mirror of https://github.com/dapr/docs.git
Merge branch 'v1.13' into issue_4193
This commit is contained in:
Hannah Hunter
GitHub
commit
c66d2d3760
|
|
@ -1,6 +1,6 @@
|
|||
# Dapr documentation
|
||||
|
||||
[](https://github.com/dapr/docs/blob/v1.13/LICENSE) [](https://github.com/dapr/docs/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22) [](http://bit.ly/dapr-discord) [](https://youtube.com/@daprdev) [](https://twitter.com/daprdev)
|
||||
[](https://github.com/dapr/docs/blob/v1.13/LICENSE) [](https://github.com/dapr/docs/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22) [](https://bit.ly/dapr-discord) [](https://youtube.com/@daprdev) [](https://twitter.com/daprdev)
|
||||
|
||||
If you are looking to explore the Dapr documentation, please go to the documentation website:
|
||||
|
||||
|
|
@ -23,7 +23,7 @@ For more information visit the [Dapr branch structure](https://docs.dapr.io/cont
|
|||
|
||||
## Contribution guidelines
|
||||
|
||||
Before making your first contribution, make sure to review the [contributing section](http://docs.dapr.io/contributing/) in the docs.
|
||||
Before making your first contribution, make sure to review the [contributing section](https://docs.dapr.io/contributing/) in the docs.
|
||||
|
||||
## Overview
|
||||
|
||||
|
|
|
|||
|
|
@ -138,7 +138,7 @@ Dapr can be used from any developer framework. Here are some that have been inte
|
|||
| [.NET]({{< ref dotnet >}}) | [ASP.NET Core](https://github.com/dapr/dotnet-sdk/tree/master/examples/AspNetCore) | 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/) | 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
|
||||
| [JavaScript](https://github.com/dapr/js-sdk) | [Express](https://expressjs.com/) | Build Express applications with Dapr APIs
|
||||
| [PHP]({{< ref php >}}) | | You can serve with Apache, Nginx, or Caddyserver.
|
||||
|
||||
#### Integrations and extensions
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ description: >
|
|||
How Dapr compares to and works with service meshes
|
||||
---
|
||||
|
||||
Dapr uses a sidecar architecture, running as a separate process alongside the application and includes features such as service invocation, network security, and distributed tracing. This often raises the question: how does Dapr compare to service mesh solutions such as [Linkerd](https://linkerd.io/), [Istio](https://istio.io/) and [Open Service Mesh](https://openservicemesh.io/) among others?
|
||||
Dapr uses a sidecar architecture, running as a separate process alongside the application and includes features such as service invocation, network security, and [distributed tracing](https://middleware.io/blog/what-is-distributed-tracing/). This often raises the question: how does Dapr compare to service mesh solutions such as [Linkerd](https://linkerd.io/), [Istio](https://istio.io/) and [Open Service Mesh](https://openservicemesh.io/) among others?
|
||||
|
||||
## How Dapr and service meshes compare
|
||||
While Dapr and service meshes do offer some overlapping capabilities, **Dapr is not a service mesh**, where a service mesh is defined as a *networking* service mesh. Unlike a service mesh which is focused on networking concerns, Dapr is focused on providing building blocks that make it easier for developers to build applications as microservices. Dapr is developer-centric, versus service meshes which are infrastructure-centric.
|
||||
|
|
|
|||
|
|
@ -106,7 +106,7 @@ spec:
|
|||
|
||||
The code examples below leverage Dapr SDKs to invoke the output bindings endpoint on a running Dapr instance.
|
||||
|
||||
{{< tabs Dotnet Java Python Go JavaScript>}}
|
||||
{{< tabs ".NET" Java Python Go JavaScript>}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -115,7 +115,7 @@ Configure your application to receive incoming events. If you're using HTTP, you
|
|||
|
||||
Below are code examples that leverage Dapr SDKs to demonstrate an output binding.
|
||||
|
||||
{{< tabs Dotnet Java Python Go JavaScript>}}
|
||||
{{< tabs ".NET" Java Python Go JavaScript>}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ spec:
|
|||
|
||||
The following example shows how to get a saved configuration item using the Dapr Configuration API.
|
||||
|
||||
{{< tabs ".NET" Java Python Go Javascript "HTTP API (BASH)" "HTTP API (Powershell)">}}
|
||||
{{< tabs ".NET" Java Python Go JavaScript "HTTP API (BASH)" "HTTP API (Powershell)">}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
|
|
@ -252,7 +252,7 @@ Invoke-RestMethod -Uri 'http://localhost:3601/v1.0/configuration/configstore?key
|
|||
|
||||
Below are code examples that leverage SDKs to subscribe to keys `[orderId1, orderId2]` using `configstore` store component.
|
||||
|
||||
{{< tabs ".NET" "ASP.NET Core" Java Python Go Javascript>}}
|
||||
{{< tabs ".NET" "ASP.NET Core" Java Python Go JavaScript>}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
|
|
@ -521,7 +521,7 @@ After you've subscribed to watch configuration items, you will receive updates f
|
|||
|
||||
Following are the code examples showing how you can unsubscribe to configuration updates using unsubscribe API.
|
||||
|
||||
{{< tabs ".NET" Java Python Go Javascript "HTTP API (BASH)" "HTTP API (Powershell)">}}
|
||||
{{< tabs ".NET" Java Python Go JavaScript "HTTP API (BASH)" "HTTP API (Powershell)">}}
|
||||
|
||||
{{% codetab %}}
|
||||
```csharp
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ spec:
|
|||
|
||||
### Acquire lock
|
||||
|
||||
{{< tabs HTTP Dotnet Go >}}
|
||||
{{< tabs HTTP ".NET" Go >}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
|
|
@ -122,7 +122,7 @@ func main() {
|
|||
|
||||
### Unlock existing lock
|
||||
|
||||
{{< tabs HTTP Dotnet Go >}}
|
||||
{{< tabs HTTP ".NET" Go >}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ scopes:
|
|||
|
||||
You can override this file with another [pubsub component]({{< ref setup-pubsub >}}) by creating a components directory (in this example, `myComponents`) containing the file and using the flag `--resources-path` with the `dapr run` CLI command.
|
||||
|
||||
{{< tabs Dotnet Java Python Go Javascript >}}
|
||||
{{< tabs ".NET" Java Python Go JavaScript >}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
|
|
@ -186,7 +186,7 @@ Place `subscription.yaml` in the same directory as your `pubsub.yaml` component.
|
|||
|
||||
Below are code examples that leverage Dapr SDKs to subscribe to the topic you defined in `subscription.yaml`.
|
||||
|
||||
{{< tabs Dotnet Java Python Go JavaScript>}}
|
||||
{{< tabs ".NET" Java Python Go JavaScript>}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
|
|
@ -422,7 +422,7 @@ Invoke-RestMethod -Method Post -ContentType 'application/json' -Body '{"orderId"
|
|||
|
||||
Below are code examples that leverage Dapr SDKs to publish a topic.
|
||||
|
||||
{{< tabs Dotnet Java Python Go Javascript>}}
|
||||
{{< tabs ".NET" Java Python Go JavaScript>}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ The bulk publish operation also does not guarantee any ordering of messages.
|
|||
|
||||
### Example
|
||||
|
||||
{{< tabs Java Javascript Dotnet Python Go "HTTP API (Bash)" "HTTP API (PowerShell)" >}}
|
||||
{{< tabs Java JavaScript ".NET" Python Go "HTTP API (Bash)" "HTTP API (PowerShell)" >}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ See a [full API reference]({{< ref secrets_api.md >}}).
|
|||
|
||||
Now that you've set up the local secret store, call Dapr to get the secrets from your application code. Below are code examples that leverage Dapr SDKs for retrieving a secret.
|
||||
|
||||
{{< tabs Dotnet Java Python Go Javascript>}}
|
||||
{{< tabs ".NET" Java Python Go JavaScript>}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ spec:
|
|||
allowedSecrets: ["secret1", "secret2"]
|
||||
```
|
||||
|
||||
The default access to the `vault` secret store is `deny`, while some secrets are accessible by the application, based on the `allowedSecrets` list. [Learn how to apply configuration to the sidecar]]({{< ref configuration-concept.md >}}).
|
||||
The default access to the `vault` secret store is `deny`, while some secrets are accessible by the application, based on the `allowedSecrets` list. [Learn how to apply configuration to the sidecar]({{< ref configuration-concept.md >}}).
|
||||
|
||||
## Scenario 3: Deny access to certain sensitive secrets in a secret store
|
||||
|
||||
|
|
@ -88,7 +88,7 @@ spec:
|
|||
deniedSecrets: ["secret1", "secret2"]
|
||||
```
|
||||
|
||||
This example configuration explicitly denies access to `secret1` and `secret2` from the secret store named `vault` while allowing access to all other secrets. [Learn how to apply configuration to the sidecar]]({{< ref configuration-concept.md >}}).
|
||||
This example configuration explicitly denies access to `secret1` and `secret2` from the secret store named `vault` while allowing access to all other secrets. [Learn how to apply configuration to the sidecar]({{< ref configuration-concept.md >}}).
|
||||
|
||||
## Permission priority
|
||||
|
||||
|
|
|
|||
|
|
@ -247,7 +247,9 @@ namespace EventService
|
|||
var content = new StringContent(orderJson, Encoding.UTF8, "application/json");
|
||||
|
||||
var httpClient = DaprClient.CreateInvokeHttpClient();
|
||||
await httpClient.PostAsJsonAsync("http://order-processor/orders", content);
|
||||
var response = await httpClient.PostAsJsonAsync("http://order-processor/orders", content);
|
||||
var result = await response.Content.ReadAsStringAsync();
|
||||
|
||||
Console.WriteLine("Order requested: " + orderId);
|
||||
Console.WriteLine("Result: " + result);
|
||||
}
|
||||
|
|
@ -408,6 +410,14 @@ Using CLI:
|
|||
dapr invoke --app-id checkout --method checkout/100
|
||||
```
|
||||
|
||||
#### Including a query string in the URL
|
||||
|
||||
You can also append a query string or a fragment to the end of the URL and Dapr will pass it through unchanged. This means that if you need to pass some additional arguments in your service invocation that aren't part of a payload or the path, you can do so by appending a `?` to the end of the URL, followed by the key/value pairs separated by `=` signs and delimited by `&`. For example:
|
||||
|
||||
```bash
|
||||
curl 'http://dapr-app-id:checkout@localhost:3602/checkout/100?basket=1234&key=abc` -X POST
|
||||
```
|
||||
|
||||
### Namespaces
|
||||
|
||||
When running on [namespace supported platforms]({{< ref "service_invocation_api.md#namespace-supported-platforms" >}}), you include the namespace of the target app in the app ID. For example, following the `<app>.<namespace>` format, use `checkout.production`.
|
||||
|
|
|
|||
|
|
@ -126,7 +126,7 @@ ctx = metadata.AppendToOutgoingContext(ctx, "dapr-app-id", "server")
|
|||
|
||||
All languages supported by gRPC allow for adding metadata. Here are a few examples:
|
||||
|
||||
{{< tabs Java Dotnet Python JavaScript Ruby "C++">}}
|
||||
{{< tabs Java ".NET" Python JavaScript Ruby "C++">}}
|
||||
|
||||
{{% codetab %}}
|
||||
```java
|
||||
|
|
@ -249,7 +249,7 @@ When using Dapr to proxy streaming RPC calls using gRPC, you must set an additio
|
|||
|
||||
For example:
|
||||
|
||||
{{< tabs Go Java Dotnet Python JavaScript Ruby "C++">}}
|
||||
{{< tabs Go Java ".NET" Python JavaScript Ruby "C++">}}
|
||||
|
||||
{{% codetab %}}
|
||||
```go
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ Set an `app-id`, as the state keys are prefixed with this value. If you don't se
|
|||
|
||||
The following example shows how to save and retrieve a single key/value pair using the Dapr state management API.
|
||||
|
||||
{{< tabs Dotnet Java Python Go Javascript "HTTP API (Bash)" "HTTP API (PowerShell)">}}
|
||||
{{< tabs ".NET" Java Python Go JavaScript "HTTP API (Bash)" "HTTP API (PowerShell)">}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
|
|
@ -356,7 +356,7 @@ Restart your sidecar and try retrieving state again to observe that state persis
|
|||
|
||||
Below are code examples that leverage Dapr SDKs for deleting the state.
|
||||
|
||||
{{< tabs Dotnet Java Python Go Javascript "HTTP API (Bash)" "HTTP API (PowerShell)">}}
|
||||
{{< tabs ".NET" Java Python Go JavaScript "HTTP API (Bash)" "HTTP API (PowerShell)">}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
|
|
@ -537,7 +537,7 @@ Try getting state again. Note that no value is returned.
|
|||
|
||||
Below are code examples that leverage Dapr SDKs for saving and retrieving multiple states.
|
||||
|
||||
{{< tabs Dotnet Java Python Go Javascript "HTTP API (Bash)" "HTTP API (PowerShell)">}}
|
||||
{{< tabs ".NET" Java Python Go JavaScript "HTTP API (Bash)" "HTTP API (PowerShell)">}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
|
|
@ -788,7 +788,7 @@ State transactions require a state store that supports multi-item transactions.
|
|||
|
||||
Below are code examples that leverage Dapr SDKs for performing state transactions.
|
||||
|
||||
{{< tabs Dotnet Java Python Go Javascript "HTTP API (Bash)" "HTTP API (PowerShell)">}}
|
||||
{{< tabs ".NET" Java Python Go JavaScript "HTTP API (Bash)" "HTTP API (PowerShell)">}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ This "replay" behavior continues until the workflow function completes or fails
|
|||
Using this replay technique, a workflow is able to resume execution from any "await" point as if it had never been unloaded from memory. Even the values of local variables from previous runs can be restored without the workflow engine knowing anything about what data they stored. This ability to restore state makes Dapr Workflows _durable_ and _fault tolerant_.
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
The workflow replay behavior described here requires that workflow function code be _deterministic_. Deterministic workflow functions take the exact same actions when provided the exact same inputs. [Learn more about the limitations around deterministic workflow code.]({{< ref "workflow-features-concepts.md#workflow-determinism-and-code-constraints" >}})
|
||||
The workflow replay behavior described here requires that workflow function code be _deterministic_. Deterministic workflow functions take the exact same actions when provided the exact same inputs. [Learn more about the limitations around deterministic workflow code.]({{< ref "workflow-features-concepts.md#workflow-determinism-and-code-restraints" >}})
|
||||
{{% /alert %}}
|
||||
|
||||
|
||||
|
|
@ -75,9 +75,9 @@ You can use the following two techniques to write workflows that may need to sch
|
|||
|
||||
### Updating workflow code
|
||||
|
||||
Because workflows are long-running and durable, updating workflow code must be done with extreme care. As discussed in the [workflow determinism]({{< ref "#workflow-determinism-and-code-constraints" >}}) limitation section, workflow code must be deterministic. Updates to workflow code must preserve this determinism if there are any non-completed workflow instances in the system. Otherwise, updates to workflow code can result in runtime failures the next time those workflows execute.
|
||||
Because workflows are long-running and durable, updating workflow code must be done with extreme care. As discussed in the [workflow determinism]({{< ref "#workflow-determinism-and-code-restraints" >}}) limitation section, workflow code must be deterministic. Updates to workflow code must preserve this determinism if there are any non-completed workflow instances in the system. Otherwise, updates to workflow code can result in runtime failures the next time those workflows execute.
|
||||
|
||||
[See known limitations]({{< ref "workflow-features-concepts.md#workflow-determinism-and-code-constraints" >}})
|
||||
[See known limitations]({{< ref "#limitations" >}})
|
||||
|
||||
## Workflow activities
|
||||
|
||||
|
|
@ -123,7 +123,7 @@ Retries are internally implemented using durable timers. This means that workflo
|
|||
The actions performed by a retry policy are saved into a workflow's history. Care must be taken not to change the behavior of a retry policy after a workflow has already been executed. Otherwise, the workflow may behave unexpectedly when replayed. See the notes on [updating workflow code]({{< ref "#updating-workflow-code" >}}) for more information.
|
||||
{{% /alert %}}
|
||||
|
||||
It's possible to use both workflow retry policies and Dapr Resiliency policies together. For example, if a workflow activity uses a Dapr client to invoke a service, the Dapr client uses the configured resiliency policy. See [Quickstart: Service-to-service resiliency]({{< ref "#resiliency-serviceinvo-quickstart" >}}) for more information with an example. However, if the activity itself fails for any reason, including exhausting the retries on the resiliency policy, then the workflow's resiliency policy kicks in.
|
||||
It's possible to use both workflow retry policies and Dapr Resiliency policies together. For example, if a workflow activity uses a Dapr client to invoke a service, the Dapr client uses the configured resiliency policy. See [Quickstart: Service-to-service resiliency]({{< ref "resiliency-serviceinvo-quickstart.md" >}}) for more information with an example. However, if the activity itself fails for any reason, including exhausting the retries on the resiliency policy, then the workflow's resiliency policy kicks in.
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
Using workflow retry policies and resiliency policies together can result in unexpected behavior. For example, if a workflow activity exhausts its configured retry policy, the workflow engine will still retry the activity according to the workflow retry policy. This can result in the activity being retried more times than expected.
|
||||
|
|
|
|||
|
|
@ -8,4 +8,4 @@ description: "Use the Dapr Kubernetes Operator to manage the Dapr control plane"
|
|||
|
||||
You can use the Dapr Kubernetes Operator to manage the Dapr control plane. Use the operator to automate the tasks required to manage the lifecycle of Dapr control plane in Kubernetes mode.
|
||||
|
||||
{{< button text="Install and use the Dapr Kubernetes Operator" link="https://github.com/dapr/dapr-kubernetes-operator" >}}
|
||||
{{< button text="Install and use the Dapr Kubernetes Operator" link="https://github.com/dapr/kubernetes-operator" >}}
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ Select your [preferred language below]({{< ref "#sdk-languages" >}}) to learn mo
|
|||
| [Java]({{< ref java >}}) | Stable | ✔ | Spring Boot <br /> Quarkus| ✔ | ✔ |
|
||||
| [Go]({{< ref go >}}) | Stable | ✔ | ✔ | ✔ | ✔ |
|
||||
| [PHP]({{< ref php >}}) | Stable | ✔ | ✔ | ✔ | |
|
||||
| [Javascript]({{< ref js >}}) | Stable| ✔ | | ✔ | ✔ |
|
||||
| [JavaScript]({{< ref js >}}) | Stable| ✔ | | ✔ | ✔ |
|
||||
| [C++](https://github.com/dapr/cpp-sdk) | In development | ✔ | | |
|
||||
| [Rust](https://github.com/dapr/rust-sdk) | In development | ✔ | | ✔ | |
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ 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.
|
||||
In Docker Desktop's advanced options, verify you've allowed the default Docker socket to be used. This option is not available if you are using WSL integration on Windows.
|
||||
<img src="/images/docker-desktop-setting.png" width=800 style="padding-bottom:15px;">
|
||||
{{% /alert %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -651,7 +651,7 @@ In the YAML file:
|
|||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- Java JDK 11 (or greater):
|
||||
- Java JDK 17 (or greater):
|
||||
- [Oracle JDK](https://www.oracle.com/java/technologies/downloads), or
|
||||
- OpenJDK
|
||||
- [Apache Maven](https://maven.apache.org/install.html), version 3.x.
|
||||
|
|
|
|||
|
|
@ -389,7 +389,7 @@ try
|
|||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- Java JDK 11 (or greater):
|
||||
- Java JDK 17 (or greater):
|
||||
- [Oracle JDK](https://www.oracle.com/technetwork/java/javase/downloads/index.html#JDK11), or
|
||||
- OpenJDK
|
||||
- [Apache Maven](https://maven.apache.org/install.html), version 3.x.
|
||||
|
|
|
|||
|
|
@ -512,7 +512,7 @@ Console.WriteLine("Published data: " + order);
|
|||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- Java JDK 11 (or greater):
|
||||
- Java JDK 17 (or greater):
|
||||
- [Oracle JDK](https://www.oracle.com/java/technologies/downloads), or
|
||||
- OpenJDK
|
||||
- [Apache Maven](https://maven.apache.org/install.html), version 3.x.
|
||||
|
|
@ -1321,7 +1321,7 @@ In the YAML file:
|
|||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- Java JDK 11 (or greater):
|
||||
- Java JDK 17 (or greater):
|
||||
- [Oracle JDK](https://www.oracle.com/java/technologies/downloads), or
|
||||
- OpenJDK
|
||||
- [Apache Maven](https://maven.apache.org/install.html), version 3.x.
|
||||
|
|
|
|||
|
|
@ -693,7 +693,7 @@ dapr run --app-port 7001 --app-id order-processor --app-protocol http --dapr-htt
|
|||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- Java JDK 11 (or greater):
|
||||
- Java JDK 17 (or greater):
|
||||
- [Oracle JDK](https://www.oracle.com/java/technologies/downloads), or
|
||||
- OpenJDK
|
||||
- [Apache Maven](https://maven.apache.org/install.html), version 3.x.
|
||||
|
|
|
|||
|
|
@ -61,27 +61,28 @@ Run the `order-processor` service alongside a Dapr sidecar. The Dapr sidecar the
|
|||
metadata:
|
||||
name: myresiliency
|
||||
scopes:
|
||||
- checkout
|
||||
|
||||
- order-processor
|
||||
|
||||
spec:
|
||||
policies:
|
||||
retries:
|
||||
retryForever:
|
||||
policy: constant
|
||||
maxInterval: 5s
|
||||
maxRetries: -1
|
||||
|
||||
duration: 5s
|
||||
maxRetries: -1
|
||||
|
||||
circuitBreakers:
|
||||
simpleCB:
|
||||
maxRequests: 1
|
||||
timeout: 5s
|
||||
timeout: 5s
|
||||
trip: consecutiveFailures >= 5
|
||||
|
||||
|
||||
targets:
|
||||
apps:
|
||||
order-processor:
|
||||
retry: retryForever
|
||||
circuitBreaker: simpleCB
|
||||
components:
|
||||
statestore:
|
||||
outbound:
|
||||
retry: retryForever
|
||||
circuitBreaker: simpleCB
|
||||
```
|
||||
|
||||
|
||||
|
|
@ -533,7 +534,7 @@ INFO[0036] Recovered processing operation component[statestore] output.
|
|||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- Java JDK 11 (or greater):
|
||||
- Java JDK 17 (or greater):
|
||||
- [Oracle JDK](https://www.oracle.com/java/technologies/downloads), or
|
||||
- OpenJDK
|
||||
- [Apache Maven](https://maven.apache.org/install.html), version 3.x.
|
||||
|
|
|
|||
|
|
@ -356,7 +356,7 @@ Order-processor output:
|
|||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- Java JDK 11 (or greater):
|
||||
- Java JDK 17 (or greater):
|
||||
- [Oracle JDK](https://www.oracle.com/java/technologies/downloads), or
|
||||
- OpenJDK
|
||||
- [Apache Maven](https://maven.apache.org/install.html), version 3.x.
|
||||
|
|
|
|||
|
|
@ -458,7 +458,7 @@ var response = await client.PostAsync($"{baseURL}/orders", content);
|
|||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- Java JDK 11 (or greater):
|
||||
- Java JDK 17 (or greater):
|
||||
- [Oracle JDK](https://www.oracle.com/java/technologies/downloads), or
|
||||
- OpenJDK
|
||||
- [Apache Maven](https://maven.apache.org/install.html), version 3.x.
|
||||
|
|
@ -1156,7 +1156,7 @@ Dapr invokes an application on any Dapr instance. In the code, the sidecar progr
|
|||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- Java JDK 11 (or greater):
|
||||
- Java JDK 17 (or greater):
|
||||
- [Oracle JDK](https://www.oracle.com/java/technologies/downloads), or
|
||||
- OpenJDK
|
||||
- [Apache Maven](https://maven.apache.org/install.html), version 3.x.
|
||||
|
|
|
|||
|
|
@ -419,7 +419,7 @@ In the YAML file:
|
|||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- Java JDK 11 (or greater):
|
||||
- Java JDK 17 (or greater):
|
||||
- [Oracle JDK](https://www.oracle.com/java/technologies/downloads), or
|
||||
- OpenJDK
|
||||
- [Apache Maven](https://maven.apache.org/install.html), version 3.x.
|
||||
|
|
@ -1050,7 +1050,7 @@ In the YAML file:
|
|||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- Java JDK 11 (or greater):
|
||||
- Java JDK 17 (or greater):
|
||||
- [Oracle JDK](https://www.oracle.com/java/technologies/downloads), or
|
||||
- OpenJDK
|
||||
- [Apache Maven](https://maven.apache.org/install.html), version 3.x.
|
||||
|
|
|
|||
|
|
@ -7,10 +7,10 @@ description: Get started with the Dapr Workflow building block
|
|||
---
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
Dapr Workflow is currently in beta. [See known limitations for {{% dapr-latest-version cli="true" %}}]({{< ref "workflow-overview.md#limitations" >}}).
|
||||
Dapr Workflow is currently in beta. [See known limitations for {{% dapr-latest-version cli="true" %}}]({{< ref "workflow-overview.md#limitations" >}}).
|
||||
{{% /alert %}}
|
||||
|
||||
Let's take a look at the Dapr [Workflow building block]({{< ref workflow-overview.md >}}). In this Quickstart, you'll create a simple console application to demonstrate Dapr's workflow programming model and the workflow management APIs.
|
||||
Let's take a look at the Dapr [Workflow building block]({{< ref workflow-overview.md >}}). In this Quickstart, you'll create a simple console application to demonstrate Dapr's workflow programming model and the workflow management APIs.
|
||||
|
||||
In this guide, you'll:
|
||||
|
||||
|
|
@ -29,8 +29,8 @@ Select your preferred language-specific Dapr SDK before proceeding with the Quic
|
|||
The `order-processor` console app starts and manages the `order_processing_workflow`, which simulates purchasing items from a store. The workflow consists of five unique workflow activities, or tasks:
|
||||
|
||||
- `notify_activity`: Utilizes a logger to print out messages throughout the workflow. These messages notify you when:
|
||||
- You have insufficient inventory
|
||||
- Your payment couldn't be processed, etc.
|
||||
- You have insufficient inventory
|
||||
- Your payment couldn't be processed, etc.
|
||||
- `process_payment_activity`: Processes and authorizes the payment.
|
||||
- `verify_inventory_activity`: Checks the state store to ensure there is enough inventory present for purchase.
|
||||
- `update_inventory_activity`: Removes the requested items from the state store and updates the store with the new remaining inventory value.
|
||||
|
|
@ -71,10 +71,11 @@ pip3 install -r requirements.txt
|
|||
In the terminal, start the order processor app alongside a Dapr sidecar using [Multi-App Run]({{< ref multi-app-dapr-run >}}):
|
||||
|
||||
```bash
|
||||
cd workflows/python/sdk
|
||||
dapr run -f .
|
||||
```
|
||||
|
||||
This starts the `order-processor` app with unique workflow ID and runs the workflow activities.
|
||||
This starts the `order-processor` app with unique workflow ID and runs the workflow activities.
|
||||
|
||||
Expected output:
|
||||
|
||||
|
|
@ -105,7 +106,7 @@ Running `dapr init` launches the [openzipkin/zipkin](https://hub.docker.com/r/op
|
|||
docker run -d -p 9411:9411 openzipkin/zipkin
|
||||
```
|
||||
|
||||
View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`).
|
||||
View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`).
|
||||
|
||||
<img src="/images/workflow-trace-spans-zipkin.png" width=800 style="padding-bottom:15px;">
|
||||
|
||||
|
|
@ -122,9 +123,10 @@ When you ran `dapr run -f .`:
|
|||
1. The `NotifyActivity` workflow activity sends a notification saying that order `f4e1926e-3721-478d-be8a-f5bebd1995da` has completed.
|
||||
1. The workflow terminates as completed.
|
||||
|
||||
#### `order-processor/app.py`
|
||||
#### `order-processor/app.py`
|
||||
|
||||
In the application's program file:
|
||||
|
||||
- The unique workflow order ID is generated
|
||||
- The workflow is scheduled
|
||||
- The workflow status is retrieved
|
||||
|
|
@ -276,7 +278,6 @@ The `order-processor` console app starts and manages the lifecycle of an order p
|
|||
- `processPaymentActivity`: Processes and authorizes the payment.
|
||||
- `updateInventoryActivity`: Updates the state store with the new remaining inventory value.
|
||||
|
||||
|
||||
### Step 1: Pre-requisites
|
||||
|
||||
For this example, you will need:
|
||||
|
|
@ -318,11 +319,11 @@ In the terminal, start the order processor app alongside a Dapr sidecar using [M
|
|||
dapr run -f .
|
||||
```
|
||||
|
||||
This starts the `order-processor` app with unique workflow ID and runs the workflow activities.
|
||||
This starts the `order-processor` app with unique workflow ID and runs the workflow activities.
|
||||
|
||||
Expected output:
|
||||
|
||||
```
|
||||
```log
|
||||
== APP - workflowApp == == APP == Orchestration scheduled with ID: 0c332155-1e02-453a-a333-28cfc7777642
|
||||
== APP - workflowApp == == APP == Waiting 30 seconds for instance 0c332155-1e02-453a-a333-28cfc7777642 to complete...
|
||||
== APP - workflowApp == == APP == Received "Orchestrator Request" work item with instance id '0c332155-1e02-453a-a333-28cfc7777642'
|
||||
|
|
@ -393,7 +394,7 @@ Running `dapr init` launches the [openzipkin/zipkin](https://hub.docker.com/r/op
|
|||
docker run -d -p 9411:9411 openzipkin/zipkin
|
||||
```
|
||||
|
||||
View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`).
|
||||
View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`).
|
||||
|
||||
<img src="/images/workflow-trace-spans-zipkin.png" width=800 style="padding-bottom:15px;">
|
||||
|
||||
|
|
@ -410,9 +411,10 @@ When you ran `dapr run -f .`:
|
|||
1. The `notifyActivity` workflow activity sends a notification saying that order `0c332155-1e02-453a-a333-28cfc7777642` has completed.
|
||||
1. The workflow terminates as completed.
|
||||
|
||||
#### `order-processor/workflowApp.ts`
|
||||
#### `order-processor/workflowApp.ts`
|
||||
|
||||
In the application file:
|
||||
|
||||
- The unique workflow order ID is generated
|
||||
- The workflow is scheduled
|
||||
- The workflow status is retrieved
|
||||
|
|
@ -489,12 +491,12 @@ start().catch((e) => {
|
|||
{{% codetab %}}
|
||||
|
||||
The `order-processor` console app starts and manages the lifecycle of an order processing workflow that stores and retrieves data in a state store. The workflow consists of four workflow activities, or tasks:
|
||||
|
||||
- `NotifyActivity`: Utilizes a logger to print out messages throughout the workflow
|
||||
- `ReserveInventoryActivity`: Checks the state store to ensure that there is enough inventory for the purchase
|
||||
- `ProcessPaymentActivity`: Processes and authorizes the payment
|
||||
- `UpdateInventoryActivity`: Removes the requested items from the state store and updates the store with the new remaining inventory value
|
||||
|
||||
|
||||
### Step 1: Pre-requisites
|
||||
|
||||
For this example, you will need:
|
||||
|
|
@ -513,10 +515,10 @@ Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quic
|
|||
git clone https://github.com/dapr/quickstarts.git
|
||||
```
|
||||
|
||||
In a new terminal window, navigate to the `order-processor` directory:
|
||||
In a new terminal window, navigate to the `sdk` directory:
|
||||
|
||||
```bash
|
||||
cd workflows/csharp/sdk/order-processor
|
||||
cd workflows/csharp/sdk
|
||||
```
|
||||
|
||||
### Step 3: Run the order processor app
|
||||
|
|
@ -527,7 +529,7 @@ In the terminal, start the order processor app alongside a Dapr sidecar using [M
|
|||
dapr run -f .
|
||||
```
|
||||
|
||||
This starts the `order-processor` app with unique workflow ID and runs the workflow activities.
|
||||
This starts the `order-processor` app with unique workflow ID and runs the workflow activities.
|
||||
|
||||
Expected output:
|
||||
|
||||
|
|
@ -567,7 +569,7 @@ Running `dapr init` launches the [openzipkin/zipkin](https://hub.docker.com/r/op
|
|||
docker run -d -p 9411:9411 openzipkin/zipkin
|
||||
```
|
||||
|
||||
View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`).
|
||||
View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`).
|
||||
|
||||
<img src="/images/workflow-trace-spans-zipkin.png" width=800 style="padding-bottom:15px;">
|
||||
|
||||
|
|
@ -584,9 +586,10 @@ When you ran `dapr run -f .`:
|
|||
1. The `NotifyActivity` workflow activity sends a notification saying that order `6d2abcc9` has completed.
|
||||
1. The workflow terminates as completed.
|
||||
|
||||
#### `order-processor/Program.cs`
|
||||
#### `order-processor/Program.cs`
|
||||
|
||||
In the application's program file:
|
||||
|
||||
- The unique workflow order ID is generated
|
||||
- The workflow is scheduled
|
||||
- The workflow status is retrieved
|
||||
|
|
@ -717,6 +720,7 @@ class OrderProcessingWorkflow : Workflow<OrderPayload, OrderResult>
|
|||
#### `order-processor/Activities` directory
|
||||
|
||||
The `Activities` directory holds the four workflow activities used by the workflow, defined in the following files:
|
||||
|
||||
- `NotifyActivity.cs`
|
||||
- `ReserveInventoryActivity.cs`
|
||||
- `ProcessPaymentActivity.cs`
|
||||
|
|
@ -734,22 +738,22 @@ Watch [this video to walk through the Dapr Workflow .NET demo](https://youtu.be/
|
|||
{{% codetab %}}
|
||||
|
||||
The `order-processor` console app starts and manages the lifecycle of an order processing workflow that stores and retrieves data in a state store. The workflow consists of four workflow activities, or tasks:
|
||||
|
||||
- `NotifyActivity`: Utilizes a logger to print out messages throughout the workflow
|
||||
- `RequestApprovalActivity`: Requests approval for processing payment
|
||||
- `ReserveInventoryActivity`: Checks the state store to ensure that there is enough inventory for the purchase
|
||||
- `ProcessPaymentActivity`: Processes and authorizes the payment
|
||||
- `UpdateInventoryActivity`: Removes the requested items from the state store and updates the store with the new remaining inventory value
|
||||
|
||||
|
||||
### Step 1: Pre-requisites
|
||||
|
||||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- Java JDK 11 (or greater):
|
||||
- [Microsoft JDK 11](https://docs.microsoft.com/java/openjdk/download#openjdk-11)
|
||||
- [Oracle JDK 11](https://www.oracle.com/technetwork/java/javase/downloads/index.html#JDK11)
|
||||
- [OpenJDK 11](https://jdk.java.net/11/)
|
||||
- Java JDK 17 (or greater):
|
||||
- [Microsoft JDK 17](https://docs.microsoft.com/java/openjdk/download#openjdk-17)
|
||||
- [Oracle JDK 17](https://www.oracle.com/technetwork/java/javase/downloads/index.html#JDK17)
|
||||
- [OpenJDK 17](https://jdk.java.net/17/)
|
||||
- [Apache Maven](https://maven.apache.org/install.html) version 3.x.
|
||||
<!-- IGNORE_LINKS -->
|
||||
- [Docker Desktop](https://www.docker.com/products/docker-desktop)
|
||||
|
|
@ -780,10 +784,11 @@ mvn clean install
|
|||
In the terminal, start the order processor app alongside a Dapr sidecar using [Multi-App Run]({{< ref multi-app-dapr-run >}}):
|
||||
|
||||
```bash
|
||||
cd workflows/java/sdk
|
||||
dapr run -f .
|
||||
```
|
||||
|
||||
This starts the `order-processor` app with unique workflow ID and runs the workflow activities.
|
||||
This starts the `order-processor` app with unique workflow ID and runs the workflow activities.
|
||||
|
||||
Expected output:
|
||||
|
||||
|
|
@ -826,7 +831,7 @@ Running `dapr init` launches the [openzipkin/zipkin](https://hub.docker.com/r/op
|
|||
docker run -d -p 9411:9411 openzipkin/zipkin
|
||||
```
|
||||
|
||||
View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`).
|
||||
View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`).
|
||||
|
||||
<img src="/images/workflow-trace-spans-zipkin.png" width=800 style="padding-bottom:15px;">
|
||||
|
||||
|
|
@ -1073,7 +1078,6 @@ The `Activities` directory holds the four workflow activities used by the workfl
|
|||
<!-- Go -->
|
||||
{{% codetab %}}
|
||||
|
||||
|
||||
The `order-processor` console app starts and manages the `OrderProcessingWorkflow` workflow, which simulates purchasing items from a store. The workflow consists of five unique workflow activities, or tasks:
|
||||
|
||||
- `NotifyActivity`: Utilizes a logger to print out messages throughout the workflow. These messages notify you when:
|
||||
|
|
@ -1102,10 +1106,10 @@ Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quic
|
|||
git clone https://github.com/dapr/quickstarts.git
|
||||
```
|
||||
|
||||
In a new terminal window, navigate to the `order-processor` directory:
|
||||
In a new terminal window, navigate to the `sdk` directory:
|
||||
|
||||
```bash
|
||||
cd workflows/go/sdk/order-processor
|
||||
cd workflows/go/sdk
|
||||
```
|
||||
|
||||
### Step 3: Run the order processor app
|
||||
|
|
@ -1116,7 +1120,7 @@ In the terminal, start the order processor app alongside a Dapr sidecar using [M
|
|||
dapr run -f .
|
||||
```
|
||||
|
||||
This starts the `order-processor` app with unique workflow ID and runs the workflow activities.
|
||||
This starts the `order-processor` app with unique workflow ID and runs the workflow activities.
|
||||
|
||||
Expected output:
|
||||
|
||||
|
|
@ -1157,7 +1161,7 @@ Running `dapr init` launches the [openzipkin/zipkin](https://hub.docker.com/r/op
|
|||
docker run -d -p 9411:9411 openzipkin/zipkin
|
||||
```
|
||||
|
||||
View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`).
|
||||
View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`).
|
||||
|
||||
<img src="/images/workflow-trace-spans-zipkin.png" width=800 style="padding-bottom:15px;">
|
||||
|
||||
|
|
@ -1174,9 +1178,10 @@ When you ran `dapr run`:
|
|||
1. The `NotifyActivity` workflow activity sends a notification saying that order `48ee83b7-5d80-48d5-97f9-6b372f5480a5` has completed.
|
||||
1. The workflow terminates as completed.
|
||||
|
||||
#### `order-processor/main.go`
|
||||
#### `order-processor/main.go`
|
||||
|
||||
In the application's program file:
|
||||
|
||||
- The unique workflow order ID is generated
|
||||
- The workflow is scheduled
|
||||
- The workflow status is retrieved
|
||||
|
|
@ -1317,6 +1322,7 @@ Meanwhile, the `OrderProcessingWorkflow` and its activities are defined as metho
|
|||
{{< /tabs >}}
|
||||
|
||||
## Tell us what you think!
|
||||
|
||||
We're continuously working to improve our Quickstart examples and value your feedback. Did you find this Quickstart helpful? Do you have suggestions for improvement?
|
||||
|
||||
Join the discussion in our [discord channel](https://discord.com/channels/778680217417809931/953427615916638238).
|
||||
|
|
|
|||
|
|
@ -118,7 +118,7 @@ The following table lists the properties for metrics:
|
|||
|--------------|--------|-------------|
|
||||
| `enabled` | boolean | When set to true, the default, enables metrics collection and the metrics endpoint. |
|
||||
| `rules` | array | Named rule to filter metrics. Each rule contains a set of `labels` to filter on and a `regex` expression to apply to the metrics path. |
|
||||
| `http.increasedCardinality` | boolean | When set to true, in the Dapr HTTP server each request path causes the creation of a new "bucket" of metrics. This can cause issues, including excessive memory consumption, when there many different requested endpoints (such as when interacting with RESTful APIs).<br>In Dapr 1.13 the default value is `true` (to preserve the behavior of Dapr <= 1.12), but will change to `false` in Dapr 1.14. |
|
||||
| `http.increasedCardinality` | boolean | When set to true, in the Dapr HTTP server each request path causes the creation of a new "bucket" of metrics. This can cause issues, including excessive memory consumption, when there many different requested endpoints (such as when interacting with RESTful APIs).<br>In Dapr 1.13 the default value is `true` (to preserve the behavior of Dapr <= 1.12), but changes to `false` in Dapr 1.14..|
|
||||
|
||||
To mitigate high memory usage and egress costs associated with [high cardinality metrics]({{< ref "metrics-overview.md#high-cardinality-metrics" >}}) with the HTTP server, you should set the `metrics.http.increasedCardinality` property to `false`.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,87 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Deploy Dapr per-node or per-cluster with Dapr Shared"
|
||||
linkTitle: "Dapr Shared"
|
||||
weight: 50000
|
||||
description: "Learn more about using Dapr Shared as an alternative deployment to sidecars"
|
||||
|
||||
---
|
||||
|
||||
Dapr automatically injects a sidecar to enable the Dapr APIs for your applications for the best availability and reliability.
|
||||
|
||||
Dapr Shared enables two alternative deployment strategies to create Dapr applications using a Kubernetes `Daemonset` for a per-node deployment or a `Deployment` for a per-cluster deployment.
|
||||
|
||||
- **`DaemonSet`:** When running Dapr Shared as a Kubernetes `DaemonSet` resource, the daprd container runs on each Kubernetes node in the cluster. This can reduce network hops between the applications and Dapr.
|
||||
- **`Deployment`:** When running Dapr Shared as a Kubernetes `Deployment`, the Kubernetes scheduler decides on which single node in the cluster the daprd container instance runs.
|
||||
|
||||
{{% alert title="Dapr Shared deployments" color="primary" %}}
|
||||
For each Dapr application you deploy, you need to deploy the Dapr Shared Helm chart using different `shared.appId`s.
|
||||
{{% /alert %}}
|
||||
|
||||
|
||||
|
||||
## Why Dapr Shared?
|
||||
|
||||
By default, when Dapr is installed into a Kubernetes cluster, the Dapr control plane injects Dapr as a sidecar to applications annotated with Dapr annotations ( `dapr.io/enabled: "true"`). Sidecars offer many advantages, including improved resiliency, since there is an instance per application and all communication between the application and the sidecar happens without involving the network.
|
||||
|
||||
|
||||
<img src="/images/dapr-shared/sidecar.png" width=800 style="padding-bottom:15px;">
|
||||
|
||||
While sidecars are Dapr's default deployment, some use cases require other approaches. Let's say you want to decouple the lifecycle of your workloads from the Dapr APIs. A typical example of this is functions, or function-as-a-service runtimes, which might automatically downscale your idle workloads to free up resources. For such cases, keeping the Dapr APIs and all the Dapr async functionalities (such as subscriptions) separate might be required.
|
||||
|
||||
Dapr Shared was created for these scenarios, extending the Dapr sidecar model with two new deployment approaches: `DaemonSet` (per-node) and `Deployment` (per-cluster).
|
||||
|
||||
{{% alert title="Important" color="primary" %}}
|
||||
No matter which deployment approach you choose, it is important to understand that in most use cases, you have one instance of Dapr Shared (Helm release) per service (app-id). This means that if you have an application composed of three microservices, each service is recommended to have its own Dapr Shared instance. You can see this in action by trying the [Hello Kubernetes with Dapr Shared tutorial](https://github.com/dapr/dapr-shared/blob/main/docs/tutorial/README.md).
|
||||
{{% /alert %}}
|
||||
|
||||
|
||||
### `DeamonSet`(Per-node)
|
||||
|
||||
With Kubernetes `DaemonSet`, you can define applications that need to be deployed once per node in the cluster. This enables applications that are running on the same node to communicate with local Dapr APIs, no matter where the Kubernetes `Scheduler` schedules your workload.
|
||||
|
||||
<img src="/images/dapr-shared/daemonset.png" width=800 style="padding-bottom:15px;">
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
Since `DaemonSet` installs one instance per node, it consumes more resources in your cluster, compared to `Deployment` for a per cluster deployment, with the advantage of improved resiliency.
|
||||
{{% /alert %}}
|
||||
|
||||
|
||||
### `Deployment` (Per-cluster)
|
||||
|
||||
Kubernetes `Deployments` are installed once per cluster. Based on available resources, the Kubernetes `Scheduler` decides on which node the workload is scheduled. For Dapr Shared, this means that your workload and the Dapr instance might be located on separate nodes, which can introduce considerable network latency with the trade-off of reduce resource usage.
|
||||
|
||||
<img src="/images/dapr-shared/deployment.png" width=800 style="padding-bottom:15px;">
|
||||
|
||||
## Getting Started with Dapr Shared
|
||||
|
||||
{{% alert title="Prerequisites" color="primary" %}}
|
||||
Before installing Dapr Shared, make ensure you have [Dapr installed in your cluster]({{< ref "kubernetes-deploy.md" >}}).
|
||||
{{% /alert %}}
|
||||
|
||||
If you want to get started with Dapr Shared, you can create a new Dapr Shared instance by installing the official Helm Chart:
|
||||
|
||||
```
|
||||
helm install my-shared-instance oci://registry-1.docker.io/daprio/dapr-shared-chart --set shared.appId=<DAPR_APP_ID> --set shared.remoteURL=<REMOTE_URL> --set shared.remotePort=<REMOTE_PORT> --set shared.strategy=deployment
|
||||
```
|
||||
|
||||
Your Dapr-enabled applications can now make use of the Dapr Shared instance by pointing the Dapr SDKs to or sending requests to the `my-shared-instance-dapr` Kubernetes service exposed by the Dapr Shared instance.
|
||||
|
||||
> The `my-shared-instance` above is the Helm Chart release name.
|
||||
|
||||
If you are using the Dapr SDKs, you can set the following environment variables for your application to connect to the Dapr Shared instance (in this case, running on the `default` namespace):
|
||||
|
||||
```
|
||||
env:
|
||||
- name: DAPR_HTTP_ENDPOINT
|
||||
value: http://my-shared-instance-dapr.default.svc.cluster.local:3500
|
||||
- name: DAPR_GRPC_ENDPOINT
|
||||
value: http://my-shared-instance-dapr.default.svc.cluster.local:50001
|
||||
```
|
||||
|
||||
If you are not using the SDKs, you can send HTTP or gRPC requests to those endpoints.
|
||||
|
||||
## Next steps
|
||||
|
||||
- Try the [Hello Kubernetes tutorial with Dapr Shared](https://github.com/dapr/dapr-shared/blob/main/docs/tutorial/README.md).
|
||||
- Read more in the [Dapr Shared repo](https://github.com/dapr/dapr-shared/blob/main/README.md)
|
||||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Deploy to hybrid Linux/Windows Kubernetes clusters"
|
||||
linkTitle: "Hybrid clusters"
|
||||
weight: 60000
|
||||
weight: 70000
|
||||
description: "How to run Dapr apps on Kubernetes clusters with Windows nodes"
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Running Dapr with a Kubernetes Job"
|
||||
linkTitle: "Kubernetes Jobs"
|
||||
weight: 70000
|
||||
weight: 80000
|
||||
description: "Use Dapr API in a Kubernetes Job context"
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "How-to: Mount Pod volumes to the Dapr sidecar"
|
||||
linkTitle: "How-to: Mount Pod volumes"
|
||||
weight: 80000
|
||||
weight: 90000
|
||||
description: "Configure the Dapr sidecar to mount Pod Volumes"
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -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 |
|
||||
|--------------------|:--------:|:--------|---------|---------|---------|------------|
|
||||
| June 28th 2024 | 1.13.5</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.5 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.5) |
|
||||
| May 29th 2024 | 1.13.4</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.4 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.4) |
|
||||
| May 21st 2024 | 1.13.3</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.3 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.3) |
|
||||
| April 3rd 2024 | 1.13.2</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.2 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.2) |
|
||||
|
|
@ -137,9 +138,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.2 |
|
||||
| 1.13.0 | N/A | 1.13.3 |
|
||||
| 1.13.0 | N/A | 1.13.4 |
|
||||
| 1.13.0 | N/A | 1.13.5 |
|
||||
|
||||
## Upgrade on Hosting platforms
|
||||
|
||||
|
|
|
|||
|
|
@ -114,7 +114,7 @@ Parameter | Description
|
|||
|
||||
#### Examples
|
||||
|
||||
> Note, the following example uses the `ttlInSeconds` field, which requires the [`ActorStateTTL` feature enabled]]({{< ref "support-preview-features.md" >}}).
|
||||
> Note, the following example uses the `ttlInSeconds` field, which requires the [`ActorStateTTL` feature enabled]({{< ref "support-preview-features.md" >}}).
|
||||
|
||||
```shell
|
||||
curl -X POST http://localhost:3500/v1.0/actors/stormtrooper/50/state \
|
||||
|
|
@ -202,6 +202,8 @@ A JSON object with the following fields:
|
|||
|-------|--------------|
|
||||
| `dueTime` | Specifies the time after which the reminder is invoked. Its format should be [time.ParseDuration](https://pkg.go.dev/time#ParseDuration)
|
||||
| `period` | Specifies the period between different invocations. Its format should be [time.ParseDuration](https://pkg.go.dev/time#ParseDuration) or ISO 8601 duration format with optional recurrence.
|
||||
| `ttl` | Sets time at or interval after which the timer or reminder will be expired and deleted. Its format should be [time.ParseDuration format](https://pkg.go.dev/time#ParseDuration), RFC3339 date format, or ISO 8601 duration format.
|
||||
| `data` | A string value and can be any related content. Content is returned when the reminder expires. For example this may be useful for returning a URL or anything related to the content.
|
||||
|
||||
`period` field supports `time.Duration` format and ISO 8601 format with some limitations. For `period`, only duration format of ISO 8601 duration `Rn/PnYnMnWnDTnHnMnS` is supported. `Rn/` specifies that the reminder will be invoked `n` number of times.
|
||||
|
||||
|
|
@ -210,7 +212,11 @@ A JSON object with the following fields:
|
|||
|
||||
If `Rn/` is not specified, the reminder will run an infinite number of times until deleted.
|
||||
|
||||
The following specifies a `dueTime` of 3 seconds and a period of 7 seconds.
|
||||
If only `ttl` and `dueTime` are set, the reminder will be accepted. However, only the `dueTime` takes effect. For example, the reminder triggers at `dueTime`, and `ttl` is ignored.
|
||||
|
||||
If `ttl`, `dueTime`, and `period` are set, the reminder first fires at `dueTime`, then repeatedly fires and expires according to `period` and `ttl`.
|
||||
|
||||
The following example specifies a `dueTime` of 3 seconds and a period of 7 seconds.
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -237,6 +243,25 @@ To configure the reminder to fire only once, the period should be set to empty s
|
|||
}
|
||||
```
|
||||
|
||||
When you specify the repetition number in both `period` and `ttl`, the timer/reminder is stopped when either condition is met. The following example has a timer with a `period` of 3 seconds (in ISO 8601 duration format) and a `ttl` of 20 seconds. This timer fires immediately after registration, then every 3 seconds after that for the duration of 20 seconds, after which it never fires again since the `ttl` was met
|
||||
|
||||
```json
|
||||
{
|
||||
"period":"PT3S",
|
||||
"ttl":"20s"
|
||||
}
|
||||
```
|
||||
|
||||
Need description for data.
|
||||
|
||||
```json
|
||||
{
|
||||
"data": "someData",
|
||||
"dueTime": "1m",
|
||||
"period": "20s"
|
||||
}
|
||||
```
|
||||
|
||||
#### HTTP Response Codes
|
||||
|
||||
Code | Description
|
||||
|
|
|
|||
|
|
@ -181,6 +181,23 @@ When subscribing to a topic, you can configure `bulkSubscribe` options. Refer to
|
|||
|
||||
Follow the instructions [here](https://learn.microsoft.com/azure/service-bus-messaging/service-bus-quickstart-portal) on setting up Azure Service Bus Queues.
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
Your queue must have the same name as the topic you are publishing to with Dapr. For example, if you are publishing to the pub/sub `"myPubsub"` on the topic `"orders"`, your queue must be named `"orders"`.
|
||||
If you are using a shared access policy to connect to the queue, that policy must be able to "manage" the queue. To work with a dead-letter queue, the policy must live on the Service Bus Namespace that contains both the main queue and the dead-letter queue.
|
||||
{{% /alert %}}
|
||||
|
||||
### Retry policy and dead-letter queues
|
||||
|
||||
By default, an Azure Service Bus Queue has a dead-letter queue. The messages are retried the amount given for `maxDeliveryCount`. The default `maxDeliveryCount` value defaults to 10, but can be set up to 2000. These retries happen very rapidly and the message is put in the dead-letter queue if no success is returned.
|
||||
|
||||
Dapr Pub/sub offers its own dead-letter queue concept that lets you control the retry policy and subscribe to the dead-letter queue through Dapr.
|
||||
1. Set up a separate queue as that dead-letter queue in the Azure Service Bus namespace, and a resilience policy that defines how to retry.
|
||||
1. Subscribe to the topic to get the failed messages and deal with them.
|
||||
|
||||
For example, setting up a dead-letter queue `orders-dlq` in the subscription and a resiliency policy lets you subscribe to the topic `orders-dlq` to handle failed messages.
|
||||
|
||||
For more details on setting up dead-letter queues, see the [dead-letter article]({{< ref pubsub-deadletter >}}).
|
||||
|
||||
## Related links
|
||||
|
||||
- [Basic schema for a Dapr component]({{< ref component-schema >}})
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
{{- if .Get "short" }}1.13{{ else if .Get "long" }}1.13.4{{ else if .Get "cli" }}1.13.0{{ else }}1.13.4{{ end -}}
|
||||
{{- if .Get "short" }}1.13{{ else if .Get "long" }}1.13.5{{ else if .Get "cli" }}1.13.0{{ else }}1.13.5{{ end -}}
|
||||
|
|
|
|||
|
|
@ -178,12 +178,12 @@
|
|||
}
|
||||
},
|
||||
"node_modules/braces": {
|
||||
"version": "3.0.2",
|
||||
"resolved": "https://registry.npmjs.org/braces/-/braces-3.0.2.tgz",
|
||||
"integrity": "sha512-b8um+L1RzM3WDSzvhm6gIz1yfTbBt6YTlcEKAvsmqCZZFw46z626lVj9j1yEPW33H5H+lBQpZMP1k8l+78Ha0A==",
|
||||
"version": "3.0.3",
|
||||
"resolved": "https://registry.npmjs.org/braces/-/braces-3.0.3.tgz",
|
||||
"integrity": "sha512-yQbXgO/OSZVD2IsiLlro+7Hf6Q18EJrKSEsdoMzKePKXct3gvD8oLcOQdIzGupr5Fj+EDe8gO/lxc1BzfMpxvA==",
|
||||
"dev": true,
|
||||
"dependencies": {
|
||||
"fill-range": "^7.0.1"
|
||||
"fill-range": "^7.1.1"
|
||||
},
|
||||
"engines": {
|
||||
"node": ">=8"
|
||||
|
|
@ -400,9 +400,9 @@
|
|||
}
|
||||
},
|
||||
"node_modules/fill-range": {
|
||||
"version": "7.0.1",
|
||||
"resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.0.1.tgz",
|
||||
"integrity": "sha512-qOo9F+dMUmC2Lcb4BbVvnKJxTPjCm+RRpe4gDuGrzkL7mEVl/djYSu2OdQ2Pa302N4oqkSg9ir6jaLWJ2USVpQ==",
|
||||
"version": "7.1.1",
|
||||
"resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.1.1.tgz",
|
||||
"integrity": "sha512-YsGpe3WHLK8ZYi4tWDg2Jy3ebRz2rXowDxnld4bkQB00cc/1Zw9AWnC0i9ztDJitivtQvaI9KaLyKrc+hBW0yg==",
|
||||
"dev": true,
|
||||
"dependencies": {
|
||||
"to-regex-range": "^5.0.1"
|
||||
|
|
|
|||
|
|
@ -7,4 +7,4 @@ spec:
|
|||
tracing:
|
||||
samplingRate: "1"
|
||||
zipkin:
|
||||
endpointAddress: "http://otel-collector.default.svc.cluster.local:9411/api/v2/spans"
|
||||
endpointAddress: "https://otel-collector.default.svc.cluster.local:9411/api/v2/spans"
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 338 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 355 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 78 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 134 KiB After Width: | Height: | Size: 131 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 154 KiB After Width: | Height: | Size: 52 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 139 KiB After Width: | Height: | Size: 61 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 133 KiB After Width: | Height: | Size: 42 KiB |
Binary file not shown.
Loading…
Reference in New Issue