diff --git a/daprdocs/content/en/contributing/roadmap.md b/daprdocs/content/en/contributing/roadmap.md
index d3a7909357f..6c1093ecbd9 100644
--- a/daprdocs/content/en/contributing/roadmap.md
+++ b/daprdocs/content/en/contributing/roadmap.md
@@ -2,47 +2,9 @@
type: docs
title: "Dapr Roadmap"
linkTitle: "Roadmap"
-description: "The Dapr Roadmap is a tool to help with visibility into investments across the Dapr project"
+description: "The Dapr Roadmap gives the community visibility into the different priorities of the projecs"
weight: 30
no_list: true
---
-
-Dapr encourages the community to help with prioritization. A GitHub project board is available to view and provide feedback on proposed issues and track them across development.
-
-[
](https://aka.ms/dapr/roadmap)
-
-{{< button text="View the backlog" link="https://aka.ms/dapr/roadmap" color="primary" >}}
-- -Please vote by adding a 👍 on the GitHub issues for the feature capabilities you would most like to see Dapr support. This will help the Dapr maintainers understand which features will provide the most value. - -Contributions from the community is also welcomed. If there are features on the roadmap that you are interested in contributing to, please comment on the GitHub issue and include your solution proposal. - -{{% alert title="Note" color="primary" %}} -The Dapr roadmap includes issues only from the v1.2 release and onwards. Issues closed and released prior to v1.2 are not included. -{{% /alert %}} - -## Stages - -The Dapr Roadmap progresses through the following stages: - -{{< cardpane >}} -{{< card title="**[📄 Backlog](https://github.com/orgs/dapr/projects/52#column-14691591)**" >}} - Issues (features) that need 👍 votes from the community to prioritize. Updated by Dapr maintainers. -{{< /card >}} -{{< card title="**[⏳ Planned (Committed)](https://github.com/orgs/dapr/projects/52#column-14561691)**" >}} - Issues with a proposal and/or targeted release milestone. This is where design proposals are discussed and designed. -{{< /card >}} -{{< card title="**[👩💻 In Progress (Development)](https://github.com/orgs/dapr/projects/52#column-14561696)**" >}} - Implementation specifics have been agreed upon and the feature is under active development. -{{< /card >}} -{{< /cardpane >}} -{{< cardpane >}} -{{< card title="**[☑ Done](https://github.com/orgs/dapr/projects/52#column-14561700)**" >}} - The feature capability has been completed and is scheduled for an upcoming release. -{{< /card >}} -{{< card title="**[✅ Released](https://github.com/orgs/dapr/projects/52#column-14659973)**" >}} - The feature is released and available for use. -{{< /card >}} -{{< /cardpane >}} +See [this document](https://github.com/dapr/community/blob/master/roadmap.md) to view the Dapr project's roadmap. diff --git a/daprdocs/content/en/developing-applications/building-blocks/actors/actors-overview.md b/daprdocs/content/en/developing-applications/building-blocks/actors/actors-overview.md index bb96b9b2326..7bb1bcf0e85 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/actors/actors-overview.md +++ b/daprdocs/content/en/developing-applications/building-blocks/actors/actors-overview.md @@ -104,7 +104,7 @@ The Dapr actor runtime provides a simple turn-based access model for accessing a ### State -Transactional state stores can be used to store actor state. To specify which state store to use for actors, specify value of property `actorStateStore` as `true` in the state store component's metadata section. Actors state is stored with a specific scheme in transactional state stores, allowing for consistent querying. Only a single state store component can be used as the state store for all actors. Read the [state API reference]({{< ref state_api.md >}}) and the [actors API reference]({{< ref actors_api.md >}}) to learn more about state stores for actors. +Transactional state stores can be used to store actor state. Regardless of whether you intend to store any state in your actor, you must specify a value for property `actorStateStore` as `true` in the state store component's metadata section. Actors state is stored with a specific scheme in transactional state stores, allowing for consistent querying. Only a single state store component can be used as the state store for all actors. Read the [state API reference]({{< ref state_api.md >}}) and the [actors API reference]({{< ref actors_api.md >}}) to learn more about state stores for actors. ### Actor timers and reminders diff --git a/daprdocs/content/en/developing-applications/building-blocks/jobs/howto-schedule-and-handle-triggered-jobs.md b/daprdocs/content/en/developing-applications/building-blocks/jobs/howto-schedule-and-handle-triggered-jobs.md index 27dc31fc2b1..0a5dba3b10c 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/jobs/howto-schedule-and-handle-triggered-jobs.md +++ b/daprdocs/content/en/developing-applications/building-blocks/jobs/howto-schedule-and-handle-triggered-jobs.md @@ -94,6 +94,75 @@ In this example, at trigger time, which is `@every 1s` according to the `Schedul At the trigger time, the `prodDBBackupHandler` function is called, executing the desired business logic for this job at trigger time. For example: +#### HTTP + +When you create a job using Dapr's Jobs API, Dapr will automatically assume there is an endpoint available at +`/job/
1. Service A makes an HTTP call targeting Service B, a non-Dapr endpoint. The call goes to the local Dapr sidecar.
-2. Dapr discovers Service B's location using the `HTTPEndpoint` or FQDN URL.
-3. Dapr forwards the message to Service B.
-4. Service B runs its business logic code.
-5. Service B sends a response to Service A's Dapr sidecar.
-6. Service A receives the response.
+2. Dapr discovers Service B's location using the `HTTPEndpoint` or FQDN URL then forwards the message to Service B.
+3. Service B sends a response to Service A's Dapr sidecar.
+4. Service A receives the response.
## Using an HTTPEndpoint resource or FQDN URL for non-Dapr endpoints
There are two ways to invoke a non-Dapr endpoint when communicating either to Dapr applications or non-Dapr applications. A Dapr application can invoke a non-Dapr endpoint by providing one of the following:
diff --git a/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-overview.md b/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-overview.md
index b4fa5a44388..ed9f747b882 100644
--- a/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-overview.md
+++ b/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-overview.md
@@ -106,8 +106,25 @@ Want to skip the quickstarts? Not a problem. You can try out the workflow buildi
## Limitations
-- **State stores:** As of the 1.12.0 beta release of Dapr Workflow, using the NoSQL databases as a state store results in limitations around storing internal states. For example, CosmosDB has a maximum single operation item limit of only 100 states in a single request.
-- **Horizontal scaling:** As of the 1.12.0 beta release of Dapr Workflow, if you scale out Dapr sidecars or your application pods to more than 2, then the concurrency of the workflow execution drops. It is recommended to test with 1 or 2 instances, and no more than 2.
+- **State stores:** Due to underlying limitations in some database choices, more commonly NoSQL databases, you might run into limitations around storing internal states. For example, CosmosDB has a maximum single operation item limit of only 100 states in a single request.
+- **Horizontal scaling:** As of the 1.12.0 beta release of Dapr Workflow, it is recommended to use a maximum of two instances of Dapr per workflow application. This limitation is resolved in Dapr 1.14.x when enabling the scheduler service.
+
+To enable the scheduler service to work for Dapr Workflows, make sure you're using Dapr 1.14.x or later and assign the following configuration to your app:
+
+```yaml
+apiVersion: dapr.io/v1alpha1
+kind: Configuration
+metadata:
+ name: schedulerconfig
+spec:
+ tracing:
+ samplingRate: "1"
+ features:
+ - name: SchedulerReminders
+ enabled: true
+```
+
+See more info about [enabling preview features]({{}}).
## Watch the demo
diff --git a/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-patterns.md b/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-patterns.md
index fe6f69b63c2..ba3ab432f1b 100644
--- a/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-patterns.md
+++ b/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-patterns.md
@@ -749,7 +749,7 @@ def status_monitor_workflow(ctx: wf.DaprWorkflowContext, job: JobStatus):
ctx.call_activity(send_alert, input=f"Job '{job.job_id}' is unhealthy!")
next_sleep_interval = 5 # check more frequently when unhealthy
- yield ctx.create_timer(fire_at=ctx.current_utc_datetime + timedelta(seconds=next_sleep_interval))
+ yield ctx.create_timer(fire_at=ctx.current_utc_datetime + timedelta(minutes=next_sleep_interval))
# restart from the beginning with a new JobStatus input
ctx.continue_as_new(job)
@@ -896,7 +896,7 @@ func StatusMonitorWorkflow(ctx *workflow.WorkflowContext) (any, error) {
}
if status == "healthy" {
job.IsHealthy = true
- sleepInterval = time.Second * 60
+ sleepInterval = time.Minutes * 60
} else {
if job.IsHealthy {
job.IsHealthy = false
@@ -905,7 +905,7 @@ func StatusMonitorWorkflow(ctx *workflow.WorkflowContext) (any, error) {
return "", err
}
}
- sleepInterval = time.Second * 5
+ sleepInterval = time.Minutes * 5
}
if err := ctx.CreateTimer(sleepInterval).Await(nil); err != nil {
return "", err
diff --git a/daprdocs/content/en/developing-applications/integrations/Diagrid/diagrid-conductor.md b/daprdocs/content/en/developing-applications/integrations/Diagrid/diagrid-conductor.md
index 554ca118a23..c7504b56cc2 100644
--- a/daprdocs/content/en/developing-applications/integrations/Diagrid/diagrid-conductor.md
+++ b/daprdocs/content/en/developing-applications/integrations/Diagrid/diagrid-conductor.md
@@ -26,6 +26,4 @@ By studying past resource behavior, recommend application resource optimization
The application graph facilitates collaboration between dev and ops by providing a dynamic overview of your services and infrastructure components.
-Try out [Conductor Free](https://www.diagrid.io/pricing), ideal for individual developers building and testing Dapr applications on Kubernetes.
-
{{< button text="Learn more about Diagrid Conductor" link="https://www.diagrid.io/conductor" >}}
diff --git a/daprdocs/content/en/getting-started/quickstarts/jobs-quickstart.md b/daprdocs/content/en/getting-started/quickstarts/jobs-quickstart.md
index 8b52eedb1d6..9435df1944f 100644
--- a/daprdocs/content/en/getting-started/quickstarts/jobs-quickstart.md
+++ b/daprdocs/content/en/getting-started/quickstarts/jobs-quickstart.md
@@ -273,23 +273,20 @@ func deleteJob(ctx context.Context, in *common.InvocationEvent) (out *common.Con
// Handler that handles job events
func handleJob(ctx context.Context, job *common.JobEvent) error {
- var jobData common.Job
- if err := json.Unmarshal(job.Data, &jobData); err != nil {
- return fmt.Errorf("failed to unmarshal job: %v", err)
- }
- decodedPayload, err := base64.StdEncoding.DecodeString(jobData.Value)
- if err != nil {
- return fmt.Errorf("failed to decode job payload: %v", err)
- }
- var jobPayload JobData
- if err := json.Unmarshal(decodedPayload, &jobPayload); err != nil {
- return fmt.Errorf("failed to unmarshal payload: %v", err)
- }
+ var jobData common.Job
+ if err := json.Unmarshal(job.Data, &jobData); err != nil {
+ return fmt.Errorf("failed to unmarshal job: %v", err)
+ }
- fmt.Println("Starting droid:", jobPayload.Droid)
- fmt.Println("Executing maintenance job:", jobPayload.Task)
+ var jobPayload JobData
+ if err := json.Unmarshal(job.Data, &jobPayload); err != nil {
+ return fmt.Errorf("failed to unmarshal payload: %v", err)
+ }
- return nil
+ fmt.Println("Starting droid:", jobPayload.Droid)
+ fmt.Println("Executing maintenance job:", jobPayload.Task)
+
+ return nil
}
```
diff --git a/daprdocs/content/en/getting-started/quickstarts/workflow-quickstart.md b/daprdocs/content/en/getting-started/quickstarts/workflow-quickstart.md
index 5a025aed855..da1ec1590f9 100644
--- a/daprdocs/content/en/getting-started/quickstarts/workflow-quickstart.md
+++ b/daprdocs/content/en/getting-started/quickstarts/workflow-quickstart.md
@@ -66,12 +66,18 @@ Install the Dapr Python SDK package:
pip3 install -r requirements.txt
```
+Return to the `python/sdk` directory:
+
+```bash
+cd ..
+```
+
+
### Step 3: Run the order processor app
-In the terminal, start the order processor app alongside a Dapr sidecar using [Multi-App Run]({{< ref multi-app-dapr-run >}}):
+In the terminal, start the order processor app alongside a Dapr sidecar using [Multi-App Run]({{< ref multi-app-dapr-run >}}). From the `python/sdk` directory, run the following command:
```bash
-cd workflows/python/sdk
dapr run -f .
```
@@ -308,12 +314,11 @@ Install the dependencies:
cd ./javascript/sdk
npm install
npm run build
-cd ..
```
### Step 3: Run the order processor app
-In the terminal, start the order processor app alongside a Dapr sidecar using [Multi-App Run]({{< ref multi-app-dapr-run >}}):
+In the terminal, start the order processor app alongside a Dapr sidecar using [Multi-App Run]({{< ref multi-app-dapr-run >}}). From the `javascript/sdk` directory, run the following command:
```bash
dapr run -f .
@@ -515,15 +520,28 @@ Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quic
git clone https://github.com/dapr/quickstarts.git
```
-In a new terminal window, navigate to the `sdk` directory:
+In a new terminal window, navigate to the `order-processor` directory:
+
+```bash
+cd workflows/csharp/sdk/order-processor
+```
+
+Install the dependencies:
```bash
-cd workflows/csharp/sdk
+dotnet restore
+dotnet build
+```
+
+Return to the `csharp/sdk` directory:
+
+```bash
+cd ..
```
### Step 3: Run the order processor app
-In the terminal, start the order processor app alongside a Dapr sidecar using [Multi-App Run]({{< ref multi-app-dapr-run >}}):
+In the terminal, start the order processor app alongside a Dapr sidecar using [Multi-App Run]({{< ref multi-app-dapr-run >}}). From the `csharp/sdk` directory, run the following command:
```bash
dapr run -f .
@@ -628,25 +646,24 @@ OrderPayload orderInfo = new OrderPayload(itemToPurchase, 15000, ammountToPurcha
// Start the workflow
Console.WriteLine("Starting workflow {0} purchasing {1} {2}", orderId, ammountToPurchase, itemToPurchase);
-await daprClient.StartWorkflowAsync(
- workflowComponent: DaprWorkflowComponent,
- workflowName: nameof(OrderProcessingWorkflow),
+await daprWorkflowClient.ScheduleNewWorkflowAsync(
+ name: nameof(OrderProcessingWorkflow),
input: orderInfo,
instanceId: orderId);
// Wait for the workflow to start and confirm the input
-GetWorkflowResponse state = await daprClient.WaitForWorkflowStartAsync(
- instanceId: orderId,
- workflowComponent: DaprWorkflowComponent);
+WorkflowState state = await daprWorkflowClient.WaitForWorkflowStartAsync(
+ instanceId: orderId);
-Console.WriteLine("Your workflow has started. Here is the status of the workflow: {0}", state.RuntimeStatus);
+Console.WriteLine($"{nameof(OrderProcessingWorkflow)} (ID = {orderId}) started successfully with {state.ReadInputAs`unlock` (`v1.0-alpha1`) | `lock` (`v1alpha1`)
`unlock` (`v1alpha1`) | -| Cryptography | `crypto` (`v1.0-alpha1`) | `crypto` (`v1alpha1`) | +| [Cryptography]({{< ref cryptography_api.md >}}) | `crypto` (`v1.0-alpha1`) | `crypto` (`v1alpha1`) | | [Workflow]({{< ref workflow_api.md >}}) | `workflows` (`v1.0-alpha1`) |`workflows` (`v1alpha1`) | | [Health]({{< ref health_api.md >}}) | `healthz` (`v1.0`) | n/a | | Shutdown | `shutdown` (`v1.0`) | `shutdown` (`v1`) | + +## Next steps + +{{< button text="Configure Dapr to use gRPC" page="grpc" >}} \ No newline at end of file diff --git a/daprdocs/content/en/operations/configuration/configuration-overview.md b/daprdocs/content/en/operations/configuration/configuration-overview.md index 0cba2414ca4..7225fc11f2f 100644 --- a/daprdocs/content/en/operations/configuration/configuration-overview.md +++ b/daprdocs/content/en/operations/configuration/configuration-overview.md @@ -1,30 +1,44 @@ --- type: docs -title: "Overview of Dapr configuration options" +title: "Dapr configuration" linkTitle: "Overview" weight: 100 -description: "Information on Dapr configuration and how to set options for your application" +description: "Overview of Dapr configuration" --- -## Sidecar configuration +Dapr configurations are settings and policies that enable you to change both the behavior of individual Dapr applications, or the global behavior of the Dapr control plane system services. -### Setup sidecar configuration +[for more information, read the configuration concept.]({{< ref configuration-concept.md >}}) -#### Self-hosted sidecar +## Application configuration -In self hosted mode the Dapr configuration is a configuration file, for example `config.yaml`. By default the Dapr sidecar looks in the default Dapr folder for the runtime configuration eg: `$HOME/.dapr/config.yaml` in Linux/MacOS and `%USERPROFILE%\.dapr\config.yaml` in Windows. +### Set up application configuration -A Dapr sidecar can also apply a configuration by using a `--config` flag to the file path with `dapr run` CLI command. +You can set up application configuration either in self-hosted or Kubernetes mode. -#### Kubernetes sidecar +{{< tabs "Self-hosted" Kubernetes >}} -In Kubernetes mode the Dapr configuration is a Configuration resource, that is applied to the cluster. For example: + +{{% codetab %}} + +In self hosted mode, the Dapr configuration is a [configuration file]({{< ref configuration-schema.md >}}) - for example, `config.yaml`. By default, the Dapr sidecar looks in the default Dapr folder for the runtime configuration: +- Linux/MacOs: `$HOME/.dapr/config.yaml` +- Windows: `%USERPROFILE%\.dapr\config.yaml` + +An application can also apply a configuration by using a `--config` flag to the file path with `dapr run` CLI command. + +{{% /codetab %}} + + +{{% codetab %}} + +In Kubernetes mode, the Dapr configuration is a Configuration resource, that is applied to the cluster. For example: ```bash kubectl apply -f myappconfig.yaml ``` -You can use the Dapr CLI to list the Configuration resources +You can use the Dapr CLI to list the Configuration resources for applications. ```bash dapr configurations -k @@ -40,11 +54,15 @@ A Dapr sidecar can apply a specific configuration by using a `dapr.io/config` an dapr.io/config: "myappconfig" ``` -Note: There are more [Kubernetes annotations]({{< ref "arguments-annotations-overview.md" >}}) available to configure the Dapr sidecar on activation by sidecar Injector system service. +> **Note:** [See all Kubernetes annotations]({{< ref "arguments-annotations-overview.md" >}}) available to configure the Dapr sidecar on activation by sidecar Injector system service. + +{{% /codetab %}} -### Sidecar configuration settings +{{< /tabs >}} -The following configuration settings can be applied to Dapr application sidecars: +### Application configuration settings + +The following menu includes all of the configuration settings you can set on the sidecar. - [Tracing](#tracing) - [Metrics](#metrics) @@ -68,7 +86,7 @@ The `tracing` section under the `Configuration` spec contains the following prop tracing: samplingRate: "1" otel: - endpointAddress: "https://..." + endpointAddress: "otelcollector.observability.svc.cluster.local:4317" zipkin: endpointAddress: "http://zipkin.default.svc.cluster.local:9411/api/v2/spans" ``` @@ -79,15 +97,22 @@ The following table lists the properties for tracing: |--------------|--------|-------------| | `samplingRate` | string | Set sampling rate for tracing to be enabled or disabled. | `stdout` | bool | True write more verbose information to the traces -| `otel.endpointAddress` | string | Set the Open Telemetry (OTEL) server address to send traces to +| `otel.endpointAddress` | string | Set the Open Telemetry (OTEL) server address to send traces to. This may or may not require the https:// or http:// depending on your OTEL provider. | `otel.isSecure` | bool | Is the connection to the endpoint address encrypted | `otel.protocol` | string | Set to `http` or `grpc` protocol -| `zipkin.endpointAddress` | string | Set the Zipkin server address to send traces to +| `zipkin.endpointAddress` | string | Set the Zipkin server address to send traces to. This should include the protocol (http:// or https://) on the endpoint. + +##### `samplingRate` -`samplingRate` is used to enable or disable the tracing. To disable the sampling rate , -set `samplingRate : "0"` in the configuration. The valid range of samplingRate is between 0 and 1 inclusive. The sampling rate determines whether a trace span should be sampled or not based on value. `samplingRate : "1"` samples all traces. By default, the sampling rate is (0.0001) or 1 in 10,000 traces. +`samplingRate` is used to enable or disable the tracing. The valid range of `samplingRate` is between `0` and `1` inclusive. The sampling rate determines whether a trace span should be sampled or not based on value. -The OpenTelemetry (otel) endpoint can also be configured via an environment variables. The presence of the OTEL_EXPORTER_OTLP_ENDPOINT environment variable +`samplingRate : "1"` samples all traces. By default, the sampling rate is (0.0001), or 1 in 10,000 traces. + +To disable the sampling rate, set `samplingRate : "0"` in the configuration. + +##### `otel` + +The OpenTelemetry (`otel`) endpoint can also be configured via an environment variable. The presence of the `OTEL_EXPORTER_OTLP_ENDPOINT` environment variable turns on tracing for the sidecar. | Environment Variable | Description | @@ -100,9 +125,9 @@ See [Observability distributed tracing]({{< ref "tracing-overview.md" >}}) for m #### Metrics -The metrics section can be used to enable or disable metrics for an application. +The `metrics` section under the `Configuration` spec can be used to enable or disable metrics for an application. -The `metrics` section under the `Configuration` spec contains the following properties: +The `metrics` section contains the following properties: ```yml metrics: @@ -122,7 +147,7 @@ metrics: excludeVerbs: false ``` -In the examples above this path filter `/orders/{orderID}/items/{itemID}` would return a single metric count matching all the orderIDs and all the itemIDs rather than multiple metrics for each itemID. For more information see [HTTP metrics path matching]({{< ref "metrics-overview.md#http-metrics-path-matching" >}}) +In the examples above, the path filter `/orders/{orderID}/items/{itemID}` would return _a single metric count_ matching all the `orderID`s and all the `itemID`s, rather than multiple metrics for each `itemID`. For more information, see [HTTP metrics path matching]({{< ref "metrics-overview.md#http-metrics-path-matching" >}}) The following table lists the properties for metrics: @@ -135,7 +160,7 @@ The following table lists the properties for metrics: | `http.pathMatching` | array | Array of paths for path matching, allowing users to define matching paths to manage cardinality. | | `http.excludeVerbs` | boolean | When set to true (default is false), the Dapr HTTP server ignores each request HTTP verb when building the method metric label. | -To further help managing cardinality, path matching allows specified paths matched according to defined patterns, reducing the number of unique metrics paths and thus controlling metric cardinality. This feature is particularly useful for applications with dynamic URLs, ensuring that metrics remain meaningful and manageable without excessive memory consumption. +To further help manage cardinality, path matching allows you to match specified paths according to defined patterns, reducing the number of unique metrics paths and thus controlling metric cardinality. This feature is particularly useful for applications with dynamic URLs, ensuring that metrics remain meaningful and manageable without excessive memory consumption. Using rules, you can set regular expressions for every metric exposed by the Dapr sidecar. For example: @@ -154,9 +179,9 @@ See [metrics documentation]({{< ref "metrics-overview.md" >}}) for more informat #### Logging -The logging section can be used to configure how logging works in the Dapr Runtime. +The `logging` section under the `Configuration` spec is used to configure how logging works in the Dapr Runtime. -The `logging` section under the `Configuration` spec contains the following properties: +The `logging` section contains the following properties: ```yml logging: @@ -178,8 +203,7 @@ See [logging documentation]({{< ref "logs.md" >}}) for more information. #### Middleware -Middleware configuration set named HTTP pipeline middleware handlers -The `httpPipeline` and the `appHttpPipeline` section under the `Configuration` spec contains the following properties: +Middleware configuration sets named HTTP pipeline middleware handlers. The `httpPipeline` and the `appHttpPipeline` section under the `Configuration` spec contain the following properties: ```yml httpPipeline: # for incoming http calls @@ -203,13 +227,13 @@ The following table lists the properties for HTTP handlers: | `name` | string | Name of the middleware component | `type` | string | Type of middleware component -See [Middleware pipelines]({{< ref "middleware.md" >}}) for more information +See [Middleware pipelines]({{< ref "middleware.md" >}}) for more information. #### Name resolution component -You can set name resolution component to use within the configuration YAML. For example, to set the `spec.nameResolution.component` property to `"sqlite"`, pass configuration options in the `spec.nameResolution.configuration` dictionary as shown below. +You can set name resolution components to use within the configuration file. For example, to set the `spec.nameResolution.component` property to `"sqlite"`, pass configuration options in the `spec.nameResolution.configuration` dictionary as shown below. -This is the basic example of a configuration resource: +This is a basic example of a configuration resource: ```yaml apiVersion: dapr.io/v1alpha1 @@ -226,7 +250,7 @@ spec: For more information, see: - [The name resolution component documentation]({{< ref supported-name-resolution >}}) for more examples. -- - [The Configuration YAML documentation]({{< ref configuration-schema.md >}}) to learn more about how to configure name resolution per component. +- [The Configuration file documentation]({{< ref configuration-schema.md >}}) to learn more about how to configure name resolution per component. #### Scope secret store access @@ -234,11 +258,11 @@ See the [Scoping secrets]({{< ref "secret-scope.md" >}}) guide for information a #### Access Control allow lists for building block APIs -See the [selectively enable Dapr APIs on the Dapr sidecar]({{< ref "api-allowlist.md" >}}) guide for information and examples on how to set ACLs on the building block APIs lists. +See the guide for [selectively enabling Dapr APIs on the Dapr sidecar]({{< ref "api-allowlist.md" >}}) for information and examples on how to set access control allow lists (ACLs) on the building block APIs lists. #### Access Control allow lists for service invocation API -See the [Allow lists for service invocation]({{< ref "invoke-allowlist.md" >}}) guide for information and examples on how to set allow lists with ACLs which using service invocation API. +See the [Allow lists for service invocation]({{< ref "invoke-allowlist.md" >}}) guide for information and examples on how to set allow lists with ACLs which use the service invocation API. #### Disallow usage of certain component types @@ -258,13 +282,23 @@ spec: - secretstores.local.file ``` -You can optionally specify a version to disallow by adding it at the end of the component name. For example, `state.in-memory/v1` disables initializing components of type `state.in-memory` and version `v1`, but does not disable a (hypothetical) `v2` version of the component. +Optionally, you can specify a version to disallow by adding it at the end of the component name. For example, `state.in-memory/v1` disables initializing components of type `state.in-memory` and version `v1`, but does not disable a (hypothetical) `v2` version of the component. + +{{% alert title="Note" color="primary" %}} + When you add the component type `secretstores.kubernetes` to the denylist, Dapr forbids the creation of _additional_ components of type `secretstores.kubernetes`. -> Note: One special note applies to the component type `secretstores.kubernetes`. When you add that component to the denylist, Dapr forbids the creation of _additional_ components of type `secretstores.kubernetes`. However, it does not disable the built-in Kubernetes secret store, which is created by Dapr automatically and is used to store secrets specified in Components specs. If you want to disable the built-in Kubernetes secret store, you need to use the `dapr.io/disable-builtin-k8s-secret-store` [annotation]({{< ref arguments-annotations-overview.md >}}). + However, it does not disable the built-in Kubernetes secret store, which is: + - Created by Dapr automatically + - Used to store secrets specified in Components specs + + If you want to disable the built-in Kubernetes secret store, you need to use the `dapr.io/disable-builtin-k8s-secret-store` [annotation]({{< ref arguments-annotations-overview.md >}}). +{{% /alert %}} #### Turning on preview features -See the [preview features]({{< ref "preview-features.md" >}}) guide for information and examples on how to opt-in to preview features for a release. Preview feature enable new capabilities to be added that still need more time until they become generally available (GA) in the runtime. +See the [preview features]({{< ref "preview-features.md" >}}) guide for information and examples on how to opt-in to preview features for a release. + +Enabling preview features unlock new capabilities to be added for dev/test, since they still need more time before becoming generally available (GA) in the runtime. ### Example sidecar configuration @@ -316,7 +350,9 @@ spec: ## Control plane configuration -There is a single configuration file called `daprsystem` installed with the Dapr control plane system services that applies global settings. This is only set up when Dapr is deployed to Kubernetes. +A single configuration file called `daprsystem` is installed with the Dapr control plane system services that applies global settings. + +> **This is only set up when Dapr is deployed to Kubernetes.** ### Control plane configuration settings @@ -353,3 +389,7 @@ spec: allowedClockSkew: 15m workloadCertTTL: 24h ``` + +## Next steps + +{{< button text="Learn about concurrency and rate limits" page="control-concurrency" >}} diff --git a/daprdocs/content/en/operations/configuration/control-concurrency.md b/daprdocs/content/en/operations/configuration/control-concurrency.md index 85b240c19b5..976b78ab980 100644 --- a/daprdocs/content/en/operations/configuration/control-concurrency.md +++ b/daprdocs/content/en/operations/configuration/control-concurrency.md @@ -3,30 +3,57 @@ type: docs title: "How-To: Control concurrency and rate limit applications" linkTitle: "Concurrency & rate limits" weight: 2000 -description: "Control how many requests and events will invoke your application simultaneously" +description: "Learn how to control how many requests and events can invoke your application simultaneously" --- -A common scenario in distributed computing is to only allow for a given number of requests to execute concurrently. -Using Dapr, you can control how many requests and events will invoke your application simultaneously. +Typically, in distributed computing, you may only want to allow for a given number of requests to execute concurrently. Using Dapr's `app-max-concurrency`, you can control how many requests and events can invoke your application simultaneously. -*Note that this rate limiting is guaranteed for every event that's coming from Dapr, meaning Pub/Sub events, direct invocation from other services, bindings events etc. Dapr can't enforce the concurrency policy on requests that are coming to your app externally.* +Default `app-max-concurreny` is set to `-1`, meaning no concurrency. -*Note that rate limiting per second can be achieved by using the **middleware.http.ratelimit** middleware. However, there is an important difference between the two approaches. The rate limit middleware is time bound and limits the number of requests per second, while the `app-max-concurrency` flag specifies the number of concurrent requests (and events) at any point of time. See [Rate limit middleware]({{< ref middleware-rate-limit.md >}}). * +## Different approaches -Watch this [video](https://youtu.be/yRI5g6o_jp8?t=1710) on how to control concurrency and rate limiting ". +While this guide focuses on `app-max-concurrency`, you can also limit request rate per second using the **`middleware.http.ratelimit`** middleware. However, it's important to understand the difference between the two approaches: + +- `middleware.http.ratelimit`: Time bound and limits the number of requests per second +- `app-max-concurrency`: Specifies the number of concurrent requests (and events) at any point of time. + +See [Rate limit middleware]({{< ref middleware-rate-limit.md >}}) for more information about that approach. + +## Demo + +Watch this [video](https://youtu.be/yRI5g6o_jp8?t=1710) on how to control concurrency and rate limiting. -## Setting app-max-concurrency +## Configure `app-max-concurrency` + +Without using Dapr, you would need to create some sort of a semaphore in the application and take care of acquiring and releasing it. + +Using Dapr, you don't need to make any code changes to your application. + +Select how you'd like to configure `app-max-concurrency`. + +{{< tabs "CLI" Kubernetes >}} + + +{{% codetab %}} + +To set concurrency limits with the Dapr CLI for running on your local dev machine, add the `app-max-concurrency` flag: + +```bash +dapr run --app-max-concurrency 1 --app-port 5000 python ./app.py +``` -Without using Dapr, a developer would need to create some sort of a semaphore in the application and take care of acquiring and releasing it. -Using Dapr, there are no code changes needed to an app. +The above example effectively turns your app into a single concurrent service. -### Setting app-max-concurrency in Kubernetes +{{% /codetab %}} -To set app-max-concurrency in Kubernetes, add the following annotation to your pod: + +{{% codetab %}} + +To configure concurrency limits in Kubernetes, add the following annotation to your pod: ```yaml apiVersion: apps/v1 @@ -50,15 +77,22 @@ spec: dapr.io/app-id: "nodesubscriber" dapr.io/app-port: "3000" dapr.io/app-max-concurrency: "1" -... +#... ``` -### Setting app-max-concurrency using the Dapr CLI +{{% /codetab %}} -To set app-max-concurrency with the Dapr CLI for running on your local dev machine, add the `app-max-concurrency` flag: +{{< /tabs >}} -```bash -dapr run --app-max-concurrency 1 --app-port 5000 python ./app.py -``` +## Limitations + +### Controlling concurrency on external requests +Rate limiting is guaranteed for every event coming _from_ Dapr, including pub/sub events, direct invocation from other services, bindings events, etc. However, Dapr can't enforce the concurrency policy on requests that are coming _to_ your app externally. + +## Related links + +[Arguments and annotations]({{< ref arguments-annotations-overview.md >}}) + +## Next steps -The above examples will effectively turn your app into a single concurrent service. +{{< button text="Limit secret store access" page="secret-scope" >}} diff --git a/daprdocs/content/en/operations/configuration/grpc.md b/daprdocs/content/en/operations/configuration/grpc.md index 59c51a4cec3..5ab2df15f07 100644 --- a/daprdocs/content/en/operations/configuration/grpc.md +++ b/daprdocs/content/en/operations/configuration/grpc.md @@ -3,20 +3,21 @@ type: docs title: "How-To: Configure Dapr to use gRPC" linkTitle: "Use gRPC interface" weight: 5000 -description: "How to configure Dapr to use gRPC for low-latency, high performance scenarios" +description: "Configure Dapr to use gRPC for low-latency, high performance scenarios" --- -Dapr implements both an HTTP and a gRPC API for local calls. gRPC is useful for low-latency, high performance scenarios and has language integration using the proto clients. - -You can find a list of auto-generated clients [here]({{< ref sdks >}}). +Dapr implements both an HTTP and a gRPC API for local calls. gRPC is useful for low-latency, high performance scenarios and has language integration using the proto clients. [You can see the full list of auto-generated clients (Dapr SDKs)]({{< ref sdks >}}). The Dapr runtime implements a [proto service](https://github.com/dapr/dapr/blob/master/dapr/proto/runtime/v1/dapr.proto) that apps can communicate with via gRPC. -In addition to calling Dapr via gRPC, Dapr can communicate with an application via gRPC. To do that, the app needs to host a gRPC server and implements the [Dapr appcallback service](https://github.com/dapr/dapr/blob/master/dapr/proto/runtime/v1/appcallback.proto) +Not only can you call Dapr via gRPC, Dapr can communicate with an application via gRPC. To do that, the app needs to host a gRPC server and implement the [Dapr `appcallback` service](https://github.com/dapr/dapr/blob/master/dapr/proto/runtime/v1/appcallback.proto) ## Configuring Dapr to communicate with an app via gRPC -### Self hosted +{{< tabs "Self-hosted" Kubernetes >}} + + +{{% codetab %}} When running in self hosted mode, use the `--app-protocol` flag to tell Dapr to use gRPC to talk to the app: @@ -25,8 +26,10 @@ dapr run --app-protocol grpc --app-port 5005 node app.js ``` This tells Dapr to communicate with your app via gRPC over port `5005`. +{{% /codetab %}} -### Kubernetes + +{{% codetab %}} On Kubernetes, set the following annotations in your deployment YAML: @@ -52,5 +55,13 @@ spec: dapr.io/app-id: "myapp" dapr.io/app-protocol: "grpc" dapr.io/app-port: "5005" -... -``` \ No newline at end of file +#... +``` + +{{% /codetab %}} + +{{< /tabs >}} + +## Next steps + +{{< button text="Handle large HTTP header sizes" page="increase-read-buffer-size" >}} \ No newline at end of file diff --git a/daprdocs/content/en/operations/configuration/increase-read-buffer-size.md b/daprdocs/content/en/operations/configuration/increase-read-buffer-size.md index a8528e09bad..9fcb80c4fb0 100644 --- a/daprdocs/content/en/operations/configuration/increase-read-buffer-size.md +++ b/daprdocs/content/en/operations/configuration/increase-read-buffer-size.md @@ -1,20 +1,23 @@ --- type: docs -title: "How-To: Handle large http header size" +title: "How-To: Handle large HTTP header size" linkTitle: "HTTP header size" weight: 6000 -description: "Configure a larger http read buffer size" +description: "Configure a larger HTTP read buffer size" --- -Dapr has a default limit of 4KB for the http header read buffer size. When sending http headers that are bigger than the default 4KB, you can increase this value. Otherwise, you may encounter a `Too big request header` service invocation error. You can change the http header size by using the `dapr.io/http-read-buffer-size` annotation or `--dapr-http-read-buffer-size` flag when using the CLI. - +Dapr has a default limit of 4KB for the HTTP header read buffer size. If you're sending HTTP headers larger than the default 4KB, you may encounter a `Too big request header` service invocation error. +You can increase the HTTP header size by using: +- The `dapr.io/http-read-buffer-size` annotation, or +- The `--dapr-http-read-buffer-size` flag when using the CLI. {{< tabs Self-hosted Kubernetes >}} + {{% codetab %}} -When running in self hosted mode, use the `--dapr-http-read-buffer-size` flag to configure Dapr to use non-default http header size: +When running in self-hosted mode, use the `--dapr-http-read-buffer-size` flag to configure Dapr to use non-default http header size: ```bash dapr run --dapr-http-read-buffer-size 16 node app.js @@ -23,10 +26,11 @@ This tells Dapr to set maximum read buffer size to `16` KB. {{% /codetab %}} - + {{% codetab %}} On Kubernetes, set the following annotations in your deployment YAML: + ```yaml apiVersion: apps/v1 kind: Deployment @@ -49,7 +53,7 @@ spec: dapr.io/app-id: "myapp" dapr.io/app-port: "8000" dapr.io/http-read-buffer-size: "16" -... +#... ``` {{% /codetab %}} @@ -57,4 +61,8 @@ spec: {{< /tabs >}} ## Related links -- [Dapr Kubernetes pod annotations spec]({{< ref arguments-annotations-overview.md >}}) +[Dapr Kubernetes pod annotations spec]({{< ref arguments-annotations-overview.md >}}) + +## Next steps + +{{< button text="Handle large HTTP body requests" page="increase-request-size" >}} diff --git a/daprdocs/content/en/operations/configuration/increase-request-size.md b/daprdocs/content/en/operations/configuration/increase-request-size.md index 2faadecf085..25461e3e83f 100644 --- a/daprdocs/content/en/operations/configuration/increase-request-size.md +++ b/daprdocs/content/en/operations/configuration/increase-request-size.md @@ -6,15 +6,16 @@ weight: 6000 description: "Configure http requests that are bigger than 4 MB" --- -By default Dapr has a limit for the request body size which is set to 4 MB, however you can change this by defining `dapr.io/http-max-request-size` annotation or `--dapr-http-max-request-size` flag. - - +By default, Dapr has a limit for the request body size, set to 4MB. You can change this by defining: +- The `dapr.io/http-max-request-size` annotation, or +- The `--dapr-http-max-request-size` flag. {{< tabs Self-hosted Kubernetes >}} + {{% codetab %}} -When running in self hosted mode, use the `--dapr-http-max-request-size` flag to configure Dapr to use non-default request body size: +When running in self-hosted mode, use the `--dapr-http-max-request-size` flag to configure Dapr to use non-default request body size: ```bash dapr run --dapr-http-max-request-size 16 node app.js @@ -23,10 +24,11 @@ This tells Dapr to set maximum request body size to `16` MB. {{% /codetab %}} - + {{% codetab %}} On Kubernetes, set the following annotations in your deployment YAML: + ```yaml apiVersion: apps/v1 kind: Deployment @@ -49,7 +51,7 @@ spec: dapr.io/app-id: "myapp" dapr.io/app-port: "8000" dapr.io/http-max-request-size: "16" -... +#... ``` {{% /codetab %}} @@ -57,4 +59,9 @@ spec: {{< /tabs >}} ## Related links -- [Dapr Kubernetes pod annotations spec]({{< ref arguments-annotations-overview.md >}}) + +[Dapr Kubernetes pod annotations spec]({{< ref arguments-annotations-overview.md >}}) + +## Next steps + +{{< button text="Install sidecar certificates" page="install-certificates" >}} \ No newline at end of file diff --git a/daprdocs/content/en/operations/configuration/install-certificates.md b/daprdocs/content/en/operations/configuration/install-certificates.md index 071753ef93d..7c2b79f8c86 100644 --- a/daprdocs/content/en/operations/configuration/install-certificates.md +++ b/daprdocs/content/en/operations/configuration/install-certificates.md @@ -6,20 +6,26 @@ weight: 6500 description: "Configure the Dapr sidecar container to trust certificates" --- -The Dapr sidecar can be configured to trust certificates for communicating with external services. This is useful in scenarios where a self-signed certificate needs to be trusted. For example, using an HTTP binding or configuring an outbound proxy for the sidecar. Both certificate authority (CA) certificates and leaf certificates are supported. +The Dapr sidecar can be configured to trust certificates for communicating with external services. This is useful in scenarios where a self-signed certificate needs to be trusted, such as: +- Using an HTTP binding +- Configuring an outbound proxy for the sidecar + +Both certificate authority (CA) certificates and leaf certificates are supported. {{< tabs Self-hosted Kubernetes >}} + {{% codetab %}} -When the sidecar is not running inside a container, certificates must be directly installed on the host operating system. +You can make the following configurations when the sidecar is running as a container. + +1. Configure certificates to be available to the sidecar container using volume mounts. +1. Point the environment variable `SSL_CERT_DIR` in the sidecar container to the directory containing the certificates. + +> **Note:** For Windows containers, make sure the container is running with administrator privileges so it can install the certificates. -When the sidecar is running as a container: -1. Certificates must be available to the sidecar container. This can be configured using volume mounts. -1. The environment variable `SSL_CERT_DIR` must be set in the sidecar container, pointing to the directory containing the certificates. -1. For Windows containers, the container needs to run with administrator privileges to be able to install the certificates. +The following example uses Docker Compose to install certificates (present locally in the `./certificates` directory) in the sidecar container: -Below is an example that uses Docker Compose to install certificates (present locally in the `./certificates` directory) in the sidecar container: ```yaml version: '3' services: @@ -39,16 +45,22 @@ services: # user: ContainerAdministrator ``` -{{% /codetab %}} +> **Note:** When the sidecar is not running inside a container, certificates must be directly installed on the host operating system. +{{% /codetab %}} + {{% codetab %}} On Kubernetes: -1. Certificates must be available to the sidecar container using a volume mount. -1. The environment variable `SSL_CERT_DIR` must be set in the sidecar container, pointing to the directory containing the certificates. -The YAML below is an example of a deployment that attaches a pod volume to the sidecar, and sets `SSL_CERT_DIR` to install the certificates. +1. Configure certificates to be available to the sidecar container using a volume mount. +1. Point the environment variable `SSL_CERT_DIR` in the sidecar container to the directory containing the certificates. + +The following example YAML shows a deployment that: +- Attaches a pod volume to the sidecar +- Sets `SSL_CERT_DIR` to install the certificates + ```yaml apiVersion: apps/v1 kind: Deployment @@ -77,23 +89,21 @@ spec: - name: certificates-vol hostPath: path: /certificates -... +#... ``` -**Note**: When using Windows containers, the sidecar container is started with admin privileges, which is required to install the certificates. This does not apply to Linux containers. +> **Note**: When using Windows containers, the sidecar container is started with admin privileges, which is required to install the certificates. This does not apply to Linux containers. {{% /codetab %}} {{< /tabs >}} -
- -All the certificates in the directory pointed by `SSL_CERT_DIR` are installed. +After following these steps, all the certificates in the directory pointed by `SSL_CERT_DIR` are installed. -1. On Linux containers, all the certificate extensions supported by OpenSSL are supported. For more information, see https://www.openssl.org/docs/man1.1.1/man1/openssl-rehash.html -1. On Windows container, all the certificate extensions supported by certoc.exe are supported. For more information, see certoc.exe present in [Windows Server Core](https://hub.docker.com/_/microsoft-windows-servercore) +- **On Linux containers:** All the certificate extensions supported by OpenSSL are supported. [Learn more.](https://www.openssl.org/docs/man1.1.1/man1/openssl-rehash.html) +- **On Windows container:** All the certificate extensions supported by `certoc.exe` are supported. [See certoc.exe present in Windows Server Core](https://hub.docker.com/_/microsoft-windows-servercore). -## Example +## Demo Watch the demo on using installing SSL certificates and securely using the HTTP binding in community call 64: @@ -106,3 +116,7 @@ Watch the demo on using installing SSL certificates and securely using the HTTP - [HTTP binding spec]({{< ref http.md >}}) - [(Kubernetes) How-to: Mount Pod volumes to the Dapr sidecar]({{< ref kubernetes-volume-mounts.md >}}) - [Dapr Kubernetes pod annotations spec]({{< ref arguments-annotations-overview.md >}}) + +## Next steps + +{{< button text="Enable preview features" page="preview-features" >}} \ No newline at end of file diff --git a/daprdocs/content/en/operations/configuration/invoke-allowlist.md b/daprdocs/content/en/operations/configuration/invoke-allowlist.md index 725c8308491..f9afe029926 100644 --- a/daprdocs/content/en/operations/configuration/invoke-allowlist.md +++ b/daprdocs/content/en/operations/configuration/invoke-allowlist.md @@ -3,71 +3,87 @@ type: docs title: "How-To: Apply access control list configuration for service invocation" linkTitle: "Service Invocation access control" weight: 4000 -description: "Restrict what operations *calling* applications can perform, via service invocation, on the *called* application" +description: "Restrict what operations calling applications can perform" --- -Access control enables the configuration of policies that restrict what operations *calling* applications can perform, via service invocation, on the *called* application. To limit access to a called applications from specific operations and HTTP verbs from the calling applications, you can define an access control policy specification in configuration. +Using access control, you can configure policies that restrict what the operations _calling_ applications can perform, via service invocation, on the _called_ application. You can define an access control policy specification in the Configuration schema to limit access: +- To a called application from specific operations, and +- To HTTP verbs from the calling applications. -An access control policy is specified in configuration and be applied to Dapr sidecar for the *called* application. Example access policies are shown below and access to the called app is based on the matched policy action. You can provide a default global action for all calling applications and if no access control policy is specified, the default behavior is to allow all calling applications to access to the called app. +An access control policy is specified in Configuration and applied to the Dapr sidecar for the _called_ application. Access to the called app is based on the matched policy action. -## Concepts +You can provide a default global action for all calling applications. If no access control policy is specified, the default behavior is to allow all calling applications to access to the called app. -**TrustDomain** - A "trust domain" is a logical group to manage trust relationships. Every application is assigned a trust domain which can be specified in the access control list policy spec. If no policy spec is defined or an empty trust domain is specified, then a default value "public" is used. This trust domain is used to generate the identity of the application in the TLS cert. +[See examples of access policies.](#example-scenarios) -**App Identity** - Dapr requests the sentry service to generate a [SPIFFE](https://spiffe.io/) id for all applications and this id is attached in the TLS cert. The SPIFFE id is of the format: `**spiffe://\
+
+You can see the `job_name` and its discovered targets.
+
+
+
## Example