mirror of https://github.com/dapr/docs.git
Merge branch 'v1.4' into local_secret_store_multivalued_1733
This commit is contained in:
commit
a66f923bc6
|
@ -0,0 +1,32 @@
|
|||
name: dapr-bot
|
||||
|
||||
on:
|
||||
issue_comment: {types: created}
|
||||
|
||||
jobs:
|
||||
daprbot:
|
||||
name: bot-processor
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Comment analyzer
|
||||
uses: actions/github-script@v1
|
||||
with:
|
||||
github-token: ${{secrets.DAPR_BOT_TOKEN}}
|
||||
script: |
|
||||
const payload = context.payload;
|
||||
const issue = context.issue;
|
||||
const isFromPulls = !!payload.issue.pull_request;
|
||||
const commentBody = payload.comment.body;
|
||||
|
||||
if (!isFromPulls && commentBody && commentBody.indexOf("/assign") == 0) {
|
||||
if (!issue.assignees || issue.assignees.length === 0) {
|
||||
await github.issues.addAssignees({
|
||||
owner: issue.owner,
|
||||
repo: issue.repo,
|
||||
issue_number: issue.number,
|
||||
assignees: [context.actor],
|
||||
})
|
||||
}
|
||||
|
||||
return;
|
||||
}
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Dapr Concepts"
|
||||
title: "Dapr concepts"
|
||||
linkTitle: "Concepts"
|
||||
weight: 10
|
||||
description: "Learn about Dapr including its main features and capabilities"
|
||||
|
|
|
@ -0,0 +1,7 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Overview of the Dapr services"
|
||||
linkTitle: "Dapr services"
|
||||
weight: 800
|
||||
description: "Learn about the services that make up the Dapr runtime"
|
||||
---
|
|
@ -0,0 +1,12 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Dapr operator service overview"
|
||||
linkTitle: "Operator"
|
||||
description: "Overview of the Dapr operator process"
|
||||
---
|
||||
|
||||
When running Dapr in [Kubernetes mode]({{< ref kubernetes >}}), a pod running the Dapr operator service manages [Dapr component]({{< ref components >}}) updates and provides Kubernetes services endpoints for Dapr.
|
||||
|
||||
## Running the operator service
|
||||
|
||||
The operator service is deployed as part of `dapr init -k`, or via the Dapr Helm charts. For more information on running Dapr on Kubernetes, visit the [Kubernetes hosting page]({{< ref kubernetes >}}).
|
|
@ -0,0 +1,16 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Dapr placement service overview"
|
||||
linkTitle: "Placement"
|
||||
description: "Overview of the Dapr placement process"
|
||||
---
|
||||
|
||||
The Dapr placement service is used to calculate and distribute distributed hash tables for the location of [Dapr actors]({{< ref actors >}}) running in [self-hosted mode]({{< ref self-hosted >}}) or on [Kubernetes]({{< ref kubernetes >}}). This hash table maps actor IDs to pods or processes so a Dapr application can communicate with the actor.Anytime a Dapr application activates a Dapr actor, the placement updates the hash tables with the latest actor locations.
|
||||
|
||||
## Self-hosted mode
|
||||
|
||||
The placement service Docker container is started automatically as part of [`dapr init`]({{< ref self-hosted-with-docker.md >}}). It can also be run manually as a process if you are running in [slim-init mode]({{< ref self-hosted-no-docker.md >}}).
|
||||
|
||||
## Kubernetes mode
|
||||
|
||||
The placement service is deployed as part of `dapr init -k`, or via the Dapr Helm charts. For more information on running Dapr on Kubernetes, visit the [Kubernetes hosting page]({{< ref kubernetes >}}).
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Dapr sentry service overview"
|
||||
linkTitle: "Sentry"
|
||||
description: "Overview of the Dapr sentry process"
|
||||
---
|
||||
|
||||
The Dapr sentry service manages mTLS between services and acts as a certificate authority. It generates mTLS certificates and distributes them to any running sidecars. This allows sidecars to communicate with encrypted, mTLS traffic. For more information read the [sidecar-to-sidecar communication overview]({{< ref "security-concept.md#sidecar-to-sidecar-communication" >}}).
|
||||
|
||||
## Self-hosted mode
|
||||
|
||||
The sentry service Docker container is started automatically as part of [`dapr init`]({{< ref self-hosted-with-docker.md >}}). It can also be run manually as a process if you are running in [slim-init mode]({{< ref self-hosted-no-docker.md >}}).
|
||||
|
||||
<img src="/images/security-mTLS-sentry-selfhosted.png" width=1000>
|
||||
|
||||
## Kubernetes mode
|
||||
|
||||
The sentry service is deployed as part of `dapr init -k`, or via the Dapr Helm charts. For more information on running Dapr on Kubernetes, visit the [Kubernetes hosting page]({{< ref kubernetes >}}).
|
||||
|
||||
<img src="/images/security-mTLS-sentry-kubernetes.png" width=1000>
|
||||
|
||||
## Further reading
|
||||
|
||||
- [Security overview]({{< ref security-concept.md >}})
|
||||
- [Self-hosted mode]({{< ref self-hosted-with-docker.md >}})
|
||||
- [Kubernetes mode]({{< ref kubernetes >}})
|
|
@ -0,0 +1,12 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Dapr sidecar injector overview"
|
||||
linkTitle: "Sidecar injector"
|
||||
description: "Overview of the Dapr sidecar injector process"
|
||||
---
|
||||
|
||||
When running Dapr in [Kubernetes mode]({{< ref kubernetes >}}), a pod is created running the dapr-sidecar-injector service, which looks for pods initialized with the [Dapr annotations]({{< ref arguments-annotations-overview.md >}}), and then creates another container in that pod for the [daprd service]({{< ref sidecar >}})
|
||||
|
||||
## Running the sidecar injector
|
||||
|
||||
The sidecar injector service is deployed as part of `dapr init -k`, or via the Dapr Helm charts. For more information on running Dapr on Kubernetes, visit the [Kubernetes hosting page]({{< ref kubernetes >}}).
|
|
@ -0,0 +1,51 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Dapr sidecar (daprd) overview"
|
||||
linkTitle: "Sidecar"
|
||||
weight: 100
|
||||
description: "Overview of the Dapr sidecar process"
|
||||
---
|
||||
|
||||
Dapr uses a [sidecar pattern]({{< ref "overview.md#sidecar-architecture" >}}), meaning the Dapr APIs are run and exposed on a separate process (i.e. the Dapr sidecar) running alongside your application. The Dapr sidecar process is named `daprd` and is launched in different ways depending on the hosting environment.
|
||||
|
||||
<img src="/images/overview-sidecar-model.png" width=700>
|
||||
|
||||
## Self-hosted with `dapr run`
|
||||
|
||||
When Dapr is installed in [self-hosted mode]({{<ref self-hosted>}}), the `daprd` binary is downloaded and placed under the user home directory (`$HOME/.dapr/bin` for Linux/MacOS or `%USERPROFILE%\.dapr\bin\` for Windows). In self-hosted mode, running the Dapr CLI [`run` command]({{< ref dapr-run.md >}}) launches the `daprd` executable together with the provided application executable. This is the recommended way of running the Dapr sidecar when working locally in scenarios such as development and testing. The various arguments the CLI exposes to configure the sidecar can be found in the [Dapr run command reference]({{<ref dapr-run>}}).
|
||||
|
||||
## Kubernetes with `dapr-sidecar-injector`
|
||||
|
||||
On [Kubernetes]({{< ref kubernetes.md >}}), the Dapr control plane includes the [dapr-sidecar-injector service]({{< ref kubernetes-overview.md >}}), which watches for new pods with the `dapr.io/enabled` annotation and injects a container with the `daprd` process within the pod. In this case, sidecar arguments can be passed through annotations as outlined in the **Kubernetes annotations** column in [this table]({{<ref arguments-annotations-overview>}}).
|
||||
|
||||
## Running the sidecar directly
|
||||
|
||||
In most cases you do not need to run `daprd` explicitly, as the sidecar is either launched by the CLI (self-hosted mode) or by the dapr-sidecar-injector service (Kubernetes). For advanced use cases (debugging, scripted deployments, etc.) the `daprd` process can be launched directly.
|
||||
|
||||
For a detailed list of all available arguments run `daprd --help` or see this [table]({{< ref arguments-annotations-overview.md >}}) which outlines how the `daprd` arguments relate to the CLI arguments and Kubernetes annotations.
|
||||
|
||||
### Examples
|
||||
|
||||
1. Start a sidecar along an application by specifying its unique ID. Note `--app-id` is a required field:
|
||||
|
||||
```bash
|
||||
daprd --app-id myapp
|
||||
```
|
||||
|
||||
2. Specify the port your application is listening to
|
||||
|
||||
```bash
|
||||
daprd --app-id --app-port 5000
|
||||
```
|
||||
|
||||
3. If you are using several custom components and want to specify the location of the component definition files, use the `--components-path` argument:
|
||||
|
||||
```bash
|
||||
daprd --app-id myapp --components-path <PATH-TO-COMPONENTS-FILES>
|
||||
```
|
||||
|
||||
4. Enable collection of Prometheus metrics while running your app
|
||||
|
||||
```bash
|
||||
daprd --app-id myapp --enable-metrics
|
||||
```
|
|
@ -9,7 +9,9 @@ description: >
|
|||
|
||||
Dapr is a portable, event-driven runtime that makes it easy for any developer to build resilient, stateless and stateful applications that run on the cloud and edge and embraces the diversity of languages and developer frameworks.
|
||||
|
||||
<iframe width="1120" height="630" src="https://www.youtube.com/embed/9o9iDAgYBA8" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="1120" height="630" src="https://www.youtube.com/embed/9o9iDAgYBA8" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
## Any language, any framework, anywhere
|
||||
|
||||
|
@ -118,4 +120,4 @@ Dapr is designed for [operations]({{< ref operations >}}) and security. The Dapr
|
|||
|
||||
The [services dashboard](https://github.com/dapr/dashboard), installed via the Dapr CLI, provides a web-based UI enabling you to see information, view logs and more for the Dapr sidecars.
|
||||
|
||||
The [monitoring tools support]({{< ref monitoring >}}) provides deeper visibility into the Dapr system services and side-cars and the [observability capabilities]({{<ref "observability-concept.md">}}) of Dapr provide insights into your application such as tracing and metrics.
|
||||
The [monitoring tools support]({{< ref monitoring >}}) provides deeper visibility into the Dapr system services and side-cars and the [observability capabilities]({{<ref "observability-concept.md">}}) of Dapr provide insights into your application such as tracing and metrics.
|
|
@ -35,6 +35,8 @@ Watch these recordings from the Dapr community calls showing presentations on ru
|
|||
- General overview and a demo of [Dapr and Linkerd](https://youtu.be/xxU68ewRmz8?t=142)
|
||||
- Demo of running [Dapr and Istio](https://youtu.be/ngIDOQApx8g?t=335)
|
||||
|
||||
Also, learn more about [running Dapr with Open Service Mesh (OSM)]({{<ref open-service-mesh>}}).
|
||||
|
||||
## When to choose using Dapr, a service mesh, or both
|
||||
Should you be using Dapr, a service mesh, or both? The answer depends on your requirements. If, for example, you are looking to use Dapr for one or more building blocks such as state management or pub/sub, and you are considering using a service mesh just for network security or observability, you may find that Dapr is a good fit and that a service mesh is not required.
|
||||
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Dapr terminology and definitions"
|
||||
linkTitle: "Terminology"
|
||||
weight: 800
|
||||
weight: 900
|
||||
description: Definitions for common terms and acronyms in the Dapr documentation
|
||||
---
|
||||
|
||||
|
|
|
@ -274,7 +274,7 @@ Will result in the following output:
|
|||
|
||||
{{< code-snippet file="contributing-1.py" lang="python" marker="#SAMPLE" >}}
|
||||
|
||||
Use the `replace-key-[token]` and `replace-value-[token]` parameters to limit the embedded snipped to a portion of the sample file. This is useful when you want abbreviate a portion of the code sample. Multiple replacements are supported with multiple values of `token`.
|
||||
Use the `replace-key-[token]` and `replace-value-[token]` parameters to limit the embedded snipped to a portion of the sample file. This is useful when you want abbreviate a portion of the code sample. Multiple replacements are supported with multiple values of `token`.
|
||||
|
||||
The shortcode below and code sample:
|
||||
|
||||
|
|
|
@ -67,7 +67,7 @@ func configHandler(w http.ResponseWriter, r *http.Request) {
|
|||
```
|
||||
|
||||
### Handling reentrant requests
|
||||
The key to a reentrant request is the `Dapr-Reentrancy-Id` header. The value of this header is used to match requests to their call chain and allow them to bypass the actor's lock.
|
||||
The key to a reentrant request is the `Dapr-Reentrancy-Id` header. The value of this header is used to match requests to their call chain and allow them to bypass the actor's lock.
|
||||
|
||||
The header is generated by the Dapr runtime for any actor request that has a reentrant config specified. Once it is generated, it is used to lock the actor and must be passed to all future requests. Below is a snippet of code from an actor handling this is Golang:
|
||||
|
||||
|
|
|
@ -25,7 +25,7 @@ Refer [api spec]({{< ref "actors_api.md#invoke-actor-method" >}}) for more detai
|
|||
Actors can save state reliably using state management capability.
|
||||
You can interact with Dapr through HTTP/gRPC endpoints for state management.
|
||||
|
||||
To use actors, your state store must support multi-item transactions. This means your state store [component](https://github.com/dapr/components-contrib/tree/master/state) must implement the [TransactionalStore](https://github.com/dapr/components-contrib/blob/master/state/transactional_store.go) interface. The list of components that support transactions/actors can be found here: [supported state stores]({{< ref supported-state-stores.md >}}). Only a single state store component can be used as the statestore for all actors.
|
||||
To use actors, your state store must support multi-item transactions. This means your state store [component](https://github.com/dapr/components-contrib/tree/master/state) must implement the [TransactionalStore](https://github.com/dapr/components-contrib/blob/master/state/transactional_store.go) interface. The list of components that support transactions/actors can be found here: [supported state stores]({{< ref supported-state-stores.md >}}). Only a single state store component can be used as the statestore for all actors.
|
||||
|
||||
## Actor timers and reminders
|
||||
|
||||
|
@ -137,7 +137,9 @@ The number of repetitions i.e. the number of times the reminder is run should be
|
|||
|
||||
Watch this [video](https://www.youtube.com/watch?v=B_vkXqptpXY&t=1002s) for more information on using ISO 861 for Reminders
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/B_vkXqptpXY?start=1003" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
#### Retrieve actor reminder
|
||||
|
||||
|
@ -198,7 +200,7 @@ public void ConfigureServices(IServiceCollection services)
|
|||
{
|
||||
// Register actor types and configure actor settings
|
||||
options.Actors.RegisterActor<MyActor>();
|
||||
|
||||
|
||||
// Configure default settings
|
||||
options.ActorIdleTimeout = TimeSpan.FromMinutes(60);
|
||||
options.ActorScanInterval = TimeSpan.FromSeconds(30);
|
||||
|
@ -310,7 +312,7 @@ public void ConfigureServices(IServiceCollection services)
|
|||
{
|
||||
// Register actor types and configure actor settings
|
||||
options.Actors.RegisterActor<MyActor>();
|
||||
|
||||
|
||||
// Configure default settings
|
||||
options.ActorIdleTimeout = TimeSpan.FromMinutes(60);
|
||||
options.ActorScanInterval = TimeSpan.FromSeconds(30);
|
||||
|
@ -385,4 +387,4 @@ For production scenarios, there are some points to be considered before enabling
|
|||
* Number of partitions can only be increased and not decreased. This allows Dapr to automatically redistribute the data on a rolling restart where one or more partition configurations might be active.
|
||||
|
||||
#### Demo
|
||||
* [Actor reminder partitioning community call video](https://youtu.be/ZwFOEUYe1WA?t=1493)
|
||||
* [Actor reminder partitioning community call video](https://youtu.be/ZwFOEUYe1WA?t=1493)
|
|
@ -10,8 +10,10 @@ Output bindings enable you to invoke external resources without taking dependenc
|
|||
For a complete sample showing output bindings, visit this [link](https://github.com/dapr/quickstarts/tree/master/bindings).
|
||||
|
||||
Watch this [video](https://www.youtube.com/watch?v=ysklxm81MTs&feature=youtu.be&t=1960) on how to use bi-directional output bindings.
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/ysklxm81MTs?start=1960" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/ysklxm81MTs?start=1960" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
## 1. Create a binding
|
||||
|
||||
|
@ -93,4 +95,4 @@ You can check [here]({{< ref supported-bindings >}}) which operations are suppor
|
|||
|
||||
- [Binding API]({{< ref bindings_api.md >}})
|
||||
- [Binding components]({{< ref bindings >}})
|
||||
- [Binding detailed specifications]({{< ref supported-bindings >}})
|
||||
- [Binding detailed specifications]({{< ref supported-bindings >}})
|
|
@ -416,6 +416,10 @@ app.post('/dsstatus', (req, res) => {
|
|||
|
||||
{{< /tabs >}}
|
||||
|
||||
{{% alert title="Note on message redelivery" color="primary" %}}
|
||||
Some pubsub components (e.g. Redis) will redeliver a message if a response is not sent back within a specified time window. Make sure to configure metadata such as `processingTimeout` to customize this behavior. For more information refer to the respective [component references]({{< ref supported-pubsub >}}).
|
||||
{{% /alert %}}
|
||||
|
||||
## (Optional) Step 5: Publishing a topic with code
|
||||
|
||||
{{< tabs Node PHP>}}
|
||||
|
|
|
@ -93,7 +93,7 @@ Similarly, if two different applications (different app-IDs) subscribe to the sa
|
|||
|
||||
### Topic scoping
|
||||
|
||||
By default, all topics backing the Dapr pub/sub component (e.g. Kafka, Redis Stream, RabbitMQ) are available to every application configured with that component. To limit which application can publish or subscribe to topics, Dapr provides topic scoping. This enables to you say which topics an application is allowed to published and which topics an application is allowed to subscribed to. For more information read [publish/subscribe topic scoping]({{< ref pubsub-scopes.md >}}).
|
||||
By default, all topics backing the Dapr pub/sub component (e.g. Kafka, Redis Stream, RabbitMQ) are available to every application configured with that component. To limit which application can publish or subscribe to topics, Dapr provides topic scoping. This enables to you say which topics an application is allowed to publish and which topics an application is allowed to subscribe to. For more information read [publish/subscribe topic scoping]({{< ref pubsub-scopes.md >}}).
|
||||
|
||||
### Message Time-to-Live (TTL)
|
||||
Dapr can set a timeout message on a per message basis, meaning that if the message is not read from the pub/sub component, then the message is discarded. This is to prevent the build up of messages that are not read. A message that has been in the queue for longer than the configured TTL is said to be dead. For more information read [publish/subscribe message time-to-live]({{< ref pubsub-message-ttl.md >}}).
|
||||
|
|
|
@ -3,7 +3,7 @@ type: docs
|
|||
title: "Pub/Sub without CloudEvents"
|
||||
linkTitle: "Pub/Sub without CloudEvents"
|
||||
weight: 7000
|
||||
description: "Use Pub/Sub without CloudEvents."
|
||||
description: "Use Pub/Sub without CloudEvents."
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
|
|
@ -158,7 +158,9 @@ The table below shows which application is allowed to subscribe to the topics:
|
|||
|
||||
## Demo
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/7VdWBBGcbHQ?start=513" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
## Related links
|
||||
|
||||
|
|
|
@ -14,11 +14,14 @@ To limit the secrets to which the Dapr application has access to, you can define
|
|||
The secret scoping policy applies to any [secret store]({{< ref supported-secret-stores.md >}}), whether that is a local secret store, a Kubernetes secret store or a public cloud secret store. For details on how to set up a [secret stores]({{< ref setup-secret-store.md >}}) read [How To: Retrieve a secret]({{< ref howto-secrets.md >}})
|
||||
|
||||
Watch this [video](https://youtu.be/j99RN_nxExA?start=2272) for a demo on how to use secret scoping with your application.
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="688" height="430" src="https://www.youtube.com/embed/j99RN_nxExA?start=2272" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
## Scenario 1 : Deny access to all secrets for a secret store
|
||||
|
||||
In this example all secret access is denied to an application running on a Kubernetes cluster which has a configured [Kubernetes secret store]({{<ref kubernetes-secret-store>}}) named `mycustomsecretstore`. In the case of Kubernetes, aside from the user defined custom store, the default store named `kubernetes` is also addressed to ensure all secrets are denied access (See [here]({{<ref "kubernetes-secret-store.md#default-kubernetes-secret-store-component">}}) to learn more about the Kubernetes default secret store).
|
||||
In this example all secret access is denied to an application running on a Kubernetes cluster which has a configured [Kubernetes secret store]({{<ref kubernetes-secret-store>}}) named `mycustomsecretstore`. In the case of Kubernetes, aside from the user defined custom store, the default store named `kubernetes` is also addressed to ensure all secrets are denied access (See [here]({{<ref "kubernetes-secret-store.md#default-kubernetes-secret-store-component">}}) to learn more about the Kubernetes default secret store).
|
||||
|
||||
To add this configuration follow the steps below:
|
||||
|
||||
|
|
|
@ -18,13 +18,13 @@ Dapr allows you to assign a global, unique ID for your app. This ID encapsulates
|
|||
In self hosted mode, set the `--app-id` flag:
|
||||
|
||||
```bash
|
||||
dapr run --app-id cart --app-port 5000 python app.py
|
||||
dapr run --app-id cart --dapr-http-port 3500 --app-port 5000 python app.py
|
||||
```
|
||||
|
||||
If your app uses an SSL connection, you can tell Dapr to invoke your app over an insecure SSL connection:
|
||||
|
||||
```bash
|
||||
dapr run --app-id cart --app-port 5000 --app-ssl python app.py
|
||||
dapr run --app-id cart --dapr-http-port 3500 --app-port 5000 --app-ssl python app.py
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
|
|
|
@ -83,7 +83,7 @@ Connection establishment via gRPC to the target sidecar has a timeout of 5 secon
|
|||
|
||||
### Pluggable service discovery
|
||||
|
||||
Dapr can run on a variety of [hosting platforms]({{< ref hosting >}}). To enable service discovery and service invocation, Dapr uses pluggable [name resolution components]({{< ref supported-name-resolution >}}). For example, the Kubernetes name resolution component uses the Kubernetes DNS service to resolve the location of other applications running in the cluster. Self-hosted machines can use the mDNS name resolution component. The Consul name resolution component can be used in any hosting environment including Kubernetes or self-hosted.
|
||||
Dapr can run on a variety of [hosting platforms]({{< ref hosting >}}). To enable service discovery and service invocation, Dapr uses pluggable [name resolution components]({{< ref supported-name-resolution >}}). For example, the Kubernetes name resolution component uses the Kubernetes DNS service to resolve the location of other applications running in the cluster. Self-hosted machines can use the mDNS name resolution component. The Consul name resolution component can be used in any hosting environment including Kubernetes or self-hosted.
|
||||
|
||||
### Round robin load balancing with mDNS
|
||||
|
||||
|
@ -105,7 +105,7 @@ The API for service invocation can be found in the [service invocation API refer
|
|||
|
||||
### gRPC proxying
|
||||
|
||||
Dapr allows users to keep their own proto services and work natively with gRPC. This means that you can use service invocation to call your existing gRPC apps without having to include any Dapr SDKs or include custom gRPC services. For more information, see the [how-to tutorial for Dapr and gRPC]({{< ref howto-invoke-services-grpc.md >}}).
|
||||
Dapr allows users to keep their own proto services and work natively with gRPC. This means that you can use service invocation to call your existing gRPC apps without having to include any Dapr SDKs or include custom gRPC services. For more information, see the [how-to tutorial for Dapr and gRPC]({{< ref howto-invoke-services-grpc.md >}}).
|
||||
|
||||
## Example
|
||||
|
||||
|
|
|
@ -21,7 +21,7 @@ When a TTL is not specified the default behavior of the state store is retained.
|
|||
|
||||
## Persisting state (ignoring an existing TTL)
|
||||
|
||||
To explictly persist a state (ignoring any TTLs set for the key), specify a `ttlInSeconds` value of `-1`.
|
||||
To explicitly persist a state (ignoring any TTLs set for the key), specify a `ttlInSeconds` value of `-1`.
|
||||
|
||||
## Supported components
|
||||
|
||||
|
|
|
@ -6,7 +6,7 @@ weight: 300
|
|||
description: "Debug Dapr apps locally which still connected to your Kubernetes cluster"
|
||||
---
|
||||
|
||||
Bridge to Kubernetes allows you to run and debug code on your development computer, while still connected to your Kubernetes cluster with the rest of your application or services. This type of debugging is often called *local tunnel debugging*.
|
||||
Bridge to Kubernetes allows you to run and debug code on your development computer, while still connected to your Kubernetes cluster with the rest of your application or services. This type of debugging is often called *local tunnel debugging*.
|
||||
|
||||
{{< button text="Learn more about Bridge to Kubernetes" link="https://aka.ms/bridge-vscode-dapr" >}}
|
||||
|
||||
|
@ -14,7 +14,9 @@ Bridge to Kubernetes allows you to run and debug code on your development comput
|
|||
|
||||
Bridge to Kubernetes supports debugging Dapr apps on your machine, while still having them interact with the services and applications running on your Kubernetes cluster. This example showcases Bridge to Kubernetes enabling a developer to debug the [distributed calculator quickstart](https://github.com/dapr/quickstarts/tree/master/distributed-calculator):
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/rxwg-__otso" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
{{% alert title="Isolation mode" color="warning" %}}
|
||||
[Isolation mode](https://aka.ms/bridge-isolation-vscode-dapr) is currently not supported with Dapr apps. Make sure to launch Bridge to Kubernetes mode without isolation.
|
||||
|
|
|
@ -91,5 +91,5 @@ All done. Now you can point to port 40000 and start a remote debug session to da
|
|||
|
||||
- [Overview of Dapr on Kubernetes]({{< ref kubernetes-overview >}})
|
||||
- [Deploy Dapr to a Kubernetes cluster]({{< ref kubernetes-deploy >}})
|
||||
- [Debug Dapr services on Kubernetes]({{< ref debug-dapr-services >}})
|
||||
- [Debug Dapr services on Kubernetes]({{< ref debug-dapr-services >}})
|
||||
- [Dapr Kubernetes Quickstart](https://github.com/dapr/quickstarts/tree/master/hello-kubernetes)
|
|
@ -63,4 +63,7 @@ Using the VS Code extension, you can debug multiple Dapr applications at the sam
|
|||
### Community call demo
|
||||
|
||||
Watch this [video](https://www.youtube.com/watch?v=OtbYCBt9C34&t=85) on how to use the Dapr VS Code extension:
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/OtbYCBt9C34?start=85" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
|
@ -56,7 +56,7 @@ In the case of the hello world quickstart, two applications are launched, each w
|
|||
"type": "python",
|
||||
"request": "launch",
|
||||
"name": "Pythonapp with Dapr",
|
||||
"program": "${workspaceFolder}/app.py",
|
||||
"program": "${workspaceFolder}/app.py",
|
||||
"console": "integratedTerminal",
|
||||
"preLaunchTask": "daprd-debug-python",
|
||||
"postDebugTask": "daprd-down-python"
|
||||
|
@ -69,7 +69,7 @@ Each configuration requires a `request`, `type` and `name`. These parameters hel
|
|||
|
||||
- `type` defines the language used. Depending on the language, it might require an extension found in the marketplace, such as the [Python Extension](https://marketplace.visualstudio.com/items?itemName=ms-python.python).
|
||||
- `name` is a unique name for the configuration. This is used for compound configurations when calling multiple configurations in your project.
|
||||
- `${workspaceFolder}` is a VS Code variable reference. This is the path to the workspace opened in VS Code.
|
||||
- `${workspaceFolder}` is a VS Code variable reference. This is the path to the workspace opened in VS Code.
|
||||
- The `preLaunchTask` and `postDebugTask` parameters refer to the program configurations run before and after launching the application. See step 2 on how to configure these.
|
||||
|
||||
For more information on VSCode debugging parameters see [VS Code launch attributes](https://code.visualstudio.com/Docs/editor/debugging#_launchjson-attributes).
|
||||
|
@ -153,7 +153,7 @@ Below are the supported parameters for VS Code tasks. These parameters are equiv
|
|||
| `appPort` | This parameter tells Dapr which port your application is listening on | Yes | `"appPort": 4000`
|
||||
| `appProtocol` | Tells Dapr which protocol your application is using. Valid options are http and grpc. Default is http | No | `"appProtocol": "http"`
|
||||
| `appSsl` | Sets the URI scheme of the app to https and attempts an SSL connection | No | `"appSsl": true`
|
||||
| `args` | Sets a list of arguments to pass on to the Dapr app | No | "args": []
|
||||
| `args` | Sets a list of arguments to pass on to the Dapr app | No | "args": []
|
||||
| `componentsPath` | Path for components directory. If empty, components will not be loaded. | No | `"componentsPath": "./components"`
|
||||
| `config` | Tells Dapr which Configuration CRD to use | No | `"config": "./config"`
|
||||
| `controlPlaneAddress` | Address for a Dapr control plane | No | `"controlPlaneAddress": "http://localhost:1366/"`
|
||||
|
|
|
@ -28,4 +28,7 @@ Dapr has pre-built Docker remote containers for NodeJS and C#. You can pick the
|
|||
|
||||
#### Example
|
||||
Watch this [video](https://www.youtube.com/watch?v=D2dO4aGpHcg&t=120) on how to use the Dapr VS Code Remote Containers with your application.
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/D2dO4aGpHcg?start=120" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/D2dO4aGpHcg?start=120" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
|
@ -22,7 +22,9 @@ Users are able to leverage both OSM SMI traffic policies and Dapr capabilities o
|
|||
|
||||
Watch the OSM team present the OSM and Dapr integration in the 05/18/2021 community call:
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/LSYyTL0nS8Y?start=1916" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
## Additional resources
|
||||
|
||||
|
|
|
@ -80,28 +80,28 @@ Prerequisites:
|
|||
1. Set up the environment variables containing the Azure Storage Account credentials:
|
||||
|
||||
{{< tabs Windows "macOS/Linux" >}}
|
||||
|
||||
|
||||
{{% codetab %}}
|
||||
```bash
|
||||
export STORAGE_ACCOUNT_KEY=<YOUR-STORAGE-ACCOUNT-KEY>
|
||||
export STORAGE_ACCOUNT_NAME=<YOUR-STORAGE-ACCOUNT-NAME>
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
|
||||
{{% codetab %}}
|
||||
```bash
|
||||
set STORAGE_ACCOUNT_KEY=<YOUR-STORAGE-ACCOUNT-KEY>
|
||||
set STORAGE_ACCOUNT_NAME=<YOUR-STORAGE-ACCOUNT-NAME>
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
1. Move to the workflows directory and run the sample runtime:
|
||||
|
||||
```bash
|
||||
cd src/Dapr.Workflows
|
||||
|
||||
|
||||
dapr run --app-id workflows --protocol grpc --port 3500 --app-port 50003 -- dotnet run --workflows-path ../../samples
|
||||
```
|
||||
|
||||
|
@ -109,8 +109,8 @@ Prerequisites:
|
|||
|
||||
```bash
|
||||
curl http://localhost:3500/v1.0/invoke/workflows/method/workflow1
|
||||
|
||||
{"value":"Hello from Logic App workflow running with Dapr!"}
|
||||
|
||||
{"value":"Hello from Logic App workflow running with Dapr!"}
|
||||
```
|
||||
|
||||
### Kubernetes
|
||||
|
@ -153,7 +153,7 @@ Prerequisites:
|
|||
|
||||
```bash
|
||||
curl http://localhost:3500/v1.0/invoke/workflows/method/workflow1
|
||||
|
||||
|
||||
{"value":"Hello from Logic App workflow running with Dapr!"}
|
||||
```
|
||||
|
||||
|
@ -186,42 +186,44 @@ Prerequisites:
|
|||
1. Next, apply the Dapr component:
|
||||
|
||||
{{< tabs Self-hosted Kubernetes >}}
|
||||
|
||||
|
||||
{{% codetab %}}
|
||||
Place the binding yaml file above in a `components` directory at the root of your application.
|
||||
{{% /codetab %}}
|
||||
|
||||
|
||||
{{% codetab %}}
|
||||
```bash
|
||||
kubectl apply -f my_binding.yaml
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
1. Once an event is sent to the bindings component, check the logs Dapr Workflows to see the output.
|
||||
|
||||
{{< tabs Self-hosted Kubernetes >}}
|
||||
|
||||
|
||||
{{% codetab %}}
|
||||
In standalone mode, the output will be printed to the local terminal.
|
||||
{{% /codetab %}}
|
||||
|
||||
|
||||
{{% codetab %}}
|
||||
On Kubernetes, run the following command:
|
||||
|
||||
|
||||
```bash
|
||||
kubectl logs -l app=dapr-workflows-host -c host
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
## Example
|
||||
|
||||
Watch an example from the Dapr community call:
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/7fP-0Ixmi-w?start=116" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
## Additional resources
|
||||
|
||||
|
|
|
@ -125,6 +125,9 @@ spec:
|
|||
secretKeyRef:
|
||||
name: redis
|
||||
key: redis-password
|
||||
# uncomment below for connecting to redis cache instances over TLS (ex - Azure Redis Cache)
|
||||
# - name: enableTLS
|
||||
# value: true
|
||||
```
|
||||
|
||||
This example uses the kubernetes secret that was created when setting up a cluster with the above instructions.
|
||||
|
@ -153,6 +156,9 @@ spec:
|
|||
secretKeyRef:
|
||||
name: redis
|
||||
key: redis-password
|
||||
# uncomment below for connecting to redis cache instances over TLS (ex - Azure Redis Cache)
|
||||
# - name: enableTLS
|
||||
# value: true
|
||||
```
|
||||
|
||||
This example uses the kubernetes secret that was created when setting up a cluster with the above instructions.
|
||||
|
@ -179,6 +185,9 @@ spec:
|
|||
value: <HOST>
|
||||
- name: redisPassword
|
||||
value: <PASSWORD>
|
||||
# uncomment below for connecting to redis cache instances over TLS (ex - Azure Redis Cache)
|
||||
# - name: enableTLS
|
||||
# value: true
|
||||
```
|
||||
|
||||
```yaml
|
||||
|
@ -195,6 +204,9 @@ spec:
|
|||
value: <HOST>
|
||||
- name: redisPassword
|
||||
value: <PASSWORD>
|
||||
# uncomment below for connecting to redis cache instances over TLS (ex - Azure Redis Cache)
|
||||
# - name: enableTLS
|
||||
# value: true
|
||||
```
|
||||
|
||||
## Apply the configuration
|
||||
|
|
|
@ -7,7 +7,7 @@ aliases:
|
|||
- /getting-started/install-dapr/
|
||||
---
|
||||
|
||||
Now that you have the [Dapr CLI installed]({{<ref install-dapr-cli.md>}}), it's time to initialize Dapr on your local machine using the CLI.
|
||||
Now that you have the [Dapr CLI installed]({{<ref install-dapr-cli.md>}}), it's time to initialize Dapr on your local machine using the CLI.
|
||||
|
||||
Dapr runs as a sidecar alongside your application, and in self-hosted mode this means it is a process on your local machine. Therefore, initializing Dapr includes fetching the Dapr sidecar binaries and installing them locally.
|
||||
|
||||
|
@ -29,11 +29,11 @@ This recommended development environment requires [Docker](https://docs.docker.c
|
|||
{{% codetab %}}
|
||||
If you run your Docker commands with sudo, or the install path is `/usr/local/bin` (default install path), you will need to use `sudo` below.
|
||||
{{% /codetab %}}
|
||||
|
||||
|
||||
{{% codetab %}}
|
||||
Make sure that you run Command Prompt as administrator (right click, run as administrator)
|
||||
{{% /codetab %}}
|
||||
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
### Step 2: Run the init CLI command
|
||||
|
|
|
@ -119,7 +119,9 @@ scopes:
|
|||
|
||||
## Example
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/8W-iBDNvCUM?start=1763" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
## Related links
|
||||
|
||||
|
|
|
@ -14,7 +14,10 @@ Using Dapr, you can control how many requests and events will invoke your applic
|
|||
*Note that rate limiting per second can be achieved by using the **middleware.http.ratelimit** middleware. However, there is an imporant difference between the two approaches. The rate limit middlware is time bound and limits the number of requests per second, while the `app-max-concurrency` flag specifies the number of concurrent requests (and events) at any point of time. See [Rate limit middleware]({{< ref middleware-rate-limit.md >}}). *
|
||||
|
||||
Watch this [video](https://youtu.be/yRI5g6o_jp8?t=1710) on how to control concurrency and rate limiting ".
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="764" height="430" src="https://www.youtube.com/embed/yRI5g6o_jp8?t=1710" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
## Setting app-max-concurrency
|
||||
|
||||
|
@ -58,4 +61,4 @@ To set app-max-concurrency with the Dapr CLI for running on your local dev machi
|
|||
dapr run --app-max-concurrency 1 --app-port 5000 python ./app.py
|
||||
```
|
||||
|
||||
The above examples will effectively turn your app into a single concurrent service.
|
||||
The above examples will effectively turn your app into a single concurrent service.
|
|
@ -11,7 +11,10 @@ Access control enables the configuration of policies that restrict what operatio
|
|||
An access control policy is specified in configuration and be applied to Dapr sidecar for the *called* application. Example access policies are shown below and access to the called app is based on the matched policy action. You can provide a default global action for all calling applications and if no access control policy is specified, the default behavior is to allow all calling applications to access to the called app.
|
||||
|
||||
Watch this [video](https://youtu.be/j99RN_nxExA?t=1108) on how to apply access control list for service invocation.
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="688" height="430" src="https://www.youtube.com/embed/j99RN_nxExA?start=1108" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
## Concepts
|
||||
|
||||
|
@ -353,4 +356,4 @@ spec:
|
|||
containers:
|
||||
- name: python
|
||||
image: dapriosamples/hello-k8s-python:edge
|
||||
```
|
||||
```
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Run Dapr in Self Hosted Mode"
|
||||
title: "Run Dapr in self-hosted mode"
|
||||
linkTitle: "Self-Hosted"
|
||||
weight: 1000
|
||||
description: "How to get Dapr up and running in your local environment"
|
||||
|
|
|
@ -20,16 +20,16 @@ The Dapr CLI provides an option to initialize Dapr using slim init, without the
|
|||
dapr init --slim
|
||||
```
|
||||
|
||||
In this mode two different binaries are installed `daprd` and `placement`. The `placement` binary is needed to enable [actors]({{< ref "actors-overview.md" >}}) in a Dapr self-hosted installation.
|
||||
In this mode two different binaries are installed `daprd` and `placement`. The `placement` binary is needed to enable [actors]({{< ref "actors-overview.md" >}}) in a Dapr self-hosted installation.
|
||||
|
||||
In this mode no default components such as Redis are installed for state management or pub/sub. This means, that aside from [Service Invocation]({{< ref "service-invocation-overview.md" >}}), no other building block functionality is available on install out of the box. Users are free to setup their own environment and custom components. Furthermore, actor based service invocation is possible if a state store is configured as explained in the following sections.
|
||||
|
||||
## Service invocation
|
||||
See [this sample](https://github.com/dapr/samples/tree/master/hello-dapr-slim) for an example on how to perform service invocation in this mode.
|
||||
See [this sample](https://github.com/dapr/samples/tree/master/hello-dapr-slim) for an example on how to perform service invocation in this mode.
|
||||
|
||||
## Enabling state management or pub/sub
|
||||
|
||||
See configuring Redis in self-hosted mode [without docker](https://redis.io/topics/quickstart) to enable a local state store or pub/sub broker for messaging.
|
||||
See configuring Redis in self-hosted mode [without docker](https://redis.io/topics/quickstart) to enable a local state store or pub/sub broker for messaging.
|
||||
|
||||
## Enabling actors
|
||||
|
||||
|
@ -51,7 +51,7 @@ INFO[0001] leader is established. instance=Nicoletaz-L10.
|
|||
|
||||
```
|
||||
|
||||
From here on you can follow the sample example created for the [java-sdk](https://github.com/dapr/java-sdk/tree/master/examples/src/main/java/io/dapr/examples/actors), [python-sdk](https://github.com/dapr/python-sdk/tree/master/examples/demo_actor) or [dotnet-sdk]({{< ref "dotnet-actors-howto.md" >}}) for running an application with Actors enabled.
|
||||
From here on you can follow the sample example created for the [java-sdk](https://github.com/dapr/java-sdk/tree/master/examples/src/main/java/io/dapr/examples/actors), [python-sdk](https://github.com/dapr/python-sdk/tree/master/examples/demo_actor) or [dotnet-sdk]({{< ref "dotnet-actors-howto.md" >}}) for running an application with Actors enabled.
|
||||
|
||||
Update the state store configuration files to have the Redis host and password match the setup that you have. Additionally to enable it as a actor state store have the metadata piece added similar to the [sample Java Redis component](https://github.com/dapr/java-sdk/blob/master/examples/components/state/redis.yaml) definition.
|
||||
|
||||
|
|
|
@ -8,7 +8,7 @@ description: "Overview of how to get Dapr running on a Windows/Linux/MacOS machi
|
|||
|
||||
## Overview
|
||||
|
||||
Dapr can be configured to run in self-hosted mode on your local developer machine or on production VMs. Each running service has a Dapr runtime process (or sidecar) which is configured to use state stores, pub/sub, binding components and the other building blocks.
|
||||
Dapr can be configured to run in self-hosted mode on your local developer machine or on production VMs. Each running service has a Dapr runtime process (or sidecar) which is configured to use state stores, pub/sub, binding components and the other building blocks.
|
||||
|
||||
## Initialization
|
||||
|
||||
|
@ -17,13 +17,13 @@ Dapr can be initialized [with Docker]({{< ref self-hosted-with-docker.md >}}) (d
|
|||
- A Zipkin container for diagnostics and tracing.
|
||||
- A default Dapr configuration and components installed in `$HOME/.dapr/` (Mac/Linux) or `%USERPROFILE%\.dapr\` (Windows).
|
||||
|
||||
The `dapr-placement` service is responsible for managing the actor distribution scheme and key range settings. This service is not launched as a container and is only required if you are using Dapr actors. For more information on the actor `Placement` service read [actor overview]({{< ref "actors-overview.md" >}}).
|
||||
The `dapr-placement` service is responsible for managing the actor distribution scheme and key range settings. This service is not launched as a container and is only required if you are using Dapr actors. For more information on the actor `Placement` service read [actor overview]({{< ref "actors-overview.md" >}}).
|
||||
|
||||
<img src="/images/overview-standalone-docker.png" width=1000 alt="Diagram of Dapr in self-hosted Docker mode" />
|
||||
|
||||
## Launching applications with Dapr
|
||||
|
||||
You can use the [`dapr run` CLI command]({{< ref dapr-run.md >}}) to a Dapr sidecar process along with your application. Additional arguments and flags can be found [here]({{< ref arguments-annotations-overview.md >}}).
|
||||
You can use the [`dapr run` CLI command]({{< ref dapr-run.md >}}) to a Dapr sidecar process along with your application. Additional arguments and flags can be found [here]({{< ref arguments-annotations-overview.md >}}).
|
||||
|
||||
## Name resolution
|
||||
|
||||
|
|
|
@ -12,7 +12,7 @@ description: "Follow these steps to upgrade Dapr in self-hosted mode and ensure
|
|||
{{% alert title="Note" color="warning" %}}
|
||||
This will remove the default `$HOME/.dapr` directory, binaries and all containers (dapr_redis, dapr_placement and dapr_zipkin). Linux users need to run `sudo` if docker command needs sudo.
|
||||
{{% /alert %}}
|
||||
|
||||
|
||||
```bash
|
||||
dapr uninstall --all
|
||||
```
|
||||
|
@ -29,7 +29,7 @@ description: "Follow these steps to upgrade Dapr in self-hosted mode and ensure
|
|||
|
||||
```bash
|
||||
$ dapr --version
|
||||
|
||||
|
||||
CLI version: 1.3
|
||||
Runtime version: 1.3
|
||||
```
|
||||
|
|
|
@ -74,5 +74,5 @@ By default, tailing is set to /var/log/containers/*.log. To change this setting,
|
|||
* [New Relic Account Signup](https://newrelic.com/signup)
|
||||
* [Telemetry Data Platform](https://newrelic.com/platform/telemetry-data-platform)
|
||||
* [New Relic Logging](https://github.com/newrelic/helm-charts/tree/master/charts/newrelic-logging)
|
||||
* [Types of New Relic API keys](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys)
|
||||
* [Types of New Relic API keys](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)
|
||||
* [Alerts and Applied Intelligence](https://docs.newrelic.com/docs/alerts-applied-intelligence)
|
||||
|
|
|
@ -173,4 +173,7 @@ First you need to connect Prometheus as a data source to Grafana.
|
|||
* [Supported Dapr metrics](https://github.com/dapr/dapr/blob/master/docs/development/dapr-metrics.md)
|
||||
|
||||
## Example
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/8W-iBDNvCUM?start=2577" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
|
@ -22,7 +22,7 @@ This document explains how to install it in your cluster, either using a Helm ch
|
|||
|
||||
2. Add the New Relic official Helm chart repository following [these instructions](https://github.com/newrelic/helm-charts/blob/master/README.md#installing-charts)
|
||||
|
||||
3. Run the following command to install the New Relic Logging Kubernetes plugin via Helm, replacing the placeholder value YOUR_LICENSE_KEY with your [New Relic license key](https://docs.newrelic.com/docs/accounts/accounts-billing/account-setup/new-relic-license-key/):
|
||||
3. Run the following command to install the New Relic Logging Kubernetes plugin via Helm, replacing the placeholder value YOUR_LICENSE_KEY with your [New Relic license key](https://docs.newrelic.com/docs/accounts/accounts-billing/account-setup/new-relic-license-key):
|
||||
|
||||
```bash
|
||||
helm install nri-prometheus newrelic/nri-prometheus --set licenseKey=YOUR_LICENSE_KEY
|
||||
|
@ -39,5 +39,5 @@ This document explains how to install it in your cluster, either using a Helm ch
|
|||
* [New Relic Account Signup](https://newrelic.com/signup)
|
||||
* [Telemetry Data Platform](https://newrelic.com/platform/telemetry-data-platform)
|
||||
* [New Relic Prometheus OpenMetrics Integration](https://github.com/newrelic/helm-charts/tree/master/charts/nri-prometheus)
|
||||
* [Types of New Relic API keys](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys)
|
||||
* [Types of New Relic API keys](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)
|
||||
* [Alerts and Applied Intelligence](https://docs.newrelic.com/docs/alerts-applied-intelligence)
|
||||
|
|
|
@ -111,9 +111,12 @@ dapr-prom-prometheus-server-694fd8d7c-q5d59 2/2 Running 0
|
|||
```
|
||||
|
||||
## Example
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/8W-iBDNvCUM?start=2577" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/8W-iBDNvCUM?start=2577" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
## References
|
||||
|
||||
* [Prometheus Installation](https://github.com/prometheus-community/helm-charts)
|
||||
* [Prometheus Query Language](https://prometheus.io/docs/prometheus/latest/querying/basics/)
|
||||
* [Prometheus Query Language](https://prometheus.io/docs/prometheus/latest/querying/basics/)
|
|
@ -7,16 +7,13 @@ description: "Set up Jaeger for distributed tracing"
|
|||
type: docs
|
||||
---
|
||||
|
||||
Dapr currently supports the Zipkin protocol. Since Jaeger is
|
||||
compatible with Zipkin, the Zipkin protocol can be used to talk to
|
||||
Jaeger.
|
||||
Dapr supports the Zipkin protocol. Since Jaeger is compatible with Zipkin, the Zipkin protocol can be used to communication with Jaeger.
|
||||
|
||||
## Configure self hosted mode
|
||||
|
||||
### Setup
|
||||
|
||||
The simplest way to start Jaeger is to use the pre-built all-in-one
|
||||
Jaeger image published to DockerHub:
|
||||
The simplest way to start Jaeger is to use the pre-built all-in-one Jaeger image published to DockerHub:
|
||||
|
||||
```bash
|
||||
docker run -d --name jaeger \
|
||||
|
@ -55,15 +52,19 @@ dapr run --app-id mynode --app-port 3000 node app.js --config config.yaml
|
|||
```
|
||||
|
||||
### Viewing Traces
|
||||
To view traces, in your browser go to http://localhost:16686 and you will see the Jaeger UI.
|
||||
To view traces, in your browser go to http://localhost:16686 to see the Jaeger UI.
|
||||
|
||||
## Configure Kubernetes
|
||||
The following steps shows you how to configure Dapr to send distributed tracing data to Jaeger running as a container in your Kubernetes cluster, how to view them.
|
||||
|
||||
### Setup
|
||||
|
||||
First create the following YAML file to install Jaeger
|
||||
* jaeger-operator.yaml
|
||||
First create the following YAML file to install Jaeger, file name is `jaeger-operator.yaml`
|
||||
|
||||
#### Development and test
|
||||
|
||||
By default, the allInOne Jaeger image uses memory as the backend storage and it is not recommended to use this in a production environment.
|
||||
|
||||
```yaml
|
||||
apiVersion: jaegertracing.io/v1
|
||||
kind: "Jaeger"
|
||||
|
@ -80,7 +81,54 @@ spec:
|
|||
base-path: /jaeger
|
||||
```
|
||||
|
||||
#### Production
|
||||
|
||||
Jaeger uses Elasticsearch as the backend storage, and you can create a secret in k8s cluster to access Elasticsearch server with access control. See [Configuring and Deploying Jaeger](https://docs.openshift.com/container-platform/4.7/jaeger/jaeger_install/rhbjaeger-deploying.html)
|
||||
|
||||
```shell
|
||||
kubectl create secret generic jaeger-secret --from-literal=ES_PASSWORD='xxx' --from-literal=ES_USERNAME='xxx' -n ${NAMESPACE}
|
||||
```
|
||||
|
||||
```yaml
|
||||
apiVersion: jaegertracing.io/v1
|
||||
kind: "Jaeger"
|
||||
metadata:
|
||||
name: jaeger
|
||||
spec:
|
||||
strategy: production
|
||||
query:
|
||||
options:
|
||||
log-level: info
|
||||
query:
|
||||
base-path: /jaeger
|
||||
collector:
|
||||
maxReplicas: 5
|
||||
resources:
|
||||
limits:
|
||||
cpu: 500m
|
||||
memory: 516Mi
|
||||
storage:
|
||||
type: elasticsearch
|
||||
esIndexCleaner:
|
||||
enabled: false ## turn the job deployment on and off
|
||||
numberOfDays: 7 ## number of days to wait before deleting a record
|
||||
schedule: "55 23 * * *" ## cron expression for it to run
|
||||
image: jaegertracing/jaeger-es-index-cleaner ## image of the job
|
||||
secretName: jaeger-secret
|
||||
options:
|
||||
es:
|
||||
server-urls: http://elasticsearch:9200
|
||||
```
|
||||
|
||||
The pictures are as follows, include Elasticsearch and Grafana tracing data:
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
|
||||
Now, use the above YAML file to install Jaeger
|
||||
|
||||
```bash
|
||||
# Install Jaeger
|
||||
helm repo add jaegertracing https://jaegertracing.github.io/helm-charts
|
||||
|
|
|
@ -14,7 +14,7 @@ description: "Set-up New Relic for distributed tracing"
|
|||
|
||||
Dapr natively captures metrics and traces that can be send directly to New Relic. The easiest way to export these is by configuring Dapr to send the traces to [New Relic's Trace API](https://docs.newrelic.com/docs/distributed-tracing/trace-api/report-zipkin-format-traces-trace-api/) using the Zipkin trace format.
|
||||
|
||||
In order for the integration to send data to New Relic [Telemetry Data Platform](https://newrelic.com/platform/telemetry-data-platform), you need a [New Relic Insights Insert API key](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys#insights-insert-key).
|
||||
In order for the integration to send data to New Relic [Telemetry Data Platform](https://newrelic.com/platform/telemetry-data-platform), you need a [New Relic Insights Insert API key](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/#insights-insert-key).
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
|
@ -39,7 +39,7 @@ New Relic Distributed Tracing details
|
|||
|
||||
## (optional) New Relic Instrumentation
|
||||
|
||||
In order for the integrations to send data to New Relic Telemetry Data Platform, you either need a [New Relic license key](https://docs.newrelic.com/docs/accounts/accounts-billing/account-setup/new-relic-license-key) or [New Relic Insights Insert API key](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys#insights-insert-key).
|
||||
In order for the integrations to send data to New Relic Telemetry Data Platform, you either need a [New Relic license key](https://docs.newrelic.com/docs/accounts/accounts-billing/account-setup/new-relic-license-key) or [New Relic Insights Insert API key](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/#insights-insert-key).
|
||||
|
||||
### OpenTelemetry instrumentation
|
||||
|
||||
|
@ -47,7 +47,7 @@ Leverage the different language specific OpenTelemetry implementations, for exam
|
|||
|
||||
### New Relic Language agent
|
||||
|
||||
Similarly to the OpenTelemetry instrumentation, you can also leverage a New Relic language agent. As an example, the [New Relic agent instrumentation for .NET Core](https://docs.newrelic.com/docs/agents/net-agent/other-installation/install-net-agent-docker-container/) is part of the Dockerfile. See example [here](https://github.com/harrykimpel/quickstarts/blob/master/distributed-calculator/csharp/Dockerfile).
|
||||
Similarly to the OpenTelemetry instrumentation, you can also leverage a New Relic language agent. As an example, the [New Relic agent instrumentation for .NET Core](https://docs.newrelic.com/docs/agents/net-agent/other-installation/install-net-agent-docker-container) is part of the Dockerfile. See example [here](https://github.com/harrykimpel/quickstarts/blob/master/distributed-calculator/csharp/Dockerfile).
|
||||
|
||||
## (optional) Enable New Relic Kubernetes integration
|
||||
|
||||
|
@ -109,6 +109,6 @@ All the data that is collected from Dapr, Kubernetes or any services that run on
|
|||
* [Telemetry Data Platform](https://newrelic.com/platform/telemetry-data-platform)
|
||||
* [Distributed Tracing](https://docs.newrelic.com/docs/distributed-tracing/concepts/introduction-distributed-tracing/)
|
||||
* [New Relic Trace API](https://docs.newrelic.com/docs/distributed-tracing/trace-api/introduction-trace-api/)
|
||||
* [Types of New Relic API keys](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys)
|
||||
* [Types of New Relic API keys](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)
|
||||
* [New Relic OpenTelemetry User Experience](https://blog.newrelic.com/product-news/opentelemetry-user-experience/)
|
||||
* [Alerts and Applied Intelligence](https://docs.newrelic.com/docs/alerts-applied-intelligence)
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Performance and Scalability"
|
||||
linkTitle: "Performance and Scalability"
|
||||
title: "Performance and scalability statistics of Dapr"
|
||||
linkTitle: "Performance and scalability"
|
||||
weight: 700
|
||||
description: "Benchmarks and guidelines for Dapr building blocks"
|
||||
---
|
||||
|
|
|
@ -223,6 +223,6 @@ In order for mDNS to function properly, ensure `Micorosft Content Filter` is ina
|
|||
- Type `mdatp system-extension network-filter disable` and hit enter.
|
||||
- Enter your account password.
|
||||
|
||||
Microsoft Content Filter is disabled when the output is "Success".
|
||||
Microsoft Content Filter is disabled when the output is "Success".
|
||||
|
||||
> Some organizations will re-enable the filter from time to time. If you repeatedly encounter app-id values missing, first check to see if the filter has been re-enabled before doing more extensive troubleshooting.
|
||||
> Some organizations will re-enable the filter from time to time. If you repeatedly encounter app-id values missing, first check to see if the filter has been re-enabled before doing more extensive troubleshooting.
|
||||
|
|
|
@ -10,35 +10,35 @@ aliases:
|
|||
|
||||
This table is meant to help users understand the equivalent options for running Dapr sidecars in different contexts--via the [CLI]({{< ref cli-overview.md >}}) directly, via daprd, or on [Kubernetes]({{< ref kubernetes-overview.md >}}) via annotations.
|
||||
|
||||
| daprd | dapr CLI | CLI shorthand | K8s annotations | Description
|
||||
|----- | ------- | -----------| ----------| ------------ | ------------ |
|
||||
| `--allowed-origins` | not supported | | not supported | Allowed HTTP origins (default "*") |
|
||||
| `--app-id` | `--app-id` | `-i` | `dapr.io/app-id` | The unique ID of the application. Used for service discovery, state encapsulation and the pub/sub consumer ID |
|
||||
| `--app-port` | `--app-port` | `-p` | `dapr.io/app-port` | This parameter tells Dapr which port your application is listening on |
|
||||
| daprd | Dapr CLI | CLI shorthand | Kubernetes annotations | Description
|
||||
|----- | ------- | -----------| ----------| ------------ |
|
||||
| `--allowed-origins` | not supported | | not supported | Allowed HTTP origins (default "*") |
|
||||
| `--app-id` | `--app-id` | `-i` | `dapr.io/app-id` | The unique ID of the application. Used for service discovery, state encapsulation and the pub/sub consumer ID |
|
||||
| `--app-port` | `--app-port` | `-p` | `dapr.io/app-port` | This parameter tells Dapr which port your application is listening on |
|
||||
| `--app-ssl` | `--app-ssl` | | `dapr.io/app-ssl` | Sets the URI scheme of the app to https and attempts an SSL connection |
|
||||
| `--components-path` | `--components-path` | `-d` | not supported | Path for components directory. If empty, components will not be loaded. |
|
||||
| `--config` | `--config` | `-c` | `dapr.io/config` | Tells Dapr which Configuration CRD to use |
|
||||
| `--control-plane-address` | not supported | | not supported | Address for a Dapr control plane |
|
||||
| `--dapr-grpc-port` | `--dapr-grpc-port` | | not supported | gRPC port for the Dapr API to listen on (default "50001") |
|
||||
| `--dapr-http-port` | `--dapr-http-port` | | not supported | The HTTP port for the Dapr API |
|
||||
|` --dapr-http-max-request-size` | --dapr-http-max-request-size | | `dapr.io/http-max-request-size` | Increasing max size of request body http and grpc servers parameter in MB to handle uploading of big files. Default is `4` MB |
|
||||
| not supported | `--image` | | not supported
|
||||
| `--internal-grpc-port` | not supported | | not supported | gRPC port for the Dapr Internal API to listen on |
|
||||
| `--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 |
|
||||
| `--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` |
|
||||
| `--components-path` | `--components-path` | `-d` | not supported | Path for components directory. If empty, components will not be loaded. |
|
||||
| `--config` | `--config` | `-c` | `dapr.io/config` | Tells Dapr which Configuration CRD to use |
|
||||
| `--control-plane-address` | not supported | | not supported | Address for a Dapr control plane |
|
||||
| `--dapr-grpc-port` | `--dapr-grpc-port` | | not supported | gRPC port for the Dapr API to listen on (default "50001") |
|
||||
| `--dapr-http-port` | `--dapr-http-port` | | not supported | The HTTP port for the Dapr API |
|
||||
|` --dapr-http-max-request-size` | --dapr-http-max-request-size | | `dapr.io/http-max-request-size` | Increasing max size of request body http and grpc servers parameter in MB to handle uploading of big files. Default is `4` MB |
|
||||
| not supported | `--image` | | not supported
|
||||
| `--internal-grpc-port` | not supported | | not supported | gRPC port for the Dapr Internal API to listen on |
|
||||
| `--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 |
|
||||
| `--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`
|
||||
| `--metrics-port` | `--metrics-port` | | `dapr.io/metrics-port` | Sets the port for the sidecar metrics server. Default is `9090` |
|
||||
| `--mode` | not supported | | not supported | Runtime mode for Dapr (default "standalone") |
|
||||
| `--placement-address` | `--placement-address` | | not supported | Addresses for Dapr Actor Placement servers |
|
||||
| `--profiling-port` | `--profiling-port` | | not supported | The port for the profile server (default "7777") |
|
||||
| `--app-protocol` | `--app-protocol` | `-P` | `dapr.io/app-protocol` | Tells Dapr which protocol your application is using. Valid options are `http` and `grpc`. Default is `http` |
|
||||
| `--sentry-address` | `--sentry-address` | | not supported | Address for the Sentry CA service |
|
||||
| `--version` | `--version` | `-v` | not supported | Prints the runtime version |
|
||||
| not supported | not supported | | `dapr.io/enabled` | Setting this paramater to true injects the Dapr sidecar into the pod |
|
||||
| not supported | not supported | | `dapr.io/api-token-secret` | Tells Dapr which Kubernetes secret to use for token based API authentication. By default this is not set |
|
||||
| `--metrics-port` | `--metrics-port` | | `dapr.io/metrics-port` | Sets the port for the sidecar metrics server. Default is `9090` |
|
||||
| `--mode` | not supported | | not supported | Runtime mode for Dapr (default "standalone") |
|
||||
| `--placement-address` | `--placement-address` | | not supported | Addresses for Dapr Actor Placement servers |
|
||||
| `--profiling-port` | `--profiling-port` | | not supported | The port for the profile server (default "7777") |
|
||||
| `--app-protocol` | `--app-protocol` | `-P` | `dapr.io/app-protocol` | Tells Dapr which protocol your application is using. Valid options are `http` and `grpc`. Default is `http` |
|
||||
| `--sentry-address` | `--sentry-address` | | not supported | Address for the Sentry CA service |
|
||||
| `--version` | `--version` | `-v` | not supported | Prints the runtime version |
|
||||
| not supported | not supported | | `dapr.io/enabled` | Setting this paramater to true injects the Dapr sidecar into the pod |
|
||||
| not supported | not supported | | `dapr.io/api-token-secret` | Tells Dapr which Kubernetes secret to use for token based API authentication. By default this is not set |
|
||||
| not supported | not supported | | `dapr.io/sidecar-cpu-limit` | Maximum amount of CPU that the Dapr sidecar can use. See valid values [here](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/). By default this is not set
|
||||
| not supported | not supported | | `dapr.io/sidecar-memory-limit` | Maximum amount of Memory that the Dapr sidecar can use. See valid values [here](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/). By default this is not set
|
||||
| not supported | not supported | | `dapr.io/sidecar-cpu-request` | Amount of CPU that the Dapr sidecar requests. See valid values [here](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/). By default this is not set
|
||||
|
|
|
@ -52,7 +52,7 @@ Use "dapr [command] --help" for more information about a command.
|
|||
|
||||
## Command Reference
|
||||
|
||||
You can learn more about each Dapr command from the links below.
|
||||
You can learn more about each Dapr command from the links below.
|
||||
|
||||
- [`dapr build-info`]({{< ref dapr-build-info.md >}})
|
||||
- [`dapr completion`]({{< ref dapr-completion.md >}})
|
||||
|
|
|
@ -26,7 +26,7 @@ dapr invoke [flags]
|
|||
| `--help`, `-h` | | | Print this help message |
|
||||
| `--method`, `-m` | | | The method to invoke |
|
||||
| `--data`, `-d` | | | The JSON serialized data string (optional) |
|
||||
| `--data-file`, `-f` | | | A file containing the JSON serialized data (optional)
|
||||
| `--data-file`, `-f` | | | A file containing the JSON serialized data (optional)
|
||||
| `--verb`, `-v` | | `POST` | The HTTP verb to use |
|
||||
|
||||
## Examples
|
||||
|
|
|
@ -7,7 +7,13 @@ description: "Detailed information on the upgrade CLI command"
|
|||
|
||||
## Description
|
||||
|
||||
Upgrade Dapr on supported hosting platforms.
|
||||
Upgrade or downgrade Dapr on supported hosting platforms.
|
||||
|
||||
{{% alert title="Warning" color="warning" %}}
|
||||
Version steps should be done incrementally, including minor versions as you upgrade or downgrade.
|
||||
|
||||
Prior to downgrading, confirm components are backwards compatible and application code does ultilize APIs that are not supported in previous versions of Dapr.
|
||||
{{% /alert %}}
|
||||
|
||||
## Supported platforms
|
||||
|
||||
|
@ -23,8 +29,8 @@ dapr upgrade [flags]
|
|||
| Name | Environment Variable | Default | Description
|
||||
| --- | --- | --- | --- |
|
||||
| `--help`, `-h` | | | Print this help message |
|
||||
| `--kubernetes`, `-k` | | `false` | Upgrade Dapr in a Kubernetes cluster |
|
||||
| `--runtime-version` | | `latest` | The version of the Dapr runtime to upgrade to, for example: `1.0.0` |
|
||||
| `--kubernetes`, `-k` | | `false` | Upgrade/Downgrade Dapr in a Kubernetes cluster |
|
||||
| `--runtime-version` | | `latest` | The version of the Dapr runtime to upgrade/downgrade to, for example: `1.0.0` |
|
||||
| `--set` | | | Set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) |
|
||||
|
||||
## Examples
|
||||
|
@ -34,15 +40,16 @@ dapr upgrade [flags]
|
|||
dapr upgrade -k
|
||||
```
|
||||
|
||||
### Upgrade specified version of Dapr runtime in Kubernetes
|
||||
### Upgrade or downgrade to a specified version of Dapr runtime in Kubernetes
|
||||
```bash
|
||||
dapr upgrade -k --runtime-version 1.2
|
||||
```
|
||||
|
||||
### Upgrade specified version of Dapr runtime in Kubernetes with value set
|
||||
### Upgrade or downgrade to a specified version of Dapr runtime in Kubernetes with value set
|
||||
```bash
|
||||
dapr upgrade -k --runtime-version 1.2 --set global.logAsJson=true
|
||||
```
|
||||
|
||||
# Related links
|
||||
|
||||
- [Upgrade Dapr on a Kubernetes cluster]({{< ref kubernetes-upgrade.md >}})
|
||||
- [Upgrade Dapr on a Kubernetes cluster]({{< ref kubernetes-upgrade.md >}})
|
|
@ -82,7 +82,7 @@ Table captions:
|
|||
|
||||
### Zeebe (Camunda Cloud)
|
||||
|
||||
| Name | Input<br>Binding | Output<br>Binding | Status | Component version | Since |
|
||||
| Name | Input<br>Binding | Output<br>Binding | Status | Component version | Since |
|
||||
|------|:----------------:|:-----------------:|--------| --------- | ---------- |
|
||||
| [Zeebe Command]({{< ref zeebe-command.md >}}) | | ✅ | Alpha | v1 | 1.2 |
|
||||
| [Zeebe Job Worker]({{< ref zeebe-jobworker.md >}}) | ✅ | | Alpha | v1 | 1.2 |
|
||||
|
|
|
@ -70,6 +70,8 @@ The above example uses secrets as plain strings. It is recommended to use a secr
|
|||
|
||||
## Binding support
|
||||
|
||||
This component supports both **input and output** binding interfaces.
|
||||
|
||||
This component supports **output binding** with the following operations:
|
||||
|
||||
- `create`
|
||||
|
|
|
@ -22,7 +22,7 @@ spec:
|
|||
version: v1
|
||||
metadata:
|
||||
- name: endpoint
|
||||
value: http://localhost:8080/v1/graphql
|
||||
value: http://localhost:8080/v1/graphql
|
||||
- name: header:x-hasura-access-key
|
||||
value: adminkey
|
||||
- name: header:Cache-Control
|
||||
|
|
|
@ -42,6 +42,8 @@ spec:
|
|||
value: "bcc@example.com"
|
||||
- name: subject
|
||||
value: "subject"
|
||||
- name: priority
|
||||
value: "[value 1-5]"
|
||||
```
|
||||
|
||||
{{% alert title="Warning" color="warning" %}}
|
||||
|
@ -62,6 +64,7 @@ The example configuration shown above, contain a username and password as plain-
|
|||
| emailCc | N | Output | If set, this specifies the email address to CC in. See [also](#example-request) | `"me@example.com"` |
|
||||
| emailBcc | N | Output | If set, this specifies email address to BCC in. See [also](#example-request) | `"me@example.com"` |
|
||||
| subject | N | Output | If set, this specifies the subject of the email message. See [also](#example-request) | `"subject of mail"` |
|
||||
| priority | N | Output | If set, this specifies the priority (X-Priority) of the email message, from 1 (lowest) to 5 (highest) (default value: 3). See [also](#example-request) | `"1"` |
|
||||
|
||||
## Binding support
|
||||
|
||||
|
@ -78,6 +81,7 @@ You can specify any of the following optional metadata properties with each requ
|
|||
- `emailCC`
|
||||
- `emailBCC`
|
||||
- `subject`
|
||||
- `priority`
|
||||
|
||||
When sending an email, the metadata in the configuration and in the request is combined. The combined set of metadata must contain at least the `emailFrom`, `emailTo` and `subject` fields.
|
||||
|
||||
|
@ -90,7 +94,8 @@ Example:
|
|||
"metadata": {
|
||||
"emailTo": "dapr-smtp-binding@example.net",
|
||||
"emailCC": "cc1@example.net; cc2@example.net",
|
||||
"subject": "Email subject"
|
||||
"subject": "Email subject",
|
||||
"priority: "1"
|
||||
},
|
||||
"data": "Testing Dapr SMTP Binding"
|
||||
}
|
||||
|
|
|
@ -35,10 +35,10 @@ spec:
|
|||
|
||||
| Field | Required | Binding support | Details | Example |
|
||||
|-------------------------|:--------:|------------|-----|---------|
|
||||
| gatewayAddr | Y | Output | Zeebe gateway address | `localhost:26500` |
|
||||
| gatewayKeepAlive | N | Output | Sets how often keep alive messages should be sent to the gateway. Defaults to 45 seconds | `45s` |
|
||||
| usePlainTextConnection | N | Output | Whether to use a plain text connection or not | `true,false` |
|
||||
| caCertificatePath | N | Output | The path to the CA cert | `/path/to/ca-cert` |
|
||||
| gatewayAddr | Y | Output | Zeebe gateway address | `localhost:26500` |
|
||||
| gatewayKeepAlive | N | Output | Sets how often keep alive messages should be sent to the gateway. Defaults to 45 seconds | `45s` |
|
||||
| usePlainTextConnection | N | Output | Whether to use a plain text connection or not | `true,false` |
|
||||
| caCertificatePath | N | Output | The path to the CA cert | `/path/to/ca-cert` |
|
||||
|
||||
## Binding support
|
||||
|
||||
|
@ -59,7 +59,7 @@ This component supports **output binding** with the following operations:
|
|||
|
||||
### Output binding
|
||||
|
||||
Zeebe uses gRPC under the hood for the Zeebe client we use in this binding. Please consult the [gRPC API reference](https://stage.docs.zeebe.io/reference/grpc.html) for more information.
|
||||
Zeebe uses gRPC under the hood for the Zeebe client we use in this binding. Please consult the [gRPC API reference](https://stage.docs.zeebe.io/reference/grpc.html) for more information.
|
||||
|
||||
#### topology
|
||||
|
||||
|
@ -161,7 +161,7 @@ The response values are:
|
|||
|
||||
- `key` - the unique key identifying the deployment
|
||||
- `processes` - a list of deployed processes
|
||||
- `bpmnProcessId` - the bpmn process ID, as parsed during deployment; together with the version forms a unique identifier for a specific
|
||||
- `bpmnProcessId` - the bpmn process ID, as parsed during deployment; together with the version forms a unique identifier for a specific
|
||||
process definition
|
||||
- `version` - the assigned process version
|
||||
- `processDefinitionKey` - the assigned key, which acts as a unique identifier for this process
|
||||
|
@ -169,7 +169,7 @@ The response values are:
|
|||
|
||||
#### create-instance
|
||||
|
||||
The `create-instance` operation creates and starts an instance of the specified process. The process definition to use to create the instance can be
|
||||
The `create-instance` operation creates and starts an instance of the specified process. The process definition to use to create the instance can be
|
||||
specified either using its unique key (as returned by the `deploy-process` operation), or using the BPMN process ID and a version.
|
||||
|
||||
Note that only processes with none start events can be started through this command.
|
||||
|
@ -296,7 +296,7 @@ To perform a `set-variables` operation, invoke the Zeebe command binding with a
|
|||
|
||||
The data parameters are:
|
||||
|
||||
- `elementInstanceKey` - the unique identifier of a particular element; can be the process instance key (as
|
||||
- `elementInstanceKey` - the unique identifier of a particular element; can be the process instance key (as
|
||||
obtained during instance creation), or a given element, such as a service task (see elementInstanceKey on the job message)
|
||||
- `local` - (optional, default: `false`) if true, the variables will be merged strictly into the local scope (as indicated by
|
||||
elementInstanceKey); this means the variables is not propagated to upper scopes.
|
||||
|
@ -369,7 +369,7 @@ The data parameters are:
|
|||
- `messageName` - the name of the message
|
||||
- `correlationKey` - (optional) the correlation key of the message
|
||||
- `timeToLive` - (optional) how long the message should be buffered on the broker
|
||||
- `messageId` - (optional) the unique ID of the message; can be omitted. only useful to ensure only one message with the given ID will ever
|
||||
- `messageId` - (optional) the unique ID of the message; can be omitted. only useful to ensure only one message with the given ID will ever
|
||||
be published (during its lifetime)
|
||||
- `variables` - (optional) the message variables as a JSON document; to be valid, the root of the document must be an object, e.g. { "a": "foo" }.
|
||||
[ "foo" ] would not be valid
|
||||
|
@ -390,7 +390,7 @@ The response values are:
|
|||
|
||||
#### activate-jobs
|
||||
|
||||
The `activate-jobs` operation iterates through all known partitions round-robin and activates up to the requested maximum and streams them back to
|
||||
The `activate-jobs` operation iterates through all known partitions round-robin and activates up to the requested maximum and streams them back to
|
||||
the client as they are activated.
|
||||
|
||||
To perform a `activate-jobs` operation, invoke the Zeebe command binding with a `POST` method, and the following JSON body:
|
||||
|
@ -419,7 +419,7 @@ The data parameters are:
|
|||
- `maxJobsToActivate` - the maximum jobs to activate by this request
|
||||
- `timeout` - (optional, default: 5 minutes) a job returned after this call will not be activated by another call until the timeout has been reached
|
||||
- `workerName` - (optional, default: `default`) the name of the worker activating the jobs, mostly used for logging purposes
|
||||
- `fetchVariables` - (optional) a list of variables to fetch as the job variables; if empty, all visible variables at the time of activation for the
|
||||
- `fetchVariables` - (optional) a list of variables to fetch as the job variables; if empty, all visible variables at the time of activation for the
|
||||
scope of the job will be returned
|
||||
|
||||
##### Response
|
||||
|
@ -429,7 +429,7 @@ The binding returns a JSON with the following response:
|
|||
```json
|
||||
[
|
||||
{
|
||||
|
||||
|
||||
}
|
||||
]
|
||||
```
|
||||
|
@ -482,8 +482,8 @@ The binding does not return a response body.
|
|||
|
||||
#### fail-job
|
||||
|
||||
The `fail-job` operation marks the job as failed; if the retries argument is positive, then the job will be immediately activatable again, and a
|
||||
worker could try again to process it. If it is zero or negative however, an incident will be raised, tagged with the given errorMessage, and the
|
||||
The `fail-job` operation marks the job as failed; if the retries argument is positive, then the job will be immediately activatable again, and a
|
||||
worker could try again to process it. If it is zero or negative however, an incident will be raised, tagged with the given errorMessage, and the
|
||||
job will not be activatable until the incident is resolved.
|
||||
|
||||
To perform a `fail-job` operation, invoke the Zeebe command binding with a `POST` method, and the following JSON body:
|
||||
|
@ -504,7 +504,7 @@ The data parameters are:
|
|||
|
||||
- `jobKey` - the unique job identifier, as obtained when activating the job
|
||||
- `retries` - the amount of retries the job should have left
|
||||
- `errorMessage ` - (optional) an message describing why the job failed this is particularly useful if a job runs out of retries and an
|
||||
- `errorMessage ` - (optional) an message describing why the job failed this is particularly useful if a job runs out of retries and an
|
||||
incident is raised, as it this message can help explain why an incident was raised
|
||||
|
||||
##### Response
|
||||
|
@ -513,7 +513,7 @@ The binding does not return a response body.
|
|||
|
||||
#### update-job-retries
|
||||
|
||||
The `update-job-retries` operation updates the number of retries a job has left. This is mostly useful for jobs that have run out of retries, should the
|
||||
The `update-job-retries` operation updates the number of retries a job has left. This is mostly useful for jobs that have run out of retries, should the
|
||||
underlying problem be solved.
|
||||
|
||||
To perform a `update-job-retries` operation, invoke the Zeebe command binding with a `POST` method, and the following JSON body:
|
||||
|
@ -540,7 +540,7 @@ The binding does not return a response body.
|
|||
|
||||
#### throw-error
|
||||
|
||||
The `throw-error` operation throw an error to indicate that a business error is occurred while processing the job. The error is identified
|
||||
The `throw-error` operation throw an error to indicate that a business error is occurred while processing the job. The error is identified
|
||||
by an error code and is handled by an error catch event in the process with the same error code.
|
||||
|
||||
To perform a `throw-error` operation, invoke the Zeebe command binding with a `POST` method, and the following JSON body:
|
||||
|
|
|
@ -53,19 +53,19 @@ spec:
|
|||
|
||||
| Field | Required | Binding support | Details | Example |
|
||||
|-------------------------|:--------:|------------|-----|---------|
|
||||
| gatewayAddr | Y | Input | Zeebe gateway address | `localhost:26500` |
|
||||
| gatewayKeepAlive | N | Input | Sets how often keep alive messages should be sent to the gateway. Defaults to 45 seconds | `45s` |
|
||||
| usePlainTextConnection | N | Input | Whether to use a plain text connection or not | `true,false` |
|
||||
| caCertificatePath | N | Input | The path to the CA cert | `/path/to/ca-cert` |
|
||||
| workerName | N | Input | The name of the worker activating the jobs, mostly used for logging purposes | `products-worker` |
|
||||
| workerTimeout | N | Input | A job returned after this call will not be activated by another call until the timeout has been reached; defaults to 5 minutes | `5m` |
|
||||
| requestTimeout | N | Input | The request will be completed when at least one job is activated or after the requestTimeout. If the requestTimeout = 0, a default timeout is used. If the requestTimeout < 0, long polling is disabled and the request is completed immediately, even when no job is activated. Defaults to 10 seconds | `30s` |
|
||||
| jobType | Y | Input | the job type, as defined in the BPMN process (e.g. `<zeebe:taskDefinition type="fetch-products" />`) | `fetch-products` |
|
||||
| maxJobsActive | N | Input | Set the maximum number of jobs which will be activated for this worker at the same time. Defaults to 32 | `32` |
|
||||
| concurrency | N | Input | The maximum number of concurrent spawned goroutines to complete jobs. Defaults to 4 | `4` |
|
||||
| pollInterval | N | Input | Set the maximal interval between polling for new jobs. Defaults to 100 milliseconds | `100ms` |
|
||||
| pollThreshold | N | Input | Set the threshold of buffered activated jobs before polling for new jobs, i.e. threshold * maxJobsActive. Defaults to 0.3 | `0.3` |
|
||||
| fetchVariables | N | Input | A list of variables to fetch as the job variables; if empty, all visible variables at the time of activation for the scope of the job will be returned | `productId, productName, productKey` |
|
||||
| gatewayAddr | Y | Input | Zeebe gateway address | `localhost:26500` |
|
||||
| gatewayKeepAlive | N | Input | Sets how often keep alive messages should be sent to the gateway. Defaults to 45 seconds | `45s` |
|
||||
| usePlainTextConnection | N | Input | Whether to use a plain text connection or not | `true,false` |
|
||||
| caCertificatePath | N | Input | The path to the CA cert | `/path/to/ca-cert` |
|
||||
| workerName | N | Input | The name of the worker activating the jobs, mostly used for logging purposes | `products-worker` |
|
||||
| workerTimeout | N | Input | A job returned after this call will not be activated by another call until the timeout has been reached; defaults to 5 minutes | `5m` |
|
||||
| requestTimeout | N | Input | The request will be completed when at least one job is activated or after the requestTimeout. If the requestTimeout = 0, a default timeout is used. If the requestTimeout < 0, long polling is disabled and the request is completed immediately, even when no job is activated. Defaults to 10 seconds | `30s` |
|
||||
| jobType | Y | Input | the job type, as defined in the BPMN process (e.g. `<zeebe:taskDefinition type="fetch-products" />`) | `fetch-products` |
|
||||
| maxJobsActive | N | Input | Set the maximum number of jobs which will be activated for this worker at the same time. Defaults to 32 | `32` |
|
||||
| concurrency | N | Input | The maximum number of concurrent spawned goroutines to complete jobs. Defaults to 4 | `4` |
|
||||
| pollInterval | N | Input | Set the maximal interval between polling for new jobs. Defaults to 100 milliseconds | `100ms` |
|
||||
| pollThreshold | N | Input | Set the threshold of buffered activated jobs before polling for new jobs, i.e. threshold * maxJobsActive. Defaults to 0.3 | `0.3` |
|
||||
| fetchVariables | N | Input | A list of variables to fetch as the job variables; if empty, all visible variables at the time of activation for the scope of the job will be returned | `productId, productName, productKey` |
|
||||
|
||||
## Binding support
|
||||
|
||||
|
@ -75,10 +75,10 @@ This component supports **input** binding interfaces.
|
|||
|
||||
#### Variables
|
||||
|
||||
The Zeebe process engine handles the process state as also process variables which can be passed
|
||||
The Zeebe process engine handles the process state as also process variables which can be passed
|
||||
on process instantiation or which can be updated or created during process execution. These variables
|
||||
can be passed to a registered job worker by defining the variable names as comma-separated list in
|
||||
the `fetchVariables` metadata field. The process engine will then pass these variables with its current
|
||||
the `fetchVariables` metadata field. The process engine will then pass these variables with its current
|
||||
values to the job worker implementation.
|
||||
|
||||
If the binding will register three variables `productId`, `productName` and `productKey` then the worker will
|
||||
|
@ -86,9 +86,9 @@ be called with the following JSON body:
|
|||
|
||||
```json
|
||||
{
|
||||
"productId": "some-product-id",
|
||||
"productName": "some-product-name",
|
||||
"productKey": "some-product-key"
|
||||
"productId": "some-product-id",
|
||||
"productName": "some-product-name",
|
||||
"productKey": "some-product-key"
|
||||
}
|
||||
```
|
||||
|
||||
|
|
|
@ -61,7 +61,7 @@ spec:
|
|||
my_claim := jwt.payload["my-claim"]
|
||||
}
|
||||
jwt = { "payload": payload } {
|
||||
auth_header := input.request.headers["authorization"]
|
||||
auth_header := input.request.headers["Authorization"]
|
||||
[_, jwt] := split(auth_header, " ")
|
||||
[_, payload, _] := io.jwt.decode(jwt)
|
||||
}
|
||||
|
@ -75,7 +75,7 @@ You can prototype and experiment with policies using the [official opa playgroun
|
|||
|--------|---------|---------|
|
||||
| rego | The Rego policy language | See above |
|
||||
| defaultStatus | The status code to return for denied responses | `"https://accounts.google.com"`, `"https://login.salesforce.com"`
|
||||
| includedHeaders | A comma-separated set of case-insensitive headers to include in the request input. Request headers are not passed to the policy by default. Include to receive incoming request headers in the input | `"x-my-custom-header, x-jwt-header"`
|
||||
| includedHeaders | A comma-separated set of case-insensitive headers to include in the request input. Request headers are not passed to the policy by default. Include to receive incoming request headers in the input | `"x-my-custom-header, x-jwt-header"`
|
||||
|
||||
## Dapr configuration
|
||||
|
||||
|
|
|
@ -97,7 +97,7 @@ spec:
|
|||
meta:
|
||||
DAPR_METRICS_PORT: "${DAPR_METRICS_PORT}"
|
||||
DAPR_PROFILE_PORT: "${DAPR_PROFILE_PORT}"
|
||||
daprPortMetaKey: "DAPR_PORT"
|
||||
daprPortMetaKey: "DAPR_PORT"
|
||||
queryOptions:
|
||||
useCache: true
|
||||
filter: "Checks.ServiceTags contains dapr"
|
||||
|
|
|
@ -8,7 +8,7 @@ aliases:
|
|||
---
|
||||
|
||||
## Default Kubernetes secret store component
|
||||
When Dapr is deployed to a Kubernetes cluster, a secret store with the name `kubernetes` is automatically provisioned. This pre-provisioned secret store allows you to use the native Kubernetes secret store with no need to author, deploy or maintain a component configuration file for the secret store and is useful for developers looking to simply access secrets stored natively in a Kubernetes cluster.
|
||||
When Dapr is deployed to a Kubernetes cluster, a secret store with the name `kubernetes` is automatically provisioned. This pre-provisioned secret store allows you to use the native Kubernetes secret store with no need to author, deploy or maintain a component configuration file for the secret store and is useful for developers looking to simply access secrets stored natively in a Kubernetes cluster.
|
||||
|
||||
A custom component definition file for a Kubernetes secret store can still be configured (See below for details). Using a custom definition decouples referencing the secret store in your code from the hosting platform as the store name is not fixed and can be customized, keeping you code more generic and portable. Additionally, by explicitly defining a Kubernetes secret store component you can connect to a Kubernetes secret store from a local Dapr self-hosted installation. This requires a valid [`kubeconfig`](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) file.
|
||||
|
||||
|
|
|
@ -83,7 +83,7 @@ docker run --name some-mongo -d mongo
|
|||
|
||||
You can then interact with the server using `localhost:27017`.
|
||||
|
||||
If you do not specify a `databaseName` value in your component definition, make sure to create a database named `daprStore`.
|
||||
If you do not specify a `databaseName` value in your component definition, make sure to create a database named `daprStore`.
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
|
|
Binary file not shown.
After Width: | Height: | Size: 447 KiB |
Binary file not shown.
After Width: | Height: | Size: 587 KiB |
Loading…
Reference in New Issue