diff --git a/daprdocs/content/en/concepts/components-concept.md b/daprdocs/content/en/concepts/components-concept.md index e6e1253f68d..48ecbb88272 100644 --- a/daprdocs/content/en/concepts/components-concept.md +++ b/daprdocs/content/en/concepts/components-concept.md @@ -11,7 +11,7 @@ Dapr uses a modular design where functionality is delivered as a component. Each You can contribute implementations and extend Dapr's component interfaces capabilities via: - The [components-contrib repository](https://github.com/dapr/components-contrib) -- [Pluggable components]({{}}). +- [Pluggable components]({{}}). A building block can use any combination of components. For example, the [actors]({{}}) and the [state management]({{}}) building blocks both use [state components](https://github.com/dapr/components-contrib/tree/master/state). diff --git a/daprdocs/content/en/concepts/resiliency-concept.md b/daprdocs/content/en/concepts/resiliency-concept.md new file mode 100644 index 00000000000..7b8cbe6757a --- /dev/null +++ b/daprdocs/content/en/concepts/resiliency-concept.md @@ -0,0 +1,39 @@ +--- +type: docs +title: "Resiliency" +linkTitle: "Resiliency" +weight: 400 +description: "Configure policies and monitor app and sidecar health" +--- + +Distributed applications are commonly comprised of many microservices, with dozens - sometimes hundreds - of instances scaling across underlying infrastructure. As these distributed solutions grow in size and complexity, the potential for system failures inevitably increases. Service instances can fail or become unresponsive due to any number of issues, including hardware failures, unexpected throughput, or application lifecycle events, such as scaling out and application restarts. Designing and implementing a self-healing solution with the ability to detect, mitigate, and respond to failure is critical. + +## Resiliency Policies +Diagram showing the resiliency applied to Dapr APIs + +Dapr provides a capability for defining and applying fault tolerance resiliency policies to your application. You can define policies for following resiliency patterns: + +- Timeouts +- Retries/back-offs +- Circuit breakers + +These policies can be applied to any Dapr API calls when calling components with a [resiliency spec]({{< ref resiliency-overview >}}). + +## App Health Checks +Diagram showing the app health feature. Running Dapr with app health enabled causes Dapr to periodically probe the app for its health + +Applications can become unresponsive for a variety of reasons. For example, they are too busy to accept new work, could have crashed, or be in a deadlock state. Sometimes the condition can be transitory or persistent. + +Dapr provides a capability for monitoring app health through probes that check the health of your application and react to status changes. When an unhealthy app is detected, Dapr stops accepting new work on behalf of the application. + +Read more on how to apply [app health checks]({{< ref app-health >}}) to your application. + +## Sidecar Health Checks +Diagram showing the app health feature. Running Dapr with app health enabled causes Dapr to periodically probe the app for its health + +Dapr provides a way to determine its health using an [HTTP `/healthz` endpoint]({{< ref health_api.md >}}). With this endpoint, the *daprd* process, or sidecar, can be: + +- Probed for its health +- Determined for readiness and liveness + +Read more on about how to apply [dapr health checks]({{< ref sidecar-health >}}) to your application. diff --git a/daprdocs/content/en/developing-applications/building-blocks/observability/sidecar-health.md b/daprdocs/content/en/developing-applications/building-blocks/observability/sidecar-health.md index 7d8027dc832..9385473dd9f 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/observability/sidecar-health.md +++ b/daprdocs/content/en/developing-applications/building-blocks/observability/sidecar-health.md @@ -6,7 +6,7 @@ weight: 200 description: Dapr sidecar health checks --- -Dapr provides a way to [determine its health using an [HTTP `/healthz` endpoint]({{< ref health_api.md >}}). With this endpoint, the *daprd* process, or sidecar, can be: +Dapr provides a way to determine its health using an [HTTP `/healthz` endpoint]({{< ref health_api.md >}}). With this endpoint, the *daprd* process, or sidecar, can be: - Probed for its health - Determined for readiness and liveness diff --git a/daprdocs/content/en/developing-applications/building-blocks/pubsub/howto-publish-subscribe.md b/daprdocs/content/en/developing-applications/building-blocks/pubsub/howto-publish-subscribe.md index 844b7ea6824..9a3463eaa00 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/pubsub/howto-publish-subscribe.md +++ b/daprdocs/content/en/developing-applications/building-blocks/pubsub/howto-publish-subscribe.md @@ -155,13 +155,14 @@ Learn more in the [declarative and programmatic subscriptions doc]({{< ref subsc Create a file named `subscription.yaml` and paste the following: ```yaml -apiVersion: dapr.io/v1alpha1 +apiVersion: dapr.io/v2alpha1 kind: Subscription metadata: name: order-pub-sub spec: topic: orders - route: /checkout + routes: + default: /checkout pubsubname: order-pub-sub scopes: - orderprocessing diff --git a/daprdocs/content/en/developing-applications/building-blocks/pubsub/subscription-methods.md b/daprdocs/content/en/developing-applications/building-blocks/pubsub/subscription-methods.md index b963d13daec..c66088ea0e1 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/pubsub/subscription-methods.md +++ b/daprdocs/content/en/developing-applications/building-blocks/pubsub/subscription-methods.md @@ -104,7 +104,6 @@ In your application code, subscribe to the topic specified in the Dapr pub/sub c ```csharp //Subscribe to a topic -[Topic("pubsub", "orders")] [HttpPost("checkout")] public void getCheckout([FromBody] int orderId) { @@ -117,16 +116,15 @@ public void getCheckout([FromBody] int orderId) {{% codetab %}} ```java +import io.dapr.client.domain.CloudEvent; + //Subscribe to a topic -@Topic(name = "orders", pubsubName = "pubsub") @PostMapping(path = "/checkout") public Mono getCheckout(@RequestBody(required = false) CloudEvent cloudEvent) { return Mono.fromRunnable(() -> { try { log.info("Subscriber received: " + cloudEvent.getData()); - } catch (Exception e) { - throw new RuntimeException(e); - } + } }); } ``` @@ -136,13 +134,13 @@ public Mono getCheckout(@RequestBody(required = false) CloudEvent {{% codetab %}} ```python +from cloudevents.sdk.event import v1 + #Subscribe to a topic -@app.subscribe(pubsub_name='pubsub', topic='orders') -def mytopic(event: v1.Event) -> None: +@app.route('/checkout', methods=['POST']) +def checkout(event: v1.Event) -> None: data = json.loads(event.Data()) logging.info('Subscriber received: ' + str(data)) - -app.run(6002) ``` {{% /codetab %}} @@ -150,11 +148,16 @@ app.run(6002) {{% codetab %}} ```javascript -//Subscribe to a topic -await server.pubsub.subscribe("pubsub", "orders", async (orderId) => { - console.log(`Subscriber received: ${JSON.stringify(orderId)}`) +const express = require('express') +const bodyParser = require('body-parser') +const app = express() +app.use(bodyParser.json({ type: 'application/*+json' })); + +// listen to the declarative route +app.post('/checkout', (req, res) => { + console.log(req.body); + res.sendStatus(200); }); -await server.startServer(); ``` {{% /codetab %}} @@ -163,11 +166,10 @@ await server.startServer(); ```go //Subscribe to a topic -if err := s.AddTopicEventHandler(sub, eventHandler); err != nil { - log.Fatalf("error adding topic subscription: %v", err) -} -if err := s.Start(); err != nil && err != http.ErrServerClosed { - log.Fatalf("error listenning: %v", err) +var sub = &common.Subscription{ + PubsubName: "pubsub", + Topic: "orders", + Route: "/checkout", } func eventHandler(ctx context.Context, e *common.TopicEvent) (retry bool, err error) { diff --git a/daprdocs/content/en/developing-applications/building-blocks/service-invocation/howto-invoke-discover-services.md b/daprdocs/content/en/developing-applications/building-blocks/service-invocation/howto-invoke-discover-services.md index f302bc1b9ab..e73456d4bfb 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/service-invocation/howto-invoke-discover-services.md +++ b/daprdocs/content/en/developing-applications/building-blocks/service-invocation/howto-invoke-discover-services.md @@ -405,9 +405,9 @@ dapr invoke --app-id checkout --method checkout/100 ### 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: `checkout.production` +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 `.` format, use `checkout.production`. -For example, invoking the example service with a namespace would look like: +Using this example, invoking the service with a namespace would look like: ```bash curl http://localhost:3602/v1.0/invoke/checkout.production/method/checkout/100 -X POST diff --git a/daprdocs/content/en/developing-applications/building-blocks/service-invocation/service-invocation-overview.md b/daprdocs/content/en/developing-applications/building-blocks/service-invocation/service-invocation-overview.md index eebf72b7a5d..0c4d3bc41a3 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/service-invocation/service-invocation-overview.md +++ b/daprdocs/content/en/developing-applications/building-blocks/service-invocation/service-invocation-overview.md @@ -134,4 +134,4 @@ For quick testing, try using the Dapr CLI for service invocation: - Read the [service invocation API specification]({{< ref service_invocation_api.md >}}). This reference guide for service invocation describes how to invoke methods on other services. - Understand the [service invocation performance numbers]({{< ref perf-service-invocation.md >}}). - Take a look at [observability]({{< ref monitoring.md >}}). Here you can dig into Dapr's monitoring tools like tracing, metrics and logging. -- Read up on our [security practices]({{< ref monitoring.md >}}) around mTLS encryption, token authentication, and endpoint authorization. +- Read up on our [security practices]({{< ref security-concept.md >}}) around mTLS encryption, token authentication, and endpoint authorization. diff --git a/daprdocs/content/en/developing-applications/integrations/Azure/authenticating-azure.md b/daprdocs/content/en/developing-applications/integrations/Azure/authenticating-azure.md index fb08ee08907..93e0e374c08 100644 --- a/daprdocs/content/en/developing-applications/integrations/Azure/authenticating-azure.md +++ b/daprdocs/content/en/developing-applications/integrations/Azure/authenticating-azure.md @@ -84,7 +84,7 @@ To start, create a new Azure AD application, which will also be used as Service Prerequisites: -- [Azure Subscription](https://azure.microsoft.com/free/) +- Azure Subscription - [Azure CLI](https://docs.microsoft.com/cli/azure/install-azure-cli) - [jq](https://stedolan.github.io/jq/download/) - OpenSSL (included by default on all Linux and macOS systems, as well as on WSL) diff --git a/daprdocs/content/en/developing-applications/integrations/Azure/azure-api-management.md b/daprdocs/content/en/developing-applications/integrations/Azure/azure-api-management.md index 793f5f834a7..5eb42a7cdad 100644 --- a/daprdocs/content/en/developing-applications/integrations/Azure/azure-api-management.md +++ b/daprdocs/content/en/developing-applications/integrations/Azure/azure-api-management.md @@ -6,6 +6,6 @@ description: "Publish APIs for Dapr services and components through Azure API Ma weight: 2000 --- -Azure API Management (APIM) is a way to create consistent and modern API gateways for back-end services, including as those built with Dapr. Dapr support can be enabled in self-hosted API Management gateways to allow them to forward requests to Dapr services, send messages to Dapr Pub/Sub topics, or trigger Dapr output bindings. For more information, read the guide on [API Management Dapr Integration policies](https://docs.microsoft.com/azure/api-management/api-management-dapr-policies) and try out the [Dapr & Azure API Management Integration Demo](https://github.com/dapr/samples/tree/master/dapr-apim-integration). +Azure API Management (APIM) is a way to create consistent and modern API gateways for back-end services, including those built with Dapr. Dapr support can be enabled in self-hosted API Management gateways to allow them to forward requests to Dapr services, send messages to Dapr Pub/Sub topics, or trigger Dapr output bindings. For more information, read the guide on [API Management Dapr Integration policies](https://docs.microsoft.com/azure/api-management/api-management-dapr-policies) and try out the [Dapr & Azure API Management Integration Demo](https://github.com/dapr/samples/tree/master/dapr-apim-integration). {{< button text="Learn more" link="https://docs.microsoft.com/azure/api-management/api-management-dapr-policies" >}} diff --git a/daprdocs/content/en/developing-applications/integrations/Azure/azure-kubernetes-service-extension.md b/daprdocs/content/en/developing-applications/integrations/Azure/azure-kubernetes-service-extension.md index 1eefc118134..a8dab479e66 100644 --- a/daprdocs/content/en/developing-applications/integrations/Azure/azure-kubernetes-service-extension.md +++ b/daprdocs/content/en/developing-applications/integrations/Azure/azure-kubernetes-service-extension.md @@ -7,7 +7,7 @@ weight: 4000 --- # Prerequisites -- [Azure subscription](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) +- Azure subscription - [Azure CLI](https://docs.microsoft.com/cli/azure/install-azure-cli-windows?tabs=azure-cli) and the ***aks-preview*** extension. - [Azure Kubernetes Service (AKS) cluster](https://docs.microsoft.com/azure/aks/tutorial-kubernetes-deploy-cluster?tabs=azure-cli) @@ -106,4 +106,4 @@ dapr-sidecar-injector-9555889bc-rpjwl 1/1 Running 0 1h dapr-sidecar-injector-9555889bc-rqjgt 1/1 Running 0 1h ``` -For further information such as configuration options and targeting specific versions of Dapr, see the official [AKS Dapr Extension Docs](https://docs.microsoft.com/azure/aks/dapr). \ No newline at end of file +For more information about configuration options and targeting specific Dapr versions, see the official [AKS Dapr Extension Docs](https://docs.microsoft.com/azure/aks/dapr). diff --git a/daprdocs/content/en/developing-applications/integrations/gRPC-integration.md b/daprdocs/content/en/developing-applications/integrations/gRPC-integration.md index b241ca3bf1a..40b53b07384 100644 --- a/daprdocs/content/en/developing-applications/integrations/gRPC-integration.md +++ b/daprdocs/content/en/developing-applications/integrations/gRPC-integration.md @@ -214,17 +214,17 @@ func main() { } ``` -This creates a gRPC server for your app on port 4000. +This creates a gRPC server for your app on port 50001. 4. Run your app To run locally, use the Dapr CLI: ``` -dapr run --app-id goapp --app-port 4000 --app-protocol grpc go run main.go +dapr run --app-id goapp --app-port 50001 --app-protocol grpc go run main.go ``` -On Kubernetes, set the required `dapr.io/app-protocol: "grpc"` and `dapr.io/app-port: "4000` annotations in your pod spec template as mentioned above. +On Kubernetes, set the required `dapr.io/app-protocol: "grpc"` and `dapr.io/app-port: "50001` annotations in your pod spec template as mentioned above. ## Other languages diff --git a/daprdocs/content/en/developing-applications/integrations/github_actions.md b/daprdocs/content/en/developing-applications/integrations/github_actions.md index 1853dd71862..b0424bef009 100644 --- a/daprdocs/content/en/developing-applications/integrations/github_actions.md +++ b/daprdocs/content/en/developing-applications/integrations/github_actions.md @@ -3,14 +3,21 @@ type: docs weight: 5000 title: "Use the Dapr CLI in a GitHub Actions workflow" linkTitle: "GitHub Actions" -description: "Learn how to add the Dapr CLI to your GitHub Actions to deploy and manage Dapr in your environments." +description: "Add the Dapr CLI to your GitHub Actions to deploy and manage Dapr in your environments." --- -Dapr can be integrated with GitHub Actions via the [Dapr tool installer](https://github.com/marketplace/actions/dapr-tool-installer) available in the GitHub Marketplace. This installer adds the Dapr CLI to your workflow, allowing you to deploy, manage, and upgrade Dapr across your environments. +Dapr can be integrated with GitHub Actions via the [Dapr tool installer](https://github.com/marketplace/actions/dapr-tool-installer) available in the GitHub Marketplace. This installer adds the Dapr CLI to your workflow, allowing you to deploy, manage, and upgrade Dapr across your environments. -## Overview +Copy and paste the following installer snippet into your applicatin's YAML file to get started: -The `dapr/setup-dapr` action will install the specified version of the Dapr CLI on macOS, Linux and Windows runners. Once installed, you can run any [Dapr CLI command]({{< ref cli >}}) to manage your Dapr environments. +```yaml +- name: Dapr tool installer + uses: dapr/setup-dapr@v1 +``` + +The [`dapr/setup-dapr` action](https://github.com/dapr/setup-dapr) will install the specified version of the Dapr CLI on macOS, Linux, and Windows runners. Once installed, you can run any [Dapr CLI command]({{< ref cli >}}) to manage your Dapr environments. + +Refer to the [`action.yml` metadata file](https://github.com/dapr/setup-dapr/blob/main/action.yml) for details about all the inputs. ## Example @@ -34,4 +41,8 @@ The `dapr/setup-dapr` action will install the specified version of the Dapr CLI dapr status --kubernetes working-directory: ./twitter-sentiment-processor/demos/demo3 -``` \ No newline at end of file +``` + +## Next steps + +Learn more about [GitHub Actions](https://docs.github.com/en/actions). \ No newline at end of file diff --git a/daprdocs/content/en/getting-started/quickstarts/_index.md b/daprdocs/content/en/getting-started/quickstarts/_index.md index efae344ff09..67380fa8763 100644 --- a/daprdocs/content/en/getting-started/quickstarts/_index.md +++ b/daprdocs/content/en/getting-started/quickstarts/_index.md @@ -27,7 +27,4 @@ Hit the ground running with our Dapr quickstarts, complete with code samples aim | [State Management]({{< ref statemanagement-quickstart.md >}}) | Store a service's data as key/value pairs in supported state stores. | | [Bindings]({{< ref bindings-quickstart.md >}}) | Work with external systems using input bindings to respond to events and output bindings to call operations. | | [Secrets Management]({{< ref secrets-quickstart.md >}}) | Securely fetch secrets. | -| Actors | Coming soon. | -| Observability | Coming soon. | -| Configuration | Coming soon. | -| Distributed Lock | Coming soon. | +| [Resiliency]({{< ref resiliency >}}) | Define and apply fault-tolerance policies to your Dapr API requests. | diff --git a/daprdocs/content/en/getting-started/quickstarts/resiliency/_index.md b/daprdocs/content/en/getting-started/quickstarts/resiliency/_index.md new file mode 100644 index 00000000000..3156dfa9d28 --- /dev/null +++ b/daprdocs/content/en/getting-started/quickstarts/resiliency/_index.md @@ -0,0 +1,7 @@ +--- +type: docs +title: "Resiliency Quickstarts" +linkTitle: "Resiliency" +weight: 100 +description: "Get started with Dapr's resiliency component" +--- \ No newline at end of file diff --git a/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-serviceinvo-quickstart.md b/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-serviceinvo-quickstart.md new file mode 100644 index 00000000000..f338bde8ac1 --- /dev/null +++ b/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-serviceinvo-quickstart.md @@ -0,0 +1,1183 @@ +--- +type: docs +title: "Quickstart: Service-to-service resiliency" +linkTitle: "Resiliency: Service-to-service" +weight: 120 +description: "Get started with Dapr's resiliency capabilities via the service invocation API" +--- + +{{% alert title="Note" color="primary" %}} + Resiliency is currently a preview feature. +{{% /alert %}} + +Observe Dapr resiliency capabilities by simulating a system failure. In this Quickstart, you will: + +- Run two microservice applications: `checkout` and `order-processor`. `checkout` will continuously make Dapr service invocation requests to `order-processor`. +- Trigger the resiliency spec by simulating a system failure. +- Remove the failure to allow the microservice application to recover. + +Diagram showing the resiliency applied to Dapr APIs + +Select your preferred language-specific Dapr SDK before proceeding with the Quickstart. + +{{< tabs "Python" "JavaScript" ".NET" "Java" "Go" >}} + +{{% codetab %}} + +### Pre-requisites + +For this example, you will need: + +- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started). +- [Python 3.7+ installed](https://www.python.org/downloads/). + +- [Docker Desktop](https://www.docker.com/products/docker-desktop) + + +### Step 1: Set up the environment + +Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quickstarts/tree/master/service_invocation). + +```bash +git clone https://github.com/dapr/quickstarts.git +``` + +### Step 2: Run `order-processor` service + +In a terminal window, from the root of the Quickstart directory, navigate to `order-processor` directory. + +```bash +cd ../service_invocation/python/http/order-processor +``` + +Install dependencies: + +```bash +pip3 install -r requirements.txt +``` + +Run the `order-processor` service alongside a Dapr sidecar. + +```bash +dapr run --app-port 8001 --app-id order-processor --config ../config.yaml --components-path ../../../components/ --app-protocol http --dapr-http-port 3501 -- python3 app.py +``` + +### Step 3: Run the `checkout` service application with resiliency enabled + +In a new terminal window, from the root of the Quickstart directory, navigate to the `checkout` directory. + +```bash +cd ../service_invocation/python/http/checkout +``` + +Install dependencies: + +```bash +pip3 install -r requirements.txt +``` + +Run the `checkout` service alongside a Dapr sidecar. The `--config` parameter applies a Dapr configuration that enables the resiliency feature. + +```bash +dapr run --app-id checkout --config ../config.yaml --components-path ../../../components/ --app-protocol http --dapr-http-port 3500 -- python3 app.py +``` + +By enabling resiliency, the resiliency spec located in the components directory is detected and loaded by the Dapr sidecar: + + ```yaml + apiVersion: dapr.io/v1alpha1 + kind: Resiliency + metadata: + name: myresiliency + scopes: + - checkout + + spec: + policies: + retries: + retryForever: + policy: constant + maxInterval: 5s + maxRetries: -1 + + circuitBreakers: + simpleCB: + maxRequests: 1 + timeout: 5s + trip: consecutiveFailures >= 5 + + targets: + apps: + order-processor: + retry: retryForever + circuitBreaker: simpleCB + ``` + +### Step 4: View the Service Invocation outputs +When both services and sidecars are running, notice how orders are passed from the `checkout` service to the `order-processor` service using Dapr service invoke. + +`checkout` service output: + +``` +== APP == Order passed: {"orderId": 1} +== APP == Order passed: {"orderId": 2} +== APP == Order passed: {"orderId": 3} +== APP == Order passed: {"orderId": 4} +``` + +`order-processor` service output: + +``` +== APP == Order received: {"orderId": 1} +== APP == Order received: {"orderId": 2} +== APP == Order received: {"orderId": 3} +== APP == Order received: {"orderId": 4} +``` + +### Step 5: Introduce a fault +Simulate a fault by stopping the `order-processor` service. Once the instance is stopped, service invoke operations from the `checkout` service begin to fail. + +Since the `resiliency.yaml` spec defines the `order-processor` service as a resiliency target, all failed requests will apply retry and circuit breaker policies: + +```yaml + targets: + apps: + order-processor: + retry: retryForever + circuitBreaker: simpleCB +``` + +In the `order-processor` window, stop the service: + +{{< tabs "MacOs" "Windows" >}} + + + +{{% codetab %}} + +```script +CMD + C +``` + +{{% /codetab %}} + + + +{{% codetab %}} + +```script +CTRL + C +``` + +{{% /codetab %}} + +{{< /tabs >}} + + +Once the first request fails, the retry policy titled `retryForever` is applied: + +```bash +INFO[0005] Error processing operation endpoint[order-processor, order-processor:orders]. Retrying... +``` + +Retries will continue for each failed request indefinitely, in 5 second intervals. + +```yaml +retryForever: + policy: constant + maxInterval: 5s + maxRetries: -1 +``` + +Once 5 consecutive retries have failed, the circuit breaker policy, `simpleCB`, is tripped and the breaker opens, halting all requests: + +```bash +INFO[0025] Circuit breaker "order-processor:orders" changed state from closed to open +``` + +```yaml +circuitBreakers: + simpleCB: + maxRequests: 1 + timeout: 5s + trip: consecutiveFailures >= 5 +``` + +After 5 seconds has surpassed, the circuit breaker will switch to a half-open state, allowing one request through to verify if the fault has been resolved. If the request continues to fail, the circuit will trip back to the open state. + +```bash +INFO[0030] Circuit breaker "order-processor:orders" changed state from open to half-open +INFO[0030] Circuit breaker "order-processor:orders" changed state from half-open to open +INFO[0030] Circuit breaker "order-processor:orders" changed state from open to half-open +INFO[0030] Circuit breaker "order-processor:orders" changed state from half-open to open +``` + +This half-open/open behavior will continue for as long as the `order-processor` service is stopped. + +### Step 6: Remove the fault + +Once you restart the `order-processor` service, the application will recover seamlessly, picking up where it left off with accepting order requests. + +In the `order-processor` service terminal, restart the application: + +```bash +dapr run --app-port 8001 --app-id order-processor --app-protocol http --dapr-http-port 3501 -- python3 app.py +``` + +`checkout` service output: + +``` +== APP == Order passed: {"orderId": 5} +== APP == Order passed: {"orderId": 6} +== APP == Order passed: {"orderId": 7} +== APP == Order passed: {"orderId": 8} +== APP == Order passed: {"orderId": 9} +== APP == Order passed: {"orderId": 10} +``` + +`order-processor` service output: + +``` +== APP == Order received: {"orderId": 5} +== APP == Order received: {"orderId": 6} +== APP == Order received: {"orderId": 7} +== APP == Order received: {"orderId": 8} +== APP == Order received: {"orderId": 9} +== APP == Order received: {"orderId": 10} +``` + +{{% /codetab %}} + + +{{% codetab %}} + +### Pre-requisites + +For this example, you will need: + +- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started). +- [Latest Node.js installed](https://nodejs.org/download/). + +- [Docker Desktop](https://www.docker.com/products/docker-desktop) + + +### Step 1: Set up the environment + +Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quickstarts/tree/master/service_invocation). + +```bash +git clone https://github.com/dapr/quickstarts.git +``` + +### Step 2: Run the `order-processor` service + +In a terminal window, from the root of the Quickstart directory, +navigate to `order-processor` directory. + +```bash +cd ../service_invocation/javascript/http/order-processor +``` + +Install dependencies: + +```bash +npm install +``` + +Run the `order-processor` service alongside a Dapr sidecar. + +```bash +dapr run --app-port 5001 --app-id order-processor --config ../config.yaml --components-path ../../../components/ --app-protocol http --dapr-http-port 3501 -- npm start +``` + +### Step 3: Run the `checkout` service application with resiliency enabled + +In a new terminal window, from the root of the Quickstart directory, +navigate to the `checkout` directory. + +```bash +cd service_invocation/javascript/http/checkout +``` + +Install dependencies: + +```bash +npm install +``` + +Run the `checkout` service alongside a Dapr sidecar. The `--config` parameter applies a Dapr configuration that enables the resiliency feature. + +```bash +dapr run --app-id checkout --config ../config.yaml --components-path ../../../components/ --app-protocol http --dapr-http-port 3500 -- npm start +``` + +By enabling resiliency, the resiliency spec located in the components directory is detected and loaded by the Dapr sidecar: + + ```yaml + apiVersion: dapr.io/v1alpha1 + kind: Resiliency + metadata: + name: myresiliency + scopes: + - checkout + + spec: + policies: + retries: + retryForever: + policy: constant + maxInterval: 5s + maxRetries: -1 + + circuitBreakers: + simpleCB: + maxRequests: 1 + timeout: 5s + trip: consecutiveFailures >= 5 + + targets: + apps: + order-processor: + retry: retryForever + circuitBreaker: simpleCB + ``` + +### Step 4: View the Service Invocation outputs +When both services and sidecars are running, notice how orders are passed from the `checkout` service to the `order-processor` service using Dapr service invoke. + +`checkout` service output: + +``` +== APP == Order passed: {"orderId": 1} +== APP == Order passed: {"orderId": 2} +== APP == Order passed: {"orderId": 3} +== APP == Order passed: {"orderId": 4} +``` + +`order-processor` service output: + +``` +== APP == Order received: {"orderId": 1} +== APP == Order received: {"orderId": 2} +== APP == Order received: {"orderId": 3} +== APP == Order received: {"orderId": 4} +``` + +### Step 5: Introduce a fault +Simulate a fault by stopping the `order-processor` service. Once the instance is stopped, service invoke operations from the `checkout` service begin to fail. + +Since the `resiliency.yaml` spec defines the `order-processor` service as a resiliency target, all failed requests will apply retry and circuit breaker policies: + +```yaml + targets: + apps: + order-processor: + retry: retryForever + circuitBreaker: simpleCB +``` + +In the `order-processor` window, stop the service: + +{{< tabs "MacOs" "Windows" >}} + + + +{{% codetab %}} + +```script +CMD + C +``` + +{{% /codetab %}} + + + +{{% codetab %}} + +```script +CTRL + C +``` + +{{% /codetab %}} + +{{< /tabs >}} + + +Once the first request fails, the retry policy titled `retryForever` is applied: + +```bash +INFO[0005] Error processing operation endpoint[order-processor, order-processor:orders]. Retrying... +``` + +Retries will continue for each failed request indefinitely, in 5 second intervals. + +```yaml +retryForever: + policy: constant + maxInterval: 5s + maxRetries: -1 +``` + +Once 5 consecutive retries have failed, the circuit breaker policy, `simpleCB`, is tripped and the breaker opens, halting all requests: + +```bash +INFO[0025] Circuit breaker "order-processor:orders" changed state from closed to open +``` + +```yaml +circuitBreakers: + simpleCB: + maxRequests: 1 + timeout: 5s + trip: consecutiveFailures >= 5 +``` + +After 5 seconds has surpassed, the circuit breaker will switch to a half-open state, allowing one request through to verify if the fault has been resolved. If the request continues to fail, the circuit will trip back to the open state. + +```bash +INFO[0030] Circuit breaker "order-processor:orders" changed state from open to half-open +INFO[0030] Circuit breaker "order-processor:orders" changed state from half-open to open +INFO[0030] Circuit breaker "order-processor:orders" changed state from open to half-open +INFO[0030] Circuit breaker "order-processor:orders" changed state from half-open to open +``` + +This half-open/open behavior will continue for as long as the Redis container is stopped. + +### Step 6: Remove the fault + +Once you restart the `order-processor` service, the application will recover seamlessly, picking up where it left off. + +In the `order-processor` service terminal, restart the application: + +```bash +dapr run --app-port 5001 --app-id order-processor --config ../config.yaml --components-path ../../../components/ --app-protocol http --dapr-http-port 3501 -- npm start +``` + +`checkout` service output: + +``` +== APP == Order passed: {"orderId": 5} +== APP == Order passed: {"orderId": 6} +== APP == Order passed: {"orderId": 7} +== APP == Order passed: {"orderId": 8} +== APP == Order passed: {"orderId": 9} +== APP == Order passed: {"orderId": 10} +``` + +`order-processor` service output: + +``` +== APP == Order received: {"orderId": 5} +== APP == Order received: {"orderId": 6} +== APP == Order received: {"orderId": 7} +== APP == Order received: {"orderId": 8} +== APP == Order received: {"orderId": 9} +== APP == Order received: {"orderId": 10} +``` + +{{% /codetab %}} + + +{{% codetab %}} + +### Pre-requisites + +For this example, you will need: + +- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started). +- [.NET SDK or .NET 6 SDK installed](https://dotnet.microsoft.com/download). + +- [Docker Desktop](https://www.docker.com/products/docker-desktop) + + +### Step 1: Set up the environment + +Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quickstarts/tree/master/service_invocation). + +```bash +git clone https://github.com/dapr/quickstarts.git +``` + +### Step 2: Run the `order-processor` service + +In a terminal window, from the root of the Quickstart directory, +navigate to `order-processor` directory. + + +```bash +cd ../service_invocation/csharp/http/order-processor +``` + +Install dependencies: + +```bash +dotnet restore +dotnet build +``` + +Run the `order-processor` service alongside a Dapr sidecar. + +```bash +dapr run --app-port 7001 --app-id order-processor --config ../config.yaml --components-path ../../../components/ --app-protocol http --dapr-http-port 3501 -- dotnet run +``` + +### Step 3: Run the `checkout` service application with resiliency enabled + +In a new terminal window, from the root of the Quickstart directory, +navigate to the `checkout` directory. + +```bash +cd ../service_invocation/csharp/http/checkout +``` + +Install dependencies: + +```bash +dotnet restore +dotnet build +``` + +Run the `checkout` service alongside a Dapr sidecar. The `--config` parameter applies a Dapr configuration that enables the resiliency feature. + +```bash +dapr run --app-id checkout --config ../config.yaml --components-path ../../../components/ --app-protocol http --dapr-http-port 3500 -- dotnet run +``` + +By enabling resiliency, the resiliency spec located in the components directory is detected and loaded by the Dapr sidecar: + + ```yaml + apiVersion: dapr.io/v1alpha1 + kind: Resiliency + metadata: + name: myresiliency + scopes: + - checkout + + spec: + policies: + retries: + retryForever: + policy: constant + maxInterval: 5s + maxRetries: -1 + + circuitBreakers: + simpleCB: + maxRequests: 1 + timeout: 5s + trip: consecutiveFailures >= 5 + + targets: + apps: + order-processor: + retry: retryForever + circuitBreaker: simpleCB + ``` + +### Step 4: View the Service Invocation outputs +When both services and sidecars are running, notice how orders are passed from the `checkout` service to the `order-processor` service using Dapr service invoke. + +`checkout` service output: + +``` +== APP == Order passed: {"orderId": 1} +== APP == Order passed: {"orderId": 2} +== APP == Order passed: {"orderId": 3} +== APP == Order passed: {"orderId": 4} +``` + +`order-processor` service output: + +``` +== APP == Order received: {"orderId": 1} +== APP == Order received: {"orderId": 2} +== APP == Order received: {"orderId": 3} +== APP == Order received: {"orderId": 4} +``` + +### Step 5: Introduce a fault +Simulate a fault by stopping the `order-processor` service. Once the instance is stopped, service invoke operations from the `checkout` service begin to fail. + +Since the `resiliency.yaml` spec defines the `order-processor` service as a resiliency target, all failed requests will apply retry and circuit breaker policies: + +```yaml + targets: + apps: + order-processor: + retry: retryForever + circuitBreaker: simpleCB +``` + +In the `order-processor` window, stop the service: + +{{< tabs "MacOs" "Windows" >}} + + + +{{% codetab %}} + +```script +CMD + C +``` + +{{% /codetab %}} + + + +{{% codetab %}} + +```script +CTRL + C +``` + +{{% /codetab %}} + +{{< /tabs >}} + + +Once the first request fails, the retry policy titled `retryForever` is applied: + +```bash +INFO[0005] Error processing operation endpoint[order-processor, order-processor:orders]. Retrying... +``` + +Retries will continue for each failed request indefinitely, in 5 second intervals. + +```yaml +retryForever: + policy: constant + maxInterval: 5s + maxRetries: -1 +``` + +Once 5 consecutive retries have failed, the circuit breaker policy, `simpleCB`, is tripped and the breaker opens, halting all requests: + +```bash +INFO[0025] Circuit breaker "order-processor:orders" changed state from closed to open +``` + +```yaml +circuitBreakers: + simpleCB: + maxRequests: 1 + timeout: 5s + trip: consecutiveFailures >= 5 +``` + +After 5 seconds has surpassed, the circuit breaker will switch to a half-open state, allowing one request through to verify if the fault has been resolved. If the request continues to fail, the circuit will trip back to the open state. + +```bash +INFO[0030] Circuit breaker "order-processor:orders" changed state from open to half-open +INFO[0030] Circuit breaker "order-processor:orders" changed state from half-open to open +INFO[0030] Circuit breaker "order-processor:orders" changed state from open to half-open +INFO[0030] Circuit breaker "order-processor:orders" changed state from half-open to open +``` + +This half-open/open behavior will continue for as long as the Redis container is stopped. + +### Step 6: Remove the fault + +Once you restart the `order-processor` service, the application will recover seamlessly, picking up where it left off. + +In the `order-processor` service terminal, restart the application: + +```bash +dapr run --app-port 7001 --app-id order-processor --app-protocol http --dapr-http-port 3501 -- dotnet run +``` + +`checkout` service output: + +``` +== APP == Order passed: {"orderId": 5} +== APP == Order passed: {"orderId": 6} +== APP == Order passed: {"orderId": 7} +== APP == Order passed: {"orderId": 8} +== APP == Order passed: {"orderId": 9} +== APP == Order passed: {"orderId": 10} +``` + +`order-processor` service output: + +``` +== APP == Order received: {"orderId": 5} +== APP == Order received: {"orderId": 6} +== APP == Order received: {"orderId": 7} +== APP == Order received: {"orderId": 8} +== APP == Order received: {"orderId": 9} +== APP == Order received: {"orderId": 10} +``` + +{{% /codetab %}} + + +{{% codetab %}} + +### Pre-requisites + +For this example, you will need: + +- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started). +- Java JDK 11 (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. + +- [Docker Desktop](https://www.docker.com/products/docker-desktop) + + +### Step 1: Set up the environment + +Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quickstarts/tree/master/service_invocation). + +```bash +git clone https://github.com/dapr/quickstarts.git +``` + +### Step 2: Run the `order-processor` service + +In a terminal window, from the root of the Quickstart directory, +navigate to `order-processor` directory. + +```bash +cd ../service_invocation/java/http/order-processor +``` + +Install dependencies: + +```bash +mvn clean install +``` + +Run the `order-processor` service alongside a Dapr sidecar. + +```bash +dapr run --app-id order-processor --config ../config.yaml --components-path ../../../components/ --app-port 9001 --app-protocol http --dapr-http-port 3501 -- java -jar target/OrderProcessingService-0.0.1-SNAPSHOT.jar +``` + +### Step 3: Run the `checkout` service application with resiliency enabled + +In a new terminal window, from the root of the Quickstart directory, +navigate to the `checkout` directory. + +```bash +cd ../service_invocation/java/http/checkout +``` + +Install dependencies: + +```bash +mvn clean install +``` + +Run the `checkout` service alongside a Dapr sidecar. The `--config` parameter applies a Dapr configuration that enables the resiliency feature. + +```bash +dapr run --app-id checkout --config ../config.yaml --components-path ../../../components/ --app-protocol http --dapr-http-port 3500 -- java -jar target/CheckoutService-0.0.1-SNAPSHOT.jar +``` + +By enabling resiliency, the resiliency spec located in the components directory is detected and loaded by the Dapr sidecar: + + ```yaml + apiVersion: dapr.io/v1alpha1 + kind: Resiliency + metadata: + name: myresiliency + scopes: + - checkout + + spec: + policies: + retries: + retryForever: + policy: constant + maxInterval: 5s + maxRetries: -1 + + circuitBreakers: + simpleCB: + maxRequests: 1 + timeout: 5s + trip: consecutiveFailures >= 5 + + targets: + apps: + order-processor: + retry: retryForever + circuitBreaker: simpleCB + ``` + +### Step 4: View the Service Invocation outputs +When both services and sidecars are running, notice how orders are passed from the `checkout` service to the `order-processor` service using Dapr service invoke. + +`checkout` service output: + +``` +== APP == Order passed: {"orderId": 1} +== APP == Order passed: {"orderId": 2} +== APP == Order passed: {"orderId": 3} +== APP == Order passed: {"orderId": 4} +``` + +`order-processor` service output: + +``` +== APP == Order received: {"orderId": 1} +== APP == Order received: {"orderId": 2} +== APP == Order received: {"orderId": 3} +== APP == Order received: {"orderId": 4} +``` + +### Step 5: Introduce a fault +Simulate a fault by stopping the `order-processor` service. Once the instance is stopped, service invoke operations from the `checkout` service begin to fail. + +Since the `resiliency.yaml` spec defines the `order-processor` service as a resiliency target, all failed requests will apply retry and circuit breaker policies: + +```yaml + targets: + apps: + order-processor: + retry: retryForever + circuitBreaker: simpleCB +``` + +In the `order-processor` window, stop the service: + +{{< tabs "MacOs" "Windows" >}} + + + +{{% codetab %}} + +```script +CMD + C +``` + +{{% /codetab %}} + + + +{{% codetab %}} + +```script +CTRL + C +``` + +{{% /codetab %}} + +{{< /tabs >}} + + +Once the first request fails, the retry policy titled `retryForever` is applied: + +```bash +INFO[0005] Error processing operation endpoint[order-processor, order-processor:orders]. Retrying... +``` + +Retries will continue for each failed request indefinitely, in 5 second intervals. + +```yaml +retryForever: + policy: constant + maxInterval: 5s + maxRetries: -1 +``` + +Once 5 consecutive retries have failed, the circuit breaker policy, `simpleCB`, is tripped and the breaker opens, halting all requests: + +```bash +INFO[0025] Circuit breaker "order-processor:orders" changed state from closed to open +``` + +```yaml +circuitBreakers: + simpleCB: + maxRequests: 1 + timeout: 5s + trip: consecutiveFailures >= 5 +``` + +After 5 seconds has surpassed, the circuit breaker will switch to a half-open state, allowing one request through to verify if the fault has been resolved. If the request continues to fail, the circuit will trip back to the open state. + +```bash +INFO[0030] Circuit breaker "order-processor:orders" changed state from open to half-open +INFO[0030] Circuit breaker "order-processor:orders" changed state from half-open to open +INFO[0030] Circuit breaker "order-processor:orders" changed state from open to half-open +INFO[0030] Circuit breaker "order-processor:orders" changed state from half-open to open +``` + +This half-open/open behavior will continue for as long as the Redis container is stopped. + +### Step 6: Remove the fault + +Once you restart the `order-processor` service, the application will recover seamlessly, picking up where it left off. + +In the `order-processor` service terminal, restart the application: + +```bash +dapr run --app-id order-processor --config ../config.yaml --components-path ../../../components/ --app-port 9001 --app-protocol http --dapr-http-port 3501 -- java -jar target/OrderProcessingService-0.0.1-SNAPSHOT.jar +``` + +`checkout` service output: + +``` +== APP == Order passed: {"orderId": 5} +== APP == Order passed: {"orderId": 6} +== APP == Order passed: {"orderId": 7} +== APP == Order passed: {"orderId": 8} +== APP == Order passed: {"orderId": 9} +== APP == Order passed: {"orderId": 10} +``` + +`order-processor` service output: + +``` +== APP == Order received: {"orderId": 5} +== APP == Order received: {"orderId": 6} +== APP == Order received: {"orderId": 7} +== APP == Order received: {"orderId": 8} +== APP == Order received: {"orderId": 9} +== APP == Order received: {"orderId": 10} +``` + +{{% /codetab %}} + + +{{% codetab %}} + +### Pre-requisites + +For this example, you will need: + +- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started). +- [Latest version of Go](https://go.dev/dl/). + +- [Docker Desktop](https://www.docker.com/products/docker-desktop) + + +### Step 1: Set up the environment + +Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quickstarts/tree/master/service_invocation). + +```bash +git clone https://github.com/dapr/quickstarts.git +``` + +### Step 2: Run the `order-processor` service + +In a terminal window, from the root of the Quickstart directory, +navigate to `order-processor` directory. + +```bash +cd ../service_invocation/go/http/order-processor +``` + +Install dependencies: + +```bash +go build . +``` + +Run the `order-processor` service alongside a Dapr sidecar. + +```bash +dapr run --app-port 6001 --app-id order-processor --config ../config.yaml --components-path ../../../components/ --app-protocol http --dapr-http-port 3501 -- go run . +``` + +### Step 3: Run the `checkout` service application with resiliency enabled + +In a new terminal window, from the root of the Quickstart directory, +navigate to the `checkout` directory. + +```bash +cd ../service_invocation/go/http/checkout +``` + +Install dependencies: + +```bash +go build . +``` + +Run the `checkout` service alongside a Dapr sidecar. The `--config` parameter applies a Dapr configuration that enables the resiliency feature. + +```bash +dapr run --app-id checkout --config ../config.yaml --components-path ../../../components/ --app-protocol http --dapr-http-port 3500 -- go run . +``` + +By enabling resiliency, the resiliency spec located in the components directory is detected and loaded by the Dapr sidecar: + + ```yaml + apiVersion: dapr.io/v1alpha1 + kind: Resiliency + metadata: + name: myresiliency + scopes: + - checkout + + spec: + policies: + retries: + retryForever: + policy: constant + maxInterval: 5s + maxRetries: -1 + + circuitBreakers: + simpleCB: + maxRequests: 1 + timeout: 5s + trip: consecutiveFailures >= 5 + + targets: + apps: + order-processor: + retry: retryForever + circuitBreaker: simpleCB + ``` + +### Step 4: View the Service Invocation outputs +When both services and sidecars are running, notice how orders are passed from the `checkout` service to the `order-processor` service using Dapr service invoke. + +`checkout` service output: + +``` +== APP == Order passed: {"orderId": 1} +== APP == Order passed: {"orderId": 2} +== APP == Order passed: {"orderId": 3} +== APP == Order passed: {"orderId": 4} +``` + +`order-processor` service output: + +``` +== APP == Order received: {"orderId": 1} +== APP == Order received: {"orderId": 2} +== APP == Order received: {"orderId": 3} +== APP == Order received: {"orderId": 4} +``` + +### Step 5: Introduce a fault +Simulate a fault by stopping the `order-processor` service. Once the instance is stopped, service invoke operations from the `checkout` service begin to fail. + +Since the `resiliency.yaml` spec defines the `order-processor` service as a resiliency target, all failed requests will apply retry and circuit breaker policies: + +```yaml + targets: + apps: + order-processor: + retry: retryForever + circuitBreaker: simpleCB +``` + +In the `order-processor` window, stop the service: + +{{< tabs "MacOs" "Windows" >}} + + + +{{% codetab %}} + +```script +CMD + C +``` + +{{% /codetab %}} + + + +{{% codetab %}} + +```script +CTRL + C +``` + +{{% /codetab %}} + +{{< /tabs >}} + + +Once the first request fails, the retry policy titled `retryForever` is applied: + +```bash +INFO[0005] Error processing operation endpoint[order-processor, order-processor:orders]. Retrying... +``` + +Retries will continue for each failed request indefinitely, in 5 second intervals. + +```yaml +retryForever: + policy: constant + maxInterval: 5s + maxRetries: -1 +``` + +Once 5 consecutive retries have failed, the circuit breaker policy, `simpleCB`, is tripped and the breaker opens, halting all requests: + +```bash +INFO[0025] Circuit breaker "order-processor:orders" changed state from closed to open +``` + +```yaml +circuitBreakers: + simpleCB: + maxRequests: 1 + timeout: 5s + trip: consecutiveFailures >= 5 +``` + +After 5 seconds has surpassed, the circuit breaker will switch to a half-open state, allowing one request through to verify if the fault has been resolved. If the request continues to fail, the circuit will trip back to the open state. + +```bash +INFO[0030] Circuit breaker "order-processor:orders" changed state from open to half-open +INFO[0030] Circuit breaker "order-processor:orders" changed state from half-open to open +INFO[0030] Circuit breaker "order-processor:orders" changed state from open to half-open +INFO[0030] Circuit breaker "order-processor:orders" changed state from half-open to open +``` + +This half-open/open behavior will continue for as long as the Redis container is stopped. + +### Step 6: Remove the fault + +Once you restart the `order-processor` service, the application will recover seamlessly, picking up where it left off. + +In the `order-processor` service terminal, restart the application: + +```bash +dapr run --app-port 6001 --app-id order-processor --config ../config.yaml --components-path ../../../components/ --app-protocol http --dapr-http-port 3501 -- go run . +``` + +`checkout` service output: + +``` +== APP == Order passed: {"orderId": 5} +== APP == Order passed: {"orderId": 6} +== APP == Order passed: {"orderId": 7} +== APP == Order passed: {"orderId": 8} +== APP == Order passed: {"orderId": 9} +== APP == Order passed: {"orderId": 10} +``` + +`order-processor` service output: + +``` +== APP == Order received: {"orderId": 5} +== APP == Order received: {"orderId": 6} +== APP == Order received: {"orderId": 7} +== APP == Order received: {"orderId": 8} +== APP == Order received: {"orderId": 9} +== APP == Order received: {"orderId": 10} +``` + +{{% /codetab %}} + +{{< /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). + +## Next steps +Visit [this](https://docs.dapr.io/operations/resiliency/resiliency-overview//) link for more information about Dapr resiliency. + +{{< button text="Explore Dapr tutorials >>" page="getting-started/tutorials/_index.md" >}} diff --git a/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-state-quickstart.md b/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-state-quickstart.md new file mode 100644 index 00000000000..ef34f4a69ae --- /dev/null +++ b/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-state-quickstart.md @@ -0,0 +1,880 @@ +--- +type: docs +title: "Quickstart: Service-to-component resiliency" +linkTitle: "Resiliency: Service-to-component" +weight: 110 +description: "Get started with Dapr's resiliency capabilities via the state management API" +--- + +{{% alert title="Note" color="primary" %}} + Resiliency is currently a preview feature. +{{% /alert %}} + +Observe Dapr resiliency capabilities by simulating a system failure. In this Quickstart, you will: + +- Execute a microservice application with resiliency enabled that continuously persists and retrieves state via Dapr's state management API. +- Trigger resiliency policies by simulating a system failure. +- Resolve the failure and the microservice application will resume. + +Diagram showing the resiliency applied to Dapr APIs + +Select your preferred language-specific Dapr SDK before proceeding with the Quickstart. + +{{< tabs "Python" "JavaScript" ".NET" "Java" "Go" >}} + +{{% codetab %}} + +### Pre-requisites + +For this example, you will need: + +- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started). +- [Python 3.7+ installed](https://www.python.org/downloads/). + +- [Docker Desktop](https://www.docker.com/products/docker-desktop) + + +### Step 1: Set up the environment + +Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quickstarts/tree/master/resiliency). + +```bash +git clone https://github.com/dapr/quickstarts.git +``` + +In a terminal window, navigate to the `order-processor` directory. + +```bash +cd ../state_management/python/sdk/order-processor +``` + +Install dependencies + +```bash +pip3 install -r requirements.txt +``` + +### Step 2: Run the application with resiliency enabled + +Run the `order-processor` service alongside a Dapr sidecar. In the `dapr run` command below, the `--config` parameter applies a Dapr configuration that enables the resiliency feature. By enabling resiliency, the resiliency spec located in the components directory is loaded by the `order-processor` sidecar. The resilency spec is: + + ```yaml + apiVersion: dapr.io/v1alpha1 + kind: Resiliency + metadata: + name: myresiliency + scopes: + - checkout + + spec: + policies: + retries: + retryForever: + policy: constant + maxInterval: 5s + maxRetries: -1 + + circuitBreakers: + simpleCB: + maxRequests: 1 + timeout: 5s + trip: consecutiveFailures >= 5 + + targets: + apps: + order-processor: + retry: retryForever + circuitBreaker: simpleCB + ``` + + +```bash +dapr run --app-id order-processor --config ../config.yaml --components-path ../../../components/ -- python3 +``` + +Once the application has started, the `order-processor`service writes and reads `orderId` key/value pairs to the `statestore` Redis instance [defined in the `statestore.yaml` component]({{< ref "statemanagement-quickstart.md#statestoreyaml-component-file" >}}). + +```bash +== APP == Saving Order: { orderId: '1' } +== APP == Getting Order: { orderId: '1' } +== APP == Saving Order: { orderId: '2' } +== APP == Getting Order: { orderId: '2' } +== APP == Saving Order: { orderId: '3' } +== APP == Getting Order: { orderId: '3' } +== APP == Saving Order: { orderId: '4' } +== APP == Getting Order: { orderId: '4' } +``` + +### Step 3: Introduce a fault + +Simulate a fault by stopping the Redis container instance that was initialized when executing `dapr init` on your development machine. Once the instance is stopped, write and read operations from the `order-processor` service begin to fail. + +Since the `resiliency.yaml` spec defines `statestore` as a component target, all failed requests will apply retry and circuit breaker policies: + +```yaml + targets: + components: + statestore: + outbound: + retry: retryForever + circuitBreaker: simpleCB +``` + +In a new terminal window, run the following command to stop Redis: + +```bash +docker stop dapr_redis +``` + +Once Redis is stopped, the requests begin to fail and the retry policy titled `retryForever` is applied. The output below shows the logs from the `order-processor` service: + +```bash +INFO[0006] Error processing operation component[statestore] output. Retrying... +``` + +As per the `retryFroever` policy, retries will continue for each failed request indefinitely, in 5 second intervals. + +```yaml +retryForever: + policy: constant + maxInterval: 5s + maxRetries: -1 +``` + +Once 5 consecutive retries have failed, the circuit breaker policy, `simpleCB`, is tripped and the breaker opens, halting all requests: + +```bash +INFO[0026] Circuit breaker "simpleCB-statestore" changed state from closed to open +``` + +```yaml +circuitBreakers: + simpleCB: + maxRequests: 1 + timeout: 5s + trip: consecutiveFailures >= 5 +``` + +After 5 seconds has surpassed, the circuit breaker will switch to a half-open state, allowing one request through to verify if the fault has been resolved. If the request continues to fail, the circuit will trip back to the open state. + +```bash +INFO[0031] Circuit breaker "simpleCB-statestore" changed state from open to half-open +INFO[0031] Circuit breaker "simpleCB-statestore" changed state from half-open to open +INFO[0036] Circuit breaker "simpleCB-statestore" changed state from open to half-open +INFO[0036] Circuit breaker "simpleCB-statestore" changed state from half-open to closed +``` + +This half-open/open behavior will continue for as long as the Redis container is stopped. + +### Step 3: Remove the fault + +Once you restart the Redis container on your machine, the application will recover seamlessly, picking up where it left off. + +```bash +docker start dapr_redis +``` + +```bash +INFO[0036] Recovered processing operation component[statestore] output. +== APP == Saving Order: { orderId: '5' } +== APP == Getting Order: { orderId: '5' } +== APP == Saving Order: { orderId: '6' } +== APP == Getting Order: { orderId: '6' } +== APP == Saving Order: { orderId: '7' } +== APP == Getting Order: { orderId: '7' } +== APP == Saving Order: { orderId: '8' } +== APP == Getting Order: { orderId: '8' } +== APP == Saving Order: { orderId: '9' } +== APP == Getting Order: { orderId: '9' } +``` + +{{% /codetab %}} + + +{{% codetab %}} + +### Pre-requisites + +For this example, you will need: + +- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started). +- [Latest Node.js installed](https://nodejs.org/download/). + +- [Docker Desktop](https://www.docker.com/products/docker-desktop) + + +### Step 1: Set up the environment + +Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quickstarts/tree/master/resiliency). + +```bash +git clone https://github.com/dapr/quickstarts.git +``` + +In a terminal window, navigate to the `order-processor` directory. + +```bash +cd ../state_management/javascript/sdk/order-processor +``` + +Install dependencies + +```bash +npm install +``` + +### Step 2: Run the application with resiliency enabled + +Run the `order-processor` service alongside a Dapr sidecar. In the `dapr run` command below, the `--config` parameter applies a Dapr configuration that enables the resiliency feature. By enabling resiliency, the resiliency spec located in the components directory is loaded by the `order-processor` sidecar. The resilency spec is: + + ```yaml + apiVersion: dapr.io/v1alpha1 + kind: Resiliency + metadata: + name: myresiliency + scopes: + - checkout + + spec: + policies: + retries: + retryForever: + policy: constant + maxInterval: 5s + maxRetries: -1 + + circuitBreakers: + simpleCB: + maxRequests: 1 + timeout: 5s + trip: consecutiveFailures >= 5 + + targets: + apps: + order-processor: + retry: retryForever + circuitBreaker: simpleCB + ``` + +```bash +dapr run --app-id order-processor --config ../config.yaml --components-path ../../../components/ -- npm start +``` + +Once the application has started, the `order-processor`service writes and reads `orderId` key/value pairs to the `statestore` Redis instance [defined in the `statestore.yaml` component]({{< ref "statemanagement-quickstart.md#statestoreyaml-component-file" >}}). + +```bash +== APP == Saving Order: { orderId: '1' } +== APP == Getting Order: { orderId: '1' } +== APP == Saving Order: { orderId: '2' } +== APP == Getting Order: { orderId: '2' } +== APP == Saving Order: { orderId: '3' } +== APP == Getting Order: { orderId: '3' } +== APP == Saving Order: { orderId: '4' } +== APP == Getting Order: { orderId: '4' } +``` + +### Step 3: Introduce a fault + +Simulate a fault by stopping the Redis container instance that was initialized when executing `dapr init` on your development machine. Once the instance is stopped, write and read operations from the `order-processor` service begin to fail. + +Since the `resiliency.yaml` spec defines `statestore` as a component target, all failed requests will apply retry and circuit breaker policies: + +```yaml + targets: + components: + statestore: + outbound: + retry: retryForever + circuitBreaker: simpleCB +``` + +In a new terminal window, run the following command to stop Redis: + +```bash +docker stop dapr_redis +``` + +Once Redis is stopped, the requests begin to fail and the retry policy titled `retryForever` is applied. The output below shows the logs from the `order-processor` service: + +```bash +INFO[0006] Error processing operation component[statestore] output. Retrying... +``` + +As per the `retryFroever` policy, retries will continue for each failed request indefinitely, in 5 second intervals. + +```yaml +retryForever: + policy: constant + maxInterval: 5s + maxRetries: -1 +``` + +Once 5 consecutive retries have failed, the circuit breaker policy, `simpleCB`, is tripped and the breaker opens, halting all requests: + +```bash +INFO[0026] Circuit breaker "simpleCB-statestore" changed state from closed to open +``` + +```yaml +circuitBreakers: + simpleCB: + maxRequests: 1 + timeout: 5s + trip: consecutiveFailures >= 5 +``` + +After 5 seconds has surpassed, the circuit breaker will switch to a half-open state, allowing one request through to verify if the fault has been resolved. If the request continues to fail, the circuit will trip back to the open state. + +```bash +INFO[0031] Circuit breaker "simpleCB-statestore" changed state from open to half-open +INFO[0031] Circuit breaker "simpleCB-statestore" changed state from half-open to open +INFO[0036] Circuit breaker "simpleCB-statestore" changed state from open to half-open +INFO[0036] Circuit breaker "simpleCB-statestore" changed state from half-open to closed +``` + +This half-open/open behavior will continue for as long as the Redis container is stopped. + +### Step 3: Remove the fault + +Once you restart the Redis container on your machine, the application will recover seamlessly, picking up where it left off. + +```bash +docker start dapr_redis +``` + +```bash +INFO[0036] Recovered processing operation component[statestore] output. +== APP == Saving Order: { orderId: '5' } +== APP == Getting Order: { orderId: '5' } +== APP == Saving Order: { orderId: '6' } +== APP == Getting Order: { orderId: '6' } +== APP == Saving Order: { orderId: '7' } +== APP == Getting Order: { orderId: '7' } +== APP == Saving Order: { orderId: '8' } +== APP == Getting Order: { orderId: '8' } +== APP == Saving Order: { orderId: '9' } +== APP == Getting Order: { orderId: '9' } +``` + +{{% /codetab %}} + + +{{% codetab %}} + +### Pre-requisites + +For this example, you will need: + +- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started). +- [.NET SDK or .NET 6 SDK installed](https://dotnet.microsoft.com/download). + +- [Docker Desktop](https://www.docker.com/products/docker-desktop) + + +### Step 1: Set up the environment + +Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quickstarts/tree/master/resiliency). + +```bash +git clone https://github.com/dapr/quickstarts.git +``` + +In a terminal window, navigate to the `order-processor` directory. + +```bash +cd ../state_management/csharp/sdk/order-processor +``` + +Install dependencies + +```bash +dotnet restore +dotnet build +``` + +### Step 2: Run the application with resiliency enabled + +Run the `order-processor` service alongside a Dapr sidecar. In the `dapr run` command below, the `--config` parameter applies a Dapr configuration that enables the resiliency feature. By enabling resiliency, the resiliency spec located in the components directory is loaded by the `order-processor` sidecar. The resilency spec is: + + ```yaml + apiVersion: dapr.io/v1alpha1 + kind: Resiliency + metadata: + name: myresiliency + scopes: + - checkout + + spec: + policies: + retries: + retryForever: + policy: constant + maxInterval: 5s + maxRetries: -1 + + circuitBreakers: + simpleCB: + maxRequests: 1 + timeout: 5s + trip: consecutiveFailures >= 5 + + targets: + apps: + order-processor: + retry: retryForever + circuitBreaker: simpleCB + ``` + +```bash +dapr run --app-id order-processor --config ../config.yaml --components-path ../../../components/ -- dotnet run +``` + +Once the application has started, the `order-processor`service writes and reads `orderId` key/value pairs to the `statestore` Redis instance [defined in the `statestore.yaml` component]({{< ref "statemanagement-quickstart.md#statestoreyaml-component-file" >}}). + +```bash +== APP == Saving Order: { orderId: '1' } +== APP == Getting Order: { orderId: '1' } +== APP == Saving Order: { orderId: '2' } +== APP == Getting Order: { orderId: '2' } +== APP == Saving Order: { orderId: '3' } +== APP == Getting Order: { orderId: '3' } +== APP == Saving Order: { orderId: '4' } +== APP == Getting Order: { orderId: '4' } +``` + +### Step 3: Introduce a fault + +Simulate a fault by stopping the Redis container instance that was initialized when executing `dapr init` on your development machine. Once the instance is stopped, write and read operations from the `order-processor` service begin to fail. + +Since the `resiliency.yaml` spec defines `statestore` as a component target, all failed requests will apply retry and circuit breaker policies: + +```yaml + targets: + components: + statestore: + outbound: + retry: retryForever + circuitBreaker: simpleCB +``` + +In a new terminal window, run the following command to stop Redis: + +```bash +docker stop dapr_redis +``` + +Once Redis is stopped, the requests begin to fail and the retry policy titled `retryForever` is applied. The output below shows the logs from the `order-processor` service: + +```bash +INFO[0006] Error processing operation component[statestore] output. Retrying... +``` + +As per the `retryFroever` policy, retries will continue for each failed request indefinitely, in 5 second intervals. + +```yaml +retryForever: + policy: constant + maxInterval: 5s + maxRetries: -1 +``` + +Once 5 consecutive retries have failed, the circuit breaker policy, `simpleCB`, is tripped and the breaker opens, halting all requests: + +```bash +INFO[0026] Circuit breaker "simpleCB-statestore" changed state from closed to open +``` + +```yaml +circuitBreakers: + simpleCB: + maxRequests: 1 + timeout: 5s + trip: consecutiveFailures >= 5 +``` + +After 5 seconds has surpassed, the circuit breaker will switch to a half-open state, allowing one request through to verify if the fault has been resolved. If the request continues to fail, the circuit will trip back to the open state. + +```bash +INFO[0031] Circuit breaker "simpleCB-statestore" changed state from open to half-open +INFO[0031] Circuit breaker "simpleCB-statestore" changed state from half-open to open +INFO[0036] Circuit breaker "simpleCB-statestore" changed state from open to half-open +INFO[0036] Circuit breaker "simpleCB-statestore" changed state from half-open to closed +``` + +This half-open/open behavior will continue for as long as the Redis container is stopped. + +### Step 3: Remove the fault + +Once you restart the Redis container on your machine, the application will recover seamlessly, picking up where it left off. + +```bash +docker start dapr_redis +``` + +```bash +INFO[0036] Recovered processing operation component[statestore] output. +== APP == Saving Order: { orderId: '5' } +== APP == Getting Order: { orderId: '5' } +== APP == Saving Order: { orderId: '6' } +== APP == Getting Order: { orderId: '6' } +== APP == Saving Order: { orderId: '7' } +== APP == Getting Order: { orderId: '7' } +== APP == Saving Order: { orderId: '8' } +== APP == Getting Order: { orderId: '8' } +== APP == Saving Order: { orderId: '9' } +== APP == Getting Order: { orderId: '9' } +``` + +{{% /codetab %}} + + +{{% codetab %}} + +### Pre-requisites + +For this example, you will need: + +- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started). +- Java JDK 11 (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. + +- [Docker Desktop](https://www.docker.com/products/docker-desktop) + + +### Step 1: Set up the environment + +Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quickstarts/tree/master/resiliency). + +```bash +git clone https://github.com/dapr/quickstarts.git +``` + +In a terminal window, navigate to the `order-processor` directory. + +```bash +cd ../state_management/java/sdk/order-processor +``` + +Install dependencies + +```bash +mvn clean install +``` + +### Step 2: Run the application with resiliency enabled + +Run the `order-processor` service alongside a Dapr sidecar. In the `dapr run` command below, the `--config` parameter applies a Dapr configuration that enables the resiliency feature. By enabling resiliency, the resiliency spec located in the components directory is loaded by the `order-processor` sidecar. The resilency spec is: + + ```yaml + apiVersion: dapr.io/v1alpha1 + kind: Resiliency + metadata: + name: myresiliency + scopes: + - checkout + + spec: + policies: + retries: + retryForever: + policy: constant + maxInterval: 5s + maxRetries: -1 + + circuitBreakers: + simpleCB: + maxRequests: 1 + timeout: 5s + trip: consecutiveFailures >= 5 + + targets: + apps: + order-processor: + retry: retryForever + circuitBreaker: simpleCB + ``` + +```bash +dapr run --app-id order-processor --config ../config.yaml --components-path ../../../components/ -- java -jar target/OrderProcessingService-0.0.1-SNAPSHOT.jar +``` + +Once the application has started, the `order-processor`service writes and reads `orderId` key/value pairs to the `statestore` Redis instance [defined in the `statestore.yaml` component]({{< ref "statemanagement-quickstart.md#statestoreyaml-component-file" >}}). + +```bash +== APP == Saving Order: { orderId: '1' } +== APP == Getting Order: { orderId: '1' } +== APP == Saving Order: { orderId: '2' } +== APP == Getting Order: { orderId: '2' } +== APP == Saving Order: { orderId: '3' } +== APP == Getting Order: { orderId: '3' } +== APP == Saving Order: { orderId: '4' } +== APP == Getting Order: { orderId: '4' } +``` + +### Step 3: Introduce a fault + +Simulate a fault by stopping the Redis container instance that was initialized when executing `dapr init` on your development machine. Once the instance is stopped, write and read operations from the `order-processor` service begin to fail. + +Since the `resiliency.yaml` spec defines `statestore` as a component target, all failed requests will apply retry and circuit breaker policies: + +```yaml + targets: + components: + statestore: + outbound: + retry: retryForever + circuitBreaker: simpleCB +``` + +In a new terminal window, run the following command to stop Redis: + +```bash +docker stop dapr_redis +``` + +Once Redis is stopped, the requests begin to fail and the retry policy titled `retryForever` is applied. The output below shows the logs from the `order-processor` service: + +```bash +INFO[0006] Error processing operation component[statestore] output. Retrying... +``` + +As per the `retryFroever` policy, retries will continue for each failed request indefinitely, in 5 second intervals. + +```yaml +retryForever: + policy: constant + maxInterval: 5s + maxRetries: -1 +``` + +Once 5 consecutive retries have failed, the circuit breaker policy, `simpleCB`, is tripped and the breaker opens, halting all requests: + +```bash +INFO[0026] Circuit breaker "simpleCB-statestore" changed state from closed to open +``` + +```yaml +circuitBreakers: + simpleCB: + maxRequests: 1 + timeout: 5s + trip: consecutiveFailures >= 5 +``` + +After 5 seconds has surpassed, the circuit breaker will switch to a half-open state, allowing one request through to verify if the fault has been resolved. If the request continues to fail, the circuit will trip back to the open state. + +```bash +INFO[0031] Circuit breaker "simpleCB-statestore" changed state from open to half-open +INFO[0031] Circuit breaker "simpleCB-statestore" changed state from half-open to open +INFO[0036] Circuit breaker "simpleCB-statestore" changed state from open to half-open +INFO[0036] Circuit breaker "simpleCB-statestore" changed state from half-open to closed +``` + +This half-open/open behavior will continue for as long as the Redis container is stopped. + +### Step 3: Remove the fault + +Once you restart the Redis container on your machine, the application will recover seamlessly, picking up where it left off. + +```bash +docker start dapr_redis +``` + +```bash +INFO[0036] Recovered processing operation component[statestore] output. +== APP == Saving Order: { orderId: '5' } +== APP == Getting Order: { orderId: '5' } +== APP == Saving Order: { orderId: '6' } +== APP == Getting Order: { orderId: '6' } +== APP == Saving Order: { orderId: '7' } +== APP == Getting Order: { orderId: '7' } +== APP == Saving Order: { orderId: '8' } +== APP == Getting Order: { orderId: '8' } +== APP == Saving Order: { orderId: '9' } +== APP == Getting Order: { orderId: '9' } +``` + +{{% /codetab %}} + + +{{% codetab %}} + +### Pre-requisites + +For this example, you will need: + +- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started). +- [Latest version of Go](https://go.dev/dl/). + +- [Docker Desktop](https://www.docker.com/products/docker-desktop) + + +### Step 1: Set up the environment + +Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quickstarts/tree/master/resiliency). + +```bash +git clone https://github.com/dapr/quickstarts.git +``` + +In a terminal window, navigate to the `order-processor` directory. + +```bash +cd ../state_management/go/sdk/order-processor +``` + +Install dependencies + +```bash +go build . +``` + +### Step 2: Run the application with resiliency enabled + +Run the `order-processor` service alongside a Dapr sidecar. In the `dapr run` command below, the `--config` parameter applies a Dapr configuration that enables the resiliency feature. By enabling resiliency, the resiliency spec located in the components directory is loaded by the `order-processor` sidecar. The resilency spec is: + + ```yaml + apiVersion: dapr.io/v1alpha1 + kind: Resiliency + metadata: + name: myresiliency + scopes: + - checkout + + spec: + policies: + retries: + retryForever: + policy: constant + maxInterval: 5s + maxRetries: -1 + + circuitBreakers: + simpleCB: + maxRequests: 1 + timeout: 5s + trip: consecutiveFailures >= 5 + + targets: + apps: + order-processor: + retry: retryForever + circuitBreaker: simpleCB + ``` + +```bash +dapr run --app-id order-processor --config ../config.yaml --components-path ../../../components -- go run . +``` + +Once the application has started, the `order-processor`service writes and reads `orderId` key/value pairs to the `statestore` Redis instance [defined in the `statestore.yaml` component]({{< ref "statemanagement-quickstart.md#statestoreyaml-component-file" >}}). + +```bash +== APP == Saving Order: { orderId: '1' } +== APP == Getting Order: { orderId: '1' } +== APP == Saving Order: { orderId: '2' } +== APP == Getting Order: { orderId: '2' } +== APP == Saving Order: { orderId: '3' } +== APP == Getting Order: { orderId: '3' } +== APP == Saving Order: { orderId: '4' } +== APP == Getting Order: { orderId: '4' } +``` + +### Step 3: Introduce a fault + +Simulate a fault by stopping the Redis container instance that was initialized when executing `dapr init` on your development machine. Once the instance is stopped, write and read operations from the `order-processor` service begin to fail. + +Since the `resiliency.yaml` spec defines `statestore` as a component target, all failed requests will apply retry and circuit breaker policies: + +```yaml + targets: + components: + statestore: + outbound: + retry: retryForever + circuitBreaker: simpleCB +``` + +In a new terminal window, run the following command to stop Redis: + +```bash +docker stop dapr_redis +``` + +Once Redis is stopped, the requests begin to fail and the retry policy titled `retryForever` is applied. The output belows shows the logs from the `order-processor` service: + +```bash +INFO[0006] Error processing operation component[statestore] output. Retrying... +``` + +As per the `retryFroever` policy, retries will continue for each failed request indefinitely, in 5 second intervals. + +```yaml +retryForever: + policy: constant + maxInterval: 5s + maxRetries: -1 +``` + +Once 5 consecutive retries have failed, the circuit breaker policy, `simpleCB`, is tripped and the breaker opens, halting all requests: + +```bash +INFO[0026] Circuit breaker "simpleCB-statestore" changed state from closed to open +``` + +```yaml +circuitBreakers: + simpleCB: + maxRequests: 1 + timeout: 5s + trip: consecutiveFailures >= 5 +``` + +After 5 seconds has surpassed, the circuit breaker will switch to a half-open state, allowing one request through to verify if the fault has been resolved. If the request continues to fail, the circuit will trip back to the open state. + +```bash +INFO[0031] Circuit breaker "simpleCB-statestore" changed state from open to half-open +INFO[0031] Circuit breaker "simpleCB-statestore" changed state from half-open to open +INFO[0036] Circuit breaker "simpleCB-statestore" changed state from open to half-open +INFO[0036] Circuit breaker "simpleCB-statestore" changed state from half-open to closed +``` + +This half-open/open behavior will continue for as long as the Redis container is stopped. + +### Step 3: Remove the fault + +Once you restart the Redis container on your machine, the application will recover seamlessly, picking up where it left off. + +```bash +docker start dapr_redis +``` + +```bash +INFO[0036] Recovered processing operation component[statestore] output. +== APP == Saving Order: { orderId: '5' } +== APP == Getting Order: { orderId: '5' } +== APP == Saving Order: { orderId: '6' } +== APP == Getting Order: { orderId: '6' } +== APP == Saving Order: { orderId: '7' } +== APP == Getting Order: { orderId: '7' } +== APP == Saving Order: { orderId: '8' } +== APP == Getting Order: { orderId: '8' } +== APP == Saving Order: { orderId: '9' } +== APP == Getting Order: { orderId: '9' } +``` + +{{% /codetab %}} + +{{< /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). + +## Next steps + +Learn more about [the resiliency feature]({{< ref resiliency-overview.md >}}) and how it works with Dapr's building block APIs. + +{{< button text="Explore Dapr tutorials >>" page="getting-started/tutorials/_index.md" >}} diff --git a/daprdocs/content/en/getting-started/tutorials/configure-state-pubsub.md b/daprdocs/content/en/getting-started/tutorials/configure-state-pubsub.md index df08db4ca39..7e394d70842 100644 --- a/daprdocs/content/en/getting-started/tutorials/configure-state-pubsub.md +++ b/daprdocs/content/en/getting-started/tutorials/configure-state-pubsub.md @@ -64,9 +64,7 @@ For Kubernetes: {{% /codetab %}} {{% codetab %}} - -Verify you have an [Azure subscription](https://azure.microsoft.com/free/). - +Verify you have an Azure subscription. 1. Open and log into the [Azure portal](https://ms.portal.azure.com/#create/Microsoft.Cache) to start the Azure Redis Cache creation flow. 1. Fill out the necessary information. diff --git a/daprdocs/content/en/operations/components/pluggable-components/pluggable-components-registration.md b/daprdocs/content/en/operations/components/pluggable-components/pluggable-components-registration.md index c1242eaf874..068780d3b58 100644 --- a/daprdocs/content/en/operations/components/pluggable-components/pluggable-components-registration.md +++ b/daprdocs/content/en/operations/components/pluggable-components/pluggable-components-registration.md @@ -174,11 +174,8 @@ spec: - name: component volumeMounts: # required, the sockets volume mount - name: dapr-unix-domain-socket - mountPath: /dapr-unix-domain-sockets + mountPath: /tmp/dapr-components-sockets image: YOUR_IMAGE_GOES_HERE:YOUR_IMAGE_VERSION - env: - - name: DAPR_COMPONENTS_SOCKETS_FOLDER # Tells the component where the sockets should be created. - value: /dapr-unix-domain-sockets ``` Before applying the deployment, let's add one more configuration: the component spec. diff --git a/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-job.md b/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-job.md index 6691c742cdd..0b2139fddc7 100644 --- a/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-job.md +++ b/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-job.md @@ -14,9 +14,12 @@ To address this issue the Dapr sidecar has an endpoint to `Shutdown` the sidecar When running a basic [Kubernetes Job](https://kubernetes.io/docs/concepts/workloads/controllers/job/) you will need to call the `/shutdown` endpoint for the sidecar to gracefully stop and the job will be considered `Completed`. -When a job is finish without calling `Shutdown` your job will be in a `NotReady` state with only the `daprd` container running endlessly. +When a job is finished without calling `Shutdown`, your job will be in a `NotReady` state with only the `daprd` container running endlessly. -Be sure and use the *POST* HTTP verb when calling the shutdown API. +Stopping the dapr sidecar will cause its readiness and liveness probes to fail in your container because the dapr sidecar was shutdown. +To prevent Kubernetes from trying to restart your job, set your job's `restartPolicy` to `Never`. + +Be sure to use the *POST* HTTP verb when calling the shutdown HTTP API. ```yaml apiVersion: batch/v1 @@ -37,7 +40,7 @@ spec: restartPolicy: Never ``` -You can also call the `Shutdown` from any of the Dapr SDK +You can also call the `Shutdown` from any of the Dapr SDKs ```go package main diff --git a/daprdocs/content/en/operations/hosting/self-hosted/self-hosted-no-docker.md b/daprdocs/content/en/operations/hosting/self-hosted/self-hosted-no-docker.md index 0fdf85a6ab3..8bbe050cdb1 100644 --- a/daprdocs/content/en/operations/hosting/self-hosted/self-hosted-no-docker.md +++ b/daprdocs/content/en/operations/hosting/self-hosted/self-hosted-no-docker.md @@ -6,36 +6,49 @@ weight: 30000 description: "How to deploy and run Dapr in self-hosted mode without Docker installed on the local machine" --- -This article provides guidance on running Dapr in self-hosted mode without Docker. - ## Prerequisites -- [Dapr CLI]({{< ref "install-dapr-selfhost.md#installing-dapr-cli" >}}) +- [Install the Dapr CLI]({{< ref "install-dapr-selfhost.md#installing-dapr-cli" >}}) ## Initialize Dapr without containers -The Dapr CLI provides an option to initialize Dapr using slim init, without the default creation of a development environment which has a dependency on Docker. To initialize Dapr with slim init, after installing the Dapr CLI use the following command: +The Dapr CLI provides an option to initialize Dapr using slim init, without the default creation of a development environment with a dependency on Docker. To initialize Dapr with slim init, after installing the Dapr CLI, use the following command: ```bash dapr init --slim ``` -In this mode two different binaries are installed `daprd` and `placement`. The `placement` binary is needed to enable [actors]({{< ref "actors-overview.md" >}}) in a Dapr self-hosted installation. +Two different binaries are installed: +- `daprd` +- `placement` + +The `placement` binary is needed to enable [actors]({{< ref "actors-overview.md" >}}) in a Dapr self-hosted installation. + +In slim init mode, no default components (such as Redis) are installed for state management or pub/sub. This means that, aside from [service invocation]({{< ref "service-invocation-overview.md" >}}), no other building block functionality is available "out-of-the-box" on install. Instead, you can set up your own environment and custom components. + +Actor-based service invocation is possible if a state store is configured, as explained in the following sections. + +## Perform service invocation +See [the _Hello Dapr slim_ sample](https://github.com/dapr/samples/tree/master/hello-dapr-slim) for an example on how to perform service invocation in slim init mode. -In this mode no default components such as Redis are installed for state management or pub/sub. This means, that aside from [Service Invocation]({{< ref "service-invocation-overview.md" >}}), no other building block functionality is available on install out of the box. Users are free to setup their own environment and custom components. Furthermore, actor based service invocation is possible if a state store is configured as explained in the following sections. +## Enable state management or pub/sub -## Service invocation -See [this sample](https://github.com/dapr/samples/tree/master/hello-dapr-slim) for an example on how to perform service invocation in this mode. +See documentation around [configuring Redis in self-hosted mode without Docker](https://redis.io/topics/quickstart) to enable a local state store or pub/sub broker for messaging. -## Enabling state management or pub/sub +## Enable actors -See configuring Redis in self-hosted mode [without docker](https://redis.io/topics/quickstart) to enable a local state store or pub/sub broker for messaging. +To enable actor placement: +- Run the placement service locally. +- Enable a [transactional state store that supports ETags]({{< ref "supported-state-stores.md" >}}) to use actors. For example, [Redis configured in self-hosted mode](https://redis.io/topics/quickstart). -## Enabling actors +By default, the `placement` binary is installed in: -The placement service must be run locally to enable actor placement. Also, a [transactional state store that supports ETags]({{< ref "supported-state-stores.md" >}}) must be enabled to use actors, for example, [Redis configured in self-hosted mode](https://redis.io/topics/quickstart). +- For Linux/MacOS: `/$HOME/.dapr/bin` +- For Windows: `%USERPROFILE%\.dapr\bin` -By default for Linux/MacOS the `placement` binary is installed in `/$HOME/.dapr/bin` or for Windows at `%USERPROFILE%\.dapr\bin`. +{{< tabs "Linux/MacOS" "Windows">}} + +{{% codetab %}} ```bash $ $HOME/.dapr/bin/placement @@ -51,16 +64,48 @@ INFO[0001] leader is established. instance=Nicoletaz-L10. ``` -From here on you can follow the sample example created for the [java-sdk](https://github.com/dapr/java-sdk/tree/master/examples/src/main/java/io/dapr/examples/actors), [python-sdk](https://github.com/dapr/python-sdk/tree/master/examples/demo_actor) or [dotnet-sdk]({{< ref "dotnet-actors-howto.md" >}}) for running an application with Actors enabled. +{{% /codetab %}} + +{{% codetab %}} + +When running standalone placement on Windows, specify port 6050: + +```bash +%USERPROFILE%/.dapr/bin/placement.exe -port 6050 + +time="2022-10-17T14:56:55.4055836-05:00" level=info msg="starting Dapr Placement Service -- version 1.9.0 -- commit fdce5f1f1b76012291c888113169aee845f25ef8" instance=LAPTOP-OMK50S19 scope=dapr.placement type=log ver=1.9.0 +time="2022-10-17T14:56:55.4066226-05:00" level=info msg="log level set to: info" instance=LAPTOP-OMK50S19 scope=dapr.placement type=log ver=1.9.0 +time="2022-10-17T14:56:55.4067306-05:00" level=info msg="metrics server started on :9090/" instance=LAPTOP-OMK50S19 scope=dapr.metrics type=log ver=1.9.0 +time="2022-10-17T14:56:55.4077529-05:00" level=info msg="Raft server is starting on 127.0.0.1:8201..." instance=LAPTOP-OMK50S19 scope=dapr.placement.raft type=log ver=1.9.0 +time="2022-10-17T14:56:55.4077529-05:00" level=info msg="placement service started on port 6050" instance=LAPTOP-OMK50S19 scope=dapr.placement type=log ver=1.9.0 +time="2022-10-17T14:56:55.4082772-05:00" level=info msg="Healthz server is listening on :8080" instance=LAPTOP-OMK50S19 scope=dapr.placement type=log ver=1.9.0 +time="2022-10-17T14:56:56.8232286-05:00" level=info msg="cluster leadership acquired" instance=LAPTOP-OMK50S19 scope=dapr.placement type=log ver=1.9.0 +time="2022-10-17T14:56:56.8232286-05:00" level=info msg="leader is established." instance=LAPTOP-OMK50S19 scope=dapr.placement type=log ver=1.9.0 + +``` + +{{% /codetab %}} + +{{< /tabs >}} + +Now, to run an application with actors enabled, you can follow the sample example created for: +- [java-sdk](https://github.com/dapr/java-sdk/tree/master/examples/src/main/java/io/dapr/examples/actors) +- [python-sdk](https://github.com/dapr/python-sdk/tree/master/examples/demo_actor) +- [dotnet-sdk]({{< ref "dotnet-actors-howto.md" >}}) + +Update the state store configuration files to match the Redis host and password with your setup. -Update the state store configuration files to have the Redis host and password match the setup that you have. Additionally to enable it as a actor state store have the metadata piece added similar to the [sample Java Redis component](https://github.com/dapr/java-sdk/blob/master/examples/components/state/redis.yaml) definition. +Enable it as a actor state store by making the metadata piece similar to the [sample Java Redis component](https://github.com/dapr/java-sdk/blob/master/examples/components/state/redis.yaml) definition. ```yaml - name: actorStateStore value: "true" ``` +## Clean up -## Cleanup +When finished, remove the binaries by following [Uninstall Dapr in a self-hosted environment]({{< ref self-hosted-uninstall >}}) to remove the binaries. -Follow the uninstall [instructions]({{< ref "install-dapr-selfhost.md#uninstall-dapr-in-a-self-hosted-mode" >}}) to remove the binaries. +## Next steps +- Run Dapr with [Podman]({{< ref self-hosted-with-podman.md >}}), using the default [Docker]({{< ref install-dapr-selfhost.md >}}), or in an [airgap environment]({{< ref self-hosted-airgap.md >}}) +- [Upgrade Dapr in self-hosted mode]({{< ref self-hosted-upgrade >}}) \ No newline at end of file diff --git a/daprdocs/content/en/operations/monitoring/logging/fluentd.md b/daprdocs/content/en/operations/monitoring/logging/fluentd.md index 4dbd1d171e8..b456b8d953e 100644 --- a/daprdocs/content/en/operations/monitoring/logging/fluentd.md +++ b/daprdocs/content/en/operations/monitoring/logging/fluentd.md @@ -32,25 +32,25 @@ description: "How to install Fluentd, Elastic Search, and Kibana to search logs By default, the chart creates 3 replicas which must be on different nodes. If your cluster has fewer than 3 nodes, specify a smaller number of replicas. For example, this sets the number of replicas to 1: ```bash - helm install elasticsearch elastic/elasticsearch -n dapr-monitoring --set replicas=1 + helm install elasticsearch elastic/elasticsearch --version 7.17.3 -n dapr-monitoring --set replicas=1 ``` Otherwise: ```bash - helm install elasticsearch elastic/elasticsearch -n dapr-monitoring + helm install elasticsearch elastic/elasticsearch --version 7.17.3 -n dapr-monitoring ``` If you are using minikube or simply want to disable persistent volumes for development purposes, you can do so by using the following command: ```bash - helm install elasticsearch elastic/elasticsearch -n dapr-monitoring --set persistence.enabled=false,replicas=1 + helm install elasticsearch elastic/elasticsearch --version 7.17.3 -n dapr-monitoring --set persistence.enabled=false,replicas=1 ``` 4. Install Kibana ```bash - helm install kibana elastic/kibana -n dapr-monitoring + helm install kibana elastic/kibana --version 7.17.3 -n dapr-monitoring ``` 5. Ensure that Elastic Search and Kibana are running in your Kubernetes cluster diff --git a/daprdocs/content/en/operations/monitoring/metrics/grafana.md b/daprdocs/content/en/operations/monitoring/metrics/grafana.md index 7bdc29eade8..edbd807bdc4 100644 --- a/daprdocs/content/en/operations/monitoring/metrics/grafana.md +++ b/daprdocs/content/en/operations/monitoring/metrics/grafana.md @@ -42,6 +42,7 @@ The `grafana-actor-dashboard.json` template shows Dapr Sidecar status, actor inv ```bash helm repo add grafana https://grafana.github.io/helm-charts + helm repo update ``` 1. Install the chart: @@ -176,4 +177,4 @@ First you need to connect Prometheus as a data source to Grafana.
-
\ No newline at end of file + diff --git a/daprdocs/content/en/operations/resiliency/resiliency-overview.md b/daprdocs/content/en/operations/resiliency/resiliency-overview.md index bbca61db52e..fea52eca2f9 100644 --- a/daprdocs/content/en/operations/resiliency/resiliency-overview.md +++ b/daprdocs/content/en/operations/resiliency/resiliency-overview.md @@ -9,8 +9,6 @@ description: "Configure Dapr retries, timeouts, and circuit breakers" Resiliency is currently a preview feature. Before you can utilize a resiliency spec, you must first [enable the resiliency preview feature]({{< ref support-preview-features >}}). {{% /alert %}} -Distributed applications are commonly comprised of many microservices, with dozens, even hundreds, of instances for any given application. With so many microservices, the likelihood of a system failure increases. For example, an instance can fail or be unresponsive due to hardware, an overwhelming number of requests, application restarts/scale outs, or several other reasons. These events can cause a network call between services to fail. Designing and implementing your application with fault tolerance, the ability to detect, mitigate, and respond to failures, allows your application to recover to a functioning state and become self healing. - Dapr provides a capability for defining and applying fault tolerance resiliency policies via a [resiliency spec]({{< ref "resiliency-overview.md#complete-example-policy" >}}). Resiliency specs are saved in the same location as components specs and are applied when the Dapr sidecar starts. The sidecar determines how to apply resiliency policies to your Dapr API calls. In self-hosted mode, the resiliency spec must be named `resiliency.yaml`. In Kubernetes Dapr finds the named resiliency specs used by your application. Within the resiliency spec, you can define policies for popular resiliency patterns, such as: - [Timeouts]({{< ref "policies.md#timeouts" >}}) diff --git a/daprdocs/content/en/operations/support/support-preview-features.md b/daprdocs/content/en/operations/support/support-preview-features.md index 72cfb47ab21..224d2e0654c 100644 --- a/daprdocs/content/en/operations/support/support-preview-features.md +++ b/daprdocs/content/en/operations/support/support-preview-features.md @@ -17,7 +17,6 @@ For CLI there is no explicit opt-in, just the version that this was first made a | ---------- |-------------|---------|---------------|-----------------| | **`--image-registry`** flag in Dapr CLI| In self hosted mode you can set this flag to specify any private registry to pull the container images required to install Dapr| N/A | [CLI init command reference]({{}}) | v1.7 | | **Resiliency** | Allows configuring of fine-grained policies for retries, timeouts and circuitbreaking. | `Resiliency` | [Configure Resiliency Policies]({{}}) | v1.7| -| **Service invocation without default `content-type`** | When enabled removes the default service invocation content-type header value `application/json` when no content-type is provided. This will become the default behavior in release v1.9.0. This requires you to explicitly set content-type headers where required for your apps. | `ServiceInvocation.NoDefaultContentType` | [Service Invocation]({{}}) | v1.7 | | **App Middleware** | Allow middleware components to be executed when making service-to-service calls | N/A | [App Middleware]({{}}) | v1.9 | | **App health checks** | Allows configuring app health checks | `AppHealthCheck` | [App health checks]({{}}) | v1.9 | | **Pluggable components** | Allows creating self-hosted gRPC-based components written in any language that supports gRPC. The following component APIs are supported: State stores, Pub/sub, Bindings | N/A | [Pluggable components concept]({{}})| v1.9 | diff --git a/daprdocs/content/en/operations/support/support-release-policy.md b/daprdocs/content/en/operations/support/support-release-policy.md index b6411eaf2d4..d83034d584b 100644 --- a/daprdocs/content/en/operations/support/support-release-policy.md +++ b/daprdocs/content/en/operations/support/support-release-policy.md @@ -34,13 +34,20 @@ The table below shows the versions of Dapr releases that have been tested togeth | Release date | Runtime | CLI | SDKs | Dashboard | Status | |--------------------|:--------:|:--------|---------|---------|---------| -| October 13th 2022 | 1.9.0
| 1.9.0 | Java 1.7.0
Go 1.6.0
PHP 1.1.0
Python 1.8.1
.NET 1.9.0
JS 2.4.2 | 0.11.0 | Supported (current) | +| December 2nd 2022 | 1.9.5
| 1.9.1 | Java 1.7.0
Go 1.6.0
PHP 1.1.0
Python 1.8.3
.NET 1.9.0
JS 2.4.2 | 0.11.0 | Supported (current) | +| November 17th 2022 | 1.9.4
| 1.9.1 | Java 1.7.0
Go 1.6.0
PHP 1.1.0
Python 1.8.3
.NET 1.9.0
JS 2.4.2 | 0.11.0 | Supported | +| November 4th 2022 | 1.9.3
| 1.9.1 | Java 1.7.0
Go 1.6.0
PHP 1.1.0
Python 1.8.3
.NET 1.9.0
JS 2.4.2 | 0.11.0 | Supported | +| November 1st 2022 | 1.9.2
| 1.9.1 | Java 1.7.0
Go 1.6.0
PHP 1.1.0
Python 1.8.1
.NET 1.9.0
JS 2.4.2 | 0.11.0 | Supported | +| October 26th 2022 | 1.9.1
| 1.9.1 | Java 1.7.0
Go 1.6.0
PHP 1.1.0
Python 1.8.1
.NET 1.9.0
JS 2.4.2 | 0.11.0 | Supported | +| October 13th 2022 | 1.9.0
| 1.9.1 | Java 1.7.0
Go 1.6.0
PHP 1.1.0
Python 1.8.3
.NET 1.9.0
JS 2.4.2 | 0.11.0 | Supported | +| October 26th 2022 | 1.8.6
| 1.8.1 | Java 1.6.0
Go 1.5.0
PHP 1.1.0
Python 1.7.0
.NET 1.8.0
JS 2.3.0 | 0.11.0 | Supported | | October 13th 2022 | 1.8.5
| 1.8.1 | Java 1.6.0
Go 1.5.0
PHP 1.1.0
Python 1.7.0
.NET 1.8.0
JS 2.3.0 | 0.11.0 | Supported | | August 10th 2022 | 1.8.4
| 1.8.1 | Java 1.6.0
Go 1.5.0
PHP 1.1.0
Python 1.7.0
.NET 1.8.0
JS 2.3.0 | 0.11.0 | Supported | | July 29th 2022 | 1.8.3
| 1.8.0 | Java 1.6.0
Go 1.5.0
PHP 1.1.0
Python 1.7.0
.NET 1.8.0
JS 2.3.0 | 0.11.0 | Supported | | July 21st 2022 | 1.8.2
| 1.8.0 | Java 1.6.0
Go 1.5.0
PHP 1.1.0
Python 1.7.0
.NET 1.8.0
JS 2.3.0 | 0.11.0 | Supported | | July 20th 2022 | 1.8.1
| 1.8.0 | Java 1.6.0
Go 1.5.0
PHP 1.1.0
Python 1.7.0
.NET 1.8.0
JS 2.3.0 | 0.11.0 | Supported | | July 7th 2022 | 1.8.0
| 1.8.0 | Java 1.6.0
Go 1.5.0
PHP 1.1.0
Python 1.7.0
.NET 1.8.0
JS 2.3.0 | 0.11.0 | Supported | +| October 26th 2022 | 1.7.5
| 1.7.0 | Java 1.5.0
Go 1.4.0
PHP 1.1.0
Python 1.6.0
.NET 1.7.0
JS 2.2.1 | 0.10.0 | Supported | | May 31st 2022 | 1.7.4
| 1.7.0 | Java 1.5.0
Go 1.4.0
PHP 1.1.0
Python 1.6.0
.NET 1.7.0
JS 2.2.1 | 0.10.0 | Supported | | May 17th 2022 | 1.7.3
| 1.7.0 | Java 1.5.0
Go 1.4.0
PHP 1.1.0
Python 1.6.0
.NET 1.7.0
JS 2.2.1 | 0.10.0 | Supported | | Apr 22th 2022 | 1.7.2
| 1.7.0 | Java 1.5.0
Go 1.4.0
PHP 1.1.0
Python 1.6.0
.NET 1.7.0
JS 2.1.0 | 0.10.0 | Supported | @@ -70,19 +77,18 @@ General guidance on upgrading can be found for [self hosted mode]({{< ref self-h | Current Runtime version | Must upgrade through | Target Runtime version | |--------------------------|-----------------------|------------------------- | -| 1.4.0 to 1.4.2 | N/A | 1.4.4 | -| | 1.4.4 | 1.5.2 | -| | 1.5.2 | 1.6.0 | -| | 1.6.0 | 1.6.2 | -| | 1.6.0 | 1.7.4 | | 1.5.0 to 1.5.2 | N/A | 1.6.0 | | | 1.6.0 | 1.6.2 | -| | 1.6.0 | 1.7.4 | -| 1.6.0 | N/A | 1.6.2 | -| 1.6.0 | N/A | 1.7.4 | -| 1.7.0 to 1.7.4 | N/A | 1.8.0 | -| 1.8.0 | N/A | 1.8.5 | -| 1.9.0 | N/A | 1.9.0 | +| | 1.6.2 | 1.7.5 | +| | 1.7.5 | 1.8.6 | +| | 1.8.6 | 1.9.5 | +| 1.6.0 to 1.6.2 | N/A | 1.7.5 | +| | 1.7.5 | 1.8.6 | +| | 1.8.6 | 1.9.5 | +| 1.7.0 to 1.7.5 | N/A | 1.8.6 | +| | 1.8.6 | 1.9.5 | +| 1.8.0 to 1.8.6 | N/A | 1.9.5 | +| 1.9.0 | N/A | 1.9.5 | ## Breaking changes and deprecations diff --git a/daprdocs/content/en/reference/api/distributed_lock_api.md b/daprdocs/content/en/reference/api/distributed_lock_api.md index ba250e3ae09..f7927021882 100644 --- a/daprdocs/content/en/reference/api/distributed_lock_api.md +++ b/daprdocs/content/en/reference/api/distributed_lock_api.md @@ -21,7 +21,7 @@ POST http://localhost:/v1.0-alpha1/lock/ Parameter | Description --------- | ----------- `daprPort` | The Dapr port -`storename` | The `metadata.name` field component file. Refer to the [component schema] ({{< ref component-schema.md>}}) +`storename` | The `metadata.name` field component file. Refer to the [component schema]({{< ref component-schema.md >}}) #### Query Parameters @@ -95,7 +95,7 @@ POST http://localhost:/v1.0-alpha1/unlock/ Parameter | Description --------- | ----------- `daprPort` | The Dapr port -`storename` | The `metadata.name` field component file. Refer to the [component schema] ({{< ref component-schema.md>}}) +`storename` | The `metadata.name` field component file. Refer to the [component schema]({{< ref component-schema.md >}}) #### Query Parameters diff --git a/daprdocs/content/en/reference/components-reference/supported-bindings/eventgrid.md b/daprdocs/content/en/reference/components-reference/supported-bindings/eventgrid.md index d422a19c726..a7f9a3c995f 100644 --- a/daprdocs/content/en/reference/components-reference/supported-bindings/eventgrid.md +++ b/daprdocs/content/en/reference/components-reference/supported-bindings/eventgrid.md @@ -44,7 +44,7 @@ spec: - name: accessKey value: "[AccessKey]" - name: topicEndpoint - value: "[TopicEndpoint] + value: "[TopicEndpoint]" ``` {{% alert title="Warning" color="warning" %}} @@ -102,7 +102,7 @@ _Make sure to also to add quotes around the `[HandshakePort]` in your Event Grid ```bash # Using random port 9000 as an example -ngrok http -host-header=localhost 9000 +ngrok http --host-header=localhost 9000 ``` - Configure the ngrok's HTTPS endpoint and custom port to input binding metadata diff --git a/daprdocs/content/en/reference/components-reference/supported-bindings/redis.md b/daprdocs/content/en/reference/components-reference/supported-bindings/redis.md index 8fabd7bc3df..8fe7638e048 100644 --- a/daprdocs/content/en/reference/components-reference/supported-bindings/redis.md +++ b/daprdocs/content/en/reference/components-reference/supported-bindings/redis.md @@ -66,10 +66,14 @@ The above example uses secrets as plain strings. It is recommended to use a secr This component supports **output binding** with the following operations: - `create` +- `get` +- `delete` + +### create You can store a record in Redis using the `create` operation. This sets a key to hold a value. If the key already exists, the value is overwritten. -### Request +#### Request ```json { @@ -84,10 +88,58 @@ You can store a record in Redis using the `create` operation. This sets a key to } ``` -### Response +#### Response An HTTP 204 (No Content) and empty body is returned if successful. +### get + +You can get a record in Redis using the `get` operation. This gets a key that was previously set. + +#### Request + +```json +{ + "operation": "get", + "metadata": { + "key": "key1" + }, + "data": { + } +} +``` + +#### Response + +```json +{ + "data": { + "Hello": "World", + "Lorem": "Ipsum" + } +} +``` + +### delete + +You can delete a record in Redis using the `delete` operation. Returns success whether the key exists or not. + +#### Request + +```json +{ + "operation": "delete", + "metadata": { + "key": "key1" + } +} +``` + +#### Response + +An HTTP 204 (No Content) and empty body is returned if successful. + + ## Create a Redis instance Dapr can use any Redis instance - containerized, running on your local dev machine, or a managed cloud service, provided the version of Redis is 5.0.0 or later. diff --git a/daprdocs/content/en/reference/components-reference/supported-bindings/storagequeues.md b/daprdocs/content/en/reference/components-reference/supported-bindings/storagequeues.md index 94d7ea96b28..b9d2113c1fa 100644 --- a/daprdocs/content/en/reference/components-reference/supported-bindings/storagequeues.md +++ b/daprdocs/content/en/reference/components-reference/supported-bindings/storagequeues.md @@ -32,7 +32,7 @@ spec: # - name: decodeBase64 # value: "false" # - name: endpoint -# value: "http://127.0.0.1:10000" +# value: "http://127.0.0.1:10001" ``` {{% alert title="Warning" color="warning" %}} @@ -48,7 +48,7 @@ The above example uses secrets as plain strings. It is recommended to use a secr | `queueName` | Y | Input/Output | The name of the Azure Storage queue | `"myqueue"` | | `ttlInSeconds` | N | Output | Parameter to set the default message time to live. If this parameter is omitted, messages will expire after 10 minutes. See [also](#specifying-a-ttl-per-message) | `"60"` | | `decodeBase64` | N | Output | Configuration to decode base64 file content before saving to Blob Storage. (In case of saving a file with binary content). `true` is the only allowed positive value. Other positive variations like `"True", "1"` are not acceptable. Defaults to `false` | `true`, `false` | -| `endpoint` | N | Input/Output | Optional custom endpoint URL. This is useful when using the [Azurite emulator](https://github.com/Azure/azurite) or when using custom domains for Azure Storage (although this is not officially supported). The endpoint must be the full base URL, including the protocol (`http://` or `https://`), the IP or FQDN, and optional port. | `"http://127.0.0.1:10000"` or `"https://accountName.queue.example.com"` | +| `endpoint` | N | Input/Output | Optional custom endpoint URL. This is useful when using the [Azurite emulator](https://github.com/Azure/azurite) or when using custom domains for Azure Storage (although this is not officially supported). The endpoint must be the full base URL, including the protocol (`http://` or `https://`), the IP or FQDN, and optional port. | `"http://127.0.0.1:10001"` or `"https://accountName.queue.example.com"` | ### Azure Active Directory (Azure AD) authentication diff --git a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-apache-kafka.md b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-apache-kafka.md index 0817524ef63..86d4a350c58 100644 --- a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-apache-kafka.md +++ b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-apache-kafka.md @@ -34,6 +34,8 @@ spec: secretKeyRef: name: kafka-secrets key: saslPasswordSecret + - name: saslMechanism + value: "SHA-512" - name: maxMessageBytes # Optional. value: 1024 - name: consumeRetryInterval # Optional. @@ -55,6 +57,7 @@ spec: | authType | Y | Configure or disable authentication. Supported values: `none`, `password`, `mtls`, or `oidc` | `"password"`, `"none"` | saslUsername | N | The SASL username used for authentication. Only required if `authType` is set to `"password"`. | `"adminuser"` | saslPassword | N | The SASL password used for authentication. Can be `secretKeyRef` to use a [secret reference]({{< ref component-secrets.md >}}). Only required if `authType is set to `"password"`. | `""`, `"KeFg23!"` +| saslMechanism | N | The SASL Authentication Mechanism you wish to use. Only required if `authType` is set to `"password"`. Defaults to `PLAINTEXT` | `"SHA-512", "SHA-256", "PLAINTEXT"` | initialOffset | N | The initial offset to use if no offset was previously committed. Should be "newest" or "oldest". Defaults to "newest". | `"oldest"` | maxMessageBytes | N | The maximum size in bytes allowed for a single Kafka message. Defaults to 1024. | `2048` | consumeRetryInterval | N | The interval between retries when attempting to consume topics. Treats numbers without suffix as milliseconds. Defaults to 100ms. | `200ms` | @@ -111,8 +114,7 @@ spec: #### SASL Password -Setting `authType` to `password` enables [SASL](https://en.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer) authentication using the **PLAIN** mechanism. This requires setting -the `saslUsername` and `saslPassword` fields. +Setting `authType` to `password` enables [SASL](https://en.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer) authentication. This requires setting the `saslUsername` and `saslPassword` fields. ```yaml apiVersion: dapr.io/v1alpha1 @@ -137,6 +139,8 @@ spec: secretKeyRef: name: kafka-secrets key: saslPasswordSecret + - name: saslMechanism + value: "SHA-512" - name: maxMessageBytes # Optional. value: 1024 - name: consumeRetryInterval # Optional. diff --git a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-hazelcast.md b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-hazelcast.md index 16962d4f5a6..b26bd27c912 100644 --- a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-hazelcast.md +++ b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-hazelcast.md @@ -7,6 +7,10 @@ aliases: - "/operations/components/setup-pubsub/supported-pubsub/setup-hazelcast/" --- +{{% alert title="Deprecation notice" color="warning" %}} +The Hazelcast PubSub component has been deprecated due to inherent lack of support for "at least once" delivery guarantee, and will be removed in a future Dapr release. +{{% /alert %}} + ## Component format To setup hazelcast pubsub create a component of type `pubsub.hazelcast`. See [this guide]({{< ref "howto-publish-subscribe.md#step-1-setup-the-pubsub-component" >}}) on how to create and apply a pubsub configuration. diff --git a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-mqtt.md b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-mqtt.md index 250e681a86b..1fbfa6105d1 100644 --- a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-mqtt.md +++ b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-mqtt.md @@ -49,8 +49,6 @@ The above example uses secrets as plain strings. It is recommended to use a secr | caCert | Required for using TLS | Certificate Authority (CA) certificate in PEM format for verifying server TLS certificates. | `"-----BEGIN CERTIFICATE-----\n\n-----END CERTIFICATE-----"` | clientCert | Required for using TLS | TLS client certificate in PEM format. Must be used with `clientKey`. | `"-----BEGIN CERTIFICATE-----\n\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\n-----END RSA PRIVATE KEY-----"` -| backOffMaxRetries | N | The maximum number of retries to process the message before returning an error. Defaults to `"0"`, which means that no retries will be attempted. `"-1"` can be specified to indicate that messages should be retried indefinitely until they are successfully processed or the application is shutdown. The component will wait 5 seconds between retries. | `"3"` - ### 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: diff --git a/daprdocs/content/en/reference/components-reference/supported-secret-stores/aws-secret-manager.md b/daprdocs/content/en/reference/components-reference/supported-secret-stores/aws-secret-manager.md index 4c21f190fec..e57aece7bd0 100644 --- a/daprdocs/content/en/reference/components-reference/supported-secret-stores/aws-secret-manager.md +++ b/daprdocs/content/en/reference/components-reference/supported-secret-stores/aws-secret-manager.md @@ -2,7 +2,7 @@ type: docs title: "AWS Secrets Manager" linkTitle: "AWS Secrets Manager" -description: Detailed information on the decret store component +description: Detailed information on the secret store component aliases: - "/operations/components/setup-secret-store/supported-secret-stores/aws-secret-manager/" --- diff --git a/daprdocs/content/en/reference/components-reference/supported-secret-stores/azure-keyvault.md b/daprdocs/content/en/reference/components-reference/supported-secret-stores/azure-keyvault.md index 9c1f63bd7cb..ce2e801f45c 100644 --- a/daprdocs/content/en/reference/components-reference/supported-secret-stores/azure-keyvault.md +++ b/daprdocs/content/en/reference/components-reference/supported-secret-stores/azure-keyvault.md @@ -53,7 +53,7 @@ Additionally, you must provide the authentication fields as explained in the [Au ### Prerequisites -- [Azure Subscription](https://azure.microsoft.com/free/) +- Azure Subscription - [Azure CLI](https://docs.microsoft.com/cli/azure/install-azure-cli) - [jq](https://stedolan.github.io/jq/download/) - The scripts below are optimized for a bash or zsh shell diff --git a/daprdocs/content/en/reference/components-reference/supported-secret-stores/hashicorp-vault.md b/daprdocs/content/en/reference/components-reference/supported-secret-stores/hashicorp-vault.md index 3c7a9bb4fc5..19eaebdbdaf 100644 --- a/daprdocs/content/en/reference/components-reference/supported-secret-stores/hashicorp-vault.md +++ b/daprdocs/content/en/reference/components-reference/supported-secret-stores/hashicorp-vault.md @@ -54,17 +54,17 @@ The above example uses secrets as plain strings. It is recommended to use a loca | Field | Required | Details | Example | |--------------------|:--------:|--------------------------------|---------------------| | vaultAddr | N | The address of the Vault server. Defaults to `"https://127.0.0.1:8200"` | `"https://127.0.0.1:8200"` | -| caCert | N | Certificate Authority use only one of the options. The encoded cacerts to use | `"cacerts"` | -| caPath | N | Certificate Authority use only one of the options. The path to a CA cert file | `"path/to/cacert/file"` | -| caPem | N | Certificate Authority use only one of the options. The encoded cacert pem to use | `"encodedpem"` | +| caPem | N | The inlined contents of the CA certificate to use, in PEM format. If defined, takes precedence over `caPath` and `caCert`. | See below | +| caPath | N | The path to a folder holding the CA certificate file to use, in PEM format. If the folder contains multiple files, only the first file found will be used. If defined, takes precedence over `caCert`. | `"path/to/cacert/holding/folder"` | +| caCert | N | The path to the CA certificate to use, in PEM format. | `""path/to/cacert.pem"` | | skipVerify | N | Skip TLS verification. Defaults to `"false"` | `"true"`, `"false"` | -| tlsServerName | N | TLS config server name | `"tls-server"` | +| tlsServerName | N | The name of the server requested during TLS handshake in order to support virtual hosting. This value is also used to verify the TLS certificate presented by Vault server. | `"tls-server"` | | vaultTokenMountPath | Y | Path to file containing token | `"path/to/file"` | | vaultToken | Y | [Token](https://learn.hashicorp.com/tutorials/vault/tokens) for authentication within Vault. | `"tokenValue"` | | vaultKVPrefix | N | The prefix in vault. Defaults to `"dapr"` | `"dapr"`, `"myprefix"` | | vaultKVUsePrefix | N | If false, vaultKVPrefix is forced to be empty. If the value is not given or set to true, vaultKVPrefix is used when accessing the vault. Setting it to false is needed to be able to use the BulkGetSecret method of the store. | `"true"`, `"false"` | | enginePath | N | The [engine](https://www.vaultproject.io/api-docs/secret/kv/kv-v2) path in vault. Defaults to `"secret"` | `"kv"`, `"any"` | -| vaultValueType | N | Vault value type. `map` means to parse the value into `map[string]string`, `text` means to use the value as a string. 'map' sets the `multipleKeyValuesPerSecret` behavior. `text' makes Vault behave as a secret store with name/value semantics. Defaults to `"map"` | `"map"`, `"text"` | +| vaultValueType | N | Vault value type. `map` means to parse the value into `map[string]string`, `text` means to use the value as a string. 'map' sets the `multipleKeyValuesPerSecret` behavior. `text` makes Vault behave as a secret store with name/value semantics. Defaults to `"map"` | `"map"`, `"text"` | ## Setup Hashicorp Vault instance @@ -109,9 +109,37 @@ $ curl http://localhost:3501/v1.0/secrets/my-hashicorp-vault/mysecret } ``` -Notice that the name of the secret (`mysecret`) is not repeated in the result. +Notice that the name of the secret (`mysecret`) is not repeated in the result. +## TLS Server verification + +The fields `skipVerify`, `tlsServerName`, `caCert`, `caPath`, and `caPem` control if and how Dapr verifies the vault server's certificate while connecting using TLS/HTTPS. + +### Inline CA PEM caPem + +The `caPem` field value should be the contents of the PEM CA certificate you want to use. Given PEM certificates are made of multiple lines, defining that value might seem challenging at first. YAML allows for a few ways of [defining a multiline values](https://yaml-multiline.info/). + +Below is one way to define a `caPem` field. + +```yaml +apiVersion: dapr.io/v1alpha1 +kind: Component +metadata: + name: vault +spec: + type: secretstores.hashicorp.vault + version: v1 + metadata: + - name: vaultAddr + value: https://127.0.0.1:8200 + - name: caPem + value: |- + -----BEGIN CERTIFICATE----- + << the rest of your PEM file content's here, indented appropriately. >> + -----END CERTIFICATE----- +``` + ## Related links - [Secrets building block]({{< ref secrets >}}) - [How-To: Retrieve a secret]({{< ref "howto-secrets.md" >}}) diff --git a/daprdocs/content/en/reference/components-reference/supported-state-stores/setup-azure-cosmosdb.md b/daprdocs/content/en/reference/components-reference/supported-state-stores/setup-azure-cosmosdb.md index caf8fb0ee33..2c7a4651c48 100644 --- a/daprdocs/content/en/reference/components-reference/supported-state-stores/setup-azure-cosmosdb.md +++ b/daprdocs/content/en/reference/components-reference/supported-state-stores/setup-azure-cosmosdb.md @@ -168,62 +168,6 @@ az cosmosdb sql role assignment create \ --role-definition-id "$ROLE_ID" ``` -### Creating the stored procedures for Dapr - -When using Cosmos DB as a state store for Dapr, we need to create two stored procedures in your collection. When you configure the state store using a "master key", Dapr creates those for you, automatically. However, when your state store authenticates with Cosmos DB using Azure AD, because of limitations in the platform we are not able to do it automatically. - -If you are using Azure AD to authenticate your Cosmos DB state store and have not created the stored procedures (or if you are using an outdated version of them), your Dapr sidecar will fail to start and you will see an error similar to this in your logs: - -```text -Dapr requires stored procedures created in Cosmos DB before it can be used as state store. Those stored procedures are currently not existing or are using a different version than expected. When you authenticate using Azure AD we cannot automatically create them for you: please start this state store with a Cosmos DB master key just once so we can create the stored procedures for you; otherwise, you can check our docs to learn how to create them yourself: https://aka.ms/dapr/cosmosdb-aad -``` - -To fix this issue, you have two options: - -1. Configure your component to authenticate with the "master key" just once, to have Dapr automatically initialize the stored procedures for you. While you need to use a "master key" the first time you launch your application, you should be able to remove that and use Azure AD credentials (including Managed Identities) after. -2. Alternatively, you can follow the steps below to create the stored procedures manually. These steps must be performed before you can start your application the first time. - -To create the stored procedures manually, you can use the commands below. - -First, download the code of the stored procedures for the version of Dapr that you're using. This will create two `.js` files in your working directory: - -```sh -# Set this to the version of Dapr that you're using -DAPR_VERSION="release-{{% dapr-latest-version short="true" %}}" -curl -LfO "https://raw.githubusercontent.com/dapr/components-contrib/${DAPR_VERSION}/state/azure/cosmosdb/storedprocedures/__daprver__.js" -curl -LfO "https://raw.githubusercontent.com/dapr/components-contrib/${DAPR_VERSION}/state/azure/cosmosdb/storedprocedures/__dapr_v2__.js" -``` - -> You won't need to update the code for the stored procedures every time you update Dapr. Although the code for the stored procedures doesn't change often, sometimes we may make updates to that: when that happens, if you're using Azure AD authentication your Dapr sidecar will fail to launch until you update the stored procedures, re-running the commands above. - -Then, using the Azure CLI create the stored procedures in Cosmos DB, for your account, database, and collection (or container): - -```sh -# Name of the Resource Group that contains your Cosmos DB -RESOURCE_GROUP="..." -# Name of your Cosmos DB account -ACCOUNT_NAME="..." -# Name of your database in the Cosmos DB account -DATABASE_NAME="..." -# Name of the container (collection) in your database -CONTAINER_NAME="..." - -az cosmosdb sql stored-procedure create \ - --resource-group "$RESOURCE_GROUP" \ - --account-name "$ACCOUNT_NAME" \ - --database-name "$DATABASE_NAME" \ - --container-name "$CONTAINER_NAME" \ - --name "__daprver__" \ - --body @__daprver__.js -az cosmosdb sql stored-procedure create \ - --resource-group "$RESOURCE_GROUP" \ - --account-name "$ACCOUNT_NAME" \ - --database-name "$DATABASE_NAME" \ - --container-name "$CONTAINER_NAME" \ - --name "__dapr_v2__" \ - --body @__dapr_v2__.js -``` - ## Related links - [Basic schema for a Dapr component]({{< ref component-schema >}}) diff --git a/daprdocs/content/en/reference/components-reference/supported-state-stores/setup-redis.md b/daprdocs/content/en/reference/components-reference/supported-state-stores/setup-redis.md index 4a1eb18ce4b..3c323b0745f 100644 --- a/daprdocs/content/en/reference/components-reference/supported-state-stores/setup-redis.md +++ b/daprdocs/content/en/reference/components-reference/supported-state-stores/setup-redis.md @@ -230,6 +230,7 @@ Consider an example where you store documents like that: }, "city": "Seattle", "state": "WA" + } } ``` diff --git a/daprdocs/data/components/pubsub/generic.yaml b/daprdocs/data/components/pubsub/generic.yaml index ef757e4b394..58fde998f72 100644 --- a/daprdocs/data/components/pubsub/generic.yaml +++ b/daprdocs/data/components/pubsub/generic.yaml @@ -1,8 +1,8 @@ - component: Hazelcast link: setup-hazelcast - state: Beta + state: Deprecated version: v1 - since: "1.7" + since: "1.9" - component: In Memory link: setup-inmemory state: Beta @@ -43,3 +43,8 @@ state: Stable version: v1 since: "1.7" +- component: RocketMQ + link: setup-rocketmq + state: Alpha + version: v1 + since: "1.8" diff --git a/daprdocs/data/components/state_stores/aws.yaml b/daprdocs/data/components/state_stores/aws.yaml index 81584efb09a..65440d5802b 100644 --- a/daprdocs/data/components/state_stores/aws.yaml +++ b/daprdocs/data/components/state_stores/aws.yaml @@ -6,6 +6,6 @@ features: crud: true transactions: false - etag: false + etag: true ttl: true query: false diff --git a/daprdocs/layouts/shortcodes/dapr-latest-version.html b/daprdocs/layouts/shortcodes/dapr-latest-version.html index db415d450c5..df0cb50bef1 100644 --- a/daprdocs/layouts/shortcodes/dapr-latest-version.html +++ b/daprdocs/layouts/shortcodes/dapr-latest-version.html @@ -1 +1 @@ -{{- if .Get "short" }}1.9{{ else if .Get "long" }}1.9.0{{ else if .Get "cli" }}1.9.0{{ else }}1.9.0{{ end -}} +{{- if .Get "short" }}1.9{{ else if .Get "long" }}1.9.5{{ else if .Get "cli" }}1.9.0{{ else }}1.9.5{{ end -}} diff --git a/daprdocs/static/images/resiliency-quickstart-svc-component.png b/daprdocs/static/images/resiliency-quickstart-svc-component.png new file mode 100644 index 00000000000..5dea0e1edf7 Binary files /dev/null and b/daprdocs/static/images/resiliency-quickstart-svc-component.png differ diff --git a/daprdocs/static/images/resiliency-quickstart-svc-invoke.png b/daprdocs/static/images/resiliency-quickstart-svc-invoke.png new file mode 100644 index 00000000000..baff0ccfea1 Binary files /dev/null and b/daprdocs/static/images/resiliency-quickstart-svc-invoke.png differ diff --git a/daprdocs/static/images/resiliency_diagram.png b/daprdocs/static/images/resiliency_diagram.png new file mode 100644 index 00000000000..8c7168f0ef1 Binary files /dev/null and b/daprdocs/static/images/resiliency_diagram.png differ diff --git a/daprdocs/static/images/sidecar-health.png b/daprdocs/static/images/sidecar-health.png new file mode 100644 index 00000000000..a8aa6819a8f Binary files /dev/null and b/daprdocs/static/images/sidecar-health.png differ diff --git a/sdkdocs/dotnet b/sdkdocs/dotnet index 52b82d7ce65..e87b9ad6eef 160000 --- a/sdkdocs/dotnet +++ b/sdkdocs/dotnet @@ -1 +1 @@ -Subproject commit 52b82d7ce6599822a37d2528379f5ca146e286bb +Subproject commit e87b9ad6eefaa05390144d82642df13c5b4bed17