mirror of https://github.com/dapr/docs.git
Merge pull request #4069 from hhunter-ms/upmerge_03-05
Upmerge Mar 5: 1.13 --> 1.14
This commit is contained in:
Hannah Hunter
GitHub
commit
91e93320e1
|
|
@ -1,3 +1,3 @@
|
|||
# Contributing to Dapr docs
|
||||
|
||||
Please see [this docs section](https://docs.dapr.io/contributing/) for general guidance on contributions to the Dapr project as well as specific guidelines on contributions to the docs repo.
|
||||
Please see [this docs section](https://docs.dapr.io/contributing/) for general guidance on contributions to the Dapr project as well as specific guidelines on contributions to the docs repo. Learn more about [Dapr bot commands and labels](https://docs.dapr.io/contributing/daprbot/) to improve your docs contributing experience.
|
||||
|
|
@ -14,8 +14,8 @@ The following branches are currently maintained:
|
|||
|
||||
| Branch | Website | Description |
|
||||
| ------------------------------------------------------------ | -------------------------- | ------------------------------------------------------------------------------------------------ |
|
||||
| [v1.12](https://github.com/dapr/docs) (primary) | https://docs.dapr.io | Latest Dapr release documentation. Typo fixes, clarifications, and most documentation goes here. |
|
||||
| [v1.13](https://github.com/dapr/docs/tree/v1.13) (pre-release) | https://v1-13.docs.dapr.io/ | Pre-release documentation. Doc updates that are only applicable to v1.13+ go here. |
|
||||
| [v1.13](https://github.com/dapr/docs) (primary) | https://docs.dapr.io | Latest Dapr release documentation. Typo fixes, clarifications, and most documentation goes here. |
|
||||
| [v1.14](https://github.com/dapr/docs/tree/v1.14) (pre-release) | https://v1-14.docs.dapr.io/ | Pre-release documentation. Doc updates that are only applicable to v1.14+ go here. |
|
||||
|
||||
For more information visit the [Dapr branch structure](https://docs.dapr.io/contributing/docs-contrib/contributing-docs/#branch-guidance) document.
|
||||
|
||||
|
|
|
|||
|
|
@ -196,7 +196,7 @@ url_latest_version = "https://docs.dapr.io"
|
|||
url = "https://docs.dapr.io"
|
||||
[[params.versions]]
|
||||
version = "v1.12"
|
||||
url = "https://docs.dapr.io"
|
||||
url = "https://v1-12.docs.dapr.io"
|
||||
[[params.versions]]
|
||||
version = "v1.11"
|
||||
url = "https://v1-11.docs.dapr.io"
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Dapr bot is triggered by a list of commands that helps with common tasks in the
|
|||
|
||||
| Command | Target | Description | Who can use | Repository |
|
||||
| ---------------- | --------------------- | -------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | -------------------------------------- |
|
||||
| `/assign` | Issue | Assigns an issue to a user or group of users | Anyone | `dapr`, `components-contrib`, `go-sdk` |
|
||||
| `/assign` | Issue | Assigns an issue to a user or group of users | Anyone | `dapr`, `docs`, `quickstarts`, `cli`, `components-contrib`, `go-sdk`, `js-sdk`, `java-sdk`, `python-sdk`, `dotnet-sdk` |
|
||||
| `/ok-to-test` | Pull request | `dapr`: trigger end to end tests <br/> `components-contrib`: trigger conformance and certification tests | Users listed in the [bot](https://github.com/dapr/dapr/blob/master/.github/scripts/dapr_bot.js) | `dapr`, `components-contrib` |
|
||||
| `/ok-to-perf` | Pull request | Trigger performance tests. | Users listed in the [bot](https://github.com/dapr/dapr/blob/master/.github/scripts/dapr_bot.js) | `dapr` |
|
||||
| `/make-me-laugh` | Issue or pull request | Posts a random joke | Users listed in the [bot](https://github.com/dapr/dapr/blob/master/.github/scripts/dapr_bot.js) | `dapr`, `components-contrib` |
|
||||
|
|
|
|||
|
|
@ -14,7 +14,9 @@ Now that you've learned about the [actor building block]({{< ref "actors-overvie
|
|||
|
||||
Dapr actors are virtual, meaning that their lifetime is not tied to their in-memory representation. As a result, they do not need to be explicitly created or destroyed. The Dapr actor runtime automatically activates an actor the first time it receives a request for that actor ID. If an actor is not used for a period of time, the Dapr actor runtime garbage-collects the in-memory object. It will also maintain knowledge of the actor's existence should it need to be reactivated later.
|
||||
|
||||
Invocation of actor methods and reminders reset the idle time, e.g. reminder firing will keep the actor active. Actor reminders fire whether an actor is active or inactive, if fired for inactive actor, it will activate the actor first. Actor timers do not reset the idle time, so timer firing will not keep the actor active. Timers only fire while the actor is active.
|
||||
Invocation of actor methods, timers, and reminders reset the actor idle time. For example, a reminder firing keeps the actor active.
|
||||
- Actor reminders fire whether an actor is active or inactive. If fired for an inactive actor, it activates the actor first.
|
||||
- Actor timers firing reset the idle time; however, timers only fire while the actor is active.
|
||||
|
||||
The idle timeout and scan interval Dapr runtime uses to see if an actor can be garbage-collected is configurable. This information can be passed when Dapr runtime calls into the actor service to get supported actor types.
|
||||
|
||||
|
|
|
|||
|
|
@ -146,6 +146,36 @@ If an invocation of the method fails, the timer is not removed. Timers are only
|
|||
- The executions run out
|
||||
- You delete it explicitly
|
||||
|
||||
## Reminder data serialization format
|
||||
|
||||
Actor reminder data is serialized to JSON by default. Dapr v1.13 onwards supports a protobuf serialization format for reminders data which, depending on throughput and size of the payload, can result in significant performance improvements, giving developers a higher throughput and lower latency. Another benefit is storing smaller data in the actor underlying database, which can result in cost optimizations when using some cloud databases. A restriction with using protobuf serialization is that the reminder data can no longer be queried.
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
Protobuf serialization will become the default format in Dapr 1.14
|
||||
{{% /alert %}}
|
||||
|
||||
Reminder data saved in protobuf format cannot be read in Dapr 1.12.x and earlier versions. Its recommended to test this feature in Dapr v1.13 and verify that it works as expected with your database before taking this into production.
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
If you use protobuf serialization in Dapr v1.13 and need to downgrade to an earlier Dapr version, the reminder data will be incompatible with versions 1.12.x and earlier versions. **Once you save your reminders data in protobuf format, you cannot move it back to JSON format**.
|
||||
{{% /alert %}}
|
||||
|
||||
### Enabling protobuf serialization on Kubernetes
|
||||
|
||||
To use protobuf serialization for actor reminders on Kubernetes, use the following Helm value:
|
||||
|
||||
```
|
||||
--set dapr_placement.maxActorApiLevel=20
|
||||
```
|
||||
|
||||
### Enabling protobuf serialization on self-hosted
|
||||
|
||||
To use protobuf serialization for actor reminders on self-hosted, use the following `daprd` flag:
|
||||
|
||||
```
|
||||
--max-api-level=20
|
||||
```
|
||||
|
||||
## Next steps
|
||||
|
||||
{{< button text="Configure actor runtime behavior >>" page="actors-runtime-config.md" >}}
|
||||
|
|
@ -153,4 +183,4 @@ If an invocation of the method fails, the timer is not removed. Timers are only
|
|||
## Related links
|
||||
|
||||
- [Actors API reference]({{< ref actors_api.md >}})
|
||||
- [Actors overview]({{< ref actors-overview.md >}})
|
||||
- [Actors overview]({{< ref actors-overview.md >}})
|
||||
|
|
|
|||
|
|
@ -6,16 +6,16 @@ weight: 2000
|
|||
description: "Learn how to encrypt and decrypt files"
|
||||
---
|
||||
|
||||
Now that you've read about [Cryptography as a Dapr building block]({{< ref cryptography-overview.md >}}), let's walk through using the cryptography APIs with the SDKs.
|
||||
Now that you've read about [Cryptography as a Dapr building block]({{< ref cryptography-overview.md >}}), let's walk through using the cryptography APIs with the SDKs.
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
Dapr cryptography is currently in alpha.
|
||||
Dapr cryptography is currently in alpha.
|
||||
|
||||
{{% /alert %}}
|
||||
|
||||
## Encrypt
|
||||
|
||||
{{< tabs "JavaScript" "Go" >}}
|
||||
{{< tabs "JavaScript" "Go" ".NET" >}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
|
|
@ -136,12 +136,32 @@ if err != nil {
|
|||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
<!-- .NET -->
|
||||
Using the Dapr SDK in your project, with the gRPC APIs, you can encrypt data in a string or a byte array:
|
||||
|
||||
```csharp
|
||||
using var client = new DaprClientBuilder().Build();
|
||||
|
||||
const string componentName = "azurekeyvault"; //Change this to match your cryptography component
|
||||
const string keyName = "myKey"; //Change this to match the name of the key in your cryptographic store
|
||||
|
||||
const string plainText = "This is the value we're going to encrypt today";
|
||||
|
||||
//Encode the string to a UTF-8 byte array and encrypt it
|
||||
var plainTextBytes = Encoding.UTF8.GetBytes(plainText);
|
||||
var encryptedBytesResult = await client.EncryptAsync(componentName, plaintextBytes, keyName, new EncryptionOptions(KeyWrapAlgorithm.Rsa));
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
## Decrypt
|
||||
|
||||
{{< tabs "JavaScript" "Go" >}}
|
||||
{{< tabs "JavaScript" "Go" ".NET" >}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
|
|
@ -186,6 +206,29 @@ out, err := sdkClient.Decrypt(context.Background(), rf, dapr.EncryptOptions{
|
|||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
<!-- .NET -->
|
||||
To decrypt a string, use the 'DecryptAsync' gRPC API in your project.
|
||||
|
||||
In the following example, we'll take a byte array (such as from the example above) and decrypt it to a UTF-8 encoded string.
|
||||
|
||||
```csharp
|
||||
public async Task<string> DecryptBytesAsync(byte[] encryptedBytes)
|
||||
{
|
||||
using var client = new DaprClientBuilder().Build();
|
||||
|
||||
const string componentName = "azurekeyvault"; //Change this to match your cryptography component
|
||||
const string keyName = "myKey"; //Change this to match the name of the key in your cryptographic store
|
||||
|
||||
var decryptedBytes = await client.DecryptAsync(componentName, encryptedBytes, keyName);
|
||||
var decryptedString = Encoding.UTF8.GetString(decryptedBytes.ToArray());
|
||||
return decryptedString;
|
||||
}
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
## Next steps
|
||||
|
|
|
|||
|
|
@ -146,6 +146,8 @@ Different state store implementations may implicitly put restrictions on the typ
|
|||
|
||||
Similarly, if a state store imposes restrictions on the size of a batch transaction, that may limit the number of parallel actions that can be scheduled by a workflow.
|
||||
|
||||
Workflow state can be purged from a state store, including all its history. Each Dapr SDK exposes APIs for purging all metadata related to specific workflow instances.
|
||||
|
||||
## Workflow scalability
|
||||
|
||||
Because Dapr Workflows are internally implemented using actors, Dapr Workflows have the same scalability characteristics as actors. The placement service:
|
||||
|
|
|
|||
|
|
@ -63,6 +63,8 @@ You can use the following two techniques to write workflows that may need to sch
|
|||
|
||||
1. **Use the _continue-as-new_ API**:
|
||||
Each workflow SDK exposes a _continue-as-new_ API that workflows can invoke to restart themselves with a new input and history. The _continue-as-new_ API is especially ideal for implementing "eternal workflows", like monitoring agents, which would otherwise be implemented using a `while (true)`-like construct. Using _continue-as-new_ is a great way to keep the workflow history size small.
|
||||
|
||||
> The _continue-as-new_ API truncates the existing history, replacing it with a new history.
|
||||
|
||||
1. **Use child workflows**:
|
||||
Each workflow SDK exposes an API for creating child workflows. A child workflow behaves like any other workflow, except that it's scheduled by a parent workflow. Child workflows have:
|
||||
|
|
@ -159,6 +161,12 @@ The backend implementation is largely decoupled from the workflow core engine or
|
|||
|
||||
In that sense, it's similar to Dapr's state store abstraction, except designed specifically for workflow. All APIs and programming model features are the same, regardless of which backend is used.
|
||||
|
||||
## Purging
|
||||
|
||||
Workflow state can be purged from a state store, purging all its history and removing all metadata related to a specific workflow instance. The purge capability is used for workflows that have run to a `COMPLETED`, `FAILED`, or `TERMINATED` state.
|
||||
|
||||
Learn more in [the workflow API reference guide]({{< ref workflow_api.md >}}).
|
||||
|
||||
## Limitations
|
||||
|
||||
### Workflow determinism and code restraints
|
||||
|
|
@ -211,7 +219,7 @@ const randomString = getRandomString();
|
|||
|
||||
```go
|
||||
// DON'T DO THIS!
|
||||
|
||||
const currentTime = time.Now()
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
|
@ -254,13 +262,12 @@ const randomString = yield context.callActivity(getRandomString);
|
|||
|
||||
{{% /codetab %}}
|
||||
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```go
|
||||
// Do this!!
|
||||
|
||||
const currentTime = ctx.CurrentUTCDateTime()
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
|
@ -319,10 +326,12 @@ fetch('https://postman-echo.com/get')
|
|||
|
||||
```go
|
||||
// DON'T DO THIS!
|
||||
resp, err := http.Get("http://example.com/api/data")
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
Do this:
|
||||
|
|
@ -364,6 +373,8 @@ const data = yield ctx.callActivity(makeHttpCall, "https://example.com/api/data"
|
|||
|
||||
```go
|
||||
// Do this!!
|
||||
err := ctx.CallActivity(MakeHttpCallActivity, workflow.ActivityInput("https://example.com/api/data")).Await(&output)
|
||||
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
|
@ -412,9 +423,16 @@ Don't declare JavaScript workflow as `async`. The Node.js runtime doesn't guaran
|
|||
|
||||
```go
|
||||
// DON'T DO THIS!
|
||||
go func() {
|
||||
err := ctx.CallActivity(DoSomething).Await(nil)
|
||||
}()
|
||||
err := ctx.CreateTimer(time.Second).Await(nil)
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
Do this:
|
||||
|
|
@ -450,7 +468,9 @@ Since the Node.js runtime doesn't guarantee that asynchronous functions are dete
|
|||
{{% codetab %}}
|
||||
|
||||
```go
|
||||
// Do this!!
|
||||
// Do this!
|
||||
task := ctx.CallActivity(DoSomething)
|
||||
task.Await(nil)
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
|
@ -489,4 +509,4 @@ To work around these constraints:
|
|||
- [JavaScript](https://github.com/dapr/js-sdk/tree/main/examples/workflow)
|
||||
- [.NET](https://github.com/dapr/dotnet-sdk/tree/master/examples/Workflow)
|
||||
- [Java](https://github.com/dapr/java-sdk/tree/master/examples/src/main/java/io/dapr/examples/workflows)
|
||||
- [Go](https://github.com/dapr/go-sdk/tree/main/examples/workflow/README.md)
|
||||
- [Go](https://github.com/dapr/go-sdk/tree/main/examples/workflow/README.md)
|
||||
|
|
|
|||
|
|
@ -823,9 +823,8 @@ public class MonitorWorkflow extends Workflow {
|
|||
}
|
||||
|
||||
// Put the workflow to sleep until the determined time
|
||||
// Note: ctx.createTimer() method is not supported in the Java SDK yet
|
||||
try {
|
||||
TimeUnit.SECONDS.sleep(nextSleepInterval.getSeconds());
|
||||
ctx.createTimer(nextSleepInterval);
|
||||
} catch (InterruptedException e) {
|
||||
throw new RuntimeException(e);
|
||||
}
|
||||
|
|
|
|||
|
|
@ -3,10 +3,11 @@ type: docs
|
|||
title: "Use the Dapr API"
|
||||
linkTitle: "Use the Dapr API"
|
||||
weight: 30
|
||||
description: "Run a Dapr sidecar and try out the state API"
|
||||
description: "Run a Dapr sidecar and try out the state management API"
|
||||
---
|
||||
|
||||
In this guide, you'll simulate an application by running the sidecar and calling the API directly. After running Dapr using the Dapr CLI, you'll:
|
||||
In this guide, you'll simulate an application by running the sidecar and calling the state management API directly.
|
||||
After running Dapr using the Dapr CLI, you'll:
|
||||
|
||||
- Save a state object.
|
||||
- Read/get the state object.
|
||||
|
|
@ -21,7 +22,8 @@ In this guide, you'll simulate an application by running the sidecar and calling
|
|||
|
||||
### Step 1: Run the Dapr sidecar
|
||||
|
||||
The [`dapr run`]({{< ref dapr-run.md >}}) command launches an application, together with a sidecar.
|
||||
The [`dapr run`]({{< ref dapr-run.md >}}) command normally runs your application and a Dapr sidecar. In this case,
|
||||
it only runs the sidecar since you are interacting with the state management API directly.
|
||||
|
||||
Launch a Dapr sidecar that will listen on port 3500 for a blank application named `myapp`:
|
||||
|
||||
|
|
|
|||
|
|
@ -15,6 +15,11 @@ You'll use the Dapr CLI as the main tool for various Dapr-related tasks. You can
|
|||
|
||||
The Dapr CLI works with both [self-hosted]({{< ref self-hosted >}}) and [Kubernetes]({{< ref Kubernetes >}}) environments.
|
||||
|
||||
{{% alert title="Before you begin" color="primary" %}}
|
||||
In Docker Desktop's advanced options, verify you've allowed the default Docker socket to be used.
|
||||
<img src="/images/docker-desktop-setting.png" width=800 style="padding-bottom:15px;">
|
||||
{{% /alert %}}
|
||||
|
||||
### Step 1: Install the Dapr CLI
|
||||
|
||||
{{< tabs Linux Windows MacOS Binaries>}}
|
||||
|
|
|
|||
|
|
@ -22,8 +22,12 @@ Dapr initialization includes:
|
|||
1. Creating a **default components folder** with component definitions for the above.
|
||||
1. Running a **Dapr placement service container instance** for local actor support.
|
||||
|
||||
{{% alert title="Kubernetes Development Environment" color="primary" %}}
|
||||
To initialize Dapr in your local or remote **Kubernetes** cluster for development (including the Redis and Zipkin containers listed above), see [how to initialize Dapr for development on Kubernetes]({{<ref "kubernetes-deploy.md#install-dapr-from-the-official-dapr-helm-chart-with-development-flag">}})
|
||||
{{% /alert %}}
|
||||
|
||||
{{% alert title="Docker" color="primary" %}}
|
||||
The recommended development environment requires [Docker](https://docs.docker.com/install/). While you can [initialize Dapr without a dependency on Docker]({{< ref self-hosted-no-docker.md >}})), the next steps in this guide assume the recommended Docker development environment.
|
||||
The recommended development environment requires [Docker](https://docs.docker.com/install/). While you can [initialize Dapr without a dependency on Docker]({{< ref self-hosted-no-docker.md >}}), the next steps in this guide assume the recommended Docker development environment.
|
||||
|
||||
You can also install [Podman](https://podman.io/) in place of Docker. Read more about [initializing Dapr using Podman]({{< ref dapr-init.md >}}).
|
||||
{{% /alert %}}
|
||||
|
|
@ -66,7 +70,7 @@ dapr init
|
|||
|
||||
**If you are installing on Mac OS Silicon with Docker,** you may need to perform the following workaround to enable `dapr init` to talk to Docker without using Kubernetes.
|
||||
1. Navigate to **Docker Desktop** > **Settings** > **Advanced**.
|
||||
1. Select the **Enable default Docker socket** checkbox.
|
||||
1. Select the **Allow the default Docker socket to be used (requires password)** checkbox.
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
|
|
@ -82,6 +86,7 @@ dapr init
|
|||
|
||||
{{< /tabs >}}
|
||||
|
||||
[See the troubleshooting guide if you encounter any error messages regarding Docker not being installed or running.]({{< ref "common_issues.md#dapr-cant-connect-to-docker-when-installing-the-dapr-cli" >}})
|
||||
|
||||
### Step 3: Verify Dapr version
|
||||
|
||||
|
|
@ -135,9 +140,14 @@ ls $HOME/.dapr
|
|||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
You can verify using either PowerShell or command line. If using PowerShell, run:
|
||||
```powershell
|
||||
explorer "%USERPROFILE%\.dapr\"
|
||||
explorer "$env:USERPROFILE\.dapr"
|
||||
```
|
||||
|
||||
If using command line, run:
|
||||
```cmd
|
||||
explorer "%USERPROFILE%\.dapr"
|
||||
```
|
||||
|
||||
**Result:**
|
||||
|
|
|
|||
|
|
@ -72,6 +72,51 @@ The `-k` flag initializes Dapr on the Kubernetes cluster in your current context
|
|||
dapr dashboard -k -n <your-namespace>
|
||||
```
|
||||
|
||||
|
||||
#### Install Dapr from the offical Dapr Helm chart (with development flag)
|
||||
|
||||
Adding the `--dev` flag initializes Dapr on the Kubernetes cluster on your current context, with the addition of Redis and Zipkin deployments.
|
||||
|
||||
The steps are similar to [installing from the Dapr Helm chart](#install-dapr-from-an-official-dapr-helm-chart), except for appending the `--dev` flag to the `init` command:
|
||||
|
||||
```bash
|
||||
dapr init -k --dev
|
||||
```
|
||||
|
||||
Expected output:
|
||||
|
||||
```bash
|
||||
⌛ Making the jump to hyperspace...
|
||||
ℹ️ Note: To install Dapr using Helm, see here: https://docs.dapr.io/getting-started/install-dapr-kubernetes/#install-with-helm-advanced
|
||||
|
||||
ℹ️ Container images will be pulled from Docker Hub
|
||||
✅ Deploying the Dapr control plane with latest version to your cluster...
|
||||
✅ Deploying the Dapr dashboard with latest version to your cluster...
|
||||
✅ Deploying the Dapr Redis with latest version to your cluster...
|
||||
✅ Deploying the Dapr Zipkin with latest version to your cluster...
|
||||
ℹ️ Applying "statestore" component to Kubernetes "default" namespace.
|
||||
ℹ️ Applying "pubsub" component to Kubernetes "default" namespace.
|
||||
ℹ️ Applying "appconfig" zipkin configuration to Kubernetes "default" namespace.
|
||||
✅ Success! Dapr has been installed to namespace dapr-system. To verify, run `dapr status -k' in your terminal. To get started, go here: https://aka.ms/dapr-getting-started
|
||||
```
|
||||
|
||||
After a short period of time (or using the `--wait` flag and specifying an amount of time to wait), you can check that the Redis and Zipkin components have been deployed to the cluster.
|
||||
|
||||
```bash
|
||||
kubectl get pods --namespace default
|
||||
```
|
||||
|
||||
Expected output:
|
||||
|
||||
```bash
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
dapr-dev-zipkin-bfb4b45bb-sttz7 1/1 Running 0 159m
|
||||
dapr-dev-redis-master-0 1/1 Running 0 159m
|
||||
dapr-dev-redis-replicas-0 1/1 Running 0 159m
|
||||
dapr-dev-redis-replicas-1 1/1 Running 0 159m
|
||||
dapr-dev-redis-replicas-2 1/1 Running 0 158m
|
||||
```
|
||||
|
||||
#### Install Dapr from a private Dapr Helm chart
|
||||
|
||||
Installing [Dapr from a private Helm chart](#install-dapr-from-an-official-dapr-helm-chart) can be helpful for when you:
|
||||
|
|
|
|||
|
|
@ -94,7 +94,8 @@ metadata:
|
|||
spec:
|
||||
metrics:
|
||||
enabled: true
|
||||
increasedCardinality: true
|
||||
http:
|
||||
increasedCardinality: true
|
||||
rules:
|
||||
- name: dapr_runtime_service_invocation_req_sent_total
|
||||
labels:
|
||||
|
|
|
|||
|
|
@ -8,18 +8,50 @@ description: Dapr sidecar health checks
|
|||
|
||||
Dapr provides a way to determine its health using an [HTTP `/healthz` endpoint]({{< ref health_api.md >}}). With this endpoint, the *daprd* process, or sidecar, can be:
|
||||
|
||||
- Probed for its health
|
||||
- Determined for readiness and liveness
|
||||
- Probed for its overall health
|
||||
- Probed for Dapr sidecar readiness during initialization
|
||||
- Determined for readiness and liveness with Kubernetes
|
||||
|
||||
In this guide, you learn how the Dapr `/healthz` endpoint integrate with health probes from the application hosting platform (for example, Kubernetes).
|
||||
|
||||
When deploying Dapr to a hosting platform like Kubernetes, the Dapr health endpoint is automatically configured for you.
|
||||
In this guide, you learn how the Dapr `/healthz` endpoint integrates with health probes from the application hosting platform (for example, Kubernetes) as well as the Dapr SDKs.
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
Dapr actors also have a health API endpoint where Dapr probes the application for a response to a signal from Dapr that the actor application is healthy and running. See [actor health API]({{< ref "actors_api.md#health-check" >}}).
|
||||
{{% /alert %}}
|
||||
|
||||
The following diagram shows the steps when a Dapr sidecar starts, the healthz endpoint and when the app channel is initialized.
|
||||
|
||||
<img src="/images/healthz-outbound.png" width="800" alt="Diagram of Dapr checking oubound health connections." />
|
||||
|
||||
## Outbound health endpoint
|
||||
|
||||
As shown by the red boundary lines in the diagram above, the `v1.0/healthz/` endpoint is used to wait for when:
|
||||
- All components are initialized;
|
||||
- The Dapr HTTP port is available; _and,_
|
||||
- The app channel is initialized.
|
||||
|
||||
This is used to check the complete initialization of the Dapr sidecar and its health.
|
||||
|
||||
Setting the `DAPR_HEALTH_TIMEOUT` environment variable lets you control the health timeout, which, for example, can be important in different environments with higher latency.
|
||||
|
||||
On the other hand, as shown by the green boundary lines in the diagram above, the `v1.0/healthz/outbound` endpoint returns successfully when:
|
||||
- All the components are initialized;
|
||||
- The Dapr HTTP port is available; _but,_
|
||||
- The app channel is not yet established.
|
||||
|
||||
In the Dapr SDKs, the `waitForSidecar`/`wait_until_ready` method (depending on [which SDK you use]({{< ref "#sdks-supporting-outbound-health-endpoint" >}})) is used for this specific check with the `v1.0/healthz/outbound` endpoint. Using this behavior, instead of waiting for the app channel to be available (see: red boundary lines) with the `v1.0/healthz/` endpoint, Dapr waits for a successful response from `v1.0/healthz/outbound`. This approach enables your application to perform calls on the Dapr sidecar APIs before the app channel is initalized - for example, reading secrets with the secrets API.
|
||||
|
||||
If you are using the `waitForSidecar`/`wait_until_ready` method on the SDKs, then the correct initialization is performed. Otherwise, you can call the `v1.0/healthz/outbound` endpoint during initalization, and if successesful, you can call the Dapr sidecar APIs.
|
||||
|
||||
### SDKs supporting outbound health endpoint
|
||||
Currently, the `v1.0/healthz/outbound` endpoint is supported in the:
|
||||
- [.NET SDK]({{< ref "dotnet-client.md#wait-for-sidecar" >}})
|
||||
- [Java SDK]({{< ref "java-client.md#wait-for-sidecar" >}})
|
||||
- [Python SDK]({{< ref "python-client.md#health-timeout" >}})
|
||||
- [JavaScript SDK](https://github.com/dapr/js-sdk/blob/4189a3d2ad6897406abd766f4ccbf2300c8f8852/src/interfaces/Client/IClientHealth.ts#L14)
|
||||
|
||||
|
||||
## Health endpoint: Integration with Kubernetes
|
||||
When deploying Dapr to a hosting platform like Kubernetes, the Dapr health endpoint is automatically configured for you.
|
||||
|
||||
Kubernetes uses *readiness* and *liveness* probes to determines the health of the container.
|
||||
|
||||
|
|
|
|||
|
|
@ -88,7 +88,11 @@ kubectl rollout restart deployment/<deployment-name> --namespace <namespace-name
|
|||
|
||||
## Adding API token to client API invocations
|
||||
|
||||
Once token authentication is configured in Dapr, all clients invoking Dapr API will have to append the API token token to every request:
|
||||
Once token authentication is configured in Dapr, all clients invoking Dapr API need to append the `dapr-api-token` token to every request.
|
||||
|
||||
> **Note:** The Dapr SDKs read the [DAPR_API_TOKEN]({{< ref environment >}}) environment variable and set it for you by default.
|
||||
|
||||
<img src="/images/tokens-auth.png" width=800 style="padding-bottom:15px;">
|
||||
|
||||
### HTTP
|
||||
|
||||
|
|
|
|||
|
|
@ -89,11 +89,13 @@ kubectl rollout restart deployment/<deployment-name> --namespace <namespace-name
|
|||
|
||||
## Authenticating requests from Dapr
|
||||
|
||||
Once app token authentication is configured in Dapr, all requests *coming from Dapr* include the token.
|
||||
Once app token authentication is configured using the environment variable or Kubernetes secret `app-api-token`, the Dapr sidecar always includes the HTTP header/gRPC metadata `dapr-api-token: <token>` in the calls to the app. From the app side, ensure you are authenticating using the `dapr-api-token` value which uses the `app-api-token` you set to authenticate requests from Dapr.
|
||||
|
||||
<img src="/images/tokens-auth.png" width=800 style="padding-bottom:15px;">
|
||||
|
||||
### HTTP
|
||||
|
||||
In case of HTTP, in your code look for the HTTP header `dapr-api-token` in incoming requests:
|
||||
In your code, look for the HTTP header `dapr-api-token` in incoming requests:
|
||||
|
||||
```text
|
||||
dapr-api-token: <token>
|
||||
|
|
|
|||
|
|
@ -45,6 +45,7 @@ The table below shows the versions of Dapr releases that have been tested togeth
|
|||
|
||||
| Release date | Runtime | CLI | SDKs | Dashboard | Status | Release notes |
|
||||
|--------------------|:--------:|:--------|---------|---------|---------|------------|
|
||||
| March 6th 2024 | 1.13.0</br> | 1.13.0 | Java 1.11.0 </br>Go 1.10.0 </br>PHP 1.2.0 </br>Python 1.13.0 </br>.NET 1.13.0 </br>JS 3.3.0 | 0.14.0 | Supported (current) | [v1.13.0 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.0) |
|
||||
| January 17th 2024 | 1.12.4</br> | 1.12.0 | Java 1.10.0 </br>Go 1.9.1 </br>PHP 1.2.0 </br>Python 1.12.0 </br>.NET 1.12.0 </br>JS 3.2.0 | 0.14.0 | Supported (current) | [v1.12.4 release notes](https://github.com/dapr/dapr/releases/tag/v1.12.4) |
|
||||
| January 2nd 2024 | 1.12.3</br> | 1.12.0 | Java 1.10.0 </br>Go 1.9.1 </br>PHP 1.2.0 </br>Python 1.12.0 </br>.NET 1.12.0 </br>JS 3.2.0 | 0.14.0 | Supported (current) | [v1.12.3 release notes](https://github.com/dapr/dapr/releases/tag/v1.12.3) |
|
||||
| November 18th 2023 | 1.12.2</br> | 1.12.0 | Java 1.10.0 </br>Go 1.9.1 </br>PHP 1.2.0 </br>Python 1.12.0 </br>.NET 1.12.0 </br>JS 3.2.0 | 0.14.0 | Supported (current) | [v1.12.2 release notes](https://github.com/dapr/dapr/releases/tag/v1.12.2) |
|
||||
|
|
@ -57,17 +58,17 @@ The table below shows the versions of Dapr releases that have been tested togeth
|
|||
| July 20th 2023 | 1.11.2</br> | 1.11.0 | Java 1.9.0 </br>Go 1.8.0 </br>PHP 1.1.0 </br>Python 1.10.0 </br>.NET 1.11.0 </br>JS 3.1.0 | 0.13.0 | Supported | [v1.11.2 release notes](https://github.com/dapr/dapr/releases/tag/v1.11.2) |
|
||||
| June 22nd 2023 | 1.11.1</br> | 1.11.0 | Java 1.9.0 </br>Go 1.8.0 </br>PHP 1.1.0 </br>Python 1.10.0 </br>.NET 1.11.0 </br>JS 3.1.0 | 0.13.0 | Supported | [v1.11.1 release notes](https://github.com/dapr/dapr/releases/tag/v1.11.1) |
|
||||
| June 12th 2023 | 1.11.0</br> | 1.11.0 | Java 1.9.0 </br>Go 1.8.0 </br>PHP 1.1.0 </br>Python 1.10.0 </br>.NET 1.11.0 </br>JS 3.1.0 | 0.13.0 | Supported | [v1.11.0 release notes](https://github.com/dapr/dapr/releases/tag/v1.11.0) |
|
||||
| November 18th 2023 | 1.10.10</br> | 1.10.0 | Java 1.8.0 </br>Go 1.7.0 </br>PHP 1.1.0 </br>Python 1.9.0 </br>.NET 1.10.0 </br>JS 3.0.0 | 0.11.0 | Supported | [v1.10.10 release notes](https://github.com/dapr/dapr/releases/tag/v1.10.10) |
|
||||
| July 20th 2023 | 1.10.9</br> | 1.10.0 | Java 1.8.0 </br>Go 1.7.0 </br>PHP 1.1.0 </br>Python 1.9.0 </br>.NET 1.10.0 </br>JS 3.0.0 | 0.11.0 | Supported | [v1.10.9 release notes](https://github.com/dapr/dapr/releases/tag/v1.10.9) |
|
||||
| June 22nd 2023 | 1.10.8</br> | 1.10.0 | Java 1.8.0 </br>Go 1.7.0 </br>PHP 1.1.0 </br>Python 1.9.0 </br>.NET 1.10.0 </br>JS 3.0.0 | 0.11.0 | Supported | [v1.10.8 release notes](https://github.com/dapr/dapr/releases/tag/v1.10.8) |
|
||||
| May 15th 2023 | 1.10.7</br> | 1.10.0 | Java 1.8.0 </br>Go 1.7.0 </br>PHP 1.1.0 </br>Python 1.9.0 </br>.NET 1.10.0 </br>JS 3.0.0 | 0.11.0 | Supported | |
|
||||
| May 12th 2023 | 1.10.6</br> | 1.10.0 | Java 1.8.0 </br>Go 1.7.0 </br>PHP 1.1.0 </br>Python 1.9.0 </br>.NET 1.10.0 </br>JS 3.0.0 | 0.11.0 | Supported | |
|
||||
| April 13 2023 |1.10.5</br> | 1.10.0 | Java 1.8.0 </br>Go 1.6.0 </br>PHP 1.1.0 </br>Python 1.9.0 </br>.NET 1.10.0 </br>JS 3.0.0 | 0.11.0 | Supported | |
|
||||
| March 16 2023 | 1.10.4</br> | 1.10.0 | Java 1.8.0 </br>Go 1.6.0 </br>PHP 1.1.0 </br>Python 1.9.0 </br>.NET 1.10.0 </br>JS 2.5.0 | 0.11.0 | Supported | |
|
||||
| March 14 2023 | 1.10.3</br> | 1.10.0 | Java 1.8.0 </br>Go 1.6.0 </br>PHP 1.1.0 </br>Python 1.9.0 </br>.NET 1.10.0 </br>JS 2.5.0 | 0.11.0 | Supported | |
|
||||
| February 24 2023 | 1.10.2</br> | 1.10.0 | Java 1.8.0 </br>Go 1.6.0 </br>PHP 1.1.0 </br>Python 1.9.0 </br>.NET 1.10.0 </br>JS 2.5.0 | 0.11.0 | Supported | |
|
||||
| February 20 2023 | 1.10.1</br> | 1.10.0 | Java 1.8.0 </br>Go 1.6.0 </br>PHP 1.1.0 </br>Python 1.9.0 </br>.NET 1.10.0 </br>JS 2.5.0 | 0.11.0 | Supported | |
|
||||
| February 14 2023 | 1.10.0</br> | 1.10.0 | Java 1.8.0 </br>Go 1.6.0 </br>PHP 1.1.0 </br>Python 1.9.0 </br>.NET 1.10.0 </br>JS 2.5.0 | 0.11.0 | Supported| |
|
||||
| November 18th 2023 | 1.10.10</br> | 1.10.0 | Java 1.8.0 </br>Go 1.7.0 </br>PHP 1.1.0 </br>Python 1.9.0 </br>.NET 1.10.0 </br>JS 3.0.0 | 0.11.0 | Unsupported | |
|
||||
| July 20th 2023 | 1.10.9</br> | 1.10.0 | Java 1.8.0 </br>Go 1.7.0 </br>PHP 1.1.0 </br>Python 1.9.0 </br>.NET 1.10.0 </br>JS 3.0.0 | 0.11.0 | Unsupported | |
|
||||
| June 22nd 2023 | 1.10.8</br> | 1.10.0 | Java 1.8.0 </br>Go 1.7.0 </br>PHP 1.1.0 </br>Python 1.9.0 </br>.NET 1.10.0 </br>JS 3.0.0 | 0.11.0 | Unsupported | |
|
||||
| May 15th 2023 | 1.10.7</br> | 1.10.0 | Java 1.8.0 </br>Go 1.7.0 </br>PHP 1.1.0 </br>Python 1.9.0 </br>.NET 1.10.0 </br>JS 3.0.0 | 0.11.0 | Unsupported | |
|
||||
| May 12th 2023 | 1.10.6</br> | 1.10.0 | Java 1.8.0 </br>Go 1.7.0 </br>PHP 1.1.0 </br>Python 1.9.0 </br>.NET 1.10.0 </br>JS 3.0.0 | 0.11.0 | Unsupported | |
|
||||
| April 13 2023 |1.10.5</br> | 1.10.0 | Java 1.8.0 </br>Go 1.6.0 </br>PHP 1.1.0 </br>Python 1.9.0 </br>.NET 1.10.0 </br>JS 3.0.0 | 0.11.0 | Unsupported | |
|
||||
| March 16 2023 | 1.10.4</br> | 1.10.0 | Java 1.8.0 </br>Go 1.6.0 </br>PHP 1.1.0 </br>Python 1.9.0 </br>.NET 1.10.0 </br>JS 2.5.0 | 0.11.0 | Unsupported | |
|
||||
| March 14 2023 | 1.10.3</br> | 1.10.0 | Java 1.8.0 </br>Go 1.6.0 </br>PHP 1.1.0 </br>Python 1.9.0 </br>.NET 1.10.0 </br>JS 2.5.0 | 0.11.0 | Unsupported | |
|
||||
| February 24 2023 | 1.10.2</br> | 1.10.0 | Java 1.8.0 </br>Go 1.6.0 </br>PHP 1.1.0 </br>Python 1.9.0 </br>.NET 1.10.0 </br>JS 2.5.0 | 0.11.0 | Unsupported | |
|
||||
| February 20 2023 | 1.10.1</br> | 1.10.0 | Java 1.8.0 </br>Go 1.6.0 </br>PHP 1.1.0 </br>Python 1.9.0 </br>.NET 1.10.0 </br>JS 2.5.0 | 0.11.0 | Unsupported | |
|
||||
| February 14 2023 | 1.10.0</br> | 1.10.0 | Java 1.8.0 </br>Go 1.6.0 </br>PHP 1.1.0 </br>Python 1.9.0 </br>.NET 1.10.0 </br>JS 2.5.0 | 0.11.0 | Unsupported | |
|
||||
| December 2nd 2022 | 1.9.5</br> | 1.9.1 | Java 1.7.0 </br>Go 1.6.0 </br>PHP 1.1.0 </br>Python 1.8.3 </br>.NET 1.9.0 </br>JS 2.4.2 | 0.11.0 | Unsupported | |
|
||||
| November 17th 2022 | 1.9.4</br> | 1.9.1 | Java 1.7.0 </br>Go 1.6.0 </br>PHP 1.1.0 </br>Python 1.8.3 </br>.NET 1.9.0 </br>JS 2.4.2 | 0.11.0 | Unsupported | |
|
||||
| November 4th 2022 | 1.9.3</br> | 1.9.1 | Java 1.7.0 </br>Go 1.6.0 </br>PHP 1.1.0 </br>Python 1.8.3 </br>.NET 1.9.0 </br>JS 2.4.2 | 0.11.0 | Unsupported | |
|
||||
|
|
@ -132,8 +133,7 @@ General guidance on upgrading can be found for [self hosted mode]({{< ref self-h
|
|||
| 1.10.0 | N/A | 1.10.8 |
|
||||
| 1.11.0 | N/A | 1.11.4 |
|
||||
| 1.12.0 | N/A | 1.12.4 |
|
||||
|
||||
|
||||
| 1.13.0 | N/A | 1.13.0 |
|
||||
|
||||
## Upgrade on Hosting platforms
|
||||
|
||||
|
|
|
|||
|
|
@ -6,6 +6,24 @@ weight: 1000
|
|||
description: "Common issues and problems faced when running Dapr applications"
|
||||
---
|
||||
|
||||
This guide covers common issues you may encounter while installing and running Dapr.
|
||||
|
||||
## Dapr can't connect to Docker when installing the Dapr CLI
|
||||
|
||||
When installing and initializing the Dapr CLI, if you see the following error message after running `dapr init`:
|
||||
|
||||
```bash
|
||||
⌛ Making the jump to hyperspace...
|
||||
❌ could not connect to docker. docker may not be installed or running
|
||||
```
|
||||
|
||||
Troubleshoot the error by ensuring:
|
||||
|
||||
1. [The correct containers are running.]({{< ref "install-dapr-selfhost.md#step-4-verify-containers-are-running" >}})
|
||||
1. In Docker Desktop, verify the **Allow the default Docker socket to be used (requires password)** option is selected.
|
||||
|
||||
<img src="/images/docker-desktop-setting.png" width=800 style="padding-bottom:15px;">
|
||||
|
||||
## I don't see the Dapr sidecar injected to my pod
|
||||
|
||||
There could be several reasons to why a sidecar will not be injected into a pod.
|
||||
|
|
|
|||
|
|
@ -6,34 +6,81 @@ description: "Detailed documentation on the health API"
|
|||
weight: 1000
|
||||
---
|
||||
|
||||
Dapr provides health checking probes that can be used as readiness or liveness of Dapr.
|
||||
Dapr provides health checking probes that can be used as readiness or liveness of Dapr and for initialization readiness from SDKs.
|
||||
|
||||
## Get Dapr health state
|
||||
|
||||
Gets the health state for Dapr.
|
||||
Gets the health state for Dapr by either:
|
||||
- Check for sidecar health
|
||||
- Check for the sidecar health, including component readiness, used during initialization.
|
||||
|
||||
### HTTP Request
|
||||
### Wait for Dapr HTTP port to become available
|
||||
|
||||
Wait for all components to be initialized, the Dapr HTTP port to be available _and_ the app channel is initialized. For example, this endpoint is used with Kubernetes liveness probes.
|
||||
|
||||
#### HTTP Request
|
||||
|
||||
```
|
||||
GET http://localhost:<daprPort>/v1.0/healthz
|
||||
```
|
||||
|
||||
### HTTP Response Codes
|
||||
#### HTTP Response Codes
|
||||
|
||||
Code | Description
|
||||
---- | -----------
|
||||
204 | dapr is healthy
|
||||
500 | dapr is not healthy
|
||||
204 | Dapr is healthy
|
||||
500 | Dapr is not healthy
|
||||
|
||||
### URL Parameters
|
||||
#### URL Parameters
|
||||
|
||||
Parameter | Description
|
||||
--------- | -----------
|
||||
daprPort | The Dapr port.
|
||||
daprPort | The Dapr port
|
||||
|
||||
### Examples
|
||||
#### Examples
|
||||
|
||||
```shell
|
||||
curl -i http://localhost:3500/v1.0/healthz
|
||||
```
|
||||
|
||||
### Wait for specific health check against `/outbound` path
|
||||
|
||||
Wait for all components to be initialized, the Dapr HTTP port to be available, however the app channel is not yet established. This endpoint enables your application to perform calls on the Dapr sidecar APIs before the app channel is initalized, for example reading secrets with the secrets API. For example used in the Dapr SDKs `waitForSidecar` method (for example .NET and Java SDKs) to check sidecar is initialized correctly ready for any calls.
|
||||
|
||||
For example, the [Java SDK]({{< ref "java-client.md#wait-for-sidecar" >}}) and [the .NET SDK]({{< ref "dotnet-client.md#wait-for-sidecar" >}}) uses this endpoint for initialization.
|
||||
|
||||
Currently, the `v1.0/healthz/outbound` endpoint is supported in the:
|
||||
- [.NET SDK]({{< ref "dotnet-client.md#wait-for-sidecar" >}})
|
||||
- [Java SDK]({{< ref "java-client.md#wait-for-sidecar" >}})
|
||||
- [Python SDK]({{< ref "python-client.md#health-timeout" >}})
|
||||
- [JavaScript SDK](https://github.com/dapr/js-sdk/blob/4189a3d2ad6897406abd766f4ccbf2300c8f8852/src/interfaces/Client/IClientHealth.ts#L14)
|
||||
|
||||
#### HTTP Request
|
||||
|
||||
```
|
||||
GET http://localhost:<daprPort>/v1.0/healthz/outbound
|
||||
```
|
||||
|
||||
#### HTTP Response Codes
|
||||
|
||||
Code | Description
|
||||
---- | -----------
|
||||
204 | Dapr is healthy
|
||||
500 | Dapr is not healthy
|
||||
|
||||
#### URL Parameters
|
||||
|
||||
Parameter | Description
|
||||
--------- | -----------
|
||||
daprPort | The Dapr port
|
||||
|
||||
#### Examples
|
||||
|
||||
```shell
|
||||
curl -i http://localhost:3500/v1.0/healthz/outbound
|
||||
```
|
||||
|
||||
## Related articles
|
||||
|
||||
- [Sidecar health]({{< ref "sidecar-health.md" >}})
|
||||
- [App health]({{< ref "app-health.md" >}})
|
||||
|
|
|
|||
|
|
@ -182,8 +182,7 @@ POST http://localhost:3500/v1.0-beta1/workflows/<workflowComponentName>/<instanc
|
|||
```
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
Purging a workflow purges all of the child workflows created by the workflow instance.
|
||||
|
||||
Only `COMPLETED`, `FAILED`, or `TERMINATED` workflows can be purged.
|
||||
{{% /alert %}}
|
||||
|
||||
### URL parameters
|
||||
|
|
@ -247,7 +246,7 @@ The API call will provide a JSON response similar to this:
|
|||
|
||||
Parameter | Description
|
||||
--------- | -----------
|
||||
`runtimeStatus` | The status of the workflow instance. Values include: `RUNNING`, `TERMINATED`, `PAUSED`
|
||||
`runtimeStatus` | The status of the workflow instance. Values include: `"RUNNING"`, `"COMPLETED"`, `"CONTINUED_AS_NEW"`, `"FAILED"`, `"CANCELED"`, `"TERMINATED"`, `"PENDING"`, `"SUSPENDED"`
|
||||
|
||||
## Component format
|
||||
|
||||
|
|
|
|||
|
|
@ -162,6 +162,12 @@ dapr uninstall --all --network mynet
|
|||
dapr init -k
|
||||
```
|
||||
|
||||
Using the `--dev` flag initializes Dapr in dev mode, which includes Zipkin and Redis.
|
||||
```bash
|
||||
dapr init -k --dev
|
||||
```
|
||||
|
||||
|
||||
You can wait for the installation to complete its deployment with the `--wait` flag.
|
||||
The default timeout is 300s (5 min), but can be customized with the `--timeout` flag.
|
||||
|
||||
|
|
|
|||
|
|
@ -40,6 +40,8 @@ spec:
|
|||
# key: "mytoken"
|
||||
#- name: securityTokenHeader
|
||||
# value: "Authorization: Bearer" # OPTIONAL <header name for the security token>
|
||||
#- name: errorIfNot2XX
|
||||
# value: "false" # OPTIONAL
|
||||
```
|
||||
|
||||
## Spec metadata fields
|
||||
|
|
@ -54,8 +56,8 @@ spec:
|
|||
| `MTLSRenegotiation` | N | Output | Type of mTLS renegotiation to be used | `RenegotiateOnceAsClient`
|
||||
| `securityToken` | N | Output | The value of a token to be added to a HTTP request as a header. Used together with `securityTokenHeader` |
|
||||
| `securityTokenHeader` | N | Output | The name of the header for `securityToken` on a HTTP request |
|
||||
| `errorIfNot2XX` | N | Output | If a binding error should be thrown when the response is not in the 2xx range. Defaults to `true` |
|
||||
|
||||
### How to configure mTLS-related fields in metadata
|
||||
|
||||
The values for **MTLSRootCA**, **MTLSClientCert** and **MTLSClientKey** can be provided in three ways:
|
||||
|
||||
|
|
|
|||
|
|
@ -276,6 +276,11 @@ The response body contains the following JSON:
|
|||
[0.018574921,-0.00023652936,-0.0057790717,.... (1536 floats total for ada)]
|
||||
```
|
||||
|
||||
## Learn more about the Azure OpenAI output binding
|
||||
|
||||
Watch [the following Community Call presentation](https://youtu.be/rTovKpG0rhY?si=g7hZTQSpSEXz4pV1&t=80) to learn more about the Azure OpenAI output binding.
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/rTovKpG0rhY?si=XP1S-80SIg1ptJuG&start=80" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
|
||||
|
||||
## Related links
|
||||
|
||||
|
|
|
|||
|
|
@ -89,6 +89,7 @@ The above example uses secrets as plain strings. It is recommended to use a [sec
|
|||
| processMode | N | Enable processing multiple messages at once. Default: `"async"` | `"async"`, `"sync"`|
|
||||
| subscribeType | N | Pulsar supports four kinds of [subscription types](https://pulsar.apache.org/docs/3.0.x/concepts-messaging/#subscription-types). Default: `"shared"` | `"shared"`, `"exclusive"`, `"failover"`, `"key_shared"`|
|
||||
| partitionKey | N | Sets the key of the message for routing policy. Default: `""` | |
|
||||
| `maxConcurrentHandlers` | N | Defines the maximum number of concurrent message handlers. Default: `100` | `10`
|
||||
|
||||
### Authenticate using Token
|
||||
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@ The above example uses secrets as plain strings. It is recommended to use a secr
|
|||
| 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"`
|
||||
| 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"`
|
||||
| redeliverInterval | N | The interval between checking for pending messages to redeliver. Can use either be Go duration string (for example "ms", "s", "m") or milliseconds number. Defaults to `"60s"`. `"0"` disables redelivery. | `"30s"`, `"5000"`
|
||||
| processingTimeout | N | The amount time that a message must be pending before attempting to redeliver it. Can use either be Go duration string ( for example "ms", "s", "m") or milliseconds number. Defaults to `"15s"`. `"0"` disables redelivery. | `"60s"`, `"600000"`
|
||||
| queueDepth | N | The size of the message queue for processing. Defaults to `"100"`. | `"1000"`
|
||||
| concurrency | N | The number of concurrent workers that are processing messages. Defaults to `"10"`. | `"15"`
|
||||
| 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"`
|
||||
|
|
|
|||
|
|
@ -47,20 +47,23 @@ spec:
|
|||
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 %}}
|
||||
|
||||
If you wish to use MongoDB as an actor store, append the following to the yaml.
|
||||
### Actor state store and transactions support
|
||||
|
||||
When using as an actor state store or to leverage transactions, MongoDB must be running in a [Replica Set](https://www.mongodb.com/docs/manual/replication/).
|
||||
|
||||
If you wish to use MongoDB as an actor store, add this metadata option to your Component YAML:
|
||||
|
||||
```yaml
|
||||
- name: actorStateStore
|
||||
value: "true"
|
||||
```
|
||||
|
||||
|
||||
## Spec metadata fields
|
||||
|
||||
| Field | Required | Details | Example |
|
||||
|--------------------|:--------:|---------|---------|
|
||||
| server | Y<sup>*</sup> | The server to connect to, when using DNS SRV record | `"server.example.com"`
|
||||
| host | Y<sup>*</sup> | The host to connect to | `"mongo-mongodb.default.svc.cluster.local:27017"`
|
||||
| server | Y<sup>1</sup> | The server to connect to, when using DNS SRV record | `"server.example.com"`
|
||||
| host | Y<sup>1</sup> | The host to connect to | `"mongo-mongodb.default.svc.cluster.local:27017"`
|
||||
| username | N | The username of the user to connect with (applicable in conjunction with `host`) | `"admin"`
|
||||
| password | N | The password of the user (applicable in conjunction with `host`) | `"password"`
|
||||
| databaseName | N | The name of the database to use. Defaults to `"daprStore"` | `"daprStore"`
|
||||
|
|
@ -68,46 +71,36 @@ If you wish to use MongoDB as an actor store, append the following to the yaml.
|
|||
| writeConcern | N | The write concern to use | `"majority"`
|
||||
| readConcern | N | The read concern to use | `"majority"`, `"local"`,`"available"`, `"linearizable"`, `"snapshot"`
|
||||
| operationTimeout | N | The timeout for the operation. Defaults to `"5s"` | `"5s"`
|
||||
| params | N<sup>**</sup> | Additional parameters to use | `"?authSource=daprStore&ssl=true"`
|
||||
| params | N<sup>2</sup> | Additional parameters to use | `"?authSource=daprStore&ssl=true"`
|
||||
|
||||
> <sup>[*]</sup> The `server` and `host` fields are mutually exclusive. If neither or both are set, Dapr will return an error.
|
||||
> <sup>[1]</sup> The `server` and `host` fields are mutually exclusive. If neither or both are set, Dapr returns an error.
|
||||
|
||||
> <sup>[**]</sup> The `params` field accepts a query string that specifies connection specific options as `<name>=<value>` pairs, separated by `"&"` and prefixed with `"?"`. e.g. to use "daprStore" db as authentication database and enabling SSL/TLS in connection, specify params as `"?authSource=daprStore&ssl=true"`. See [the mongodb manual](https://docs.mongodb.com/manual/reference/connection-string/#std-label-connections-connection-options) for the list of available options and their use cases.
|
||||
> <sup>[2]</sup> The `params` field accepts a query string that specifies connection specific options as `<name>=<value>` pairs, separated by `&` and prefixed with `?`. e.g. to use "daprStore" db as authentication database and enabling SSL/TLS in connection, specify params as `?authSource=daprStore&ssl=true`. See [the mongodb manual](https://docs.mongodb.com/manual/reference/connection-string/#std-label-connections-connection-options) for the list of available options and their use cases.
|
||||
|
||||
## Setup MongoDB
|
||||
|
||||
{{< tabs "Self-Hosted" "Kubernetes" >}}
|
||||
|
||||
{{% codetab %}}
|
||||
You can run MongoDB locally using Docker:
|
||||
You can run a single MongoDB instance locally using Docker:
|
||||
|
||||
```
|
||||
```sh
|
||||
docker run --name some-mongo -d mongo
|
||||
```
|
||||
|
||||
You can then interact with the server using `localhost:27017`.
|
||||
|
||||
If you do not specify a `databaseName` value in your component definition, make sure to create a database named `daprStore`.
|
||||
You can then interact with the server at `localhost:27017`. If you do not specify a `databaseName` value in your component definition, make sure to create a database named `daprStore`.
|
||||
|
||||
In order to use the MongoDB state store for transactions and as an actor state store, you need to run MongoDB as a Replica Set. Refer to [the official documentation](https://www.mongodb.com/compatibility/deploying-a-mongodb-cluster-with-docker) for how to create a 3-node Replica Set using Docker.
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
The easiest way to install MongoDB on Kubernetes is by using the [Helm chart](https://github.com/helm/charts/tree/master/stable/mongodb):
|
||||
|
||||
```
|
||||
helm install mongo stable/mongodb
|
||||
```
|
||||
|
||||
You can conveniently install MongoDB on Kubernetes using the [Helm chart packaged by Bitnami](https://github.com/bitnami/charts/tree/main/bitnami/mongodb/). Refer to the documentation for the Helm chart for deploying MongoDB, both as a standalone server, and with a Replica Set (required for using transactions and actors).
|
||||
This installs MongoDB into the `default` namespace.
|
||||
To interact with MongoDB, find the service with: `kubectl get svc mongo-mongodb`.
|
||||
|
||||
For example, if installing using the example above, the MongoDB host address would be:
|
||||
|
||||
For example, if installing using the Helm defaults above, the MongoDB host address would be:
|
||||
`mongo-mongodb.default.svc.cluster.local:27017`
|
||||
|
||||
|
||||
Follow the on-screen instructions to get the root password for MongoDB.
|
||||
The username is `admin` by default.
|
||||
The username is typically `admin` by default.
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
|
@ -117,6 +110,7 @@ The username is `admin` by default.
|
|||
This state store supports [Time-To-Live (TTL)]({{< ref state-store-ttl.md >}}) for records stored with Dapr. When storing data using Dapr, you can set the `ttlInSeconds` metadata property to indicate when the data should be considered "expired".
|
||||
|
||||
## Related links
|
||||
|
||||
- [Basic schema for a Dapr component]({{< ref component-schema >}})
|
||||
- Read [this guide]({{< ref "howto-get-save-state.md#step-2-save-and-retrieve-a-single-state" >}}) for instructions on configuring state store components
|
||||
- [State management building block]({{< ref state-management >}})
|
||||
|
|
|
|||
|
|
@ -30,18 +30,14 @@ spec:
|
|||
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
|
||||
value: <bool> # Optional. Allowed: true, false.
|
||||
- name: sentinelMasterName
|
||||
value: # Optional
|
||||
value: <string> # Optional
|
||||
- name: redeliverInterval
|
||||
value: # Optional
|
||||
- name: processingTimeout
|
||||
|
|
|
|||
|
|
@ -29,3 +29,4 @@ The following table lists the environment variables used by the Dapr runtime, CL
|
|||
| DAPR_COMPONENTS_SOCKETS_EXTENSION | .NET and Java pluggable component SDKs | A per-SDK configuration that indicates the default file extension applied to socket files created by the SDKs. Not a Dapr-enforced behavior. |
|
||||
| DAPR_PLACEMENT_METADATA_ENABLED | Dapr placement | Enable an endpoint for the Placement service that exposes placement table information on actor usage. Set to `true` to enable in self-hosted mode. [Learn more about the Placement API]({{< ref placement_api.md >}}) |
|
||||
| DAPR_HOST_IP | Dapr sidecar | The host's chosen IP address. If not specified, will loop over the network interfaces and select the first non-loopback address it finds.|
|
||||
| DAPR_HEALTH_TIMEOUT | SDKs | Sets the time on the "wait for sidecar" availability. Overrides the default timeout setting of 60 seconds. |
|
||||
|
|
@ -14,6 +14,14 @@
|
|||
features:
|
||||
input: true
|
||||
output: true
|
||||
- component: Azure OpenAI
|
||||
link: openai
|
||||
state: Alpha
|
||||
version: v1
|
||||
since: "1.11"
|
||||
features:
|
||||
input: true
|
||||
output: true
|
||||
- component: Azure SignalR
|
||||
link: signalr
|
||||
state: Alpha
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
{{- if .Get "short" }}1.12{{ else if .Get "long" }}1.12.4{{ else if .Get "cli" }}1.12.0{{ else }}1.12.4{{ end -}}
|
||||
{{- if .Get "short" }}1.13{{ else if .Get "long" }}1.13.0{{ else if .Get "cli" }}1.13.0{{ else }}1.13.0{{ end -}}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 255 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 62 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 24 KiB |
Binary file not shown.
Binary file not shown.
|
|
@ -1 +1 @@
|
|||
Subproject commit d023a43ba4fd4cddb7aa2c0962cf786f01f58c24
|
||||
Subproject commit c07eb698ac5d1b152a60d76c64af4841ffa07397
|
||||
|
|
@ -1 +1 @@
|
|||
Subproject commit a65eddaa4e9217ed5cdf436b3438d2ffd837ba55
|
||||
Subproject commit 5ef7aa2234d4d4c07769ad31cde223ef11c4e33e
|
||||
|
|
@ -1 +1 @@
|
|||
Subproject commit a9a09ba2acc39bc7e54a5a7092e1c5820818e23c
|
||||
Subproject commit 2f5947392a33bc7911e6669601ddb9e8b59b58fe
|
||||
|
|
@ -1 +1 @@
|
|||
Subproject commit 5c2b40ac94b50f6a5bdb32008f6a47da69946d95
|
||||
Subproject commit 4189a3d2ad6897406abd766f4ccbf2300c8f8852
|
||||
|
|
@ -1 +1 @@
|
|||
Subproject commit ef732090e8e04629ca573d127c5ee187a505aba4
|
||||
Subproject commit 0b7aafdab1d4fade424b1b6c9569329ad10bb516
|
||||
Loading…
Reference in New Issue