mirror of https://github.com/dapr/docs.git
Merge branch 'v1.3' of https://github.com/berndverst/docs into v1.3
This commit is contained in:
commit
20e81cc5fd
|
@ -14,3 +14,6 @@
|
|||
path = translations/docs-zh
|
||||
url = https://github.com/dapr/docs-zh.git
|
||||
branch = v1.0_content
|
||||
[submodule "sdkdocs/go"]
|
||||
path = sdkdocs/go
|
||||
url = https://github.com/dapr/go-sdk.git
|
||||
|
|
|
@ -71,6 +71,14 @@ id = "UA-149338238-3"
|
|||
source = "../sdkdocs/dotnet/daprdocs/content/en/dotnet-sdk-contributing"
|
||||
target = "content/contributing/"
|
||||
lang = "en"
|
||||
[[module.mounts]]
|
||||
source = "../sdkdocs/go/daprdocs/content/en/go-sdk-docs"
|
||||
target = "content/developing-applications/sdks/go"
|
||||
lang = "en"
|
||||
[[module.mounts]]
|
||||
source = "../sdkdocs/go/daprdocs/content/en/go-sdk-contributing"
|
||||
target = "content/contributing/"
|
||||
lang = "en"
|
||||
|
||||
[[module.mounts]]
|
||||
source = "../translations/docs-zh/content/zh-hans"
|
||||
|
|
|
@ -101,7 +101,7 @@ Welcome to the Dapr documentation site!
|
|||
</div>
|
||||
</div>
|
||||
<div class="media mt-3">
|
||||
<a class="pr-4" href="{{< ref sdks >}}">
|
||||
<a class="pr-4" href="{{< ref go >}}">
|
||||
<img src="/images/homepage/golang.svg" alt="Go logo" width=30>
|
||||
</a>
|
||||
<div class="media-body">
|
||||
|
|
|
@ -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 >}})
|
|
@ -30,7 +30,6 @@ cd dapr
|
|||
make release GOOS=linux GOARCH=amd64 DEBUG=1
|
||||
```
|
||||
|
||||
>On Windows download [MingGW](https://sourceforge.net/projects/mingw/files/MinGW/Extension/make/mingw32-make-3.80-3/) and use `ming32-make.exe` instead of `make`.
|
||||
>On Windows download [MingGW](https://sourceforge.net/projects/mingw/files/MinGW/Extension/make/mingw32-make-3.80-3/) and use `ming32-make.exe` instead of `make`.
|
||||
|
||||
In the above command, 'DEBUG' is specified to '1' to disable compiler optimization. 'GOOS=linux' and 'GOARCH=amd64' are also necessary since the binaries will be packaged into Linux-based Docker image in the next step.
|
||||
|
|
|
@ -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>
|
|
@ -34,7 +34,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 | ✔ |
|
||||
| [Go](https://github.com/dapr/go-sdk) | Stable | ✔ | ✔ | |
|
||||
| [Go]({{< ref go >}}) | Stable | ✔ | ✔ | |
|
||||
| [PHP]({{< ref php >}}) | Stable | ✔ | ✔ | ✔ |
|
||||
| [C++](https://github.com/dapr/cpp-sdk) | In development | ✔ | |
|
||||
| [Rust](https://github.com/dapr/rust-sdk) | In development | ✔ | | |
|
||||
|
|
|
@ -65,6 +65,8 @@ Run the following command to launch a Dapr sidecar that will listen on port 3500
|
|||
dapr run --app-id myapp --dapr-http-port 3500 --components-path ./my-components
|
||||
```
|
||||
|
||||
> If you encounter a error message stating the app ID is already in use, it may be that the sidecar you ran in the previous step is still running. Make sure you stop the sidecar before running the above command (e.g. using "Control-C").
|
||||
|
||||
## Step 4: Get a secret
|
||||
|
||||
In a separate terminal run:
|
||||
|
|
|
@ -54,3 +54,4 @@ Dapr support for Kubernetes is aligned with [Kubernetes Version Skew Policy](htt
|
|||
- [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 >}})
|
||||
|
|
|
@ -381,7 +381,7 @@ Deletes a timer for an actor.
|
|||
|
||||
#### HTTP Request
|
||||
|
||||
```http
|
||||
```
|
||||
DELETE http://localhost:<daprPort>/v1.0/actors/<actorType>/<actorId>/timers/<name>
|
||||
```
|
||||
|
||||
|
|
|
@ -103,7 +103,7 @@ Adds a custom attribute to the Dapr sidecar information stored by the Metadata E
|
|||
|
||||
### HTTP Request
|
||||
|
||||
```http
|
||||
```
|
||||
PUT http://localhost:<daprPort>/v1.0/metadata/attributeName
|
||||
```
|
||||
|
||||
|
|
|
@ -41,11 +41,11 @@ The above example uses secrets as plain strings. It is recommended to use a secr
|
|||
|
||||
| Field | Required | Binding support | Details | Example |
|
||||
|--------------------|:--------:|--------|---------|---------|
|
||||
| storageAccount | Y | Output | The Blob Storage account name | `"myexmapleaccount"` |
|
||||
| storageAccessKey | Y | Output | The Blob Storage access key | `"access-key"` |
|
||||
| container | Y | Output | The name of the Blob Storage container to write to | `"myexamplecontainer"` |
|
||||
| decodeBase64 | N | Output | Configuration to decode base64 file content before saving to Blob Storage. (In case of saving a file with binary content). `"true"` is the only allowed positive value. Other positive variations like `"True"` are not acceptable. Defaults to `"false"` | `"true"`, `"false"` |
|
||||
| getBlobRetryCount | N | Output | Specifies the maximum number of HTTP GET requests that will be made while reading from a RetryReader Defaults to `"10"` | `"1"`, `"2"`
|
||||
| storageAccount | Y | Output | The Blob Storage account name | `myexmapleaccount` |
|
||||
| storageAccessKey | Y | Output | The Blob Storage access key | `access-key` |
|
||||
| container | Y | Output | The name of the Blob Storage container to write to | `myexamplecontainer` |
|
||||
| decodeBase64 | N | Output | Configuration to decode base64 file content before saving to Blob Storage. (In case of saving a file with binary content). `true` is the only allowed positive value. Other positive variations like `"True", "1"` are not acceptable. Defaults to `false` | `true`, `false` |
|
||||
| getBlobRetryCount | N | Output | Specifies the maximum number of HTTP GET requests that will be made while reading from a RetryReader Defaults to `10` | `1`, `2`
|
||||
|
||||
|
||||
## Binding support
|
||||
|
@ -55,6 +55,7 @@ This component supports **output binding** with the following operations:
|
|||
- `create` : [Create blob](#create-blob)
|
||||
- `get` : [Get blob](#get-blob)
|
||||
- `delete` : [Delete blob](#delete-blob)
|
||||
- `list`: [List blobs](#list-blobs)
|
||||
|
||||
### Create blob
|
||||
|
||||
|
@ -133,7 +134,7 @@ spec:
|
|||
- name: container
|
||||
value: container1
|
||||
- name: decodeBase64
|
||||
value: "true"
|
||||
value: true
|
||||
```
|
||||
|
||||
Then you can upload it as you would normally:
|
||||
|
@ -174,11 +175,17 @@ To perform a get blob operation, invoke the Azure Blob Storage binding with a `P
|
|||
{
|
||||
"operation": "get",
|
||||
"metadata": {
|
||||
"blobName": "myblob"
|
||||
"blobName": "myblob",
|
||||
"includeMetadata": "true"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The metadata parameters are:
|
||||
|
||||
- `blobName` - the name of the blob
|
||||
- `includeMetadata`- (optional) defines if the user defined metadata should be returned or not, defaults to: false
|
||||
|
||||
#### Example
|
||||
|
||||
{{< tabs Windows Linux >}}
|
||||
|
@ -200,7 +207,10 @@ To perform a get blob operation, invoke the Azure Blob Storage binding with a `P
|
|||
|
||||
#### Response
|
||||
|
||||
The response body contains the value stored in the blob object.
|
||||
The response body contains the value stored in the blob object. If enabled, the user defined metadata will be returned as HTTP headers in the form:
|
||||
|
||||
`Metadata.key1: value1`
|
||||
`Metadata.key2: value2`
|
||||
|
||||
### Delete blob
|
||||
|
||||
|
@ -215,6 +225,13 @@ To perform a delete blob operation, invoke the Azure Blob Storage binding with a
|
|||
}
|
||||
```
|
||||
|
||||
The metadata parameters are:
|
||||
|
||||
- `blobName` - the name of the blob
|
||||
- `deleteSnapshots` - (optional) required if the blob has associated snapshots. Specify one of the following two options:
|
||||
- include: Delete the base blob and all of its snapshots
|
||||
- only: Delete only the blob's snapshots and not the blob itself
|
||||
|
||||
#### Examples
|
||||
|
||||
##### Delete blob
|
||||
|
@ -242,13 +259,13 @@ To perform a delete blob operation, invoke the Azure Blob Storage binding with a
|
|||
|
||||
{{% codetab %}}
|
||||
```bash
|
||||
curl -d '{ \"operation\": \"delete\", \"metadata\": { \"blobName\": \"myblob\", \"DeleteSnapshotOptions\": \"only\" }}' http://localhost:<dapr-port>/v1.0/bindings/<binding-name>
|
||||
curl -d '{ \"operation\": \"delete\", \"metadata\": { \"blobName\": \"myblob\", \"deleteSnapshots\": \"only\" }}' http://localhost:<dapr-port>/v1.0/bindings/<binding-name>
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
```bash
|
||||
curl -d '{ "operation": "delete", "metadata": { "blobName": "myblob", "DeleteSnapshotOptions": "only" }}' \
|
||||
curl -d '{ "operation": "delete", "metadata": { "blobName": "myblob", "deleteSnapshots": "only" }}' \
|
||||
http://localhost:<dapr-port>/v1.0/bindings/<binding-name>
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
@ -261,13 +278,13 @@ To perform a delete blob operation, invoke the Azure Blob Storage binding with a
|
|||
|
||||
{{% codetab %}}
|
||||
```bash
|
||||
curl -d '{ \"operation\": \"delete\", \"metadata\": { \"blobName\": \"myblob\", \"DeleteSnapshotOptions\": \"include\" }}' http://localhost:<dapr-port>/v1.0/bindings/<binding-name>
|
||||
curl -d '{ \"operation\": \"delete\", \"metadata\": { \"blobName\": \"myblob\", \"deleteSnapshots\": \"include\" }}' http://localhost:<dapr-port>/v1.0/bindings/<binding-name>
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
```bash
|
||||
curl -d '{ "operation": "delete", "metadata": { "blobName": "myblob", "DeleteSnapshotOptions": "include" }}' \
|
||||
curl -d '{ "operation": "delete", "metadata": { "blobName": "myblob", "deleteSnapshots": "include" }}' \
|
||||
http://localhost:<dapr-port>/v1.0/bindings/<binding-name>
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
@ -278,6 +295,104 @@ To perform a delete blob operation, invoke the Azure Blob Storage binding with a
|
|||
|
||||
An HTTP 204 (No Content) and empty body will be retuned if successful.
|
||||
|
||||
### List blobs
|
||||
|
||||
To perform a list blobs operation, invoke the Azure Blob Storage binding with a `POST` method and the following JSON body:
|
||||
|
||||
```json
|
||||
{
|
||||
"operation": "list",
|
||||
"data": {
|
||||
"maxResults": 10,
|
||||
"prefix": "file",
|
||||
"marker": "2!108!MDAwMDM1IWZpbGUtMDgtMDctMjAyMS0wOS0zOC01NS03NzgtMjEudHh0ITAwMDAyOCE5OTk5LTEyLTMxVDIzOjU5OjU5Ljk5OTk5OTlaIQ--",
|
||||
"include": {
|
||||
"snapshots": false,
|
||||
"metadata": true,
|
||||
"uncommittedBlobs": false,
|
||||
"copy": false,
|
||||
"deleted": false
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The data parameters are:
|
||||
|
||||
- `maxResults` - (optional) specifies the maximum number of blobs to return, including all BlobPrefix elements. If the request does not specify maxresults the server will return up to 5,000 items.
|
||||
- `prefix` - (optional) filters the results to return only blobs whose names begin with the specified prefix.
|
||||
- `marker` - (optional) a string value that identifies the portion of the list to be returned with the next list operation. The operation returns a marker value within the response body if the list returned was not complete. The marker value may then be used in a subsequent call to request the next set of list items.
|
||||
- `include` - (optional) Specifies one or more datasets to include in the response:
|
||||
- snapshots: Specifies that snapshots should be included in the enumeration. Snapshots are listed from oldest to newest in the response. Defaults to: false
|
||||
- metadata: Specifies that blob metadata be returned in the response. Defaults to: false
|
||||
- uncommittedBlobs: Specifies that blobs for which blocks have been uploaded, but which have not been committed using Put Block List, be included in the response. Defaults to: false
|
||||
- copy: Version 2012-02-12 and newer. Specifies that metadata related to any current or previous Copy Blob operation should be included in the response. Defaults to: false
|
||||
- deleted: Version 2017-07-29 and newer. Specifies that soft deleted blobs should be included in the response. Defaults to: false
|
||||
|
||||
#### Response
|
||||
|
||||
The response body contains the list of found blocks as also the following HTTP headers:
|
||||
|
||||
`Metadata.marker: 2!108!MDAwMDM1IWZpbGUtMDgtMDctMjAyMS0wOS0zOC0zNC04NjctMTEudHh0ITAwMDAyOCE5OTk5LTEyLTMxVDIzOjU5OjU5Ljk5OTk5OTlaIQ--`
|
||||
`Metadata.number: 10`
|
||||
|
||||
- `marker` - the next marker which can be used in a subsequent call to request the next set of list items. See the marker description on the data property of the binding input.
|
||||
- `number` - the number of found blobs
|
||||
|
||||
The list of blobs will be returned as JSON array in the following form:
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"XMLName": {
|
||||
"Space": "",
|
||||
"Local": "Blob"
|
||||
},
|
||||
"Name": "file-08-07-2021-09-38-13-776-1.txt",
|
||||
"Deleted": false,
|
||||
"Snapshot": "",
|
||||
"Properties": {
|
||||
"XMLName": {
|
||||
"Space": "",
|
||||
"Local": "Properties"
|
||||
},
|
||||
"CreationTime": "2021-07-08T07:38:16Z",
|
||||
"LastModified": "2021-07-08T07:38:16Z",
|
||||
"Etag": "0x8D941E3593C6573",
|
||||
"ContentLength": 1,
|
||||
"ContentType": "application/octet-stream",
|
||||
"ContentEncoding": "",
|
||||
"ContentLanguage": "",
|
||||
"ContentMD5": "xMpCOKC5I4INzFCab3WEmw==",
|
||||
"ContentDisposition": "",
|
||||
"CacheControl": "",
|
||||
"BlobSequenceNumber": null,
|
||||
"BlobType": "BlockBlob",
|
||||
"LeaseStatus": "unlocked",
|
||||
"LeaseState": "available",
|
||||
"LeaseDuration": "",
|
||||
"CopyID": null,
|
||||
"CopyStatus": "",
|
||||
"CopySource": null,
|
||||
"CopyProgress": null,
|
||||
"CopyCompletionTime": null,
|
||||
"CopyStatusDescription": null,
|
||||
"ServerEncrypted": true,
|
||||
"IncrementalCopy": null,
|
||||
"DestinationSnapshot": null,
|
||||
"DeletedTime": null,
|
||||
"RemainingRetentionDays": null,
|
||||
"AccessTier": "Hot",
|
||||
"AccessTierInferred": true,
|
||||
"ArchiveStatus": "",
|
||||
"CustomerProvidedKeySha256": null,
|
||||
"AccessTierChangeTime": null
|
||||
},
|
||||
"Metadata": null
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
## Metadata information
|
||||
|
||||
By default the Azure Blob Storage output binding auto generates a UUID as the blob filename and is not assigned any system or custom metadata to it. It is configurable in the metadata property of the message (all optional).
|
||||
|
@ -289,13 +404,13 @@ Applications publishing to an Azure Blob Storage output binding should send a me
|
|||
"data": "file content",
|
||||
"metadata": {
|
||||
"blobName" : "filename.txt",
|
||||
"ContentType" : "text/plain",
|
||||
"ContentMD5" : "vZGKbMRDAnMs4BIwlXaRvQ==",
|
||||
"ContentEncoding" : "UTF-8",
|
||||
"ContentLanguage" : "en-us",
|
||||
"ContentDisposition" : "attachment",
|
||||
"CacheControl" : "no-cache",
|
||||
"Custom" : "hello-world",
|
||||
"contentType" : "text/plain",
|
||||
"contentMD5" : "vZGKbMRDAnMs4BIwlXaRvQ==",
|
||||
"contentEncoding" : "UTF-8",
|
||||
"contentLanguage" : "en-us",
|
||||
"contentDisposition" : "attachment",
|
||||
"cacheControl" : "no-cache",
|
||||
"custom" : "hello-world"
|
||||
},
|
||||
"operation": "create"
|
||||
}
|
||||
|
|
|
@ -9,7 +9,7 @@ description: "Detailed documentation on the Zeebe command binding component"
|
|||
|
||||
To setup Zeebe command binding create a component of type `bindings.zeebe.command`. See [this guide]({{< ref "howto-bindings.md#1-create-a-binding" >}}) on how to create and apply a binding configuration.
|
||||
|
||||
See [this](https://docs.camunda.io/docs/product-manuals/zeebe/zeebe-overview/) for Zeebe documentation.
|
||||
See [this](https://docs.camunda.io/docs/product-manuals/zeebe/zeebe-overview) for Zeebe documentation.
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
|
@ -59,8 +59,7 @@ This component supports **output binding** with the following operations:
|
|||
|
||||
### Output binding
|
||||
|
||||
Zeebe uses gRPC under the hood for the Zeebe client we use in this binding. Please consult the gRPC API reference for more information:
|
||||
https://stage.docs.zeebe.io/reference/grpc.html
|
||||
Zeebe uses gRPC under the hood for the Zeebe client we use in this binding. Please consult the [gRPC API reference](https://stage.docs.zeebe.io/reference/grpc.html) for more information.
|
||||
|
||||
#### topology
|
||||
|
||||
|
|
|
@ -82,6 +82,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 %}}
|
||||
|
|
|
@ -0,0 +1 @@
|
|||
Subproject commit fc67f725e0b5bb14ce903940fe889a76b59fceef
|
Loading…
Reference in New Issue