mirror of https://github.com/dapr/docs.git
Merge branch 'v1.5' into v1.6
This commit is contained in:
Will Tsai
commit
c1223787dd
|
|
@ -16,6 +16,16 @@ jobs:
|
|||
PYTHON_VER: 3.7
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Check Microsoft URLs do not pin localized versions
|
||||
run: |
|
||||
localized=$(find . -name '*.md' | xargs grep -ol "\.microsoft\.com/[[:alpha:]]\{2\}-[[:alpha:]]\{2\}/") || true
|
||||
if [ -z "$localized" ]; then
|
||||
echo "All Microsoft Docs links ok."
|
||||
else
|
||||
echo "The following files contain links to Microsoft Docs that pin a localized version:"
|
||||
echo $localized
|
||||
exit 1
|
||||
fi
|
||||
- name: Set up Python ${{ env.PYTHON_VER }}
|
||||
uses: actions/setup-python@v2
|
||||
with:
|
||||
|
|
@ -27,3 +37,4 @@ jobs:
|
|||
- name: Check Markdown Files
|
||||
run: |
|
||||
for name in `find . -name "*.md"`; do echo -e "------\n$name" ; mm.py -l $name || exit 1 ;done
|
||||
|
||||
|
|
|
|||
|
|
@ -3,11 +3,11 @@ name: Azure Static Web App Root
|
|||
on:
|
||||
push:
|
||||
branches:
|
||||
- v1.4
|
||||
- v1.5
|
||||
pull_request:
|
||||
types: [opened, synchronize, reopened, closed]
|
||||
branches:
|
||||
- v1.4
|
||||
- v1.5
|
||||
|
||||
jobs:
|
||||
build_and_deploy_job:
|
||||
|
|
|
|||
|
|
@ -14,8 +14,8 @@ The following branches are currently maintained:
|
|||
|
||||
| Branch | Website | Description |
|
||||
| ------------------------------------------------------------ | -------------------------- | ------------------------------------------------------------------------------------------------ |
|
||||
| [v1.4](https://github.com/dapr/docs) (primary) | https://docs.dapr.io | Latest Dapr release documentation. Typo fixes, clarifications, and most documentation goes here. |
|
||||
| [v1.5](https://github.com/dapr/docs/tree/v1.5) (pre-release) | https://v1-5.docs.dapr.io/ | Pre-release documentation. Doc updates that are only applicable to v1.5+ go here. |
|
||||
| [v1.5](https://github.com/dapr/docs) (primary) | https://docs.dapr.io | Latest Dapr release documentation. Typo fixes, clarifications, and most documentation goes here. |
|
||||
| [v1.6](https://github.com/dapr/docs/tree/v1.6) (pre-release) | https://v1-6.docs.dapr.io/ | Pre-release documentation. Doc updates that are only applicable to v1.6+ go here. |
|
||||
|
||||
For more information visit the [Dapr branch structure](https://docs.dapr.io/contributing/contributing-docs/#branch-guidance) document.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,9 @@
|
|||
# Site Configuration
|
||||
<<<<<<< HEAD
|
||||
baseURL = "https://v1-6.docs.dapr.io/"
|
||||
=======
|
||||
baseURL = "https://docs.dapr.io/"
|
||||
>>>>>>> v1.5
|
||||
title = "Dapr Docs"
|
||||
theme = "docsy"
|
||||
disableFastRender = true
|
||||
|
|
|
|||
|
|
@ -2,23 +2,6 @@
|
|||
type: docs
|
||||
no_list: true
|
||||
---
|
||||
|
||||
<div class="card-deck">
|
||||
<div class="card">
|
||||
<div class="card-body">
|
||||
<h5 class="card-title">
|
||||
<img src="/images/daprcon.png" alt="DaprCon logo" width=40>
|
||||
<b> Watch DaprCon sessions on-demand!</b>
|
||||
</h5>
|
||||
<p class="card-text">
|
||||
The first ever DaprCon took place October 19th-20th, 2021. Read this recap and find links to all on-demand content <br></br><i><b>Learn more >></b></i>
|
||||
</p>
|
||||
<a href="https://blog.dapr.io/posts/2021/10/21/thanks-for-a-great-first-daprcon/" class="stretched-link"></a>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<br></br>
|
||||
# <img src="/images/home-title.png" alt="Dapr Docs" width=400>
|
||||
|
||||
Welcome to the Dapr documentation site!
|
||||
|
|
|
|||
|
|
@ -26,4 +26,5 @@ The following are the building blocks provided by Dapr:
|
|||
| [**Resource 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.
|
||||
| [**Observability**]({{<ref "observability-concept.md">}}) | `N/A` | Dapr system components and runtime emit metrics, logs, and traces to debug, operate and monitor Dapr system services, components and user applications.
|
||||
| [**Secrets**]({{<ref "secrets-overview.md">}}) | `/v1.0/secrets` | Dapr offers a secrets building block API and integrates with secret stores such as Azure Key Vault and Kubernetes to store the secrets. Service code can call the secrets API to retrieve secrets out of the Dapr supported secret stores.
|
||||
| [**Secrets**]({{<ref "secrets-overview.md">}}) | `/v1.0/secrets` | Dapr provides a secrets building block API and integrates with secret stores such as Hashicorp valut, local files, Azure Key Vault 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 "app-configuration-overview.md">}}) | `/v1.0/configuration` | Dapr provides a Configuration API that enables you to retrieve and subscribe to application configuration items for Dapr supported configuration stores. This enables an application to set specific configuration information for example at start up or when configuration changes are made in the stores.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,7 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Configuration"
|
||||
linkTitle: "Configuration"
|
||||
weight: 30
|
||||
description: Manage application configuration
|
||||
---
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Configuration overview"
|
||||
linkTitle: "Configuration overview"
|
||||
weight: 1000
|
||||
description: "Use Dapr to get and watch application configuration"
|
||||
---
|
||||
|
||||
Consuming application configuration is a common task when writing applications and frequently configuration stores are used to manage this configuration data. A configuration item is often dynamic in nature and is tightly coupled to the needs of the application that consumes it. For example, common uses for application configuration include names of secrets that need to be retrieved, different identifiers, partition or consumer IDs, names of databased to connect to etc. These configuration items are typically stored as key-value items in a database.
|
||||
|
||||
Dapr provides a [State Management API]({{<ref "state-management-overview.md">}})) that is based on key-value stores. However, application configuration can be changed by either developers or operators at runtime and the developer needs to be notified of these changes in order to take the required action and load the new configuration. Also the configuration data may want to be read only. Dapr's Configuration API allows developers to consume configuration items that are returned as key/value pair and subscribe to changes whenever a configuration item changes.
|
||||
|
||||
*This API is currently in `Alpha state` and only available on gRPC. An HTTP1.1 supported version with this URL `/v1.0/configuration` will be available before the API becomes stable. *
|
||||
|
||||
## References
|
||||
|
||||
- [How-To: Manage application configuration]({{< ref howto-manage-configuration.md >}})
|
||||
|
||||
|
|
@ -0,0 +1,114 @@
|
|||
---
|
||||
type: docs
|
||||
title: "How-To: Manage application configuration"
|
||||
linkTitle: "How-To: Manage application configuration"
|
||||
weight: 2000
|
||||
description: "Learn how to get application configuration and watch for changes"
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
Consuming application configuration is a common task when writing applications and frequently configuration stores are used to manage this configuration data. A configuration item is often dynamic in nature and is tightly coupled to the needs of the application that consumes it. For example, common uses for application configuration include names of secrets that need to be retrieved, different identifiers, partition or consumer IDs, names of databased to connect to etc. These configuration items are typically stored as key-value items in a database.
|
||||
|
||||
Dapr provides a [State Management API]({{<ref "state-management-overview.md">}})) that is based on key-value stores. However, application configuration can be changed by either developers or operators at runtime and the developer needs to be notified of these changes in order to take the required action and load the new configuration. Also the configuration data may want to be read only. Dapr's Configuration API allows developers to consume configuration items that are returned as key/value pair and subscribe to changes whenever a configuration item changes.
|
||||
|
||||
*This API is currently in `Alpha state` and only available on gRPC. An HTTP1.1 supported version with this URL `/v1.0/configuration` will be available before the API becomes stable. *
|
||||
|
||||
This HowTo uses the Redis configuration store component as an exmaple to retrieve a configuration item.
|
||||
|
||||
## Step 1: Save a configuration item
|
||||
|
||||
First, create a configuration item in a supported configuration store. This can be a simple key-value item, with any key of your choice. For this example, we'll use the Redis configuration store component
|
||||
|
||||
### Run Redis with Docker
|
||||
|
||||
```
|
||||
docker run --name my-redis -p 6379:6379 -d redis
|
||||
```
|
||||
|
||||
### Save an item
|
||||
|
||||
Using the [Redis CLI](https://redis.com/blog/get-redis-cli-without-installing-redis-server/), connect to the Redis instance:
|
||||
|
||||
```
|
||||
redis-cli -p 6379
|
||||
```
|
||||
|
||||
Save a configuration item:
|
||||
|
||||
```
|
||||
set myconfig "wookie"
|
||||
```
|
||||
|
||||
### Configure a Dapr configuration store
|
||||
|
||||
Save the following file component file, for example to the default components folder on your machine. You can use this as the Dapr component YAML for Kubernetes using kubectl or when running with the Dapr CLI. Hint: The Redis configuration component has identical metadata to the Redis statestore component, so you can simply copy and change the component type if you already have a Redis statestore YAML file.
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: redisconfiguration
|
||||
spec:
|
||||
type: configuration.redis
|
||||
metadata:
|
||||
- name: redisHost
|
||||
value: localhost:6379
|
||||
```
|
||||
|
||||
### Get configuration items using gRPC API
|
||||
|
||||
Using your [favorite language](https://grpc.io/docs/languages/), create a Dapr gRPC client from the [Dapr proto](https://github.com/dapr/dapr/blob/master/dapr/proto/runtime/v1/dapr.proto). The following examples show Java, C#, Python and Javascript clients.
|
||||
|
||||
{{< tabs Java Dotnet Python Javascript >}}
|
||||
|
||||
{{% codetab %}}
|
||||
```java
|
||||
|
||||
Dapr.ServiceBlockingStub stub = Dapr.newBlockingStub(channel);
|
||||
stub.GetConfigurationAlpha1(new GetConfigurationRequest{ StoreName = "redisconfig", Keys = new String[]{"myconfig"} });
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
```csharp
|
||||
|
||||
var call = client.GetConfigurationAlpha1(new GetConfigurationRequest { StoreName = "redisconfig", Keys = new String[]{"myconfig"} });
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
```python
|
||||
response = stub.GetConfigurationAlpha1(request={ StoreName: 'redisconfig', Keys = ['myconfig'] })
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
```javascript
|
||||
client.GetConfigurationAlpha1({ StoreName: 'redisconfig', Keys = ['myconfig'] })
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
### Watch configuration items
|
||||
|
||||
Using your [favorite language](https://grpc.io/docs/languages/), create a Dapr gRPC client from the [Dapr proto](https://github.com/dapr/dapr/blob/master/dapr/proto/runtime/v1/dapr.proto).
|
||||
Use the proto method `SubscribeConfigurationAlpha1` on your client stub to start subscribing to events. The method accepts the following request object:
|
||||
|
||||
```proto
|
||||
message SubscribeConfigurationRequest {
|
||||
// The name of configuration store.
|
||||
string store_name = 1;
|
||||
|
||||
// Optional. The key of the configuration item to fetch.
|
||||
// If set, only query for the specified configuration items.
|
||||
// Empty list means fetch all.
|
||||
repeated string keys = 2;
|
||||
|
||||
// The metadata which will be sent to configuration store components.
|
||||
map<string,string> metadata = 3;
|
||||
}
|
||||
```
|
||||
|
||||
Using this method, you can subscribe to changes in specific keys for a given configuration store. gRPC streaming varies widely based on language - see the [gRPC examples here](https://grpc.io/docs/languages/) for usage.
|
||||
|
|
@ -0,0 +1,422 @@
|
|||
---
|
||||
type: docs
|
||||
title: "How-To: Query state"
|
||||
linkTitle: "How-To: Query state"
|
||||
weight: 250
|
||||
description: "API for querying state stores"
|
||||
---
|
||||
|
||||
{{% alert title="alpha" color="warning" %}}
|
||||
The state query API is in **alpha** stage.
|
||||
{{% /alert %}}
|
||||
|
||||
## Introduction
|
||||
|
||||
The state query API provides a way of querying the key/value data stored in state store components. This query API is not a replacement for a complete query language, and is focused on retrieving, filtering and sorting key/value data that you have saved through the state management APIs.
|
||||
|
||||
Even though the state store is a key/value store, the `value` might be a JSON document with its own hierarchy, keys, and values.
|
||||
The query API allows you to use those keys and values to retrive corresponding documents.
|
||||
|
||||
This query API does not support querying of actor state stored in a state store. For that you need to use the query API for the specific database.
|
||||
See [querying actor state]({{< ref "state-management-overview.md#querying-actor-state" >}}).
|
||||
|
||||
You can find additional information in the [related links]({{< ref "#related-links" >}}) section.
|
||||
|
||||
## Querying the state
|
||||
|
||||
You submit query requests via HTTP POST/PUT or gRPC.
|
||||
The body of the request is the JSON map with 3 entries: `filter`, `sort`, and `pagination`.
|
||||
|
||||
The `filter` is an optional section. It specifies the query conditions in the form of a tree of key/value operations, where the key is the operator and the value is the operands.
|
||||
|
||||
The following operations are supported:
|
||||
|
||||
| Operator | Operands | Description |
|
||||
|----------|-------------|--------------|
|
||||
| `EQ` | key:value | key == value |
|
||||
| `IN` | key:[]value | key == value[0] OR key == value[1] OR ... OR key == value[n] |
|
||||
| `AND` | []operation | operation[0] AND operation[1] AND ... AND operation[n] |
|
||||
| `OR` | []operation | operation[0] OR operation[1] OR ... OR operation[n] |
|
||||
|
||||
If `filter` section is omitted, the query returns all entries.
|
||||
|
||||
The `sort` is an optional section and is an ordered array of `key:order` pairs, where `key` is a key in the state store, and the `order` is an optional string indicating sorting order: `"ASC"` for ascending and `"DESC"` for descending. If omitted, ascending order is the default.
|
||||
|
||||
The `pagination` is an optional section containing `limit` and `token` parameters. `limit` sets the page size. `token` is an iteration token returned by the component, and is used in subsequent queries.
|
||||
|
||||
For some background understanding, this query request is translated into the native query language and executed by the state store component.
|
||||
|
||||
## Example data and query
|
||||
|
||||
Let's look at some real examples, starting with simple and progressing towards more complex ones.
|
||||
|
||||
As a dataset, let's consider a [collection of with employee records](../query-api-examples/dataset.json) containing employee ID, organization, state, and city.
|
||||
Notice that this dataset is an array of key/value pairs where `key` is the unique ID, and the `value` is the JSON object with employee record.
|
||||
To better illustrate functionality, let's have organization name (org) and employee ID (id) as a nested JSON person object.
|
||||
|
||||
First, you need to create an instance of MongoDB, which is your state store.
|
||||
```bash
|
||||
docker run -d --rm -p 27017:27017 --name mongodb mongo:5
|
||||
```
|
||||
|
||||
Next is to start a Dapr application. Refer to this [component configuration file](../query-api-examples/components/mongodb.yml), which instructs Dapr to use MongoDB as its state store.
|
||||
```bash
|
||||
dapr run --app-id demo --dapr-http-port 3500 --components-path query-api-examples/components
|
||||
```
|
||||
|
||||
Now populate the state store with the employee dataset, so you can then query it later.
|
||||
```bash
|
||||
curl -X POST -H "Content-Type: application/json" -d @query-api-examples/dataset.json http://localhost:3500/v1.0/state/statestore
|
||||
```
|
||||
|
||||
Once populated, you can examine the data in the state store. The image below a section of the MongoDB UI displaying employee records.
|
||||
<table><tr><td>
|
||||
<img src="/images/state-management-query-mongodb-dataset.png" width=500 alt="Sample dataset" class="center">
|
||||
</td></tr></table>
|
||||
|
||||
Each entry has the `_id` member as a concatenated object key, and the `value` member containing the JSON record.
|
||||
|
||||
The query API allows you to select records from this JSON structure.
|
||||
|
||||
Now you can run the queries.
|
||||
|
||||
### Example 1
|
||||
|
||||
First, let's find all employees in the state of California and sort them by their employee ID in descending order.
|
||||
|
||||
This is the [query](../query-api-examples/query1.json):
|
||||
```json
|
||||
{
|
||||
"query": {
|
||||
"filter": {
|
||||
"EQ": { "value.state": "CA" }
|
||||
},
|
||||
"sort": [
|
||||
{
|
||||
"key": "value.person.id",
|
||||
"order": "DESC"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
An equivalent of this query in SQL is:
|
||||
```sql
|
||||
SELECT * FROM c WHERE
|
||||
value.state = "CA"
|
||||
ORDER BY
|
||||
value.person.id DESC
|
||||
```
|
||||
|
||||
Execute the query with the following command:
|
||||
{{< tabs "HTTP API (Bash)" "HTTP API (PowerShell)" >}}
|
||||
{{% codetab %}}
|
||||
```bash
|
||||
curl -s -X POST -H "Content-Type: application/json" -d @query-api-examples/query1.json http://localhost:3500/v1.0-alpha1/state/statestore/query | jq .
|
||||
```
|
||||
{{% /codetab %}}
|
||||
{{% codetab %}}
|
||||
```powershell
|
||||
Invoke-RestMethod -Method Post -ContentType 'application/json' -InFile query-api-examples/query1.json -Uri 'http://localhost:3500/v1.0-alpha1/state/statestore/query'
|
||||
```
|
||||
{{% /codetab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
The query result is an array of matching key/value pairs in the requested order:
|
||||
```json
|
||||
{
|
||||
"results": [
|
||||
{
|
||||
"key": "3",
|
||||
"data": {
|
||||
"person": {
|
||||
"org": "Finance",
|
||||
"id": 1071
|
||||
},
|
||||
"city": "Sacramento",
|
||||
"state": "CA"
|
||||
},
|
||||
"etag": "44723d41-deb1-4c23-940e-3e6896c3b6f7"
|
||||
},
|
||||
{
|
||||
"key": "7",
|
||||
"data": {
|
||||
"city": "San Francisco",
|
||||
"state": "CA",
|
||||
"person": {
|
||||
"id": 1015,
|
||||
"org": "Dev Ops"
|
||||
}
|
||||
},
|
||||
"etag": "0e69e69f-3dbc-423a-9db8-26767fcd2220"
|
||||
},
|
||||
{
|
||||
"key": "5",
|
||||
"data": {
|
||||
"state": "CA",
|
||||
"person": {
|
||||
"org": "Hardware",
|
||||
"id": 1007
|
||||
},
|
||||
"city": "Los Angeles"
|
||||
},
|
||||
"etag": "f87478fa-e5c5-4be0-afa5-f9f9d75713d8"
|
||||
},
|
||||
{
|
||||
"key": "9",
|
||||
"data": {
|
||||
"person": {
|
||||
"org": "Finance",
|
||||
"id": 1002
|
||||
},
|
||||
"city": "San Diego",
|
||||
"state": "CA"
|
||||
},
|
||||
"etag": "f5cf05cd-fb43-4154-a2ec-445c66d5f2f8"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Example 2
|
||||
|
||||
Let's now find all employees from the "Dev Ops" and "Hardware" organizations.
|
||||
|
||||
This is the [query](../query-api-examples/query2.json):
|
||||
```json
|
||||
{
|
||||
"query": {
|
||||
"filter": {
|
||||
"IN": { "value.person.org": [ "Dev Ops", "Hardware" ] }
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
An equivalent of this query in SQL is:
|
||||
```sql
|
||||
SELECT * FROM c WHERE
|
||||
value.person.org IN ("Dev Ops", "Hardware")
|
||||
```
|
||||
|
||||
Execute the query with the following command:
|
||||
{{< tabs "HTTP API (Bash)" "HTTP API (PowerShell)" >}}
|
||||
{{% codetab %}}
|
||||
```bash
|
||||
curl -s -X POST -H "Content-Type: application/json" -d @query-api-examples/query2.json http://localhost:3500/v1.0-alpha1/state/statestore/query | jq .
|
||||
```
|
||||
{{% /codetab %}}
|
||||
{{% codetab %}}
|
||||
```powershell
|
||||
Invoke-RestMethod -Method Post -ContentType 'application/json' -InFile query-api-examples/query2.json -Uri 'http://localhost:3500/v1.0-alpha1/state/statestore/query'
|
||||
```
|
||||
{{% /codetab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
Similar to the previous example, the result is an array of matching key/value pairs.
|
||||
|
||||
### Example 3
|
||||
|
||||
In this example let's find all employees from the "Dev Ops" department
|
||||
and those employees from the "Finance" departing residing in the states of Washington and California.
|
||||
|
||||
In addition, let's sort the results first by state in descending alphabetical order, and then by employee ID in ascending order.
|
||||
Also, let's process up to 3 records at a time.
|
||||
|
||||
This is the [query](../query-api-examples/query3.json):
|
||||
|
||||
```json
|
||||
{
|
||||
"query": {
|
||||
"filter": {
|
||||
"OR": [
|
||||
{
|
||||
"EQ": { "value.person.org": "Dev Ops" }
|
||||
},
|
||||
{
|
||||
"AND": [
|
||||
{
|
||||
"EQ": { "value.person.org": "Finance" }
|
||||
},
|
||||
{
|
||||
"IN": { "value.state": [ "CA", "WA" ] }
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
"sort": [
|
||||
{
|
||||
"key": "value.state",
|
||||
"order": "DESC"
|
||||
},
|
||||
{
|
||||
"key": "value.person.id"
|
||||
}
|
||||
],
|
||||
"pagination": {
|
||||
"limit": 3
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
An equivalent of this query in SQL is:
|
||||
```sql
|
||||
SELECT * FROM c WHERE
|
||||
value.person.org = "Dev Ops" OR
|
||||
(value.person.org = "Finance" AND value.state IN ("CA", "WA"))
|
||||
ORDER BY
|
||||
value.state DESC,
|
||||
value.person.id ASC
|
||||
LIMIT 3
|
||||
```
|
||||
|
||||
Execute the query with the following command:
|
||||
{{< tabs "HTTP API (Bash)" "HTTP API (PowerShell)" >}}
|
||||
{{% codetab %}}
|
||||
```bash
|
||||
curl -s -X POST -H "Content-Type: application/json" -d @query-api-examples/query3.json http://localhost:3500/v1.0-alpha1/state/statestore/query | jq .
|
||||
```
|
||||
{{% /codetab %}}
|
||||
{{% codetab %}}
|
||||
```powershell
|
||||
Invoke-RestMethod -Method Post -ContentType 'application/json' -InFile query-api-examples/query3.json -Uri 'http://localhost:3500/v1.0-alpha1/state/statestore/query'
|
||||
```
|
||||
{{% /codetab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
Upon successful execution, the state store returns a JSON object with a list of matching records and the pagination token:
|
||||
```json
|
||||
{
|
||||
"results": [
|
||||
{
|
||||
"key": "1",
|
||||
"data": {
|
||||
"person": {
|
||||
"org": "Dev Ops",
|
||||
"id": 1036
|
||||
},
|
||||
"city": "Seattle",
|
||||
"state": "WA"
|
||||
},
|
||||
"etag": "6f54ad94-dfb9-46f0-a371-e42d550adb7d"
|
||||
},
|
||||
{
|
||||
"key": "4",
|
||||
"data": {
|
||||
"person": {
|
||||
"org": "Dev Ops",
|
||||
"id": 1042
|
||||
},
|
||||
"city": "Spokane",
|
||||
"state": "WA"
|
||||
},
|
||||
"etag": "7415707b-82ce-44d0-bf15-6dc6305af3b1"
|
||||
},
|
||||
{
|
||||
"key": "10",
|
||||
"data": {
|
||||
"person": {
|
||||
"org": "Dev Ops",
|
||||
"id": 1054
|
||||
},
|
||||
"city": "New York",
|
||||
"state": "NY"
|
||||
},
|
||||
"etag": "26bbba88-9461-48d1-8a35-db07c374e5aa"
|
||||
}
|
||||
],
|
||||
"token": "3"
|
||||
}
|
||||
```
|
||||
|
||||
The pagination token is used "as is" in the [subsequent query](../query-api-examples/query3-token.json) to get the next batch of records:
|
||||
|
||||
```json
|
||||
{
|
||||
"query": {
|
||||
"filter": {
|
||||
"OR": [
|
||||
{
|
||||
"EQ": { "value.person.org": "Dev Ops" }
|
||||
},
|
||||
{
|
||||
"AND": [
|
||||
{
|
||||
"EQ": { "value.person.org": "Finance" }
|
||||
},
|
||||
{
|
||||
"IN": { "value.state": [ "CA", "WA" ] }
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
"sort": [
|
||||
{
|
||||
"key": "value.state",
|
||||
"order": "DESC"
|
||||
},
|
||||
{
|
||||
"key": "value.person.id"
|
||||
}
|
||||
],
|
||||
"pagination": {
|
||||
"limit": 3,
|
||||
"token": "3"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
And the result of this query is:
|
||||
```json
|
||||
{
|
||||
"results": [
|
||||
{
|
||||
"key": "9",
|
||||
"data": {
|
||||
"person": {
|
||||
"org": "Finance",
|
||||
"id": 1002
|
||||
},
|
||||
"city": "San Diego",
|
||||
"state": "CA"
|
||||
},
|
||||
"etag": "f5cf05cd-fb43-4154-a2ec-445c66d5f2f8"
|
||||
},
|
||||
{
|
||||
"key": "7",
|
||||
"data": {
|
||||
"city": "San Francisco",
|
||||
"state": "CA",
|
||||
"person": {
|
||||
"id": 1015,
|
||||
"org": "Dev Ops"
|
||||
}
|
||||
},
|
||||
"etag": "0e69e69f-3dbc-423a-9db8-26767fcd2220"
|
||||
},
|
||||
{
|
||||
"key": "3",
|
||||
"data": {
|
||||
"person": {
|
||||
"org": "Finance",
|
||||
"id": 1071
|
||||
},
|
||||
"city": "Sacramento",
|
||||
"state": "CA"
|
||||
},
|
||||
"etag": "44723d41-deb1-4c23-940e-3e6896c3b6f7"
|
||||
}
|
||||
],
|
||||
"token": "6"
|
||||
}
|
||||
```
|
||||
That way you can update the pagination token in the query and iterate through the results until no more records are returned.
|
||||
|
||||
## Related links
|
||||
- [Query API reference ]({{< ref "state_api.md#state-query" >}})
|
||||
- [State store components with those that implement query support]({{< ref supported-state-stores.md >}})
|
||||
- [State store query API implementation guide](https://github.com/dapr/components-contrib/blob/master/state/Readme.md#implementing-state-query-api)
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: statestore
|
||||
spec:
|
||||
type: state.mongodb
|
||||
version: v1
|
||||
metadata:
|
||||
- name: host
|
||||
value: localhost:27017
|
||||
|
|
@ -0,0 +1,112 @@
|
|||
[
|
||||
{
|
||||
"key": "1",
|
||||
"value": {
|
||||
"person": {
|
||||
"org": "Dev Ops",
|
||||
"id": 1036
|
||||
},
|
||||
"city": "Seattle",
|
||||
"state": "WA"
|
||||
}
|
||||
},
|
||||
{
|
||||
"key": "2",
|
||||
"value": {
|
||||
"person": {
|
||||
"org": "Hardware",
|
||||
"id": 1028
|
||||
},
|
||||
"city": "Portland",
|
||||
"state": "OR"
|
||||
}
|
||||
},
|
||||
{
|
||||
"key": "3",
|
||||
"value": {
|
||||
"person": {
|
||||
"org": "Finance",
|
||||
"id": 1071
|
||||
},
|
||||
"city": "Sacramento",
|
||||
"state": "CA"
|
||||
}
|
||||
},
|
||||
{
|
||||
"key": "4",
|
||||
"value": {
|
||||
"person": {
|
||||
"org": "Dev Ops",
|
||||
"id": 1042
|
||||
},
|
||||
"city": "Spokane",
|
||||
"state": "WA"
|
||||
}
|
||||
},
|
||||
{
|
||||
"key": "5",
|
||||
"value": {
|
||||
"person": {
|
||||
"org": "Hardware",
|
||||
"id": 1007
|
||||
},
|
||||
"city": "Los Angeles",
|
||||
"state": "CA"
|
||||
}
|
||||
},
|
||||
{
|
||||
"key": "6",
|
||||
"value": {
|
||||
"person": {
|
||||
"org": "Finance",
|
||||
"id": 1094
|
||||
},
|
||||
"city": "Eugene",
|
||||
"state": "OR"
|
||||
}
|
||||
},
|
||||
{
|
||||
"key": "7",
|
||||
"value": {
|
||||
"person": {
|
||||
"org": "Dev Ops",
|
||||
"id": 1015
|
||||
},
|
||||
"city": "San Francisco",
|
||||
"state": "CA"
|
||||
}
|
||||
},
|
||||
{
|
||||
"key": "8",
|
||||
"value": {
|
||||
"person": {
|
||||
"org": "Hardware",
|
||||
"id": 1077
|
||||
},
|
||||
"city": "Redmond",
|
||||
"state": "WA"
|
||||
}
|
||||
},
|
||||
{
|
||||
"key": "9",
|
||||
"value": {
|
||||
"person": {
|
||||
"org": "Finance",
|
||||
"id": 1002
|
||||
},
|
||||
"city": "San Diego",
|
||||
"state": "CA"
|
||||
}
|
||||
},
|
||||
{
|
||||
"key": "10",
|
||||
"value": {
|
||||
"person": {
|
||||
"org": "Dev Ops",
|
||||
"id": 1054
|
||||
},
|
||||
"city": "New York",
|
||||
"state": "NY"
|
||||
}
|
||||
}
|
||||
]
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
{
|
||||
"query": {
|
||||
"filter": {
|
||||
"EQ": { "value.state": "CA" }
|
||||
},
|
||||
"sort": [
|
||||
{
|
||||
"key": "value.person.id",
|
||||
"order": "DESC"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
{
|
||||
"query": {
|
||||
"filter": {
|
||||
"IN": { "value.person.org": [ "Dev Ops", "Hardware" ] }
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -0,0 +1,34 @@
|
|||
{
|
||||
"query": {
|
||||
"filter": {
|
||||
"OR": [
|
||||
{
|
||||
"EQ": { "value.person.org": "Dev Ops" }
|
||||
},
|
||||
{
|
||||
"AND": [
|
||||
{
|
||||
"EQ": { "value.person.org": "Finance" }
|
||||
},
|
||||
{
|
||||
"IN": { "value.state": [ "CA", "WA" ] }
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
"sort": [
|
||||
{
|
||||
"key": "value.state",
|
||||
"order": "DESC"
|
||||
},
|
||||
{
|
||||
"key": "value.person.id"
|
||||
}
|
||||
],
|
||||
"pagination": {
|
||||
"limit": 3,
|
||||
"token": "3"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
{
|
||||
"query": {
|
||||
"filter": {
|
||||
"OR": [
|
||||
{
|
||||
"EQ": { "value.person.org": "Dev Ops" }
|
||||
},
|
||||
{
|
||||
"AND": [
|
||||
{
|
||||
"EQ": { "value.person.org": "Finance" }
|
||||
},
|
||||
{
|
||||
"IN": { "value.state": [ "CA", "WA" ] }
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
"sort": [
|
||||
{
|
||||
"key": "value.state",
|
||||
"order": "DESC"
|
||||
},
|
||||
{
|
||||
"key": "value.person.id"
|
||||
}
|
||||
],
|
||||
"pagination": {
|
||||
"limit": 3
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -8,39 +8,37 @@ description: "Overview of the state management building block"
|
|||
|
||||
## Introduction
|
||||
|
||||
Using state management, your application can store data as key/value pairs in the [supported state stores]({{< ref supported-state-stores.md >}}).
|
||||
Using state management, your application can store and query data as key/value pairs in the [supported state stores]({{< ref supported-state-stores.md >}}). This enables you to build stateful, long running applications that can save and retrieve their state, for example a shopping cart or a game's session state.
|
||||
|
||||
When using state management your application can leverage features that would otherwise be complicated and error-prone to build yourself such as:
|
||||
When using state management, your application can leverage features that would otherwise be complicated and error-prone to build yourself such as:
|
||||
|
||||
- Distributed concurrency and data consistency
|
||||
- Bulk [CRUD](https://en.wikipedia.org/wiki/Create,_read,_update_and_delete) operations
|
||||
- Setting the choices on concurrency control and data consistency.
|
||||
- Performing bulk update operations [CRUD](https://en.wikipedia.org/wiki/Create,_read,_update_and_delete) including multiple transactional operations.
|
||||
- Querying and filtering the key/value data.
|
||||
|
||||
Your application can use Dapr's state management API to save and read key/value pairs using a state store component, as shown in the diagram below. For example, by using HTTP POST you can save key/value pairs and by using HTTP GET you can read a key and have its value returned.
|
||||
Your application can use Dapr's state management API to save, read and query key/value pairs using a state store component, as shown in the diagram below. For example, by using HTTP POST you can save or query key/value pairs and by using HTTP GET you can read a specific key and have its value returned.
|
||||
|
||||
<img src="/images/state-management-overview.png" width=900>
|
||||
|
||||
|
||||
## Features
|
||||
These are the features available as part of the state management API:
|
||||
|
||||
### Pluggable state stores
|
||||
|
||||
Dapr data stores are modeled as components, which can be swapped out without any changes to your service code. See [supported state stores]({{< ref supported-state-stores >}}) to see the list.
|
||||
|
||||
### Configurable state store behavior
|
||||
|
||||
Dapr allows developers to attach additional metadata to a state operation request that describes how the request is expected to be handled. You can attach:
|
||||
### Configurable state store behaviors
|
||||
Dapr allows you to include additional metadata in a state operation request that describes how the request is expected to be handled. You can attach:
|
||||
- Concurrency requirements
|
||||
- Consistency requirements
|
||||
|
||||
By default, your application should assume a data store is **eventually consistent** and uses a **last-write-wins** concurrency pattern.
|
||||
|
||||
[Not all stores are created equal]({{< ref supported-state-stores.md >}}). To ensure portability of your application you can query the capabilities of the store and make your code adaptive to different store capabilities.
|
||||
[Not all stores are created equal]({{< ref supported-state-stores.md >}}). To ensure portability of your application you can query the metadata capabilities of the store and make your code adaptive to different store capabilities.
|
||||
|
||||
### Concurrency
|
||||
Dapr supports Optimistic Concurrency Control (OCC) using ETags. When a state value is requested, Dapr always attaches an ETag property to the returned state. When the user code tries to update or delete a state, it’s expected to attach the ETag either through the request body for updates or the `If-Match` header for deletes. The write operation can succeed only when the provided ETag matches with the ETag in the state store.
|
||||
|
||||
Dapr supports optimistic concurrency control (OCC) using ETags. When a state is requested, Dapr always attaches an ETag property to the returned state. When the user code tries to update or delete a state, it’s expected to attach the ETag either through the request body for updates or the `If-Match` header for deletes. The write operation can succeed only when the provided ETag matches with the ETag in the state store.
|
||||
|
||||
Dapr chooses OCC because in many applications, data update conflicts are rare because clients are naturally partitioned by business contexts to operate on different data. However, if your application chooses to use ETags, a request may get rejected because of mismatched ETags. It's recommended that you use a retry policy to compensate for such conflicts when using ETags.
|
||||
Dapr chooses OCC because in many applications, data update conflicts are rare because clients are naturally partitioned by business contexts to operate on different data. However, if your application chooses to use ETags, a request may get rejected because of mismatched ETags. It's recommended that you use a retry policy in your code to compensate for such conflicts when using ETags.
|
||||
|
||||
If your application omits ETags in writing requests, Dapr skips ETag checks while handling the requests. This essentially enables the **last-write-wins** pattern, compared to the **first-write-wins** pattern with ETags.
|
||||
|
||||
|
|
@ -50,14 +48,7 @@ For stores that don't natively support ETags, it's expected that the correspondi
|
|||
|
||||
Read the [API reference]({{< ref state_api.md >}}) to learn how to set concurrency options.
|
||||
|
||||
### Automatic encryption
|
||||
|
||||
Dapr supports automatic client encryption of application state with support for key rotations. This is a preview feature and it is supported on all Dapr state stores.
|
||||
|
||||
For more info, read the [How-To: Encrypt application state]({{< ref howto-encrypt-state.md >}}) section.
|
||||
|
||||
### Consistency
|
||||
|
||||
Dapr supports both **strong consistency** and **eventual consistency**, with eventual consistency as the default behavior.
|
||||
|
||||
When strong consistency is used, Dapr waits for all replicas (or designated quorums) to acknowledge before it acknowledges a write request. When eventual consistency is used, Dapr returns as soon as the write request is accepted by the underlying data store, even if this is a single replica.
|
||||
|
|
@ -66,25 +57,40 @@ Read the [API reference]({{< ref state_api.md >}}) to learn how to set consisten
|
|||
|
||||
### Bulk operations
|
||||
|
||||
Dapr supports two types of bulk operations - **bulk** or **multi**. You can group several requests of the same type into a bulk (or a batch). Dapr submits requests in the bulk as individual requests to the underlying data store. In other words, bulk operations are not transactional. On the other hand, you can group requests of different types into a multi-operation, which is handled as an atomic transaction.
|
||||
Dapr supports two types of bulk operations: **bulk** or **multi**. You can group several requests of the same type into a bulk (or a batch). Dapr submits requests in bulk operations as individual requests to the underlying data store. In other words, bulk operations are not transactional. On the other hand, you can group requests of different types into a multi-operation, which is then handled as an atomic transaction.
|
||||
|
||||
Read the [API reference]({{< ref state_api.md >}}) to learn how use bulk and multi options.
|
||||
|
||||
### State encryption
|
||||
Dapr supports automatic client encryption of application state with support for key rotations. This is supported on all Dapr state stores. For more info, read the [How-To: Encrypt application state]({{< ref howto-encrypt-state.md >}}) topic.
|
||||
|
||||
### Shared state between applications
|
||||
Different applications might have different needs when it comes to sharing state. For example, in one scenario you may want to encapsulate all state within a given application and have Dapr manage the access for you. In a different scenario, you may need to have two applications working on the same state be able to get and save the same keys. Dapr enable states to be isolated to an application, shared in a state store between applications or have multiple applications share state across different state stores. For more details read [How-To: Share state between applications]({{< ref howto-share-state.md >}}),
|
||||
|
||||
### Actor state
|
||||
Transactional state stores can be used to store actor state. To specify which state store to be used for actors, specify value of property `actorStateStore` as `true` in the metadata section of the state store component. Actors state is stored with a specific scheme in transactional state stores, which allows for consistent querying. Only a single state store component can be used as the statestore for all actors. Read the [API reference]({{< ref state_api.md >}}) to learn more about state stores for actors and the [actors API reference]({{< ref actors_api.md >}})
|
||||
Transactional state stores can be used to store actor state. To specify which state store to be used for actors, specify value of property `actorStateStore` as `true` in the metadata section of the state store component. Actors state is stored with a specific scheme in transactional state stores, which allows for consistent querying. Only a single state store component can be used as the state store for all actors. Read the [API reference]({{< ref state_api.md >}}) to learn more about state stores for actors and the [actors API reference]({{< ref actors_api.md >}})
|
||||
|
||||
### Query state store directly
|
||||
### Querying state
|
||||
There are two ways to query the state:
|
||||
* Using the [state management query API]({{< ref "#state-query-api" >}}) provided in Dapr runtime.
|
||||
* Querying state store [directly]({{< ref "#query-state-store-directly" >}}) with the store's native SDK.
|
||||
|
||||
#### Query API
|
||||
The query API provides a way of querying the key/value data saved using state management in state stores regardless of underlying database or storage technology. It is an optional state management API. Using the state management query API you can filter, sort and paginate the key/value data. For more details read [How-To: Query state]({{< ref howto-state-query-api.md >}}).
|
||||
|
||||
#### Querying state store directly
|
||||
Dapr saves and retrieves state values without any transformation. You can query and aggregate state directly from the [underlying state store]({{< ref query-state-store >}}).
|
||||
|
||||
For example, to get all state keys associated with an application ID "myApp" in Redis, use:
|
||||
|
||||
```bash
|
||||
KEYS "myApp*"
|
||||
```
|
||||
|
||||
#### Querying actor state
|
||||
{{% alert title="Note on direct queries" color="primary" %}}
|
||||
Direct queries of the state store are not governed by Dapr concurrency control, since you are not calling through the Dapr runtime. What you see are snapshots of committed data which are acceptable for read-only queries across multiple actors, however writes should be done via the Dapr state management or actors APIs.
|
||||
{{% /alert %}}
|
||||
|
||||
##### Querying actor state
|
||||
If the data store supports SQL queries, you can query an actor's state using SQL queries. For example use:
|
||||
|
||||
```sql
|
||||
|
|
@ -97,20 +103,20 @@ You can also perform aggregate queries across actor instances, avoiding the comm
|
|||
SELECT AVG(value) FROM StateTable WHERE Id LIKE '<app-id>||<thermometer>||*||temperature'
|
||||
```
|
||||
|
||||
{{% alert title="Note on direct queries" color="primary" %}}
|
||||
Direct queries of the state store are not governed by Dapr concurrency control, since you are not calling through the Dapr runtime. What you see are snapshots of committed data which are acceptable for read-only queries across multiple actors, however writes should be done via the Dapr state management or actors APIs.
|
||||
{{% /alert %}}
|
||||
### State Time-to-Live (TTL)
|
||||
Dapr enables per state set request time-to-live (TTL). This means that applications can set time-to-live per state stored, and these states cannot be retrieved after expiration.
|
||||
|
||||
### State management API
|
||||
|
||||
The API for state management can be found in the [state management API reference]({{< ref state_api.md >}}) which describes how to retrieve, save and delete state values by providing keys.
|
||||
The state management API can be found in the [state management API reference]({{< ref state_api.md >}}) which describes how to retrieve, save, delete and query state values by providing keys.
|
||||
|
||||
## Next steps
|
||||
* Follow these guides on:
|
||||
* [How-To: Save and get state]({{< ref howto-get-save-state.md >}})
|
||||
* [How-To: Build a stateful service]({{< ref howto-stateful-service.md >}})
|
||||
* [How-To: Share state between applications]({{< ref howto-share-state.md >}})
|
||||
* [How-To: Query state]({{< ref howto-state-query-api.md >}})
|
||||
* [How-To: Encrypt application state]({{< ref howto-encrypt-state.md >}})
|
||||
* [State Time-to-Live]({{< ref state-store-ttl.md >}})
|
||||
* Try out the [hello world quickstart](https://github.com/dapr/quickstarts/blob/master/hello-world/README.md) which shows how to use state management or try the samples in the [Dapr SDKs]({{< ref sdks >}})
|
||||
* List of [state store components]({{< ref supported-state-stores.md >}})
|
||||
* Read the [state management API reference]({{< ref state_api.md >}})
|
||||
|
|
|
|||
|
|
@ -48,6 +48,11 @@ This command installs the latest darwin Dapr CLI to `/usr/local/bin`:
|
|||
```bash
|
||||
curl -fsSL https://raw.githubusercontent.com/dapr/cli/master/install/install.sh | /bin/bash
|
||||
```
|
||||
#### Note for ARM64 Macs
|
||||
Support for ARM64 Macs is available as a Preview feature. When installing from the terminal, native ARM64 binaries are downloaded when available. For older releases, AMD64 binaries are downloaded, which must be run with Rosetta2 emulation enabled. To install Rosetta emulation:
|
||||
```bash
|
||||
softwareupdate --install-rosetta
|
||||
```
|
||||
|
||||
### Install from Homebrew
|
||||
You can install via [Homebrew](https://brew.sh):
|
||||
|
|
@ -55,11 +60,11 @@ You can install via [Homebrew](https://brew.sh):
|
|||
brew install dapr/tap/dapr-cli
|
||||
```
|
||||
|
||||
#### Note for M1 Macs
|
||||
For M1 Macs, homebrew is not supported. You will need to use the dapr install script and have the rosetta amd64 compatibility layer installed. If you do not have it installed already, you can run the following:
|
||||
#### Note for ARM64 Macs
|
||||
For ARM64 Macs, only Homebrew 3.0 and higher versions are supported. Please update Homebrew to 3.0.0 or higher and then run the command below:
|
||||
|
||||
```bash
|
||||
softwareupdate --install-rosetta
|
||||
arch -arm64 brew install dapr/tap/dapr-cli
|
||||
```
|
||||
|
||||
### Install without `sudo`
|
||||
|
|
@ -132,4 +137,4 @@ Flags:
|
|||
Use "dapr [command] --help" for more information about a command.
|
||||
```
|
||||
|
||||
{{< button text="Next step: Initialize Dapr >>" page="install-dapr-selfhost" >}}
|
||||
{{< button text="Next step: Initialize Dapr >>" page="install-dapr-selfhost" >}}
|
||||
|
|
@ -16,3 +16,4 @@ Preview features in Dapr are considered experimental when they are first release
|
|||
| **gRPC proxying** | Enables calling endpoints using service invocation on gRPC services through Dapr via gRPC proxying, without requiring the use of Dapr SDKs. | `proxy.grpc` | [How-To: Invoke services using gRPC]({{<ref howto-invoke-services-grpc>}}) |
|
||||
| **State store encryption** | Enables automatic client side encryption for state stores | `State.Encryption` | [How-To: Encrypt application state]({{<ref howto-encrypt-state>}}) |
|
||||
| **Pub/Sub routing** | Allow the use of expressions to route cloud events to different URIs/paths and event handlers in your application. | `PubSub.Routing` | [How-To: Publish a message and subscribe to a topic]({{<ref howto-route-messages>}}) |
|
||||
| **ARM64 Mac Support** | Dapr CLI, sidecar, and Dashboard are now natively compiled for ARM64 Macs, along with Dapr CLI installation via Homebrew. | N/A | [Install the Dapr CLI]({{<ref install-dapr-cli>}}) |
|
||||
|
|
@ -39,13 +39,14 @@ The table below shows the versions of Dapr releases that have been tested togeth
|
|||
| May 26th 2021 | 1.2.0</br> | 1.2.0 | Java 1.1.0 </br>Go 1.1.0 </br>PHP 1.1.0 </br>Python 1.1.0 </br>.NET 1.2.0 | 0.6.0 | Unsupported |
|
||||
| Jun 16th 2021 | 1.2.1</br> | 1.2.0 | Java 1.1.0 </br>Go 1.1.0 </br>PHP 1.1.0 </br>Python 1.1.0 </br>.NET 1.2.0 | 0.6.0 | Unsupported |
|
||||
| Jun 16th 2021 | 1.2.2</br> | 1.2.0 | Java 1.1.0 </br>Go 1.1.0 </br>PHP 1.1.0 </br>Python 1.1.0 </br>.NET 1.2.0 | 0.6.0 | Unsupported |
|
||||
| Jul 26th 2021 | 1.3</br> | 1.3.0 | Java 1.2.0 </br>Go 1.2.0 </br>PHP 1.1.0 </br>Python 1.2.0 </br>.NET 1.3.0 | 0.7.0 | Supported |
|
||||
| Sep 14th 2021 | 1.3.1</br> | 1.3.0 | Java 1.2.0 </br>Go 1.2.0 </br>PHP 1.1.0 </br>Python 1.2.0 </br>.NET 1.3.0 | 0.7.0 | Supported |
|
||||
| Sep 15th 2021 | 1.4</br> | 1.4.0 | Java 1.3.0 </br>Go 1.3.0 </br>PHP 1.2.0 </br>Python 1.3.0 </br>.NET 1.4.0 | 0.8.0 | Supported |
|
||||
| Sep 22nd 2021 | 1.4.1</br> | 1.4.0 | Java 1.3.0 </br>Go 1.3.0 </br>PHP 1.2.0 </br>Python 1.3.0 </br>.NET 1.4.0 | 0.8.0 | Supported
|
||||
| Sep 24th 2021 | 1.4.2</br> | 1.4.0 | Java 1.3.0 </br>Go 1.3.0 </br>PHP 1.2.0 </br>Python 1.3.0 </br>.NET 1.4.0 | 0.8.0 | Supported |
|
||||
| Oct 7th 2021 | 1.4.3</br> | 1.4.0 | Java 1.3.0 </br>Go 1.3.0 </br>PHP 1.2.0 </br>Python 1.3.0 </br>.NET 1.4.0 | 0.8.0 | Supported (current) |
|
||||
|
||||
| Jul 26th 2021 | 1.3</br> | 1.3.0 | Java 1.2.0 </br>Go 1.2.0 </br>PHP 1.1.0 </br>Python 1.2.0 </br>.NET 1.3.0 | 0.7.0 | Unsupported |
|
||||
| Sep 14th 2021 | 1.3.1</br> | 1.3.0 | Java 1.2.0 </br>Go 1.2.0 </br>PHP 1.1.0 </br>Python 1.2.0 </br>.NET 1.3.0 | 0.7.0 | Unsupported |
|
||||
| Sep 15th 2021 | 1.4</br> | 1.4.0 | Java 1.3.0 </br>Go 1.2.0 </br>PHP 1.1.0 </br>Python 1.3.0 </br>.NET 1.4.0 | 0.8.0 | Supported |
|
||||
| Sep 22nd 2021 | 1.4.1</br> | 1.4.0 | Java 1.3.0 </br>Go 1.2.0 </br>PHP 1.1.0 </br>Python 1.3.0 </br>.NET 1.4.0 | 0.8.0 | Supported
|
||||
| Sep 24th 2021 | 1.4.2</br> | 1.4.0 | Java 1.3.0 </br>Go 1.2.0 </br>PHP 1.1.0 </br>Python 1.3.0 </br>.NET 1.4.0 | 0.8.0 | Supported |
|
||||
| Oct 7th 2021 | 1.4.3</br> | 1.4.0 | Java 1.3.0 </br>Go 1.2.0 </br>PHP 1.1.0 </br>Python 1.3.0 </br>.NET 1.4.0 | 0.8.0 | Supported |
|
||||
| Nov 11th 2021 | 1.5.0</br> | 1.5.0 | Java 1.3.0 </br>Go 1.3.0 </br>PHP 1.1.0 </br>Python 1.4.0 </br>.NET 1.5.0 </br>JS 1.0.2 | 0.9.0 | Supported (current) |
|
||||
|
||||
## Upgrade paths
|
||||
After the 1.0 release of the runtime there may be situations where it is necessary to explicitly upgrade through an additional release to reach the desired target. For example an upgrade from v1.0 to v1.2 may need go pass through v1.1
|
||||
|
||||
|
|
@ -59,15 +60,22 @@ General guidance on upgrading can be found for [self hosted mode]({{<ref self-ho
|
|||
| | 1.1.2 | 1.2.2 |
|
||||
| | 1.2.2 | 1.3.1 |
|
||||
| | 1.3.1 | 1.4.3 |
|
||||
| | 1.4.3 | 1.5.0 |
|
||||
| 1.1.0 to 1.1.2 | N/A | 1.2.2 |
|
||||
| | 1.2.2 | 1.3.1 |
|
||||
| | 1.3.1 | 1.4.3 |
|
||||
| | 1.4.3 | 1.5.0 |
|
||||
| 1.2.0 to 1.2.2 | N/A | 1.3.1 |
|
||||
| | 1.3.1 | 1.4.3 |
|
||||
| | 1.4.3 | 1.5.0 |
|
||||
| 1.3.0 | N/A | 1.3.1 |
|
||||
| | 1.3.1 | 1.4.3 |
|
||||
| | 1.4.3 | 1.5.0 |
|
||||
| 1.3.1 | N/A | 1.4.3 |
|
||||
| | 1.4.3 | 1.5.0 |
|
||||
| 1.4.0 to 1.4.2 | N/A | 1.4.3 |
|
||||
| | 1.4.3 | 1.5.0 |
|
||||
| 1.4.3 | N/A | 1.5.0 |
|
||||
|
||||
## Feature and deprecations
|
||||
There is a process for announcing feature deprecations. Deprecations are applied two (2) releases after the release in which they were announced. For example Feature X is announced to be deprecated in the 1.0.0 release notes and will then be removed in 1.2.0.
|
||||
|
|
|
|||
|
|
@ -292,6 +292,132 @@ None.
|
|||
curl -X "DELETE" http://localhost:3500/v1.0/state/starwars/planet -H "If-Match: xxxxxxx"
|
||||
```
|
||||
|
||||
## Query state
|
||||
|
||||
This endpoint lets you query the key/value state.
|
||||
|
||||
{{% alert title="alpha" color="warning" %}}
|
||||
This API is in alpha stage.
|
||||
{{% /alert %}}
|
||||
|
||||
### HTTP Request
|
||||
|
||||
```
|
||||
POST/PUT http://localhost:<daprPort>/v1.0-alpha1/state/<storename>/query
|
||||
```
|
||||
|
||||
#### URL Parameters
|
||||
|
||||
Parameter | Description
|
||||
--------- | -----------
|
||||
daprPort | the Dapr port
|
||||
storename | ```metadata.name``` field in the user configured state store component yaml. Refer to the Dapr state store configuration structure mentioned above.
|
||||
metadata | (optional) metadata as query parameters to the state store
|
||||
|
||||
> Note, all URL parameters are case-sensitive.
|
||||
|
||||
#### Response Codes
|
||||
|
||||
Code | Description
|
||||
---- | -----------
|
||||
200 | State query successful
|
||||
400 | State store is missing or misconfigured
|
||||
500 | State query failed
|
||||
|
||||
#### Response Body
|
||||
An array of JSON-encoded values
|
||||
|
||||
### Example
|
||||
|
||||
```shell
|
||||
curl http://localhost:3500/v1.0-alpha1/state/myStore/query \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"query": {
|
||||
"filter": {
|
||||
"OR": [
|
||||
{
|
||||
"EQ": { "value.person.org": "Dev Ops" }
|
||||
},
|
||||
{
|
||||
"AND": [
|
||||
{
|
||||
"EQ": { "value.person.org": "Finance" }
|
||||
},
|
||||
{
|
||||
"IN": { "value.state": [ "CA", "WA" ] }
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
"sort": [
|
||||
{
|
||||
"key": "value.state",
|
||||
"order": "DESC"
|
||||
},
|
||||
{
|
||||
"key": "value.person.id"
|
||||
}
|
||||
],
|
||||
"pagination": {
|
||||
"limit": 3
|
||||
}
|
||||
}
|
||||
}'
|
||||
```
|
||||
|
||||
> The above command returns an array of objects along with a token:
|
||||
|
||||
```json
|
||||
{
|
||||
"results": [
|
||||
{
|
||||
"key": "1",
|
||||
"data": {
|
||||
"person": {
|
||||
"org": "Dev Ops",
|
||||
"id": 1036
|
||||
},
|
||||
"city": "Seattle",
|
||||
"state": "WA"
|
||||
},
|
||||
"etag": "6f54ad94-dfb9-46f0-a371-e42d550adb7d"
|
||||
},
|
||||
{
|
||||
"key": "4",
|
||||
"data": {
|
||||
"person": {
|
||||
"org": "Dev Ops",
|
||||
"id": 1042
|
||||
},
|
||||
"city": "Spokane",
|
||||
"state": "WA"
|
||||
},
|
||||
"etag": "7415707b-82ce-44d0-bf15-6dc6305af3b1"
|
||||
},
|
||||
{
|
||||
"key": "10",
|
||||
"data": {
|
||||
"person": {
|
||||
"org": "Dev Ops",
|
||||
"id": 1054
|
||||
},
|
||||
"city": "New York",
|
||||
"state": "NY"
|
||||
},
|
||||
"etag": "26bbba88-9461-48d1-8a35-db07c374e5aa"
|
||||
}
|
||||
],
|
||||
"token": "3"
|
||||
}
|
||||
```
|
||||
To pass metadata as query parammeter:
|
||||
|
||||
```
|
||||
POST http://localhost:3500/v1.0-alpha1/state/myStore/query?metadata.partitionKey=mypartitionKey
|
||||
```
|
||||
|
||||
## State transactions
|
||||
|
||||
Persists the changes to the state store as a multi-item transaction.
|
||||
|
|
|
|||
|
|
@ -27,6 +27,7 @@ This table is meant to help users understand the equivalent options for running
|
|||
| `--enable-metrics` | not supported | | configuration spec | Enable prometheus metric (default true) |
|
||||
| `--enable-mtls` | not supported | | configuration spec | Enables automatic mTLS for daprd to daprd communication channels |
|
||||
| `--enable-profiling` | `--enable-profiling` | | `dapr.io/enable-profiling` | Enable profiling |
|
||||
| `--unix-domain-socket` | `--unix-domain-socket` | `-u` | not supported | On Linux, when communicating with the Dapr sidecar, use unix domain sockets for lower latency and greater throughput compared to TCP ports. Not available on Windows OS |
|
||||
| `--log-as-json` | not supported | | `dapr.io/log-as-json` | Setting this parameter to `true` outputs logs in JSON format. Default is `false` |
|
||||
| `--log-level` | `--log-level` | | `dapr.io/log-level` | Sets the log level for the Dapr sidecar. Allowed values are `debug`, `info`, `warn`, `error`. Default is `info` |
|
||||
| `--app-max-concurrency` | `--app-max-concurrency` | | `dapr.io/app-max-concurrency` | Limit the concurrency of your application. A valid value is any number larger than `0`
|
||||
|
|
|
|||
|
|
@ -38,6 +38,7 @@ dapr run [flags] [command]
|
|||
| `--log-level` | | `info` | The log verbosity. Valid values are: `debug`, `info`, `warn`, `error`, `fatal`, or `panic` |
|
||||
| `--metrics-port` | `DAPR_METRICS_PORT` | `9090` | The port that Dapr sends its metrics information to |
|
||||
| `--profile-port` | | `7777` | The port for the profile server to listen on |
|
||||
| `--unix-domain-socket`, `-u` | | | Path to a unix domain socket dir mount. If specified, communication with the Dapr sidecar uses unix domain sockets for lower latency and greater throughput when compared to using TCP ports. Not available on Windows OS |
|
||||
| `--dapr-http-max-request-size` | | `4` | Max size of request body in MB. |
|
||||
|
||||
### Examples
|
||||
|
|
@ -46,6 +47,9 @@ dapr run [flags] [command]
|
|||
# Run a .NET application
|
||||
dapr run --app-id myapp --app-port 5000 -- dotnet run
|
||||
|
||||
# Run a .Net application with unix domain sockets
|
||||
dapr run --app-id myapp --app-port 5000 --unix-domain-socket /tmp -- dotnet run
|
||||
|
||||
# Run a Java application
|
||||
dapr run --app-id myapp -- java -jar myapp.jar
|
||||
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ Table captions:
|
|||
|------|:----------------:|:-----------------:|--------| ------ |----------|
|
||||
| [Alibaba Cloud DingTalk]({{< ref alicloud-dingtalk.md >}}) | ✅ | ✅ | Alpha | v1 | 1.2 |
|
||||
| [Alibaba Cloud OSS]({{< ref alicloudoss.md >}}) | | ✅ | Alpha | v1 | 1.0 |
|
||||
| [Alibaba Cloud Tablestore]({{< ref alicloudtablestore.md >}}) | | ✅ | Alpha | v1 | 1.4 |
|
||||
| [Alibaba Cloud Tablestore]({{< ref alicloudtablestore.md >}}) | | ✅ | Alpha | v1 | 1.5 |
|
||||
|
||||
### Amazon Web Services (AWS)
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,6 @@ aliases:
|
|||
|
||||
To setup MQTT binding create a component of type `bindings.mqtt`. See [this guide]({{< ref "howto-bindings.md#1-create-a-binding" >}}) on how to create and apply a binding configuration.
|
||||
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
|
|
@ -25,14 +24,17 @@ spec:
|
|||
- name: url
|
||||
value: "tcp://[username][:password]@host.domain[:port]"
|
||||
- name: topic
|
||||
value: "topic1"
|
||||
value: "mytopic"
|
||||
- name: qos
|
||||
value: 1
|
||||
- name: retain
|
||||
value: "false"
|
||||
- name: cleanSession
|
||||
value: "false"
|
||||
value: "true"
|
||||
- name: backOffMaxRetries
|
||||
value: "0"
|
||||
```
|
||||
|
||||
{{% alert title="Warning" color="warning" %}}
|
||||
The above example uses secrets as plain strings. It is recommended to use a secret store for the secrets as described [here]({{< ref component-secrets.md >}}).
|
||||
{{% /alert %}}
|
||||
|
|
@ -41,19 +43,20 @@ The above example uses secrets as plain strings. It is recommended to use a secr
|
|||
|
||||
| Field | Required | Binding support | Details | Example |
|
||||
|--------------------|:--------:|---------|---------|---------|
|
||||
| url | Y | Input/Output | Address of the MQTT broker | Use `**tcp://**` scheme for non-TLS communication. Use`**ssl://**` scheme for TLS communication. <br> "tcp://[username][:password]@host.domain[:port]"
|
||||
| topic | Y | Input/Output | The topic to listen on or send events to | `"mytopic"` |
|
||||
| qos | N | Input/Output | Indicates the Quality of Service Level (QoS) of the message. Default 0|`1`
|
||||
| retain | N | Input/Output | Defines whether the message is saved by the broker as the last known good value for a specified topic. Default `"false"` | `"true"`, `"false"`
|
||||
| cleanSession | N | Input/Output | will set the "clean session" in the connect message when client connects to an MQTT broker. Default `"true"` | `"true"`, `"false"`
|
||||
| caCert | Required for using TLS | Input/Output | Certificate authority certificate. Can be `secretKeyRef` to use a secret reference | `0123456789-0123456789`
|
||||
| clientCert | Required for using TLS | Input/Output | Client certificate. Can be `secretKeyRef` to use a secret reference | `0123456789-0123456789`
|
||||
| clientKey | Required for using TLS | Input/Output | Client key. Can be `secretKeyRef` to use a secret reference | `012345`
|
||||
| url | Y | Input/Output | 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]"`
|
||||
| topic | Y | Input/Output | The topic to listen on or send events to. | `"mytopic"` |
|
||||
| consumerID | N | Input/Output | The client ID used to connect to the MQTT broker. Defaults to the Dapr app ID. | `"myMqttClientApp"`
|
||||
| qos | N | Input/Output | Indicates the Quality of Service Level (QoS) of the message. Defaults to `0`. |`1`
|
||||
| retain | N | Input/Output | 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 | Input/Output | Sets the `clean_session` flag in the connection message to the MQTT broker if `"true"`. Defaults to `"true"`. | `"true"`, `"false"`
|
||||
| caCert | Required for using TLS | Input/Output | 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 | Input/Output | TLS client certificate in PEM format. Must be used with `clientKey`. | `"-----BEGIN CERTIFICATE-----\n<base64-encoded DER>\n-----END CERTIFICATE-----"`
|
||||
| clientKey | Required for using TLS | Input/Output | TLS client key in PEM format. Must be used with `clientCert`. Can be `secretKeyRef` to use a secret reference. | `"-----BEGIN RSA PRIVATE KEY-----\n<base64-encoded PKCS8>\n-----END RSA PRIVATE KEY-----"`
|
||||
| backOffMaxRetries | N | Input | The maximum number of retries to process the message before returning an error. Defaults to `"0"`, which means that no retries will be attempted. `"-1"` can be specified to indicate that messages should be retried indefinitely until they are successfully processed or the application is shutdown. The component will wait 5 seconds between retries. | `"3"`
|
||||
|
||||
### Communication using TLS
|
||||
To configure communication using TLS, ensure mosquitto broker is configured to support certificates.
|
||||
Pre-requisite includes `certficate authority certificate`, `ca issued client certificate`, `client private key`.
|
||||
Here is an example.
|
||||
|
||||
To configure communication using TLS, ensure that the MQTT broker (e.g. mosquitto) is configured to support certificates and provide the `caCert`, `clientCert`, `clientKey` metadata in the component configuration. For example:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
|
|
@ -75,23 +78,31 @@ spec:
|
|||
value: "false"
|
||||
- name: cleanSession
|
||||
value: "false"
|
||||
- name: backoffMaxRetries
|
||||
value: "0"
|
||||
- name: caCert
|
||||
value: ''
|
||||
value: ${{ myLoadedCACert }}
|
||||
- name: clientCert
|
||||
value: ''
|
||||
value: ${{ myLoadedClientCert }}
|
||||
- name: clientKey
|
||||
value: ''
|
||||
secretKeyRef:
|
||||
name: myMqttClientKey
|
||||
key: myMqttClientKey
|
||||
auth:
|
||||
secretStore: <SECRET_STORE_NAME>
|
||||
```
|
||||
|
||||
Note that while the `caCert` and `clientCert` values may not be secrets, they can be referenced from a Dapr secret store as well for convenience.
|
||||
|
||||
### Consuming a shared topic
|
||||
|
||||
When consuming a shared topic, each consumer must have a unique identifier. By default, the application Id is used to uniquely identify each consumer and publisher. In self-hosted mode, running each Dapr run with a different application Id is sufficient to have them consume from the same shared topic. However on Kubernetes, a pod with multiple application instances shares the same application Id, prohibiting all instances from consuming the same topic. To overcome this, configure the component's `ConsumerID` metadata with a `{uuid}` tag, making each instance to have a randomly generated `ConsumerID` value on start up. For example:
|
||||
When consuming a shared topic, each consumer must have a unique identifier. By default, the application ID is used to uniquely identify each consumer and publisher. In self-hosted mode, invoking each `dapr run` with a different application ID is sufficient to have them consume from the same shared topic. However, on Kubernetes, multiple instances of an application pod will share the same application ID, prohibiting all instances from consuming the same topic. To overcome this, configure the component's `consumerID` metadata with a `{uuid}` tag, which will give each instance a randomly generated `consumerID` value on start up. For example:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: messagebus
|
||||
name: mqtt-binding
|
||||
namespace: default
|
||||
spec:
|
||||
type: bindings.mqtt
|
||||
|
|
@ -109,6 +120,8 @@ spec:
|
|||
value: "false"
|
||||
- name: cleanSession
|
||||
value: "false"
|
||||
- name: backoffMaxRetries
|
||||
value: "0"
|
||||
```
|
||||
|
||||
{{% alert title="Warning" color="warning" %}}
|
||||
|
|
@ -122,6 +135,7 @@ This component supports both **input and output** binding interfaces.
|
|||
This component supports **output binding** with the following operations:
|
||||
|
||||
- `create`
|
||||
|
||||
## Related links
|
||||
|
||||
- [Basic schema for a Dapr component]({{< ref component-schema >}})
|
||||
|
|
|
|||
|
|
@ -22,12 +22,12 @@ Table captions:
|
|||
|
||||
| Name | Status | Component version | Since |
|
||||
|-------------------------------------------------------|--------| -----| ------------- |
|
||||
| [Apache Kafka]({{< ref setup-apache-kafka.md >}}) | Beta | v1 | 1.0 |
|
||||
| [Apache Kafka]({{< ref setup-apache-kafka.md >}}) | Stable | v1 | 1.5 |
|
||||
| [Hazelcast]({{< ref setup-hazelcast.md >}}) | Alpha | v1 | 1.0 |
|
||||
| [MQTT]({{< ref setup-mqtt.md >}}) | Alpha | v1 | 1.0 |
|
||||
| [NATS Streaming]({{< ref setup-nats-streaming.md >}}) | Beta | v1 | 1.0 |
|
||||
| [In Memory]({{< ref setup-inmemory.md >}}) | Alpha | v1 | 1.4 |
|
||||
| [JetStream]({{< ref setup-jetstream.md >}}) | Alpha | v1 | 1.4 |
|
||||
| [NATS Streaming]({{< ref setup-nats-streaming.md >}}) | Beta | v1 | 1.0 |
|
||||
| [In Memory]({{< ref setup-inmemory.md >}}) | Alpha | v1 | 1.4 |
|
||||
| [JetStream]({{< ref setup-jetstream.md >}}) | Alpha | v1 | 1.4 |
|
||||
| [Pulsar]({{< ref setup-pulsar.md >}}) | Alpha | v1 | 1.0 |
|
||||
| [RabbitMQ]({{< ref setup-rabbitmq.md >}}) | Alpha | v1 | 1.0 |
|
||||
| [Redis Streams]({{< ref setup-redis-pubsub.md >}}) | Stable | v1 | 1.0 |
|
||||
|
|
|
|||
|
|
@ -39,6 +39,8 @@ spec:
|
|||
value: 1024
|
||||
- name: consumeRetryInterval # Optional.
|
||||
value: 200ms
|
||||
- name: version # Optional.
|
||||
value: 0.10.2.0
|
||||
```
|
||||
|
||||
## Spec metadata fields
|
||||
|
|
@ -54,6 +56,65 @@ spec:
|
|||
| initialOffset | N | The initial offset to use if no offset was previously committed. Should be "newest" or "oldest". Defaults to "newest". | `"oldest"`
|
||||
| maxMessageBytes | N | The maximum size in bytes allowed for a single Kafka message. Defaults to 1024. | `2048`
|
||||
| consumeRetryInterval | N | The interval between retries when attempting to consume topics. Treats numbers without suffix as milliseconds. Defaults to 100ms. | `200ms`
|
||||
| version | N | Kafka cluster version. Defaults to 2.0.0.0 | `0.10.2.0`
|
||||
| caCert | N | Certificate authority certificate, required for using TLS. Can be `secretKeyRef` to use a secret reference | `"-----BEGIN CERTIFICATE-----\n<base64-encoded DER>\n-----END CERTIFICATE-----"`
|
||||
| clientCert | N | Client certificate, required for using TLS. Can be `secretKeyRef` to use a secret reference | `"-----BEGIN CERTIFICATE-----\n<base64-encoded DER>\n-----END CERTIFICATE-----"`
|
||||
| clientKey | N | Client key, required for using TLS. Can be `secretKeyRef` to use a secret reference | `"-----BEGIN RSA PRIVATE KEY-----\n<base64-encoded PKCS8>\n-----END RSA PRIVATE KEY-----"`
|
||||
| skipVerify | N | Skip TLS verification, this is not recommended for use in production. Defaults to `"false"` | `"true"`, `"false"` |
|
||||
|
||||
### Communication using TLS
|
||||
To configure communication using TLS, ensure the Kafka broker is configured to support certificates.
|
||||
Pre-requisite includes `certficate authority certificate`, `ca issued client certificate`, `client private key`.
|
||||
Below is an example of a Kafka pubsub component configured to use TLS:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: kafka-pubsub
|
||||
namespace: default
|
||||
spec:
|
||||
type: pubsub.kafka
|
||||
version: v1
|
||||
metadata:
|
||||
- name: brokers # Required. Kafka broker connection setting
|
||||
value: "dapr-kafka.myapp.svc.cluster.local:9092"
|
||||
- name: consumerGroup # Optional. Used for input bindings.
|
||||
value: "group1"
|
||||
- name: clientID # Optional. Used as client tracing ID by Kafka brokers.
|
||||
value: "my-dapr-app-id"
|
||||
- name: authRequired # Required.
|
||||
value: "true"
|
||||
- name: saslUsername # Required if authRequired is `true`.
|
||||
value: "adminuser"
|
||||
- name: consumeRetryInterval # Optional.
|
||||
value: 200ms
|
||||
- name: version # Optional.
|
||||
value: 0.10.2.0
|
||||
- name: saslPassword # Required if authRequired is `true`.
|
||||
secretKeyRef:
|
||||
name: kafka-secrets
|
||||
key: saslPasswordSecret
|
||||
- name: maxMessageBytes # Optional.
|
||||
value: 1024
|
||||
- name: caCert # Certificate authority certificate.
|
||||
secretKeyRef:
|
||||
name: kafka-tls
|
||||
key: caCert
|
||||
- name: clientCert # Client certificate.
|
||||
secretKeyRef:
|
||||
name: kafka-tls
|
||||
key: clientCert
|
||||
- name: clientKey # Client key.
|
||||
secretKeyRef:
|
||||
name: kafka-tls
|
||||
key: clientKey
|
||||
auth:
|
||||
secretStore: <SECRET_STORE_NAME>
|
||||
```
|
||||
|
||||
The `secretKeyRef` above is referencing a [kubernetes secrets store]({{< ref kubernetes-secret-store.md >}}) to access the tls information. Visit [here]({{< ref setup-secret-store.md >}}) to learn more about how to configure a secret store component.
|
||||
|
||||
|
||||
## Per-call metadata fields
|
||||
|
||||
|
|
|
|||
|
|
@ -28,26 +28,32 @@ spec:
|
|||
- name: retain
|
||||
value: "false"
|
||||
- name: cleanSession
|
||||
value: "false"
|
||||
value: "true"
|
||||
- name: backOffMaxRetries
|
||||
value: "0"
|
||||
```
|
||||
|
||||
{{% alert title="Warning" color="warning" %}}
|
||||
The above example uses secrets as plain strings. It is recommended to use a secret store for the secrets as described [here]({{< ref component-secrets.md >}}).
|
||||
{{% /alert %}}
|
||||
|
||||
## Spec metadata fields
|
||||
|
||||
| Field | Required | Details | Example |
|
||||
|--------------------|:--------:|---------|---------|
|
||||
| url | Y | Address of the MQTT broker | Use `**tcp://**` scheme for non-TLS communication. Use`**tcps://**` scheme for TLS communication. <br> "tcp://[username][:password]@host.domain[:port]"
|
||||
| qos | N | Indicates the Quality of Service Level (QoS) of the message. Default 0|`1`
|
||||
| retain | N | Defines whether the message is saved by the broker as the last known good value for a specified topic. Default `"false"` | `"true"`, `"false"`
|
||||
| cleanSession | N | will set the "clean session" in the connect message when client connects to an MQTT broker. Default `"true"` | `"true"`, `"false"`
|
||||
| caCert | Required for using TLS | Certificate authority certificate. Can be `secretKeyRef` to use a secret reference | `0123456789-0123456789`
|
||||
| clientCert | Required for using TLS | Client certificate. Can be `secretKeyRef` to use a secret reference | `0123456789-0123456789`
|
||||
| clientKey | Required for using TLS | Client key. Can be `secretKeyRef` to use a secret reference | `012345`
|
||||
| backOffMaxRetries | N | The maximum number of retries to process the message before returning an error. Defaults to `"0"` which means the component will not retry processing the message. `"-1"` will retry indefinitely until the message is processed or the application is shutdown. And positive number is treated as the maximum retry count. The component will wait 5 seconds between retries. | `"3"`
|
||||
|
||||
| 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"`
|
||||
| qos | N | Indicates the Quality of Service Level (QoS) of the message. Defaults to `0`. |`1`
|
||||
| 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"`. Defaults to `"true"`. | `"true"`, `"false"`
|
||||
| caCert | Required for using TLS | Certificate Authority (CA) certificate in PEM format for verifying server TLS certificates. | `"-----BEGIN CERTIFICATE-----\n<base64-encoded DER>\n-----END CERTIFICATE-----"`
|
||||
| clientCert | Required for using TLS | TLS client certificate in PEM format. Must be used with `clientKey`. | `"-----BEGIN CERTIFICATE-----\n<base64-encoded DER>\n-----END CERTIFICATE-----"`
|
||||
| clientKey | Required for using TLS | TLS client key in PEM format. Must be used with `clientCert`. Can be `secretKeyRef` to use a secret reference. | `"-----BEGIN RSA PRIVATE KEY-----\n<base64-encoded PKCS8>\n-----END RSA PRIVATE KEY-----"`
|
||||
| backOffMaxRetries | N | The maximum number of retries to process the message before returning an error. Defaults to `"0"`, which means that no retries will be attempted. `"-1"` can be specified to indicate that messages should be retried indefinitely until they are successfully processed or the application is shutdown. The component will wait 5 seconds between retries. | `"3"`
|
||||
|
||||
### Communication using TLS
|
||||
To configure communication using TLS, ensure mosquitto broker is configured to support certificates.
|
||||
Pre-requisite includes `certficate authority certificate`, `ca issued client certificate`, `client private key`.
|
||||
Here is an example.
|
||||
|
||||
To configure communication using TLS, ensure that the MQTT broker (e.g. mosquitto) is configured to support certificates and provide the `caCert`, `clientCert`, `clientKey` metadata in the component configuration. For example:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
|
|
@ -60,30 +66,38 @@ spec:
|
|||
version: v1
|
||||
metadata:
|
||||
- name: url
|
||||
value: "tcps://host.domain[:port]"
|
||||
value: "ssl://host.domain[:port]"
|
||||
- name: qos
|
||||
value: 1
|
||||
- name: retain
|
||||
value: "false"
|
||||
- name: cleanSession
|
||||
value: "false"
|
||||
- name: backoffMaxRetries
|
||||
value: "0"
|
||||
- name: caCert
|
||||
value: ''
|
||||
value: ${{ myLoadedCACert }}
|
||||
- name: clientCert
|
||||
value: ''
|
||||
value: ${{ myLoadedClientCert }}
|
||||
- name: clientKey
|
||||
value: ''
|
||||
secretKeyRef:
|
||||
name: myMqttClientKey
|
||||
key: myMqttClientKey
|
||||
auth:
|
||||
secretStore: <SECRET_STORE_NAME>
|
||||
```
|
||||
|
||||
Note that while the `caCert` and `clientCert` values may not be secrets, they can be referenced from a Dapr secret store as well for convenience.
|
||||
|
||||
### Consuming a shared topic
|
||||
|
||||
When consuming a shared topic, each consumer must have a unique identifier. By default, the application Id is used to uniquely identify each consumer and publisher. In self-hosted mode, running each Dapr run with a different application Id is sufficient to have them consume from the same shared topic. However on Kubernetes, a pod with multiple application instances shares the same application Id, prohibiting all instances from consuming the same topic. To overcome this, configure the component's `ConsumerID` metadata with a `{uuid}` tag, making each instance to have a randomly generated `ConsumerID` value on start up. For example:
|
||||
When consuming a shared topic, each consumer must have a unique identifier. By default, the application ID is used to uniquely identify each consumer and publisher. In self-hosted mode, invoking each `dapr run` with a different application ID is sufficient to have them consume from the same shared topic. However, on Kubernetes, multiple instances of an application pod will share the same application ID, prohibiting all instances from consuming the same topic. To overcome this, configure the component's `consumerID` metadata with a `{uuid}` tag, which will give each instance a randomly generated `consumerID` value on start up. For example:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: messagebus
|
||||
name: mqtt-pubsub
|
||||
namespace: default
|
||||
spec:
|
||||
type: pubsub.mqtt
|
||||
|
|
@ -99,13 +113,14 @@ spec:
|
|||
value: "false"
|
||||
- name: cleanSession
|
||||
value: "false"
|
||||
- name: backoffMaxRetries
|
||||
value: "0"
|
||||
```
|
||||
|
||||
{{% alert title="Warning" color="warning" %}}
|
||||
The above example uses secrets as plain strings. It is recommended to use a secret store for the secrets as described [here]({{< ref component-secrets.md >}}).
|
||||
{{% /alert %}}
|
||||
|
||||
|
||||
## Create a MQTT broker
|
||||
|
||||
{{< tabs "Self-Hosted" "Kubernetes">}}
|
||||
|
|
@ -116,6 +131,7 @@ You can run a MQTT broker [locally using Docker](https://hub.docker.com/_/eclips
|
|||
```bash
|
||||
docker run -d -p 1883:1883 -p 9001:9001 --name mqtt eclipse-mosquitto:1.6.9
|
||||
```
|
||||
|
||||
You can then interact with the server using the client port: `mqtt://localhost:1883`
|
||||
{{% /codetab %}}
|
||||
|
||||
|
|
@ -171,12 +187,14 @@ spec:
|
|||
name: websocket
|
||||
protocol: TCP
|
||||
```
|
||||
|
||||
You can then interact with the server using the client port: `tcp://mqtt-broker.default.svc.cluster.local:1883`
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
## Related links
|
||||
|
||||
- [Basic schema for a Dapr component]({{< ref component-schema >}})
|
||||
- Read [this guide]({{< ref "howto-publish-subscribe.md#step-2-publish-a-topic" >}}) for instructions on configuring pub/sub components
|
||||
- [Pub/Sub building block]({{< ref pubsub >}})
|
||||
|
|
|
|||
|
|
@ -24,16 +24,48 @@ spec:
|
|||
value: "localhost:6650"
|
||||
- name: enableTLS
|
||||
value: "false"
|
||||
|
||||
```
|
||||
|
||||
## Spec metadata fields
|
||||
|
||||
| Field | Required | Details | Example |
|
||||
|--------------------|:--------:|---------|---------|
|
||||
| host | Y | Address of the Pulsar broker. Default is `"localhost:6650"` | `"localhost:6650"`
|
||||
| enableTLS | N | Enable TLS. Default: `"false"` | `"true"`, `"false"`
|
||||
| host | Y | Address of the Pulsar broker. Default is `"localhost:6650"` | `"localhost:6650"`|
|
||||
| enableTLS | N | Enable TLS. Default: `"false"` | `"true"`, `"false"`|
|
||||
|
||||
|
||||
### Delay queue
|
||||
|
||||
When invoking the Pulsar pub/sub, it's possible to provide an optional delay queue by using the `metadata` query parameters in the request url.
|
||||
|
||||
These optional parameter names are `metadata.deliverAt` or `metadata.deliverAfter`:
|
||||
- `deliverAt`: Delay message to deliver at a specified time (RFC3339 format), e.g. `"2021-09-01T10:00:00Z"`
|
||||
- `deliverAfter`: Delay message to deliver after a specified amount of time, e.g.`"4h5m3s"`
|
||||
|
||||
Examples:
|
||||
|
||||
```shell
|
||||
curl -X POST http://localhost:3500/v1.0/publish/myPulsar/myTopic?metadata.deliverAt='2021-09-01T10:00:00Z' \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"data": {
|
||||
"message": "Hi"
|
||||
}
|
||||
}'
|
||||
```
|
||||
|
||||
Or
|
||||
|
||||
```shell
|
||||
curl -X POST http://localhost:3500/v1.0/publish/myPulsar/myTopic?metadata.deliverAfter='4h5m3s' \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"data": {
|
||||
"message": "Hi"
|
||||
}
|
||||
}'
|
||||
```
|
||||
|
||||
## Create a Pulsar instance
|
||||
|
||||
{{< tabs "Self-Hosted" "Kubernetes">}}
|
||||
|
|
@ -60,4 +92,4 @@ Refer to the following [Helm chart](https://pulsar.apache.org/docs/en/kubernetes
|
|||
## Related links
|
||||
- [Basic schema for a Dapr component]({{< ref component-schema >}})
|
||||
- Read [this guide]({{< ref "howto-publish-subscribe.md#step-2-publish-a-topic" >}}) for instructions on configuring pub/sub components
|
||||
- [Pub/Sub building block]({{< ref pubsub >}})
|
||||
- [Pub/Sub building block]({{< ref pubsub >}})
|
||||
|
|
|
|||
|
|
@ -23,8 +23,8 @@ Table captions:
|
|||
|
||||
| Name | Status | Component version | Since |
|
||||
|-------------------------------------------------------------------|------------------------------| ---------------- |-- |
|
||||
| [Local environment variables]({{< ref envvar-secret-store.md >}}) | Beta | v1 | 1.0 |
|
||||
| [Local file]({{< ref file-secret-store.md >}}) | Beta | v1 | 1.0 |
|
||||
| [Local environment variables]({{< ref envvar-secret-store.md >}}) | Beta | v1 | 1.0 |
|
||||
| [Local file]({{< ref file-secret-store.md >}}) | Beta | v1 | 1.0 |
|
||||
| [HashiCorp Vault]({{< ref hashicorp-vault.md >}}) | Alpha | v1 | 1.0 |
|
||||
| [Kubernetes secrets]({{< ref kubernetes-secret-store.md >}}) | Stable | v1 | 1.0 |
|
||||
|
||||
|
|
@ -45,4 +45,4 @@ Table captions:
|
|||
|
||||
| Name | Status | Component version | Since |
|
||||
|---------------------------------------------------------------------------------------|--------| ---- |--------------|
|
||||
| [Azure Key Vault]({{< ref azure-keyvault.md >}}) | Stable | v1 | 1.0 |
|
||||
| [Azure Key Vault]({{< ref azure-keyvault.md >}}) | Stable | v1 | 1.0 |
|
||||
|
|
|
|||
|
|
@ -258,6 +258,43 @@ To use a **certificate**:
|
|||
kubectl apply -f azurekeyvault.yaml
|
||||
```
|
||||
|
||||
To use **Azure managed identity**:
|
||||
|
||||
1. Ensure your AKS cluster has managed identity enabled and follow the [guide for using managed identities](https://docs.microsoft.com/azure/aks/use-managed-identity).
|
||||
2. Create an `azurekeyvault.yaml` component file.
|
||||
|
||||
The component yaml refers to a particular KeyVault name. The managed identity you will use in a later step must be given read access to this particular KeyVault instance.
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: azurekeyvault
|
||||
namespace: default
|
||||
spec:
|
||||
type: secretstores.azure.keyvault
|
||||
version: v1
|
||||
metadata:
|
||||
- name: vaultName
|
||||
value: "[your_keyvault_name]"
|
||||
```
|
||||
|
||||
3. Apply the `azurekeyvault.yaml` component:
|
||||
|
||||
```bash
|
||||
kubectl apply -f azurekeyvault.yaml
|
||||
```
|
||||
4. Create and use a managed identity / pod identity by following [this guide](https://docs.microsoft.com/azure/aks/use-azure-ad-pod-identity#create-a-pod-identity). After creating an AKS pod identity, [give this identity read permissions on your desired KeyVault instance](https://docs.microsoft.com/azure/key-vault/general/assign-access-policy?tabs=azure-cli#assign-the-access-policy), and finally in your application deployment inject the pod identity via a label annotation:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: mydaprdemoapp
|
||||
labels:
|
||||
aadpodidbinding: $POD_IDENTITY_NAME
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
|
|
|||
|
|
@ -26,38 +26,38 @@ The following stores are supported, at various levels, by the Dapr state managem
|
|||
|
||||
### Generic
|
||||
|
||||
| Name | CRUD | Transactional | ETag | [TTL]({{< ref state-store-ttl.md >}}) | [Actors]({{< ref howto-actors.md >}}) | Status | Component version | Since |
|
||||
|----------------------------------------------------------------|------|---------------------|------|-----|------|--------| -------|------|
|
||||
| [Aerospike]({{< ref setup-aerospike.md >}}) | ✅ | ❌ | ✅ | ❌ | ❌ | Alpha | v1 | 1.0 |
|
||||
| [Apache Cassandra]({{< ref setup-cassandra.md >}}) | ✅ | ❌ | ❌ | ✅ | ❌ | Alpha | v1 | 1.0 |
|
||||
| [Cloudstate]({{< ref setup-cloudstate.md >}}) | ✅ | ❌ | ✅ | ❌ | ❌ | Alpha | v1 | 1.0 |
|
||||
| [Couchbase]({{< ref setup-couchbase.md >}}) | ✅ | ❌ | ✅ | ❌ | ❌ | Alpha | v1 | 1.0 |
|
||||
| [Hashicorp Consul]({{< ref setup-consul.md >}}) | ✅ | ❌ | ❌ | ❌ | ❌ | Alpha | v1 | 1.0 |
|
||||
| [Hazelcast]({{< ref setup-hazelcast.md >}}) | ✅ | ❌ | ❌ | ❌ | ❌ | Alpha | v1 | 1.0 |
|
||||
| [Memcached]({{< ref setup-memcached.md >}}) | ✅ | ❌ | ❌ | ✅ | ❌ | Alpha | v1 | 1.0 |
|
||||
| [MongoDB]({{< ref setup-mongodb.md >}}) | ✅ | ✅ | ✅ | ❌ | ✅ | Stable | v1 | 1.0 |
|
||||
| [MySQL]({{< ref setup-mysql.md >}}) | ✅ | ✅ | ✅ | ❌ | ✅ | Alpha | v1 | 1.0 |
|
||||
| [PostgreSQL]({{< ref setup-postgresql.md >}}) | ✅ | ✅ | ✅ | ❌ | ✅ | Alpha | v1 | 1.0 |
|
||||
| [Redis]({{< ref setup-redis.md >}}) | ✅ | ✅ | ✅ | ✅ | ✅ | Stable | v1 | 1.0 |
|
||||
| [RethinkDB]({{< ref setup-rethinkdb.md >}}) | ✅ | ✅ | ✅ | ❌ | ✅ | Alpha | v1 | 1.0 |
|
||||
| [Zookeeper]({{< ref setup-zookeeper.md >}}) | ✅ | ❌ | ✅ | ❌ | ❌ | Alpha | v1 | 1.0 |
|
||||
| Name |CRUD|Transactional|ETag| [TTL]({{< ref state-store-ttl.md >}}) | [Actors]({{< ref howto-actors.md >}}) | [Query]({{< ref howto-state-query-api.md >}}) | Status | Component version | Since |
|
||||
|----------------------------------------------------|----|-------------|----|----|----|----|-------|----|-----|
|
||||
| [Aerospike]({{< ref setup-aerospike.md >}}) | ✅ | ❌ | ✅ | ❌ | ❌ | ❌ | Alpha | v1 | 1.0 |
|
||||
| [Apache Cassandra]({{< ref setup-cassandra.md >}}) | ✅ | ❌ | ❌ | ✅ | ❌ | ❌ | Alpha | v1 | 1.0 |
|
||||
| [Cloudstate]({{< ref setup-cloudstate.md >}}) | ✅ | ❌ | ✅ | ❌ | ❌ | ❌ | Alpha | v1 | 1.0 |
|
||||
| [Couchbase]({{< ref setup-couchbase.md >}}) | ✅ | ❌ | ✅ | ❌ | ❌ | ❌ | Alpha | v1 | 1.0 |
|
||||
| [Hashicorp Consul]({{< ref setup-consul.md >}}) | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | Alpha | v1 | 1.0 |
|
||||
| [Hazelcast]({{< ref setup-hazelcast.md >}}) | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | Alpha | v1 | 1.0 |
|
||||
| [Memcached]({{< ref setup-memcached.md >}}) | ✅ | ❌ | ❌ | ✅ | ❌ | ❌ | Alpha | v1 | 1.0 |
|
||||
| [MongoDB]({{< ref setup-mongodb.md >}}) | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ | Stable | v1 | 1.0 |
|
||||
| [MySQL]({{< ref setup-mysql.md >}}) | ✅ | ✅ | ✅ | ❌ | ✅ | ❌ | Alpha | v1 | 1.0 |
|
||||
| [PostgreSQL]({{< ref setup-postgresql.md >}}) | ✅ | ✅ | ✅ | ❌ | ✅ | ❌ | Alpha | v1 | 1.0 |
|
||||
| [Redis]({{< ref setup-redis.md >}}) | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | Stable | v1 | 1.0 |
|
||||
| [RethinkDB]({{< ref setup-rethinkdb.md >}}) | ✅ | ✅ | ✅ | ❌ | ✅ | ❌ | Alpha | v1 | 1.0 |
|
||||
| [Zookeeper]({{< ref setup-zookeeper.md >}}) | ✅ | ❌ | ✅ | ❌ | ❌ | ❌ | Alpha | v1 | 1.0 |
|
||||
|
||||
|
||||
### Amazon Web Services (AWS)
|
||||
| Name | CRUD | Transactional | ETag | [TTL]({{< ref state-store-ttl.md >}}) | [Actors]({{< ref howto-actors.md >}}) | Status | Component version | Since |
|
||||
|------------------------------------------------------------------|------|---------------------|------|-----|--------|-----|-----|-------|
|
||||
| [AWS DynamoDB]({{< ref setup-dynamodb.md>}}) | ✅ | ❌ | ❌ | ❌ | ❌ | Alpha | v1 | 1.0 |
|
||||
| Name |CRUD|Transactional|ETag| [TTL]({{< ref state-store-ttl.md >}}) | [Actors]({{< ref howto-actors.md >}}) | [Query]({{< ref howto-state-query-api.md >}}) | Status | Component version | Since |
|
||||
|----------------------------------------------------|----|-------------|----|----|----|----|------|----|-----|
|
||||
| [AWS DynamoDB]({{< ref setup-dynamodb.md>}}) | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | Alpha | v1 | 1.0 |
|
||||
|
||||
### Google Cloud Platform (GCP)
|
||||
| Name | CRUD | Transactional | ETag | [TTL]({{< ref state-store-ttl.md >}}) | [Actors]({{< ref howto-actors.md >}}) | Status | Component version | Since |
|
||||
|------------------------------------------------------------------|------|---------------------|------|-----|--------|-----|-----|-------|
|
||||
| [GCP Firestore]({{< ref setup-firestore.md >}}) | ✅ | ❌ | ❌ | ❌ | ❌ | Alpha | v1 | 1.0 |
|
||||
| Name |CRUD|Transactional|ETag| [TTL]({{< ref state-store-ttl.md >}}) | [Actors]({{< ref howto-actors.md >}}) | [Query]({{< ref howto-state-query-api.md >}}) | Status | Component version | Since |
|
||||
|----------------------------------------------------|------|---------------|----|----|----|----|------|----|-----|
|
||||
| [GCP Firestore]({{< ref setup-firestore.md >}}) | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | Alpha | v1 | 1.0 |
|
||||
|
||||
### Microsoft Azure
|
||||
|
||||
| Name | CRUD | Transactional | ETag | [TTL]({{< ref state-store-ttl.md >}}) | [Actors]({{< ref howto-actors.md >}}) | Status | Component version | Since |
|
||||
|------------------------------------------------------------------|------|---------------------|------|-----|--------|-----|-----|-------|
|
||||
| [Azure Blob Storage]({{< ref setup-azure-blobstorage.md >}}) | ✅ | ❌ | ✅ | ❌ | ❌ | Stable | v1 | 1.0 |
|
||||
| [Azure CosmosDB]({{< ref setup-azure-cosmosdb.md >}}) | ✅ | ✅ | ✅ | ✅ | ✅ | Stable | v1 | 1.0 |
|
||||
| [Azure SQL Server]({{< ref setup-sqlserver.md >}}) | ✅ | ✅ | ✅ | ❌ | ✅ | Alpha | v1 | 1.0 |
|
||||
| [Azure Table Storage]({{< ref setup-azure-tablestorage.md >}}) | ✅ | ❌ | ✅ | ❌ | ❌ | Alpha | v1 | 1.0 |
|
||||
| Name |CRUD|Transactional|ETag| [TTL]({{< ref state-store-ttl.md >}}) | [Actors]({{< ref howto-actors.md >}}) | [Query]({{< ref howto-state-query-api.md >}}) | Status | Component version | Since |
|
||||
|------------------------------------------------------------------|----|-------------|----|----|----|----|-------|----|-----|
|
||||
| [Azure Blob Storage]({{< ref setup-azure-blobstorage.md >}}) | ✅ | ❌ | ✅ | ❌ | ❌ | ❌ | Stable | v1 | 1.0 |
|
||||
| [Azure CosmosDB]({{< ref setup-azure-cosmosdb.md >}}) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | Stable | v1 | 1.0 |
|
||||
| [Azure SQL Server]({{< ref setup-sqlserver.md >}}) | ✅ | ✅ | ✅ | ❌ | ✅ | ❌ | Stable | v1 | 1.5 |
|
||||
| [Azure Table Storage]({{< ref setup-azure-tablestorage.md >}}) | ✅ | ❌ | ✅ | ❌ | ❌ | ❌ | Alpha | v1 | 1.0 |
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ If you wish to use SQL server as an [actor state store]({{< ref "state_api.md#co
|
|||
| keyType | N | The type of key used. Defaults to `"string"` | `"string"`
|
||||
| keyLength | N | The max length of key. Used along with `"string"` keytype. Defaults to `"200"` | `"200"`
|
||||
| schema | N | The schema to use. Defaults to `"dbo"` | `"dapr"`,`"dbo"`
|
||||
| indexedProperties | N | List of IndexedProperties. | `"[{"ColumnName": "column", "Property": "property", "Type": "type"}]"`
|
||||
| indexedProperties | N | List of IndexedProperties. | `'[{"column": "transactionid", "property": "id", "type": "int"}, {"column": "customerid", "property": "customer", "type": "nvarchar(100)"}]'`
|
||||
| actorStateStore | N | Indicates that Dapr should configure this component for the actor state store ([more information]({{< ref "state_api.md#configuring-state-store-for-actors" >}})). | `"true"`
|
||||
|
||||
|
||||
|
|
@ -65,7 +65,7 @@ If you wish to use SQL server as an [actor state store]({{< ref "state_api.md#co
|
|||
|
||||
[Follow the instructions](https://docs.microsoft.com/azure/sql-database/sql-database-single-database-get-started?tabs=azure-portal) from the Azure documentation on how to create a SQL database. The database must be created before Dapr consumes it.
|
||||
|
||||
**Note: SQL Server state store also supports SQL Server running on VMs.**
|
||||
**Note: SQL Server state store also supports SQL Server running on VMs and in Docker.**
|
||||
|
||||
In order to setup SQL Server as a state store, you need the following properties:
|
||||
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
{{- if .Get "short" }}1.4{{ else if .Get "long" }}1.4.3{{ else if .Get "cli" }}1.4.0{{ else }}1.4.3{{ end -}}
|
||||
{{- if .Get "short" }}1.5{{ else if .Get "long" }}1.5.0{{ else if .Get "cli" }}1.5.0{{ else }}1.5.0{{ end -}}
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 88 KiB After Width: | Height: | Size: 191 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 205 KiB |
Loading…
Reference in New Issue