mirror of https://github.com/dapr/docs.git
Merge branch 'v1.8' into shubham1172/fix-js-sdk-docs
This commit is contained in:
Mark Fussell
GitHub
commit
bfcfd49759
|
|
@ -23,8 +23,9 @@ The following are the building blocks provided by Dapr:
|
|||
| [**Service-to-service invocation**]({{<ref "service-invocation-overview.md">}}) | `/v1.0/invoke` | Service invocation enables applications to communicate with each other through well-known endpoints in the form of http or gRPC messages. Dapr provides an endpoint that acts as a combination of a reverse proxy with built-in service discovery, while leveraging built-in distributed tracing and error handling.
|
||||
| [**State management**]({{<ref "state-management-overview.md">}}) | `/v1.0/state` | Application state is anything an application wants to preserve beyond a single session. Dapr provides a key/value-based state and query APIs with pluggable state stores for persistence.
|
||||
| [**Publish and subscribe**]({{<ref "pubsub-overview.md">}}) | `/v1.0/publish` `/v1.0/subscribe`| Pub/Sub is a loosely coupled messaging pattern where senders (or publishers) publish messages to a topic, to which subscribers subscribe. Dapr supports the pub/sub pattern between applications.
|
||||
| [**Resource bindings**]({{<ref "bindings-overview.md">}}) | `/v1.0/bindings` | A binding provides a bi-directional connection to an external cloud/on-premise service or system. Dapr allows you to invoke the external service through the Dapr binding API, and it allows your application to be triggered by events sent by the connected service.
|
||||
| [**Bindings**]({{<ref "bindings-overview.md">}}) | `/v1.0/bindings` | A binding provides a bi-directional connection to an external cloud/on-premise service or system. Dapr allows you to invoke the external service through the Dapr binding API, and it allows your application to be triggered by events sent by the connected service.
|
||||
| [**Actors**]({{<ref "actors-overview.md">}}) | `/v1.0/actors` | An actor is an isolated, independent unit of compute and state with single-threaded execution. Dapr provides an actor implementation based on the virtual actor pattern which provides a single-threaded programming model and where actors are garbage collected when not in use.
|
||||
| [**Observability**]({{<ref "observability-concept.md">}}) | `N/A` | Dapr system components and runtime emit metrics, logs, and traces to debug, operate and monitor Dapr system services, components and user applications.
|
||||
| [**Secrets**]({{<ref "secrets-overview.md">}}) | `/v1.0/secrets` | Dapr provides a secrets building block API and integrates with secret stores such as public cloud stores, local stores and Kubernetes to store the secrets. Services can call the secrets API to retrieve secrets, for example to get a connection string to a database.
|
||||
| [**Configuration**]({{<ref "configuration-api-overview.md">}}) | `/v1.0-alpha1/configuration` | Dapr provides a Configuration API that enables you to retrieve and subscribe to application configuration items for supported configuration stores. This enables an application to retrieve specific configuration information, for example, at start up or when configuration changes are made in the store.
|
||||
| [**Configuration**]({{<ref "configuration-api-overview.md">}}) | `/v1.0-alpha1/configuration` | The Configuration API enables you to retrieve and subscribe to application configuration items for supported configuration stores. This enables an application to retrieve specific configuration information, for example, at start up or when configuration changes are made in the store.
|
||||
| [**Distributed lock**]({{<ref "distributed-lock-api-overview.md">}}) | `/v1.0-alpha1/lock` | The distributed lock API enables you to take a lock on a resource so that multiple instances of an application can access the resource without conflicts and provide consistency guarantees.
|
||||
|
|
@ -18,6 +18,9 @@ Each component has a specification (or spec) that it conforms to. Components are
|
|||
|
||||
It is important to understand that the component spec values, particularly the spec `metadata`, can change between components of the same component type, for example between different state stores, and that some design-time spec values can be overridden at runtime when making requests to a component's API. As a result, it is strongly recommended to review a [component's specs]({{<ref "components-reference">}}), paying particular attention to the sample payloads for requests to set the metadata used to interact with the component.
|
||||
|
||||
The diagram below shows some examples of the components for each component type
|
||||
<img src="/images/concepts-components.png" width=1200>
|
||||
|
||||
## Available component types
|
||||
|
||||
The following are the component types provided by Dapr:
|
||||
|
|
@ -64,6 +67,13 @@ Configuration stores are used to save application data, which can then be read b
|
|||
- [List of supported configuration stores]({{< ref supported-configuration-stores >}})
|
||||
- [Configuration store implementations](https://github.com/dapr/components-contrib/tree/master/configuration)
|
||||
|
||||
### Locks
|
||||
|
||||
Lock components are used as a distributed lock to provide mutually exclusive access to a resource such as a queue or database.
|
||||
|
||||
- [List of supported locks]({{< ref supported-locks >}})
|
||||
- [Lock implementations](https://github.com/dapr/components-contrib/tree/master/lock)
|
||||
|
||||
### Middleware
|
||||
|
||||
Dapr allows custom [middleware]({{<ref "middleware.md">}}) to be plugged into the HTTP request processing pipeline. Middleware can perform additional actions on an HTTP request, such as authentication, encryption and message transformation before the request is routed to the user code, or before the response is returned to the client. The middleware components are used with the [service invocation]({{<ref "service-invocation-overview.md">}}) building block.
|
||||
|
|
|
|||
|
|
@ -9,4 +9,43 @@ When running Dapr in [Kubernetes mode]({{< ref kubernetes >}}), a pod running th
|
|||
|
||||
## Running the operator service
|
||||
|
||||
The operator service is deployed as part of `dapr init -k`, or via the Dapr Helm charts. For more information on running Dapr on Kubernetes, visit the [Kubernetes hosting page]({{< ref kubernetes >}}).
|
||||
The operator service is deployed as part of `dapr init -k`, or via the Dapr Helm charts. For more information on running Dapr on Kubernetes, visit the [Kubernetes hosting page]({{< ref kubernetes >}}).
|
||||
|
||||
## Additional configuration options
|
||||
|
||||
The operator service includes additional configuration options.
|
||||
|
||||
### Injector watchdog
|
||||
|
||||
The operator service includes an _injector watchdog_ feature which periodically polls all pods running in your Kubernetes cluster and confirms that the Dapr sidecar is injected in those which have the `dapr.io/enabled=true` annotation. It is primarily meant to address situations where the [Injector service]({{< ref sidecar-injector >}}) did not successfully inject the sidecar (the `daprd` container) into pods.
|
||||
|
||||
|
||||
The injector watchdog can be useful in a few situations, including:
|
||||
|
||||
- Recovering from a Kubernetes cluster completely stopped. When a cluster is completely stopped and then restarted (including in the case of a total cluster failure), pods are restarted in a random order. If your application is restarted before the Dapr control plane (specifically the Injector service) is ready, the Dapr sidecar may not be injected into your application's pods, causing your application to behave unexpectedly.
|
||||
|
||||
- Addressing potential random failures with the sidecar injector, such as transient failures within the Injector service.
|
||||
|
||||
|
||||
If the watchdog detects a pod that does not have a sidecar when it should have had one, it deletes it. Kubernetes will then re-create the pod, invoking the Dapr sidecar injector again.
|
||||
|
||||
The injector watchdog feature is **disabled by default**.
|
||||
|
||||
You can enable it by passing the `--watch-interval` flag to the `operator` command, which can take one of the following values:
|
||||
|
||||
|
||||
- `--watch-interval=0`: disables the injector watchdog (default value if the flag is omitted).
|
||||
- `--watch-interval=<interval>`: the injector watchdog is enabled and polls all pods at the given interval; the value for the interval is a string that includes the unit. For example: `--watch-interval=10s` (every 10 seconds) or `--watch-interval=2m` (every 2 minutes).
|
||||
- `--watch-interval=once`: the injector watchdog runs only once when the operator service is started.
|
||||
|
||||
If you're using Helm, you can configure the injector watchdog with the [`dapr_operator.watchInterval` option](https://github.com/dapr/dapr/blob/master/charts/dapr/README.md#dapr-operator-options), which has the same values as the command line flags.
|
||||
|
||||
|
||||
> The injector watchdog is safe to use when the operator service is running in HA (High Availability) mode with more than one replica. In this case, Kubernetes automatically elects a "leader" instance which is the only one that runs the injector watchdog service.
|
||||
|
||||
> However, when in HA mode, if you configure the injector watchdog to run "once", the watchdog polling is actually started every time an instance of the operator service is elected as leader. This means that, should the leader of the operator service crash and a new leader be elected, that would trigger the injector watchdog again.
|
||||
|
||||
Watch this video for an overview of the injector watchdog:
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="360" height="315" src="https://www.youtube-nocookie.com/embed/ecFvpp24lpo?start=1848" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
|
|
|||
|
|
@ -43,6 +43,7 @@ Each of these building block APIs is independent, meaning that you can use one,
|
|||
| [**Observability**]({{<ref "observability-concept.md">}}) | Dapr emits metrics, logs, and traces to debug and monitor both Dapr and user applications. Dapr supports distributed tracing to easily diagnose and serve inter-service calls in production using the W3C Trace Context standard and Open Telemetry to send to different monitoring tools.
|
||||
| [**Secrets**]({{<ref "secrets-overview.md">}}) | The secrets management API integrates with public cloud and local secret stores to retrieve the secrets for use in application code.
|
||||
| [**Configuration**]({{<ref "configuration-api-overview.md">}}) | The configuration API enables you to retrieve and subscribe to application configuration items from configuration stores.
|
||||
| [**Distributed lock**]({{<ref "distributed-lock-api-overview.md">}}) | The distributed lock API enables your application to aquire a lock for any resource that gives it exclusive access until either the lock is released by the application, or a lease timeout occurs.
|
||||
|
||||
## Sidecar architecture
|
||||
|
||||
|
|
@ -60,7 +61,7 @@ In [self-hosted mode]({{< ref self-hosted-overview.md >}}) Dapr runs as a separa
|
|||
|
||||
You can use the [Dapr CLI](https://github.com/dapr/cli#launch-dapr-and-your-app) to run a Dapr-enabled application on your local machine. The diagram below show Dapr's local development environment when configured with the CLI `init` command. Try this out with the [getting started samples]({{< ref getting-started >}}).
|
||||
|
||||
<img src="/images/overview_standalone.png" width=1200 alt="Architecture diagram of Dapr in self-hosted mode">
|
||||
<img src="/images/overview-standalone.png" width=1200 alt="Architecture diagram of Dapr in self-hosted mode">
|
||||
|
||||
### Kubernetes
|
||||
|
||||
|
|
@ -72,7 +73,7 @@ The `dapr-sentry` service is a certificate authority that enables mutual TLS bet
|
|||
|
||||
Deploying and running a Dapr-enabled application into your Kubernetes cluster is as simple as adding a few annotations to the deployment schemes. Visit the [Dapr on Kubernetes docs]({{< ref kubernetes >}})
|
||||
|
||||
<img src="/images/overview_kubernetes.png" width=1200 alt="Architecture diagram of Dapr in Kubernetes mode">
|
||||
<img src="/images/overview-kubernetes.png" width=1200 alt="Architecture diagram of Dapr in Kubernetes mode">
|
||||
|
||||
### Clusters of physical or virtual machines
|
||||
|
||||
|
|
@ -107,9 +108,9 @@ Dapr can be used from any developer framework. Here are some that have been inte
|
|||
| Language | Frameworks | Description |
|
||||
|----------|------------|-------------|
|
||||
| [.NET]({{< ref dotnet >}}) | [ASP.NET Core]({{< ref dotnet-aspnet.md >}}) | Brings stateful routing controllers that respond to pub/sub events from other services. Can also take advantage of [ASP.NET Core gRPC Services](https://docs.microsoft.com/aspnet/core/grpc/).
|
||||
| [Java]({{< ref java >}}) | [Spring Boot](https://spring.io/)
|
||||
| [Python]({{< ref python >}}) | [Flask]({{< ref python-flask.md >}})
|
||||
| [Javascript](https://github.com/dapr/js-sdk) | [Express](http://expressjs.com/)
|
||||
| [Java]({{< ref java >}}) | [Spring Boot](https://spring.io/) | Build Spring boot applications with Dapr APIs
|
||||
| [Python]({{< ref python >}}) | [Flask]({{< ref python-flask.md >}}) | Build Flask applications with Dapr APIs
|
||||
| [Javascript](https://github.com/dapr/js-sdk) | [Express](http://expressjs.com/) | Build Express applications with Dapr APIs
|
||||
| [PHP]({{< ref php >}}) | | You can serve with Apache, Nginx, or Caddyserver.
|
||||
|
||||
#### Integrations and extensions
|
||||
|
|
|
|||
|
|
@ -288,22 +288,15 @@ Refer to the documentation and examples of the [Dapr SDKs]({{< ref "developing-a
|
|||
|
||||
## Partitioning reminders
|
||||
|
||||
{{% alert title="Preview feature" color="warning" %}}
|
||||
Actor reminders partitioning is currently in [preview]({{< ref preview-features.md >}}). Use this feature if you are runnining into issues due to a high number of reminders registered.
|
||||
{{% /alert %}}
|
||||
Actor reminders are persisted and continue to be triggered after sidecar restarts. Applications with multiple reminders registered can experience the following issues:
|
||||
|
||||
Actor reminders are persisted and continue to be triggered after sidecar restarts. Prior to Dapr runtime version 1.3, reminders were persisted on a single record in the actor state store:
|
||||
- Low throughput on reminders registration and de-registration
|
||||
- Limit on the total number of reminders registered based on the single record size limit on the state store
|
||||
|
||||
| Key | Value |
|
||||
| ----------- | ----------- |
|
||||
| `actors\|\|<actor type>` | `[ <reminder 1>, <reminder 2>, ... , <reminder n> ]` |
|
||||
Applications can enable partitioning of actor reminders while data is distributed in multiple keys in the state store.
|
||||
|
||||
Applications that register many reminders can experience the following issues:
|
||||
|
||||
* Low throughput on reminders registration and deregistration
|
||||
* Limit on total number of reminders registered based on the single record size limit on the state store
|
||||
|
||||
Since version 1.3, applications can now enable partitioning of actor reminders in the state store. As data is distributed in multiple keys in the state store. First, there is a metadata record in `actors\|\|<actor type>\|\|metadata` that is used to store persisted configuration for a given actor type. Then, there are multiple records that stores subsets of the reminders for the same actor type.
|
||||
1. A metadata record in `actors\|\|<actor type>\|\|metadata` is used to store persisted configuration for a given actor type.
|
||||
1. Multiple records store subsets of the reminders for the same actor type.
|
||||
|
||||
| Key | Value |
|
||||
| ----------- | ----------- |
|
||||
|
|
@ -312,16 +305,18 @@ Since version 1.3, applications can now enable partitioning of actor reminders i
|
|||
| `actors\|\|<actor type>\|\|<actor metadata identifier>\|\|reminders\|\|2` | `[ <reminder 1-1>, <reminder 1-2>, ... , <reminder 1-m> ]` |
|
||||
| ... | ... |
|
||||
|
||||
If the number of partitions is not enough, it can be changed and Dapr's sidecar will automatically redistribute the reminders's set.
|
||||
If you need to change the number of partitions, Dapr's sidecar will automatically redistribute the reminders's set.
|
||||
|
||||
### Enabling actor reminders partitioning
|
||||
|
||||
#### Actor runtime configuration for actor reminders partitioning
|
||||
First, the actor runtime must provide the appropriate configuration to partition actor reminders. This is done by the actor's endpoint for `GET /dapr/config`, similar to other actor configuration elements.
|
||||
|
||||
Similar to other actor configuration elements, the actor runtime provides the appropriate configuration to partition actor reminders via the actor's endpoint for `GET /dapr/config`.
|
||||
|
||||
{{< tabs Java Dotnet Python Go >}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```java
|
||||
// import io.dapr.actors.runtime.ActorRuntime;
|
||||
// import java.time.Duration;
|
||||
|
|
@ -331,10 +326,11 @@ ActorRuntime.getInstance().getConfig().setActorScanInterval(Duration.ofSeconds(3
|
|||
ActorRuntime.getInstance().getConfig().setRemindersStoragePartitions(7);
|
||||
```
|
||||
|
||||
See [this example](https://github.com/dapr/java-sdk/blob/master/examples/src/main/java/io/dapr/examples/actors/DemoActorService.java)
|
||||
For more information, see [the Java actors example](https://github.com/dapr/java-sdk/blob/master/examples/src/main/java/io/dapr/examples/actors/DemoActorService.java)
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```csharp
|
||||
// In Startup.cs
|
||||
public void ConfigureServices(IServiceCollection services)
|
||||
|
|
@ -356,10 +352,12 @@ public void ConfigureServices(IServiceCollection services)
|
|||
services.AddSingleton<BankService>();
|
||||
}
|
||||
```
|
||||
See the .NET SDK [documentation](https://github.com/dapr/dotnet-sdk/blob/master/daprdocs/content/en/dotnet-sdk-docs/dotnet-actors/dotnet-actors-usage.md#registering-actors).
|
||||
|
||||
See the .NET SDK [documentation for registering actors](https://github.com/dapr/dotnet-sdk/blob/master/daprdocs/content/en/dotnet-sdk-docs/dotnet-actors/dotnet-actors-usage.md#registering-actors).
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```python
|
||||
from datetime import timedelta
|
||||
|
||||
|
|
@ -371,9 +369,11 @@ ActorRuntime.set_actor_config(
|
|||
)
|
||||
)
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```go
|
||||
type daprConfig struct {
|
||||
Entities []string `json:"entities,omitempty"`
|
||||
|
|
@ -399,11 +399,12 @@ func configHandler(w http.ResponseWriter, r *http.Request) {
|
|||
json.NewEncoder(w).Encode(daprConfigResponse)
|
||||
}
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
The following, is an example of a valid configuration for reminder partitioning:
|
||||
The following is an example of a valid configuration for reminder partitioning:
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -413,7 +414,14 @@ The following, is an example of a valid configuration for reminder partitioning:
|
|||
```
|
||||
|
||||
#### Handling configuration changes
|
||||
To configure actor reminders partitioning, Dapr persists the actor type metadata in the actor's state store. This allows the configuration changes to be applied globally and not only in a single sidecar instance. Also the **number of partitions can only be increased and not decreased**. This allows Dapr to automatically redistribute the data on a rolling restart where one or more partition configurations might be active.
|
||||
|
||||
To configure actor reminders partitioning, Dapr persists the actor type metadata in the actor's state store. This allows the configuration changes to be applied globally, not just in a single sidecar instance.
|
||||
|
||||
Also, **you can only increase the number of partitions**, not decrease. This allows Dapr to automatically redistribute the data on a rolling restart where one or more partition configurations might be active.
|
||||
|
||||
#### Demo
|
||||
* [Actor reminder partitioning presented in community call](https://youtu.be/ZwFOEUYe1WA?t=1493)
|
||||
|
||||
Watch [this video for a demo of actor reminder partitioning](https://youtu.be/ZwFOEUYe1WA?t=1493):
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/ZwFOEUYe1WA?start=1495" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
|
@ -14,9 +14,9 @@ Consuming application configuration is a common task when writing applications a
|
|||
|
||||
It is worth noting that this configuration API should not be confused with the [Dapr sidecar and control plane configuration]({{<ref "configuration-overview">}}) which is used to set policies and settings on instances of Dapr sidecars or the installed Dapr control plane.
|
||||
|
||||
## Features
|
||||
*This API is currently in `Alpha` state*
|
||||
|
||||
*This API is currently in `Alpha` state and only available on gRPC. An HTTP1.1 supported version with this URL syntax `/v1.0/configuration` will be available before the API is certified into `Stable` state.*
|
||||
## Features
|
||||
|
||||
## Next steps
|
||||
Follow these guides on:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,7 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Distributed lock"
|
||||
linkTitle: "Distributed lock"
|
||||
weight: 90
|
||||
description: Distributed locks provide mutually exclusive access to shared resources from an application.
|
||||
---
|
||||
|
|
@ -0,0 +1,43 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Distributed lock overview"
|
||||
linkTitle: "Overview"
|
||||
weight: 1000
|
||||
description: "Overview of the distributed lock API building block"
|
||||
---
|
||||
|
||||
## Introduction
|
||||
Locks are used to provide mutually exclusive access to a resource. For example, you can use a lock to:
|
||||
|
||||
- Provide exclusive access to a database row, table, or an entire database
|
||||
- Lock reading messages from a queue in a sequential manner
|
||||
|
||||
Any resource that is shared where updates occur can be the target for a lock. Locks are usually used on operations that mutate state, not on reads.
|
||||
|
||||
Each lock has a name. The application determines the resources that the named lock accesses. Typically, multiple instances of the same application use this named lock to exclusively access the resource and perform updates.
|
||||
|
||||
For example, in the competing consumer pattern, multiple instances of an application access a queue. You can decide that you want to lock the queue while the application is running its business logic.
|
||||
|
||||
In the diagram below, two instances of the same application, `App1`, use the [Redis lock component]({{< ref redis-lock >}}) to take a lock on a shared resource.
|
||||
|
||||
- The first app instance acquires the named lock and gets exclusive access.
|
||||
- The second app instance is unable to acquire the lock and therefore is not allowed to access the resource until the lock is released, either:
|
||||
- Explicitly by the application through the unlock API, or
|
||||
- After a period of time, due to a lease timeout.
|
||||
|
||||
<img src="/images/lock-overview.png" width=900>
|
||||
|
||||
*This API is currently in `Alpha` state.
|
||||
|
||||
## Features
|
||||
|
||||
### Mutually exclusive access to a resource
|
||||
At any given moment, only one instance of an application can hold a named lock. Locks are scoped to a Dapr app-id.
|
||||
|
||||
### Deadlock free using leases
|
||||
Dapr distributed locks use a lease-based locking mechanism. If an application acquires a lock, encounters an exception, and cannot free the lock, the lock is automatically released after a period of time using a lease. This prevents resource deadlocks in the event of application failures.
|
||||
|
||||
## Next steps
|
||||
Follow these guides on:
|
||||
- [How-To: Use distributed locks in your application]({{< ref howto-use-distributed-lock.md >}})
|
||||
|
||||
|
|
@ -0,0 +1,66 @@
|
|||
---
|
||||
type: docs
|
||||
title: "How-To: Use a lock"
|
||||
linkTitle: "How-To: Use a lock"
|
||||
weight: 2000
|
||||
description: "Learn how to use distributed locks to provide exclusive access to a resource"
|
||||
---
|
||||
|
||||
Now that you've learned what the Dapr distributed lock API building block provides, learn how it can work in your service. The example below describes an application that aquires a lock. This example uses the Redis lock component to demonstrate how to lock resources.
|
||||
|
||||
<img src="/images/building-block-lock-example.png" width=1000 alt="Diagram showing aquiring a lock from multiple instances of same application">
|
||||
<img src="/images/building-block-lock-unlock-example.png" width=1000 alt="Diagram showing releasing a lock from multiple instances of same application">
|
||||
<img src="/images/building-block-lock-multiple-example.png" width=1000 alt="Diagram showing aquiring multiple locks from different applications">
|
||||
|
||||
### Configure a lock component
|
||||
|
||||
Save the following component file to the [default components folder]({{< ref "install-dapr-selfhost.md#step-5-verify-components-directory-has-been-initialized" >}}) on your machine.
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: lock
|
||||
spec:
|
||||
type: lock.redis
|
||||
metadata:
|
||||
- name: redisHost
|
||||
value: localhost:6379
|
||||
- name: redisPassword
|
||||
value: <PASSWORD>
|
||||
```
|
||||
|
||||
### Get configuration items using Dapr SDKs
|
||||
|
||||
{{< tabs Dotnet Java Python>}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```csharp
|
||||
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```java
|
||||
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```python
|
||||
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
## Next steps
|
||||
|
||||
* Read [distributed lock API overview]({{< ref distributed-lock-api-overview.md >}})
|
||||
|
|
@ -17,6 +17,10 @@ Using Dapr's secret store building block typically involves the following:
|
|||
1. Retrieving secrets using the Dapr secrets API in the application code.
|
||||
1. Optionally, referencing secrets in Dapr component files.
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
By default, Dapr enables a built-in [Kubernetes secret store in Kubernetes mode]({{<ref "kubernetes-secret-store.md">}}) deployed either via the Helm defaults or `dapr init -k`. If you are using another secret store, you can disable (not configure) the Dapr Kubernetes secret store using the `disable-builtin-k8s-secret-store` setting, when set to `true` through the Helm settings. The default is `false`.
|
||||
{{% /alert %}}
|
||||
|
||||
## Setting up a secret store
|
||||
|
||||
See [Setup secret stores]({{< ref howto-secrets.md >}}) for guidance on how to setup a secret store with Dapr.
|
||||
|
|
|
|||
|
|
@ -8,8 +8,9 @@ description: "Recommendations and practices for deploying Dapr to a Kubernetes c
|
|||
|
||||
## Cluster capacity requirements
|
||||
|
||||
For a production-ready Kubernetes cluster deployment, it is recommended you run a cluster of at least 3 worker nodes to support a highly-available control plane installation.
|
||||
Use the following resource settings as a starting point. Requirements will vary depending on cluster size and other factors, so perform individual testing to find the right values for your environment:
|
||||
For a production-ready Kubernetes cluster deployment, we recommended you run a cluster of at least 3 worker nodes to support a highly-available control plane installation.
|
||||
|
||||
Use the following resource settings as a starting point. Requirements will vary depending on cluster size and other factors, so you should perform individual testing to find the right values for your environment:
|
||||
|
||||
| Deployment | CPU | Memory
|
||||
|-------------|-----|-------
|
||||
|
|
@ -21,20 +22,23 @@ Use the following resource settings as a starting point. Requirements will vary
|
|||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
For more info, read the [concept article on CPU and Memory resource units and their meaning](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes).
|
||||
|
||||
{{% /alert %}}
|
||||
|
||||
### Helm
|
||||
|
||||
When installing Dapr using Helm, no default limit/request values are set. Each component has a `resources` option (for example, `dapr_dashboard.resources`), which you can use to tune the Dapr control plane to fit your environment. The [Helm chart readme](https://github.com/dapr/dapr/blob/master/charts/dapr/README.md) has detailed information and examples. For local/dev installations, you might simply want to skip configuring the `resources` options.
|
||||
When installing Dapr using Helm, no default limit/request values are set. Each component has a `resources` option (for example, `dapr_dashboard.resources`), which you can use to tune the Dapr control plane to fit your environment.
|
||||
|
||||
The [Helm chart readme](https://github.com/dapr/dapr/blob/master/charts/dapr/README.md) has detailed information and examples.
|
||||
|
||||
For local/dev installations, you might simply want to skip configuring the `resources` options.
|
||||
|
||||
### Optional components
|
||||
|
||||
The following Dapr control plane deployments are optional:
|
||||
|
||||
- **Placement** - Needed for Dapr Actors
|
||||
- **Sentry** - Needed for mTLS for service to service invocation
|
||||
- **Dashboard** - Needed for operational view of the cluster
|
||||
- **Placement**: needed to use Dapr Actors
|
||||
- **Sentry**: needed for mTLS for service to service invocation
|
||||
- **Dashboard**: needed to get an operational view of the cluster
|
||||
|
||||
## Sidecar resource settings
|
||||
|
||||
|
|
@ -58,14 +62,13 @@ Example settings for the Dapr sidecar in a production-ready setup:
|
|||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
Since Dapr is intended to do much of the I/O heavy lifting for your app, it's expected that the resources given to Dapr enable you to drastically reduce the resource allocations for the application.
|
||||
|
||||
{{% /alert %}}
|
||||
|
||||
The CPU and memory limits above account for the fact that Dapr is intended to a high number of I/O bound operations. It is strongly recommended that you use a monitoring tool to baseline the sidecar (and app) containers and tune these settings based on those baselines.
|
||||
The CPU and memory limits above account for the fact that Dapr is intended to support a high number of I/O bound operations. It is strongly recommended that you use a monitoring tool to get a baseline for the sidecar (and app) containers and tune these settings based on those baselines.
|
||||
|
||||
## Highly-available mode
|
||||
|
||||
When deploying Dapr in a production-ready configuration, it's recommended to deploy with a highly available (HA) configuration of the control plane, which creates 3 replicas of each control plane pod in the dapr-system namespace. This configuration allows the Dapr control plane to retain 3 running instances and survive node failures and other outages.
|
||||
When deploying Dapr in a production-ready configuration, it is recommend to deploy with a highly available (HA) configuration of the control plane, which creates 3 replicas of each control plane pod in the dapr-system namespace. This configuration allows the Dapr control plane to retain 3 running instances and survive individual node failures and other outages.
|
||||
|
||||
For a new Dapr deployment, the HA mode can be set with both the [Dapr CLI]({{< ref "kubernetes-deploy.md#install-in-highly-available-mode" >}}) and with [Helm charts]({{< ref "kubernetes-deploy.md#add-and-install-dapr-helm-chart" >}}).
|
||||
|
||||
|
|
@ -76,6 +79,7 @@ For an existing Dapr deployment, enabling the HA mode requires additional steps.
|
|||
[Visit the full guide on deploying Dapr with Helm]({{< ref "kubernetes-deploy.md#install-with-helm-advanced" >}}).
|
||||
|
||||
### Parameters file
|
||||
|
||||
Instead of specifying parameters on the command line, it's recommended to create a values file. This file should be checked into source control so that you can track its changes.
|
||||
|
||||
For a full list of all available options you can set in the values file (or by using the `--set` command-line option), see https://github.com/dapr/dapr/blob/master/charts/dapr/README.md.
|
||||
|
|
@ -119,7 +123,7 @@ The Dapr Helm chart automatically deploys with affinity for nodes with the label
|
|||
|
||||
## Upgrading Dapr with Helm
|
||||
|
||||
Dapr supports zero downtime upgrades. The upgrade path includes the following steps:
|
||||
Dapr supports zero-downtime upgrades. The upgrade path includes the following steps:
|
||||
|
||||
1. Upgrading a CLI version (optional but recommended)
|
||||
2. Updating the Dapr control plane
|
||||
|
|
@ -189,7 +193,6 @@ It is recommended that a production-ready deployment includes the following sett
|
|||
|
||||
6. Dapr also supports **scoping components for certain applications**. This is not a required practice, and can be enabled according to your security needs. See [here]({{< ref "component-scopes.md" >}}) for more info.
|
||||
|
||||
|
||||
## Tracing and metrics configuration
|
||||
|
||||
Dapr has tracing and metrics enabled by default. It is *recommended* that you set up distributed tracing and metrics for your applications and the Dapr control plane in production.
|
||||
|
|
@ -197,15 +200,26 @@ Dapr has tracing and metrics enabled by default. It is *recommended* that you se
|
|||
If you already have your own observability set-up, you can disable tracing and metrics for Dapr.
|
||||
|
||||
### Tracing
|
||||
|
||||
To configure a tracing backend for Dapr visit [this]({{< ref "setup-tracing.md" >}}) link.
|
||||
|
||||
### Metrics
|
||||
|
||||
For metrics, Dapr exposes a Prometheus endpoint listening on port 9090 which can be scraped by Prometheus.
|
||||
|
||||
To setup Prometheus, Grafana and other monitoring tools with Dapr, visit [this]({{< ref "monitoring" >}}) link.
|
||||
|
||||
## Injector watchdog
|
||||
|
||||
The Dapr Operator service includes an _injector watchdog_ which can be used to detect and remediate situations where your application's pods may be deployed without the Dapr sidecar (the `daprd` container) when they should have been. For example, it can assist with recovering the applications after a total cluster failure.
|
||||
|
||||
The injector watchdog is disabled by default when running Dapr in Kubernetes mode and it is recommended that you consider enabling it with values that are appropriate for your specific situation.
|
||||
|
||||
Refer to the documentation for the [Dapr operator]({{< ref operator >}}) service for more details on the injector watchdog and how to enable it.
|
||||
|
||||
## Best Practices
|
||||
|
||||
Watch this video for a deep dive into the best practices for running Dapr in production with Kubernetes
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="360" height="315" src="https://www.youtube.com/embed/_U9wJqq-H1g" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
<iframe width="360" height="315" src="https://www.youtube-nocookie.com/embed/_U9wJqq-H1g" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
|
|
|||
|
|
@ -17,7 +17,9 @@ You can set the following annotations in your deployment YAML:
|
|||
1. **dapr.io/volume-mounts**: for read-only volume mounts
|
||||
1. **dapr.io/volume-mounts-rw**: for read-write volume mounts
|
||||
|
||||
These annotations are comma separated pairs of `volume:path`. Make sure that the corresponding Volumes exist in the Pod spec.
|
||||
These annotations are comma separated pairs of `volume-name:path/in/container`. Make sure that the corresponding Volumes exist in the Pod spec.
|
||||
|
||||
In the snippet below, `my-volume1` and `my-volume2` are available inside the sidecar container at `/tmp/sample1` and `/tmp/sample2` respectively, in read-only mode. `my-volume3` is available inside the sidecar container at `/tmp/sample3` in read-write mode.
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
|
|
|
|||
|
|
@ -0,0 +1,156 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Distributed Lock API reference"
|
||||
linkTitle: "Distributed Lock API"
|
||||
description: "Detailed documentation on the distributed lock API"
|
||||
weight: 660
|
||||
---
|
||||
|
||||
## Lock
|
||||
|
||||
This endpoint lets you acquire a lock by supplying a named lock owner and the resource ID to lock.
|
||||
|
||||
### HTTP Request
|
||||
|
||||
```
|
||||
POST http://localhost:<daprPort>/v1.0-alpha1/lock/<storename>
|
||||
```
|
||||
|
||||
#### URL Parameters
|
||||
|
||||
Parameter | Description
|
||||
--------- | -----------
|
||||
`daprPort` | The Dapr port
|
||||
`storename` | The `metadata.name` field component file. Refer to the [component schema] ({{< ref component-schema.md>}})
|
||||
|
||||
#### Query Parameters
|
||||
|
||||
None
|
||||
|
||||
### HTTP Response codes
|
||||
|
||||
Code | Description
|
||||
---- | -----------
|
||||
200 | Request successful
|
||||
204 | Empty Response
|
||||
400 | Malformed request
|
||||
500 | Request failed
|
||||
|
||||
### HTTP Request Body
|
||||
|
||||
The lock endpoint receives the following JSON payload:
|
||||
|
||||
```json
|
||||
{
|
||||
"resourceId": "",
|
||||
"lockOwner": "",
|
||||
"expiryInSeconds": 0
|
||||
}
|
||||
```
|
||||
|
||||
Field | Description
|
||||
---- | -----------
|
||||
resourceId | The ID of the resource to lock. Can be any value
|
||||
lockOwner | The name of the lock owner. Should be set to a unique value per-request
|
||||
expiryInSeconds | The time in seconds to hold the lock before it expires
|
||||
|
||||
### HTTP Response Body
|
||||
|
||||
The lock endpoint returns the following payload:
|
||||
|
||||
```json
|
||||
{
|
||||
"success": true
|
||||
}
|
||||
```
|
||||
|
||||
### Examples
|
||||
|
||||
```shell
|
||||
curl -X POST http://localhost:3500/v1.0-alpha/lock/redisStore \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"resourceId": "lock1",
|
||||
"lockOwner": "vader",
|
||||
"expiryInSeconds": 60
|
||||
}'
|
||||
|
||||
{
|
||||
"success": "true"
|
||||
}
|
||||
```
|
||||
|
||||
## Unlock
|
||||
|
||||
This endpoint lets you unlock an existing lock based on the lock owner and resource Id
|
||||
|
||||
### HTTP Request
|
||||
|
||||
```
|
||||
POST http://localhost:<daprPort>/v1.0-alpha1/unlock/<storename>
|
||||
```
|
||||
|
||||
#### URL Parameters
|
||||
|
||||
Parameter | Description
|
||||
--------- | -----------
|
||||
`daprPort` | The Dapr port
|
||||
`storename` | The `metadata.name` field component file. Refer to the [component schema] ({{< ref component-schema.md>}})
|
||||
|
||||
#### Query Parameters
|
||||
|
||||
None
|
||||
|
||||
### HTTP Response codes
|
||||
|
||||
Code | Description
|
||||
---- | -----------
|
||||
200 | Request successful
|
||||
204 | Empty Response
|
||||
400 | Malformed request
|
||||
500 | Request failed
|
||||
|
||||
### HTTP Request Body
|
||||
|
||||
The unlock endpoint receives the following JSON payload:
|
||||
|
||||
```json
|
||||
{
|
||||
"resourceId": "",
|
||||
"lockOwner": ""
|
||||
}
|
||||
```
|
||||
|
||||
### HTTP Response Body
|
||||
|
||||
The unlock endpoint returns the following payload:
|
||||
|
||||
```json
|
||||
{
|
||||
"status": 0
|
||||
}
|
||||
```
|
||||
|
||||
The `status` field contains the following response codes:
|
||||
|
||||
Code | Description
|
||||
---- | -----------
|
||||
0 | Success
|
||||
1 | Lock doesn't exist
|
||||
2 | Lock belongs to another owner
|
||||
3 | Internal error
|
||||
|
||||
### Examples
|
||||
|
||||
```shell
|
||||
curl -X POST http://localhost:3500/v1.0-alpha/unlock/redisStore \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"resourceId": "lock1",
|
||||
"lockOwner": "vader"
|
||||
}'
|
||||
|
||||
{
|
||||
"status": 0
|
||||
}
|
||||
```
|
||||
|
|
@ -58,4 +58,5 @@ This table is meant to help users understand the equivalent options for running
|
|||
| not supported | not supported | | `dapr.io/sidecar-readiness-probe-threshold` | When the sidecar readiness probe fails, Kubernetes will try N times before giving up. In this case, the Pod will be marked Unready. Read more about `failureThreshold` [here](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes). Default is `3`|
|
||||
| not supported | not supported | | `dapr.io/env` | List of environment variable to be injected into the sidecar. Strings consisting of key=value pairs separated by a comma.|
|
||||
| not supported | not supported | | `dapr.io/volume-mounts` | List of pod volumes to be mounted to the sidecar container in read-only mode. Strings consisting of `volume:path` pairs separated by a comma. Example, `"volume-1:/tmp/mount1,volume-2:/home/root/mount2"`. |
|
||||
| not supported | not supported | | `dapr.io/volume-mounts-rw` | List of pod volumes to be mounted to the sidecar container in read-write mode. Strings consisting of `volume:path` pairs separated by a comma. Example, `"volume-1:/tmp/mount1,volume-2:/home/root/mount2"`. |
|
||||
| not supported | not supported | | `dapr.io/volume-mounts-rw` | List of pod volumes to be mounted to the sidecar container in read-write mode. Strings consisting of `volume:path` pairs separated by a comma. Example, `"volume-1:/tmp/mount1,volume-2:/home/root/mount2"`. |
|
||||
| `--disable-builtin-k8s-secret-store` | not supported | | `dapr.io/disable-builtin-k8s-secret-store` | Disables BuiltIn Kubernetes secret store. Default value is false. See [Kubernetes secret store component]({{<ref "kubernetes-secret-store.md">}}) for details. |
|
||||
|
|
@ -71,6 +71,7 @@ You can learn more about each Dapr command from the links below.
|
|||
- [`dapr stop`]({{< ref dapr-stop.md >}})
|
||||
- [`dapr uninstall`]({{< ref dapr-uninstall.md >}})
|
||||
- [`dapr upgrade`]({{< ref dapr-upgrade.md >}})
|
||||
- [`dapr-version`]({{< ref dapr-version.md >}})
|
||||
|
||||
### Environment Variables
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ dapr init [flags]
|
|||
| `--slim`, `-s` | | `false` | Exclude placement service, Redis and Zipkin containers from self-hosted installation |
|
||||
| `--timeout` | | `300` | The wait timeout for the Kubernetes installation |
|
||||
| `--wait` | | `false` | Wait for Kubernetes initialization to complete |
|
||||
| N/A |DAPR_DEFAULT_IMAGE_REGISTRY| | In self hosted mode, it is used to specify the default container registry to pull images from. When its value is set to `GHCR` or `ghcr` it pulls the required images from Github container registry. To default to Docker hub as default, just unset this env variable.|
|
||||
| N/A |DAPR_DEFAULT_IMAGE_REGISTRY| | It is used to specify the default container registry to pull images from. When its value is set to `GHCR` or `ghcr` it pulls the required images from Github container registry. To default to Docker hub, unset the environment variable or leave it blank|
|
||||
|
||||
### Examples
|
||||
|
||||
|
|
@ -119,4 +119,15 @@ Use the `--set` flag to configure a set of [Helm Chart values](https://github.co
|
|||
|
||||
```bash
|
||||
dapr init -k --set global.tag=1.0.0 --set dapr_operator.logLevel=error
|
||||
```
|
||||
|
||||
You can also specify a private registry to pull container images from. As of now `dapr init -k` does not use specific images for sentry, operator, placement and sidecar. It relies on only Dapr runtime container image `dapr` for all these images.
|
||||
|
||||
Scenario 1 : dapr image hosted directly under root folder in private registry -
|
||||
```bash
|
||||
dapr init -k --image-registry docker.io/username
|
||||
```
|
||||
Scenario 2 : dapr image hosted under a new/different directory in private registry -
|
||||
```bash
|
||||
dapr init -k --image-registry docker.io/username/<directory-name>
|
||||
```
|
||||
|
|
@ -33,6 +33,7 @@ dapr upgrade [flags]
|
|||
| `--kubernetes`, `-k` | | `false` | Upgrade/Downgrade Dapr in a Kubernetes cluster |
|
||||
| `--runtime-version` | | `latest` | The version of the Dapr runtime to upgrade/downgrade to, for example: `1.0.0` |
|
||||
| `--set` | | | Set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) |
|
||||
| `--image-registry` | | | Pulls container images required by Dapr from the given image registry |
|
||||
|
||||
### Examples
|
||||
|
||||
|
|
@ -46,6 +47,14 @@ dapr upgrade -k --runtime-version 1.2
|
|||
# Upgrade or downgrade to a specified version of Dapr runtime in Kubernetes with value set
|
||||
dapr upgrade -k --runtime-version 1.2 --set global.logAsJson=true
|
||||
```
|
||||
```bash
|
||||
# Upgrade or downgrade using private registry, if you are using private registry for hosting dapr images and have used it while doing `dapr init -k`
|
||||
# Scenario 1 : dapr image hosted directly under root folder in private registry -
|
||||
dapr init -k --image-registry docker.io/username
|
||||
# Scenario 2 : dapr image hosted under a new/different directory in private registry -
|
||||
dapr init -k --image-registry docker.io/username/<directory-name>
|
||||
```
|
||||
|
||||
### Warning messages
|
||||
This command can issue warning messages.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,41 @@
|
|||
---
|
||||
type: docs
|
||||
title: "version CLI command reference"
|
||||
linkTitle: "version"
|
||||
description: "Print Dapr runtime and CLI version."
|
||||
---
|
||||
|
||||
### Description
|
||||
|
||||
Print the version for `dapr` CLI and `daprd` executables either in normal or JSON formats.
|
||||
|
||||
### Supported platforms
|
||||
|
||||
- [Self-Hosted]({{< ref self-hosted >}})
|
||||
|
||||
### Usage
|
||||
|
||||
```bash
|
||||
dapr version [flags]
|
||||
```
|
||||
|
||||
### Flags
|
||||
|
||||
| Name | Environment Variable | Default | Description
|
||||
| --- | --- | --- | --- |
|
||||
| `--help`, `-h` | | | Print this help message |
|
||||
| `--output`, `-o` | | | Output format (options: json) |
|
||||
|
||||
### Examples
|
||||
|
||||
```bash
|
||||
# Version for Dapr CLI and runtime
|
||||
dapr version --output json
|
||||
```
|
||||
|
||||
### Related facts
|
||||
|
||||
You can get `daprd` version directly by invoking `daprd --version` command.
|
||||
|
||||
|
||||
You can also get the normal version output by running `dapr --version` flag.
|
||||
|
|
@ -58,7 +58,7 @@ The above example uses secrets as plain strings. It is recommended to use a secr
|
|||
|
||||
## Setup Redis
|
||||
|
||||
Dapr can use any Redis instance - containerized, running on your local dev machine, or a managed cloud service.
|
||||
Dapr can use any Redis instance: containerized, running on your local dev machine, or a managed cloud service.
|
||||
|
||||
{{< tabs "Self-Hosted" "Kubernetes" "Azure" "AWS" "GCP" >}}
|
||||
|
||||
|
|
@ -67,7 +67,7 @@ A Redis instance is automatically created as a Docker container when you run `da
|
|||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
We can use [Helm](https://helm.sh/) to quickly create a Redis instance in our Kubernetes cluster. This approach requires [Installing Helm](https://github.com/helm/helm#install).
|
||||
You can use [Helm](https://helm.sh/) to quickly create a Redis instance in our Kubernetes cluster. This approach requires [Installing Helm](https://github.com/helm/helm#install).
|
||||
|
||||
1. Install Redis into your cluster. Note that we're explicitly setting an image tag to get a version greater than 5, which is what Dapr' pub/sub functionality requires. If you're intending on using Redis as just a state store (and not for pub/sub), you do not have to set the image version.
|
||||
```bash
|
||||
|
|
@ -82,8 +82,8 @@ We can use [Helm](https://helm.sh/) to quickly create a Redis instance in our Ku
|
|||
- name: redisHost
|
||||
value: redis-master:6379
|
||||
```
|
||||
4. Next, we'll get the Redis password, which is slightly different depending on the OS we're using:
|
||||
- **Windows**: Run `kubectl get secret --namespace default redis -o jsonpath="{.data.redis-password}" > encoded.b64`, which will create a file with your encoded password. Next, run `certutil -decode encoded.b64 password.txt`, which will put your redis password in a text file called `password.txt`. Copy the password and delete the two files.
|
||||
4. Next, get the Redis password, which is slightly different depending on the OS we're using:
|
||||
- **Windows**: Run `kubectl get secret --namespace default redis -o jsonpath="{.data.redis-password}" > encoded.b64`, which creates a file with your encoded password. Next, run `certutil -decode encoded.b64 password.txt`, which will put your redis password in a text file called `password.txt`. Copy the password and delete the two files.
|
||||
|
||||
- **Linux/MacOS**: Run `kubectl get secret --namespace default redis -o jsonpath="{.data.redis-password}" | base64 --decode` and copy the outputted password.
|
||||
|
||||
|
|
@ -98,13 +98,19 @@ We can use [Helm](https://helm.sh/) to quickly create a Redis instance in our Ku
|
|||
{{% codetab %}}
|
||||
**Note**: this approach requires having an Azure Subscription.
|
||||
|
||||
1. Open [this link](https://ms.portal.azure.com/#create/Microsoft.Cache) to start the Azure Cache for Redis creation flow. Log in if necessary.
|
||||
1. [Start the Azure Cache for Redis creation flow](https://ms.portal.azure.com/#create/Microsoft.Cache). Log in if necessary.
|
||||
2. Fill out necessary information and **check the "Unblock port 6379" box**, which will allow us to persist state without SSL.
|
||||
3. Click "Create" to kickoff deployment of your Redis instance.
|
||||
4. Once your instance is created, you'll need to grab the Host name (FQDN) and your access key.
|
||||
- for the Host name navigate to the resources "Overview" and copy "Host name"
|
||||
- for your access key navigate to "Access Keys" under "Settings" and copy your key.
|
||||
5. Finally, we need to add our key and our host to a `redis.yaml` file that Dapr can apply to our cluster. If you're running a sample, you'll add the host and key to the provided `redis.yaml`. If you're creating a project from the ground up, you'll create a `redis.yaml` file as specified in [Configuration](#configuration). Set the `redisHost` key to `[HOST NAME FROM PREVIOUS STEP]:6379` and the `redisPassword` key to the key you copied in step 4. **Note:** In a production-grade application, follow [secret management]({{< ref component-secrets.md >}}) instructions to securely manage your secrets.
|
||||
4. Once your instance is created, you'll need to grab the Host name (FQDN) and your access key:
|
||||
- For the Host name: navigate to the resource's "Overview" and copy "Host name".
|
||||
- For your access key: navigate to "Settings" > "Access Keys" to copy and save your key.
|
||||
5. Add your key and your host to a `redis.yaml` file that Dapr can apply to your cluster.
|
||||
- If you're running a sample, add the host and key to the provided `redis.yaml`.
|
||||
- If you're creating a project from the ground up, create a `redis.yaml` file as specified in [Configuration](#configuration).
|
||||
|
||||
Set the `redisHost` key to `[HOST NAME FROM PREVIOUS STEP]:6379` and the `redisPassword` key to the key you saved earlier.
|
||||
|
||||
**Note:** In a production-grade application, follow [secret management]({{< ref component-secrets.md >}}) instructions to securely manage your secrets.
|
||||
|
||||
> **NOTE:** Dapr pub/sub uses [Redis Streams](https://redis.io/topics/streams-intro) that was introduced by Redis 5.0, which isn't currently available on Azure Managed Redis Cache. Consequently, you can use Azure Managed Redis Cache only for state persistence.
|
||||
{{% /codetab %}}
|
||||
|
|
@ -119,7 +125,6 @@ We can use [Helm](https://helm.sh/) to quickly create a Redis instance in our Ku
|
|||
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
## Related links
|
||||
- [Basic schema for a Dapr component]({{< ref component-schema >}})
|
||||
- Read [How-To: Manage configuration from a store]({{< ref "howto-manage-configuration" >}}) for instructions on how to use Redis as a configuration store.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,12 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Lock component specs"
|
||||
linkTitle: "Locks"
|
||||
weight: 4500
|
||||
description: The supported locks that interface with Dapr
|
||||
no_list: true
|
||||
---
|
||||
|
||||
{{< partial "components/description.html" >}}
|
||||
|
||||
{{< partial "components/locks.html" >}}
|
||||
|
|
@ -0,0 +1,180 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Redis"
|
||||
linkTitle: "Redis"
|
||||
description: Detailed information on the Redis lock component
|
||||
---
|
||||
|
||||
## Component format
|
||||
|
||||
To set up the Redis lock, create a component of type `lock.redis`. See [this guide]({{< ref "howto-use-distributed-lock" >}}) on how to create a lock.
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: <NAME>
|
||||
namespace: <NAMESPACE>
|
||||
spec:
|
||||
type: lock.redis
|
||||
version: v1
|
||||
metadata:
|
||||
- name: redisHost
|
||||
value: <HOST>
|
||||
- name: redisPassword
|
||||
value: <PASSWORD>
|
||||
- name: enableTLS
|
||||
value: <bool> # Optional. Allowed: true, false.
|
||||
- name: failover
|
||||
value: <bool> # Optional. Allowed: true, false.
|
||||
- name: sentinelMasterName
|
||||
value: <string> # Optional
|
||||
- name: maxRetries
|
||||
value: # Optional
|
||||
- name: maxRetryBackoff
|
||||
value: # Optional
|
||||
- name: failover
|
||||
value: # Optional
|
||||
- name: sentinelMasterName
|
||||
value: # Optional
|
||||
- name: redeliverInterval
|
||||
value: # Optional
|
||||
- name: processingTimeout
|
||||
value: # Optional
|
||||
- name: redisType
|
||||
value: # Optional
|
||||
- name: redisDB
|
||||
value: # Optional
|
||||
- name: redisMaxRetries
|
||||
value: # Optional
|
||||
- name: redisMinRetryInterval
|
||||
value: # Optional
|
||||
- name: redisMaxRetryInterval
|
||||
value: # Optional
|
||||
- name: dialTimeout
|
||||
value: # Optional
|
||||
- name: readTimeout
|
||||
value: # Optional
|
||||
- name: writeTimeout
|
||||
value: # Optional
|
||||
- name: poolSize
|
||||
value: # Optional
|
||||
- name: poolTimeout
|
||||
value: # Optional
|
||||
- name: maxConnAge
|
||||
value: # Optional
|
||||
- name: minIdleConns
|
||||
value: # Optional
|
||||
- name: idleCheckFrequency
|
||||
value: # Optional
|
||||
- name: idleTimeout
|
||||
value: # Optional
|
||||
```
|
||||
|
||||
{{% alert title="Warning" color="warning" %}}
|
||||
The above example uses secrets as plain strings. It is recommended to use a secret store for the secrets, as described [here]({{< ref component-secrets.md >}}).
|
||||
{{% /alert %}}
|
||||
|
||||
|
||||
## Spec metadata fields
|
||||
|
||||
| Field | Required | Details | Example |
|
||||
|--------------------|:--------:|---------|---------|
|
||||
| redisHost | Y | Connection-string for the redis host | `localhost:6379`, `redis-master.default.svc.cluster.local:6379`
|
||||
| redisPassword | Y | Password for Redis host. No Default. Can be `secretKeyRef` to use a secret reference | `""`, `"KeFg23!"`
|
||||
| redisUsername | N | Username for Redis host. Defaults to empty. Make sure your redis server version is 6 or above, and have created acl rule correctly. | `""`, `"default"`
|
||||
| enableTLS | N | If the Redis instance supports TLS with public certificates, can be configured to be enabled or disabled. Defaults to `"false"` | `"true"`, `"false"`
|
||||
| maxRetries | N | Maximum number of retries before giving up. Defaults to `3` | `5`, `10`
|
||||
| maxRetryBackoff | N | Minimum backoff between each retry. Defaults to `2` seconds; `"-1"` disables backoff. | `3000000000`
|
||||
| failover | N | Property to enabled failover configuration. Needs sentinalMasterName to be set. The redisHost should be the sentinel host address. See [Redis Sentinel Documentation](https://redis.io/docs/manual/sentinel/). Defaults to `"false"` | `"true"`, `"false"`
|
||||
| sentinelMasterName | N | The sentinel master name. See [Redis Sentinel Documentation](https://redis.io/docs/manual/sentinel/) | `""`, `"127.0.0.1:6379"`
|
||||
| redeliverInterval | N | The interval between checking for pending messages to redelivery. Defaults to `"60s"`. `"0"` disables redelivery. | `"30s"`
|
||||
| processingTimeout | N | The amount time a message must be pending before attempting to redeliver it. Defaults to `"15s"`. `"0"` disables redelivery. | `"30s"`
|
||||
| redisType | N | The type of redis. There are two valid values, one is `"node"` for single node mode, the other is `"cluster"` for redis cluster mode. Defaults to `"node"`. | `"cluster"`
|
||||
| redisDB | N | Database selected after connecting to redis. If `"redisType"` is `"cluster"` this option is ignored. Defaults to `"0"`. | `"0"`
|
||||
| redisMaxRetries | N | Alias for `maxRetries`. If both values are set `maxRetries` is ignored. | `"5"`
|
||||
| redisMinRetryInterval | N | Minimum backoff for redis commands between each retry. Default is `"8ms"`; `"-1"` disables backoff. | `"8ms"`
|
||||
| redisMaxRetryInterval | N | Alias for `maxRetryBackoff`. If both values are set `maxRetryBackoff` is ignored. | `"5s"`
|
||||
| dialTimeout | N | Dial timeout for establishing new connections. Defaults to `"5s"`. | `"5s"`
|
||||
| readTimeout | N | Timeout for socket reads. If reached, redis commands will fail with a timeout instead of blocking. Defaults to `"3s"`, `"-1"` for no timeout. | `"3s"`
|
||||
| writeTimeout | N | Timeout for socket writes. If reached, redis commands will fail with a timeout instead of blocking. Defaults is readTimeout. | `"3s"`
|
||||
| poolSize | N | Maximum number of socket connections. Default is 10 connections per every CPU as reported by runtime.NumCPU. | `"20"`
|
||||
| poolTimeout | N | Amount of time client waits for a connection if all connections are busy before returning an error. Default is readTimeout + 1 second. | `"5s"`
|
||||
| maxConnAge | N | Connection age at which the client retires (closes) the connection. Default is to not close aged connections. | `"30m"`
|
||||
| minIdleConns | N | Minimum number of idle connections to keep open in order to avoid the performance degradation associated with creating new connections. Defaults to `"0"`. | `"2"`
|
||||
| idleCheckFrequency | N | Frequency of idle checks made by idle connections reaper. Default is `"1m"`. `"-1"` disables idle connections reaper. | `"-1"`
|
||||
| idleTimeout | N | Amount of time after which the client closes idle connections. Should be less than server's timeout. Default is `"5m"`. `"-1"` disables idle timeout check. | `"10m"`
|
||||
|
||||
## Setup Redis
|
||||
|
||||
Dapr can use any Redis instance: containerized, running on your local dev machine, or a managed cloud service.
|
||||
|
||||
{{< tabs "Self-Hosted" "Kubernetes" "Azure" "AWS" "GCP" >}}
|
||||
|
||||
{{% codetab %}}
|
||||
A Redis instance is automatically created as a Docker container when you run `dapr init`
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
You can use [Helm](https://helm.sh/) to quickly create a Redis instance in our Kubernetes cluster. This approach requires [Installing Helm](https://github.com/helm/helm#install).
|
||||
|
||||
1. Install Redis into your cluster. Note that we're explicitly setting an image tag to get a version greater than 5, which is what Dapr' pub/sub functionality requires. If you're intending on using Redis as just a state store (and not for pub/sub), you do not have to set the image version.
|
||||
```bash
|
||||
helm repo add bitnami https://charts.bitnami.com/bitnami
|
||||
helm install redis bitnami/redis
|
||||
```
|
||||
|
||||
2. Run `kubectl get pods` to see the Redis containers now running in your cluster.
|
||||
3. Add `redis-master:6379` as the `redisHost` in your [redis.yaml](#configuration) file. For example:
|
||||
```yaml
|
||||
metadata:
|
||||
- name: redisHost
|
||||
value: redis-master:6379
|
||||
```
|
||||
4. Next, get the Redis password, which is slightly different depending on the OS we're using:
|
||||
- **Windows**: Run `kubectl get secret --namespace default redis -o jsonpath="{.data.redis-password}" > encoded.b64`, which creates a file with your encoded password. Next, run `certutil -decode encoded.b64 password.txt`, which will put your redis password in a text file called `password.txt`. Copy the password and delete the two files.
|
||||
|
||||
- **Linux/MacOS**: Run `kubectl get secret --namespace default redis -o jsonpath="{.data.redis-password}" | base64 --decode` and copy the outputted password.
|
||||
|
||||
Add this password as the `redisPassword` value in your [redis.yaml](#configuration) file. For example:
|
||||
```yaml
|
||||
metadata:
|
||||
- name: redisPassword
|
||||
value: lhDOkwTlp0
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
**Note**: this approach requires having an Azure Subscription.
|
||||
|
||||
1. [Start the Azure Cache for Redis creation flow](https://ms.portal.azure.com/#create/Microsoft.Cache). Log in if necessary.
|
||||
2. Fill out necessary information and **check the "Unblock port 6379" box**, which will allow us to persist state without SSL.
|
||||
3. Click "Create" to kickoff deployment of your Redis instance.
|
||||
4. Once your instance is created, you'll need to grab the Host name (FQDN) and your access key:
|
||||
- For the Host name: navigate to the resource's "Overview" and copy "Host name".
|
||||
- For your access key: navigate to "Settings" > "Access Keys" to copy and save your key.
|
||||
5. Add your key and your host to a `redis.yaml` file that Dapr can apply to your cluster.
|
||||
- If you're running a sample, add the host and key to the provided `redis.yaml`.
|
||||
- If you're creating a project from the ground up, create a `redis.yaml` file as specified in [Configuration](#configuration).
|
||||
|
||||
Set the `redisHost` key to `[HOST NAME FROM PREVIOUS STEP]:6379` and the `redisPassword` key to the key you saved earlier.
|
||||
|
||||
**Note:** In a production-grade application, follow [secret management]({{< ref component-secrets.md >}}) instructions to securely manage your secrets.
|
||||
|
||||
> **NOTE:** Dapr pub/sub uses [Redis Streams](https://redis.io/topics/streams-intro) that was introduced by Redis 5.0, which isn't currently available on Azure Managed Redis Cache. Consequently, you can use Azure Managed Redis Cache only for state persistence.
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
[AWS Redis](https://aws.amazon.com/redis/)
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
[GCP Cloud MemoryStore](https://cloud.google.com/memorystore/)
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
## Related links
|
||||
- [Basic schema for a Dapr component]({{< ref component-schema >}})
|
||||
- [Distributed lock building block]({{< ref distributed-lock-api-overview >}})
|
||||
|
|
@ -29,9 +29,12 @@ metadata:
|
|||
spec:
|
||||
type: secretstores.kubernetes
|
||||
version: v1
|
||||
metadata:
|
||||
- name: ""
|
||||
metadata:[]
|
||||
```
|
||||
|
||||
## Spec metadata fields
|
||||
For the Kubernetes secret store component, there are no metadata attributes.
|
||||
|
||||
## Related links
|
||||
- [Secrets building block]({{< ref secrets >}})
|
||||
- [How-To: Retrieve a secret]({{< ref "howto-secrets.md" >}})
|
||||
|
|
|
|||
|
|
@ -35,6 +35,42 @@ spec:
|
|||
value: # Optional
|
||||
- name: maxRetryBackoff
|
||||
value: # Optional
|
||||
- name: failover
|
||||
value: # Optional
|
||||
- name: sentinelMasterName
|
||||
value: # Optional
|
||||
- name: redeliverInterval
|
||||
value: # Optional
|
||||
- name: processingTimeout
|
||||
value: # Optional
|
||||
- name: redisType
|
||||
value: # Optional
|
||||
- name: redisDB
|
||||
value: # Optional
|
||||
- name: redisMaxRetries
|
||||
value: # Optional
|
||||
- name: redisMinRetryInterval
|
||||
value: # Optional
|
||||
- name: redisMaxRetryInterval
|
||||
value: # Optional
|
||||
- name: dialTimeout
|
||||
value: # Optional
|
||||
- name: readTimeout
|
||||
value: # Optional
|
||||
- name: writeTimeout
|
||||
value: # Optional
|
||||
- name: poolSize
|
||||
value: # Optional
|
||||
- name: poolTimeout
|
||||
value: # Optional
|
||||
- name: maxConnAge
|
||||
value: # Optional
|
||||
- name: minIdleConns
|
||||
value: # Optional
|
||||
- name: idleCheckFrequency
|
||||
value: # Optional
|
||||
- name: idleTimeout
|
||||
value: # Optional
|
||||
- name: ttlInSeconds
|
||||
value: <int> # Optional
|
||||
- name: queryIndexes
|
||||
|
|
@ -60,7 +96,6 @@ If you wish to use Redis as an actor store, append the following to the yaml.
|
|||
| redisHost | Y | Connection-string for the redis host | `localhost:6379`, `redis-master.default.svc.cluster.local:6379`
|
||||
| redisPassword | Y | Password for Redis host. No Default. Can be `secretKeyRef` to use a secret reference | `""`, `"KeFg23!"`
|
||||
| redisUsername | N | Username for Redis host. Defaults to empty. Make sure your redis server version is 6 or above, and have created acl rule correctly. | `""`, `"default"`
|
||||
| consumerID | N | The consumer group ID | `"myGroup"`
|
||||
| enableTLS | N | If the Redis instance supports TLS with public certificates, can be configured to be enabled or disabled. Defaults to `"false"` | `"true"`, `"false"`
|
||||
| maxRetries | N | Maximum number of retries before giving up. Defaults to `3` | `5`, `10`
|
||||
| maxRetryBackoff | N | Minimum backoff between each retry. Defaults to `2` seconds; `"-1"` disables backoff. | `3000000000`
|
||||
|
|
@ -68,18 +103,18 @@ If you wish to use Redis as an actor store, append the following to the yaml.
|
|||
| sentinelMasterName | N | The sentinel master name. See [Redis Sentinel Documentation](https://redis.io/docs/manual/sentinel/) | `""`, `"127.0.0.1:6379"`
|
||||
| redeliverInterval | N | The interval between checking for pending messages to redelivery. Defaults to `"60s"`. `"0"` disables redelivery. | `"30s"`
|
||||
| processingTimeout | N | The amount time a message must be pending before attempting to redeliver it. Defaults to `"15s"`. `"0"` disables redelivery. | `"30s"`
|
||||
| redisType | N | The type of redis. There are two valid values, one is `"node"` for single node mode, the other is `"cluster"` for redis cluster mode. Defaults to `"node"`. | `"cluster"`
|
||||
| redisDB | N | Database selected after connecting to redis. If `"redisType"` is `"cluster"` this option is ignored. Defaults to `"0"`. | `"0"`
|
||||
| redisMaxRetries | N | Alias for `maxRetries`. If both values are set `maxRetries` is ignored. | `"5"`
|
||||
| redisType | N | The type of redis. There are two valid values, one is `"node"` for single node mode, the other is `"cluster"` for redis cluster mode. Defaults to `"node"`. | `"cluster"`
|
||||
| redisDB | N | Database selected after connecting to redis. If `"redisType"` is `"cluster"` this option is ignored. Defaults to `"0"`. | `"0"`
|
||||
| redisMaxRetries | N | Alias for `maxRetries`. If both values are set `maxRetries` is ignored. | `"5"`
|
||||
| redisMinRetryInterval | N | Minimum backoff for redis commands between each retry. Default is `"8ms"`; `"-1"` disables backoff. | `"8ms"`
|
||||
| redisMaxRetryInterval | N | Alias for `maxRetryBackoff`. If both values are set `maxRetryBackoff` is ignored. | `"5s"`
|
||||
| dialTimeout | N | Dial timeout for establishing new connections. Defaults to `"5s"`. | `"5s"`
|
||||
| readTimeout | N | Timeout for socket reads. If reached, redis commands will fail with a timeout instead of blocking. Defaults to `"3s"`, `"-1"` for no timeout. | `"3s"`
|
||||
| writeTimeout | N | Timeout for socket writes. If reached, redis commands will fail with a timeout instead of blocking. Defaults is readTimeout. | `"3s"`
|
||||
| poolSize | N | Maximum number of socket connections. Default is 10 connections per every CPU as reported by runtime.NumCPU. | `"20"`
|
||||
| writeTimeout | N | Timeout for socket writes. If reached, redis commands will fail with a timeout instead of blocking. Defaults is readTimeout. | `"3s"`
|
||||
| poolSize | N | Maximum number of socket connections. Default is 10 connections per every CPU as reported by runtime.NumCPU. | `"20"`
|
||||
| poolTimeout | N | Amount of time client waits for a connection if all connections are busy before returning an error. Default is readTimeout + 1 second. | `"5s"`
|
||||
| maxConnAge | N | Connection age at which the client retires (closes) the connection. Default is to not close aged connections. | `"30m"`
|
||||
| minIdleConns | N | Minimum number of idle connections to keep open in order to avoid the performance degradation associated with creating new connections. Defaults to `"0"`. | `"2"`
|
||||
| maxConnAge | N | Connection age at which the client retires (closes) the connection. Default is to not close aged connections. | `"30m"`
|
||||
| minIdleConns | N | Minimum number of idle connections to keep open in order to avoid the performance degradation associated with creating new connections. Defaults to `"0"`. | `"2"`
|
||||
| idleCheckFrequency | N | Frequency of idle checks made by idle connections reaper. Default is `"1m"`. `"-1"` disables idle connections reaper. | `"-1"`
|
||||
| idleTimeout | N | Amount of time after which the client closes idle connections. Should be less than server's timeout. Default is `"5m"`. `"-1"` disables idle timeout check. | `"10m"`
|
||||
| actorStateStore | N | Consider this state store for actors. Defaults to `"false"` | `"true"`, `"false"`
|
||||
|
|
@ -88,17 +123,16 @@ If you wish to use Redis as an actor store, append the following to the yaml.
|
|||
|
||||
## Setup Redis
|
||||
|
||||
Dapr can use any Redis instance - containerized, running on your local dev machine, or a managed cloud service.
|
||||
Dapr can use any Redis instance: containerized, running on your local dev machine, or a managed cloud service.
|
||||
|
||||
{{< tabs "Self-Hosted" "Kubernetes" "Azure" "AWS" "GCP" >}}
|
||||
|
||||
{{% codetab %}}
|
||||
A Redis instance is automatically created as a Docker container when you run `dapr init`
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
We can use [Helm](https://helm.sh/) to quickly create a Redis instance in our Kubernetes cluster. This approach requires [Installing Helm](https://github.com/helm/helm#install).
|
||||
You can use [Helm](https://helm.sh/) to quickly create a Redis instance in our Kubernetes cluster. This approach requires [Installing Helm](https://github.com/helm/helm#install).
|
||||
|
||||
1. Install Redis into your cluster. Note that we're explicitly setting an image tag to get a version greater than 5, which is what Dapr' pub/sub functionality requires. If you're intending on using Redis as just a state store (and not for pub/sub), you do not have to set the image version.
|
||||
```bash
|
||||
|
|
@ -113,8 +147,8 @@ We can use [Helm](https://helm.sh/) to quickly create a Redis instance in our Ku
|
|||
- name: redisHost
|
||||
value: redis-master:6379
|
||||
```
|
||||
4. Next, we'll get the Redis password, which is slightly different depending on the OS we're using:
|
||||
- **Windows**: Run `kubectl get secret --namespace default redis -o jsonpath="{.data.redis-password}" > encoded.b64`, which will create a file with your encoded password. Next, run `certutil -decode encoded.b64 password.txt`, which will put your redis password in a text file called `password.txt`. Copy the password and delete the two files.
|
||||
4. Next, get the Redis password, which is slightly different depending on the OS we're using:
|
||||
- **Windows**: Run `kubectl get secret --namespace default redis -o jsonpath="{.data.redis-password}" > encoded.b64`, which creates a file with your encoded password. Next, run `certutil -decode encoded.b64 password.txt`, which will put your redis password in a text file called `password.txt`. Copy the password and delete the two files.
|
||||
|
||||
- **Linux/MacOS**: Run `kubectl get secret --namespace default redis -o jsonpath="{.data.redis-password}" | base64 --decode` and copy the outputted password.
|
||||
|
||||
|
|
@ -129,13 +163,19 @@ We can use [Helm](https://helm.sh/) to quickly create a Redis instance in our Ku
|
|||
{{% codetab %}}
|
||||
**Note**: this approach requires having an Azure Subscription.
|
||||
|
||||
1. Open [this link](https://ms.portal.azure.com/#create/Microsoft.Cache) to start the Azure Cache for Redis creation flow. Log in if necessary.
|
||||
1. [Start the Azure Cache for Redis creation flow](https://ms.portal.azure.com/#create/Microsoft.Cache). Log in if necessary.
|
||||
2. Fill out necessary information and **check the "Unblock port 6379" box**, which will allow us to persist state without SSL.
|
||||
3. Click "Create" to kickoff deployment of your Redis instance.
|
||||
4. Once your instance is created, you'll need to grab the Host name (FQDN) and your access key.
|
||||
- for the Host name navigate to the resources "Overview" and copy "Host name"
|
||||
- for your access key navigate to "Access Keys" under "Settings" and copy your key.
|
||||
5. Finally, we need to add our key and our host to a `redis.yaml` file that Dapr can apply to our cluster. If you're running a sample, you'll add the host and key to the provided `redis.yaml`. If you're creating a project from the ground up, you'll create a `redis.yaml` file as specified in [Configuration](#configuration). Set the `redisHost` key to `[HOST NAME FROM PREVIOUS STEP]:6379` and the `redisPassword` key to the key you copied in step 4. **Note:** In a production-grade application, follow [secret management]({{< ref component-secrets.md >}}) instructions to securely manage your secrets.
|
||||
4. Once your instance is created, you'll need to grab the Host name (FQDN) and your access key:
|
||||
- For the Host name: navigate to the resource's "Overview" and copy "Host name".
|
||||
- For your access key: navigate to "Settings" > "Access Keys" to copy and save your key.
|
||||
5. Add your key and your host to a `redis.yaml` file that Dapr can apply to your cluster.
|
||||
- If you're running a sample, add the host and key to the provided `redis.yaml`.
|
||||
- If you're creating a project from the ground up, create a `redis.yaml` file as specified in [Configuration](#configuration).
|
||||
|
||||
Set the `redisHost` key to `[HOST NAME FROM PREVIOUS STEP]:6379` and the `redisPassword` key to the key you saved earlier.
|
||||
|
||||
**Note:** In a production-grade application, follow [secret management]({{< ref component-secrets.md >}}) instructions to securely manage your secrets.
|
||||
|
||||
> **NOTE:** Dapr pub/sub uses [Redis Streams](https://redis.io/topics/streams-intro) that was introduced by Redis 5.0, which isn't currently available on Azure Managed Redis Cache. Consequently, you can use Azure Managed Redis Cache only for state persistence.
|
||||
{{% /codetab %}}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,5 @@
|
|||
- component: Redis
|
||||
link: redis-lock
|
||||
state: Alpha
|
||||
version: v1
|
||||
since: "1.8"
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
{{- $groups := dict
|
||||
" Generic" $.Site.Data.components.locks.generic
|
||||
}}
|
||||
|
||||
{{ range $group, $components := $groups }}
|
||||
<h3>{{ $group }}</h3>
|
||||
<table width="100%">
|
||||
<tr>
|
||||
<th>Component</th>
|
||||
<th>Status</th>
|
||||
<th>Component version</th>
|
||||
<th>Since runtime version</th>
|
||||
</tr>
|
||||
{{ range sort $components "component" }}
|
||||
<tr>
|
||||
<td><a href="/reference/components-reference/supported-locks/{{ .link }}/" }}>{{ .component
|
||||
}}</a>
|
||||
</td>
|
||||
<td>{{ .state }}</td>
|
||||
<td>{{ .version }}</td>
|
||||
<td>{{ .since }}</td>
|
||||
</tr>
|
||||
{{ end }}
|
||||
</table>
|
||||
{{ end }}
|
||||
|
||||
{{ partial "components/componenttoc.html" . }}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 177 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 194 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 157 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 128 KiB After Width: | Height: | Size: 378 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 47 KiB After Width: | Height: | Size: 124 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 426 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 206 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 535 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 110 KiB After Width: | Height: | Size: 258 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 382 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 381 KiB After Width: | Height: | Size: 549 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 133 KiB After Width: | Height: | Size: 362 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 331 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.2 MiB |
|
|
@ -1,6 +1,11 @@
|
|||
{
|
||||
"globalHeaders": {
|
||||
"X-Frame-Options": "DENY"
|
||||
"X-Frame-Options": "DENY"
|
||||
},
|
||||
"responseOverrides": {
|
||||
"404": {
|
||||
"rewrite": "/404.html",
|
||||
"statusCode": 404
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue