mirror of https://github.com/dapr/docs.git
Merge branch 'v1.3' into update_kibana_docs
This commit is contained in:
Ori Zohar
GitHub
commit
70593a3acb
|
|
@ -3,11 +3,11 @@ name: Azure Static Web App Root
|
|||
on:
|
||||
push:
|
||||
branches:
|
||||
- v1.2
|
||||
- v1.3
|
||||
pull_request:
|
||||
types: [opened, synchronize, reopened, closed]
|
||||
branches:
|
||||
- v1.2
|
||||
- v1.3
|
||||
|
||||
jobs:
|
||||
build_and_deploy_job:
|
||||
|
|
|
|||
|
|
@ -4,3 +4,4 @@
|
|||
node_modules/
|
||||
daprdocs/public
|
||||
daprdocs/resources/_gen
|
||||
.venv/
|
||||
|
|
|
|||
|
|
@ -17,3 +17,6 @@
|
|||
[submodule "sdkdocs/go"]
|
||||
path = sdkdocs/go
|
||||
url = https://github.com/dapr/go-sdk.git
|
||||
[submodule "sdkdocs/java"]
|
||||
path = sdkdocs/java
|
||||
url = https://github.com/dapr/java-sdk.git
|
||||
|
|
|
|||
|
|
@ -1,2 +0,0 @@
|
|||
# These owners are the maintainers and approvers of this repo
|
||||
* @maintainers-docs @approvers-docs
|
||||
|
|
@ -14,8 +14,8 @@ The following branches are currently maintained:
|
|||
|
||||
| Branch | Website | Description |
|
||||
|--------|---------|-------------|
|
||||
| [v1.2](https://github.com/dapr/docs) (primary) | https://docs.dapr.io | Latest Dapr release documentation. Typo fixes, clarifications, and most documentation goes here.
|
||||
| [v1.3](https://github.com/dapr/docs/tree/v1.3) (pre-release) | https://v1-3.docs.dapr.io/ | Pre-release documentation. Doc updates that are only applicable to v1.3+ go here.
|
||||
| [v1.3](https://github.com/dapr/docs) (primary) | https://docs.dapr.io | Latest Dapr release documentation. Typo fixes, clarifications, and most documentation goes here.
|
||||
| [v1.4](https://github.com/dapr/docs/tree/v1.4) (pre-release) | https://v1-4.docs.dapr.io/ | Pre-release documentation. Doc updates that are only applicable to v1.4+ go here.
|
||||
|
||||
For more information visit the [Dapr branch structure](https://docs.dapr.io/contributing/contributing-docs/#branch-guidance) document.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
# Site Configuration
|
||||
baseURL = "https://v1-3.docs.dapr.io/"
|
||||
baseURL = "https://docs.dapr.io/"
|
||||
title = "Dapr Docs"
|
||||
theme = "docsy"
|
||||
disableFastRender = true
|
||||
|
|
@ -79,6 +79,14 @@ id = "UA-149338238-3"
|
|||
source = "../sdkdocs/go/daprdocs/content/en/go-sdk-contributing"
|
||||
target = "content/contributing/"
|
||||
lang = "en"
|
||||
[[module.mounts]]
|
||||
source = "../sdkdocs/java/daprdocs/content/en/java-sdk-docs"
|
||||
target = "content/developing-applications/sdks/java"
|
||||
lang = "en"
|
||||
[[module.mounts]]
|
||||
source = "../sdkdocs/java/daprdocs/content/en/java-sdk-contributing"
|
||||
target = "content/contributing/"
|
||||
lang = "en"
|
||||
|
||||
[[module.mounts]]
|
||||
source = "../translations/docs-zh/content/zh-hans"
|
||||
|
|
@ -144,17 +152,20 @@ github_subdir = "daprdocs"
|
|||
github_branch = "v1.3"
|
||||
|
||||
# Versioning
|
||||
version_menu = "v1.3 (preview)"
|
||||
version_menu = "v1.3 (latest)"
|
||||
version = "v1.3"
|
||||
archived_version = false
|
||||
url_latest_version = "https://docs.dapr.io"
|
||||
|
||||
[[params.versions]]
|
||||
version = "v1.3 (preview)"
|
||||
version = "v1.4 (preview)"
|
||||
url = "https://v1-4.docs.dapr.io"
|
||||
[[params.versions]]
|
||||
version = "v1.3 (latest)"
|
||||
url = "#"
|
||||
[[params.versions]]
|
||||
version = "v1.2 (latest)"
|
||||
url = "https://docs.dapr.io"
|
||||
version = "v1.2"
|
||||
url = "https://v1-2.docs.dapr.io"
|
||||
[[params.versions]]
|
||||
version = "v1.1"
|
||||
url = "https://v1-1.docs.dapr.io"
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ Dapr can be used from any developer framework. Here are some that have been inte
|
|||
| Language | Frameworks | Description |
|
||||
|----------|------------|-------------|
|
||||
| [.NET]({{< ref dotnet >}}) | [ASP.NET]({{< ref dotnet-aspnet.md >}}) | Brings stateful routing controllers that respond to pub/sub events from other services. Can also take advantage of [ASP.NET Core gRPC Services](https://docs.microsoft.com/en-us/aspnet/core/grpc/).
|
||||
| [Java](https://github.com/dapr/java-sdk) | [Spring Boot](https://spring.io/)
|
||||
| [Java]({{< ref java >}}) | [Spring Boot](https://spring.io/)
|
||||
| [Python]({{< ref python >}}) | [Flask]({{< ref python-flask.md >}})
|
||||
| [Javascript](https://github.com/dapr/js-sdk) | [Express](http://expressjs.com/)
|
||||
| [PHP]({{< ref php >}}) | | You can serve with Apache, Nginx, or Caddyserver.
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ Refer [api spec]({{< ref "actors_api.md#invoke-timer" >}}) for more details.
|
|||
|
||||
### Actor reminders
|
||||
|
||||
Reminders are a mechanism to trigger *persistent* callbacks on an actor at specified times. Their functionality is similar to timers. But unlike timers, reminders are triggered under all circumstances until the actor explicitly unregisters them or the actor is explicitly deleted. Specifically, reminders are triggered across actor deactivations and failovers because the Dapr actors runtime persists the information about the actors' reminders using Dapr actor state provider.
|
||||
Reminders are a mechanism to trigger *persistent* callbacks on an actor at specified times. Their functionality is similar to timers. But unlike timers, reminders are triggered under all circumstances until the actor explicitly unregisters them or the actor is explicitly deleted or the number in invocations is exhausted. Specifically, reminders are triggered across actor deactivations and failovers because the Dapr actors runtime persists the information about the actors' reminders using Dapr actor state provider.
|
||||
|
||||
You can create a persistent reminder for an actor by calling the Http/gRPC request to Dapr.
|
||||
|
||||
|
|
@ -111,6 +111,34 @@ The following request body configures a reminder with a `dueTime` 15 seconds and
|
|||
}
|
||||
```
|
||||
|
||||
[ISO 8601 duration](https://en.wikipedia.org/wiki/ISO_8601#Durations) can also be used to specify `period`. The following request body configures a reminder with a `dueTime` 0 seconds an `period` of 15 seconds.
|
||||
```json
|
||||
{
|
||||
"dueTime":"0h0m0s0ms",
|
||||
"period":"P0Y0M0W0DT0H0M15S"
|
||||
}
|
||||
```
|
||||
The designators for zero are optional and the above `period` can be simplified to `PT15S`.
|
||||
ISO 8601 specifies multiple recurrence formats but only the duration format is currently supported.
|
||||
|
||||
#### Reminders with repetitions
|
||||
|
||||
When configured with ISO 8601 durations, the `period` column also allows to specify number of times a reminder can run. The following request body will create a reminder that will execute for 5 number of times with a period of 15 seconds.
|
||||
```json
|
||||
{
|
||||
"dueTime":"0h0m0s0ms",
|
||||
"period":"R5/PT15S"
|
||||
}
|
||||
```
|
||||
|
||||
The number of repetitions i.e. the number of times the reminder is run should be a positive number.
|
||||
|
||||
**Example**
|
||||
|
||||
Watch this [video](https://www.youtube.com/watch?v=B_vkXqptpXY&t=1002s) for more information on using ISO 861 for Reminders
|
||||
|
||||
<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>
|
||||
|
||||
#### Retrieve actor reminder
|
||||
|
||||
You can retrieve the actor reminder by calling
|
||||
|
|
@ -139,6 +167,8 @@ You can configure the Dapr Actors runtime configuration to modify the default ru
|
|||
- `drainOngoingCallTimeout` - The duration when in the process of draining rebalanced actors. This specifies the timeout for the current active actor method to finish. If there is no current actor method call, this is ignored. **Default: 60 seconds**
|
||||
- `drainRebalancedActors` - If true, Dapr will wait for `drainOngoingCallTimeout` duration to allow a current actor call to complete before trying to deactivate an actor. **Default: true**
|
||||
- `reentrancy` (ActorReentrancyConfig) - Configure the reentrancy behavior for an actor. If not provided, reentrancy is diabled. **Default: disabled**
|
||||
**Default: 0**
|
||||
- `remindersStoragePartitions` - Configure the number of partitions for actor's reminders. If not provided, all reminders are saved as a single record in actor's state store. **Default: 0**
|
||||
|
||||
{{< tabs Java Dotnet Python >}}
|
||||
|
||||
|
|
@ -152,6 +182,7 @@ ActorRuntime.getInstance().getConfig().setActorScanInterval(Duration.ofSeconds(3
|
|||
ActorRuntime.getInstance().getConfig().setDrainOngoingCallTimeout(Duration.ofSeconds(60));
|
||||
ActorRuntime.getInstance().getConfig().setDrainBalancedActors(true);
|
||||
ActorRuntime.getInstance().getConfig().setActorReentrancyConfig(false, null);
|
||||
ActorRuntime.getInstance().getConfig().setRemindersStoragePartitions(7);
|
||||
```
|
||||
|
||||
See [this example](https://github.com/dapr/java-sdk/blob/master/examples/src/main/java/io/dapr/examples/actors/DemoActorService.java)
|
||||
|
|
@ -173,6 +204,7 @@ public void ConfigureServices(IServiceCollection services)
|
|||
options.ActorScanInterval = TimeSpan.FromSeconds(30);
|
||||
options.DrainOngoingCallTimeout = TimeSpan.FromSeconds(60);
|
||||
options.DrainRebalancedActors = true;
|
||||
options.RemindersStoragePartitions = 7;
|
||||
// reentrancy not implemented in the .NET SDK at this time
|
||||
});
|
||||
|
||||
|
|
@ -194,7 +226,8 @@ ActorRuntime.set_actor_config(
|
|||
actor_scan_interval=timedelta(seconds=30),
|
||||
drain_ongoing_call_timeout=timedelta(minutes=1),
|
||||
drain_rebalanced_actors=True,
|
||||
reentrancy=ActorReentrancyConfig(enabled=False)
|
||||
reentrancy=ActorReentrancyConfig(enabled=False),
|
||||
remindersStoragePartitions=7
|
||||
)
|
||||
)
|
||||
```
|
||||
|
|
@ -203,3 +236,153 @@ ActorRuntime.set_actor_config(
|
|||
{{< /tabs >}}
|
||||
|
||||
Refer to the documentation and examples of the [Dapr SDKs]({{< ref "developing-applications/sdks/#sdk-languages" >}}) for more details.
|
||||
|
||||
## Partitioning reminders
|
||||
|
||||
{{% alert title="Preview feature" color="warning" %}}
|
||||
Actor reminders partitioning is currently in [preview]({{< ref preview-features.md >}}). Use this feature if you are runnining into issues due to a high number of reminders registered.
|
||||
{{% /alert %}}
|
||||
|
||||
Actor reminders are persisted and continue to be triggered after sidecar restarts. Prior to Dapr runtime version 1.3, reminders were persisted on a single record in the actor state store:
|
||||
|
||||
| Key | Value |
|
||||
| ----------- | ----------- |
|
||||
| `actors\|\|<actor type>` | `[ <reminder 1>, <reminder 2>, ... , <reminder n> ]` |
|
||||
|
||||
Applications that register many reminders can experience the following issues:
|
||||
|
||||
* Low throughput on reminders registration and deregistration
|
||||
* Limit on total number of reminders registered based on the single record size limit on the state store
|
||||
|
||||
Since version 1.3, applications can now enable partitioning of actor reminders in the state store. As data is distributed in multiple keys in the state store. First, there is a metadata record in `actors\|\|<actor type>\|\|metadata` that is used to store persisted configuration for a given actor type. Then, there are multiple records that stores subsets of the reminders for the same actor type.
|
||||
|
||||
| Key | Value |
|
||||
| ----------- | ----------- |
|
||||
| `actors\|\|<actor type>\|\|metadata` | `{ "id": <actor metadata identifier>, "actorRemindersMetadata": { "partitionCount": <number of partitions for reminders> } }` |
|
||||
| `actors\|\|<actor type>\|\|<actor metadata identifier>\|\|reminders\|\|1` | `[ <reminder 1-1>, <reminder 1-2>, ... , <reminder 1-n> ]` |
|
||||
| `actors\|\|<actor type>\|\|<actor metadata identifier>\|\|reminders\|\|2` | `[ <reminder 1-1>, <reminder 1-2>, ... , <reminder 1-m> ]` |
|
||||
| ... | ... |
|
||||
|
||||
If the number of partitions is not enough, it can be changed and Dapr's sidecar will automatically redistribute the reminders's set.
|
||||
|
||||
### Enabling actor reminders partitioning
|
||||
Actor reminders partitioning is currently in preview, so enabling it is a two step process.
|
||||
|
||||
#### Preview feature configuration
|
||||
Before using reminders partitioning, actor type metadata must be enabled in Dapr. For more information on preview configurations, see [the full guide on opting into preview features in Dapr]({{< ref preview-features.md >}}). Below is an example of the configuration:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Configuration
|
||||
metadata:
|
||||
name: myconfig
|
||||
spec:
|
||||
features:
|
||||
- name: Actor.TypeMetadata
|
||||
enabled: true
|
||||
```
|
||||
|
||||
#### Actor runtime configuration
|
||||
Once actor type metadata is enabled as an opt-in preview feature, the actor runtime must also provide the appropriate configuration to partition actor reminders. This is done by the actor's endpoint for `GET /dapr/config`, similar to other actor configuration elements.
|
||||
|
||||
{{< tabs Java Dotnet Python Go >}}
|
||||
|
||||
{{% codetab %}}
|
||||
```java
|
||||
// import io.dapr.actors.runtime.ActorRuntime;
|
||||
// import java.time.Duration;
|
||||
|
||||
ActorRuntime.getInstance().getConfig().setActorIdleTimeout(Duration.ofMinutes(60));
|
||||
ActorRuntime.getInstance().getConfig().setActorScanInterval(Duration.ofSeconds(30));
|
||||
ActorRuntime.getInstance().getConfig().setRemindersStoragePartitions(7);
|
||||
```
|
||||
|
||||
See [this example](https://github.com/dapr/java-sdk/blob/master/examples/src/main/java/io/dapr/examples/actors/DemoActorService.java)
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
```csharp
|
||||
// In Startup.cs
|
||||
public void ConfigureServices(IServiceCollection services)
|
||||
{
|
||||
// Register actor runtime with DI
|
||||
services.AddActors(options =>
|
||||
{
|
||||
// Register actor types and configure actor settings
|
||||
options.Actors.RegisterActor<MyActor>();
|
||||
|
||||
// Configure default settings
|
||||
options.ActorIdleTimeout = TimeSpan.FromMinutes(60);
|
||||
options.ActorScanInterval = TimeSpan.FromSeconds(30);
|
||||
options.RemindersStoragePartitions = 7;
|
||||
// reentrancy not implemented in the .NET SDK at this time
|
||||
});
|
||||
|
||||
// Register additional services for use with actors
|
||||
services.AddSingleton<BankService>();
|
||||
}
|
||||
```
|
||||
See the .NET SDK [documentation](https://github.com/dapr/dotnet-sdk/blob/master/daprdocs/content/en/dotnet-sdk-docs/dotnet-actors/dotnet-actors-usage.md#registering-actors).
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
```python
|
||||
from datetime import timedelta
|
||||
|
||||
ActorRuntime.set_actor_config(
|
||||
ActorRuntimeConfig(
|
||||
actor_idle_timeout=timedelta(hours=1),
|
||||
actor_scan_interval=timedelta(seconds=30),
|
||||
remindersStoragePartitions=7
|
||||
)
|
||||
)
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
```go
|
||||
type daprConfig struct {
|
||||
Entities []string `json:"entities,omitempty"`
|
||||
ActorIdleTimeout string `json:"actorIdleTimeout,omitempty"`
|
||||
ActorScanInterval string `json:"actorScanInterval,omitempty"`
|
||||
DrainOngoingCallTimeout string `json:"drainOngoingCallTimeout,omitempty"`
|
||||
DrainRebalancedActors bool `json:"drainRebalancedActors,omitempty"`
|
||||
RemindersStoragePartitions int `json:"remindersStoragePartitions,omitempty"`
|
||||
}
|
||||
|
||||
var daprConfigResponse = daprConfig{
|
||||
[]string{defaultActorType},
|
||||
actorIdleTimeout,
|
||||
actorScanInterval,
|
||||
drainOngoingCallTimeout,
|
||||
drainRebalancedActors,
|
||||
7,
|
||||
}
|
||||
|
||||
func configHandler(w http.ResponseWriter, r *http.Request) {
|
||||
w.Header().Set("Content-Type", "application/json")
|
||||
w.WriteHeader(http.StatusOK)
|
||||
json.NewEncoder(w).Encode(daprConfigResponse)
|
||||
}
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
The following, is an example of a valid configuration for reminder partitioning:
|
||||
|
||||
```json
|
||||
{
|
||||
"entities": [ "MyActorType", "AnotherActorType" ],
|
||||
"remindersStoragePartitions": 7
|
||||
}
|
||||
```
|
||||
|
||||
#### Handling configuration changes
|
||||
For production scenarios, there are some points to be considered before enabling this feature:
|
||||
|
||||
* Enabling actor type metadata can only be reverted if the number of partitions remains zero, otherwise the reminders' set will be reverted to an previous state.
|
||||
* 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)
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ weight: 1000
|
|||
description: "Use Dapr tracing to get visibility for distributed application"
|
||||
---
|
||||
|
||||
Dapr uses the Zipkin protocol for distributed traces and metrics collection. Due to the ubiquity of the Zipkin protocol, many backends are supported out of the box, for examples [Stackdriver](https://cloud.google.com/stackdriver), [Zipkin](https://zipkin.io), [New Relic](https://newrelic.com) and others. Combining with the OpenTelemetry Collector, Dapr can export traces to many other backends including but not limted to [Azure Monitor](https://azure.microsoft.com/en-us/services/monitor/), [Datadog](https://www.datadoghq.com), [Instana](https://www.instana.com), [Jaeger](https://www.jaegertracing.io/), and [SignalFX](https://www.signalfx.com/).
|
||||
Dapr uses the Zipkin protocol for distributed traces and metrics collection. Due to the ubiquity of the Zipkin protocol, many backends are supported out of the box, for examples [Stackdriver](https://cloud.google.com/stackdriver), [Zipkin](https://zipkin.io), [New Relic](https://newrelic.com) and others. Combining with the OpenTelemetry Collector, Dapr can export traces to many other backends including but not limted to [Azure Monitor](https://azure.microsoft.com/en-us/services/monitor/), [Datadog](https://www.datadoghq.com), Instana, [Jaeger](https://www.jaegertracing.io/), and [SignalFX](https://www.signalfx.com/).
|
||||
|
||||
<img src="/images/tracing.png" width=600>
|
||||
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ In these scenarios Dapr does some of the work for you and you need to either cre
|
|||
To understand how to extract the trace headers from a response and add the trace headers into a request, see the [how to use trace context]({{< ref w3c-tracing >}}) article.
|
||||
|
||||
2. You have chosen to generate your own trace context headers.
|
||||
This is much more unusual. There may be occassions where you specifically chose to add W3C trace headers into a service call, for example if you have an existing application that does not currently use Dapr. In this case Dapr still propagates the trace context headers for you. If you decide to generate trace headers yourself, there are three ways this can be done :
|
||||
This is much more unusual. There may be occasions where you specifically chose to add W3C trace headers into a service call, for example if you have an existing application that does not currently use Dapr. In this case Dapr still propagates the trace context headers for you. If you decide to generate trace headers yourself, there are three ways this can be done :
|
||||
|
||||
1. You can use the industry standard OpenCensus/OpenTelemetry SDKs to generate trace headers and pass these trace headers to a Dapr enabled service. This is the preferred recommendation.
|
||||
|
||||
|
|
|
|||
|
|
@ -83,8 +83,7 @@ Dapr apps are also able to subscribe to raw events coming from existing pub/sub
|
|||
|
||||
<img src="/images/pubsub_subscribe_raw.png" alt="Diagram showing how to subscribe with Dapr when publisher does not use Dapr or CloudEvent" width=1000>
|
||||
|
||||
|
||||
### Programmatically subscribe to raw events
|
||||
### Programmatically subscribe to raw events
|
||||
|
||||
When subscribing programmatically, add the additional metadata entry for `rawPayload` so the Dapr sidecar automatically wraps the payloads into a CloudEvent that is compatible with current Dapr SDKs.
|
||||
|
||||
|
|
@ -148,10 +147,25 @@ $app->start();
|
|||
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
## Declaratively subscribe to raw events
|
||||
|
||||
Subscription Custom Resources Definitions (CRDs) do not currently contain metadata attributes ([issue #3225](https://github.com/dapr/dapr/issues/3225)). At this time subscribing to raw events can only be done through programmatic subscriptions.
|
||||
Similarly, you can subscribe to raw events declaratively by adding the `rawPayload` metadata entry to your Subscription Custom Resource Definition (CRD):
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Subscription
|
||||
metadata:
|
||||
name: myevent-subscription
|
||||
spec:
|
||||
topic: deathStarStatus
|
||||
route: /dsstatus
|
||||
pubsubname: pubsub
|
||||
metadata:
|
||||
rawPayload: "true"
|
||||
scopes:
|
||||
- app1
|
||||
- app2
|
||||
```
|
||||
|
||||
## Related links
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ To use this topic scoping three metadata properties can be set for a pub/sub com
|
|||
- `spec.metadata.allowedTopics`
|
||||
- A comma-separated list of allowed topics for all applications.
|
||||
- If `allowedTopics` is not set (default behavior), all topics are valid. `subscriptionScopes` and `publishingScopes` still take place if present.
|
||||
- `publishingScopes` or `subscriptionScopes` can be used in conjuction with `allowedTopics` to add granular limitations
|
||||
- `publishingScopes` or `subscriptionScopes` can be used in conjunction with `allowedTopics` to add granular limitations
|
||||
|
||||
These metadata properties can be used for all pub/sub components. The following examples use Redis as pub/sub component.
|
||||
|
||||
|
|
|
|||
|
|
@ -42,6 +42,9 @@ spec:
|
|||
|
||||
Make sure to replace `<PATH TO SECRETS FILE>` with the path to the JSON file you just created.
|
||||
|
||||
>Note: the path to the secret store JSON is relative to where you call `dapr run` from.
|
||||
|
||||
|
||||
To configure a different kind of secret store see the guidance on [how to configure a secret store]({{<ref setup-secret-store>}}) and review [supported secret stores]({{<ref supported-secret-stores >}}) to see specific details required for different secret store solutions.
|
||||
## Get a secret
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ type: docs
|
|||
|
||||
You can read [guidance on setting up secret store components]({{< ref setup-secret-store >}}) to configure a secret store for an application. Once configured, by default *any* secret defined within that store is accessible from the Dapr application.
|
||||
|
||||
To limit the secrets to which the Dapr application has access to, you can can define secret scopes by adding a secret scope policy to the application configuration with restrictive permissions. Follow [these instructions]({{< ref configuration-concept.md >}}) to define an application configuration.
|
||||
To limit the secrets to which the Dapr application has access to, you can define secret scopes by adding a secret scope policy to the application configuration with restrictive permissions. Follow [these instructions]({{< ref configuration-concept.md >}}) to define an application configuration.
|
||||
|
||||
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 >}})
|
||||
|
||||
|
|
@ -18,7 +18,9 @@ Watch this [video](https://youtu.be/j99RN_nxExA?start=2272) for a demo on how to
|
|||
|
||||
## Scenario 1 : Deny access to all secrets for a secret store
|
||||
|
||||
This example uses Kubernetes. The native Kubernetes secret store is added to you Dapr application by default. In some scenarios it may be necessary to deny access to Dapr secrets for a given application. To add this configuration follow the steps below:
|
||||
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:
|
||||
|
||||
Define the following `appconfig.yaml` configuration and apply it to the Kubernetes cluster using the command `kubectl apply -f appconfig.yaml`.
|
||||
|
||||
|
|
@ -32,6 +34,8 @@ spec:
|
|||
scopes:
|
||||
- storeName: kubernetes
|
||||
defaultAccess: deny
|
||||
- storeName: mycustomsecreststore
|
||||
defaultAccess: deny
|
||||
```
|
||||
|
||||
For applications that need to be denied access to the Kubernetes secret store, follow [these instructions]({{< ref kubernetes-overview.md >}}), and add the following annotation to the application pod.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
type: docs
|
||||
title: "How-To: Invoke services using HTTP"
|
||||
linkTitle: "How-To: Invoke services"
|
||||
linkTitle: "How-To: Invoke with HTTP"
|
||||
description: "Call between services using service invocation"
|
||||
weight: 2000
|
||||
---
|
||||
|
|
@ -57,7 +57,7 @@ spec:
|
|||
dapr.io/app-port: "5000"
|
||||
...
|
||||
```
|
||||
*If your app uses an SSL connection, you can tell Dapr to invoke your app over an insecure SSL connection with the `app-ssl: "true"` annotation (full list [here]({{< ref kubernetes-annotations.md >}}))*
|
||||
*If your app uses an SSL connection, you can tell Dapr to invoke your app over an insecure SSL connection with the `app-ssl: "true"` annotation (full list [here]({{< ref arguments-annotations-overview.md >}}))*
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,307 @@
|
|||
---
|
||||
type: docs
|
||||
title: "How-To: Invoke services using gRPC"
|
||||
linkTitle: "How-To: Invoke with gRPC"
|
||||
description: "Call between services using service invocation"
|
||||
weight: 3000
|
||||
---
|
||||
|
||||
This article describe how to use Dapr to connect services using gRPC.
|
||||
By using Dapr's gRPC proxying capability, you can use your existing proto based gRPC services and have the traffic go through the Dapr sidecar. Doing so yields the following [Dapr Service Invocation]({{< ref service-invocation-overview.md >}}) benefits to developers:
|
||||
|
||||
1. Mutual authentication
|
||||
2. Tracing
|
||||
3. Metrics
|
||||
4. Access lists
|
||||
5. Network level resiliency
|
||||
6. API token based authentication
|
||||
|
||||
## Step 1: Run a gRPC server
|
||||
|
||||
The following example is taken from the [hello world grpc-go example](https://github.com/grpc/grpc-go/tree/master/examples/helloworld).
|
||||
|
||||
Note this example is in Go, but applies to all programming languages supported by gRPC.
|
||||
|
||||
```go
|
||||
package main
|
||||
|
||||
import (
|
||||
"context"
|
||||
"log"
|
||||
"net"
|
||||
|
||||
"google.golang.org/grpc"
|
||||
pb "google.golang.org/grpc/examples/helloworld/helloworld"
|
||||
)
|
||||
|
||||
const (
|
||||
port = ":50051"
|
||||
)
|
||||
|
||||
// server is used to implement helloworld.GreeterServer.
|
||||
type server struct {
|
||||
pb.UnimplementedGreeterServer
|
||||
}
|
||||
|
||||
// SayHello implements helloworld.GreeterServer
|
||||
func (s *server) SayHello(ctx context.Context, in *pb.HelloRequest) (*pb.HelloReply, error) {
|
||||
log.Printf("Received: %v", in.GetName())
|
||||
return &pb.HelloReply{Message: "Hello " + in.GetName()}, nil
|
||||
}
|
||||
|
||||
func main() {
|
||||
lis, err := net.Listen("tcp", port)
|
||||
if err != nil {
|
||||
log.Fatalf("failed to listen: %v", err)
|
||||
}
|
||||
s := grpc.NewServer()
|
||||
pb.RegisterGreeterServer(s, &server{})
|
||||
log.Printf("server listening at %v", lis.Addr())
|
||||
if err := s.Serve(lis); err != nil {
|
||||
log.Fatalf("failed to serve: %v", err)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
This Go app implements the Greeter proto service and exposes a `SayHello` method.
|
||||
|
||||
### Run the gRPC server using the Dapr CLI
|
||||
|
||||
Since gRPC proxying is currently a preview feature, you need to opt-in using a configuration file. See https://docs.dapr.io/operations/configuration/preview-features/ for more information.
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Configuration
|
||||
metadata:
|
||||
name: serverconfig
|
||||
spec:
|
||||
tracing:
|
||||
samplingRate: "1"
|
||||
zipkin:
|
||||
endpointAddress: http://localhost:9411/api/v2/spans
|
||||
features:
|
||||
- name: proxy.grpc
|
||||
enabled: true
|
||||
```
|
||||
|
||||
Run the sidecar and the Go server:
|
||||
|
||||
```bash
|
||||
dapr run --app-id server --app-protocol grpc --app-port 50051 --config config.yaml -- go run main.go
|
||||
```
|
||||
|
||||
Using the Dapr CLI, we're assigning a unique id to the app, `server`, using the `--app-id` flag.
|
||||
|
||||
## Step 2: Invoke the service
|
||||
|
||||
The following example shows you how to discover the Greeter service using Dapr from a gRPC client.
|
||||
Notice that instead of invoking the target service directly at port `50051`, the client is invoking its local Dapr sidecar over port `50007` which then provides all the capabilities of service invocation including service discovery, tracing, mTLS and retries.
|
||||
|
||||
```go
|
||||
package main
|
||||
|
||||
import (
|
||||
"context"
|
||||
"log"
|
||||
"time"
|
||||
|
||||
"google.golang.org/grpc"
|
||||
pb "google.golang.org/grpc/examples/helloworld/helloworld"
|
||||
"google.golang.org/grpc/metadata"
|
||||
)
|
||||
|
||||
const (
|
||||
address = "localhost:50007"
|
||||
)
|
||||
|
||||
func main() {
|
||||
// Set up a connection to the server.
|
||||
conn, err := grpc.Dial(address, grpc.WithInsecure(), grpc.WithBlock())
|
||||
if err != nil {
|
||||
log.Fatalf("did not connect: %v", err)
|
||||
}
|
||||
defer conn.Close()
|
||||
c := pb.NewGreeterClient(conn)
|
||||
|
||||
ctx, cancel := context.WithTimeout(context.Background(), time.Second*2)
|
||||
defer cancel()
|
||||
|
||||
ctx = metadata.AppendToOutgoingContext(ctx, "dapr-app-id", "server")
|
||||
r, err := c.SayHello(ctx, &pb.HelloRequest{Name: "Darth Tyrannus"})
|
||||
if err != nil {
|
||||
log.Fatalf("could not greet: %v", err)
|
||||
}
|
||||
|
||||
log.Printf("Greeting: %s", r.GetMessage())
|
||||
}
|
||||
```
|
||||
|
||||
The following line tells Dapr to discover and invoke an app named `server`:
|
||||
|
||||
```go
|
||||
ctx = metadata.AppendToOutgoingContext(ctx, "dapr-app-id", "server")
|
||||
```
|
||||
|
||||
All languages supported by gRPC allow for adding metadata. Here are a few examples:
|
||||
|
||||
{{< tabs Java Dotnet Python JavaScript Ruby "C++">}}
|
||||
|
||||
{{% codetab %}}
|
||||
```java
|
||||
Metadata headers = new Metadata();
|
||||
Metadata.Key<String> jwtKey = Metadata.Key.of("dapr-app-id", "server");
|
||||
|
||||
GreeterService.ServiceBlockingStub stub = GreeterService.newBlockingStub(channel);
|
||||
stub = MetadataUtils.attachHeaders(stub, header);
|
||||
stub.SayHello(new HelloRequest() { Name = "Darth Malak" });
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
```csharp
|
||||
var metadata = new Metadata
|
||||
{
|
||||
{ "dapr-app-id", "server" }
|
||||
};
|
||||
|
||||
var call = client.SayHello(new HelloRequest { Name = "Darth Nihilus" }, metadata);
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
```python
|
||||
metadata = (('dapr-app-id', 'server'))
|
||||
response = stub.SayHello(request={ name: 'Darth Revan' }, metadata=metadata)
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
```javascript
|
||||
const metadata = new grpc.Metadata();
|
||||
metadata.add('dapr-app-id', 'server');
|
||||
|
||||
client.sayHello({ name: "Darth Malgus", metadata })
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
```ruby
|
||||
metadata = { 'dapr-app-id' : 'server' }
|
||||
response = service.sayHello({ 'name': 'Darth Bane' }, metadata)
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
```c++
|
||||
grpc::ClientContext context;
|
||||
context.AddMetadata("dapr-app-id", "Darth Sidious");
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
### Run the client using the Dapr CLI
|
||||
|
||||
Since gRPC proxying is currently a preview feature, you need to opt-in using a configuration file. See https://docs.dapr.io/operations/configuration/preview-features/ for more information.
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Configuration
|
||||
metadata:
|
||||
name: serverconfig
|
||||
spec:
|
||||
tracing:
|
||||
samplingRate: "1"
|
||||
zipkin:
|
||||
endpointAddress: http://localhost:9411/api/v2/spans
|
||||
features:
|
||||
- name: proxy.grpc
|
||||
enabled: true
|
||||
```
|
||||
|
||||
```bash
|
||||
dapr run --app-id client --dapr-grpc-port 50007 --config config.yaml -- go run main.go
|
||||
```
|
||||
|
||||
### View telemetry
|
||||
|
||||
If you're running Dapr locally with Zipkin installed, open the browser at `http://localhost:9411` and view the traces between the client and server.
|
||||
|
||||
## Deploying to Kubernetes
|
||||
|
||||
### Step 1: Apply the following configuration YAML using `kubectl`
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Configuration
|
||||
metadata:
|
||||
name: serverconfig
|
||||
spec:
|
||||
tracing:
|
||||
samplingRate: "1"
|
||||
zipkin:
|
||||
endpointAddress: http://localhost:9411/api/v2/spans
|
||||
features:
|
||||
- name: proxy.grpc
|
||||
enabled: true
|
||||
```
|
||||
|
||||
```bash
|
||||
kubectl apply -f config.yaml
|
||||
```
|
||||
|
||||
### Step 2: set the following Dapr annotations on your pod
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: grpc-app
|
||||
namespace: default
|
||||
labels:
|
||||
app: grpc-app
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app: grpc-app
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: grpc-app
|
||||
annotations:
|
||||
dapr.io/enabled: "true"
|
||||
dapr.io/app-id: "server"
|
||||
dapr.io/app-protocol: "grpc"
|
||||
dapr.io/app-port: "50051"
|
||||
dapr.io/config: "serverconfig"
|
||||
...
|
||||
```
|
||||
*If your app uses an SSL connection, you can tell Dapr to invoke your app over an insecure SSL connection with the `app-ssl: "true"` annotation (full list [here]({{< ref arguments-annotations-overview.md >}}))*
|
||||
|
||||
The `dapr.io/app-protocol: "grpc"` annotation tells Dapr to invoke the app using gRPC.
|
||||
The `dapr.io/config: "serverconfig"` annotation tells Dapr to use the configuration applied above that enables gRPC proxying.
|
||||
|
||||
### Namespaces
|
||||
|
||||
When running on [namespace supported platforms]({{< ref "service_invocation_api.md#namespace-supported-platforms" >}}), you include the namespace of the target app in the app ID: `myApp.production`
|
||||
|
||||
For example, invoking the gRPC server on a different namespace:
|
||||
|
||||
```go
|
||||
ctx = metadata.AppendToOutgoingContext(ctx, "dapr-app-id", "server.production")
|
||||
```
|
||||
|
||||
See the [Cross namespace API spec]({{< ref "service_invocation_api.md#cross-namespace-invocation" >}}) for more information on namespaces.
|
||||
|
||||
## Step 3: View traces and logs
|
||||
|
||||
The example above showed you how to directly invoke a different service running locally or in Kubernetes. Dapr outputs metrics, tracing and logging information allowing you to visualize a call graph between services, log errors and optionally log the payload body.
|
||||
|
||||
For more information on tracing and logs see the [observability]({{< ref observability-concept.md >}}) article.
|
||||
|
||||
## Related Links
|
||||
|
||||
* [Service invocation overview]({{< ref service-invocation-overview.md >}})
|
||||
* [Service invocation API specification]({{< ref service_invocation_api.md >}})
|
||||
* [gRPC proxying community call video](https://youtu.be/B_vkXqptpXY?t=70)
|
||||
|
|
@ -103,6 +103,10 @@ By default, all calls between applications are traced and metrics are gathered t
|
|||
|
||||
The API for service invocation can be found in the [service invocation API reference]({{< ref service_invocation_api.md >}}) which describes how to invoke a method on another service.
|
||||
|
||||
### 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 >}}).
|
||||
|
||||
## Example
|
||||
|
||||
Following the above call sequence, suppose you have the applications as described in the [hello world quickstart](https://github.com/dapr/quickstarts/blob/master/hello-world/README.md), where a python app invokes a node.js app. In such a scenario, the python app would be "Service A" , and a Node.js app would be "Service B".
|
||||
|
|
@ -124,6 +128,7 @@ The diagram below shows sequence 1-7 again on a local machine showing the API ca
|
|||
- Follow these guides on:
|
||||
- [How-to: Invoke services using HTTP]({{< ref howto-invoke-discover-services.md >}})
|
||||
- [How-To: Configure Dapr to use gRPC]({{< ref grpc >}})
|
||||
- [How-to: Invoke services using gRPC]({{< ref howto-invoke-services-grpc.md >}})
|
||||
- Try out the [hello world quickstart](https://github.com/dapr/quickstarts/blob/master/hello-world/README.md) which shows how to use HTTP service invocation or try the samples in the [Dapr SDKs]({{< ref sdks >}})
|
||||
- Read the [service invocation API specification]({{< ref service_invocation_api.md >}})
|
||||
- Understand the [service invocation performance]({{< ref perf-service-invocation.md >}}) numbers
|
||||
|
|
|
|||
|
|
@ -80,7 +80,7 @@ Add a new `<tool></tool>` entry:
|
|||
</toolSet>
|
||||
```
|
||||
|
||||
Optionally, you may also create a new entry for a sidecar tool that can be reused accross many projects:
|
||||
Optionally, you may also create a new entry for a sidecar tool that can be reused across many projects:
|
||||
|
||||
```xml
|
||||
<toolSet name="External Tools">
|
||||
|
|
|
|||
|
|
@ -0,0 +1,178 @@
|
|||
---
|
||||
type: docs
|
||||
title: "How-To: Debug Dapr applications with Visual Studio Code"
|
||||
linkTitle: "How-To: Debug with VSCode"
|
||||
weight: 20000
|
||||
description: "Learn how to configure VSCode to debug Dapr applications"
|
||||
aliases:
|
||||
- /developing-applications/ides/vscode/vscode-manual-configuration/
|
||||
---
|
||||
|
||||
## Manual debugging
|
||||
|
||||
When developing Dapr applications, you typically use the Dapr CLI to start your daprized service similar to this:
|
||||
|
||||
```bash
|
||||
dapr run --app-id nodeapp --app-port 3000 --dapr-http-port 3500 app.js
|
||||
```
|
||||
|
||||
One approach to attaching the debugger to your service is to first run daprd with the correct arguments from the command line and then launch your code and attach the debugger. While this is a perfectly acceptable solution, it does require a few extra steps and some instruction to developers who might want to clone your repo and hit the "play" button to begin debugging.
|
||||
|
||||
If your application is a collection of microservices, each with a Dapr sidecar, it will be useful to debug them together in Visual Studio Code. This page will use the [hello world quickstart](https://github.com/dapr/quickstarts/tree/master/hello-world) to showcase how to configure VSCode to debug multiple Dapr application using [VSCode debugging](https://code.visualstudio.com/Docs/editor/debugging).
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Install the [Dapr extension]({{< ref vscode-dapr-extension.md >}}). You will be using the [tasks](https://code.visualstudio.com/docs/editor/tasks) it offers later on.
|
||||
- Optionally clone the [hello world quickstart](https://github.com/dapr/quickstarts/tree/master/hello-world)
|
||||
|
||||
## Step 1: Configure launch.json
|
||||
|
||||
The file `.vscode/launch.json` contains [launch configurations](https://code.visualstudio.com/Docs/editor/debugging#_launch-configurations) for a VS Code debug run. This file defines what will launch and how it is configured when the user begins debugging. Configurations are available for each programming language in the [Visual Studio Code marketplace](https://marketplace.visualstudio.com/VSCode).
|
||||
|
||||
{{% alert title="Scaffold debugging configuration" color="primary" %}}
|
||||
The [Dapr VSCode extension]({{< ref vscode-dapr-extension.md >}}) offers built-in scaffolding to generate `launch.json` and `tasks.json` for you.
|
||||
|
||||
{{< button text="Learn more" page="vscode-dapr-extension#scaffold-dapr-components" >}}
|
||||
{{% /alert %}}
|
||||
|
||||
In the case of the hello world quickstart, two applications are launched, each with its own Dapr sidecar. One is written in Node.JS, and the other in Python. You'll notice each configuration contains a `daprd run` preLaunchTask and a `daprd stop` postDebugTask.
|
||||
|
||||
```json
|
||||
{
|
||||
"version": "0.2.0",
|
||||
"configurations": [
|
||||
{
|
||||
"type": "pwa-node",
|
||||
"request": "launch",
|
||||
"name": "Nodeapp with Dapr",
|
||||
"skipFiles": [
|
||||
"<node_internals>/**"
|
||||
],
|
||||
"program": "${workspaceFolder}/app.js",
|
||||
"preLaunchTask": "daprd-debug-node",
|
||||
"postDebugTask": "daprd-down-node"
|
||||
},
|
||||
{
|
||||
"type": "python",
|
||||
"request": "launch",
|
||||
"name": "Pythonapp with Dapr",
|
||||
"program": "${workspaceFolder}/app.py",
|
||||
"console": "integratedTerminal",
|
||||
"preLaunchTask": "daprd-debug-python",
|
||||
"postDebugTask": "daprd-down-python"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Each configuration requires a `request`, `type` and `name`. These parameters help VSCode identify the task configurations in the `.vscode/task.json` files.
|
||||
|
||||
- `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.
|
||||
- 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).
|
||||
|
||||
## Step 2: Configure task.json
|
||||
|
||||
For each [task](https://code.visualstudio.com/docs/editor/tasks) defined in `.vscode/launch.json` , a corresponding task definition must exist in `.vscode/task.json`.
|
||||
|
||||
For the quickstart, each service needs a task to launch a Dapr sidecar with the `daprd` type, and a task to stop the sidecar with `daprd-down`. The parameters `appId`, `httpPort`, `metricsPort`, `label` and `type` are required. Additional optional parameters are available, see the [reference table here](#daprd-parameter-table").
|
||||
|
||||
```json
|
||||
{
|
||||
"version": "2.0.0",
|
||||
"tasks": [
|
||||
{
|
||||
"label": "daprd-debug-node",
|
||||
"type": "daprd",
|
||||
"appId": "nodeapp",
|
||||
"appPort": 3000,
|
||||
"httpPort": 3500,
|
||||
"metricsPort": 9090
|
||||
},
|
||||
{
|
||||
"label": "daprd-down-node",
|
||||
"type": "daprd-down",
|
||||
"appId": "nodeapp"
|
||||
},
|
||||
{
|
||||
"label": "daprd-debug-python",
|
||||
"type": "daprd",
|
||||
"appId": "pythonapp",
|
||||
"httpPort": 53109,
|
||||
"grpcPort": 53317,
|
||||
"metricsPort": 9091
|
||||
},
|
||||
{
|
||||
"label": "daprd-down-python",
|
||||
"type": "daprd-down",
|
||||
"appId": "pythonapp"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Step 3: Configure a compound launch in launch.json
|
||||
|
||||
A compound launch configuration can defined in `.vscode/launch.json` and is a set of two or more launch configurations that are launched in parallel. Optionally, a `preLaunchTask` can be specified and run before the individual debug sessions are started.
|
||||
|
||||
For this example the compound configuration is:
|
||||
|
||||
```json
|
||||
{
|
||||
"version": "2.0.0",
|
||||
"tasks": [...],
|
||||
"compounds": [
|
||||
{
|
||||
"name": "Node/Python Dapr",
|
||||
"configurations": ["Nodeapp with Dapr","Pythonapp with Dapr"]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Step 4: Launch your debugging session
|
||||
|
||||
You can now run the applications in debug mode by finding the compound command name you have defined in the previous step in the VS Code debugger:
|
||||
|
||||
<img src="/images/vscode-launch-configuration.png" width=400 >
|
||||
|
||||
You are now debugging multiple applications with Dapr!
|
||||
|
||||
## Daprd parameter table
|
||||
|
||||
Below are the supported parameters for VS Code tasks. These parameters are equivalent to `daprd` arguments as detailed in [this reference]({{< ref arguments-annotations-overview.md >}}):
|
||||
|
||||
| Parameter | Description | Required | Example |
|
||||
|--------------|---------------|-------------|---------|
|
||||
| `allowedOrigins` | Allowed HTTP origins (default "\*") | No | `"allowedOrigins": "*"`
|
||||
| `appId`| The unique ID of the application. Used for service discovery, state encapsulation and the pub/sub consumer ID | Yes | `"appId": "divideapp"`
|
||||
| `appMaxConcurrency` | Limit the concurrency of your application. A valid value is any number larger than 0 | No | `"appMaxConcurrency": -1`
|
||||
| `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": []
|
||||
| `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/"`
|
||||
| `enableProfiling` | Enable profiling | No | `"enableProfiling": false`
|
||||
| `enableMtls` | Enables automatic mTLS for daprd to daprd communication channels | No | `"enableMtls": false`
|
||||
| `grpcPort` | gRPC port for the Dapr API to listen on (default “50001”) | Yes, if multiple apps | `"grpcPort": 50004`
|
||||
| `httpPort` | The HTTP port for the Dapr API | Yes | `"httpPort": 3502`
|
||||
| `internalGrpcPort` | gRPC port for the Dapr Internal API to listen on | No | `"internalGrpcPort": 50001`
|
||||
| `logAsJson` | Setting this parameter to true outputs logs in JSON format. Default is false | No | `"logAsJson": false`
|
||||
| `logLevel` | Sets the log level for the Dapr sidecar. Allowed values are debug, info, warn, error. Default is info | No | `"logLevel": "debug"`
|
||||
| `metricsPort` | Sets the port for the sidecar metrics server. Default is 9090 | Yes, if multiple apps | `"metricsPort": 9093`
|
||||
| `mode` | Runtime mode for Dapr (default “standalone”) | No | `"mode": "standalone"`
|
||||
| `placementHostAddress` | Addresses for Dapr Actor Placement servers | No | `"placementHostAddress": "http://localhost:1313/"`
|
||||
| `profilePort` | The port for the profile server (default “7777”) | No | `"profilePort": 7777`
|
||||
| `sentryAddress` | Address for the Sentry CA service | No | `"sentryAddress": "http://localhost:1345/"`
|
||||
| `type` | Tells VS Code it will be a daprd task type | Yes | `"type": "daprd"`
|
||||
|
||||
|
||||
## Related Links
|
||||
|
||||
- [Visual Studio Code Extension Overview]({{< ref vscode-dapr-extension.md >}})
|
||||
- [Visual Studio Code Debugging](https://code.visualstudio.com/docs/editor/debugging)
|
||||
|
|
@ -1,168 +0,0 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Visual Studio Code manual debugging configuration"
|
||||
linkTitle: "Manual debugging"
|
||||
weight: 30000
|
||||
description: "How to manually setup Visual Studio Code debugging"
|
||||
---
|
||||
|
||||
The [Dapr VSCode extension]({{< ref vscode-dapr-extension.md >}}) automates the setup of [VSCode debugging](https://code.visualstudio.com/Docs/editor/debugging).
|
||||
|
||||
If instead you wish to manually configure the `[tasks.json](https://code.visualstudio.com/Docs/editor/tasks)` and `[launch.json](https://code.visualstudio.com/Docs/editor/debugging)` files to use Dapr, these are the steps.
|
||||
|
||||
When developing Dapr applications, you typically use the Dapr cli to start your daprized service similar to this:
|
||||
|
||||
```bash
|
||||
dapr run --app-id nodeapp --app-port 3000 --dapr-http-port 3500 app.js
|
||||
```
|
||||
|
||||
One approach to attaching the debugger to your service is to first run daprd with the correct arguments from the command line and then launch your code and attach the debugger. While this is a perfectly acceptable solution, it does require a few extra steps and some instruction to developers who might want to clone your repo and hit the "play" button to begin debugging.
|
||||
|
||||
Using the [tasks.json](https://code.visualstudio.com/Docs/editor/tasks) and [launch.json](https://code.visualstudio.com/Docs/editor/debugging) files in Visual Studio Code, you can simplify the process and request that VS Code kick off the daprd process prior to launching the debugger.
|
||||
|
||||
#### Modifying launch.json configurations to include a preLaunchTask
|
||||
|
||||
In your [launch.json](https://code.visualstudio.com/Docs/editor/debugging) file add a [preLaunchTask](https://code.visualstudio.com/Docs/editor/debugging#_launchjson-attributes) for each configuration that you want daprd launched. The [preLaunchTask](https://code.visualstudio.com/Docs/editor/debugging#_launchjson-attributes) references tasks that you define in your tasks.json file. Here is an example for both Node and .NET Core. Notice the [preLaunchTasks](https://code.visualstudio.com/Docs/editor/debugging#_launchjson-attributes) referenced: daprd-web and daprd-leaderboard.
|
||||
|
||||
```json
|
||||
{
|
||||
"version": "0.2.0",
|
||||
"configurations": [
|
||||
{
|
||||
"type": "node",
|
||||
"request": "launch",
|
||||
"name": "Node Launch w/Dapr (Web)",
|
||||
"preLaunchTask": "daprd-web",
|
||||
"program": "${workspaceFolder}/Game/Web/server.js",
|
||||
"skipFiles": [
|
||||
"<node_internals>/**"
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "coreclr",
|
||||
"request": "launch",
|
||||
"name": ".NET Core Launch w/Dapr (LeaderboardService)",
|
||||
"preLaunchTask": "daprd-leaderboard",
|
||||
"program": "${workspaceFolder}/Game/Services/LeaderboardService/bin/Debug/netcoreapp3.0/LeaderboardService.dll",
|
||||
"args": [],
|
||||
"cwd": "${workspaceFolder}/Game/Services/LeaderboardService",
|
||||
"stopAtEntry": false,
|
||||
"serverReadyAction": {
|
||||
"action": "openExternally",
|
||||
"pattern": "^\\s*Now listening on:\\s+(https?://\\S+)"
|
||||
},
|
||||
"env": {
|
||||
"ASPNETCORE_ENVIRONMENT": "Development"
|
||||
},
|
||||
"sourceFileMap": {
|
||||
"/Views": "${workspaceFolder}/Views"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
#### Adding daprd tasks to tasks.json
|
||||
|
||||
You need to define a task and problem matcher for daprd in your [tasks.json](https://code.visualstudio.com/Docs/editor/tasks) file. Here are two examples (both referenced via the [preLaunchTask](https://code.visualstudio.com/Docs/editor/debugging#_launchjson-attributes) members above). Notice that in the case of the .NET Core daprd task (daprd-leaderboard) there is also a [dependsOn](https://code.visualstudio.com/Docs/editor/tasks#_compound-tasks) member that references the build task to ensure the latest code is being run/debugged. The [problemMatcher](https://code.visualstudio.com/Docs/editor/tasks#_defining-a-problem-matcher) is used so that VSCode can understand when the daprd process is up and running.
|
||||
|
||||
Let's take a quick look at the args that are being passed to the daprd command.
|
||||
|
||||
* -app-id -- the id (how you locate it via service invocation) of your microservice
|
||||
* -app-port -- the port number that your application code is listening on
|
||||
* -dapr-http-port -- the http port for the dapr api
|
||||
* -dapr-grpc-port -- the grpc port for the dapr api
|
||||
* -placement-host-address -- the location of the placement service (this should be running in docker as it was created when you installed dapr and ran ```dapr init```)
|
||||
|
||||
>Note: You need to ensure that you specify different http/grpc (-dapr-http-port and -dapr-grpc-port) ports for each daprd task that you create, otherwise you run into port conflicts when you attempt to launch the second configuration.
|
||||
|
||||
```json
|
||||
{
|
||||
"version": "2.0.0",
|
||||
"tasks": [
|
||||
{
|
||||
"label": "build",
|
||||
"command": "dotnet",
|
||||
"type": "process",
|
||||
"args": [
|
||||
"build",
|
||||
"${workspaceFolder}/Game/Services/LeaderboardService/LeaderboardService.csproj",
|
||||
"/property:GenerateFullPaths=true",
|
||||
"/consoleloggerparameters:NoSummary"
|
||||
],
|
||||
"problemMatcher": "$msCompile"
|
||||
},
|
||||
{
|
||||
"label": "daprd-web",
|
||||
"command": "daprd",
|
||||
"args": [
|
||||
"-app-id",
|
||||
"whac-a-mole--web",
|
||||
"-app-port",
|
||||
"3000",
|
||||
"-dapr-http-port",
|
||||
"51000",
|
||||
"-dapr-grpc-port",
|
||||
"52000",
|
||||
"-placement-host-address",
|
||||
"localhost:50005"
|
||||
],
|
||||
"isBackground": true,
|
||||
"problemMatcher": {
|
||||
"pattern": [
|
||||
{
|
||||
"regexp": ".",
|
||||
"file": 1,
|
||||
"location": 2,
|
||||
"message": 3
|
||||
}
|
||||
],
|
||||
"background": {
|
||||
"beginsPattern": "^.*starting Dapr Runtime.*",
|
||||
"endsPattern": "^.*waiting on port.*"
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"label": "daprd-leaderboard",
|
||||
"command": "daprd",
|
||||
"args": [
|
||||
"-app-id",
|
||||
"whac-a-mole--leaderboard",
|
||||
"-app-port",
|
||||
"5000",
|
||||
"-dapr-http-port",
|
||||
"51001",
|
||||
"-dapr-grpc-port",
|
||||
"52001",
|
||||
"-placement-host-address",
|
||||
"localhost:50005"
|
||||
],
|
||||
"isBackground": true,
|
||||
"problemMatcher": {
|
||||
"pattern": [
|
||||
{
|
||||
"regexp": ".",
|
||||
"file": 1,
|
||||
"location": 2,
|
||||
"message": 3
|
||||
}
|
||||
],
|
||||
"background": {
|
||||
"beginsPattern": "^.*starting Dapr Runtime.*",
|
||||
"endsPattern": "^.*waiting on port.*"
|
||||
}
|
||||
},
|
||||
"dependsOn": "build"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
#### Wrapping up
|
||||
|
||||
Once you have made the required changes, you should be able to switch to the [debug](https://code.visualstudio.com/Docs/editor/debugging) view in VSCode and launch your daprized configurations by clicking the "play" button. If everything was configured correctly, you should see daprd launch in the VSCode terminal window and the [debugger](https://code.visualstudio.com/Docs/editor/debugging) should attach to your application (you should see it's output in the debug window).
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
Since you didn't launch the service(s) using the **dapr** ***run*** cli command, but instead by running **daprd**, the **dapr** ***list*** command will not show a list of apps that are currently running.
|
||||
{{% /alert %}}
|
||||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Developing Dapr applications with remote dev containers"
|
||||
linkTitle: "Remote dev containers"
|
||||
weight: 20000
|
||||
weight: 30000
|
||||
description: "How to setup a remote dev container environment with Dapr"
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ You can find a list of auto-generated clients [here](https://github.com/dapr/doc
|
|||
|
||||
The Dapr runtime implements a [proto service](https://github.com/dapr/dapr/blob/master/dapr/proto/runtime/v1/dapr.proto) that apps can communicate with via gRPC.
|
||||
|
||||
In addition to calling Dapr via gRPC, Dapr can communicate with an application via gRPC. To do that, the app needs to host a gRPC server and implements the [Dapr appcallback service](https://github.com/dapr/dapr/blob/master/dapr/proto/runtime/v1/appcallback.proto)
|
||||
In addition to calling Dapr via gRPC, Dapr supports service to service calls with gRPC by acting as a proxy. See more information [here]({{< ref howto-invoke-services-grpc.md >}}).
|
||||
|
||||
## Configuring Dapr to communicate with an app via gRPC
|
||||
|
||||
|
|
@ -177,7 +177,7 @@ func (s *server) ListInputBindings(ctx context.Context, in *empty.Empty) (*pb.Li
|
|||
}, nil
|
||||
}
|
||||
|
||||
// This method gets invoked every time a new event is fired from a registerd binding. The message carries the binding name, a payload and optional metadata
|
||||
// This method gets invoked every time a new event is fired from a registered binding. The message carries the binding name, a payload and optional metadata
|
||||
func (s *server) OnBindingEvent(ctx context.Context, in *pb.BindingEventRequest) (*pb.BindingEventResponse, error) {
|
||||
fmt.Println("Invoked from binding")
|
||||
return &pb.BindingEventResponse{}, nil
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ The Dapr SDKs are the easiest way for you to get Dapr into your application. Cho
|
|||
|----------|:------|:----------:|:-----------:|:---------:|
|
||||
| [.NET]({{< ref dotnet >}}) | Stable | ✔ | [ASP.NET Core]({{< ref dotnet-aspnet >}}) | ✔ |
|
||||
| [Python]({{< ref python >}}) | Stable | ✔ | [gRPC]({{< ref python-grpc.md >}}) | [FastAPI]({{< ref python-fastapi.md >}})<br />[Flask]({{< ref python-flask.md >}}) |
|
||||
| [Java](https://github.com/dapr/java-sdk) | Stable | ✔ | Spring Boot | ✔ |
|
||||
| [Java]({{< ref java >}}) | Stable | ✔ | Spring Boot | ✔ |
|
||||
| [Go]({{< ref go >}}) | Stable | ✔ | ✔ | |
|
||||
| [PHP]({{< ref php >}}) | Stable | ✔ | ✔ | ✔ |
|
||||
| [C++](https://github.com/dapr/cpp-sdk) | In development | ✔ | |
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ spec:
|
|||
value: ":"
|
||||
```
|
||||
|
||||
You can see that the above file definition has a `type: secretstores.local.file` which tells Dapr to use the local file component as a secret store. The metadata fields provide component specific information needed to work with this component (in this case, the path to the secret store JSON)
|
||||
You can see that the above file definition has a `type: secretstores.local.file` which tells Dapr to use the local file component as a secret store. The metadata fields provide component specific information needed to work with this component (in this case, the path to the secret store JSON is relative to where you call `dapr run` from.)
|
||||
|
||||
## Step 3: Run the Dapr sidecar
|
||||
|
||||
|
|
|
|||
|
|
@ -12,40 +12,62 @@ Begin by downloading and installing the Dapr CLI:
|
|||
{{< tabs Linux Windows MacOS Binaries>}}
|
||||
|
||||
{{% codetab %}}
|
||||
### Install from Terminal
|
||||
|
||||
This command installs the latest linux Dapr CLI to `/usr/local/bin`:
|
||||
```bash
|
||||
wget -q https://raw.githubusercontent.com/dapr/cli/master/install/install.sh -O - | /bin/bash
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
This Command Prompt command installs the latest windows Dapr cli to `C:\dapr` and adds this directory to User PATH environment variable.
|
||||
```powershell
|
||||
powershell -Command "iwr -useb https://raw.githubusercontent.com/dapr/cli/master/install/install.ps1 | iex"
|
||||
### Install without `sudo`
|
||||
If you do not have access to the `sudo` command or your username is not in the `sudoers` file you can install Dapr to an alternate directory via the `DAPR_INSTALL_DIR` environment variable.
|
||||
|
||||
```bash
|
||||
wget -q https://raw.githubusercontent.com/dapr/cli/master/install/install.sh -O - | DAPR_INSTALL_DIR="$HOME/dapr" /bin/bash
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
### Install from Command Prompt
|
||||
This Command Prompt command installs the latest windows Dapr cli to `C:\dapr` and adds this directory to User PATH environment variable.
|
||||
```powershell
|
||||
powershell -Command "iwr -useb https://raw.githubusercontent.com/dapr/cli/master/install/install.ps1 | iex"
|
||||
```
|
||||
|
||||
### Install without administrative rights
|
||||
If you do not have admin rights you can install Dapr to an alternate directory via the `DAPR_INSTALL_DIR` environment variable.
|
||||
|
||||
```powershell
|
||||
$script=iwr -useb https://raw.githubusercontent.com/dapr/cli/master/install/install.ps1; $block=[ScriptBlock]::Create($script); invoke-command -ScriptBlock $block -ArgumentList "", "$HOME/dapr"
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
### Install from Terminal
|
||||
This command installs the latest darwin Dapr CLI to `/usr/local/bin`:
|
||||
```bash
|
||||
curl -fsSL https://raw.githubusercontent.com/dapr/cli/master/install/install.sh | /bin/bash
|
||||
```
|
||||
|
||||
Or you can install via [Homebrew](https://brew.sh):
|
||||
### Install from Homebrew
|
||||
You can install via [Homebrew](https://brew.sh):
|
||||
```bash
|
||||
brew install dapr/tap/dapr-cli
|
||||
```
|
||||
|
||||
{{% alert title="Note for M1 Macs" color="primary" %}}
|
||||
#### Note for M1 Macs
|
||||
For M1 Macs, homebrew is not supported. You will need to use the dapr install script and have the rosetta amd64 compatibility layer installed. If you do not have it installed already, you can run the following:
|
||||
|
||||
```bash
|
||||
softwareupdate --install-rosetta
|
||||
```
|
||||
|
||||
{{% /alert %}}
|
||||
|
||||
### Install without `sudo`
|
||||
If you do not have access to the `sudo` command or your username is not in the `sudoers` file you can install Dapr to an alternate directory via the `DAPR_INSTALL_DIR` environment variable.
|
||||
|
||||
```bash
|
||||
curl -fsSL https://raw.githubusercontent.com/dapr/cli/master/install/install.sh | DAPR_INSTALL_DIR="$HOME/dapr" /bin/bash
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
|
@ -54,7 +76,7 @@ Each release of Dapr CLI includes various OSes and architectures. These binary v
|
|||
1. Download the desired Dapr CLI from the latest [Dapr Release](https://github.com/dapr/cli/releases)
|
||||
2. Unpack it (e.g. dapr_linux_amd64.tar.gz, dapr_windows_amd64.zip)
|
||||
3. Move it to your desired location.
|
||||
- For Linux/MacOS - `/usr/local/bin`
|
||||
- For Linux/MacOS `/usr/local/bin` is recommended.
|
||||
- For Windows, create a directory and add this to your System PATH. For example create a directory called `C:\dapr` and add this directory to your User PATH, by editing your system environment variable.
|
||||
{{% /codetab %}}
|
||||
{{< /tabs >}}
|
||||
|
|
|
|||
|
|
@ -52,8 +52,8 @@ dapr --version
|
|||
|
||||
Output should look like this:
|
||||
```
|
||||
CLI version: 1.2.0
|
||||
Runtime version: 1.2.0
|
||||
CLI version: 1.3.0
|
||||
Runtime version: 1.3.0
|
||||
```
|
||||
|
||||
### Step 4: Verify containers are running
|
||||
|
|
|
|||
|
|
@ -17,11 +17,11 @@ The [Dapr Quickstarts](https://github.com/dapr/quickstarts/tree/v1.0.0) are a co
|
|||
|
||||
| Quickstart | Description |
|
||||
|--------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| [Hello World](https://github.com/dapr/quickstarts/tree/v1.0.0/hello-world) | Demonstrates how to run Dapr locally. Highlights service invocation and state management. |
|
||||
| [Hello Kubernetes](https://github.com/dapr/quickstarts/tree/v1.0.0/hello-kubernetes) | Demonstrates how to run Dapr in Kubernetes. Highlights service invocation and state management. |
|
||||
| [Distributed Calculator](https://github.com/dapr/quickstarts/tree/v1.0.0/distributed-calculator) | Demonstrates a distributed calculator application that uses Dapr services to power a React web app. Highlights polyglot (multi-language) programming, service invocation and state management. |
|
||||
| [Pub/Sub](https://github.com/dapr/quickstarts/tree/v1.0.0/pub-sub) | Demonstrates how to use Dapr to enable pub-sub applications. Uses Redis as a pub-sub component. |
|
||||
| [Bindings](https://github.com/dapr/quickstarts/tree/v1.0.0/bindings) | Demonstrates how to use Dapr to create input and output bindings to other components. Uses bindings to Kafka. |
|
||||
| [Middleware](https://github.com/dapr/quickstarts/tree/v1.0.0/middleware) | Demonstrates use of Dapr middleware to enable OAuth 2.0 authorization. |
|
||||
| [Observability](https://github.com/dapr/quickstarts/tree/v1.0.0/observability) | Demonstrates Dapr tracing capabilities. Uses Zipkin as a tracing component. |
|
||||
| [Secret Store](https://github.com/dapr/quickstarts/tree/v1.0.0/secretstore) | Demonstrates the use of Dapr Secrets API to access secret stores. |
|
||||
| [Hello World](https://github.com/dapr/quickstarts/tree/v1.3.0/hello-world) | Demonstrates how to run Dapr locally. Highlights service invocation and state management. |
|
||||
| [Hello Kubernetes](https://github.com/dapr/quickstarts/tree/v1.3.0/hello-kubernetes) | Demonstrates how to run Dapr in Kubernetes. Highlights service invocation and state management. |
|
||||
| [Distributed Calculator](https://github.com/dapr/quickstarts/tree/v1.3.0/distributed-calculator) | Demonstrates a distributed calculator application that uses Dapr services to power a React web app. Highlights polyglot (multi-language) programming, service invocation and state management. |
|
||||
| [Pub/Sub](https://github.com/dapr/quickstarts/tree/v1.3.0/pub-sub) | Demonstrates how to use Dapr to enable pub-sub applications. Uses Redis as a pub-sub component. |
|
||||
| [Bindings](https://github.com/dapr/quickstarts/tree/v1.3.0/bindings) | Demonstrates how to use Dapr to create input and output bindings to other components. Uses bindings to Kafka. |
|
||||
| [Middleware](https://github.com/dapr/quickstarts/tree/v1.3.0/middleware) | Demonstrates use of Dapr middleware to enable OAuth 2.0 authorization. |
|
||||
| [Observability](https://github.com/dapr/quickstarts/tree/v1.3.0/observability) | Demonstrates Dapr tracing capabilities. Uses Zipkin as a tracing component. |
|
||||
| [Secret Store](https://github.com/dapr/quickstarts/tree/v1.3.0/secretstore) | Demonstrates the use of Dapr Secrets API to access secret stores. |
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ A Dapr sidecar can apply a specific configuration by using a ```dapr.io/config``
|
|||
dapr.io/app-port: "3000"
|
||||
dapr.io/config: "myappconfig"
|
||||
```
|
||||
Note: There are more [Kubernetes annotations]({{< ref "kubernetes-annotations.md" >}}) available to configure the Dapr sidecar on activation by sidecar Injector system service.
|
||||
Note: There are more [Kubernetes annotations]({{< ref "arguments-annotations-overview.md" >}}) available to configure the Dapr sidecar on activation by sidecar Injector system service.
|
||||
|
||||
### Sidecar configuration settings
|
||||
|
||||
|
|
|
|||
|
|
@ -57,4 +57,4 @@ spec:
|
|||
{{< /tabs >}}
|
||||
|
||||
## Related links
|
||||
- [Dapr Kubernetes pod annotations spec]({{< ref kubernetes-annotations.md >}})
|
||||
- [Dapr Kubernetes pod annotations spec]({{< ref arguments-annotations-overview.md >}})
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ description: "Restrict what operations *calling* applications can perform, via s
|
|||
|
||||
Access control enables the configuration of policies that restrict what operations *calling* applications can perform, via service invocation, on the *called* application. To limit access to a called applications from specific operations and HTTP verbs from the calling applications, you can define an access control policy specification in configuration.
|
||||
|
||||
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 applicatons to access to the called app.
|
||||
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.
|
||||
<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>
|
||||
|
|
@ -194,7 +194,7 @@ spec:
|
|||
|
||||
## Hello world examples
|
||||
These examples show how to apply access control to the [hello world](https://github.com/dapr/quickstarts#quickstarts) quickstart samples where a python app invokes a node.js app.
|
||||
Access control lists rely on the Dapr [Sentry service]({{< ref "security-concept.md" >}}) to generate the TLS certificates with a SPIFFE id for authentication, which means the Sentry service either has to be running locally or deployed to your hosting enviroment such as a Kubernetes cluster.
|
||||
Access control lists rely on the Dapr [Sentry service]({{< ref "security-concept.md" >}}) to generate the TLS certificates with a SPIFFE id for authentication, which means the Sentry service either has to be running locally or deployed to your hosting environment such as a Kubernetes cluster.
|
||||
|
||||
The nodeappconfig example below shows how to **deny** access to the `neworder` method from the `pythonapp`, where the python app is in the `myDomain` trust domain and `default` namespace. The nodeapp is in the `public` trust domain.
|
||||
|
||||
|
|
|
|||
|
|
@ -7,20 +7,19 @@ description: "How to specify and enable preview features"
|
|||
---
|
||||
|
||||
## Overview
|
||||
Some features in Dapr are considered experimental when they are first released. These features require explicit opt-in in order to be used. The opt-in is specified in Dapr's configuration.
|
||||
Preview features in Dapr are considered experimental when they are first released. These preview features require explicit opt-in in order to be used. The opt-in is specified in Dapr's configuration.
|
||||
|
||||
Currently, preview features are enabled on a per application basis when running on Kubernetes. A global scope may be introduced in the future should there be a use case for it.
|
||||
Preview features are enabled on a per application basis by setting configuration when running an application instance.
|
||||
|
||||
### Current preview features
|
||||
Below is a list of existing preview features:
|
||||
- [Actor Reentrancy]({{<ref actor-reentrancy.md>}})
|
||||
### Preview features
|
||||
The current list of preview features can be found [here]({{<ref support-preview-features>}}).
|
||||
|
||||
## Configuration properties
|
||||
The `features` section under the `Configuration` spec contains the following properties:
|
||||
|
||||
| Property | Type | Description |
|
||||
|----------------|--------|-------------|
|
||||
|name|string|The name of the preview feature that will be enabled/disabled
|
||||
|name|string|The name of the preview feature that is enabled/disabled
|
||||
|enabled|bool|Boolean specifying if the feature is enabled or disabled
|
||||
|
||||
## Enabling a preview feature
|
||||
|
|
|
|||
|
|
@ -96,7 +96,7 @@ spec:
|
|||
|
||||
This example defines configuration for secret store named vault. The default access to the secret store is `deny`, whereas some secrets are accessible by the application based on the `allowedSecrets` list. Follow [these instructions]({{< ref configuration-overview.md >}}) to apply configuration to the sidecar.
|
||||
|
||||
### Scenario 3: Deny access to certain senstive secrets in a secret store
|
||||
### Scenario 3: Deny access to certain sensitive secrets in a secret store
|
||||
|
||||
Define the following `config.yaml`:
|
||||
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ minikube config set vm-driver [driver_name]
|
|||
Use 1.13.x or newer version of Kubernetes with `--kubernetes-version`
|
||||
|
||||
```bash
|
||||
minikube start --cpus=4 --memory=4096 --kubernetes-version=1.16.2 --extra-config=apiserver.authorization-mode=RBAC
|
||||
minikube start --cpus=4 --memory=4096
|
||||
```
|
||||
|
||||
3. Enable dashboard and ingress addons
|
||||
|
|
|
|||
|
|
@ -1,38 +0,0 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Dapr Kubernetes pod annotations spec"
|
||||
linkTitle: "Kubernetes annotations"
|
||||
weight: 50000
|
||||
description: "The available annotations available when configuring Dapr in your Kubernetes environment"
|
||||
---
|
||||
|
||||
The following table shows all the supported pod Spec annotations supported by Dapr.
|
||||
|
||||
| Annotation | Description |
|
||||
|---------------------------------------------------|-------------|
|
||||
| `dapr.io/enabled` | Setting this paramater to `true` injects the Dapr sidecar into the pod
|
||||
| `dapr.io/app-port` | This parameter tells Dapr which port your application is listening on
|
||||
| `dapr.io/app-id` | The unique ID of the application. Used for service discovery, state encapsulation and the pub/sub consumer ID
|
||||
| `dapr.io/log-level` | Sets the log level for the Dapr sidecar. Allowed values are `debug`, `info`, `warn`, `error`. Default is `info`
|
||||
| `dapr.io/config` | Tells Dapr which Configuration CRD to use
|
||||
| `dapr.io/log-as-json` | Setting this parameter to `true` outputs logs in JSON format. Default is `false`
|
||||
| `dapr.io/enable-profiling` | Setting this paramater to `true` starts the Dapr profiling server on port `7777`. Default is `false`
|
||||
| `dapr.io/api-token-secret` | Tells Dapr which Kubernetes secret to use for token based API authentication. By default this is not set.
|
||||
| `dapr.io/app-protocol` | Tells Dapr which protocol your application is using. Valid options are `http` and `grpc`. Default is `http`
|
||||
| `dapr.io/app-max-concurrency` | Limit the concurrency of your application. A valid value is any number larger than `0`
|
||||
| `dapr.io/app-ssl` | Tells Dapr to invoke the app over an insecure SSL connection. Applies to both HTTP and gRPC. Traffic between your app and the Dapr sidecar is encrypted with a certificate issued by a non-trusted certificate authority, which is considered insecure. Default is `false`.
|
||||
| `dapr.io/metrics-port` | Sets the port for the sidecar metrics server. Default is `9090`
|
||||
| `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
|
||||
| `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
|
||||
| `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
|
||||
| `dapr.io/sidecar-memory-request` | Amount of Memory 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
|
||||
| `dapr.io/sidecar-liveness-probe-delay-seconds` | Number of seconds after the sidecar container has started before liveness probe is initiated. Read more [here](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes). Default is `3`
|
||||
| `dapr.io/sidecar-liveness-probe-timeout-seconds` | Number of seconds after which the sidecar liveness probe times out. Read more [here](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes). Default is `3`
|
||||
| `dapr.io/sidecar-liveness-probe-period-seconds` | How often (in seconds) to perform the sidecar liveness probe. Read more [here](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes). Default is `6`
|
||||
| `dapr.io/sidecar-liveness-probe-threshold` | When the sidecar liveness probe fails, Kubernetes will try N times before giving up. In this case, the Pod will be marked Unhealthy. Read more about `failureThreshold` [here](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes). Default is `3`
|
||||
| `dapr.io/sidecar-readiness-probe-delay-seconds` | Number of seconds after the sidecar container has started before readiness probe is initiated. Read more [here](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes). Default is `3`
|
||||
| `dapr.io/sidecar-readiness-probe-timeout-seconds` | Number of seconds after which the sidecar readiness probe times out. Read more [here](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes). Default is `3`
|
||||
| `dapr.io/sidecar-readiness-probe-period-seconds` | How often (in seconds) to perform the sidecar readiness probe. Read more [here](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes). Default is `6`
|
||||
| `dapr.io/sidecar-readiness-probe-threshold` | When the sidecar readiness probe fails, Kubernetes will try N times before giving up. In this case, the Pod will be marked Unready. Read more about `failureThreshold` [here](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes). Default is `3`
|
||||
| `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
|
||||
| `dapr.io/env` | List of environment variable to be injected into the sidecar. Strings consisting of key=value pairs separated by a comma.
|
||||
|
|
@ -22,7 +22,7 @@ Read [this guide]({{< ref kubernetes-deploy.md >}}) to learn how to deploy Dapr
|
|||
|
||||
## Adding Dapr to a Kubernetes deployment
|
||||
|
||||
Deploying and running a Dapr enabled application into your Kubernetes cluster is as simple as adding a few annotations to the deployment schemes. To give your service an `id` and `port` known to Dapr, turn on tracing through configuration and launch the Dapr sidecar container, you annotate your Kubernetes deployment like this. For more information check [dapr annotations]({{< ref kubernetes-annotations.md >}})
|
||||
Deploying and running a Dapr enabled application into your Kubernetes cluster is as simple as adding a few annotations to the deployment schemes. To give your service an `id` and `port` known to Dapr, turn on tracing through configuration and launch the Dapr sidecar container, you annotate your Kubernetes deployment like this. For more information check [dapr annotations]({{< ref arguments-annotations-overview.md >}})
|
||||
|
||||
```yml
|
||||
annotations:
|
||||
|
|
@ -34,7 +34,7 @@ Deploying and running a Dapr enabled application into your Kubernetes cluster is
|
|||
|
||||
## Pulling container images from private registries
|
||||
|
||||
Dapr works seamlessly with any user application container image, regardless of its origin. Simply init Dapr and add the [Dapr annotations]({{< ref kubernetes-annotations >}}) to your Kubernetes definition to add the Dapr sidecar.
|
||||
Dapr works seamlessly with any user application container image, regardless of its origin. Simply init Dapr and add the [Dapr annotations]({{< ref arguments-annotations-overview.md >}}) to your Kubernetes definition to add the Dapr sidecar.
|
||||
|
||||
The Dapr control-plane and sidecar images come from the [daprio Docker Hub](https://hub.docker.com/u/daprio) container registry, which is a public registry.
|
||||
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ The following Dapr control plane deployments are optional:
|
|||
|
||||
## Sidecar resource settings
|
||||
|
||||
To set the resource assignments for the Dapr sidecar, see the annotations [here]({{< ref "kubernetes-annotations.md" >}}).
|
||||
To set the resource assignments for the Dapr sidecar, see the annotations [here]({{< ref "arguments-annotations-overview.md" >}}).
|
||||
The specific annotations related to resource constraints are:
|
||||
|
||||
- `dapr.io/sidecar-cpu-limit`
|
||||
|
|
@ -61,7 +61,9 @@ The CPU and memory limits above account for the fact that Dapr is intended to a
|
|||
|
||||
When deploying Dapr in a production-ready configuration, it's recommended to deploy with a highly available (HA) configuration of the control plane, which creates 3 replicas of each control plane pod in the dapr-system namespace. This configuration allows for the Dapr control plane to survive node failures and other outages.
|
||||
|
||||
HA mode can be enabled with both the [Dapr CLI]({{< ref "kubernetes-deploy.md#install-in-highly-available-mode" >}}) and with [Helm charts]({{< ref "kubernetes-deploy.md#add-and-install-dapr-helm-chart" >}}).
|
||||
For a new Dapr deployment, the HA mode can be set with both the [Dapr CLI]({{< ref "kubernetes-deploy.md#install-in-highly-available-mode" >}}) and with [Helm charts]({{< ref "kubernetes-deploy.md#add-and-install-dapr-helm-chart" >}}).
|
||||
|
||||
For an existing Dapr deployment, enabling the HA mode requires additional steps. Please refer to [this paragraph]({{< ref "#enabling-high-availability-in-an-existing-dapr-deployment" >}}) for more details.
|
||||
|
||||
## Deploying Dapr with Helm
|
||||
|
||||
|
|
@ -139,6 +141,23 @@ APP ID APP PORT AGE CREATED
|
|||
nodeapp 3000 16h 2020-07-29 17:16.22
|
||||
```
|
||||
|
||||
### Enabling high-availability in an existing Dapr deployment
|
||||
|
||||
Enabling HA mode for an existing Dapr deployment requires two steps.
|
||||
|
||||
First, delete the existing placement stateful set:
|
||||
```bash
|
||||
kubectl delete statefulset.apps/dapr-placement-server -n dapr-system
|
||||
```
|
||||
Second, issue the upgrade command:
|
||||
```bash
|
||||
helm upgrade dapr ./charts/dapr -n dapr-system --set global.ha.enabled=true
|
||||
```
|
||||
|
||||
The reason for deletion of the placement stateful set is because in the HA mode, the placement service adds [Raft](https://raft.github.io/) for leader election. However, Kubernetes only allows for limited fields in stateful sets to be patched, subsequently failing upgrade of the placement service.
|
||||
|
||||
Deletion of the existing placement stateful set is safe. The agents will reconnect and re-register with the newly created placement service, which will persist its table in Raft.
|
||||
|
||||
## Recommended security configuration
|
||||
|
||||
When properly configured, Dapr ensures secure communication. It can also make your application more secure with a number of built-in features.
|
||||
|
|
|
|||
|
|
@ -11,15 +11,15 @@ description: "Follow these steps to upgrade Dapr on Kubernetes and ensure a smoo
|
|||
- [Dapr CLI]({{< ref install-dapr-cli.md >}})
|
||||
- [Helm 3](https://github.com/helm/helm/releases) (if using Helm)
|
||||
|
||||
## Upgrade existing cluster to 1.2.0
|
||||
## Upgrade existing cluster to 1.3.0
|
||||
There are two ways to upgrade the Dapr control plane on a Kubernetes cluster using either the Dapr CLI or Helm.
|
||||
|
||||
### Dapr CLI
|
||||
|
||||
The example below shows how to upgrade to version 1.2.0:
|
||||
The example below shows how to upgrade to version 1.3.0:
|
||||
|
||||
```bash
|
||||
dapr upgrade -k --runtime-version=1.2.0
|
||||
dapr upgrade -k --runtime-version=1.3.0
|
||||
```
|
||||
|
||||
You can provide all the available Helm chart configurations using the Dapr CLI.
|
||||
|
|
@ -43,7 +43,7 @@ To resolve this issue please run the follow command to upgrade the CustomResourc
|
|||
kubectl replace -f https://raw.githubusercontent.com/dapr/dapr/5a15b3e0f093d2d0938b12f144c7047474a290fe/charts/dapr/crds/configuration.yaml
|
||||
```
|
||||
|
||||
Then proceed with the `dapr upgrade --runtime-version 1.2.0 -k` command as above.
|
||||
Then proceed with the `dapr upgrade --runtime-version 1.3.0 -k` command as above.
|
||||
|
||||
### Helm
|
||||
|
||||
|
|
@ -81,6 +81,11 @@ From version 1.0.0 onwards, upgrading Dapr using Helm is no longer a disruptive
|
|||
|
||||
4. All done!
|
||||
|
||||
#### Upgrading existing Dapr to enable high availability mode
|
||||
|
||||
Enabling HA mode in an existing Dapr deployment requires additional steps. Please refer to [this paragraph]({{< ref "kubernetes-production.md#enabling-high-availability-in-an-existing-dapr-deployment" >}}) for more details.
|
||||
|
||||
|
||||
## Next steps
|
||||
|
||||
- [Dapr on Kubernetes]({{< ref kubernetes-overview.md >}})
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ The `dapr-placement` service is responsible for managing the actor distribution
|
|||
|
||||
## 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.
|
||||
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
|
||||
|
||||
|
|
|
|||
|
|
@ -25,11 +25,11 @@ description: "Follow these steps to upgrade Dapr in self-hosted mode and ensure
|
|||
dapr init
|
||||
```
|
||||
|
||||
1. Ensure you are using the latest version of Dapr (v1.2) with:
|
||||
1. Ensure you are using the latest version of Dapr (v1.3) with:
|
||||
|
||||
```bash
|
||||
$ dapr --version
|
||||
|
||||
CLI version: 1.2
|
||||
Runtime version: 1.2
|
||||
CLI version: 1.3
|
||||
Runtime version: 1.3
|
||||
```
|
||||
|
|
|
|||
|
|
@ -99,7 +99,7 @@ Each container will receive a unique IP on that network and be able to communica
|
|||
|
||||
[Docker Compose](https://docs.docker.com/compose/) can be used to define multi-container application configurations. If you wish to run multiple apps with Dapr sidecars locally without Kubernetes then it is recommended to use a Docker Compose definition (`docker-compose.yml`).
|
||||
|
||||
The syntax and tooling of Docker Compose is outside the scope of this article, however, it is recommended you refer to the [offical Docker documentation](https://docs.docker.com/compose/) for further details.
|
||||
The syntax and tooling of Docker Compose is outside the scope of this article, however, it is recommended you refer to the [official Docker documentation](https://docs.docker.com/compose/) for further details.
|
||||
|
||||
In order to run your applications using Dapr and Docker Compose you'll need to define the sidecar pattern in your `docker-compose.yml`. For example:
|
||||
|
||||
|
|
|
|||
|
|
@ -156,7 +156,7 @@ First you need to connect Prometheus as a data source to Grafana.
|
|||
|
||||
1. Find the dashboard that you imported and enjoy
|
||||
|
||||
<img src="/images/system-service-dashboard.png" alt="Screenshot of Dapr service dashbaord" width=900>
|
||||
<img src="/images/system-service-dashboard.png" alt="Screenshot of Dapr service dashboard" width=900>
|
||||
|
||||
{{% alert title="Tip" color="primary" %}}
|
||||
Hover your mouse over the `i` in the corner to the description of each chart:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,16 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Preview features"
|
||||
linkTitle: "Preview features"
|
||||
weight: 4000
|
||||
description: "List of current preview features"
|
||||
---
|
||||
Preview features in Dapr are considered experimental when they are first released. These preview features require explicit opt-in in order to be used. The opt-in is specified in Dapr's configuration. See [How-To: Enable preview features]({{<ref preview-features>}}) for information more information.
|
||||
|
||||
|
||||
## Current preview features
|
||||
| Description | Setting | Documentation |
|
||||
|-------------|---------|---------------|
|
||||
| Preview feature that enables Actors to be called multiple times in the same call chain allowing call backs between actors. | Actor.Reentrancy | [Actor reentrancy]({{<ref actor-reentrancy>}}) |
|
||||
| Preview feature that allows Actor reminders to be partitioned across multiple keys in the underlying statestore in order to improve scale and performance. | Actor.TypeMetadata | [How-To: Partition Actor Reminders]({{< ref "howto-actors.md#partitioning-reminders" >}}) |
|
||||
| Preview feature that enables you to call endpoints using service invocation on gRPC services through Dapr via gRPC proxying, without requiring the use of Dapr SDKs. | proxy.grpc | [How-To: Invoke services using gRPC]({{<ref howto-invoke-services-grpc>}}) |
|
||||
|
|
@ -33,27 +33,29 @@ The table below shows the versions of Dapr releases that have been tested togeth
|
|||
|--------------------|:--------:|:--------|---------|---------|---------|
|
||||
| Feb 17th 2021 | 1.0.0</br>| 1.0.0 | Java 1.0.0 </br>Go 1.0.0 </br>PHP 1.0.0 </br>Python 1.0.0 </br>.NET 1.0.0 | 0.6.0 | Unsupported |
|
||||
| Mar 4th 2021 | 1.0.1</br>| 1.0.1 | Java 1.0.2 </br>Go 1.0.0 </br>PHP 1.0.0 </br>Python 1.0.0 </br>.NET 1.0.0 | 0.6.0 | Unsupported |
|
||||
| Apr 1st 2021 | 1.1.0</br> | 1.1.0 | Java 1.0.2 </br>Go 1.1.0 </br>PHP 1.0.0 </br>Python 1.1.0 </br>.NET 1.1.0 | 0.6.0 | Supported |
|
||||
| Apr 6th 2021 | 1.1.1</br> | 1.1.0 | Java 1.0.2 </br>Go 1.1.0 </br>PHP 1.0.0 </br>Python 1.1.0 </br>.NET 1.1.0 | 0.6.0 | Supported |
|
||||
| Apr 16th 2021 | 1.1.2</br> | 1.1.0 | Java 1.0.2 </br>Go 1.1.0 </br>PHP 1.0.0 </br>Python 1.1.0 </br>.NET 1.1.0 | 0.6.0 | Supported |
|
||||
| May 26th 2021 | 1.2.0</br> | 1.2.0 | Java 1.1.0 </br>Go 1.1.0 </br>PHP 1.1.0 </br>Python 1.1.0 </br>.NET 1.2.0 | 0.6.0 | Supported (current) |
|
||||
| Apr 1st 2021 | 1.1.0</br> | 1.1.0 | Java 1.0.2 </br>Go 1.1.0 </br>PHP 1.0.0 </br>Python 1.1.0 </br>.NET 1.1.0 | 0.6.0 | Unsupported |
|
||||
| Apr 6th 2021 | 1.1.1</br> | 1.1.0 | Java 1.0.2 </br>Go 1.1.0 </br>PHP 1.0.0 </br>Python 1.1.0 </br>.NET 1.1.0 | 0.6.0 | Unsupported |
|
||||
| Apr 16th 2021 | 1.1.2</br> | 1.1.0 | Java 1.0.2 </br>Go 1.1.0 </br>PHP 1.0.0 </br>Python 1.1.0 </br>.NET 1.1.0 | 0.6.0 | Unsupported |
|
||||
| May 26th 2021 | 1.2.0</br> | 1.2.0 | Java 1.1.0 </br>Go 1.1.0 </br>PHP 1.1.0 </br>Python 1.1.0 </br>.NET 1.2.0 | 0.6.0 | Supported |
|
||||
| June 16th 2021 | 1.2.1</br> | 1.2.0 | Java 1.1.0 </br>Go 1.1.0 </br>PHP 1.1.0 </br>Python 1.1.0 </br>.NET 1.2.0 | 0.6.0 | Supported |
|
||||
| June 16th 2021 | 1.2.2</br> | 1.2.0 | Java 1.1.0 </br>Go 1.1.0 </br>PHP 1.1.0 </br>Python 1.1.0 </br>.NET 1.2.0 | 0.6.0 | Supported |
|
||||
| July 26th 2021 | 1.3</br> | 1.3.0 | Java 1.2.0 </br>Go 1.2.0 </br>PHP 1.1.0 </br>Python 1.2.0 </br>.NET 1.3.0 | 0.7.0 | Supported (current) |
|
||||
|
||||
## Upgrade paths
|
||||
After the 1.0 release of the runtime there may be situations where it is necessary to explicitly upgrade through an additional release to reach the desired target. For example an upgrade from v1.0 to v1.2 may need go pass through v1.1
|
||||
|
||||
The table below shows the tested upgrade paths for the Dapr runtime. For example you are able to upgrade from 1.0-rc4 to the 1.0 release. Any other combinations of upgrades have not been tested.
|
||||
The table below shows the tested upgrade paths for the Dapr runtime. Any other combinations of upgrades have not been tested.
|
||||
|
||||
General guidance on upgrading can be found for [self hosted mode]({{<ref self-hosted-upgrade>}}) and [Kubernetes]({{<ref kubernetes-upgrade>}}) deployments. It is best to review the target version release notes for specific guidance.
|
||||
|
||||
| Current Runtime version | Must upgrade through | Target Runtime version |
|
||||
|--------------------------|-----------------------|------------------------- |
|
||||
| 0.11 | N/A | 1.0.1 |
|
||||
| | 1.0.1 | 1.1.2 |
|
||||
| 1.0-rc1 to 1.0-rc4 | N/A | 1.0.1 |
|
||||
| 1.0.0 or 1.0.1 | N/A | 1.1.2 |
|
||||
| 1.1.0 or 1.1.1 | N/A | 1.1.2 |
|
||||
| 1.0.0 or 1.0.1 | 1.1.2 | 1.2.0 |
|
||||
| 1.1.0 to 1.1.2 | N/A | 1.2.0 |
|
||||
| 1.0.0 or 1.0.1 | N/A | 1.1.2 |
|
||||
| | 1.1.2 | 1.2.2 |
|
||||
| | 1.2.2 | 1.3.0 |
|
||||
| 1.1.0 to 1.1.2 | N/A | 1.2.2 |
|
||||
| | 1.2.2 | 1.3.0 |
|
||||
| 1.2.0 to 1.2.2 | N/A | 1.3.0 |
|
||||
|
||||
## Feature and deprecations
|
||||
There is a process for announcing feature deprecations. Deprecations are applied two (2) releases after the release in which they were announced. For example Feature X is announced to be deprecated in the 1.0.0 release notes and will then be removed in 1.2.0.
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ The most common cause of this failure is that a component (such as a state store
|
|||
|
||||
To diagnose the root cause:
|
||||
|
||||
- Significantly increase the liveness probe delay - [link]({{< ref "kubernetes-annotations.md" >}})
|
||||
- Significantly increase the liveness probe delay - [link]({{< ref "arguments-annotations-overview.md" >}})
|
||||
- Set the log level of the sidecar to debug - [link]({{< ref "logs-troubleshooting.md#setting-the-sidecar-log-level" >}})
|
||||
- Watch the logs for meaningful information - [link]({{< ref "logs-troubleshooting.md#viewing-logs-on-kubernetes" >}})
|
||||
|
||||
|
|
@ -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 disbaled 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.
|
||||
|
|
|
|||
|
|
@ -106,7 +106,7 @@ This section will guide you on how to view logs for Dapr system components as we
|
|||
|
||||
#### Sidecar Logs
|
||||
|
||||
When deployed in Kubernetes, the Dapr sidecar injector will inject an Dapr container named `daprd` into your annotated pod.
|
||||
When deployed in Kubernetes, the Dapr sidecar injector will inject a Dapr container named `daprd` into your annotated pod.
|
||||
In order to view logs for the sidecar, simply find the pod in question by running `kubectl get pods`:
|
||||
|
||||
```bash
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ To enable profiling in Standalone mode, pass the `--enable-profiling` and the `-
|
|||
Note that `profile-port` is not required, and if not provided Dapr will pick an available port.
|
||||
|
||||
```bash
|
||||
dapr run --enable-profiling true --profile-port 7777 python myapp.py
|
||||
dapr run --enable-profiling --profile-port 7777 python myapp.py
|
||||
```
|
||||
|
||||
### Kubernetes
|
||||
|
|
|
|||
|
|
@ -178,7 +178,16 @@ Creates a persistent reminder for an actor.
|
|||
POST/PUT http://localhost:<daprPort>/v1.0/actors/<actorType>/<actorId>/reminders/<name>
|
||||
```
|
||||
|
||||
Body:
|
||||
#### Request Body
|
||||
|
||||
A JSON object with the following fields:
|
||||
|
||||
| Field | Description |
|
||||
|-------|--------------|
|
||||
| dueTime | Specifies the time after which the reminder is invoked, its format should be [time.ParseDuration](https://pkg.go.dev/time#ParseDuration) format
|
||||
| period | Specifies the period between different invocations, its format should be [time.ParseDuration](https://pkg.go.dev/time#ParseDuration) format or ISO 8601 duration format with optional recurrence.
|
||||
|
||||
`period` field supports `time.Duration` format and ISO 8601 format (with some limitations). Only duration format of ISO 8601 duration `Rn/PnYnMnWnDTnHnMnS` is supported for `period`. Here `Rn/` specifies that the reminder will be invoked `n` number of times. It should be a positive integer greater than zero. If certain values are zero, the `period` can be shortened, for example 10 seconds can be specified in ISO 8601 duration as `PT10S`. If `Rn/` is not specified the reminder will run infinite number of times until deleted.
|
||||
|
||||
The following specifies a `dueTime` of 3 seconds and a period of 7 seconds.
|
||||
```json
|
||||
|
|
|
|||
|
|
@ -0,0 +1,54 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Dapr arguments and annotations for daprd, CLI, and Kubernetes"
|
||||
linkTitle: "Arguments and annotations"
|
||||
description: "The arguments and annotations available when configuring Dapr in different environments"
|
||||
weight: 300
|
||||
aliases:
|
||||
- "/operations/hosting/kubernetes/kubernetes-annotations/"
|
||||
---
|
||||
|
||||
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 |
|
||||
| `--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` |
|
||||
| `--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 |
|
||||
| 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
|
||||
| not supported | not supported | | `dapr.io/sidecar-memory-request` | Amount of Memory 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
|
||||
| not supported | not supported | | `dapr.io/sidecar-liveness-probe-delay-seconds` | Number of seconds after the sidecar container has started before liveness probe is initiated. Read more [here](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes). Default is `3`
|
||||
| not supported | not supported | | `dapr.io/sidecar-liveness-probe-timeout-seconds` | Number of seconds after which the sidecar liveness probe times out. Read more [here](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes). Default is `3`
|
||||
| not supported | not supported | | `dapr.io/sidecar-liveness-probe-period-seconds` | How often (in seconds) to perform the sidecar liveness probe. Read more [here](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes). Default is `6`
|
||||
| not supported | not supported | | `dapr.io/sidecar-liveness-probe-threshold` | When the sidecar liveness probe fails, Kubernetes will try N times before giving up. In this case, the Pod will be marked Unhealthy. Read more about `failureThreshold` [here](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes). Default is `3`
|
||||
| not supported | not supported | | `dapr.io/sidecar-readiness-probe-delay-seconds` | Number of seconds after the sidecar container has started before readiness probe is initiated. Read more [here](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes). Default is `3`
|
||||
| not supported | not supported | | `dapr.io/sidecar-readiness-probe-timeout-seconds` | Number of seconds after which the sidecar readiness probe times out. Read more [here](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes). Default is `3`
|
||||
| not supported | not supported | | `dapr.io/sidecar-readiness-probe-period-seconds` | How often (in seconds) to perform the sidecar readiness probe. Read more [here](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes). Default is `6`
|
||||
| not supported | not supported | | `dapr.io/sidecar-readiness-probe-threshold` | When the sidecar readiness probe fails, Kubernetes will try N times before giving up. In this case, the Pod will be marked Unready. Read more about `failureThreshold` [here](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes). Default is `3`
|
||||
| not supported | not supported | | `dapr.io/env` | List of environment variable to be injected into the sidecar. Strings consisting of key=value pairs separated by a comma.
|
||||
|
|
@ -24,6 +24,7 @@ Usage:
|
|||
dapr [command]
|
||||
|
||||
Available Commands:
|
||||
build-info Print build info of Dapr CLI and runtime
|
||||
completion Generates shell completion scripts
|
||||
components List all Dapr components. Supported platforms: Kubernetes
|
||||
configurations List all Dapr configurations. Supported platforms: Kubernetes
|
||||
|
|
@ -37,21 +38,23 @@ Available Commands:
|
|||
publish Publish a pub-sub event. Supported platforms: Self-hosted
|
||||
run Run Dapr and (optionally) your application side by side. Supported platforms: Self-hosted
|
||||
status Show the health status of Dapr services. Supported platforms: Kubernetes
|
||||
stop Stop Dapr instances and their associated apps. . Supported platforms: Self-hosted
|
||||
stop Stop Dapr instances and their associated apps. Supported platforms: Self-hosted
|
||||
uninstall Uninstall Dapr runtime. Supported platforms: Kubernetes and self-hosted
|
||||
upgrade Upgrades a Dapr control plane installation in a cluster. Supported platforms: Kubernetes
|
||||
|
||||
Flags:
|
||||
-h, --help help for dapr
|
||||
-v, --version version for dapr
|
||||
-h, --help help for dapr
|
||||
--log-as-json Log output in JSON format
|
||||
-v, --version version for dapr
|
||||
|
||||
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 >}})
|
||||
- [`dapr components`]({{< ref dapr-components.md >}})
|
||||
- [`dapr configurations`]({{< ref dapr-configurations.md >}})
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ description: "Detailed information on the run CLI command"
|
|||
|
||||
## Description
|
||||
|
||||
Run Dapr and (optionally) your application side by side.
|
||||
Run Dapr and (optionally) your application side by side. A full list comparing daprd arguments, CLI arguments, and Kubernetes annotations can be found [here]({{< ref arguments-annotations-overview.md >}}).
|
||||
|
||||
## Supported platforms
|
||||
|
||||
|
|
|
|||
|
|
@ -31,9 +31,9 @@ spec:
|
|||
|
||||
## Binding support
|
||||
|
||||
This component supports **output binding** with the folowing [HTTP methods/verbs](https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html):
|
||||
This component supports **output binding** with the following [HTTP methods/verbs](https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html):
|
||||
|
||||
- `create` : For backward compatability and treated like a post
|
||||
- `create` : For backward compatibility and treated like a post
|
||||
- `get` : Read data/records
|
||||
- `head` : Identical to get except that the server does not return a response body
|
||||
- `post` : Typically used to create records or send commands
|
||||
|
|
@ -133,7 +133,7 @@ To send data to the HTTP endpoint, invoke the HTTP binding with a `POST`, `PUT`,
|
|||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
Any metadata field that starts with a capital letter is passed as a request header.
|
||||
For example, the default content type is `application/json; charset=utf-8`. This can be overriden be setting the `Content-Type` metadata field.
|
||||
For example, the default content type is `application/json; charset=utf-8`. This can be overridden be setting the `Content-Type` metadata field.
|
||||
{{% /alert %}}
|
||||
|
||||
```json
|
||||
|
|
|
|||
|
|
@ -493,7 +493,7 @@ To perform a `fail-job` operation, invoke the Zeebe command binding with a `POST
|
|||
"data": {
|
||||
"jobKey": 2251799813685739,
|
||||
"retries": 5,
|
||||
"errorMessage": "some error occured"
|
||||
"errorMessage": "some error occurred"
|
||||
},
|
||||
"metadata": {},
|
||||
"operation": "fail-job"
|
||||
|
|
|
|||
|
|
@ -99,7 +99,7 @@ This middleware supplies a [`HTTPRequest`](#httprequest) as input.
|
|||
|
||||
### HTTPRequest
|
||||
|
||||
The `HTTPRequest` input contains all the revelant information about an incoming HTTP Request except it's body.
|
||||
The `HTTPRequest` input contains all the relevant information about an incoming HTTP Request except it's body.
|
||||
|
||||
```go
|
||||
type Input struct {
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ The above example uses secrets as plain strings. It is recommended to use a secr
|
|||
| deletedWhenUnused | N | Whether or not the queue should be configured to [auto-delete](https://www.rabbitmq.com/queues.html) Defaults to `"true"` | `"true"`, `"false"`
|
||||
| autoAck | N | Whether or not the queue consumer should [auto-ack](https://www.rabbitmq.com/confirms.html) messages. Defaults to `"false"` | `"true"`, `"false"`
|
||||
| deliveryMode | N | Persistence mode when publishing messages. Defaults to `"0"`. RabbitMQ treats `"2"` as persistent, all other numbers as non-persistent | `"0"`, `"2"`
|
||||
| requeueInFailure | N | Whether or not to requeue when sending a [negative acknolwedgement](https://www.rabbitmq.com/nack.html) in case of a failure. Defaults to `"false"` | `"true"`, `"false"`
|
||||
| requeueInFailure | N | Whether or not to requeue when sending a [negative acknowledgement](https://www.rabbitmq.com/nack.html) in case of a failure. Defaults to `"false"` | `"true"`, `"false"`
|
||||
| prefetchCount | N | Number of messages to [prefetch](https://www.rabbitmq.com/consumer-prefetch.html). Consider changing this to a non-zero value for production environments. Defaults to `"0"`, which means that all available messages will be pre-fetched. | `"2"`
|
||||
| reconnectWait | N | How long to wait (in seconds) before reconnecting if a connection failure occurs | `"0"`
|
||||
| concurrencyMode | N | `parallel` is the default, and allows processing multiple messages in parallel (limited by the `app-max-concurrency` annotation, if configured). Set to `single` to disable parallel processing. In most situations there's no reason to change this. | `parallel`, `single`
|
||||
|
|
|
|||
|
|
@ -30,6 +30,6 @@ spec:
|
|||
```
|
||||
## Related Links
|
||||
- [Secrets building block]({{< ref secrets >}})
|
||||
- [How-To: Retreive a secret]({{< ref "howto-secrets.md" >}})
|
||||
- [How-To: Retrieve a secret]({{< ref "howto-secrets.md" >}})
|
||||
- [How-To: Reference secrets in Dapr components]({{< ref component-secrets.md >}})
|
||||
- [Secrets API reference]({{< ref secrets_api.md >}})
|
||||
|
|
@ -58,7 +58,7 @@ The above example uses secrets as plain strings. It is recommended to use a loca
|
|||
| tlsServerName | N | TLS config server name | `"tls-server"` |
|
||||
| vaultTokenMountPath | Y | Path to file containing token | `"path/to/file"` |
|
||||
| vaultToken | Y | [Token](https://learn.hashicorp.com/tutorials/vault/tokens) for authentication within Vault. | `"tokenValue"` |
|
||||
| vaultKVPrefix | N | The prefix in vault. Defautls to `"dapr"` | `"dapr"`, `"myprefix"` |
|
||||
| vaultKVPrefix | N | The prefix in vault. Defaults to `"dapr"` | `"dapr"`, `"myprefix"` |
|
||||
| vaultKVUsePrefix | N | If false, vaultKVPrefix is forced to be empty. If the value is not given or set to true, vaultKVPrefix is used when accessing the vault. Setting it to false is needed to be able to use the BulkGetSecret method of the store. | `"true"`, `"false"` |
|
||||
|
||||
## Setup Hashicorp Vault instance
|
||||
|
|
|
|||
|
|
@ -7,12 +7,34 @@ aliases:
|
|||
- "/operations/components/setup-secret-store/supported-secret-stores/kubernetes-secret-store/"
|
||||
---
|
||||
|
||||
## Summary
|
||||
## 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.
|
||||
|
||||
Kubernetes has a built-in secrets store which Dapr components can use to retrieve secrets from. No special configuration is needed to setup the Kubernetes secrets store, and you are able to retrieve secrets from the `http://localhost:3500/v1.0/secrets/kubernetes/[my-secret]` URL. See this guide on [referencing secrets]({{< ref component-secrets.md >}}) to retrieve and use the secret with Dapr components.
|
||||
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.
|
||||
|
||||
{{% alert title="Scoping secret store access" color="warning" %}}
|
||||
When limiting access to secrets in your application using [secret scopes]({{<ref secrets-scopes.md>}}), it's important to include the default secret store in the scope definition in order to restrict it.
|
||||
{{% /alert %}}
|
||||
|
||||
## Create a custom Kubernetes secret store component
|
||||
|
||||
To setup a Kubernetes secret store create a component of type `secretstores.kubernetes`. See [this guide]({{< ref "setup-secret-store.md#apply-the-configuration" >}}) on how to create and apply a secretstore configuration. See this guide on [referencing secrets]({{< ref component-secrets.md >}}) to retrieve and use the secret with Dapr components.
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: mycustomsecretstore
|
||||
namespace: default
|
||||
spec:
|
||||
type: secretstores.kubernetes
|
||||
version: v1
|
||||
metadata:
|
||||
- name: ""
|
||||
```
|
||||
## Related links
|
||||
- [Secrets building block]({{< ref secrets >}})
|
||||
- [How-To: Retrieve a secret]({{< ref "howto-secrets.md" >}})
|
||||
- [How-To: Reference secrets in Dapr components]({{< ref component-secrets.md >}})
|
||||
- [Secrets API reference]({{< ref secrets_api.md >}})
|
||||
- [How To: Use secret scoping]({{<ref secrets-scopes.md>}})
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ will create the following record in a table:
|
|||
|
||||
## Concurrency
|
||||
|
||||
Azure Table Storage state concurrency is achieved by using `ETag`s according to [the official documenation]( https://docs.microsoft.com/en-us/azure/storage/common/storage-concurrency#managing-concurrency-in-table-storage).
|
||||
Azure Table Storage state concurrency is achieved by using `ETag`s according to [the official documentation]( https://docs.microsoft.com/en-us/azure/storage/common/storage-concurrency#managing-concurrency-in-table-storage).
|
||||
|
||||
|
||||
## Related links
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@ If you wish to use MongoDB as an actor store, append the following to the yaml.
|
|||
| collectionName | N | The name of the collection to use. Defaults to `"daprCollection"` | `"daprCollection"`
|
||||
| writeconcern | N | The write concern to use | `"majority"`
|
||||
| readconcern | N | The read concern to use | `"majority"`, `"local"`,`"available"`, `"linearizable"`, `"snapshot"`
|
||||
| operationTimeout | N | The timeout for the operation. Defautls to `"5s"` | `"5s"`
|
||||
| operationTimeout | N | The timeout for the operation. Defaults to `"5s"` | `"5s"`
|
||||
|
||||
> <sup>[*]</sup> The `server` and `host` fields are mutually exclusive. If neither or both are set, Dapr will return an error.
|
||||
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ The above example uses secrets as plain strings. It is recommended to use a secr
|
|||
| servers | Y | Comma delimited list of servers | `"zookeeper.default.svc.cluster.local:2181"`
|
||||
| sessionTimeout | Y | The session timeout value | `"5s"`
|
||||
| maxBufferSize | N | The maximum size of buffer. Defaults to `"1048576"` | `"1048576"`
|
||||
| maxConnBufferSize | N | The maximum size of connection buffer. Defautls to `"1048576`" | `"1048576"`
|
||||
| maxConnBufferSize | N | The maximum size of connection buffer. Defaults to `"1048576`" | `"1048576"`
|
||||
| keyPrefixPath | N | The key prefix path in Zookeeper. No default | `"dapr"`
|
||||
|
||||
## Setup Zookeeper
|
||||
|
|
|
|||
|
|
@ -12,12 +12,12 @@ data:
|
|||
# Any errors related to config map settings can be found in the KubeMonAgentEvents table in the Log Analytics workspace that the cluster is sending data to.
|
||||
[log_collection_settings]
|
||||
[log_collection_settings.stdout]
|
||||
# In the absense of this configmap, default value for enabled is true
|
||||
# In the absence of this configmap, default value for enabled is true
|
||||
enabled = true
|
||||
# exclude_namespaces setting holds good only if enabled is set to true
|
||||
# kube-system log collection is disabled by default in the absence of 'log_collection_settings.stdout' setting. If you want to enable kube-system, remove it from the following setting.
|
||||
# If you want to continue to disable kube-system log collection keep this namespace in the following setting and add any other namespace you want to disable log collection to the array.
|
||||
# In the absense of this configmap, default value for exclude_namespaces = ["kube-system"]
|
||||
# In the absence of this configmap, default value for exclude_namespaces = ["kube-system"]
|
||||
exclude_namespaces = ["kube-system"]
|
||||
[log_collection_settings.stderr]
|
||||
# Default value for enabled is true
|
||||
|
|
@ -25,17 +25,17 @@ data:
|
|||
# exclude_namespaces setting holds good only if enabled is set to true
|
||||
# kube-system log collection is disabled by default in the absence of 'log_collection_settings.stderr' setting. If you want to enable kube-system, remove it from the following setting.
|
||||
# If you want to continue to disable kube-system log collection keep this namespace in the following setting and add any other namespace you want to disable log collection to the array.
|
||||
# In the absense of this cofigmap, default value for exclude_namespaces = ["kube-system"]
|
||||
# In the absence of this cofigmap, default value for exclude_namespaces = ["kube-system"]
|
||||
exclude_namespaces = ["kube-system"]
|
||||
[log_collection_settings.env_var]
|
||||
# In the absense of this configmap, default value for enabled is true
|
||||
# In the absence of this configmap, default value for enabled is true
|
||||
enabled = true
|
||||
[log_collection_settings.enrich_container_logs]
|
||||
# In the absense of this configmap, default value for enrich_container_logs is false
|
||||
# In the absence of this configmap, default value for enrich_container_logs is false
|
||||
enabled = true
|
||||
# When this is enabled (enabled = true), every container log entry (both stdout & stderr) will be enriched with container Name & container Image
|
||||
[log_collection_settings.collect_all_kube_events]
|
||||
# In the absense of this configmap, default value for collect_all_kube_events is false
|
||||
# In the absence of this configmap, default value for collect_all_kube_events is false
|
||||
# When the setting is set to false, only the kube events with !normal event type will be collected
|
||||
enabled = false
|
||||
# When this is enabled (enabled = true), all kube events including normal events will be collected
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 221 KiB |
|
|
@ -0,0 +1 @@
|
|||
Subproject commit d3df194bad3826069b7c9cda5178196e92dacad1
|
||||
Loading…
Reference in New Issue