mirror of https://github.com/dapr/docs.git
successful upmerge
Signed-off-by: Hannah Hunter <hannahhunter@microsoft.com>
This commit is contained in:
Hannah Hunter
commit
39db5686aa
|
|
@ -1,5 +1,7 @@
|
|||
# Dapr documentation
|
||||
|
||||
[](https://github.com/dapr/docs/blob/v1.13/LICENSE) [](https://github.com/dapr/docs/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22) [](http://bit.ly/dapr-discord) [](https://youtube.com/@daprdev) [](https://twitter.com/daprdev)
|
||||
|
||||
If you are looking to explore the Dapr documentation, please go to the documentation website:
|
||||
|
||||
[**https://docs.dapr.io**](https://docs.dapr.io)
|
||||
|
|
|
|||
|
|
@ -21,12 +21,12 @@ Dapr provides the following building blocks:
|
|||
| Building Block | Endpoint | Description |
|
||||
|----------------|----------|-------------|
|
||||
| [**Service-to-service invocation**]({{< ref "service-invocation-overview.md" >}}) | `/v1.0/invoke` | Service invocation enables applications to communicate with each other through well-known endpoints in the form of http or gRPC messages. Dapr provides an endpoint that acts as a combination of a reverse proxy with built-in service discovery, while leveraging built-in distributed tracing and error handling.
|
||||
| [**State management**]({{< ref "state-management-overview.md" >}}) | `/v1.0/state` | Application state is anything an application wants to preserve beyond a single session. Dapr provides a key/value-based state and query APIs with pluggable state stores for persistence.
|
||||
| [**Publish and subscribe**]({{< ref "pubsub-overview.md" >}}) | `/v1.0/publish` `/v1.0/subscribe`| Pub/Sub is a loosely coupled messaging pattern where senders (or publishers) publish messages to a topic, to which subscribers subscribe. Dapr supports the pub/sub pattern between applications.
|
||||
| [**Workflows**]({{< ref "workflow-overview.md" >}}) | `/v1.0-beta1/workflow` | The Workflow API enables you to define long running, persistent processes or data flows that span multiple microservices using Dapr workflows or workflow components. The Workflow API can be combined with other Dapr API building blocks. For example, a workflow can call another service with service invocation or retrieve secrets, providing flexibility and portability.
|
||||
| [**State management**]({{< ref "state-management-overview.md" >}}) | `/v1.0/state` | Application state is anything an application wants to preserve beyond a single session. Dapr provides a key/value-based state and query APIs with pluggable state stores for persistence.
|
||||
| [**Bindings**]({{< ref "bindings-overview.md" >}}) | `/v1.0/bindings` | A binding provides a bi-directional connection to an external cloud/on-premise service or system. Dapr allows you to invoke the external service through the Dapr binding API, and it allows your application to be triggered by events sent by the connected service.
|
||||
| [**Actors**]({{< ref "actors-overview.md" >}}) | `/v1.0/actors` | An actor is an isolated, independent unit of compute and state with single-threaded execution. Dapr provides an actor implementation based on the virtual actor pattern which provides a single-threaded programming model and where actors are garbage collected when not in use.
|
||||
| [**Secrets**]({{< ref "secrets-overview.md" >}}) | `/v1.0/secrets` | Dapr provides a secrets building block API and integrates with secret stores such as public cloud stores, local stores and Kubernetes to store the secrets. Services can call the secrets API to retrieve secrets, for example to get a connection string to a database.
|
||||
| [**Configuration**]({{< ref "configuration-api-overview.md" >}}) | `/v1.0/configuration` | The Configuration API enables you to retrieve and subscribe to application configuration items for supported configuration stores. This enables an application to retrieve specific configuration information, for example, at start up or when configuration changes are made in the store.
|
||||
| [**Distributed lock**]({{< ref "distributed-lock-api-overview.md" >}}) | `/v1.0-alpha1/lock` | The distributed lock API enables you to take a lock on a resource so that multiple instances of an application can access the resource without conflicts and provide consistency guarantees.
|
||||
| [**Workflows**]({{< ref "workflow-overview.md" >}}) | `/v1.0-beta1/workflow` | The Workflow API enables you to define long running, persistent processes or data flows that span multiple microservices using Dapr workflows or workflow components. The Workflow API can be combined with other Dapr API building blocks. For example, a workflow can call another service with service invocation or retrieve secrets, providing flexibility and portability.
|
||||
| [**Cryptography**]({{< ref "cryptography-overview.md" >}}) | `/v1.0-alpha1/crypto` | The Cryptography API enables you to perform cryptographic operations, such as encrypting and decrypting messages, without exposing keys to your application.
|
||||
|
|
@ -64,13 +64,6 @@ The component is unavailable for a short period of time during reload and reinit
|
|||
|
||||
The following are the component types provided by Dapr:
|
||||
|
||||
### State stores
|
||||
|
||||
State store components are data stores (databases, files, memory) that store key-value pairs as part of the [state management]({{< ref "state-management-overview.md" >}}) building block.
|
||||
|
||||
- [List of state stores]({{< ref supported-state-stores >}})
|
||||
- [State store implementations](https://github.com/dapr/components-contrib/tree/master/state)
|
||||
|
||||
### Name resolution
|
||||
|
||||
Name resolution components are used with the [service invocation]({{< ref "service-invocation-overview.md" >}}) building block to integrate with the hosting environment and provide service-to-service discovery. For example, the Kubernetes name resolution component integrates with the Kubernetes DNS service, self-hosted uses mDNS and clusters of VMs can use the Consul name resolution component.
|
||||
|
|
@ -85,6 +78,20 @@ Pub/sub broker components are message brokers that can pass messages to/from ser
|
|||
- [List of pub/sub brokers]({{< ref supported-pubsub >}})
|
||||
- [Pub/sub broker implementations](https://github.com/dapr/components-contrib/tree/master/pubsub)
|
||||
|
||||
### Workflows
|
||||
|
||||
A [workflow]({{< ref workflow-overview.md >}}) is custom application logic that defines a reliable business process or data flow. Workflow components are workflow runtimes (or engines) that run the business logic written for that workflow and store their state into a state store.
|
||||
|
||||
<!--- [List of supported workflows]()
|
||||
- [Workflow implementations](https://github.com/dapr/components-contrib/tree/master/workflows)-->
|
||||
|
||||
### State stores
|
||||
|
||||
State store components are data stores (databases, files, memory) that store key-value pairs as part of the [state management]({{< ref "state-management-overview.md" >}}) building block.
|
||||
|
||||
- [List of state stores]({{< ref supported-state-stores >}})
|
||||
- [State store implementations](https://github.com/dapr/components-contrib/tree/master/state)
|
||||
|
||||
### Bindings
|
||||
|
||||
External resources can connect to Dapr in order to trigger a method on an application or be called from an application as part of the [bindings]({{< ref bindings-overview.md >}}) building block.
|
||||
|
|
@ -113,13 +120,6 @@ Lock components are used as a distributed lock to provide mutually exclusive acc
|
|||
- [List of supported locks]({{< ref supported-locks >}})
|
||||
- [Lock implementations](https://github.com/dapr/components-contrib/tree/master/lock)
|
||||
|
||||
### Workflows
|
||||
|
||||
A [workflow]({{< ref workflow-overview.md >}}) is custom application logic that defines a reliable business process or data flow. Workflow components are workflow runtimes (or engines) that run the business logic written for that workflow and store their state into a state store.
|
||||
|
||||
<!--- [List of supported workflows]()
|
||||
- [Workflow implementations](https://github.com/dapr/components-contrib/tree/master/workflows)-->
|
||||
|
||||
### Cryptography
|
||||
|
||||
[Cryptography]({{< ref cryptography-overview.md >}}) components are used to perform crypographic operations, including encrypting and decrypting messages, without exposing keys to your application.
|
||||
|
|
|
|||
|
|
@ -45,14 +45,14 @@ Each of these building block APIs is independent, meaning that you can use any n
|
|||
| Building Block | Description |
|
||||
|----------------|-------------|
|
||||
| [**Service-to-service invocation**]({{< ref "service-invocation-overview.md" >}}) | Resilient service-to-service invocation enables method calls, including retries, on remote services, wherever they are located in the supported hosting environment.
|
||||
| [**State management**]({{< ref "state-management-overview.md" >}}) | With state management for storing and querying key/value pairs, long-running, highly available, stateful services can be easily written alongside stateless services in your application. The state store is pluggable and examples include AWS DynamoDB, Azure Cosmos DB, Azure SQL Server, GCP Firebase, PostgreSQL or Redis, among others.
|
||||
| [**Publish and subscribe**]({{< ref "pubsub-overview.md" >}}) | Publishing events and subscribing to topics between services enables event-driven architectures to simplify horizontal scalability and make them resilient to failure. Dapr provides at-least-once message delivery guarantee, message TTL, consumer groups and other advance features.
|
||||
| [**Workflows**]({{< ref "workflow-overview.md" >}}) | The workflow API can be combined with other Dapr building blocks to define long running, persistent processes or data flows that span multiple microservices using Dapr workflows or workflow components.
|
||||
| [**State management**]({{< ref "state-management-overview.md" >}}) | With state management for storing and querying key/value pairs, long-running, highly available, stateful services can be easily written alongside stateless services in your application. The state store is pluggable and examples include AWS DynamoDB, Azure Cosmos DB, Azure SQL Server, GCP Firebase, PostgreSQL or Redis, among others.
|
||||
| [**Resource bindings**]({{< ref "bindings-overview.md" >}}) | Resource bindings with triggers builds further on event-driven architectures for scale and resiliency by receiving and sending events to and from any external source such as databases, queues, file systems, etc.
|
||||
| [**Actors**]({{< ref "actors-overview.md" >}}) | A pattern for stateful and stateless objects that makes concurrency simple, with method and state encapsulation. Dapr provides many capabilities in its actor runtime, including concurrency, state, and life-cycle management for actor activation/deactivation, and timers and reminders to wake up actors.
|
||||
| [**Secrets**]({{< ref "secrets-overview.md" >}}) | The secrets management API integrates with public cloud and local secret stores to retrieve the secrets for use in application code.
|
||||
| [**Configuration**]({{< ref "configuration-api-overview.md" >}}) | The configuration API enables you to retrieve and subscribe to application configuration items from configuration stores.
|
||||
| [**Distributed lock**]({{< ref "distributed-lock-api-overview.md" >}}) | The distributed lock API enables your application to acquire a lock for any resource that gives it exclusive access until either the lock is released by the application, or a lease timeout occurs.
|
||||
| [**Workflows**]({{< ref "workflow-overview.md" >}}) | The workflow API can be combined with other Dapr building blocks to define long running, persistent processes or data flows that span multiple microservices using Dapr workflows or workflow components.
|
||||
| [**Cryptography**]({{< ref "cryptography-overview.md" >}}) | The cryptography API provides an abstraction layer on top of security infrastructure such as key vaults. It contains APIs that allow you to perform cryptographic operations, such as encrypting and decrypting messages, without exposing keys to your applications.
|
||||
|
||||
### Cross-cutting APIs
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Dapr bot is triggered by a list of commands that helps with common tasks in the
|
|||
|
||||
| Command | Target | Description | Who can use | Repository |
|
||||
| ---------------- | --------------------- | -------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | -------------------------------------- |
|
||||
| `/assign` | Issue | Assigns an issue to a user or group of users | Anyone | `dapr`, `docs`, `quickstarts`, `cli`, `components-contrib`, `go-sdk`, `js-sdk`, `java-sdk`, `python-sdk`, `dotnet-sdk` |
|
||||
| `/assign` | Issue | Assigns an issue to a user or group of users | Anyone | `dapr`, `docs`, `quickstarts`, `cli`, `components-contrib`, `go-sdk`, `js-sdk`, `java-sdk`, `python-sdk`, `dotnet-sdk`, `rust-sdk` |
|
||||
| `/ok-to-test` | Pull request | `dapr`: trigger end to end tests <br/> `components-contrib`: trigger conformance and certification tests | Users listed in the [bot](https://github.com/dapr/dapr/blob/master/.github/scripts/dapr_bot.js) | `dapr`, `components-contrib` |
|
||||
| `/ok-to-perf` | Pull request | Trigger performance tests. | Users listed in the [bot](https://github.com/dapr/dapr/blob/master/.github/scripts/dapr_bot.js) | `dapr` |
|
||||
| `/make-me-laugh` | Issue or pull request | Posts a random joke | Users listed in the [bot](https://github.com/dapr/dapr/blob/master/.github/scripts/dapr_bot.js) | `dapr`, `components-contrib` |
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ We welcome community members giving presentations on Dapr and spreading the word
|
|||
{{% alert color="primary" %}}
|
||||
If you're using the PowerPoint template with MacOS, please install the Space Grotesk font to ensure the text is rendered properly:
|
||||
```sh
|
||||
brew install --cask homebrew/cask-fonts/font-space-grotesk
|
||||
brew install --cask font-space-grotesk
|
||||
```
|
||||
{{% /alert %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Actors"
|
||||
linkTitle: "Actors"
|
||||
weight: 50
|
||||
weight: 60
|
||||
description: Encapsulate code and data in reusable actor objects as a common microservices design pattern
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -52,6 +52,12 @@ You would use Dapr Workflow when you need to define and orchestrate complex work
|
|||
|
||||
[Learn more about Dapr Workflow and how to use workflows in your application.]({{< ref workflow-overview.md >}})
|
||||
|
||||
## Actor types and actor IDs
|
||||
|
||||
Actors are uniquely defined as an instance of an actor type, similar to how an object is an instance of a class. For example, you might have an actor type that implements the functionality of a calculator. There could be many actors of that type distributed across various nodes in a cluster.
|
||||
|
||||
Each actor is uniquely identified by an actor ID. An actor ID can be _any_ string value you choose. If you do not provide an actor ID, Dapr generates a random string for you as an ID.
|
||||
|
||||
## Features
|
||||
|
||||
### Actor lifetime
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Bindings"
|
||||
linkTitle: "Bindings"
|
||||
weight: 40
|
||||
weight: 50
|
||||
description: Interface with or be triggered from external systems
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Cryptography"
|
||||
linkTitle: "Cryptography"
|
||||
weight: 110
|
||||
weight: 100
|
||||
description: "Perform cryptographic operations without exposing keys to your application"
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Publish & subscribe messaging"
|
||||
linkTitle: "Publish & subscribe"
|
||||
weight: 30
|
||||
weight: 20
|
||||
description: Secure, scalable messaging between services
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ scopes:
|
|||
|
||||
In the programmatic approach, the `routes` structure is returned instead of `route`. The JSON structure matches the declarative YAML:
|
||||
|
||||
{{< tabs Python Node "C#" Go PHP>}}
|
||||
{{< tabs Python JavaScript ".NET" Go PHP>}}
|
||||
|
||||
{{% codetab %}}
|
||||
```python
|
||||
|
|
|
|||
|
|
@ -69,17 +69,17 @@ The table below shows which applications are allowed to publish into the topics:
|
|||
|
||||
| | topic1 | topic2 | topic3 |
|
||||
|------|--------|--------|--------|
|
||||
| app1 | X | | |
|
||||
| app2 | | X | X |
|
||||
| app1 | ✅ | | |
|
||||
| app2 | | ✅ | ✅ |
|
||||
| app3 | | | |
|
||||
|
||||
The table below shows which applications are allowed to subscribe to the topics:
|
||||
|
||||
| | topic1 | topic2 | topic3 |
|
||||
|------|--------|--------|--------|
|
||||
| app1 | X | X | X |
|
||||
| app1 | ✅ | ✅ | ✅ |
|
||||
| app2 | | | |
|
||||
| app3 | X | | |
|
||||
| app3 | ✅ | | |
|
||||
|
||||
> Note: If an application is not listed (e.g. app1 in subscriptionScopes) it is allowed to subscribe to all topics. Because `allowedTopics` is not used and app1 does not have any subscription scopes, it can also use additional topics not listed above.
|
||||
|
||||
|
|
@ -143,17 +143,17 @@ The table below shows which application is allowed to publish into the topics:
|
|||
|
||||
| | A | B | C |
|
||||
|------|---|---|---|
|
||||
| app1 | X | | |
|
||||
| app2 | X | X | |
|
||||
| app3 | X | X | |
|
||||
| app1 | ✅ | | |
|
||||
| app2 | ✅ | ✅ | |
|
||||
| app3 | ✅ | ✅ | |
|
||||
|
||||
The table below shows which application is allowed to subscribe to the topics:
|
||||
|
||||
| | A | B | C |
|
||||
|------|---|---|---|
|
||||
| app1 | | | |
|
||||
| app2 | X | | |
|
||||
| app3 | X | X | |
|
||||
| app2 | ✅ | | |
|
||||
| app3 | ✅ | ✅ | |
|
||||
|
||||
## Example 4: Mark topics as protected
|
||||
|
||||
|
|
@ -187,17 +187,17 @@ The table below shows which application is allowed to publish into the topics:
|
|||
|
||||
| | A | B | C |
|
||||
|------|---|---|---|
|
||||
| app1 | X | X | |
|
||||
| app2 | | X | |
|
||||
| app3 | | | X |
|
||||
| app1 | ✅ | ✅ | |
|
||||
| app2 | | ✅ | |
|
||||
| app3 | | | ✅ |
|
||||
|
||||
The table below shows which application is allowed to subscribe to the topics:
|
||||
|
||||
| | A | B | C |
|
||||
|------|---|---|---|
|
||||
| app1 | X | X | |
|
||||
| app2 | | X | |
|
||||
| app3 | | | X |
|
||||
| app1 | ✅ | ✅ | |
|
||||
| app2 | | ✅ | |
|
||||
| app3 | | | ✅ |
|
||||
|
||||
|
||||
## Demo
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ There are two ways to invoke a non-Dapr endpoint when communicating either to Da
|
|||
```
|
||||
|
||||
### Using appId when calling Dapr enabled applications
|
||||
AppIDs are always used to call Dapr applications with the `appID` and `my-method``. Read the [How-To: Invoke services using HTTP]({{< ref howto-invoke-discover-services.md >}}) guide for more information. For example:
|
||||
AppIDs are always used to call Dapr applications with the `appID` and `my-method`. Read the [How-To: Invoke services using HTTP]({{< ref howto-invoke-discover-services.md >}}) guide for more information. For example:
|
||||
|
||||
```sh
|
||||
localhost:3500/v1.0/invoke/<appID>/method/<my-method>
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "State management"
|
||||
linkTitle: "State management"
|
||||
weight: 20
|
||||
weight: 40
|
||||
description: Create long running stateful services
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -537,7 +537,7 @@ Try getting state again. Note that no value is returned.
|
|||
|
||||
Below are code examples that leverage Dapr SDKs for saving and retrieving multiple states.
|
||||
|
||||
{{< tabs Dotnet Java Python Javascript "HTTP API (Bash)" "HTTP API (PowerShell)">}}
|
||||
{{< tabs Dotnet Java Python Go Javascript "HTTP API (Bash)" "HTTP API (PowerShell)">}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
|
|
@ -656,6 +656,56 @@ dapr run --app-id orderprocessing --app-port 6001 --dapr-http-port 3601 --dapr-g
|
|||
|
||||
{{% codetab %}}
|
||||
|
||||
```go
|
||||
// dependencies
|
||||
import (
|
||||
"context"
|
||||
"log"
|
||||
"math/rand"
|
||||
"strconv"
|
||||
"time"
|
||||
|
||||
dapr "github.com/dapr/go-sdk/client"
|
||||
)
|
||||
|
||||
// code
|
||||
func main() {
|
||||
const STATE_STORE_NAME = "statestore"
|
||||
rand.Seed(time.Now().UnixMicro())
|
||||
for i := 0; i < 10; i++ {
|
||||
orderId := rand.Intn(1000-1) + 1
|
||||
client, err := dapr.NewClient()
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
defer client.Close()
|
||||
ctx := context.Background()
|
||||
err = client.SaveState(ctx, STATE_STORE_NAME, "order_1", []byte(strconv.Itoa(orderId)), nil)
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
keys := []string{"key1", "key2", "key3"}
|
||||
items, err := client.GetBulkState(ctx, STATE_STORE_NAME, keys, nil, 100)
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
for _, item := range items {
|
||||
log.Println("Item from GetBulkState:", string(item.Value))
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
To launch a Dapr sidecar for the above example application, run a command similar to the following:
|
||||
|
||||
```bash
|
||||
dapr run --app-id orderprocessing --app-port 6001 --dapr-http-port 3601 --dapr-grpc-port 60001 go run OrderProcessingService.go
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```javascript
|
||||
//dependencies
|
||||
import { DaprClient, HttpMethod, CommunicationProtocolEnum } from '@dapr/dapr';
|
||||
|
|
@ -738,7 +788,7 @@ State transactions require a state store that supports multi-item transactions.
|
|||
|
||||
Below are code examples that leverage Dapr SDKs for performing state transactions.
|
||||
|
||||
{{< tabs Dotnet Java Python Javascript "HTTP API (Bash)" "HTTP API (PowerShell)">}}
|
||||
{{< tabs Dotnet Java Python Go Javascript "HTTP API (Bash)" "HTTP API (PowerShell)">}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
|
|
@ -893,6 +943,79 @@ dapr run --app-id orderprocessing --app-port 6001 --dapr-http-port 3601 --dapr-g
|
|||
|
||||
{{% codetab %}}
|
||||
|
||||
```go
|
||||
// dependencies
|
||||
package main
|
||||
|
||||
import (
|
||||
"context"
|
||||
"log"
|
||||
"math/rand"
|
||||
"strconv"
|
||||
"time"
|
||||
|
||||
dapr "github.com/dapr/go-sdk/client"
|
||||
)
|
||||
|
||||
// code
|
||||
func main() {
|
||||
const STATE_STORE_NAME = "statestore"
|
||||
rand.Seed(time.Now().UnixMicro())
|
||||
for i := 0; i < 10; i++ {
|
||||
orderId := rand.Intn(1000-1) + 1
|
||||
client, err := dapr.NewClient()
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
defer client.Close()
|
||||
ctx := context.Background()
|
||||
err = client.SaveState(ctx, STATE_STORE_NAME, "order_1", []byte(strconv.Itoa(orderId)), nil)
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
result, err := client.GetState(ctx, STATE_STORE_NAME, "order_1", nil)
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
|
||||
ops := make([]*dapr.StateOperation, 0)
|
||||
data1 := "data1"
|
||||
data2 := "data2"
|
||||
|
||||
op1 := &dapr.StateOperation{
|
||||
Type: dapr.StateOperationTypeUpsert,
|
||||
Item: &dapr.SetStateItem{
|
||||
Key: "key1",
|
||||
Value: []byte(data1),
|
||||
},
|
||||
}
|
||||
op2 := &dapr.StateOperation{
|
||||
Type: dapr.StateOperationTypeDelete,
|
||||
Item: &dapr.SetStateItem{
|
||||
Key: "key2",
|
||||
Value: []byte(data2),
|
||||
},
|
||||
}
|
||||
ops = append(ops, op1, op2)
|
||||
meta := map[string]string{}
|
||||
err = client.ExecuteStateTransaction(ctx, STATE_STORE_NAME, meta, ops)
|
||||
|
||||
log.Println("Result after get:", string(result.Value))
|
||||
time.Sleep(2 * time.Second)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
To launch a Dapr sidecar for the above example application, run a command similar to the following:
|
||||
|
||||
```bash
|
||||
dapr run --app-id orderprocessing --app-port 6001 --dapr-http-port 3601 --dapr-grpc-port 60001 go run OrderProcessingService.go
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```javascript
|
||||
//dependencies
|
||||
import { DaprClient, HttpMethod, CommunicationProtocolEnum } from '@dapr/dapr';
|
||||
|
|
|
|||
|
|
@ -28,8 +28,10 @@ The diagram below is an overview of how the outbox feature works:
|
|||
|
||||
The outbox feature can be used with using any [transactional state store]({{< ref supported-state-stores >}}) supported by Dapr. All [pub/sub brokers]({{< ref supported-pubsub >}}) are supported with the outbox feature.
|
||||
|
||||
[Learn more about the transactional methods you can use.]({{< ref "howto-get-save-state.md#perform-state-transactions" >}})
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
Message brokers that work with the competing consumer pattern (for example, [Apache Kafka]({{< ref setup-apache-kafka>}}) are encouraged to reduce the chances of duplicate events.
|
||||
Message brokers that work with the competing consumer pattern (for example, [Apache Kafka]({{< ref setup-apache-kafka>}})) are encouraged to reduce the chances of duplicate events.
|
||||
{{% /alert %}}
|
||||
|
||||
## Usage
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Workflow"
|
||||
linkTitle: "Workflow"
|
||||
weight: 100
|
||||
weight: 30
|
||||
description: "Orchestrate logic across various microservices"
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -586,7 +586,45 @@ The key takeaways from this example are:
|
|||
- The number of parallel tasks can be static or dynamic
|
||||
- The workflow itself is capable of aggregating the results of parallel executions
|
||||
|
||||
While not shown in the example, it's possible to go further and limit the degree of concurrency using simple, language-specific constructs. Furthermore, the execution of the workflow is durable. If a workflow starts 100 parallel task executions and only 40 complete before the process crashes, the workflow restarts itself automatically and only schedules the remaining 60 tasks.
|
||||
Furthermore, the execution of the workflow is durable. If a workflow starts 100 parallel task executions and only 40 complete before the process crashes, the workflow restarts itself automatically and only schedules the remaining 60 tasks.
|
||||
|
||||
It's possible to go further and limit the degree of concurrency using simple, language-specific constructs. The sample code below illustrates how to restrict the degree of fan-out to just 5 concurrent activity executions:
|
||||
|
||||
{{< tabs ".NET" >}}
|
||||
|
||||
{{% codetab %}}
|
||||
<!-- .NET -->
|
||||
```csharp
|
||||
|
||||
//Revisiting the earlier example...
|
||||
// Get a list of N work items to process in parallel.
|
||||
object[] workBatch = await context.CallActivityAsync<object[]>("GetWorkBatch", null);
|
||||
|
||||
const int MaxParallelism = 5;
|
||||
var results = new List<int>();
|
||||
var inFlightTasks = new HashSet<Task<int>>();
|
||||
foreach(var workItem in workBatch)
|
||||
{
|
||||
if (inFlightTasks.Count >= MaxParallelism)
|
||||
{
|
||||
var finishedTask = await Task.WhenAny(inFlightTasks);
|
||||
results.Add(finishedTask.Result);
|
||||
inFlightTasks.Remove(finishedTask);
|
||||
}
|
||||
|
||||
inFlightTasks.Add(context.CallActivityAsync<int>("ProcessWorkItem", workItem));
|
||||
}
|
||||
results.AddRange(await Task.WhenAll(inFlightTasks));
|
||||
|
||||
var sum = results.Sum(t => t);
|
||||
await context.CallActivityAsync("PostResults", sum);
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
Limiting the degree of concurrency in this way can be useful for limiting contention against shared resources. For example, if the activities need to call into external resources that have their own concurrency limits, like a databases or external APIs, it can be useful to ensure that no more than a specified number of activities call that resource concurrently.
|
||||
|
||||
## Async HTTP APIs
|
||||
|
||||
|
|
|
|||
|
|
@ -6,9 +6,6 @@ description: "Access Dapr capabilities from your Azure Functions runtime applica
|
|||
weight: 3000
|
||||
---
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
The Dapr extension for Azure Functions is currently in preview.
|
||||
{{% /alert %}}
|
||||
|
||||
Dapr integrates with the [Azure Functions runtime](https://learn.microsoft.com/azure/azure-functions/functions-overview) via an extension that lets a function seamlessly interact with Dapr.
|
||||
- **Azure Functions** provides an event-driven programming model.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,21 @@
|
|||
---
|
||||
type: docs
|
||||
title: "How to: Integrate using Testcontainers Dapr Module"
|
||||
linkTitle: "Dapr Testcontainers"
|
||||
weight: 3000
|
||||
description: "Use the Dapr Testcontainer module from your Java application"
|
||||
---
|
||||
|
||||
You can use the Testcontainers Dapr Module provided by Diagrid to set up Dapr locally for your Java applications. Simply add the following dependency to your Maven project:
|
||||
|
||||
```xml
|
||||
<dependency>
|
||||
<groupId>io.diagrid.dapr</groupId>
|
||||
<artifactId>testcontainers-dapr</artifactId>
|
||||
<version>0.10.x</version>
|
||||
</dependency>
|
||||
```
|
||||
|
||||
[If you're using Spring Boot, you can also use the Spring Boot Starter.](https://github.com/diagridio/spring-boot-starter-dapr)
|
||||
|
||||
{{< button text="Use the Testcontainers Dapr Module" link="https://github.com/diagridio/testcontainers-dapr" >}}
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
type: docs
|
||||
title: "How to: Autoscale a Dapr app with KEDA"
|
||||
linkTitle: "How to: Autoscale with KEDA"
|
||||
linkTitle: "KEDA"
|
||||
description: "How to configure your Dapr application to autoscale using KEDA"
|
||||
weight: 3000
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
type: docs
|
||||
title: "How to: Use the gRPC interface in your Dapr application"
|
||||
linkTitle: "How to: gRPC interface"
|
||||
linkTitle: "gRPC interface"
|
||||
weight: 6000
|
||||
description: "Use the Dapr gRPC API in your application"
|
||||
---
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
weight: 5000
|
||||
title: "How to: Use the Dapr CLI in a GitHub Actions workflow"
|
||||
linkTitle: "How to: GitHub Actions"
|
||||
linkTitle: "GitHub Actions"
|
||||
description: "Add the Dapr CLI to your GitHub Actions to deploy and manage Dapr in your environments."
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
type: docs
|
||||
title: "How to: Integrate with Kratix"
|
||||
linkTitle: "Kratix Marketplace"
|
||||
weight: 8000
|
||||
description: "Integrate with Kratix using a Dapr promise"
|
||||
---
|
||||
|
||||
As part of the [Kratix Marketplace](https://docs.kratix.io/marketplace), Dapr can be used to build custom platforms tailored to your needs.
|
||||
|
||||
{{% alert title="Note" color="warning" %}}
|
||||
The Dapr Helm chart generates static public and private key pairs that are published in the repository. This promise should only be used _locally_ for demo purposes. If you wish to use this promise for more than demo purposes, it's recommended to manually update all the secrets in the promise with keys with your own credentials.
|
||||
{{% /alert %}}
|
||||
|
||||
Get started by simply installing the Dapr Promise, which installs Dapr on all matching clusters.
|
||||
|
||||
{{< button text="Install the Dapr Promise" link="https://github.com/syntasso/kratix-marketplace/tree/main/dapr" >}}
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
---
|
||||
type: docs
|
||||
title: "How to: Use the Dapr Kubernetes Operator"
|
||||
linkTitle: "Dapr Kubernetes Operator"
|
||||
weight: 7000
|
||||
description: "Use the Dapr Kubernetes Operator to manage the Dapr control plane"
|
||||
---
|
||||
|
||||
You can use the Dapr Kubernetes Operator to manage the Dapr control plane. Use the operator to automate the tasks required to manage the lifecycle of Dapr control plane in Kubernetes mode.
|
||||
|
||||
{{< button text="Install and use the Dapr Kubernetes Operator" link="https://github.com/dapr/dapr-kubernetes-operator" >}}
|
||||
|
|
@ -42,7 +42,7 @@ dapr run -f <dir_path>
|
|||
<!--kubernetes-->
|
||||
|
||||
```cmd
|
||||
dapr run -f -k <dir_path>
|
||||
dapr run -f <dir_path> -k
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
|
|
@ -67,7 +67,7 @@ dapr run -f ./path/to/<your-preferred-file-name>.yaml
|
|||
<!--kubernetes-->
|
||||
|
||||
```cmd
|
||||
dapr run -f -k ./path/to/<your-preferred-file-name>.yaml
|
||||
dapr run -f ./path/to/<your-preferred-file-name>.yaml -k
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
|
|
@ -77,10 +77,27 @@ dapr run -f -k ./path/to/<your-preferred-file-name>.yaml
|
|||
|
||||
Once the multi-app template is running, you can view the started applications with the following command:
|
||||
|
||||
{{< tabs Self-hosted Kubernetes>}}
|
||||
|
||||
{{% codetab %}}
|
||||
<!--selfhosted-->
|
||||
|
||||
```cmd
|
||||
dapr list
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
<!--kubernetes-->
|
||||
|
||||
```cmd
|
||||
dapr list -k
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
## Stop the multi-app template
|
||||
|
||||
Stop the multi-app run template anytime with either of the following commands:
|
||||
|
|
@ -109,12 +126,12 @@ dapr stop -f ./path/to/<your-preferred-file-name>.yaml
|
|||
```cmd
|
||||
# the template file needs to be called `dapr.yaml` by default if a directory path is given
|
||||
|
||||
dapr stop -f -k
|
||||
dapr stop -f <dir_path> -k
|
||||
```
|
||||
or:
|
||||
|
||||
```cmd
|
||||
dapr stop -f -k ./path/to/<your-preferred-file-name>.yaml
|
||||
dapr stop -f ./path/to/<your-preferred-file-name>.yaml -k
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
|
|
|||
|
|
@ -22,13 +22,13 @@ Hit the ground running with our Dapr quickstarts, complete with code samples aim
|
|||
|
||||
| Quickstarts | Description |
|
||||
| ----------- | ----------- |
|
||||
| [Publish and Subscribe]({{< ref pubsub-quickstart.md >}}) | Asynchronous communication between two services using messaging. |
|
||||
| [Service Invocation]({{< ref serviceinvocation-quickstart.md >}}) | Synchronous communication between two services using HTTP or gRPC. |
|
||||
| [Publish and Subscribe]({{< ref pubsub-quickstart.md >}}) | Asynchronous communication between two services using messaging. |
|
||||
| [Workflow]({{< ref workflow-quickstart.md >}}) | Orchestrate business workflow activities in long running, fault-tolerant, stateful applications. |
|
||||
| [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. |
|
||||
| [Actors]({{< ref actors-quickstart.md >}}) | Run a microservice and a simple console client to demonstrate stateful object patterns in Dapr Actors. |
|
||||
| [Secrets Management]({{< ref secrets-quickstart.md >}}) | Securely fetch secrets. |
|
||||
| [Configuration]({{< ref configuration-quickstart.md >}}) | Get configuration items and subscribe for configuration updates. |
|
||||
| [Resiliency]({{< ref resiliency >}}) | Define and apply fault-tolerance policies to your Dapr API requests. |
|
||||
| [Workflow]({{< ref workflow-quickstart.md >}}) | Orchestrate business workflow activities in long running, fault-tolerant, stateful applications. |
|
||||
| [Cryptography]({{< ref cryptography-quickstart.md >}}) | Encrypt and decrypt data using Dapr's cryptographic APIs. |
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Quickstart: Actors"
|
||||
linkTitle: "Actors"
|
||||
weight: 75
|
||||
weight: 76
|
||||
description: "Get started with Dapr's Actors building block"
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Quickstart: Input & Output Bindings"
|
||||
linkTitle: "Bindings"
|
||||
weight: 74
|
||||
weight: 75
|
||||
description: "Get started with Dapr's Binding building block"
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Quickstart: Configuration"
|
||||
linkTitle: Configuration
|
||||
weight: 77
|
||||
weight: 78
|
||||
description: Get started with Dapr's Configuration building block
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Quickstart: Publish and Subscribe"
|
||||
linkTitle: "Publish and Subscribe"
|
||||
weight: 73
|
||||
weight: 72
|
||||
description: "Get started with Dapr's Publish and Subscribe building block"
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Quickstart: Secrets Management"
|
||||
linkTitle: "Secrets Management"
|
||||
weight: 76
|
||||
weight: 77
|
||||
description: "Get started with Dapr's Secrets Management building block"
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Quickstart: State Management"
|
||||
linkTitle: "State Management"
|
||||
weight: 72
|
||||
weight: 74
|
||||
description: "Get started with Dapr's State Management building block"
|
||||
---
|
||||
|
||||
|
|
@ -169,14 +169,6 @@ Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quic
|
|||
git clone https://github.com/dapr/quickstarts.git
|
||||
```
|
||||
|
||||
Install the dependencies for the `order-processor` app:
|
||||
|
||||
```bash
|
||||
cd ./order-processor
|
||||
npm install
|
||||
cd ..
|
||||
```
|
||||
|
||||
### Step 2: Manipulate service state
|
||||
|
||||
In a terminal window, navigate to the `order-processor` directory.
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Quickstart: Workflow"
|
||||
linkTitle: Workflow
|
||||
weight: 78
|
||||
weight: 73
|
||||
description: Get started with the Dapr Workflow building block
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -75,15 +75,14 @@ spec:
|
|||
type: bindings.azure.servicebusqueues
|
||||
version: v1
|
||||
metadata:
|
||||
-name: connectionString
|
||||
secretKeyRef:
|
||||
- name: connectionString
|
||||
secretKeyRef:
|
||||
name: asbNsConnString
|
||||
key: asbNsConnString
|
||||
-name: queueName
|
||||
value: servicec-inputq
|
||||
- name: queueName
|
||||
value: servicec-inputq
|
||||
auth:
|
||||
secretStore: <SECRET_STORE_NAME>
|
||||
|
||||
```
|
||||
The above "Secret is a string" case yaml tells Dapr to extract a connection string named `asbNsConnstring` from the defined `secretStore` and assign the value to the `connectionString` field in the component since there is no key embedded in the "secret" from the `secretStore` because it is a plain string. This requires the secret `name` and secret `key` to be identical.
|
||||
|
||||
|
|
@ -95,7 +94,7 @@ The following example shows you how to create a Kubernetes secret to hold the co
|
|||
|
||||
1. First, create the Kubernetes secret:
|
||||
```bash
|
||||
kubectl create secret generic eventhubs-secret --from-literal=connectionString=*********
|
||||
kubectl create secret generic eventhubs-secret --from-literal=connectionString=*********
|
||||
```
|
||||
|
||||
2. Next, reference the secret in your binding:
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ Since you are running Dapr in the same host as the component, verify that this f
|
|||
|
||||
### Component discovery and multiplexing
|
||||
|
||||
A pluggable component accessible through a [Unix Domain Socket][UDS] (UDS) can host multiple distinct component APIs . During the components' initial discovery process, Dapr uses reflection to enumerate all the component APIs behind a UDS. The `my-component` pluggable component in the example above can contain both state store (`state`) and a pub/sub (`pubsub`) component APIs.
|
||||
A pluggable component accessible through a [Unix Domain Socket][UDS] (UDS) can host multiple distinct component APIs. During the components' initial discovery process, Dapr uses reflection to enumerate all the component APIs behind a UDS. The `my-component` pluggable component in the example above can contain both state store (`state`) and a pub/sub (`pubsub`) component APIs.
|
||||
|
||||
Typically, a pluggable component implements a single component API for packaging and deployment. However, at the expense of increasing its dependencies and broadening its security attack surface, a pluggable component can have multiple component APIs implemented. This could be done to ease the deployment and monitoring burden. Best practice for isolation, fault tolerance, and security is a single component API implementation for each pluggable component.
|
||||
|
||||
|
|
|
|||
|
|
@ -23,12 +23,12 @@ The table below shows which resources are deployed to which namespaces:
|
|||
|
||||
| Resource | namespace-a | namespace-b |
|
||||
|------------------------ |-------------|-------------|
|
||||
| Redis master | X | |
|
||||
| Redis replicas | X | |
|
||||
| Dapr's PubSub component | X | X |
|
||||
| Node subscriber | X | |
|
||||
| Python subscriber | X | |
|
||||
| React UI publisher | | X |
|
||||
| Redis master | ✅ | ❌ |
|
||||
| Redis replicas | ✅ | ❌ |
|
||||
| Dapr's PubSub component | ✅ | ✅ |
|
||||
| Node subscriber | ✅ | ❌ |
|
||||
| Python subscriber | ✅ | ❌ |
|
||||
| React UI publisher | ❌ | ✅ |
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
All pub/sub components support limiting pub/sub topics to specific applications using [namespace or component scopes]({{< ref pubsub-scopes.md >}}).
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ The CustomResourceDefinition "configurations.dapr.io" is invalid: spec.preserveU
|
|||
1. Run the following command to upgrade the `CustomResourceDefinition` to a compatible version:
|
||||
|
||||
```sh
|
||||
kubectl replace -f https://raw.githubusercontent.com/dapr/dapr/5a15b3e0f093d2d0938b12f144c7047474a290fe/charts/dapr/crds/configuration.yaml
|
||||
kubectl replace -f https://raw.githubusercontent.com/dapr/dapr/release-{{% dapr-latest-version short="true" %}}/charts/dapr/crds/configuration.yaml
|
||||
```
|
||||
|
||||
1. Proceed with the `dapr upgrade --runtime-version {{% dapr-latest-version long="true" %}} -k` command.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ spec:
|
|||
tracing:
|
||||
samplingRate: "1"
|
||||
otel:
|
||||
endpointAddress: "https://..."
|
||||
endpointAddress: "myendpoint.cluster.local:4317"
|
||||
zipkin:
|
||||
endpointAddress: "https://..."
|
||||
|
||||
|
|
@ -32,10 +32,10 @@ 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.
|
||||
| `otel.endpointAddress` | string | Set the Open Telemetry (OTEL) target hostname and optionally port. If this is used, you do not need to specify the 'zipkin' section.
|
||||
| `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. If this is used, you do not need to specify the `otel` section.
|
||||
| `zipkin.endpointAddress` | string | Set the Zipkin server URL. If this is used, you do not need to specify the `otel` section.
|
||||
|
||||
To enable tracing, use a configuration file (in self hosted mode) or a Kubernetes configuration object (in Kubernetes mode). For example, the following configuration object changes the sample rate to 1 (every span is sampled), and sends trace using OTEL protocol to the OTEL server at localhost:4317
|
||||
|
||||
|
|
@ -66,7 +66,7 @@ turns on tracing for the sidecar.
|
|||
|
||||
| Environment Variable | Description |
|
||||
|----------------------|-------------|
|
||||
| `OTEL_EXPORTER_OTLP_ENDPOINT` | Sets the Open Telemetry (OTEL) server address, turns on tracing |
|
||||
| `OTEL_EXPORTER_OTLP_ENDPOINT` | Sets the Open Telemetry (OTEL) server hostname and optionally port, turns on tracing |
|
||||
| `OTEL_EXPORTER_OTLP_INSECURE` | Sets the connection to the endpoint as unencrypted (true/false) |
|
||||
| `OTEL_EXPORTER_OTLP_PROTOCOL` | Transport protocol (`grpc`, `http/protobuf`, `http/json`) |
|
||||
|
||||
|
|
|
|||
|
|
@ -45,6 +45,8 @@ The table below shows the versions of Dapr releases that have been tested togeth
|
|||
|
||||
| Release date | Runtime | CLI | SDKs | Dashboard | Status | Release notes |
|
||||
|--------------------|:--------:|:--------|---------|---------|---------|------------|
|
||||
| May 29th 2024 | 1.13.4</br> | 1.13.0 | Java 1.11.0 </br>Go 1.10.0 </br>PHP 1.2.0 </br>Python 1.13.0 </br>.NET 1.13.0 </br>JS 3.3.0 | 0.14.0 | Supported (current) | [v1.13.4 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.4) |
|
||||
| May 21st 2024 | 1.13.3</br> | 1.13.0 | Java 1.11.0 </br>Go 1.10.0 </br>PHP 1.2.0 </br>Python 1.13.0 </br>.NET 1.13.0 </br>JS 3.3.0 | 0.14.0 | Supported (current) | [v1.13.3 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.3) |
|
||||
| April 3rd 2024 | 1.13.2</br> | 1.13.0 | Java 1.11.0 </br>Go 1.10.0 </br>PHP 1.2.0 </br>Python 1.13.0 </br>.NET 1.13.0 </br>JS 3.3.0 | 0.14.0 | Supported (current) | [v1.13.2 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.2) |
|
||||
| March 26th 2024 | 1.13.1</br> | 1.13.0 | Java 1.11.0 </br>Go 1.10.0 </br>PHP 1.2.0 </br>Python 1.13.0 </br>.NET 1.13.0 </br>JS 3.3.0 | 0.14.0 | Supported (current) | [v1.13.1 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.1) |
|
||||
| March 6th 2024 | 1.13.0</br> | 1.13.0 | Java 1.11.0 </br>Go 1.10.0 </br>PHP 1.2.0 </br>Python 1.13.0 </br>.NET 1.13.0 </br>JS 3.3.0 | 0.14.0 | Supported (current) | [v1.13.0 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.0) |
|
||||
|
|
@ -136,6 +138,8 @@ General guidance on upgrading can be found for [self hosted mode]({{< ref self-h
|
|||
| 1.11.0 | N/A | 1.11.4 |
|
||||
| 1.12.0 | N/A | 1.12.4 |
|
||||
| 1.13.0 | N/A | 1.13.2 |
|
||||
| 1.13.0 | N/A | 1.13.3 |
|
||||
| 1.13.0 | N/A | 1.13.4 |
|
||||
|
||||
## Upgrade on Hosting platforms
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ type: docs
|
|||
title: "Actors API reference"
|
||||
linkTitle: "Actors API"
|
||||
description: "Detailed documentation on the actors API"
|
||||
weight: 500
|
||||
weight: 600
|
||||
---
|
||||
|
||||
Dapr provides native, cross-platform, and cross-language virtual actor capabilities.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ type: docs
|
|||
title: "Bindings API reference"
|
||||
linkTitle: "Bindings API"
|
||||
description: "Detailed documentation on the bindings API"
|
||||
weight: 400
|
||||
weight: 500
|
||||
---
|
||||
|
||||
Dapr provides bi-directional binding capabilities for applications and a consistent approach to interacting with different cloud/on-premise services or systems.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ type: docs
|
|||
title: "Configuration API reference"
|
||||
linkTitle: "Configuration API"
|
||||
description: "Detailed documentation on the configuration API"
|
||||
weight: 700
|
||||
weight: 800
|
||||
---
|
||||
|
||||
## Get Configuration
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ type: docs
|
|||
title: "Distributed Lock API reference"
|
||||
linkTitle: "Distributed Lock API"
|
||||
description: "Detailed documentation on the distributed lock API"
|
||||
weight: 800
|
||||
weight: 900
|
||||
---
|
||||
|
||||
## Lock
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ type: docs
|
|||
title: "Pub/sub API reference"
|
||||
linkTitle: "Pub/Sub API"
|
||||
description: "Detailed documentation on the pub/sub API"
|
||||
weight: 300
|
||||
weight: 200
|
||||
---
|
||||
|
||||
## Publish a message to a given topic
|
||||
|
|
@ -177,7 +177,15 @@ Example:
|
|||
{
|
||||
"pubsubname": "pubsub",
|
||||
"topic": "newOrder",
|
||||
"route": "/orders",
|
||||
"routes": {
|
||||
"rules": [
|
||||
{
|
||||
"match": "event.type == order",
|
||||
"path": "/orders"
|
||||
}
|
||||
]
|
||||
"default" : "/otherorders"
|
||||
},
|
||||
"metadata": {
|
||||
"rawPayload": "true"
|
||||
}
|
||||
|
|
@ -197,7 +205,7 @@ Parameter | Description
|
|||
|
||||
### Provide route(s) for Dapr to deliver topic events
|
||||
|
||||
In order to deliver topic events, a `POST` call will be made to user code with the route specified in the subscription response.
|
||||
In order to deliver topic events, a `POST` call will be made to user code with the route specified in the subscription response. Under `routes`, you can provide [rules that match a certain condition to a specific path when a message topic is received.]({{< ref "howto-route-messages.md" >}}) You can also provide a default route for any rules that do not have a specific match.
|
||||
|
||||
The following example illustrates this point, considering a subscription for topic `newOrder` with route `orders` on port 3000: `POST http://localhost:3000/orders`
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ type: docs
|
|||
title: "Secrets API reference"
|
||||
linkTitle: "Secrets API"
|
||||
description: "Detailed documentation on the secrets API"
|
||||
weight: 600
|
||||
weight: 700
|
||||
---
|
||||
|
||||
## Get Secret
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ type: docs
|
|||
title: "State management API reference"
|
||||
linkTitle: "State management API"
|
||||
description: "Detailed documentation on the state management API"
|
||||
weight: 200
|
||||
weight: 400
|
||||
---
|
||||
|
||||
## Component file
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ type: docs
|
|||
title: "Workflow API reference"
|
||||
linkTitle: "Workflow API"
|
||||
description: "Detailed documentation on the workflow API"
|
||||
weight: 900
|
||||
weight: 300
|
||||
---
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
|
|
|
|||
|
|
@ -71,10 +71,10 @@ dapr init -s
|
|||
|
||||
**Specify a runtime version**
|
||||
|
||||
You can also specify a specific runtime version. Be default, the latest version is used.
|
||||
You can also specify a specific runtime version. By default, the latest version is used.
|
||||
|
||||
```bash
|
||||
dapr init --runtime-version 1.13.0
|
||||
dapr init --runtime-version 1.13.4
|
||||
```
|
||||
|
||||
**Install with image variant**
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Bindings component specs"
|
||||
linkTitle: "Bindings"
|
||||
weight: 3000
|
||||
weight: 4000
|
||||
description: The supported external bindings that interface with Dapr
|
||||
aliases:
|
||||
- "/operations/components/setup-bindings/supported-bindings/"
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Configuration store component specs"
|
||||
linkTitle: "Configuration stores"
|
||||
weight: 5000
|
||||
weight: 6000
|
||||
description: The supported configuration stores that interface with Dapr
|
||||
aliases:
|
||||
- "/operations/components/setup-configuration-store/supported-configuration-stores/"
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Cryptography component specs"
|
||||
linkTitle: "Cryptography"
|
||||
weight: 7000
|
||||
weight: 8000
|
||||
description: The supported cryptography components that interface with Dapr
|
||||
no_list: true
|
||||
---
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Lock component specs"
|
||||
linkTitle: "Locks"
|
||||
weight: 6000
|
||||
weight: 7000
|
||||
description: The supported locks that interface with Dapr
|
||||
no_list: true
|
||||
---
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Middleware component specs"
|
||||
linkTitle: "Middleware"
|
||||
weight: 9000
|
||||
weight: 10000
|
||||
description: List of all the supported middleware components that can be injected in Dapr's processing pipeline.
|
||||
no_list: true
|
||||
aliases:
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Name resolution provider component specs"
|
||||
linkTitle: "Name resolution"
|
||||
weight: 8000
|
||||
weight: 9000
|
||||
description: The supported name resolution providers to enable Dapr service invocation
|
||||
no_list: true
|
||||
---
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Pub/sub brokers component specs"
|
||||
linkTitle: "Pub/sub brokers"
|
||||
weight: 2000
|
||||
weight: 1000
|
||||
description: The supported pub/sub brokers that interface with Dapr
|
||||
aliases:
|
||||
- "/operations/components/setup-pubsub/supported-pubsub/"
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ spec:
|
|||
|--------------------|:--------:|---------|---------|
|
||||
| brokers | Y | A comma-separated list of Kafka brokers. | `"localhost:9092,dapr-kafka.myapp.svc.cluster.local:9093"`
|
||||
| consumerGroup | N | A kafka consumer group to listen on. Each record published to a topic is delivered to one consumer within each consumer group subscribed to the topic. If a value for `consumerGroup` is provided, any value for `consumerID` is ignored - a combination of the consumer group and a random unique identifier will be set for the `consumerID` instead. | `"group1"`
|
||||
| consumerID | N | Consumer ID (consumer tag) organizes one or more consumers into a group. Consumers with the same consumer ID work as one virtual consumer; for example, a message is processed only once by one of the consumers in the group. If the `consumerID` is not provided, the Dapr runtime set it to the Dapr application ID (`appID`) value. If a value for `consumerGroup` is provided, any value for `consumerID` is ignored - a combination of the consumer group and a random unique identifier will be set for the `consumerID` instead. | `"channel1"`
|
||||
| consumerID | N | Consumer ID (consumer tag) organizes one or more consumers into a group. Consumers with the same consumer ID work as one virtual consumer; for example, a message is processed only once by one of the consumers in the group. If the `consumerID` is not provided, the Dapr runtime set it to the Dapr application ID (`appID`) value. If a value for `consumerGroup` is provided, any value for `consumerID` is ignored - a combination of the consumer group and a random unique identifier will be set for the `consumerID` instead. | Can be set to string value (such as `"channel1"` in the example above) or string format value (such as `"{podName}"`, etc.). [See all of template tags you can use in your component metadata.]({{< ref "component-schema.md#templated-metadata-values" >}})
|
||||
| clientID | N | A user-provided string sent with every request to the Kafka brokers for logging, debugging, and auditing purposes. Defaults to `"namespace.appID"` for Kubernetes mode or `"appID"` for Self-Hosted mode. | `"my-namespace.my-dapr-app"`, `"my-dapr-app"`
|
||||
| authRequired | N | *Deprecated* Enable [SASL](https://en.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer) authentication with the Kafka brokers. | `"true"`, `"false"`
|
||||
| authType | Y | Configure or disable authentication. Supported values: `none`, `password`, `mtls`, `oidc` or `awsiam` | `"password"`, `"none"`
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ The above example uses secrets as plain strings. It is recommended to use [a sec
|
|||
| accessKey | Y | ID of the AWS account/role with appropriate permissions to SNS and SQS (see below) | `"AKIAIOSFODNN7EXAMPLE"`
|
||||
| secretKey | Y | Secret for the AWS user/role. If using an `AssumeRole` access, you will also need to provide a `sessionToken` |`"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"`
|
||||
| region | Y | The AWS region where the SNS/SQS assets are located or be created in. See [this page](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/?p=ugi&l=na) for valid regions. Ensure that SNS and SQS are available in that region | `"us-east-1"`
|
||||
| consumerID | N | Consumer ID (consumer tag) organizes one or more consumers into a group. Consumers with the same consumer ID work as one virtual consumer; for example, a message is processed only once by one of the consumers in the group. If the `consumerID` is not provided, the Dapr runtime set it to the Dapr application ID (`appID`) value. See the [pub/sub broker component file]({{< ref setup-pubsub.md >}}) to learn how ConsumerID is automatically generated. | `"channel1"`
|
||||
| consumerID | N | Consumer ID (consumer tag) organizes one or more consumers into a group. Consumers with the same consumer ID work as one virtual consumer; for example, a message is processed only once by one of the consumers in the group. If the `consumerID` is not provided, the Dapr runtime set it to the Dapr application ID (`appID`) value. See the [pub/sub broker component file]({{< ref setup-pubsub.md >}}) to learn how ConsumerID is automatically generated. | Can be set to string value (such as `"channel1"` in the example above) or string format value (such as `"{podName}"`, etc.). [See all of template tags you can use in your component metadata.]({{< ref "component-schema.md#templated-metadata-values" >}})
|
||||
| endpoint | N | AWS endpoint for the component to use. Only used for local development with, for example, [localstack](https://github.com/localstack/localstack). The `endpoint` is unnecessary when running against production AWS | `"http://localhost:4566"`
|
||||
| sessionToken | N | AWS session token to use. A session token is only required if you are using temporary security credentials | `"TOKEN"`
|
||||
| messageReceiveLimit | N | Number of times a message is received, after processing of that message fails, that once reached, results in removing of that message from the queue. If `sqsDeadLettersQueueName` is specified, `messageReceiveLimit` is the number of times a message is received, after processing of that message fails, that once reached, results in moving of the message to the SQS dead-letters queue. Default: `10` | `10`
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ The above example uses secrets as plain strings. It is recommended to use a secr
|
|||
|--------------------|:--------:|---------|---------|
|
||||
| `connectionString` | Y* | Connection string for the Event Hub or the Event Hub namespace.<br>* Mutally exclusive with `eventHubNamespace` field.<br>* Required when not using [Microsoft Entra ID Authentication]({{< ref "authenticating-azure.md" >}}) | `"Endpoint=sb://{EventHubNamespace}.servicebus.windows.net/;SharedAccessKeyName={PolicyName};SharedAccessKey={Key};EntityPath={EventHub}"` or `"Endpoint=sb://{EventHubNamespace}.servicebus.windows.net/;SharedAccessKeyName={PolicyName};SharedAccessKey={Key}"`
|
||||
| `eventHubNamespace` | Y* | The Event Hub Namespace name.<br>* Mutally exclusive with `connectionString` field.<br>* Required when using [Microsoft Entra ID Authentication]({{< ref "authenticating-azure.md" >}}) | `"namespace"`
|
||||
| `consumerID` | N | Consumer ID (consumer tag) organizes one or more consumers into a group. Consumers with the same consumer ID work as one virtual consumer; for example, a message is processed only once by one of the consumers in the group. If the `consumerID` is not provided, the Dapr runtime set it to the Dapr application ID (`appID`) value. | `"channel1"`
|
||||
| `consumerID` | N | Consumer ID (consumer tag) organizes one or more consumers into a group. Consumers with the same consumer ID work as one virtual consumer; for example, a message is processed only once by one of the consumers in the group. If the `consumerID` is not provided, the Dapr runtime set it to the Dapr application ID (`appID`) value. | Can be set to string value (such as `"channel1"` in the example above) or string format value (such as `"{podName}"`, etc.). [See all of template tags you can use in your component metadata.]({{< ref "component-schema.md#templated-metadata-values" >}})
|
||||
| `storageAccountName` | Y | Storage account name to use for the checkpoint store. |`"myeventhubstorage"`
|
||||
| `storageAccountKey` | Y* | Storage account key for the checkpoint store account.<br>* When using Microsoft Entra ID, it's possible to omit this if the service principal has access to the storage account too. | `"112233445566778899"`
|
||||
| `storageConnectionString` | Y* | Connection string for the checkpoint store, alternative to specifying `storageAccountKey` | `"DefaultEndpointsProtocol=https;AccountName=myeventhubstorage;AccountKey=<account-key>"`
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ The above example uses secrets as plain strings. It is recommended to use a secr
|
|||
| Field | Required | Details | Example |
|
||||
|--------------------|:--------:|---------|---------|
|
||||
| `connectionString` | Y | Shared access policy connection string for the Service Bus. Required unless using Microsoft Entra ID authentication. | See example above
|
||||
| `consumerID` | N | Consumer ID (consumer tag) organizes one or more consumers into a group. Consumers with the same consumer ID work as one virtual consumer; for example, a message is processed only once by one of the consumers in the group. If the `consumerID` is not provided, the Dapr runtime set it to the Dapr application ID (`appID`) value. | `"channel1"`
|
||||
| `consumerID` | N | Consumer ID (consumer tag) organizes one or more consumers into a group. Consumers with the same consumer ID work as one virtual consumer; for example, a message is processed only once by one of the consumers in the group. If the `consumerID` is not provided, the Dapr runtime set it to the Dapr application ID (`appID`) value. | Can be set to string value (such as `"channel1"` in the example above) or string format value (such as `"{podName}"`, etc.). [See all of template tags you can use in your component metadata.]({{< ref "component-schema.md#templated-metadata-values" >}})
|
||||
| `namespaceName`| N | Parameter to set the address of the Service Bus namespace, as a fully-qualified domain name. Required if using Microsoft Entra ID authentication. | `"namespace.servicebus.windows.net"` |
|
||||
| `timeoutInSec` | N | Timeout for sending messages and for management operations. Default: `60` |`30`
|
||||
| `handlerTimeoutInSec`| N | Timeout for invoking the app's handler. Default: `60` | `30`
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ spec:
|
|||
- name: connectionString
|
||||
value: "Endpoint=sb://{ServiceBusNamespace}.servicebus.windows.net/;SharedAccessKeyName={PolicyName};SharedAccessKey={Key};EntityPath={ServiceBus}"
|
||||
# - name: consumerID # Optional: defaults to the app's own ID
|
||||
# value: "{identifier}"
|
||||
# value: channel1
|
||||
# - name: timeoutInSec # Optional
|
||||
# value: 60
|
||||
# - name: handlerTimeoutInSec # Optional
|
||||
|
|
@ -75,7 +75,7 @@ The above example uses secrets as plain strings. It is recommended to use a secr
|
|||
|--------------------|:--------:|---------|---------|
|
||||
| `connectionString` | Y | Shared access policy connection string for the Service Bus. Required unless using Microsoft Entra ID authentication. | See example above
|
||||
| `namespaceName`| N | Parameter to set the address of the Service Bus namespace, as a fully-qualified domain name. Required if using Microsoft Entra ID authentication. | `"namespace.servicebus.windows.net"` |
|
||||
| `consumerID` | N | Consumer ID (consumer tag) organizes one or more consumers into a group. Consumers with the same consumer ID work as one virtual consumer; for example, a message is processed only once by one of the consumers in the group. If the `consumerID` is not provided, the Dapr runtime set it to the Dapr application ID (`appID`) value. (`appID`) value. |
|
||||
| `consumerID` | N | Consumer ID (consumer tag) organizes one or more consumers into a group. Consumers with the same consumer ID work as one virtual consumer; for example, a message is processed only once by one of the consumers in the group. If the `consumerID` is not provided, the Dapr runtime set it to the Dapr application ID (`appID`) value. (`appID`) value. | Can be set to string value (such as `"channel1"` in the example above) or string format value (such as `"{podName}"`, etc.). [See all of template tags you can use in your component metadata.]({{< ref "component-schema.md#templated-metadata-values" >}})
|
||||
| `timeoutInSec` | N | Timeout for sending messages and for management operations. Default: `60` |`30`
|
||||
| `handlerTimeoutInSec`| N | Timeout for invoking the app's handler. Default: `60` | `30`
|
||||
| `lockRenewalInSec` | N | Defines the frequency at which buffered message locks will be renewed. Default: `20`. | `20`
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ The above example uses secrets as plain strings. It is recommended to use a secr
|
|||
|--------------------|:--------:|---------|---------|
|
||||
| projectId | Y | GCP project id| `myproject-123`
|
||||
| endpoint | N | GCP endpoint for the component to use. Only used for local development (for example) with [GCP Pub/Sub Emulator](https://cloud.google.com/pubsub/docs/emulator). The `endpoint` is unnecessary when running against the GCP production API. | `"http://localhost:8085"`
|
||||
| `consumerID` | N | The Consumer ID organizes one or more consumers into a group. Consumers with the same consumer ID work as one virtual consumer; for example, a message is processed only once by one of the consumers in the group. If the `consumerID` is not provided, the Dapr runtime set it to the Dapr application ID (`appID`) value. The `consumerID`, along with the `topic` provided as part of the request, are used to build the Pub/Sub subscription ID |
|
||||
| `consumerID` | N | The Consumer ID organizes one or more consumers into a group. Consumers with the same consumer ID work as one virtual consumer; for example, a message is processed only once by one of the consumers in the group. If the `consumerID` is not provided, the Dapr runtime set it to the Dapr application ID (`appID`) value. The `consumerID`, along with the `topic` provided as part of the request, are used to build the Pub/Sub subscription ID | Can be set to string value (such as `"channel1"`) or string format value (such as `"{podName}"`, etc.). [See all of template tags you can use in your component metadata.]({{< ref "component-schema.md#templated-metadata-values" >}})
|
||||
| identityProjectId | N | If the GCP pubsub project is different from the identity project, specify the identity project using this attribute | `"myproject-123"`
|
||||
| privateKeyId | N | If using explicit credentials, this field should contain the `private_key_id` field from the service account json document | `"my-private-key"`
|
||||
| privateKey | N | If using explicit credentials, this field should contain the `private_key` field from the service account json | `-----BEGIN PRIVATE KEY-----MIIBVgIBADANBgkqhkiG9w0B`
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ spec:
|
|||
|-------------------|:--------:|-----------------------------------------------------------------------------------------------------------------------------|----------------------------------------|
|
||||
| address | Y | Address of the KubeMQ server | `"localhost:50000"` |
|
||||
| store | N | type of pubsub, true: pubsub persisted (EventsStore), false: pubsub in-memory (Events) | `true` or `false` (default is `false`) |
|
||||
| consumerID | N | Consumer ID (consumer tag) organizes one or more consumers into a group. Consumers with the same consumer ID work as one virtual consumer; for example, a message is processed only once by one of the consumers in the group. If the `consumerID` is not provided, the Dapr runtime set it to the Dapr application ID (`appID`) value. | `"channel1"`
|
||||
| consumerID | N | Consumer ID (consumer tag) organizes one or more consumers into a group. Consumers with the same consumer ID work as one virtual consumer; for example, a message is processed only once by one of the consumers in the group. If the `consumerID` is not provided, the Dapr runtime set it to the Dapr application ID (`appID`) value. | Can be set to string value (such as `"channel1"` in the example above) or string format value (such as `"{podName}"`, etc.). [See all of template tags you can use in your component metadata.]({{< ref "component-schema.md#templated-metadata-values" >}})
|
||||
| clientID | N | Name for client id connection | `sub-client-12345` |
|
||||
| authToken | N | Auth JWT token for connection Check out [KubeMQ Authentication](https://docs.kubemq.io/learn/access-control/authentication) | `ew...` |
|
||||
| group | N | Subscriber group for load balancing | `g1` |
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ The above example uses secrets as plain strings. It is recommended to use a secr
|
|||
| Field | Required | Details | Example |
|
||||
|--------------------|:--------:|---------|---------|
|
||||
| url | Y | Address of the MQTT broker. Can be `secretKeyRef` to use a secret reference. <br> Use the **`tcp://`** URI scheme for non-TLS communication. <br> Use the **`ssl://`** URI scheme for TLS communication. | `"tcp://[username][:password]@host.domain[:port]"`
|
||||
| consumerID | N | The client ID used to connect to the MQTT broker for the consumer connection. Defaults to the Dapr app ID.<br>Note: if `producerID` is not set, `-consumer` is appended to this value for the consumer connection | `"myMqttClientApp"`
|
||||
| consumerID | N | The client ID used to connect to the MQTT broker for the consumer connection. Defaults to the Dapr app ID.<br>Note: if `producerID` is not set, `-consumer` is appended to this value for the consumer connection | Can be set to string value (such as `"channel1"` in the example above) or string format value (such as `"{podName}"`, etc.). [See all of template tags you can use in your component metadata.]({{< ref "component-schema.md#templated-metadata-values" >}})
|
||||
| producerID | N | The client ID used to connect to the MQTT broker for the producer connection. Defaults to `{consumerID}-producer`. | `"myMqttProducerApp"`
|
||||
| qos | N | Indicates the Quality of Service Level (QoS) of the message ([more info](https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels/)). Defaults to `1`. |`0`, `1`, `2`
|
||||
| retain | N | Defines whether the message is saved by the broker as the last known good value for a specified topic. Defaults to `"false"`. | `"true"`, `"false"`
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ The above example uses secrets as plain strings. It is recommended to use a secr
|
|||
| Field | Required | Details | Example |
|
||||
|--------------------|:--------:|---------|---------|
|
||||
| `url` | Y | Address of the MQTT broker. Can be `secretKeyRef` to use a secret reference. <br> Use the **`tcp://`** URI scheme for non-TLS communication. <br> Use the **`ssl://`** URI scheme for TLS communication. | `"tcp://[username][:password]@host.domain[:port]"`
|
||||
| `consumerID` | N | The client ID used to connect to the MQTT broker. Defaults to the Dapr app ID. | `"myMqttClientApp"`
|
||||
| `consumerID` | N | The client ID used to connect to the MQTT broker. Defaults to the Dapr app ID. | Can be set to string value (such as `"channel1"` in the example above) or string format value (such as `"{podName}"`, etc.). [See all of template tags you can use in your component metadata.]({{< ref "component-schema.md#templated-metadata-values" >}})
|
||||
| `retain` | N | Defines whether the message is saved by the broker as the last known good value for a specified topic. Defaults to `"false"`. | `"true"`, `"false"`
|
||||
| `cleanSession` | N | Sets the `clean_session` flag in the connection message to the MQTT broker if `"true"` ([more info](http://www.steves-internet-guide.com/mqtt-clean-sessions-example/)). Defaults to `"false"`. | `"true"`, `"false"`
|
||||
| `caCert` | Required for using TLS | Certificate Authority (CA) certificate in PEM format for verifying server TLS certificates. | See example below
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ The above example uses secrets as plain strings. It is recommended to use a [sec
|
|||
| host | Y | Address of the Pulsar broker. Default is `"localhost:6650"` | `"localhost:6650"` OR `"http://pulsar-pj54qwwdpz4b-pulsar.ap-sg.public.pulsar.com:8080"`|
|
||||
| enableTLS | N | Enable TLS. Default: `"false"` | `"true"`, `"false"` |
|
||||
| tenant | N | The topic tenant within the instance. Tenants are essential to multi-tenancy in Pulsar, and spread across clusters. Default: `"public"` | `"public"` |
|
||||
| consumerID | N | Used to set the subscription name or consumer ID. | `"channel1"`
|
||||
| consumerID | N | Used to set the subscription name or consumer ID. | Can be set to string value (such as `"channel1"` in the example above) or string format value (such as `"{podName}"`, etc.). [See all of template tags you can use in your component metadata.]({{< ref "component-schema.md#templated-metadata-values" >}})
|
||||
| namespace | N | The administrative unit of the topic, which acts as a grouping mechanism for related topics. Default: `"default"` | `"default"`
|
||||
| persistent | N | Pulsar supports two kinds of topics: [persistent](https://pulsar.apache.org/docs/en/concepts-architecture-overview#persistent-storage) and [non-persistent](https://pulsar.apache.org/docs/en/concepts-messaging/#non-persistent-topics). With persistent topics, all messages are durably persisted on disks (if the broker is not standalone, messages are durably persisted on multiple disks), whereas data for non-persistent topics is not persisted to storage disks.
|
||||
| disableBatching | N | disable batching.When batching enabled default batch delay is set to 10 ms and default batch size is 1000 messages,Setting `disableBatching: true` will make the producer to send messages individually. Default: `"false"` | `"true"`, `"false"`|
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ spec:
|
|||
- name: password
|
||||
value: password
|
||||
- name: consumerID
|
||||
value: myapp
|
||||
value: channel1
|
||||
- name: durable
|
||||
value: false
|
||||
- name: deletedWhenUnused
|
||||
|
|
@ -81,7 +81,7 @@ The above example uses secrets as plain strings. It is recommended to use a secr
|
|||
| hostname | N* | The RabbitMQ hostname. *Mutally exclusive with connectionString field | `localhost` |
|
||||
| username | N* | The RabbitMQ username. *Mutally exclusive with connectionString field | `username` |
|
||||
| password | N* | The RabbitMQ password. *Mutally exclusive with connectionString field | `password` |
|
||||
| consumerID | N | Consumer ID (consumer tag) organizes one or more consumers into a group. Consumers with the same consumer ID work as one virtual consumer; for example, a message is processed only once by one of the consumers in the group. If the `consumerID` is not provided, the Dapr runtime set it to the Dapr application ID (`appID`) value. |
|
||||
| consumerID | N | Consumer ID (consumer tag) organizes one or more consumers into a group. Consumers with the same consumer ID work as one virtual consumer; for example, a message is processed only once by one of the consumers in the group. If the `consumerID` is not provided, the Dapr runtime set it to the Dapr application ID (`appID`) value. | Can be set to string value (such as `"channel1"` in the example above) or string format value (such as `"{podName}"`, etc.). [See all of template tags you can use in your component metadata.]({{< ref "component-schema.md#templated-metadata-values" >}})
|
||||
| durable | N | Whether or not to use [durable](https://www.rabbitmq.com/queues.html#durability) queues. Defaults to `"false"` | `"true"`, `"false"`
|
||||
| deletedWhenUnused | N | Whether or not the queue should be configured to [auto-delete](https://www.rabbitmq.com/queues.html) Defaults to `"true"` | `"true"`, `"false"`
|
||||
| autoAck | N | Whether or not the queue consumer should [auto-ack](https://www.rabbitmq.com/confirms.html) messages. Defaults to `"false"` | `"true"`, `"false"`
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ spec:
|
|||
- name: redisPassword
|
||||
value: "KeFg23!"
|
||||
- name: consumerID
|
||||
value: "myGroup"
|
||||
value: "channel1"
|
||||
- name: enableTLS
|
||||
value: "false"
|
||||
```
|
||||
|
|
@ -41,7 +41,7 @@ The above example uses secrets as plain strings. It is recommended to use a secr
|
|||
| redisHost | Y | Connection-string for the redis host. If `"redisType"` is `"cluster"` it can be multiple hosts separated by commas or just a single host | `localhost:6379`, `redis-master.default.svc.cluster.local:6379`
|
||||
| redisPassword | Y | Password for Redis host. No Default. Can be `secretKeyRef` to use a secret reference | `""`, `"KeFg23!"`
|
||||
| redisUsername | N | Username for Redis host. Defaults to empty. Make sure your redis server version is 6 or above, and have created acl rule correctly. | `""`, `"default"`
|
||||
| consumerID | N | The consumer group ID | `"myGroup"`
|
||||
| consumerID | N | The consumer group ID. | Can be set to string value (such as `"channel1"` in the example above) or string format value (such as `"{podName}"`, etc.). [See all of template tags you can use in your component metadata.]({{< ref "component-schema.md#templated-metadata-values" >}})
|
||||
| enableTLS | N | If the Redis instance supports TLS with public certificates, can be configured to be enabled or disabled. Defaults to `"false"` | `"true"`, `"false"`
|
||||
| redeliverInterval | N | The interval between checking for pending messages to redeliver. Can use either be Go duration string (for example "ms", "s", "m") or milliseconds number. Defaults to `"60s"`. `"0"` disables redelivery. | `"30s"`, `"5000"`
|
||||
| processingTimeout | N | The amount time that a message must be pending before attempting to redeliver it. Can use either be Go duration string ( for example "ms", "s", "m") or milliseconds number. Defaults to `"15s"`. `"0"` disables redelivery. | `"60s"`, `"600000"`
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ spec:
|
|||
- name: producerGroup
|
||||
value: dapr-rocketmq-test-g-p
|
||||
- name: consumerID
|
||||
value: topic
|
||||
value: channel1
|
||||
- name: nameSpace
|
||||
value: dapr-test
|
||||
- name: nameServer
|
||||
|
|
@ -49,7 +49,7 @@ The above example uses secrets as plain strings. It is recommended to use a secr
|
|||
| instanceName | N | Instance name | `time.Now().String()` | `dapr-rocketmq-test` |
|
||||
| consumerGroup | N | Consumer group name. Recommend. If `producerGroup` is `null`，`groupName` is used. | | `dapr-rocketmq-test-g-c ` |
|
||||
| producerGroup (consumerID) | N | Producer group name. Recommended. If `producerGroup` is `null`，`consumerID` is used. If `consumerID` also is null, `groupName` is used. | | `dapr-rocketmq-test-g-p` |
|
||||
| consumerID | N | Consumer ID (consumer tag) organizes one or more consumers into a group. Consumers with the same consumer ID work as one virtual consumer; for example, a message is processed only once by one of the consumers in the group. If the `consumerID` is not provided, the Dapr runtime set it to the Dapr application ID (`appID`) value. | `"channel1"`
|
||||
| consumerID | N | Consumer ID (consumer tag) organizes one or more consumers into a group. Consumers with the same consumer ID work as one virtual consumer; for example, a message is processed only once by one of the consumers in the group. If the `consumerID` is not provided, the Dapr runtime set it to the Dapr application ID (`appID`) value. | Can be set to string value (such as `"channel1"` in the example above) or string format value (such as `"{podName}"`, etc.). [See all of template tags you can use in your component metadata.]({{< ref "component-schema.md#templated-metadata-values" >}})
|
||||
| groupName | N | Consumer/Producer group name. **Depreciated**. | | `dapr-rocketmq-test-g` |
|
||||
| nameSpace | N | RocketMQ namespace | | `dapr-rocketmq` |
|
||||
| nameServerDomain | N | RocketMQ name server domain | | `https://my-app.net:8080/nsaddr` |
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ The above example uses secrets as plain strings. It is recommended to use a secr
|
|||
| url | Y | Address of the AMQP broker. Can be `secretKeyRef` to use a secret reference. <br> Use the **`amqp://`** URI scheme for non-TLS communication. <br> Use the **`amqps://`** URI scheme for TLS communication. | `"amqp://host.domain[:port]"`
|
||||
| username | Y | The username to connect to the broker. Only required if anonymous is not specified or set to `false` .| `default`
|
||||
| password | Y | The password to connect to the broker. Only required if anonymous is not specified or set to `false`. | `default`
|
||||
| consumerID | N | Consumer ID (consumer tag) organizes one or more consumers into a group. Consumers with the same consumer ID work as one virtual consumer; for example, a message is processed only once by one of the consumers in the group. If the `consumerID` is not provided, the Dapr runtime set it to the Dapr application ID (`appID`) value. | `"channel1"`
|
||||
| consumerID | N | Consumer ID (consumer tag) organizes one or more consumers into a group. Consumers with the same consumer ID work as one virtual consumer; for example, a message is processed only once by one of the consumers in the group. If the `consumerID` is not provided, the Dapr runtime set it to the Dapr application ID (`appID`) value. | Can be set to string value (such as `"channel1"` in the example above) or string format value (such as `"{podName}"`, etc.). [See all of template tags you can use in your component metadata.]({{< ref "component-schema.md#templated-metadata-values" >}})
|
||||
| anonymous | N | To connect to the broker without credential validation. Only works if enabled on the broker. A username and password would not be required if this is set to `true`. | `true`
|
||||
| caCert | Required for using TLS | Certificate Authority (CA) certificate in PEM format for verifying server TLS certificates. | `"-----BEGIN CERTIFICATE-----\n<base64-encoded DER>\n-----END CERTIFICATE-----"`
|
||||
| clientCert | Required for using TLS | TLS client certificate in PEM format. Must be used with `clientKey`. | `"-----BEGIN CERTIFICATE-----\n<base64-encoded DER>\n-----END CERTIFICATE-----"`
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Secret store component specs"
|
||||
linkTitle: "Secret stores"
|
||||
weight: 4000
|
||||
weight: 5000
|
||||
description: The supported secret stores that interface with Dapr
|
||||
aliases:
|
||||
- "/operations/components/setup-secret-store/supported-secret-stores/"
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ type: docs
|
|||
title: "State store component specs"
|
||||
linkTitle: "State stores"
|
||||
description: "The supported state stores that interface with Dapr"
|
||||
weight: 1000
|
||||
weight: 4000
|
||||
aliases:
|
||||
- "/operations/components/setup-state-store/supported-state-stores/"
|
||||
no_list: true
|
||||
|
|
|
|||
|
|
@ -28,6 +28,9 @@ spec:
|
|||
value: <REPLACE-WITH-DATABASE>
|
||||
- name: collection
|
||||
value: <REPLACE-WITH-COLLECTION>
|
||||
# Uncomment this if you wish to use Azure Cosmos DB as a state store for actors (optional)
|
||||
#- name: actorStateStore
|
||||
# value: "true"
|
||||
```
|
||||
|
||||
{{% alert title="Warning" color="warning" %}}
|
||||
|
|
@ -49,7 +52,7 @@ If you wish to use Cosmos DB as an actor store, append the following to the yam
|
|||
| masterKey | Y* | The key to authenticate to the Cosmos DB account. Only required when not using Microsoft Entra ID authentication. | `"key"`
|
||||
| database | Y | The name of the database | `"db"`
|
||||
| collection | Y | The name of the collection (container) | `"collection"`
|
||||
| actorStateStore | N | Consider this state store for actors. Defaults to `"false"` | `"true"`, `"false"`
|
||||
| actorStateStore | N | Consider this state store for actors. Defaults to `"false"` | `"true"`, `"false"`
|
||||
|
||||
### Microsoft Entra ID authentication
|
||||
|
||||
|
|
@ -172,7 +175,9 @@ az cosmosdb sql role assignment create \
|
|||
--role-definition-id "$ROLE_ID"
|
||||
```
|
||||
|
||||
## Optimizing Cosmos DB for bulk operation write performance
|
||||
## Optimizations
|
||||
|
||||
### Optimizing Cosmos DB for bulk operation write performance
|
||||
|
||||
If you are building a system that only ever reads data from Cosmos DB via key (`id`), which is the default Dapr behavior when using the state management API or actors, there are ways you can optimize Cosmos DB for improved write speeds. This is done by excluding all paths from indexing. By default, Cosmos DB indexes all fields inside of a document. On systems that are write-heavy and run little-to-no queries on values within a document, this indexing policy slows down the time it takes to write or update a document in Cosmos DB. This is exacerbated in high-volume systems.
|
||||
|
||||
|
|
@ -208,6 +213,18 @@ This optimization comes at the cost of queries against fields inside of document
|
|||
|
||||
{{% /alert %}}
|
||||
|
||||
### Optimizing Cosmos DB for cost savings
|
||||
|
||||
If you intend to use Cosmos DB only as a key-value pair, it may be in your interest to consider converting your state object to JSON and compressing it before persisting it to state, and subsequently decompressing it when reading it out of state. This is because Cosmos DB bills your usage based on the maximum number of RU/s used in a given time period (typically each hour). Furthermore, RU usage is calculated as 1 RU per 1 KB of data you read or write. Compression helps by reducing the size of the data stored in Cosmos DB and subsequently reducing RU usage.
|
||||
|
||||
This savings is particularly significant for Dapr actors. While the Dapr State Management API does a base64 encoding of your object before saving, Dapr actor state is saved as raw, formatted JSON. This means multiple lines with indentations for formatting. Compressing can signficantly reduce the size of actor state objects. For example, if you have an actor state object that is 75KB in size when the actor is hydrated, you will use 75 RU/s to read that object out of state. If you then modify the state object and it grows to 100KB, you will use 100 RU/s to write that object to Cosmos DB, totalling 175 RU/s for the I/O operation. Let's say your actors are concurrently handling 1000 requests per second, you will need at least 175,000 RU/s to meet that load. With effective compression, the size reduction can be in the region of 90%, which means you will only need in the region of 17,500 RU/s to meet the load.
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
|
||||
This particular optimization only makes sense if you are saving large objects to state. The performance and memory tradeoff for performing the compression and decompression on either end need to make sense for your use case. Furthermore, once the data is saved to state, it is not human readable, nor is it queryable. You should only adopt this optimization if you are saving large state objects as key-value pairs.
|
||||
|
||||
{{% /alert %}}
|
||||
|
||||
## Related links
|
||||
|
||||
- [Basic schema for a Dapr component]({{< ref component-schema >}})
|
||||
|
|
|
|||
|
|
@ -36,6 +36,9 @@ spec:
|
|||
value: "expiresAt" # Optional
|
||||
- name: partitionKey
|
||||
value: "ContractID" # Optional
|
||||
# Uncomment this if you wish to use AWS DynamoDB as a state store for actors (optional)
|
||||
#- name: actorStateStore
|
||||
# value: "true"
|
||||
```
|
||||
|
||||
{{% alert title="Warning" color="warning" %}}
|
||||
|
|
@ -58,6 +61,7 @@ In order to use DynamoDB as a Dapr state store, the table must have a primary ke
|
|||
| sessionToken | N |AWS session token to use. A session token is only required if you are using temporary security credentials. | `"TOKEN"`
|
||||
| ttlAttributeName | N |The table attribute name which should be used for TTL. | `"expiresAt"`
|
||||
| partitionKey | N |The table primary key or partition key attribute name. This field is used to replace the default primary key attribute name `"key"`. See the section [Partition Keys]({{< ref "setup-dynamodb.md#partition-keys" >}}). | `"ContractID"`
|
||||
| actorStateStore | N | Consider this state store for actors. Defaults to "false" | `"true"`, `"false"`
|
||||
|
||||
{{% alert title="Important" color="warning" %}}
|
||||
When running the Dapr sidecar (daprd) with your application on EKS (AWS Kubernetes), if you're using a node/pod that has already been attached to an IAM policy defining access to AWS resources, you **must not** provide AWS access-key, secret-key, and tokens in the definition of the component spec you're using.
|
||||
|
|
|
|||
|
|
@ -34,6 +34,9 @@ spec:
|
|||
value: <CERT> # Optional. Required if tlsEnable is `true`.
|
||||
- name: key
|
||||
value: <KEY> # Optional. Required if tlsEnable is `true`.
|
||||
# Uncomment this if you wish to use Etcd as a state store for actors (optional)
|
||||
#- name: actorStateStore
|
||||
# value: "true"
|
||||
```
|
||||
|
||||
{{% alert title="Warning" color="warning" %}}
|
||||
|
|
@ -59,6 +62,7 @@ If you are using `v1`, you should continue to use `v1` until you create a new Et
|
|||
| `ca` | N | CA certificate for connecting to Etcd, PEM-encoded. Can be `secretKeyRef` to use a [secret reference]({{< ref component-secrets.md >}}).| `"-----BEGIN CERTIFICATE-----\nMIIC9TCCA..."`
|
||||
| `cert` | N | TLS certificate for connecting to Etcd, PEM-encoded. Can be `secretKeyRef` to use a [secret reference]({{< ref component-secrets.md >}}).| `"-----BEGIN CERTIFICATE-----\nMIIDUTCC..."`
|
||||
| `key` | N | TLS key for connecting to Etcd, PEM-encoded. Can be `secretKeyRef` to use a [secret reference]({{< ref component-secrets.md >}}).| `"-----BEGIN PRIVATE KEY-----\nMIIEpAIB..."`
|
||||
| `actorStateStore` | N | Consider this state store for actors. Defaults to `"false"` | `"true"`, `"false"`
|
||||
|
||||
## Setup Etcd
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,10 @@ metadata:
|
|||
spec:
|
||||
type: state.in-memory
|
||||
version: v1
|
||||
metadata: []
|
||||
metadata:
|
||||
# Uncomment this if you wish to use In-memory as a state store for actors (optional)
|
||||
#- name: actorStateStore
|
||||
# value: "true"
|
||||
```
|
||||
|
||||
> Note: While in-memory does not require any specific metadata for the component to work, `spec.metadata` is a required field.
|
||||
|
|
|
|||
|
|
@ -41,6 +41,10 @@ spec:
|
|||
value: <REPLACE-WITH-OPERATION-TIMEOUT> # Optional. default: "5s"
|
||||
- name: params
|
||||
value: <REPLACE-WITH-ADDITIONAL-PARAMETERS> # Optional. Example: "?authSource=daprStore&ssl=true"
|
||||
# Uncomment this if you wish to use MongoDB as a state store for actors (optional)
|
||||
#- name: actorStateStore
|
||||
# value: "true"
|
||||
|
||||
```
|
||||
|
||||
{{% alert title="Warning" color="warning" %}}
|
||||
|
|
@ -72,6 +76,7 @@ If you wish to use MongoDB as an actor store, add this metadata option to your C
|
|||
| readConcern | N | The read concern to use | `"majority"`, `"local"`,`"available"`, `"linearizable"`, `"snapshot"`
|
||||
| operationTimeout | N | The timeout for the operation. Defaults to `"5s"` | `"5s"`
|
||||
| params | N<sup>2</sup> | Additional parameters to use | `"?authSource=daprStore&ssl=true"`
|
||||
| actorStateStore | N | Consider this state store for actors. Defaults to `"false"` | `"true"`, `"false"`
|
||||
|
||||
> <sup>[1]</sup> The `server` and `host` fields are mutually exclusive. If neither or both are set, Dapr returns an error.
|
||||
|
||||
|
|
@ -85,7 +90,7 @@ If you wish to use MongoDB as an actor store, add this metadata option to your C
|
|||
You can run a single MongoDB instance locally using Docker:
|
||||
|
||||
```sh
|
||||
docker run --name some-mongo -d mongo
|
||||
docker run --name some-mongo -d -p 27017:27017 mongo
|
||||
```
|
||||
|
||||
You can then interact with the server at `localhost:27017`. If you do not specify a `databaseName` value in your component definition, make sure to create a database named `daprStore`.
|
||||
|
|
|
|||
|
|
@ -35,6 +35,9 @@ spec:
|
|||
value: "<PEM PATH>"
|
||||
- name: pemContents # Required if pemPath not provided. Pem value.
|
||||
value: "<PEM CONTENTS>"
|
||||
# Uncomment this if you wish to use MySQL & MariaDB as a state store for actors (optional)
|
||||
#- name: actorStateStore
|
||||
# value: "true"
|
||||
```
|
||||
|
||||
{{% alert title="Warning" color="warning" %}}
|
||||
|
|
@ -59,6 +62,7 @@ If you wish to use MySQL as an actor store, append the following to the yaml.
|
|||
| `pemPath` | N | Full path to the PEM file to use for [enforced SSL Connection](#enforced-ssl-connection) required if pemContents is not provided. Cannot be used in K8s environment | `"/path/to/file.pem"`, `"C:\path\to\file.pem"` |
|
||||
| `pemContents` | N | Contents of PEM file to use for [enforced SSL Connection](#enforced-ssl-connection) required if pemPath is not provided. Can be used in K8s environment | `"pem value"` |
|
||||
| `cleanupIntervalInSeconds` | N | Interval, in seconds, to clean up rows with an expired TTL. Default: `3600` (that is 1 hour). Setting this to values <=0 disables the periodic cleanup. | `1800`, `-1`
|
||||
| `actorStateStore` | N | Consider this state store for actors. Defaults to `"false"` | `"true"`, `"false"`
|
||||
|
||||
## Setup MySQL
|
||||
|
||||
|
|
|
|||
|
|
@ -28,6 +28,9 @@ spec:
|
|||
value: "<FULL PATH TO DIRECTORY WITH ORACLE WALLET CONTENTS >" # Optional, no default
|
||||
- name: tableName
|
||||
value: "<NAME OF DATABASE TABLE TO STORE STATE IN >" # Optional, defaults to STATE
|
||||
# Uncomment this if you wish to use Oracle Database as a state store for actors (optional)
|
||||
#- name: actorStateStore
|
||||
# value: "true"
|
||||
```
|
||||
{{% alert title="Warning" color="warning" %}}
|
||||
The above example uses secrets as plain strings. It is recommended to use a secret store for the secrets as described [here]({{< ref component-secrets.md >}}).
|
||||
|
|
@ -40,6 +43,7 @@ The above example uses secrets as plain strings. It is recommended to use a secr
|
|||
| connectionString | Y | The connection string for Oracle Database | `"oracle://user/password@host:port/servicename"` for example `"oracle://demo:demo@localhost:1521/xe"` or for Autonomous Database `"oracle://states_schema:State12345pw@adb.us-ashburn-1.oraclecloud.com:1522/k8j2agsqjsw_daprdb_low.adb.oraclecloud.com"`
|
||||
| oracleWalletLocation | N | Location of the contents of an Oracle Wallet file (required to connect to Autonomous Database on OCI)| `"/home/app/state/Wallet_daprDB/"`
|
||||
| tableName | N | Name of the database table in which this instance of the state store records the data default `"STATE"`| `"MY_APP_STATE_STORE"`
|
||||
| actorStateStore | N | Consider this state store for actors. Defaults to `"false"` | `"true"`, `"false"`
|
||||
|
||||
## What Happens at Runtime?
|
||||
When the state store component initializes, it connects to the Oracle Database and checks if a table with the name specified with `tableName` exists. If it does not, it creates this table (with columns Key, Value, Binary_YN, ETag, Creation_Time, Update_Time, Expiration_time).
|
||||
|
|
|
|||
|
|
@ -74,6 +74,9 @@ spec:
|
|||
value: <int> # Optional
|
||||
- name: queryIndexes
|
||||
value: <string> # Optional
|
||||
# Uncomment this if you wish to use Redis as a state store for actors (optional)
|
||||
#- name: actorStateStore
|
||||
# value: "true"
|
||||
```
|
||||
|
||||
{{% alert title="Warning" color="warning" %}}
|
||||
|
|
@ -116,9 +119,9 @@ If you wish to use Redis as an actor store, append the following to the yaml.
|
|||
| minIdleConns | N | Minimum number of idle connections to keep open in order to avoid the performance degradation associated with creating new connections. Defaults to `"0"`. | `"2"`
|
||||
| idleCheckFrequency | N | Frequency of idle checks made by idle connections reaper. Default is `"1m"`. `"-1"` disables idle connections reaper. | `"-1"`
|
||||
| idleTimeout | N | Amount of time after which the client closes idle connections. Should be less than server's timeout. Default is `"5m"`. `"-1"` disables idle timeout check. | `"10m"`
|
||||
| actorStateStore | N | Consider this state store for actors. Defaults to `"false"` | `"true"`, `"false"`
|
||||
| ttlInSeconds | N | Allows specifying a default Time-to-live (TTL) in seconds that will be applied to every state store request unless TTL is explicitly defined via the [request metadata]({{< ref "state-store-ttl.md" >}}). | `600`
|
||||
| queryIndexes | N | Indexing schemas for querying JSON objects | see [Querying JSON objects](#querying-json-objects)
|
||||
| actorStateStore | N | Consider this state store for actors. Defaults to `"false"` | `"true"`, `"false"`
|
||||
|
||||
## Setup Redis
|
||||
|
||||
|
|
|
|||
|
|
@ -52,6 +52,9 @@ spec:
|
|||
value: ""
|
||||
- name: cleanupIntervalInSeconds
|
||||
value: "3600"
|
||||
# Uncomment this if you wish to use Microsoft SQL Server as a state store for actors (optional)
|
||||
#- name: actorStateStore
|
||||
# value: "true"
|
||||
```
|
||||
|
||||
{{% alert title="Warning" color="warning" %}}
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Workflow backend component specs"
|
||||
linkTitle: "Workflow backend"
|
||||
weight: 9000
|
||||
weight: 2000
|
||||
description: The supported workflow backend that orchestrate workflow and save workflow state
|
||||
no_list: true
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
{{- if .Get "short" }}1.13{{ else if .Get "long" }}1.13.0{{ else if .Get "cli" }}1.13.0{{ else }}1.13.0{{ end -}}
|
||||
{{- if .Get "short" }}1.13{{ else if .Get "long" }}1.13.4{{ else if .Get "cli" }}1.13.4{{ else }}1.13.4{{ end -}}
|
||||
|
|
@ -17,8 +17,8 @@ data:
|
|||
zpages:
|
||||
endpoint: :55679
|
||||
exporters:
|
||||
logging:
|
||||
loglevel: debug
|
||||
debug:
|
||||
verbosity: basic
|
||||
azuremonitor:
|
||||
endpoint: "https://dc.services.visualstudio.com/v2/track"
|
||||
instrumentation_key: "<INSTRUMENTATION-KEY>"
|
||||
|
|
@ -33,7 +33,7 @@ data:
|
|||
pipelines:
|
||||
traces:
|
||||
receivers: [zipkin]
|
||||
exporters: [azuremonitor,logging]
|
||||
exporters: [azuremonitor,debug]
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
|
|
@ -71,7 +71,7 @@ spec:
|
|||
spec:
|
||||
containers:
|
||||
- name: otel-collector
|
||||
image: otel/opentelemetry-collector-contrib:0.77.0
|
||||
image: otel/opentelemetry-collector-contrib:0.101.0
|
||||
command:
|
||||
- "/otelcol-contrib"
|
||||
- "--config=/conf/otel-collector-config.yaml"
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 72 KiB After Width: | Height: | Size: 79 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 45 KiB After Width: | Height: | Size: 40 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 102 KiB After Width: | Height: | Size: 136 KiB |
Binary file not shown.
Loading…
Reference in New Issue