mirror of https://github.com/dapr/docs.git
Merge branch 'v1.2' into add_java_sdk_docs
This commit is contained in:
Aaron Crawfis
GitHub
commit
36226b92c0
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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,26 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Bridge to Kubernetes support for Dapr services"
|
||||
linkTitle: "Bridge to Kubernetes"
|
||||
weight: 300
|
||||
description: "Debug Dapr apps locally which still connected to your Kubernetes cluster"
|
||||
---
|
||||
|
||||
Bridge to Kubernetes allows you to run and debug code on your development computer, while still connected to your Kubernetes cluster with the rest of your application or services. This type of debugging is often called *local tunnel debugging*.
|
||||
|
||||
{{< button text="Learn more about Bridge to Kubernetes" link="https://aka.ms/bridge-vscode-dapr" >}}
|
||||
|
||||
## Debug Dapr apps
|
||||
|
||||
Bridge to Kubernetes supports debugging Dapr apps on your machine, while still having them interact with the services and applications running on your Kubernetes cluster. This example showcases Bridge to Kubernetes enabling a developer to debug the [distributed calculator quickstart](https://github.com/dapr/quickstarts/tree/master/distributed-calculator):
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/rxwg-__otso" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
{{% alert title="Isolation mode" color="warning" %}}
|
||||
[Isolation mode](https://aka.ms/bridge-isolation-vscode-dapr) is currently not supported with Dapr apps. Make sure to launch Bridge to Kubernetes mode without isolation.
|
||||
{{% /alert %}}
|
||||
|
||||
## Further reading
|
||||
|
||||
- [Bridge to Kubernetes documentation](https://code.visualstudio.com/docs/containers/bridge-to-kubernetes)
|
||||
- [VSCode integration]({{< ref vscode >}})
|
||||
|
|
@ -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">
|
||||
|
|
|
|||
|
|
@ -1,227 +0,0 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Visual Studio Code integrations with Dapr"
|
||||
linkTitle: "Visual Studio Code"
|
||||
weight: 1000
|
||||
description: "Information on how to develop and run Dapr applications in VS Code"
|
||||
---
|
||||
|
||||
## Extension
|
||||
|
||||
Dapr offers a *preview* [Dapr Visual Studio Code extension](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-dapr) for local development and debugging of your Dapr applications.
|
||||
|
||||
<a href="vscode:extension/ms-azuretools.vscode-dapr" class="btn btn-primary" role="button">Open in VSCode</a>
|
||||
|
||||
### Feature overview
|
||||
- Scaffold Dapr task, launch, and component assets
|
||||
<br /><img src="/images/vscode-extension-scaffold.png" alt="Screenshot of the Dapr VSCode extension scaffold option" width="800">
|
||||
- View running Dapr applications
|
||||
<br /><img src="/images/vscode-extension-view.png" alt="Screenshot of the Dapr VSCode extension view running applications option" width="800">
|
||||
- Invoke Dapr application methods
|
||||
<br /><img src="/images/vscode-extension-invoke.png" alt="Screenshot of the Dapr VSCode extension invoke option" width="800">
|
||||
- Publish events to Dapr applications
|
||||
<br /><img src="/images/vscode-extension-publish.png" alt="Screenshot of the Dapr VSCode extension publish option" width="800">
|
||||
|
||||
#### Example
|
||||
Watch this [video](https://www.youtube.com/watch?v=OtbYCBt9C34&t=85) on how to use the Dapr VS Code extension:
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/OtbYCBt9C34?start=85" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
## Remote Dev Containers
|
||||
|
||||
The Visual Studio Code Remote Containers extension lets you use a Docker container as a full-featured development environment enabling you to [develop inside a container](https://code.visualstudio.com/docs/remote/containers) without installing any additional frameworks or packages to your local filesystem.
|
||||
|
||||
Dapr has pre-built Docker remote containers for each of the language SDKs. You can pick the one of your choice for a ready made environment. Note these pre-built containers automatically update to the latest Dapr release.
|
||||
|
||||
### Setup a remote dev container
|
||||
|
||||
#### Prerequisites
|
||||
- [Docker Desktop](https://www.docker.com/products/docker-desktop)
|
||||
- [Visual Studio Code](https://code.visualstudio.com/)
|
||||
- [VSCode Remote Development extension pack](https://aka.ms/vscode-remote/download/extension)
|
||||
|
||||
#### Create remote Dapr container
|
||||
1. Open your application workspace in VS Code
|
||||
2. In the command command palette (ctrl+shift+p) type and select `Remote-Containers: Add Development Container Configuration Files...`
|
||||
<br /><img src="/images/vscode-remotecontainers-addcontainer.png" alt="Screenshot of adding a remote container" width="700">
|
||||
3. Type `dapr` to filter the list to available Dapr remote containers and choose the language container that matches your application. Note you may need to select `Show All Definitions...`
|
||||
<br /><img src="/images/vscode-remotecontainers-daprcontainers.png" alt="Screenshot of adding a Dapr container" width="700">
|
||||
4. Follow the prompts to rebuild your application in container.
|
||||
<br /><img src="/images/vscode-remotecontainers-reopen.png" alt="Screenshot of reopening an application in the dev container" width="700">
|
||||
|
||||
#### Example
|
||||
Watch this [video](https://www.youtube.com/watch?v=D2dO4aGpHcg&t=120) on how to use the Dapr VS Code Remote Containers with your application.
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/D2dO4aGpHcg?start=120" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Debugging multiple Dapr applications at the same time
|
||||
Using the VS Code extension you can debug multiple Dapr applications at the same time with [Multi-target debugging](https://code.visualstudio.com/docs/editor/debugging#_multitarget-debugging)
|
||||
|
||||
|
||||
### Manually configuring Visual Studio Code for debugging with daprd
|
||||
If instead of using the Dapr VS Code extension you wish to configure a project to use Dapr in the [tasks.json](https://code.visualstudio.com/Docs/editor/tasks) and [launch.json](https://code.visualstudio.com/Docs/editor/debugging) files these are the manual 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
|
||||
```
|
||||
|
||||
This will generate the components yaml files (if they don't exist) so that your service can interact with the local redis container. This is great when you are just getting started but what if you want to attach a debugger to your service and step through the code? This is where you can use the dapr runtime (daprd) to help facilitate this.
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
The dapr runtime (daprd) will not automatically generate the components yaml files for Redis. These will need to be created manually or you will need to run the dapr cli (dapr) once in order to have them created automatically.
|
||||
{{% /alert %}}
|
||||
|
||||
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.
|
||||
|
||||
Let's get started!
|
||||
|
||||
#### 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) will reference 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 will 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 will 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 will 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 will 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 %}}
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Visual Studio Code integration with Dapr"
|
||||
linkTitle: "Visual Studio Code"
|
||||
weight: 1000
|
||||
description: "How to develop and run Dapr applications in Visual Studio Code"
|
||||
---
|
||||
|
|
@ -0,0 +1,66 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Dapr Visual Studio Code extension overview"
|
||||
linkTitle: "Dapr extension"
|
||||
weight: 10000
|
||||
description: "How to develop and run Dapr applications with the Dapr extension"
|
||||
---
|
||||
|
||||
|
||||
Dapr offers a *preview* [Dapr Visual Studio Code extension](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-dapr) for local development which enables users a variety of features related to better managing their Dapr applications and debugging of your Dapr applications for all supported Dapr languages which are .NET, Go, PHP, Python and Java.
|
||||
|
||||
<a href="vscode:extension/ms-azuretools.vscode-dapr" class="btn btn-primary" role="button">Open in VSCode</a>
|
||||
|
||||
## Features
|
||||
|
||||
### Scaffold Dapr debugging tasks
|
||||
|
||||
The Dapr extension helps you debug your applications with Dapr using Visual Studio Code's [built-in debugging capability](https://code.visualstudio.com/Docs/editor/debugging).
|
||||
|
||||
Using the `Dapr: Scaffold Dapr Tasks` [Command Palette](https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette) operation, you can update your existing `task.json` and `launch.json` files to launch and configure the Dapr sidecar when you begin debugging.
|
||||
|
||||
1. Make sure you have a launch configuration set for your app. ([Learn more](https://code.visualstudio.com/Docs/editor/debugging))
|
||||
2. Open the Command Palette with `Ctrl+Shift+P`
|
||||
3. Select `Dapr: Scaffold Dapr Tasks`
|
||||
4. Run your app and the Dapr sidecar with `F5` or via the Run view.
|
||||
|
||||
### Scaffold Dapr components
|
||||
|
||||
When adding Dapr to your application, you may want to have a dedicated components directory, separate from the default components initialized as part of `dapr init`.
|
||||
|
||||
To create a dedicated components folder with the default `statestore`, `pubsub`, and `zipkin` components, use the `Dapr: Scaffold Dapr Components` [Command Palette](https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette) operation.
|
||||
|
||||
1. Open your application directory in Visual Studio Code
|
||||
2. Open the Command Palette with `Ctrl+Shift+P`
|
||||
3. Select `Dapr: Scaffold Dapr Components`
|
||||
4. Run your application with `dapr run --components-path ./components -- ...`
|
||||
|
||||
### View running Dapr applications
|
||||
|
||||
The Applications view shows Dapr applications running locally on your machine.
|
||||
|
||||
<br /><img src="/images/vscode-extension-view.png" alt="Screenshot of the Dapr VSCode extension view running applications option" width="800">
|
||||
|
||||
### Invoke Dapr applications
|
||||
|
||||
Within the Applications view, users can right-click and invoke Dapr apps via GET or POST methods, optionally specifying a payload.
|
||||
|
||||
<br /><img src="/images/vscode-extension-invoke.png" alt="Screenshot of the Dapr VSCode extension invoke option" width="800">
|
||||
|
||||
### Publish events to Dapr applications
|
||||
|
||||
Within the Applications view, users can right-click and publish messages to a running Dapr application, specifying the topic and payload.
|
||||
|
||||
Users can also publish messages to all running applications.
|
||||
|
||||
<br /><img src="/images/vscode-extension-publish.png" alt="Screenshot of the Dapr VSCode extension publish option" width="800">
|
||||
## Additional resources
|
||||
|
||||
### Debugging multiple Dapr applications at the same time
|
||||
|
||||
Using the VS Code extension, you can debug multiple Dapr applications at the same time with [Multi-target debugging](https://code.visualstudio.com/docs/editor/debugging#_multitarget-debugging).
|
||||
|
||||
### Community call demo
|
||||
|
||||
Watch this [video](https://www.youtube.com/watch?v=OtbYCBt9C34&t=85) on how to use the Dapr VS Code extension:
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/OtbYCBt9C34?start=85" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
|
@ -0,0 +1,168 @@
|
|||
---
|
||||
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 %}}
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Developing Dapr applications with remote dev containers"
|
||||
linkTitle: "Remote dev containers"
|
||||
weight: 20000
|
||||
description: "How to setup a remote dev container environment with Dapr"
|
||||
---
|
||||
|
||||
The Visual Studio Code [Remote Containers extension](https://code.visualstudio.com/docs/remote/containers) lets you use a Docker container as a full-featured development environment without installing any additional frameworks or packages to your local filesystem.
|
||||
|
||||
Dapr has pre-built Docker remote containers for NodeJS and C#. You can pick the one of your choice for a ready made environment. Note these pre-built containers automatically update to the latest Dapr release.
|
||||
|
||||
### Setup a remote dev container
|
||||
|
||||
#### Prerequisites
|
||||
- [Docker Desktop](https://www.docker.com/products/docker-desktop)
|
||||
- [Visual Studio Code](https://code.visualstudio.com/)
|
||||
- [VSCode Remote Development extension pack](https://aka.ms/vscode-remote/download/extension)
|
||||
|
||||
#### Create remote Dapr container
|
||||
1. Open your application workspace in VS Code
|
||||
2. In the command command palette (`CTRL+SHIFT+P`) type and select `Remote-Containers: Add Development Container Configuration Files...`
|
||||
<br /><img src="/images/vscode-remotecontainers-addcontainer.png" alt="Screenshot of adding a remote container" width="700">
|
||||
3. Type `dapr` to filter the list to available Dapr remote containers and choose the language container that matches your application. Note you may need to select `Show All Definitions...`
|
||||
<br /><img src="/images/vscode-remotecontainers-daprcontainers.png" alt="Screenshot of adding a Dapr container" width="700">
|
||||
4. Follow the prompts to rebuild your application in container.
|
||||
<br /><img src="/images/vscode-remotecontainers-reopen.png" alt="Screenshot of reopening an application in the dev container" width="700">
|
||||
|
||||
#### Example
|
||||
Watch this [video](https://www.youtube.com/watch?v=D2dO4aGpHcg&t=120) on how to use the Dapr VS Code Remote Containers with your application.
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/D2dO4aGpHcg?start=120" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
@ -50,3 +50,4 @@ Dapr is tested and supported on the following versions of Kubernetes.
|
|||
- [Upgrade Dapr on a Kubernetes cluster]({{< ref kubernetes-upgrade >}})
|
||||
- [Production guidelines for Dapr on Kubernetes]({{< ref kubernetes-production.md >}})
|
||||
- [Dapr Kubernetes Quickstart](https://github.com/dapr/quickstarts/tree/master/hello-kubernetes)
|
||||
- [Use Bridge to Kubernetes to debug Dapr apps locally, while connected to your Kubernetes cluster]({{< ref bridge-to-kubernetes >}})
|
||||
|
|
|
|||
|
|
@ -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`
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -50,7 +50,7 @@ Use "dapr [command] --help" for more information about a command.
|
|||
|
||||
## Command Reference
|
||||
|
||||
You can learn more about each Dapr command from the links below.
|
||||
You can learn more about each Dapr command from the links below.
|
||||
|
||||
- [`dapr completion`]({{< ref dapr-completion.md >}})
|
||||
- [`dapr components`]({{< ref dapr-components.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
|
||||
|
|
|
|||
|
|
@ -497,7 +497,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 {
|
||||
|
|
|
|||
|
|
@ -51,7 +51,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 >}})
|
||||
|
|
@ -56,7 +56,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"` |
|
||||
|
||||
## Setup Hashicorp Vault instance
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -63,7 +63,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"`
|
||||
|
||||
## Setup MongoDB
|
||||
|
||||
|
|
@ -77,6 +77,9 @@ docker run --name some-mongo -d mongo
|
|||
```
|
||||
|
||||
You can then interact with the server using `localhost:27017`.
|
||||
|
||||
If you do not specify a `databaseName` value in your component definition, make sure to create a database named `daprStore`.
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue