mirror of https://github.com/dapr/docs.git
Hannah Hunter
GitHub
commit
66e95f97ff
|
|
@ -181,6 +181,9 @@ url_latest_version = "https://docs.dapr.io"
|
|||
[[params.versions]]
|
||||
version = "v1.9"
|
||||
url = "https://v1-9.docs.dapr.io"
|
||||
[[params.versions]]
|
||||
version = "v1.9"
|
||||
url = "https://v1-9.docs.dapr.io"
|
||||
[[params.versions]]
|
||||
version = "v1.8"
|
||||
url = "https://v1-8.docs.dapr.io"
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ description: >
|
|||
Dapr is a portable, event-driven runtime that makes it easy for any developer to build resilient, stateless and stateful applications that run on the cloud and edge and embraces the diversity of languages and developer frameworks.
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="1120" height="630" src="https://www.youtube.com/embed/9o9iDAgYBA8" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
<iframe width="1120" height="630" src="https://www.youtube-nocookie.com/embed/9o9iDAgYBA8" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
## Any language, any framework, anywhere
|
||||
|
|
|
|||
|
|
@ -3,49 +3,97 @@ type: docs
|
|||
title: "Contributing with GitHub Codespaces"
|
||||
linkTitle: "GitHub Codespaces"
|
||||
weight: 60
|
||||
description: "How to work with Dapr repos in GitHub Codespaces"
|
||||
description: "How to contribute to the Dapr project with GitHub Codespaces"
|
||||
aliases:
|
||||
- "/contributing/codespaces/"
|
||||
- "/developing-applications/ides/codespaces/"
|
||||
---
|
||||
|
||||
[GitHub Codespaces](https://github.com/features/codespaces) are the easiest way to get up and running for contributing to a Dapr repo. In as little as a single click, you can have an environment with all of the prerequisites ready to go in your browser.
|
||||
[GitHub Codespaces](https://github.com/features/codespaces) is the easiest way to get up and running for contributing to a Dapr repo. In as little as a single click, you can have an environment with all of the prerequisites ready to go in your browser.
|
||||
|
||||
## Features
|
||||
|
||||
- **Click and Run**: Get a dedicated and sandboxed environment with all of the required frameworks and packages ready to go.
|
||||
- **Usage-based Billing**: Only pay for the time you spend developing in the Codespace. Environments are spun down automatically when not in use.
|
||||
- **Portable**: Run in your browser or in Visual Studio Code
|
||||
- **Usage-based Billing**: Only pay for the time you spend developing in the Codespaces. Environments are spun down automatically when not in use.
|
||||
- **Portable**: Run in your browser or in Visual Studio Code, or connect to it using SSH.
|
||||
|
||||
## Open a Dapr repo in a Codespace
|
||||
|
||||
To open a Dapr repository in a Codespace simply select "Code" from the repo homepage and "Open with Codespaces":
|
||||
To open a Dapr repository in a Codespace, select "Code" from the repo homepage and "Open with Codespaces":
|
||||
|
||||
<img src="/images/codespaces-create.png" alt="Screenshot of creating a Dapr Codespace" width="300">
|
||||
|
||||
If you haven't already forked the repo, creating the Codespace will also create a fork for you and use it inside the Codespace.
|
||||
|
||||
### Supported repos
|
||||
## Supported repos
|
||||
|
||||
- [Dapr](https://github.com/dapr/dapr)
|
||||
- [Components-contrib](https://github.com/dapr/components-contrib)
|
||||
- [Python SDK](https://github.com/dapr/python-sdk)
|
||||
- [dapr/dapr](https://github.com/dapr/dapr)
|
||||
- [dapr/components-contrib](https://github.com/dapr/components-contrib)
|
||||
- [dapr/cli](https://github.com/dapr/cli)
|
||||
- [dapr/python-sdk](https://github.com/dapr/python-sdk)
|
||||
|
||||
### Developing Dapr Components in a Codespace
|
||||
## Developing Dapr Components in a Codespace
|
||||
|
||||
Developing a new Dapr component requires working with both the [components-contrib](https://github.com/dapr/components-contrib) and [dapr](https://github.com/dapr/dapr) repos together under the `$GOPATH` tree for testing purposes. To facilitate this, the `/go/src/github.com/dapr` folder in the components-contrib Codespace will already be set up with your fork of components-contrib, and a clone of the dapr repo as described in the [component development documentation](https://github.com/dapr/components-contrib/blob/master/docs/developing-component.md). A few things to note in this configuration:
|
||||
Developing a new Dapr component requires working with both the [dapr/components-contrib](https://github.com/dapr/components-contrib) and [dapr/dapr](https://github.com/dapr/dapr) repos. It is recommended to place both folders inside the `/workspaces` directory, side-by-side.
|
||||
|
||||
- The components-contrib and dapr repos only define Codespaces for the Linux amd64 environment at the moment.
|
||||
- The `/go/src/github.com/dapr/components-contrib` folder is a soft link to Codespace's default `/workspace/components-contrib` folder, so changes in one will be automatically reflected in the other.
|
||||
- Since the `/go/src/github.com/dapr/dapr` folder uses a clone of the official dapr repo rather than a fork, you will not be able to make a pull request from changes made in that folder directly. You can use the dapr Codespace separately for that PR, or if you would like to use the same Codespace for the dapr changes as well, you should remap the dapr repo origin to your fork in the components-contrib Codespace. For example, to use a dapr fork under `my-git-alias`:
|
||||
### If you created a Codespace from `dapr/dapr`
|
||||
|
||||
```bash
|
||||
cd /go/src/github.com/dapr/dapr
|
||||
git remote set-url origin https://github.com/my-git-alias/dapr
|
||||
git fetch
|
||||
git reset --hard
|
||||
If your Codespaces was started from the `dapr/dapr` repo or a fork of that, you will need to clone the `dapr/components-contrib` repository (or your fork of that) inside `/workspaces/components-contrib`.
|
||||
|
||||
First, make sure you've authenticated with the GitHub CLI:
|
||||
|
||||
```sh
|
||||
# Run this command and follow the prompts
|
||||
# Most users should accept the default choices
|
||||
gh auth login
|
||||
```
|
||||
|
||||
Clone the repo:
|
||||
|
||||
```sh
|
||||
# If you want to use your fork of dapr/components-contrib, replace this with your fork (e.g. "yourusername/components-contrib")
|
||||
# Make sure you've forked the repo before doing this
|
||||
REPO=dapr/components-contrib
|
||||
cd /workspaces
|
||||
gh repo clone "$REPO" /workspaces/components-contrib
|
||||
```
|
||||
|
||||
Then, add the folder to current workspace:
|
||||
|
||||
```sh
|
||||
code -a /workspaces/components-contrib
|
||||
```
|
||||
|
||||
### If you created a Codespace from `dapr/components-contrib`
|
||||
|
||||
If your Codespaces was started from the `dapr/components-contrib` repo or a fork of that, you will need to clone the `dapr/dapr` repository (or your fork of that) inside `/workspaces/dapr`.
|
||||
|
||||
First, make sure you've authenticated with the GitHub CLI:
|
||||
|
||||
```sh
|
||||
# Run this command and follow the prompts
|
||||
# Most users should accept the default choices
|
||||
gh auth login
|
||||
```
|
||||
|
||||
Clone the repo:
|
||||
|
||||
```sh
|
||||
# If you want to use your fork of dapr/dapr, replace this with your fork (e.g. "yourusername/dapr")
|
||||
# Make sure you've forked the repo before doing this
|
||||
REPO=dapr/dapr
|
||||
cd /workspaces
|
||||
gh repo clone "$REPO" /workspaces/dapr
|
||||
```
|
||||
|
||||
Then, add the folder to current workspace:
|
||||
|
||||
```sh
|
||||
code -a /workspaces/dapr
|
||||
```
|
||||
|
||||
|
||||
## Related links
|
||||
<!-- IGNORE_LINKS -->
|
||||
- [GitHub documentation](https://docs.github.com/github/developing-online-with-codespaces/about-codespaces)
|
||||
- [GitHub documentation](https://docs.github.com/codespaces/overview)
|
||||
<!-- END_IGNORE -->
|
||||
|
|
|
|||
|
|
@ -136,5 +136,5 @@ func reentrantCallHandler(w http.ResponseWriter, r *http.Request) {
|
|||
|
||||
Watch this [video](https://www.youtube.com/watch?v=QADHQ5v-gww&list=PLcip_LgkYwzuF-OV6zKRADoiBvUvGhkao&t=674s) on how to use actor reentrancy.
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/QADHQ5v-gww?start=674" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/QADHQ5v-gww?start=674" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -294,7 +294,7 @@ curl -X POST -H 'Content-Type: application/json' http://localhost:3601/v1.0/bind
|
|||
Watch this [video](https://www.youtube.com/watch?v=ysklxm81MTs&feature=youtu.be&t=1960) on how to use bi-directional output bindings.
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/ysklxm81MTs?start=1960" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/ysklxm81MTs?start=1960" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
## References
|
||||
|
|
|
|||
|
|
@ -268,8 +268,11 @@ has(event.data.important) && event.data.important == true
|
|||
Match deposits greater than $10,000:
|
||||
|
||||
```javascript
|
||||
event.type == "deposit" && event.data.amount > 10000
|
||||
event.type == "deposit" && int(event.data.amount) > 10000
|
||||
```
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
By default the numeric values are written as double-precision floating-point. There are no automatic arithmetic conversions for numeric values. In this case, if `event.data.amount` is not cast as integer, the match is not performed. For more information, see the [CEL documentation](https://github.com/google/cel-spec/blob/master/doc/langdef.md).
|
||||
{{% /alert %}}
|
||||
|
||||
Match multiple versions of a message:
|
||||
|
||||
|
|
@ -447,7 +450,7 @@ Currently, comparisons to time (e.g. before or after "now") are not supported.
|
|||
Watch [this video](https://www.youtube.com/watch?v=QqJgRmbH82I&t=1063s) on how to use message routing with pub/sub:
|
||||
|
||||
<p class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="688" height="430" src="https://www.youtube.com/embed/QqJgRmbH82I?start=1063" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
<iframe width="688" height="430" src="https://www.youtube-nocookie.com/embed/QqJgRmbH82I?start=1063" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</p>
|
||||
|
||||
## Next steps
|
||||
|
|
|
|||
|
|
@ -156,7 +156,7 @@ The table below shows which application is allowed to subscribe to the topics:
|
|||
## Demo
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/7VdWBBGcbHQ?start=513" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/7VdWBBGcbHQ?start=513" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
## Next steps
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ For details on how to set up a [secret store]({{< ref setup-secret-store.md >}})
|
|||
Watch [this video](https://youtu.be/j99RN_nxExA?start=2272) for a demo on how to use secret scoping with your application.
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="688" height="430" src="https://www.youtube.com/embed/j99RN_nxExA?start=2272" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
<iframe width="688" height="430" src="https://www.youtube-nocookie.com/embed/j99RN_nxExA?start=2272" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
## Scenario 1 : Deny access to all secrets for a secret store
|
||||
|
|
|
|||
|
|
@ -326,4 +326,5 @@ Watch this [video](https://youtu.be/B_vkXqptpXY?t=69) on how to use Dapr's gRPC
|
|||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/B_vkXqptpXY?start=69" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/B_vkXqptpXY?start=69" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Bridge to Kubernetes allows you to run and debug code on your development comput
|
|||
Bridge to Kubernetes supports debugging Dapr apps on your machine, while still having them interact with the services and applications running on your Kubernetes cluster. This example showcases Bridge to Kubernetes enabling a developer to debug the [distributed calculator quickstart](https://github.com/dapr/quickstarts/tree/master/tutorials/distributed-calculator):
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/rxwg-__otso" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/rxwg-__otso" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
{{% alert title="Isolation mode" color="warning" %}}
|
||||
|
|
|
|||
|
|
@ -222,7 +222,7 @@ Prerequisites:
|
|||
Watch an example from the Dapr community call:
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/7fP-0Ixmi-w?start=116" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/7fP-0Ixmi-w?start=116" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
## Additional resources
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ Users are able to leverage both OSM SMI traffic policies and Dapr capabilities o
|
|||
Watch the OSM team present the OSM and Dapr integration in the 05/18/2021 community call:
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/LSYyTL0nS8Y?start=1916" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/LSYyTL0nS8Y?start=1916" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
## Additional resources
|
||||
|
|
|
|||
|
|
@ -65,5 +65,5 @@ Using the VS Code extension, you can debug multiple Dapr applications at the sam
|
|||
Watch this [video](https://www.youtube.com/watch?v=OtbYCBt9C34&t=85) on how to use the Dapr VS Code extension:
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/OtbYCBt9C34?start=85" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/OtbYCBt9C34?start=85" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
|
@ -32,5 +32,5 @@ Dapr has pre-built Docker remote containers for NodeJS and C#. You can pick the
|
|||
Watch this [video](https://www.youtube.com/watch?v=D2dO4aGpHcg&t=120) on how to use the Dapr VS Code Remote Containers with your application.
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/D2dO4aGpHcg?start=120" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/D2dO4aGpHcg?start=120" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
|
@ -43,7 +43,7 @@ git clone https://github.com/dapr/quickstarts.git
|
|||
In a terminal window, from the root of the Quickstart directory, navigate to `order-processor` directory.
|
||||
|
||||
```bash
|
||||
cd ../service_invocation/python/http/order-processor
|
||||
cd service_invocation/python/http/order-processor
|
||||
```
|
||||
|
||||
Install dependencies:
|
||||
|
|
@ -63,7 +63,7 @@ dapr run --app-port 8001 --app-id order-processor --resources-path ../../../res
|
|||
In a new terminal window, from the root of the Quickstart directory, navigate to the `checkout` directory.
|
||||
|
||||
```bash
|
||||
cd ../service_invocation/python/http/checkout
|
||||
cd service_invocation/python/http/checkout
|
||||
```
|
||||
|
||||
Install dependencies:
|
||||
|
|
@ -145,31 +145,10 @@ Since the `resiliency.yaml` spec defines the `order-processor` service as a resi
|
|||
|
||||
In the `order-processor` window, stop the service:
|
||||
|
||||
{{< tabs "MacOs" "Windows" >}}
|
||||
|
||||
<!-- MacOS -->
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```script
|
||||
CMD + C
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
<!-- Windows -->
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```script
|
||||
CTRL + C
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
Once the first request fails, the retry policy titled `retryForever` is applied:
|
||||
|
||||
```bash
|
||||
|
|
@ -271,7 +250,7 @@ In a terminal window, from the root of the Quickstart directory,
|
|||
navigate to `order-processor` directory.
|
||||
|
||||
```bash
|
||||
cd ../service_invocation/javascript/http/order-processor
|
||||
cd service_invocation/javascript/http/order-processor
|
||||
```
|
||||
|
||||
Install dependencies:
|
||||
|
|
@ -502,7 +481,7 @@ navigate to `order-processor` directory.
|
|||
|
||||
|
||||
```bash
|
||||
cd ../service_invocation/csharp/http/order-processor
|
||||
cd service_invocation/csharp/http/order-processor
|
||||
```
|
||||
|
||||
Install dependencies:
|
||||
|
|
@ -524,7 +503,7 @@ In a new terminal window, from the root of the Quickstart directory,
|
|||
navigate to the `checkout` directory.
|
||||
|
||||
```bash
|
||||
cd ../service_invocation/csharp/http/checkout
|
||||
cd service_invocation/csharp/http/checkout
|
||||
```
|
||||
|
||||
Install dependencies:
|
||||
|
|
@ -736,7 +715,7 @@ In a terminal window, from the root of the Quickstart directory,
|
|||
navigate to `order-processor` directory.
|
||||
|
||||
```bash
|
||||
cd ../service_invocation/java/http/order-processor
|
||||
cd service_invocation/java/http/order-processor
|
||||
```
|
||||
|
||||
Install dependencies:
|
||||
|
|
@ -757,7 +736,7 @@ In a new terminal window, from the root of the Quickstart directory,
|
|||
navigate to the `checkout` directory.
|
||||
|
||||
```bash
|
||||
cd ../service_invocation/java/http/checkout
|
||||
cd service_invocation/java/http/checkout
|
||||
```
|
||||
|
||||
Install dependencies:
|
||||
|
|
@ -966,7 +945,7 @@ In a terminal window, from the root of the Quickstart directory,
|
|||
navigate to `order-processor` directory.
|
||||
|
||||
```bash
|
||||
cd ../service_invocation/go/http/order-processor
|
||||
cd service_invocation/go/http/order-processor
|
||||
```
|
||||
|
||||
Install dependencies:
|
||||
|
|
@ -987,7 +966,7 @@ In a new terminal window, from the root of the Quickstart directory,
|
|||
navigate to the `checkout` directory.
|
||||
|
||||
```bash
|
||||
cd ../service_invocation/go/http/checkout
|
||||
cd service_invocation/go/http/checkout
|
||||
```
|
||||
|
||||
Install dependencies:
|
||||
|
|
|
|||
|
|
@ -333,11 +333,13 @@ Run the `order-processor` service alongside a Dapr sidecar.
|
|||
dapr run --app-port 7001 --app-id order-processor --app-protocol http --dapr-http-port 3501 -- dotnet run
|
||||
```
|
||||
|
||||
Below is the working code block from the order processor's `Program.cs` file.
|
||||
|
||||
```csharp
|
||||
app.MapPost("/orders", async context => {
|
||||
var data = await context.Request.ReadFromJsonAsync<Order>();
|
||||
Console.WriteLine("Order received : " + data);
|
||||
await context.Response.WriteAsync(data.ToString());
|
||||
app.MapPost("/orders", (Order order) =>
|
||||
{
|
||||
Console.WriteLine("Order received : " + order);
|
||||
return order.ToString();
|
||||
});
|
||||
```
|
||||
|
||||
|
|
@ -363,7 +365,7 @@ Run the `checkout` service alongside a Dapr sidecar.
|
|||
dapr run --app-id checkout --app-protocol http --dapr-http-port 3500 -- dotnet run
|
||||
```
|
||||
|
||||
In the `checkout` service, you'll notice there's no need to rewrite your app code to use Dapr's service invocation. You can enable service invocation by simply adding the `dapr-app-id` header, which specifies the ID of the target service.
|
||||
In the Program.cs file for the `checkout` service, you'll notice there's no need to rewrite your app code to use Dapr's service invocation. You can enable service invocation by simply adding the `dapr-app-id` header, which specifies the ID of the target service.
|
||||
|
||||
```csharp
|
||||
var client = new HttpClient();
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@ scopes:
|
|||
### Community call demo
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/8W-iBDNvCUM?start=1763" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/8W-iBDNvCUM?start=1763" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
## Using namespaces with service invocation
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ Using Dapr, you can control how many requests and events will invoke your applic
|
|||
Watch this [video](https://youtu.be/yRI5g6o_jp8?t=1710) on how to control concurrency and rate limiting ".
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="764" height="430" src="https://www.youtube.com/embed/yRI5g6o_jp8?t=1710" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
<iframe width="764" height="430" src="https://www.youtube-nocookie.com/embed/yRI5g6o_jp8?t=1710" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
## Setting app-max-concurrency
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ All the certificates in the directory pointed by `SSL_CERT_DIR` are installed.
|
|||
Watch the demo on using installing SSL certificates and securely using the HTTP binding in community call 64:
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/M0VM7GlphAU?start=800" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/M0VM7GlphAU?start=800" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -379,5 +379,5 @@ spec:
|
|||
Watch this [video](https://youtu.be/j99RN_nxExA?t=1108) on how to apply access control list for service invocation.
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="688" height="430" src="https://www.youtube.com/embed/j99RN_nxExA?start=1108" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
<iframe width="688" height="430" src="https://www.youtube-nocookie.com/embed/j99RN_nxExA?start=1108" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
|
@ -14,6 +14,10 @@ description: "Follow these steps to upgrade Dapr on Kubernetes and ensure a smoo
|
|||
## Upgrade existing cluster to {{% dapr-latest-version long="true" %}}
|
||||
There are two ways to upgrade the Dapr control plane on a Kubernetes cluster using either the Dapr CLI or Helm.
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
Refer to the [Dapr version policy]({{< ref "support-release-policy.md#upgrade-paths" >}}) for guidance on which versions of Dapr can be upgraded to which versions.
|
||||
{{% /alert %}}
|
||||
|
||||
### Dapr CLI
|
||||
|
||||
The example below shows how to upgrade to version {{% dapr-latest-version long="true" %}}:
|
||||
|
|
|
|||
|
|
@ -8,18 +8,29 @@ description: "Configure the Dapr sidecar to mount Pod Volumes"
|
|||
|
||||
## Introduction
|
||||
|
||||
The Dapr sidecar can be configured to mount any Volume attached to the application Pod. These volumes can be accessed by the sidecar in _read-only_ or _read-write_ modes. If a Volume is configured to be mounted but it does not exist in the Pod, Dapr logs a warning and ignores it.
|
||||
For more information on different types of Volumes, check [Volumes | Kubernetes](https://kubernetes.io/docs/concepts/storage/volumes/).
|
||||
The Dapr sidecar can be configured to mount any Kubernetes Volume attached to the application Pod. These Volumes can be accessed by the `daprd` (sidecar) container in _read-only_ or _read-write_ modes. If a Volume is configured to be mounted but it does not exist in the Pod, Dapr logs a warning and ignores it.
|
||||
|
||||
For more information on different types of Volumes, check the [Kubernetes documentation](https://kubernetes.io/docs/concepts/storage/volumes/).
|
||||
|
||||
## Configuration
|
||||
|
||||
You can set the following annotations in your deployment YAML:
|
||||
|
||||
1. **dapr.io/volume-mounts**: for read-only volume mounts
|
||||
1. **dapr.io/volume-mounts-rw**: for read-write volume mounts
|
||||
|
||||
These annotations are comma separated pairs of `volume-name:path/in/container`. Make sure that the corresponding Volumes exist in the Pod spec.
|
||||
|
||||
In the snippet below, `my-volume1` and `my-volume2` are available inside the sidecar container at `/tmp/sample1` and `/tmp/sample2` respectively, in read-only mode. `my-volume3` is available inside the sidecar container at `/tmp/sample3` in read-write mode.
|
||||
Within the official container images, Dapr runs as a process with user ID (UID) `65532`. Make sure that folders and files inside the mounted Volume are writable or readable by user `65532` as appropriate.
|
||||
|
||||
Although you can mount a Volume in any folder within the Dapr sidecar container, prevent conflicts and ensure smooth operations going forward by placing all mountpoints within one of these two locations, or in a subfolder within them:
|
||||
|
||||
- `/mnt` is recommended for Volumes containing persistent data that the Dapr sidecar process can read and/or write.
|
||||
- `/tmp` is recommended for Volumes containing temporary data, such as scratch disks.
|
||||
|
||||
### Example
|
||||
|
||||
In the example Deployment resource below, `my-volume1` and `my-volume2` are available inside the sidecar container at `/mnt/sample1` and `/mnt/sample2` respectively, in read-only mode. `my-volume3` is available inside the sidecar container at `/tmp/sample3` in read-write mode.
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
|
|
@ -42,7 +53,7 @@ spec:
|
|||
dapr.io/enabled: "true"
|
||||
dapr.io/app-id: "myapp"
|
||||
dapr.io/app-port: "8000"
|
||||
dapr.io/volume-mounts: "my-volume1:/tmp/sample1,my-volume2:/tmp/sample2"
|
||||
dapr.io/volume-mounts: "my-volume1:/mnt/sample1,my-volume2:/mnt/sample2"
|
||||
dapr.io/volume-mounts-rw: "my-volume3:/tmp/sample3"
|
||||
spec:
|
||||
volumes:
|
||||
|
|
@ -57,52 +68,59 @@ spec:
|
|||
...
|
||||
```
|
||||
|
||||
## Example
|
||||
## Examples
|
||||
|
||||
### Custom secrets storage using local file secret store
|
||||
|
||||
Since any type of Kubernetes Volume can be attached to the sidecar, you can use the local file secret store to read secrets from a variety of places. For example, if you have a Network File Share (NFS) server running at `10.201.202.203`, with secrets stored at `/secrets/stage/secrets.json`, you can use that as a secrets storage.
|
||||
|
||||
1. Configure the application pod to mount the NFS and attach it to the Dapr sidecar.
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: myapp
|
||||
...
|
||||
spec:
|
||||
...
|
||||
template:
|
||||
...
|
||||
annotations:
|
||||
dapr.io/enabled: "true"
|
||||
dapr.io/app-id: "myapp"
|
||||
dapr.io/app-port: "8000"
|
||||
dapr.io/volume-mounts: "nfs-ss-vol:/usr/secrets"
|
||||
spec:
|
||||
volumes:
|
||||
- name: nfs-ss-vol
|
||||
nfs:
|
||||
server: 10.201.202.203
|
||||
path: /secrets/stage
|
||||
...
|
||||
```
|
||||
2. Point the local file secret store component to the attached file.
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: local-secret-store
|
||||
spec:
|
||||
type: secretstores.local.file
|
||||
version: v1
|
||||
1. Configure the application pod to mount the NFS and attach it to the Dapr sidecar.
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
- name: secretsFile
|
||||
value: /usr/secrets/secrets.json
|
||||
```
|
||||
3. Use the secrets.
|
||||
```
|
||||
GET http://localhost:<daprPort>/v1.0/secrets/local-secret-store/my-secret
|
||||
```
|
||||
name: myapp
|
||||
...
|
||||
spec:
|
||||
...
|
||||
template:
|
||||
...
|
||||
annotations:
|
||||
dapr.io/enabled: "true"
|
||||
dapr.io/app-id: "myapp"
|
||||
dapr.io/app-port: "8000"
|
||||
dapr.io/volume-mounts: "nfs-secrets-vol:/mnt/secrets"
|
||||
spec:
|
||||
volumes:
|
||||
- name: nfs-secrets-vol
|
||||
nfs:
|
||||
server: 10.201.202.203
|
||||
path: /secrets/stage
|
||||
...
|
||||
```
|
||||
|
||||
2. Point the local file secret store component to the attached file.
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: local-secret-store
|
||||
spec:
|
||||
type: secretstores.local.file
|
||||
version: v1
|
||||
metadata:
|
||||
- name: secretsFile
|
||||
value: /mnt/secrets/secrets.json
|
||||
```
|
||||
|
||||
3. Use the secrets.
|
||||
|
||||
```
|
||||
GET http://localhost:<daprPort>/v1.0/secrets/local-secret-store/my-secret
|
||||
```
|
||||
|
||||
## Related links
|
||||
|
||||
- [Dapr Kubernetes pod annotations spec]({{< ref arguments-annotations-overview.md >}})
|
||||
|
|
|
|||
|
|
@ -176,5 +176,5 @@ First you need to connect Prometheus as a data source to Grafana.
|
|||
## Example
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/8W-iBDNvCUM?start=2577" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/8W-iBDNvCUM?start=2577" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -113,7 +113,7 @@ dapr-prom-prometheus-server-694fd8d7c-q5d59 2/2 Running 0
|
|||
## Example
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/8W-iBDNvCUM?start=2577" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/8W-iBDNvCUM?start=2577" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
## References
|
||||
|
|
|
|||
|
|
@ -17,9 +17,10 @@ Timeouts can be used to early-terminate long-running operations. If you've excee
|
|||
- The operation in progress is terminated (if possible).
|
||||
- An error is returned.
|
||||
|
||||
Valid values are of the form `15s`, `2m`, `1h30m`, etc.
|
||||
Valid values are of the form accepted by Go's [time.ParseDuration](https://pkg.go.dev/time#ParseDuration), for example: `15s`, `2m`, `1h30m`.
|
||||
|
||||
Example:
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
policies:
|
||||
|
|
@ -36,10 +37,10 @@ With `retries`, you can define a retry strategy for failed operations, including
|
|||
|
||||
| Retry option | Description |
|
||||
| ------------ | ----------- |
|
||||
| `policy` | Determines the back-off and retry interval strategy. Valid values are `constant` and `exponential`. Defaults to `constant`. |
|
||||
| `duration` | Determines the time interval between retries. Default: `5s`. Only applies to the `constant` policy. Valid values are of the form `200ms`, `15s`, `2m`, etc. |
|
||||
| `maxInterval` | Determines the maximum interval between retries to which the `exponential` back-off policy can grow. Additional retries always occur after a duration of `maxInterval`. Defaults to `60s`. Valid values are of the form `5s`, `1m`, `1m30s`, etc |
|
||||
| `maxRetries` | The maximum number of retries to attempt. `-1` denotes an indefinite number of retries. Defaults to `-1`. |
|
||||
| `policy` | Determines the back-off and retry interval strategy. Valid values are `constant` and `exponential`.<br/>Defaults to `constant`. |
|
||||
| `duration` | Determines the time interval between retries. Only applies to the `constant` policy.<br/>Valid values are of the form `200ms`, `15s`, `2m`, etc.<br/> Defaults to `5s`.|
|
||||
| `maxInterval` | Determines the maximum interval between retries to which the `exponential` back-off policy can grow.<br/>Additional retries always occur after a duration of `maxInterval`. Defaults to `60s`. Valid values are of the form `5s`, `1m`, `1m30s`, etc |
|
||||
| `maxRetries` | The maximum number of retries to attempt. <br/>`-1` denotes an unlimited number of retries, while `0` means the request will not be retried (essentially behaving as if the retry policy were not set).<br/>Defaults to `-1`. |
|
||||
|
||||
The exponential back-off window uses the following formula:
|
||||
|
||||
|
|
@ -51,6 +52,7 @@ if BackOffDuration > maxInterval {
|
|||
```
|
||||
|
||||
Example:
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
policies:
|
||||
|
|
@ -67,20 +69,19 @@ spec:
|
|||
maxRetries: -1 # Retry indefinitely
|
||||
```
|
||||
|
||||
## Circuit breakers
|
||||
## Circuit Breakers
|
||||
|
||||
Circuit breakers (CBs) policies are used when other applications/services/components are experiencing elevated failure rates. CBs monitor the requests and shut off all traffic to the impacted service when a certain criteria is met. By doing this, CBs give the service time to recover from their outage instead of flooding them with events. The CB can also allow partial traffic through to see if the system has healed (half-open state). Once successful requests start to occur, the CB can close and allow traffic to resume.
|
||||
Circuit Breaker (CB) policies are used when other applications/services/components are experiencing elevated failure rates. CBs monitor the requests and shut off all traffic to the impacted service when a certain criteria is met ("open" state). By doing this, CBs give the service time to recover from their outage instead of flooding it with events. The CB can also allow partial traffic through to see if the system has healed ("half-open" state). Once requests resume being successful, the CB gets into "closed" state and allows traffic to completely resume.
|
||||
|
||||
| Retry option | Description |
|
||||
| ------------ | ----------- |
|
||||
| `maxRequests` | The maximum number of requests allowed to pass through when the CB is half-open (recovering from failure). Defaults to `1`. |
|
||||
| `interval` | The cyclical period of time used by the CB to clear its internal counts. If set to 0 seconds, this never clears. Defaults to `0s`. |
|
||||
| `timeout` | The period of the open state (directly after failure) until the CB switches to half-open. Defaults to `60s`. |
|
||||
| `trip` | A Common Expression Language (CEL) statement that is evaluated by the CB. When the statement evaluates to true, the CB trips and becomes open. Default is `consecutiveFailures > 5`. |
|
||||
| `circuitBreakerScope` | Specify whether circuit breaking state should be scoped to an individual actor ID, all actors across the actor type, or both. Possible values include `id`, `type`, or `both`|
|
||||
| `circuitBreakerCacheSize` | Specify a cache size for the number of CBs to keep in memory. The value should be larger than the expected number of active actor instances. Provide an integer value, for example `5000`. |
|
||||
| `trip` | A [Common Expression Language (CEL)](https://github.com/google/cel-spec) statement that is evaluated by the CB. When the statement evaluates to true, the CB trips and becomes open. Defaults to `consecutiveFailures > 5`. |
|
||||
|
||||
Example:
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
policies:
|
||||
|
|
@ -94,23 +95,23 @@ spec:
|
|||
|
||||
## Overriding default retries
|
||||
|
||||
Dapr provides default retries for certain request failures and transient errors. Within a resiliency spec, you have the option to override Dapr's default retry logic by defining policies with reserved, named keywords. For example, defining a policy with the name `DaprBuiltInServiceRetries`, overrides the default retries for failures between sidecars via service-to-service requests. Policy overrides are not applied to specific targets.
|
||||
Dapr provides default retries for certain request failures and transient errors. Within a resiliency spec, you have the option to override Dapr's default retry logic by defining policies with reserved, named keywords. For example, defining a policy with the name `DaprBuiltInServiceRetries`, overrides the default retries for failures between sidecars via service-to-service requests. Policy overrides are not applied to specific targets.
|
||||
|
||||
> Note: Although you can override default values with more robust retries, you cannot override with lesser values than the provided default value, or completely remove default retries. This prevents unexpected downtime.
|
||||
> Note: Although you can override default values with more robust retries, you cannot override with lesser values than the provided default value, or completely remove default retries. This prevents unexpected downtime.
|
||||
|
||||
Below is a table that describes Dapr's default retries and the policy keywords to override them:
|
||||
|
||||
| Capability | Override Keyword | Default Retry Behavior | Description |
|
||||
| ------------------ | ------------------------- | ------------------------------ | ----------------------------------------------------------------------------------------------------------- |
|
||||
| Service Invocation | DaprBuiltInServiceRetries | Per call retries are performed with a backoff interval of 1 second, up to a threshold of 3 times. | Sidecar-to-sidecar requests (a service invocation method call) that fail and result in a gRPC code `Unavailable` or `Unauthenticated` |
|
||||
| Actors | DaprBuiltInActorRetries | Per call retries are performed with a backoff interval of 1 second, up to a threshold of 3 times. | Sidecar-to-sidecar requests (an actor method call) that fail and result in a gRPC code `Unavailable` or `Unauthenticated` |
|
||||
| Actor Reminders | DaprBuiltInActorReminderRetries | Per call retries are performed with an exponential backoff with an initial interval of 500ms, up to a maximum of 60s for a duration of 15mins | Requests that fail to persist an actor reminder to a state store |
|
||||
| Initialization Retries | DaprBuiltInInitializationRetries | Per call retries are performed 3 times with an exponential backoff, an initial interval of 500ms and for a duration of 10s | Failures when making a request to an application to retrieve a given spec. For example, failure to retrieve a subscription, component or resiliency specification |
|
||||
| Capability | Override Keyword | Default Retry Behavior | Description |
|
||||
| ------------------ | ------------------------- | ------------------------------ | ----------------------------------------------------------------------------------------------------------- |
|
||||
| Service Invocation | DaprBuiltInServiceRetries | Per call retries are performed with a backoff interval of 1 second, up to a threshold of 3 times. | Sidecar-to-sidecar requests (a service invocation method call) that fail and result in a gRPC code `Unavailable` or `Unauthenticated` |
|
||||
| Actors | DaprBuiltInActorRetries | Per call retries are performed with a backoff interval of 1 second, up to a threshold of 3 times. | Sidecar-to-sidecar requests (an actor method call) that fail and result in a gRPC code `Unavailable` or `Unauthenticated` |
|
||||
| Actor Reminders | DaprBuiltInActorReminderRetries | Per call retries are performed with an exponential backoff with an initial interval of 500ms, up to a maximum of 60s for a duration of 15mins | Requests that fail to persist an actor reminder to a state store |
|
||||
| Initialization Retries | DaprBuiltInInitializationRetries | Per call retries are performed 3 times with an exponential backoff, an initial interval of 500ms and for a duration of 10s | Failures when making a request to an application to retrieve a given spec. For example, failure to retrieve a subscription, component or resiliency specification |
|
||||
|
||||
|
||||
The resiliency spec example below shows overriding the default retries for _all_ service invocation requests by using the reserved, named keyword 'DaprBuiltInServiceRetries'.
|
||||
|
||||
Also defined is a retry policy called 'retryForever' that is only applied to the appB target. appB uses the 'retryForever' retry policy, while all other application service invocation retry failures use the overridden 'DaprBuiltInServiceRetries' default policy.
|
||||
Also defined is a retry policy called 'retryForever' that is only applied to the appB target. appB uses the 'retryForever' retry policy, while all other application service invocation retry failures use the overridden 'DaprBuiltInServiceRetries' default policy.
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
|
|
@ -134,37 +135,37 @@ spec:
|
|||
|
||||
## Setting default policies
|
||||
|
||||
In resiliency you can set default policies, which have a broad scope. This is done through reserved keywords that let Dapr know when to apply the policy. There are 3 default policies types:
|
||||
In resiliency you can set default policies, which have a broad scope. This is done through reserved keywords that let Dapr know when to apply the policy. There are 3 default policy types:
|
||||
|
||||
- DefaultRetryPolicy
|
||||
- DefaultTimeoutPolicy
|
||||
- DefaultCircuitBreakerPolicy
|
||||
- `DefaultRetryPolicy`
|
||||
- `DefaultTimeoutPolicy`
|
||||
- `DefaultCircuitBreakerPolicy`
|
||||
|
||||
If these policies are defined, they are used for every operation to a service, application, or component. They can also be modified to be more specific through the appending of additional keywords. The specific policies follow the following pattern, `Default%sRetryPolicy`, `Default%sTimeoutPolicy`, and `Default%sCircuitBreakerPolicy`. Where the `%s` is replaced by a target of the policy.
|
||||
|
||||
Below is a table of all possible default policy keywords and how they translate into a policy name.
|
||||
|
||||
| Keyword | Target Operation | Example Policy Name |
|
||||
| ------------------------------ | ---------------------------------------------------- | --------------------------------------------------------- |
|
||||
| App | Service invocation. | DefaultAppRetryPolicy |
|
||||
| Actor | Actor invocation. | DefaultActorTimeoutPolicy |
|
||||
| Component | All component operations. | DefaultComponentCircuitBreakerPolicy |
|
||||
| ComponentInbound | All inbound component operations. | DefaultComponentInboundRetryPolicy |
|
||||
| ComponentOutbound | All outbound component operations. | DefaultComponentOutboundTimeoutPolicy |
|
||||
| StatestoreComponentOutbound | All statestore component operations. | DefaultStatestoreComponentOutboundCircuitBreakerPolicy |
|
||||
| PubsubComponentOutbound | All outbound pubusub (publish) component operations. | DefaultPubsubComponentOutboundRetryPolicy |
|
||||
| PubsubComponentInbound | All inbound pubsub (subscribe) component operations. | DefaultPubsubComponentInboundTimeoutPolicy |
|
||||
| BindingComponentOutbound | All outbound binding (invoke) component operations. | DefaultBindingComponentOutboundCircuitBreakerPolicy |
|
||||
| BindingComponentInbound | All inbound binding (read) component operations. | DefaultBindingComponentInboundRetryPolicy |
|
||||
| SecretstoreComponentOutbound | All secretstore component operations. | DefaultSecretstoreComponentTimeoutPolicy |
|
||||
| ConfigurationComponentOutbound | All configuration component operations. | DefaultConfigurationComponentOutboundCircuitBreakerPolicy |
|
||||
| LockComponentOutbound | All lock component operations. | DefaultLockComponentOutboundRetryPolicy |
|
||||
| Keyword | Target Operation | Example Policy Name |
|
||||
| -------------------------------- | ---------------------------------------------------- | ----------------------------------------------------------- |
|
||||
| `App` | Service invocation. | `DefaultAppRetryPolicy` |
|
||||
| `Actor` | Actor invocation. | `DefaultActorTimeoutPolicy` |
|
||||
| `Component` | All component operations. | `DefaultComponentCircuitBreakerPolicy` |
|
||||
| `ComponentInbound` | All inbound component operations. | `DefaultComponentInboundRetryPolicy` |
|
||||
| `ComponentOutbound` | All outbound component operations. | `DefaultComponentOutboundTimeoutPolicy` |
|
||||
| `StatestoreComponentOutbound` | All statestore component operations. | `DefaultStatestoreComponentOutboundCircuitBreakerPolicy` |
|
||||
| `PubsubComponentOutbound` | All outbound pubusub (publish) component operations. | `DefaultPubsubComponentOutboundRetryPolicy` |
|
||||
| `PubsubComponentInbound` | All inbound pubsub (subscribe) component operations. | `DefaultPubsubComponentInboundTimeoutPolicy` |
|
||||
| `BindingComponentOutbound` | All outbound binding (invoke) component operations. | `DefaultBindingComponentOutboundCircuitBreakerPolicy` |
|
||||
| `BindingComponentInbound` | All inbound binding (read) component operations. | `DefaultBindingComponentInboundRetryPolicy` |
|
||||
| `SecretstoreComponentOutbound` | All secretstore component operations. | `DefaultSecretstoreComponentTimeoutPolicy` |
|
||||
| `ConfigurationComponentOutbound` | All configuration component operations. | `DefaultConfigurationComponentOutboundCircuitBreakerPolicy` |
|
||||
| `LockComponentOutbound` | All lock component operations. | `DefaultLockComponentOutboundRetryPolicy` |
|
||||
|
||||
### Policy hierarchy resolution
|
||||
|
||||
Default policies are applied if the operation being executed matches the policy type and if there is no more specific policy targeting it. For each target type (app, actor, and component), the policy with the highest priority is a Named Policy, one that targets that construct specifically.
|
||||
|
||||
If none exists, the policies are applied from most specific to most broad.
|
||||
If none exists, the policies are applied from most specific to most broad.
|
||||
|
||||
#### How default policies and built-in retries work together
|
||||
|
||||
|
|
@ -195,16 +196,19 @@ Policy resolution hierarchy for components, from most specific to most broad:
|
|||
As an example, take the following solution consisting of three applications, three components and two actor types:
|
||||
|
||||
Applications:
|
||||
|
||||
- AppA
|
||||
- AppB
|
||||
- AppC
|
||||
|
||||
Components:
|
||||
|
||||
- Redis Pubsub: pubsub
|
||||
- Redis statestore: statestore
|
||||
- CosmosDB Statestore: actorstore
|
||||
|
||||
Actors:
|
||||
|
||||
- EventActor
|
||||
- SummaryActor
|
||||
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ Policies can be applied for `outbound` operations (calls to the Dapr sidecar) an
|
|||
`outbound` operations are calls from the sidecar to a component, such as:
|
||||
|
||||
- Persisting or retrieving state.
|
||||
- Publishing a message.
|
||||
- Publishing a message on a PubSub component.
|
||||
- Invoking an output binding.
|
||||
|
||||
> Some components may have built-in retry capabilities and are configured on a per-component basis.
|
||||
|
|
@ -66,7 +66,7 @@ spec:
|
|||
|
||||
`inbound` operations are calls from the sidecar to your application, such as:
|
||||
|
||||
- Subscriptions when delivering a message.
|
||||
- PubSub subscriptions when delivering a message.
|
||||
- Input bindings.
|
||||
|
||||
> Some components may have built-in retry capabilities and are configured on a per-component basis.
|
||||
|
|
@ -108,15 +108,13 @@ spec:
|
|||
|
||||
With the `actors` target, you can apply `retry`, `timeout`, and `circuitBreaker` policies to actor operations.
|
||||
|
||||
When using a `circuitBreaker` policy, you can specify whether circuit breaking state should be scoped to:
|
||||
When using a `circuitBreaker` policy for the `actors` target, you can specify how circuit breaking state should be scoped by using `circuitBreakerScope`:
|
||||
|
||||
- An individual actor ID.
|
||||
- All actors across the actor type.
|
||||
- Both.
|
||||
- `id`: an individual actor ID
|
||||
- `type`: all actors of a given actor type
|
||||
- `both`: both of the above
|
||||
|
||||
Specify `circuitBreakerScope` with values `id`, `type`, or `both`.
|
||||
|
||||
You can specify a cache size for the number of circuit breakers to keep in memory. Do this by specifying `circuitBreakerCacheSize` and providing an integer value, e.g. `5000`.
|
||||
You can also specify a cache size for the number of circuit breakers to keep in memory with the `circuitBreakerCacheSize` property, providing an integer value, e.g. `5000`.
|
||||
|
||||
Example
|
||||
|
||||
|
|
|
|||
|
|
@ -295,7 +295,7 @@ You will experience potential downtime due to mismatching certificates until all
|
|||
### Kubernetes video demo
|
||||
Watch this video to show how to update mTLS certificates on Kubernetes
|
||||
|
||||
<iframe width="1280" height="720" src="https://www.youtube.com/embed/_U9wJqq-H1g" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
<iframe width="1280" height="720" src="https://www.youtube-nocookie.com/embed/_U9wJqq-H1g" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
### Set up monitoring for Dapr control plane mTLS certificate expiration
|
||||
|
||||
|
|
@ -489,5 +489,5 @@ By default, system services will look for the credentials in `/var/run/dapr/cred
|
|||
Watch this [video](https://www.youtube.com/watch?v=Hkcx9kBDrAc&feature=youtu.be&t=1400) on how to perform certificate rotation if your certicates are expiring.
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/Hkcx9kBDrAc?start=1400"></iframe>
|
||||
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/Hkcx9kBDrAc?start=1400"></iframe>
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ When the middleware is enabled any method invocation through Dapr needs to be au
|
|||
|
||||
The main difference between the two flows is that the `Authorization Code Grant flow` needs user interaction and authorizes a user where the `Client Credentials Grant flow` doesn't need a user interaction and authorizes a service/application.
|
||||
|
||||
## Register your application with a authorization server
|
||||
## Register your application with an authorization server
|
||||
|
||||
Different authorization servers provide different application registration experiences. Here are some samples:
|
||||
<!-- IGNORE_LINKS -->
|
||||
|
|
|
|||
|
|
@ -72,6 +72,10 @@ The table below shows the versions of Dapr releases that have been tested togeth
|
|||
|
||||
After the 1.0 release of the runtime there may be situations where it is necessary to explicitly upgrade through an additional release to reach the desired target. For example, an upgrade from v1.0 to v1.2 may need to pass through v1.1.
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
Dapr only has a seamless guarantee when upgrading patch versions in a single minor version, or upgrading from one minor version to the next. For example, upgrading from `v1.6.0` to `v1.6.4` or `v1.6.4` to `v1.7.0` is guaranteed tested. Upgrading more than one minor version at a time is untested and treated as best effort.
|
||||
{{% /alert %}}
|
||||
|
||||
The table below shows the tested upgrade paths for the Dapr runtime. Any other combinations of upgrades have not been tested.
|
||||
|
||||
General guidance on upgrading can be found for [self hosted mode]({{< ref self-hosted-upgrade >}}) and [Kubernetes]({{< ref kubernetes-upgrade >}}) deployments. It is best to review the target version release notes for specific guidance.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,205 @@
|
|||
---
|
||||
type: docs
|
||||
title: "MQTT"
|
||||
linkTitle: "MQTT"
|
||||
description: "Detailed documentation on the MQTT pubsub component"
|
||||
aliases:
|
||||
- "/operations/components/setup-pubsub/supported-pubsub/setup-mqtt/"
|
||||
---
|
||||
|
||||
## Component format
|
||||
|
||||
To setup MQTT pubsub create a component of type `pubsub.mqtt`. See [this guide]({{< ref "howto-publish-subscribe.md#step-1-setup-the-pubsub-component" >}}) on how to create and apply a pubsub configuration
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: mqtt-pubsub
|
||||
spec:
|
||||
type: pubsub.mqtt
|
||||
version: v1
|
||||
metadata:
|
||||
- name: url
|
||||
value: "tcp://[username][:password]@host.domain[:port]"
|
||||
- name: qos
|
||||
value: 1
|
||||
- name: retain
|
||||
value: "false"
|
||||
- name: cleanSession
|
||||
value: "false"
|
||||
```
|
||||
|
||||
{{% alert title="Warning" color="warning" %}}
|
||||
The above example uses secrets as plain strings. It is recommended to use a secret store for the secrets as described [here]({{< ref component-secrets.md >}}).
|
||||
{{% /alert %}}
|
||||
|
||||
## Spec metadata fields
|
||||
|
||||
| Field | Required | Details | Example |
|
||||
|--------------------|:--------:|---------|---------|
|
||||
| url | Y | Address of the MQTT broker. Can be `secretKeyRef` to use a secret reference. <br> Use the **`tcp://`** URI scheme for non-TLS communication. <br> Use the **`ssl://`** URI scheme for TLS communication. | `"tcp://[username][:password]@host.domain[:port]"`
|
||||
| consumerID | N | The client ID used to connect to the MQTT broker for the consumer connection. Defaults to the Dapr app ID.<br>Note: if `producerID` is not set, `-consumer` is appended to this value for the consumer connection | `"myMqttClientApp"`
|
||||
| producerID | N | The client ID used to connect to the MQTT broker for the producer connection. Defaults to `{consumerID}-producer`. | `"myMqttProducerApp"`
|
||||
| qos | N | Indicates the Quality of Service Level (QoS) of the message ([more info](https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels/)). Defaults to `1`. |`0`, `1`, `2`
|
||||
| retain | N | Defines whether the message is saved by the broker as the last known good value for a specified topic. Defaults to `"false"`. | `"true"`, `"false"`
|
||||
| cleanSession | N | Sets the `clean_session` flag in the connection message to the MQTT broker if `"true"` ([more info](http://www.steves-internet-guide.com/mqtt-clean-sessions-example/)). Defaults to `"false"`. | `"true"`, `"false"`
|
||||
| caCert | Required for using TLS | Certificate Authority (CA) certificate in PEM format for verifying server TLS certificates. | `"-----BEGIN CERTIFICATE-----\n<base64-encoded DER>\n-----END CERTIFICATE-----"`
|
||||
| clientCert | Required for using TLS | TLS client certificate in PEM format. Must be used with `clientKey`. | `"-----BEGIN CERTIFICATE-----\n<base64-encoded DER>\n-----END CERTIFICATE-----"`
|
||||
| clientKey | Required for using TLS | TLS client key in PEM format. Must be used with `clientCert`. Can be `secretKeyRef` to use a secret reference. | `"-----BEGIN RSA PRIVATE KEY-----\n<base64-encoded PKCS8>\n-----END RSA PRIVATE KEY-----"`
|
||||
|
||||
### Enabling message delivery retries
|
||||
|
||||
The MQTT pub/sub component has no built-in support for retry strategies. This means that the sidecar sends a message to the service only once. If the service marks the message as not processed, the message won't be acknowledged back to the broker. Only if broker resends the message, would it would be retried.
|
||||
|
||||
To make Dapr use more spohisticated retry policies, you can apply a [retry resiliency policy]({{< ref "policies.md#retries" >}}) to the MQTT pub/sub component.
|
||||
|
||||
There is a crucial difference between the two ways of retries:
|
||||
|
||||
1. Re-delivery of unacknowledged messages is completely dependent on the broker. Dapr does not guarantee it. Some brokers like [emqx](https://www.emqx.io/), [vernemq](https://vernemq.com/) etc. support it but it not a part of [MQTT3 spec](http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718103).
|
||||
|
||||
2. Using a [retry resiliency policy]({{< ref "policies.md#retries" >}}) makes the same Dapr sidecar retry redelivering the messages. So it is the same Dapr sidecar and the same app receiving the same message.
|
||||
|
||||
### Communication using TLS
|
||||
|
||||
To configure communication using TLS, ensure that the MQTT broker (e.g. mosquitto) is configured to support certificates and provide the `caCert`, `clientCert`, `clientKey` metadata in the component configuration. For example:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: mqtt-pubsub
|
||||
spec:
|
||||
type: pubsub.mqtt
|
||||
version: v1
|
||||
metadata:
|
||||
- name: url
|
||||
value: "ssl://host.domain[:port]"
|
||||
- name: qos
|
||||
value: 1
|
||||
- name: retain
|
||||
value: "false"
|
||||
- name: cleanSession
|
||||
value: "false"
|
||||
- name: caCert
|
||||
value: ${{ myLoadedCACert }}
|
||||
- name: clientCert
|
||||
value: ${{ myLoadedClientCert }}
|
||||
- name: clientKey
|
||||
secretKeyRef:
|
||||
name: myMqttClientKey
|
||||
key: myMqttClientKey
|
||||
auth:
|
||||
secretStore: <SECRET_STORE_NAME>
|
||||
```
|
||||
|
||||
Note that while the `caCert` and `clientCert` values may not be secrets, they can be referenced from a Dapr secret store as well for convenience.
|
||||
|
||||
### Consuming a shared topic
|
||||
|
||||
When consuming a shared topic, each consumer must have a unique identifier. By default, the application ID is used to uniquely identify each consumer and publisher. In self-hosted mode, invoking each `dapr run` with a different application ID is sufficient to have them consume from the same shared topic. However, on Kubernetes, multiple instances of an application pod will share the same application ID, prohibiting all instances from consuming the same topic. To overcome this, configure the component's `consumerID` metadata with a `{uuid}` tag, which will give each instance a randomly generated `consumerID` value on start up. For example:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: mqtt-pubsub
|
||||
spec:
|
||||
type: pubsub.mqtt
|
||||
version: v1
|
||||
metadata:
|
||||
- name: consumerID
|
||||
value: "{uuid}"
|
||||
- name: url
|
||||
value: "tcp://admin:public@localhost:1883"
|
||||
- name: qos
|
||||
value: 1
|
||||
- name: retain
|
||||
value: "false"
|
||||
- name: cleanSession
|
||||
value: "true"
|
||||
```
|
||||
|
||||
{{% alert title="Warning" color="warning" %}}
|
||||
The above example uses secrets as plain strings. It is recommended to use a secret store for the secrets as described [here]({{< ref component-secrets.md >}}).
|
||||
{{% /alert %}}
|
||||
|
||||
Note that in the case, the value of the consumer ID is random every time Dapr restarts, so we are setting `cleanSession` to true as well.
|
||||
|
||||
## Create a MQTT broker
|
||||
|
||||
{{< tabs "Self-Hosted" "Kubernetes">}}
|
||||
|
||||
{{% codetab %}}
|
||||
You can run a MQTT broker [locally using Docker](https://hub.docker.com/_/eclipse-mosquitto):
|
||||
|
||||
```bash
|
||||
docker run -d -p 1883:1883 -p 9001:9001 --name mqtt eclipse-mosquitto:1.6
|
||||
```
|
||||
|
||||
You can then interact with the server using the client port: `mqtt://localhost:1883`
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
You can run a MQTT broker in kubernetes using following yaml:
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: mqtt-broker
|
||||
labels:
|
||||
app-name: mqtt-broker
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app-name: mqtt-broker
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app-name: mqtt-broker
|
||||
spec:
|
||||
containers:
|
||||
- name: mqtt
|
||||
image: eclipse-mosquitto:1.6
|
||||
imagePullPolicy: IfNotPresent
|
||||
ports:
|
||||
- name: default
|
||||
containerPort: 1883
|
||||
protocol: TCP
|
||||
- name: websocket
|
||||
containerPort: 9001
|
||||
protocol: TCP
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: mqtt-broker
|
||||
labels:
|
||||
app-name: mqtt-broker
|
||||
spec:
|
||||
type: ClusterIP
|
||||
selector:
|
||||
app-name: mqtt-broker
|
||||
ports:
|
||||
- port: 1883
|
||||
targetPort: default
|
||||
name: default
|
||||
protocol: TCP
|
||||
- port: 9001
|
||||
targetPort: websocket
|
||||
name: websocket
|
||||
protocol: TCP
|
||||
```
|
||||
|
||||
You can then interact with the server using the client port: `tcp://mqtt-broker.default.svc.cluster.local:1883`
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
## Related links
|
||||
|
||||
- [Basic schema for a Dapr component]({{< ref component-schema >}})
|
||||
- Read [this guide]({{< ref "howto-publish-subscribe.md#step-2-publish-a-topic" >}}) for instructions on configuring pub/sub components
|
||||
- [Pub/Sub building block]({{< ref pubsub >}})
|
||||
|
|
@ -32,10 +32,6 @@ spec:
|
|||
value: "default"
|
||||
- name: persistent
|
||||
value: "true"
|
||||
- name: backOffPolicy
|
||||
value: "constant"
|
||||
- name: backOffMaxRetries
|
||||
value: "-1"
|
||||
- name: disableBatching
|
||||
value: "false"
|
||||
- name: <topic-name>.jsonschema # sets a json schema validation for the configured topic
|
||||
|
|
@ -71,15 +67,7 @@ spec:
|
|||
| token | N | Enable Authentication. | [How to create pulsar token](https://pulsar.apache.org/docs/en/security-jwt/#generate-tokens)|
|
||||
| tenant | N | The topic tenant within the instance. Tenants are essential to multi-tenancy in Pulsar, and spread across clusters. Default: `"public"` | `"public"` |
|
||||
| namespace | N | The administrative unit of the topic, which acts as a grouping mechanism for related topics. Default: `"default"` | `"default"`
|
||||
| persistent | N | Pulsar supports two kind of topics: [persistent](https://pulsar.apache.org/docs/en/concepts-architecture-overview#persistent-storage) and [non-persistent](https://pulsar.apache.org/docs/en/concepts-messaging/#non-persistent-topics). With persistent topics, all messages are durably persisted on disks (if the broker is not standalone, messages are durably persisted on multiple disks), whereas data for non-persistent topics is not persisted to storage disks. Note: the default retry behavior is to retry until it succeeds, so when you use a non-persistent theme, you can reduce or prohibit retries by defining `backOffMaxRetries` to `0`. Default: `"true"` | `"true"`, `"false"`
|
||||
| backOffPolicy | N | Retry policy, `"constant"` is a backoff policy that always returns the same backoff delay. `"exponential"` is a backoff policy that increases the backoff period for each retry attempt using a randomization function that grows exponentially. Defaults to `"constant"`. | `constant`、`exponential` |
|
||||
| backOffDuration | N | The fixed interval only takes effect when the `backOffPolicy` is `"constant"`. There are two valid formats, one is the fraction with a unit suffix format, and the other is the pure digital format that is processed as milliseconds. Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h". Defaults to `"5s"`. | `"5s"`、`"5000"` |
|
||||
| backOffInitialInterval | N | The backoff initial interval on retry. Only takes effect when the `backOffPolicy` is `"exponential"`. There are two valid formats, one is the fraction with a unit suffix format, and the other is the pure digital format that is processed as milliseconds. Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h". Defaults to `"500"` | `"50"` |
|
||||
| backOffMaxInterval | N | The backoff initial interval on retry. Only takes effect when the `backOffPolicy` is `"exponential"`. There are two valid formats, one is the fraction with a unit suffix format, and the other is the pure digital format that is processed as milliseconds. Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h". Defaults to `"60s"` | `"60000"` |
|
||||
| backOffMaxRetries | N | The maximum number of retries to process the message before returning an error. Defaults to `"0"` which means the component will not retry processing the message. `"-1"` will retry indefinitely until the message is processed or the application is shutdown. Any positive number is treated as the maximum retry count. | `"3"` |
|
||||
| backOffRandomizationFactor | N | Randomization factor, between 1 and 0, including 0 but not 1. Randomized interval = RetryInterval * (1 ± backOffRandomizationFactor). Defaults to `"0.5"`. | `"0.5"` |
|
||||
| backOffMultiplier | N | Backoff multiplier for the policy. Increments the interval by multiplying it with the multiplier. Defaults to `"1.5"` | `"1.5"` |
|
||||
| backOffMaxElapsedTime | N | After MaxElapsedTime the ExponentialBackOff returns Stop. There are two valid formats, one is the fraction with a unit suffix format, and the other is the pure digital format that is processed as milliseconds. Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h". Defaults to `"15m"` | `"15m"` |
|
||||
| persistent | N | Pulsar supports two kinds of topics: [persistent](https://pulsar.apache.org/docs/en/concepts-architecture-overview#persistent-storage) and [non-persistent](https://pulsar.apache.org/docs/en/concepts-messaging/#non-persistent-topics). With persistent topics, all messages are durably persisted on disks (if the broker is not standalone, messages are durably persisted on multiple disks), whereas data for non-persistent topics is not persisted to storage disks.
|
||||
| disableBatching | N | disable batching.When batching enabled default batch delay is set to 10 ms and default batch size is 1000 messages,Setting `disableBatching: true` will make the producer to send messages individually. Default: `"false"` | `"true"`, `"false"`|
|
||||
| batchingMaxPublishDelay | N | batchingMaxPublishDelay set the time period within which the messages sent will be batched,if batch messages are enabled. If set to a non zero value, messages will be queued until this time interval or batchingMaxMessages (see below) or batchingMaxSize (see below). There are two valid formats, one is the fraction with a unit suffix format, and the other is the pure digital format that is processed as milliseconds. Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h". Default: `"10ms"` | `"10ms"`, `"10"`|
|
||||
| batchingMaxMessages | N | batchingMaxMessages set the maximum number of messages permitted in a batch.If set to a value greater than 1, messages will be queued until this threshold is reached or batchingMaxSize (see below) has been reached or the batch interval has elapsed. Default: `"1000"` | `"1000"`|
|
||||
|
|
@ -87,6 +75,10 @@ spec:
|
|||
| <topic-name>.jsonschema | N | Enforces JSON schema validation for the configured topic. |
|
||||
| <topic-name>.avroschema | N | Enforces Avro schema validation for the configured topic. |
|
||||
|
||||
### Enabling message delivery retries
|
||||
|
||||
The Pulsar pub/sub component has no built-in support for retry strategies. This means that sidecar sends a message to the service only once and is not retried in case of failures. To make Dapr use more spohisticated retry policies, you can apply a [retry resiliency policy]({{< ref "policies.md#retries" >}}) to the MQTT pub/sub component. Note that it will be the same Dapr sidecar retrying the redelivery the message to the same app instance and not other instances.
|
||||
|
||||
### Delay queue
|
||||
|
||||
When invoking the Pulsar pub/sub, it's possible to provide an optional delay queue by using the `metadata` query parameters in the request url.
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ If you wish to use Redis as an actor store, append the following to the yaml.
|
|||
| enableTLS | N | If the Redis instance supports TLS with public certificates, can be configured to be enabled or disabled. Defaults to `"false"` | `"true"`, `"false"`
|
||||
| maxRetries | N | Maximum number of retries before giving up. Defaults to `3` | `5`, `10`
|
||||
| maxRetryBackoff | N | Maximum backoff between each retry. Defaults to `2` seconds; `"-1"` disables backoff. | `3000000000`
|
||||
| failover | N | Property to enabled failover configuration. Needs sentinalMasterName to be set. The redisHost should be the sentinel host address. See [Redis Sentinel Documentation](https://redis.io/docs/manual/sentinel/). Defaults to `"false"` | `"true"`, `"false"`
|
||||
| failover | N | Property to enabled failover configuration. Needs sentinelMasterName to be set. The redisHost should be the sentinel host address. See [Redis Sentinel Documentation](https://redis.io/docs/manual/sentinel/). Defaults to `"false"` | `"true"`, `"false"`
|
||||
| sentinelMasterName | N | The sentinel master name. See [Redis Sentinel Documentation](https://redis.io/docs/manual/sentinel/) | `""`, `"127.0.0.1:6379"`
|
||||
| redeliverInterval | N | The interval between checking for pending messages to redelivery. Defaults to `"60s"`. `"0"` disables redelivery. | `"30s"`
|
||||
| processingTimeout | N | The amount time a message must be pending before attempting to redeliver it. Defaults to `"15s"`. `"0"` disables redelivery. | `"30s"`
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
Subproject commit 915260bf2399999fe82307b31e5c70c1dc42c3ef
|
||||
Subproject commit f9571d5b34f5b1f41a06ba9b9b4da0c2c0f3fb36
|
||||
Loading…
Reference in New Issue