dapr
/
docs
mirror of https://github.com/dapr/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'v1.1' into harrykimpel-newrelic-howto

This commit is contained in:
Ori Zohar 2021-03-02 15:54:03 -08:00 committed by GitHub
parent da1e286013 112e9542c3
commit 8ec55f2fd3
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
31 changed files with 511 additions and 297 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

52
.github/workflows/azure-static-web-apps-black-water-03a7ce11e.yml vendored
View File

@ -1,52 +0,0 @@
name: Azure Static Web Apps CI/CD
on:
push:
branches:
- v1.0
pull_request:
types: [opened, synchronize, reopened, closed]
branches:
- v1.0
jobs:
build_and_deploy_job:
if: github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.action != 'closed')
runs-on: ubuntu-latest
name: Build and Deploy Job
steps:
- uses: actions/checkout@v2
with:
submodules: recursive
- name: Setup Docsy
run: cd daprdocs && git submodule update --init --recursive && sudo npm install -D --save autoprefixer && sudo npm install -D --save postcss-cli
- name: Build And Deploy
id: builddeploy
uses: Azure/static-web-apps-deploy@v0.0.1-preview
env:
HUGO_ENV: production
HUGO_VERSION: "0.74.3"
with:
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_BLACK_WATER_03A7CE11E }}
repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments)
skip_deploy_on_missing_secrets: true
action: "upload"
###### Repository/Build Configurations - These values can be configured to match you app requirements. ######
app_location: "daprdocs" # App source code path
api_location: "api" # Api source code path - optional
app_artifact_location: 'public' # Built app content directory - optional
app_build_command: "hugo"
###### End of Repository/Build Configurations ######
close_pull_request_job:
if: github.event_name == 'pull_request' && github.event.action == 'closed'
runs-on: ubuntu-latest
name: Close Pull Request Job
steps:
- name: Close Pull Request
id: closepullrequest
uses: Azure/static-web-apps-deploy@v0.0.1-preview
with:
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_BLACK_WATER_03A7CE11E }}
skip_deploy_on_missing_secrets: true
action: "close"

52
.github/workflows/azure-static-web-apps-kind-pond-0f48cbe1e.yml vendored
View File

@ -1,52 +0,0 @@
name: Azure Static Web Apps CI/CD
on:
push:
branches:
- v1.0-rc3
pull_request:
types: [opened, synchronize, reopened, closed]
branches:
- v1.0-rc3
jobs:
build_and_deploy_job:
if: github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.action != 'closed')
runs-on: ubuntu-latest
name: Build and Deploy Job
steps:
- uses: actions/checkout@v2
with:
submodules: recursive
- name: Setup Docsy
run: cd daprdocs && git submodule update --init --recursive && sudo npm install -D --save autoprefixer && sudo npm install -D --save postcss-cli
- name: Build And Deploy
id: builddeploy
uses: Azure/static-web-apps-deploy@v0.0.1-preview
env:
HUGO_ENV: production
HUGO_VERSION: "0.74.3"
with:
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_KIND_POND_0F48CBE1E }}
repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments)
skip_deploy_on_missing_secrets: true
action: "upload"
###### Repository/Build Configurations - These values can be configured to match you app requirements. ######
app_location: "daprdocs" # App source code path
api_location: "api" # Api source code path - optional
app_artifact_location: 'public' # Built app content directory - optional
app_build_command: "hugo"
###### End of Repository/Build Configurations ######
close_pull_request_job:
if: github.event_name == 'pull_request' && github.event.action == 'closed'
runs-on: ubuntu-latest
name: Close Pull Request Job
steps:
- name: Close Pull Request
id: closepullrequest
uses: Azure/static-web-apps-deploy@v0.0.1-preview
with:
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_KIND_POND_0F48CBE1E }}
skip_deploy_on_missing_secrets: true
action: "close"

54
.github/workflows/azure-static-web-apps-polite-bush-0f42b0a1e.yml vendored
View File

@ -1,54 +0,0 @@
name: Azure Static Web Apps CI/CD
on:
push:
branches:
- v1.0-rc2
pull_request:
types: [opened, synchronize, reopened, closed]
branches:
- v1.0-rc2
jobs:
build_and_deploy_job:
if: github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.action != 'closed')
runs-on: ubuntu-latest
name: Build and Deploy Job
steps:
- uses: actions/checkout@v2
with:
submodules: recursive
- name: Setup Docsy
run: cd daprdocs && git submodule update --init --recursive && sudo npm install -D --save autoprefixer && sudo npm install -D --save postcss-cli
- name: Build And Deploy
id: builddeploy
uses: Azure/static-web-apps-deploy@v0.0.1-preview
env:
HUGO_ENV: production
HUGO_VERSION: "0.74.3"
with:
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_POLITE_BUSH_0F42B0A1E }}
repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments)
skip_deploy_on_missing_secrets: true
action: "upload"
###### Repository/Build Configurations - These values can be configured to match you app requirements. ######
# For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig
app_location: "daprdocs" # App source code path
api_location: "api" # Api source code path - optional
app_artifact_location: 'public' # Built app content directory - optional
app_build_command: "hugo"
###### End of Repository/Build Configurations ######
close_pull_request_job:
if: github.event_name == 'pull_request' && github.event.action == 'closed'
runs-on: ubuntu-latest
name: Close Pull Request Job
steps:
- name: Close Pull Request
id: closepullrequest
uses: Azure/static-web-apps-deploy@v0.0.1-preview
with:
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_POLITE_BUSH_0F42B0A1E }}
skip_deploy_on_missing_secrets: true
action: "close"

12
.github/workflows/azure-static-web-apps-green-hill-0d7377310.yml → .github/workflows/azure-static-web-apps-yellow-river-084fe4e1e.yml vendored
View File

@ -3,11 +3,11 @@ name: Azure Static Web Apps CI/CD
on:
push:
branches:
- v0.11
- v1.1
pull_request:
types: [opened, synchronize, reopened, closed]
branches:
- v0.11
- v1.1
jobs:
build_and_deploy_job:
@ -27,15 +27,15 @@ jobs:
HUGO_ENV: production
HUGO_VERSION: "0.74.3"
with:
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_GREEN_HILL_0D7377310 }}
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_YELLOW_RIVER_084FE4E1E }}
repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments)
skip_deploy_on_missing_secrets: true
action: "upload"
###### Repository/Build Configurations - These values can be configured to match you app requirements. ######
# For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig
app_location: "daprdocs" # App source code path
app_location: "/daprdocs" # App source code path
api_location: "api" # Api source code path - optional
app_artifact_location: 'public' # Built app content directory - optional
output_location: "public" # Built app content directory - optional
app_build_command: "hugo"
###### End of Repository/Build Configurations ######
@ -48,6 +48,6 @@ jobs:
id: closepullrequest
uses: Azure/static-web-apps-deploy@v0.0.1-preview
with:
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_GREEN_HILL_0D7377310 }}
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_YELLOW_RIVER_084FE4E1E }}
skip_deploy_on_missing_secrets: true
action: "close"

2
daprdocs/config.toml
View File

@ -1,5 +1,5 @@
# Site Configuration
baseURL = "https://v1-0.docs.dapr.io/"
baseURL = "https://docs.dapr.io/"
title = "Dapr Docs"
theme = "docsy"
disableFastRender = true

2
daprdocs/content/en/concepts/faq.md
View File

@ -29,7 +29,7 @@ Read [How does Dapr work with service meshes?](https://github.com/dapr/dapr/wiki
Istio is not a programming model and does not focus on application level features such as state management, pub-sub, bindings etc. That is where Dapr comes in.
## Performance Benchmarks
The Dapr project is focused on performance due to the inherent discussion of Dapr being a sidecar to your application. This [performance benchmark video](https://youtu.be/4kV3SHs1j2k?t=783) discusses and demos the work that has been done so far. The performance benchmark data is planned to be published on a regular basis. You can also run the perf tests in your own environment to get perf numbers.
The Dapr project is focused on performance due to the inherent discussion of Dapr being a sidecar to your application. See [here]({{< ref perf-service-invocation.md >}}) for updated performance numbers.
## Actors

4
daprdocs/content/en/concepts/overview.md
View File

@ -62,7 +62,7 @@ In container hosting environments such as Kubernetes, Dapr runs as a side-car co
## Developer language SDKs and frameworks
To make using Dapr more natural for different languages, it also includes [language specific SDKs]({{<ref sdks>}}) for Go, Java, JavaScript, .NET, PHP and Python. These SDKs expose the functionality in the Dapr building blocks, such as saving state, publishing an event or creating an actor, through a typed, language API rather than calling the http/gRPC API. This enables you to write a combination of stateless and stateful functions and actors all in the language of their choice. And because these SDKs share the Dapr runtime, you get cross-language actor and functions support.
To make using Dapr more natural for different languages, it also includes [language specific SDKs]({{<ref sdks>}}) for C++, Go, Java, JavaScript, Python, Rust .NET and PHP. These SDKs expose the functionality in the Dapr building blocks, such as saving state, publishing an event or creating an actor, through a typed, language API rather than calling the http/gRPC API. This enables you to write a combination of stateless and stateful functions and actors all in the language of their choice. And because these SDKs share the Dapr runtime, you get cross-language actor and functions support.
### SDKs
@ -81,7 +81,7 @@ To make using Dapr more natural for different languages, it also includes [langu
Dapr can be used from any developer framework. Here are some that have been integrated with Dapr.
#### Web
In the Dapr [.NET SDK](https://github.com/dapr/dotnet-sdk) you can find ASP.NET Core integration, which brings stateful routing controllers that respond to pub/sub events from other services.
In the Dapr [.NET SDK](https://github.com/dapr/dotnet-sdk) you can find [ASP.NET Core](https://dotnet.microsoft.com/apps/aspnet) integration, which brings stateful routing controllers that respond to pub/sub events from other services.
In the Dapr [Java SDK](https://github.com/dapr/java-sdk) you can find [Spring Boot](https://spring.io/) integration.

2
daprdocs/content/en/contributing/contributing-docs.md
View File

@ -128,7 +128,7 @@ As an example, for this specific section the complete reference to the page and
```
### Images
The markdown spec used by Docsy and Hugo does not give an option to resize images using markdown notation. Instead, raw HMTL is used.
The markdown spec used by Docsy and Hugo does not give an option to resize images using markdown notation. Instead, raw HTML is used.
Begin by placing images under `/daprdocs/static/images` with the naming convention of `[page-name]-[image-name].[png|jpg|svg]`.

4
daprdocs/content/en/developing-applications/building-blocks/state-management/howto-get-save-state.md
View File

@ -77,7 +77,7 @@ dapr run --app-id myapp --dapr-http-port 3500
Then in a separate terminal save a key/value pair into your statestore:
```bash
curl -X POST -H "Content-Type: application/json" -d '{ "key": "key1", "value": "value1"}' http://localhost:3500/v1.0/state/statestore
curl -X POST -H "Content-Type: application/json" -d '[{ "key": "key1", "value": "value1"}]' http://localhost:3500/v1.0/state/statestore
```
Now get the state you just saved:
@ -98,7 +98,7 @@ dapr --app-id myapp --port 3500 run
Then in a separate terminal save a key/value pair into your statestore:
```powershell
Invoke-RestMethod -Method Post -ContentType 'application/json' -Body '{"key": "key1", "value": "value1"}' -Uri 'http://localhost:3500/v1.0/state/statestore'
Invoke-RestMethod -Method Post -ContentType 'application/json' -Body '[{"key": "key1", "value": "value1"}]' -Uri 'http://localhost:3500/v1.0/state/statestore'
```
Now get the state you just saved:

16
daprdocs/content/en/developing-applications/middleware/supported-middleware/_index.md
View File

@ -9,11 +9,11 @@ no_list: true
### HTTP
| Name | Description | Status |
|--------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------|----------------------------|
| [Rate limit]({{< ref middleware-rate-limit.md >}}) | Restricts the maximum number of allowed HTTP requests per second | Alpha |
| [OAuth2]({{< ref middleware-oauth2.md >}}) | Enables the [OAuth2 Authorization Grant flow](https://tools.ietf.org/html/rfc6749#section-4.1) on a Web API | Alpha |
| [OAuth2 client credentials]({{< ref middleware-oauth2clientcredentials.md >}}) | Enables the [OAuth2 Client Credentials Grant flow](https://tools.ietf.org/html/rfc6749#section-4.4) on a Web API | Alpha |
| [Bearer]({{< ref middleware-bearer.md >}}) | Verifies a [Bearer Token](https://tools.ietf.org/html/rfc6750) using [OpenID Connect](https://openid.net/connect/) on a Web API | Alpha |
| [Open Policy Agent]({{< ref middleware-opa.md >}}) | Applies [Rego/OPA Policies](https://www.openpolicyagent.org/) to incoming Dapr HTTP requests | Alpha |
| [Uppercase]({{< ref middleware-uppercase.md >}}) | Converts the body of the request to uppercase letters | GA (For local development) |
| Name | Description | Status | Component version |
|------------|----------------|-----------|--------------------|
| [Rate limit]({{< ref middleware-rate-limit.md >}}) | Restricts the maximum number of allowed HTTP requests per second | Alpha | v1|
| [OAuth2]({{< ref middleware-oauth2.md >}}) | Enables the [OAuth2 Authorization Grant flow](https://tools.ietf.org/html/rfc6749#section-4.1) on a Web API | Alpha | v1|
| [OAuth2 client credentials]({{< ref middleware-oauth2clientcredentials.md >}}) | Enables the [OAuth2 Client Credentials Grant flow](https://tools.ietf.org/html/rfc6749#section-4.4) on a Web API | Alpha | v1|
| [Bearer]({{< ref middleware-bearer.md >}}) | Verifies a [Bearer Token](https://tools.ietf.org/html/rfc6750) using [OpenID Connect](https://openid.net/connect/) on a Web API | Alpha | v1|
| [Open Policy Agent]({{< ref middleware-opa.md >}}) | Applies [Rego/OPA Policies](https://www.openpolicyagent.org/) to incoming Dapr HTTP requests | Alpha | v1|
| [Uppercase]({{< ref middleware-uppercase.md >}}) | Converts the body of the request to uppercase letters | GA (For local development) | v1|

1
daprdocs/content/en/developing-applications/middleware/supported-middleware/middleware-rate-limit.md
View File

@ -18,6 +18,7 @@ metadata:
name: ratelimit
spec:
type: middleware.http.ratelimit
version: v1
metadata:
- name: maxRequestsPerSecond
value: 10

2
daprdocs/content/en/developing-applications/middleware/supported-middleware/middleware-uppercase.md
View File

@ -11,6 +11,7 @@ The uppercase [HTTP middleware]({{< ref middleware-concept.md >}}) converts the
## Component format
In the following definition, the maximum requests per second are set to 10:
```yaml
apiVersion: dapr.io/v1alpha1
kind: Component
@ -18,6 +19,7 @@ metadata:
name: uppercase
spec:
type: middleware.http.uppercase
version: v1
```
This component has no `metadata` to configure.

4
daprdocs/content/en/getting-started/get-started-api.md
View File

@ -42,7 +42,7 @@ Invoke-RestMethod -Method Post -ContentType 'application/json' -Body '[{ "key":
{{< /tabs >}}
## Step 2: Get state
## Step 3: Get state
Now get the state you just stored using a key with the state management API:
@ -64,7 +64,7 @@ Invoke-RestMethod -Uri 'http://localhost:3500/v1.0/state/statestore/name'
{{< /tabs >}}
## Step 3: See how the state is stored in Redis
## Step 4: See how the state is stored in Redis
You can look in the Redis container and verify Dapr is using it as a state store. Run the following to use the Redis CLI:

89
daprdocs/content/en/operations/components/certification-lifecycle.md Normal file
View File

@ -0,0 +1,89 @@
---
type: docs
title: "Certification lifecycle"
linkTitle: "Certification lifecycle"
weight: 200
description: "The component certification lifecycle from submission to production ready"
---
## Overview
Dapr uses a modular design where functionality is delivered as a component. Each component has an interface definition. All of the components are pluggable so that in ideal scenarios, you can swap out one component with the same interface for another. Each component that is used in production, needs to maintain a certain set of technical requirements that ensure the functional compatibility and robustness of the component.
In general a component needs to be:
- compliant with the defined Dapr interfaces
- functionally correct and robust
- well documented and maintained
To make sure a component conforms to the standards set by Dapr, there are a set of tests run against a component in a Dapr maintainers managed environment. Once the tests pass consistently, the maturity level can be determined for a component.
## Certification levels
The levels are as follows:
- [Alpha](#alpha)
- [Beta](#beta)
- [General availability (GA)](#general-availability-ga)
### Alpha
- The component implements the required interface and works as described in the specification
- The component has documentation
- The component might be buggy or might expose bugs on integration
- The component may not pass all conformance tests
- The component may not have conformance tests
- Recommended for only non-business-critical uses because of potential for incompatible changes in subsequent releases
All components start at the Alpha stage.
### Beta
- The component must pass all the component conformance tests defined to satisfy the component specification
- The component conformance tests have been run in a Dapr maintainers managed environment
- The component contains a record of the conformance test result reviewed and approved by Dapr maintainers with specific components-contrib version
- Recommended for only non-business-critical uses because of potential for incompatible changes in subsequent releases
### General Availability (GA)
- Has at least two different users using the component in production
- A GA component has a maintainer in the Dapr community or the Dapr maintainers
- The component is well documented, tested and maintained across multiple versions of components-contrib repo
## Conformance tests
Each component in the [components-contrib](https://github.com/dapr/components-contrib) repository needs to adhere to a set of interfaces defined by Dapr. Conformance tests are tests that are run on these component definitions with their associated backing services such that the component is tested to be conformant with the Dapr interface specifications and behavior.
The conformance tests are defined for the following building blocks:
- State store
- Secret store
- Bindings
- Pub/Sub
To understand more about them see the readme [here](https://github.com/dapr/components-contrib/blob/master/tests/conformance/README.md).
### Test requirements
- The tests should validate the functional behavior and robustness of component based on the component specification
- All the details needed to reproduce the tests are added as part of the component conformance test documentation
## Component certification process
For a component to be certified tests are run in an environment maintained by the Dapr team.
### New component certification: Alpha->Beta or Beta->GA
For a new component requiring a certification change from Alpha to Beta or Beta to GA, a request for component certification follows these steps:
- An issue is created with a request for certification of the component with the current and the new certification levels
- A user of a component submits a PR for integrating the component to run with the defined conformance test suite
- The user details the environment setup in the issue created, so that a Dapr maintainer can setup the service in a managed environment
- After the environment setup is complete, Dapr maintainers review the PR and if approved merges that PR
- Dapr maintainers review functional correctness with the test being run in an environment maintained by the Dapr team
- Dapr maintainers update the component status document categorized by Dapr Runtime version. This is done as part of the release process in the next release of Dapr runtime
### Existing GA certified component
For an existing GA certified component, conformance test should be run against any changes made to component code or the backing service version or the client version.
In the scenarios where a component version is updated, the component again starts from Alpha stage and then the new component certification is followed for that.

2
daprdocs/content/en/operations/components/component-scopes.md
View File

@ -2,7 +2,7 @@
type: docs
title: "How-To: Scope components to one or more applications"
linkTitle: "How-To: Set component scopes"
weight: 200
weight: 300
description: "Limit component access to particular Dapr instances"
---

2
daprdocs/content/en/operations/components/component-secrets.md
View File

@ -2,7 +2,7 @@
type: docs
title: "How-To: Reference secrets in components"
linkTitle: "How-To: Reference secrets"
weight: 300
weight: 400
description: "How to securly reference secrets from a component definition"
---

91
daprdocs/content/en/operations/components/setup-bindings/supported-bindings/_index.md
View File

@ -3,30 +3,43 @@ type: docs
title: "Supported external bindings"
linkTitle: "Supported bindings"
weight: 200
description: The supported external systems that interface with Dapr as input/output bindings
description: The supported external bindings that interface with Dapr
no_list: true
---
Every binding has its own unique set of properties. Click the name link to see the component YAML for each binding.
Table captions:
> `Status`: [Component certification]({{<ref "certification-lifecycle.md">}}) status
- [Alpha]({{<ref "certification-lifecycle.md#alpha">}})
- [Beta]({{<ref "certification-lifecycle.md#beta">}})
- [GA]({{<ref "certification-lifecycle.md#general-availability-ga">}})
> `Since`: defines from which Dapr Runtime version, the component is in the current status
> `Component version`: defines the version of the component
### Generic
| Name | Input<br>Binding | Output<br>Binding | Status |
|------|:----------------:|:-----------------:|--------|
| [Apple Push Notifications (APN)]({{< ref apns.md >}}) | | ✅ | Alpha |
| [Cron (Scheduler)]({{< ref cron.md >}}) | ✅ | ✅ | Alpha |
| [HTTP]({{< ref http.md >}}) | | ✅ | Alpha |
| [InfluxDB]({{< ref influxdb.md >}}) | | ✅ | Alpha |
| [Kafka]({{< ref kafka.md >}}) | ✅ | ✅ | Alpha |
| [Kubernetes Events]({{< ref "kubernetes-binding.md" >}}) | ✅ | | Alpha |
| [MQTT]({{< ref mqtt.md >}}) | ✅ | ✅ | Alpha |
| [MySQL]({{< ref mysql.md >}}) | | ✅ | Alpha |
| [PostgreSql]({{< ref postgres.md >}}) | | ✅ | Alpha |
| [Postmark]({{< ref postmark.md >}}) | | ✅ | Alpha |
| [RabbitMQ]({{< ref rabbitmq.md >}}) | ✅ | ✅ | Alpha |
| [Redis]({{< ref redis.md >}}) | | ✅ | Alpha |
| [SMTP]({{< ref smtp.md >}}) | | ✅ | Alpha |
| [Twilio]({{< ref twilio.md >}}) | | ✅ | Alpha |
| [Twitter]({{< ref twitter.md >}}) | ✅ | ✅ | Alpha |
| [SendGrid]({{< ref sendgrid.md >}}) | | ✅ | Alpha |
| Name | Input<br>Binding | Output<br>Binding | Status | Component version | Since runtime version |
|------|:----------------:|:-----------------:|--------|-------- | ---------|
| [Apple Push Notifications (APN)]({{< ref apns.md >}}) | | ✅ | Alpha | v1 | 1.0 |
| [Cron (Scheduler)]({{< ref cron.md >}}) | ✅ | ✅ | Alpha | v1 | 1.0 |
| [HTTP]({{< ref http.md >}}) | | ✅ | GA | v1 | 1.0 |
| [InfluxDB]({{< ref influxdb.md >}}) | | ✅ | Alpha | v1 | 1.0 |
| [Kafka]({{< ref kafka.md >}}) | ✅ | ✅ | Alpha | v1 | 1.0 |
| [Kubernetes Events]({{< ref "kubernetes-binding.md" >}}) | ✅ | | Alpha | v1 | 1.0 |
| [MQTT]({{< ref mqtt.md >}}) | ✅ | ✅ | Alpha | v1 | 1.0 |
| [MySQL]({{< ref mysql.md >}}) | | ✅ | Alpha | v1 | 1.0 |
| [PostgreSql]({{< ref postgres.md >}}) | | ✅ | Alpha | v1 | 1.0 |
| [Postmark]({{< ref postmark.md >}}) | | ✅ | Alpha | v1 | 1.0 |
| [RabbitMQ]({{< ref rabbitmq.md >}}) | ✅ | ✅ | Alpha | v1 | 1.0 |
| [Redis]({{< ref redis.md >}}) | | ✅ | Alpha | v1 | 1.0 |
| [SMTP]({{< ref smtp.md >}}) | | ✅ | Alpha | v1 | 1.0 |
| [Twilio]({{< ref twilio.md >}}) | | ✅ | Alpha | v1 | 1.0 |
| [Twitter]({{< ref twitter.md >}}) | ✅ | ✅ | Alpha | v1 | 1.0 |
| [SendGrid]({{< ref sendgrid.md >}}) | | ✅ | Alpha | v1 | 1.0 |
### Alibaba Cloud
@ -36,29 +49,29 @@ no_list: true
### Amazon Web Services (AWS)
| Name | Input<br>Binding | Output<br>Binding | Status |
|------|:----------------:|:-----------------:|--------|
| [AWS DynamoDB]({{< ref dynamodb.md >}}) | | ✅ | Alpha |
| [AWS S3]({{< ref s3.md >}}) | | ✅ | Alpha |
| [AWS SNS]({{< ref sns.md >}}) | | ✅ | Alpha |
| [AWS SQS]({{< ref sqs.md >}}) | ✅ | ✅ | Alpha |
| [AWS Kinesis]({{< ref kinesis.md >}}) | ✅ | ✅ | Alpha |
| Name | Input<br>Binding | Output<br>Binding | Status | Component version | Since |
|------|:----------------:|:-----------------:|--------| ------ |----------|
| [AWS DynamoDB]({{< ref dynamodb.md >}}) | | ✅ | Alpha | v1 | 1.0 |
| [AWS S3]({{< ref s3.md >}}) | | ✅ | Alpha | v1 | 1.0 |
| [AWS SNS]({{< ref sns.md >}}) | | ✅ | Alpha | v1 | 1.0 |
| [AWS SQS]({{< ref sqs.md >}}) | ✅ | ✅ | Alpha | v1 | 1.0 |
| [AWS Kinesis]({{< ref kinesis.md >}}) | ✅ | ✅ | Alpha | v1 | 1.0 |
### Google Cloud Platform (GCP)
| Name | Input<br>Binding | Output<br>Binding | Status |
|------|:----------------:|:-----------------:|--------|
| [GCP Cloud Pub/Sub]({{< ref gcppubsub.md >}}) | ✅ | ✅ | Alpha |
| [GCP Storage Bucket]({{< ref gcpbucket.md >}}) | | ✅ | Alpha |
| Name | Input<br>Binding | Output<br>Binding | Status | Component version | Since |
|------|:----------------:|:-----------------:|--------| ------ | ---------- |
| [GCP Cloud Pub/Sub]({{< ref gcppubsub.md >}}) | ✅ | ✅ | Alpha | v1 | 1.0 |
| [GCP Storage Bucket]({{< ref gcpbucket.md >}}) | | ✅ | Alpha | v1 | 1.0 |
### Microsoft Azure
| Name | Input<br>Binding | Output<br>Binding | Status |
|------|:----------------:|:-----------------:|--------|
| [Azure Blob Storage]({{< ref blobstorage.md >}}) | | ✅ | Alpha |
| [Azure CosmosDB]({{< ref cosmosdb.md >}}) | | ✅ | Alpha |
| [Azure Event Grid]({{< ref eventgrid.md >}}) | ✅ | ✅ | Alpha |
| [Azure Event Hubs]({{< ref eventhubs.md >}}) | ✅ | ✅ | Alpha |
| [Azure Service Bus Queues]({{< ref servicebusqueues.md >}}) | ✅ | ✅ | Alpha |
| [Azure SignalR]({{< ref signalr.md >}}) | | ✅ | Alpha |
| [Azure Storage Queues]({{< ref storagequeues.md >}}) | ✅ | ✅ | Alpha |
| Name | Input<br>Binding | Output<br>Binding | Status | Component version | Since |
|------|:----------------:|:-----------------:|--------| --------- | ---------- |
| [Azure Blob Storage]({{< ref blobstorage.md >}}) | | ✅ | Alpha | v1 | 1.0 |
| [Azure CosmosDB]({{< ref cosmosdb.md >}}) | | ✅ | Alpha | v1 | 1.0 |
| [Azure Event Grid]({{< ref eventgrid.md >}}) | ✅ | ✅ | Alpha | v1 | 1.0 |
| [Azure Event Hubs]({{< ref eventhubs.md >}}) | ✅ | ✅ | Alpha | v1 | 1.0 |
| [Azure Service Bus Queues]({{< ref servicebusqueues.md >}}) | ✅ | ✅ | Alpha | v1 | 1.0 |
| [Azure SignalR]({{< ref signalr.md >}}) | | ✅ | Alpha | v1 | 1.0 |
| [Azure Storage Queues]({{< ref storagequeues.md >}}) | ✅ | ✅ | GA | v1 | 1.0 |

51
daprdocs/content/en/operations/components/setup-pubsub/supported-pubsub/_index.md
View File

@ -1,39 +1,48 @@
---
type: docs
title: "Supported pub/sub components"
linkTitle: "Supported pub/sub"
title: "Supported pub/sub brokers"
linkTitle: "Supported pub/sub brokers"
weight: 30000
description: The supported pub/sub brokers that interface with Dapr
no_list: true
---
Table captions:
> `Status`: [Component certification]({{<ref "certification-lifecycle.md">}}) status
- [Alpha]({{<ref "certification-lifecycle.md#alpha">}})
- [Beta]({{<ref "certification-lifecycle.md#beta">}})
- [GA]({{<ref "certification-lifecycle.md#general-availability-ga">}})
> `Since`: defines from which Dapr Runtime version, the component is in the current status
> `Component version`: defines the version of the component
### Generic
| Name | Status |
|-------------------------------------------------------|--------|
| [Apache Kafka]({{< ref setup-apache-kafka.md >}}) | Alpha |
| [Hazelcast]({{< ref setup-hazelcast.md >}}) | Alpha |
| [MQTT]({{< ref setup-mqtt.md >}}) | Alpha |
| [NATS Streaming]({{< ref setup-nats-streaming.md >}}) | Alpha |
| [Pulsar]({{< ref setup-pulsar.md >}}) | Alpha |
| [RabbitMQ]({{< ref setup-rabbitmq.md >}}) | Alpha |
| [Redis Streams]({{< ref setup-redis-pubsub.md >}}) | Alpha |
| Name | Status | Component version | Since |
|-------------------------------------------------------|--------| -----| ------------- |
| [Apache Kafka]({{< ref setup-apache-kafka.md >}}) | Beta | v1 | 1.0 |
| [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 |
| [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 >}}) | GA | v1 | 1.0 |
### Amazon Web Services (AWS)
| Name | Status |
|---------------------------------------------------|--------|
| [AWS SNS/SQS]({{< ref setup-aws-snssqs.md >}}) | Alpha |
| Name | Status | Component version | Since |
|---------------------------------------------------|--------| ---- |---------------|
| [AWS SNS/SQS]({{< ref setup-aws-snssqs.md >}}) | Alpha | v1 | 1.0 |
### Google Cloud Platform (GCP)
| Name | Status |
|---------------------------------------------------|--------|
| [GCP Pub/Sub]({{< ref setup-gcp-pubsub.md >}}) | Alpha |
| Name | Status | Component version | Since |
|---------------------------------------------------|--------| ---- | --------------|
| [GCP Pub/Sub]({{< ref setup-gcp-pubsub.md >}}) | Alpha | v1 | 1.0 |
### Microsoft Azure
| Name | Status |
|-----------------------------------------------------------|--------|
| [Azure Events Hub]({{< ref setup-azure-eventhubs.md >}}) | Alpha |
| [Azure Service Bus]({{< ref setup-azure-servicebus.md >}})| Alpha |
| Name | Status | Component version | Since |
|-----------------------------------------------------------|--------| ----------------| -- |
| [Azure Events Hub]({{< ref setup-azure-eventhubs.md >}}) | Alpha | v1 | 1.0 |
| [Azure Service Bus]({{< ref setup-azure-servicebus.md >}})| GA | v1 | 1.0 |

4
daprdocs/content/en/operations/components/setup-pubsub/supported-pubsub/setup-rabbitmq.md
View File

@ -33,7 +33,7 @@ spec:
value: "0"
- name: reconnectWait
value: "0"
- name: concurrency
- name: concurrencyMode
value: parallel
```
{{% alert title="Warning" color="warning" %}}
@ -52,7 +52,7 @@ The above example uses secrets as plain strings. It is recommended to use a secr
| requeueInFailure | N | Whether or not to requeue when sending a [negative acknolwedgement](https://www.rabbitmq.com/nack.html) in case of a failure. Defaults to `"false"` | `"true"`, `"false"`
| prefetchCount | N | Number of messages to [prefecth](https://www.rabbitmq.com/consumer-prefetch.html). Consider changing this to a non-zero value for production environments. Defaults to `"0"`, which means that all available messages will be pre-fetched. | `"2"`
| reconnectWait | N | How long to wait (in seconds) before reconnecting if a connection failure occurs | `"0"`
| concurrency | N | `paralell` is the default, and allows processing multiple messages in paralell (limited by the `app-max-concurrency` annotation, if configured). Set to `single` to disable paralell processing. In most situations there's no reason to change this. | `paralell`, `single`
| concurrencyMode | N | `parallel` is the default, and allows processing multiple messages in parallel (limited by the `app-max-concurrency` annotation, if configured). Set to `single` to disable parallel processing. In most situations there's no reason to change this. | `parallel`, `single`
## Create a RabbitMQ server

42
daprdocs/content/en/operations/components/setup-secret-store/supported-secret-stores/_index.md
View File

@ -7,30 +7,40 @@ description: The supported secret stores that interface with Dapr
no_list: true
---
Table captions:
> `Status`: [Component certification]({{<ref "certification-lifecycle.md">}}) status
- [Alpha]({{<ref "certification-lifecycle.md#alpha">}})
- [Beta]({{<ref "certification-lifecycle.md#beta">}})
- [GA]({{<ref "certification-lifecycle.md#general-availability-ga">}})
> `Since`: defines from which Dapr Runtime version, the component is in the current status
> `Component version`: defines the version of the component
### Generic
| Name | Status |
|-------------------------------------------------------------------|------------------------------|
| [Local environment variables]({{< ref envvar-secret-store.md >}}) | GA (For local development) |
| [Local file]({{< ref file-secret-store.md >}}) | GA (For local development) |
| [HashiCorp Vault]({{< ref hashicorp-vault.md >}}) | Alpha |
| [Kubernetes secrets]({{< ref kubernetes-secret-store.md >}}) | Alpha |
| 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 |
| [HashiCorp Vault]({{< ref hashicorp-vault.md >}}) | Alpha | v1 | 1.0 |
| [Kubernetes secrets]({{< ref kubernetes-secret-store.md >}}) | GA | v1 | 1.0 |
### Amazon Web Services (AWS)
| Name | Status |
|----------------------------------------------------------|--------|
| [AWS Secrets Manager]({{< ref aws-secret-manager.md >}}) | Alpha |
| Name | Status | Component version | Since |
|----------------------------------------------------------|--------| -------------------| ---- |
| [AWS Secrets Manager]({{< ref aws-secret-manager.md >}}) | Alpha | v1 | 1.0 |
### Google Cloud Platform (GCP)
| Name | Status |
|----------------------------------------------------------|--------|
| [GCP Secret Manager]({{< ref gcp-secret-manager.md >}}) | Alpha |
| Name | Status | Component version | Since |
|----------------------------------------------------------|--------| ---- | ------------|
| [GCP Secret Manager]({{< ref gcp-secret-manager.md >}}) | Alpha | v1 | 1.0 |
### Microsoft Azure
| Name | Status |
|---------------------------------------------------------------------------------------|--------|
| [Azure Key Vault w/ Managed Identity]({{< ref azure-keyvault-managed-identity.md >}}) | Alpha |
| [Azure Key Vault]({{< ref azure-keyvault.md >}}) | Alpha |
| Name | Status | Component version | Since |
|---------------------------------------------------------------------------------------|--------| ---- |--------------|
| [Azure Key Vault w/ Managed Identity]({{< ref azure-keyvault-managed-identity.md >}}) | Alpha | v1 | 1.0 |
| [Azure Key Vault]({{< ref azure-keyvault.md >}}) | GA | v1 | 1.0 |

71
daprdocs/content/en/operations/components/setup-state-store/supported-state-stores/_index.md
View File

@ -1,45 +1,58 @@
---
type: docs
title: "Supported stores"
linkTitle: "Supported stores"
title: "Supported state stores"
linkTitle: "Supported state stores"
description: "The supported state stores that interface with Dapr"
weight: 20000
no_list: true
---
Table captions:
> `Status`: [Component certification]({{<ref "certification-lifecycle.md">}}) status
- [Alpha]({{<ref "certification-lifecycle.md#alpha">}})
- [Beta]({{<ref "certification-lifecycle.md#beta">}})
- [GA]({{<ref "certification-lifecycle.md#general-availability-ga">}})
> `Since`: defines from which Dapr Runtime version, the component is in the current status
> `Component version`: defines the version of the component
The following stores are supported, at various levels, by the Dapr state management building block:
### Generic
| Name | CRUD | Transactional </br>(Supports Actors) | ETag | Status |
|----------------------------------------------------------------|------|---------------------|------|--------|
| [Aerospike]({{< ref setup-aerospike.md >}}) | ✅ | ❌ | ✅ | Alpha |
| [Apache Cassandra]({{< ref setup-cassandra.md >}}) | ✅ | ❌ | ❌ | Alpha |
| [Cloudstate]({{< ref setup-cloudstate.md >}}) | ✅ | ❌ | ✅ | Alpha |
| [Couchbase]({{< ref setup-couchbase.md >}}) | ✅ | ❌ | ✅ | Alpha |
| [Hashicorp Consul]({{< ref setup-consul.md >}}) | ✅ | ❌ | ❌ | Alpha |
| [Hazelcast]({{< ref setup-hazelcast.md >}}) | ✅ | ❌ | ❌ | Alpha |
| [Memcached]({{< ref setup-memcached.md >}}) | ✅ | ❌ | ❌ | Alpha |
| [MongoDB]({{< ref setup-mongodb.md >}}) | ✅ | ✅ | ❌ | Alpha |
| [MySQL]({{< ref setup-mysql.md >}}) | ✅ | ✅ | ✅ | Alpha |
| [PostgreSQL]({{< ref setup-postgresql.md >}}) | ✅ | ✅ | ✅ | Alpha |
| [Redis]({{< ref setup-redis.md >}}) | ✅ | ✅ | ✅ | Alpha |
| [RethinkDB]({{< ref setup-rethinkdb.md >}}) | ✅ | ✅ | ✅ | Alpha |
| [Zookeeper]({{< ref setup-zookeeper.md >}}) | ✅ | ❌ | ✅ | Alpha |
| Name | CRUD | Transactional </br>(Supports Actors) | ETag | 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 >}}) | ✅ | ✅ | ❌ | GA | 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 >}}) | ✅ | ✅ | ✅ | GA | 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 </br>(Supports Actors) | ETag | Status |
|------------------------------------------------------------------|------|---------------------|------|--------|
| [AWS DynamoDB]({{< ref setup-dynamodb.md>}}) | ✅ | ❌ | ❌ | Alpha |
| Name | CRUD | Transactional </br>(Supports Actors) | ETag | Status | Component version | Since |
|------------------------------------------------------------------|------|---------------------|------|--------|-----|-------|
| [AWS DynamoDB]({{< ref setup-dynamodb.md>}}) | ✅ | ❌ | ❌ | Alpha | v1 | 1.0 |
### Google Cloud Platform (GCP)
| Name | CRUD | Transactional </br>(Supports Actors) | ETag | Status |
|-------------------------------------------------------|------|---------------------|------|--------|
| [GCP Firestore]({{< ref setup-firestore.md >}}) | ✅ | ❌ | ❌ | Alpha |
| Name | CRUD | Transactional </br>(Supports Actors) | ETag | Status | Component version | Since |
|-------------------------------------------------------|------|---------------------|------|--------|-----|------|
| [GCP Firestore]({{< ref setup-firestore.md >}}) | ✅ | ❌ | ❌ | Alpha | v1 | 1.0 |
### Microsoft Azure
| Name | CRUD | Transactional </br>(Supports Actors) | ETag | Status |
|------------------------------------------------------------------|------|---------------------|------|--------|
| [Azure Blob Storage]({{< ref setup-azure-blobstorage.md >}}) | ✅ | ❌ | ✅ | Alpha |
| [Azure CosmosDB]({{< ref setup-azure-cosmosdb.md >}}) | ✅ | ✅ | ✅ | Alpha |
| [Azure SQL Server]({{< ref setup-sqlserver.md >}}) | ✅ | ✅ | ✅ | Alpha |
| [Azure Table Storage]({{< ref setup-azure-tablestorage.md >}}) | ✅ | ❌ | ✅ | Alpha |
| Name | CRUD | Transactional </br>(Supports Actors) | ETag | Status | Component version | Since |
|------------------------------------------------------------------|------|---------------------|------|--------| ------|-----|
| [Azure Blob Storage]({{< ref setup-azure-blobstorage.md >}}) | ✅ | ❌ | ✅ | GA | v1 | 1.0 |
| [Azure CosmosDB]({{< ref setup-azure-cosmosdb.md >}}) | ✅ | ✅ | ✅ | GA | 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 |

2
daprdocs/content/en/operations/hosting/kubernetes/kubernetes-deploy.md
View File

@ -46,7 +46,7 @@ You can install Dapr to a Kubernetes cluster using the [Dapr CLI]({{< ref instal
The `-k` flag initializes Dapr on the Kubernetes cluster in your current context.
{{% alert title="Target cluster" color="primary" %}}
Make sure the correct "target" cluster is set. Check `kubectl context (kubectl config kubectl config get-contexts)` to verify. You can set a different context using `kubectl config use-context <CONTEXT>`.
Make sure the correct "target" cluster is set. Check `kubectl context (kubectl config get-contexts)` to verify. You can set a different context using `kubectl config use-context <CONTEXT>`.
{{% /alert %}}
Run on your local machine:

2
daprdocs/content/en/operations/hosting/kubernetes/kubernetes-overview.md
View File

@ -23,4 +23,4 @@ Deploying and running a Dapr enabled application into your Kubernetes cluster is
```
You can see some examples [here](https://github.com/dapr/quickstarts/tree/master/hello-kubernetes/deploy) in the Kubernetes getting started sample.
Read [Kubernetes how to topics](https://github.com/dapr/docs/tree/master/howto#kubernetes-configuration) for more information about setting up Kubernetes and Dapr.
Explore additional [Kubernetes related topics]({{<ref kubernetes>}}) for more information about working with Dapr on Kubernetes.

2
daprdocs/content/en/operations/monitoring/logging/fluentd.md
View File

@ -45,7 +45,7 @@ helm install elasticsearch elastic/elasticsearch -n dapr-monitoring
If you are using minikube or want to disable persistent volumes for development purposes, you can disable it by using the following command:
```bash
helm install elasticsearch elastic/elasticsearch -n dapr-monitoring --set persistence.enabled=false --replicas=1
helm install elasticsearch elastic/elasticsearch -n dapr-monitoring --set persistence.enabled=false,replicas=1
```
4. Install Kibana

2
daprdocs/content/en/operations/performance-and-scalability/_index.md
View File

@ -2,6 +2,6 @@
type: docs
title: "Performance and Scalability"
linkTitle: "Performance and Scalability"
weight: 90
weight: 700
description: "Benchmarks and guidelines for Dapr building blocks"
---

56
daprdocs/content/en/operations/performance-and-scalability/perf-actors-activation.md Normal file
View File

@ -0,0 +1,56 @@
---
type: docs
title: "Actors activation performance"
linkTitle: "Actors activation performance"
weight: 20000
description: ""
---
This article provides service invocation API performance benchmarks and resource utilization for actors in Dapr on Kubernetes.
## System overview
For applications using actors in Dapr there are two aspects to be considered. First, is the routing of actor invocations handled by Dapr sidecar. Second, is the actors runtime that is implemented and handled on the application side and depends on the SDK. For now, the performance tests are using the Java SDK to provide an actors runtime in the application.
### Kubernetes components
* Sidecar (data plane)
* Placement (required for actors, control plane mapping actor types to hosts)
* Operator (control plane)
* Sidecar Injector (control plane)
* Sentry (optional, control plane)
## Performance summary for Dapr v1.0
The actors API in Dapr sidecar will identify which hosts are registered for a given actor type and route the request to the appropriate host for a given actor ID. The host runs an instance of the application and uses the Dapr SDK (.Net, Java, Python or PHP) to handle actors requests via HTTP.
This test uses invokes actors via Dapr's HTTP API directly.
For more information see [actors overview]({{< ref actors-overview.md >}}).
### Kubernetes performance test setup
The test was conducted on a 3 node Kubernetes cluster, using commodity hardware running 4 cores and 8GB of RAM, without any network acceleration.
The setup included a load tester ([Fortio](https://github.com/fortio/fortio)) pod with a Dapr sidecar injected into it that called the service invocation API to reach a pod on a different node.
Test parameters:
* 500 requests per second
* 1 replica
* 1 minute duration
* Sidecar limited to 0.5 vCPU
* mTLS enabled
* Sidecar telemetry enabled (tracing with a sampling rate of 0.1)
* Payload of an empty JSON object: `{}`
### Results
* The actual throughput was ~500 qps.
* The tp90 latency was ~3ms.
* The tp99 latency was ~6.2ms.
* Dapr app consumed ~523m CPU and ~304.7Mb of Memory
* Dapr sidecar consumed 2m CPU and ~18.2Mb of Memory
* No app restarts
* No sidecar restarts
## Related links
* For more information see [overview of Dapr on Kubernetes]({{< ref kubernetes-overview.md >}})

6
daprdocs/content/en/operations/performance-and-scalability/perf-service-invocation.md
View File

@ -29,7 +29,7 @@ For more information see [overview of Dapr in self-hosted mode]({{< ref self-hos
For more information see [overview of Dapr on Kubernetes]({{< ref kubernetes-overview.md >}}).
## Performance summary for Dapr v0.11.3
## Performance summary for Dapr v1.0
The service invocation API is a reverse proxy with built-in service discovery to connect to other services. This includes tracing, metrics, mTLS for in-transit encryption of traffic, together with resiliency in the form of retries for network partitions and connection errors.
@ -76,7 +76,9 @@ There are a number of variants that affect the CPU and memory consumption for ea
### Data plane performance
The Dapr sidecar uses 0.48 vCPU and 23Mb per 1000 requests per second.
End-to-end, the Dapr sidecars (client and server) add 1.57 ms to the 90th percentile latency, and 2.36 ms to the 99th percentile latency. End-to-end here is a call from one app to another app receiving a response. This is shown by steps 1-7 in [this diagram]({{< ref service-invocation-overview.md >}}).
End-to-end, the Dapr sidecars (client and server) add ~1.40 ms to the 90th percentile latency, and ~2.10 ms to the 99th percentile latency. End-to-end here is a call from one app to another app receiving a response. This is shown by steps 1-7 in [this diagram]({{< ref service-invocation-overview.md >}}).
This performance is on par or better than commonly used service meshes.
### Latency

7
daprdocs/content/en/operations/support/_index.md Normal file
View File

@ -0,0 +1,7 @@
---
type: docs
title: "Support and versioning"
linkTitle: "Support"
weight: 600
description: "The support and versioning options available for Dapr"
---

65
daprdocs/content/en/operations/support/support-release-policy.md Normal file
View File

@ -0,0 +1,65 @@
---
type: docs
title: "Supported releases"
linkTitle: "Supported releases"
weight: 1000
description: "Release support and upgrade policies "
---
## Introduction
This topic details the supported versions of Dapr releases, the upgrade policies and how deprecations and breaking changes are communicated.
Dapr releases use `MAJOR.MINOR.PATCH` versioning. For example 1.0.0
* A `PATCH` version is incremented for bug and security hot fixes.
* A `MINOR` version is updated as part of the regular release cadence, including new features, bug and security fixes.
* A `MAJOR` version is updated when there’s a non-backward compatible change to the runtime, such as an API change. A `MAJOR` release can also occur then there is a considered a significant addition/change of functionality that needs to differentiate from the previous version.
A supported release means;
- A hoxfix patch is released if the release has a critical issue such as a mainline broken scenario or a security issue. Each of these are reviewed on a case by case basis.
- Issues are investigated for the supported releases. If a release is no longer supported, you need to upgrade to a newer release and determine if the issue is still relevant.
From the 1.0.0 release onwards two (2) versions of Dapr are supported; the current and previous versions. Typically these are `MINOR`release updates. This means that there is a rolling window that moves forward for supported releases and it is your operational responsibility to remain up to date with these supported versions. If you have an older version of Dapr you may have to do intermediate upgrades to get to a supported version.
There will be at least 6 weeks between major.minor version releases giving users a 12 week (3 month) rolling window for upgrading.
Patch support is for supported versions (current and previous).
## Supported versions
The table below shows the versions of Dapr releases that have been tested together and form a "packaged" release. Any other combinations of releases are not supported.
| Release date | Runtime | CLI | SDKs | Dashboard | Status |
|--------------------|:--------:|:--------|---------|---------|---------|
| Feb 17th 2021 | 1.0.0 | 1.0.0 | Java 1.0.0 </br>Go 1.0.0 </br>PHP 1.0.0 </br>Python 1.0.0 </br>.NET 1.0.0 | 0.6.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
The table below shows the tested upgrade paths for the Dapr runtime. For example you are able to upgrade from 1.0-rc4 to the 1.0 release. Any other combinations of upgrades have not been tested.
| Current Runtime version | Must upgrade through | Target Runtime version | Notes
|--------------------------|-----------------------|------------------------- |------------------------- |
| 0.11 | N/A | 1.0.0 | Use Dapr CLI to upgrade for both self hosted and Kubernetes
| 1.0-rc1 to 1.0-rc4 | N/A | 1.0.0 | See Dapr 1.0 release notes
## 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.
Deprecations appear in release notes under a section named “Deprecations”, which indicates:
- The point in the future the now-deprecated feature will no longer be supported. For example release x.y.z. This is at least two (2) releases prior.
- Document any steps the user must take to modify their code, operations, etc if applicable in the release notes.
After announcing a future breaking change, the change will happen in 2 releases or 6 months, whichever is greater. Deprecated features should respond with warning but do nothing otherwise.
Here is an example, using a hypothetical 1.1.0 as the deprecation announcement release.
| Feature | Deprecation announcement | Deprecation |
|-----------------------|-----------------------|------------------------- |
| Feature X | 1.1.0 | 1.3.0 |
## Upgrade on Hosting platforms
Dapr can support multiple hosting platforms for production. With the 1.0 release the two supported platforms are Kubernetes and physical machines. For Kubernetes upgrades see [Production guidelines on Kubernetes]({{< ref kubernetes-production.md >}})
## Related links
* Read the [Versioning policy]({{< ref support-versioning.md >}})

105
daprdocs/content/en/operations/support/support-versioning.md Normal file
View File

@ -0,0 +1,105 @@
---
type: docs
title: "Versioning policy"
linkTitle: "Versioning "
weight: 2000
description: "Dapr's versioning policies"
---
## Introduction
Dapr is designed for future changes in the runtime, APIs and components with versioning schemes. This topic describes the versioning schemes and strategies for APIs, manifests such as components and Github repositories.
## Versioning
Versioning is the process of assigning either unique version names or unique version numbers to unique states of computer software.
- Versioning provides compatibility, explicit change control and handling changes, in particular breaking changes.
- Dapr strives to be backwards compatible. If a breaking change is needed it’ll be [announced in advance]({{< ref "support-release-policy#feature-and-deprecations" >}}).
- Deprecated features are done over multiple releases with both new and deprecated features working side-by-side.
Versioning refers to the following Dapr repos: dapr, CLI, stable language SDKs, dashboard, components-contrib, quickstarts, helm-charts and documentation.
Dapr has the following versioning schemes:
- Dapr `HTTP API` versioned with `MAJOR.MINOR`
- Dapr `GRPC API` with `MAJOR`
- Releases (GitHub repositories including dapr, CLI, SDKs and Helm Chart) with `MAJOR.MINOR.PATCH`
- Documentation and Quickstarts repositories are versioned with the Dapr runtime repository versioning.
- Dapr `Components` with `MAJOR` in components-contrib GitHub repositories.
- Dapr `Manifests` with `MAJOR.MINOR`. These include subscriptions and configurations.
Note that the Dapr APIs, binaries releases (runtime, CLI, SDKs) and components are all independent from one another.
## Dapr API
The Dapr HTTP API is versioned according to these [REST API guidelines](https://github.com/microsoft/api-guidelines/blob/vNext/Guidelines.md#71-url-structure).
Based to the these guidelines;
- A `MAJOR` version of the API is incremented when a deprecation is expected of the older version. Any such deprecation will be communicated and an upgrade path made available.
- A `MINOR` versions *may* be incremented for any other changes. For example a change to the JSON schema of the message sent to the API.
The definition of a breaking change to the API can be viewed [here](https://github.com/microsoft/api-guidelines/blob/vNext/Guidelines.md#123-definition-of-a-breaking-change).
- Experimental APIs include an “alpha” suffix to denote for their alpha status. For example v1.0alpha, v2.0alpha, etc.
## Dapr runtime
Dapr releases use `MAJOR.MINOR.PATCH` versioning. For example 1.0.0. Read [Supported releases]({{< ref support-release-policy.md >}}) for more on the versioning of releases.
## Helm Charts
Helm charts in the [helm-charts repo](https://github.com/dapr/helm-charts) are versioned with the Dapr runtime. The Helm charts are used in the [Kubernetes deployment]({{< ref "kubernetes-deploy#install-with-helm-advanced" >}})
## Language SDKs, CLI and dashboard
The Dapr language SDKs, CLI and dashboard are versioned independently from the Dapr runtime and can be released at different schedules. See this [table]({{< ref "support-release-policy#supported-versions" >}}) to show the compatibility between versions of the SDKs, CLI, dashboard and runtime. Each new release on the runtime lists the corresponding supported SDKs, CLI and Dashboard.
SDKs, CLIs and Dashboard are versioning follows a `MAJOR.MINOR.PATCH` format. A major version is incremented when there’s a non-backwards compatible change in an SDK (for example, changing a parameter on a client method. A minor version is updated for new features and bug fixes and the patch version is incremented in case of bug or security hot fixes.
Samples and examples in SDKs version with that repo.
## Components
Components are implemented in the components-contrib repository and follow a `MAJOR` versioning scheme. The version for components adheres to major versions (vX), as patches and non-breaking changes are added to the latest major version. The version is incremented when there’s a non-backwards compatible change in a component interface, for example, changing an existing method in the State Store interface.
The [components-contrib](https://github.com/dapr/components-contrib/) repo release is a flat version across all components inside. That is, a version for the components-contrib repo release is made up of all the schemas for the components inside it. A new version of Dapr does not mean there is a new release of components-contrib if there are no component changes.
Note: Components have a production usage lifecycle status: Alpha, Beta and GA (stable). These statuses are not related to their versioning. The tables of supported components shows both their versions and their status.
* List of [state store components]({{< ref supported-state-stores.md >}})
* List of [pub/sub components]({{< ref supported-pubsub.md >}})
* List of [secret store components]({{< ref supported-secret-stores.md >}})
* List of [binding components]({{< ref supported-bindings.md >}})
For more information on component versioning read [Version 2 and beyond of a component](https://github.com/dapr/components-contrib/blob/master/docs/developing-component.md#version-2-and-beyond-of-a-component)
### Component schemas
Versioning for component YAMLs comes in two forms:
- Versioning for the component manifest. The `apiVersion`
- Version for the component implementation. The `.spec.version`
A component manifest includes the schema for an implementation in the `.spec.metadata` field, with the `.type` field denoting the implementation
See the comments in the example below:
```yaml
apiVersion: dapr.io/v1alpha1 # <-- This is the version of the component manifest
kind: Component
metadata:
name: pubsub
spec:
version: v1 # <-- This is the version of the pubsub.redis schema implementation
type: pubsub.redis
metadata:
- name: redisHost
value: redis-master:6379
- name: redisPassword
value: general-kenobi
```
### Component manifest version
The Component YAML manifest is versioned with `dapr.io/v1alpha1`.
### Component implementation version
The version for a component implementation is determined by the `.spec.version` field as can be seen in the example above. The `.spec.version` field is mandatory in a schema instance and the component fails to load if this is not present. For the release of Dapr 1.0.0 all components are marked as `v1`.The component implementation version is incremented only for non-backward compatible changes.
### Component deprecations
Deprecations of components will be announced two (2) releases ahead. Deprecation of a component, results in major version update of the component version. After 2 releases, the component is unregistered from the Dapr runtime, and trying to load it will throw a fatal exception.
## Quickstarts and Samples
Quickstarts in the [Quickstarts repo](https://github.com/dapr/quickstarts) are versioned with the runtime, where a table of corresponding versions is on the front page of the samples repo. Users should only use Quickstarts corresponding to the version of the runtime being run.
Samples in the [Samples repo](https://github.com/dapr/samples) are each versioned on a case by case basis depending on the sample maintainer. Samples that become very out of date with the runtime releases (many versions behind) or have not been maintained for more than 1 year will be removed.
## Related links
* Read the [Supported releases]({{< ref support-release-policy.md >}})

2
daprdocs/layouts/partials/hooks/body-end.html
View File

@ -5,7 +5,7 @@
// Your apiKey and indexName will be given to you once
// we create your config
apiKey: '54ae43aa28ce8f00c54c8d5f544d29b9',
indexName: 'crawler_dapr-rc3',
indexName: 'crawler_dapr',
appId: 'O0QLQGNF38',
// Replace inputSelector with a CSS selector
// matching your search input