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

Updated docs for zipkin init (#648) 

* Updated docs for zipkin init

* Update README.md

* Update README.md

* Update environment-setup.md

* Update environment-setup.md

* Update README.md

* Update daprrun.md

Co-authored-by: Mark Fussell <mfussell@microsoft.com>
This commit is contained in:
Mukundan Sundararajan 2020-06-22 09:25:51 -07:00 committed by GitHub
parent 98fb6513da
commit 04971ff167
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
5 changed files with 45 additions and 67 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
concepts/configuration/README.md
View File

@ -9,8 +9,8 @@ An example of a per Dapr sidecar setting is configuring trace settings. An examp
- [Kubernetes control plane configuration](#Kubernetes-control-plane-configuration)
- [Control plane configuration settings](#control-plane-configuration-settings)
## Self hosted sidecar configuration
In self hosted mode the Dapr configuration is a configuration file, for example `myappconfig.yaml`. By default Dapr side looks in the `components/` sub-folder under the folder where you run your application for a configuration file.
## Self hosted sidecar configuration
In self hosted mode the Dapr configuration is a configuration file, for example `config.yaml`. By default Dapr sidecar looks in the default Dapr folder for the runtime configuration eg: `$HOME/.dapr/config.yaml` in Linux/MacOS and `%USERPROFILE%\.dapr\config.yaml` in Windows.
A Dapr sidecar can also apply a configuration by using a ```--config``` flag to the file path with ```dapr run``` CLI command.
@ -51,22 +51,22 @@ The `tracing` section under the `Configuration` spec contains the following prop
```yml
tracing:
enabled: true
expandParams: true
includeBody: true
samplingRate: "1"
```
The following table lists the different properties.
Property | Type | Description
---- | ------- | -----------
enabled | bool | Set tracing to be enabled or disabled
expandParams | bool | When true, expands parameters passed to HTTP endpoints
includeBody | bool | When true, includes the request body in the tracing event
samplingRate | string | Set sampling rate for tracing to be enabled or disabled.
`samplingRate` is used to enable or disable the tracing. To disable the sampling rate ,
set `samplingRate : "0"` in the configuration. The valid range of samplingRate is between 0 and 1 inclusive. The sampling rate determines whether a trace span should be sampled or not based on value. `samplingRate : "1"` samples all traces. By default, the sampling rate is (0.0001) or 1 in 10,000 traces.
### Middleware configuration
The `middleware` section under the `Configuration` spec contains the following properties:
The `httpPipeline` section under the `Configuration` spec contains the following properties:
```yml
httpPipeline:
@ -96,9 +96,7 @@ metadata:
namespace: default
spec:
tracing:
enabled: true
expandParams: true
includeBody: true
samplingRate: "1"
httpPipeline:
- name: oauth2
type: middleware.http.oauth2

33
getting-started/environment-setup.md
View File

@ -1,6 +1,6 @@
# Environment Setup
Dapr can be run in either Standalone or Kubernetes modes. Running Dapr runtime in Standalone mode enables you to develop Dapr applications in your local development environment and then deploy and run them in other Dapr supported environments. For example, you can develop Dapr applications in Standalone mode and then deploy them to any Kubernetes cluster.
Dapr can be run in either self hosted or Kubernetes modes. Running Dapr runtime in self hosted mode enables you to develop Dapr applications in your local development environment and then deploy and run them in other Dapr supported environments. For example, you can develop Dapr applications in self hosted mode and then deploy them to any Kubernetes cluster.
## Contents
@ -59,7 +59,7 @@ Each release of Dapr CLI includes various OSes and architectures. These binary v
- For Linux/MacOS - `/usr/local/bin`
- For Windows, create a directory and add this to your System PATH. For example create a directory called `c:\dapr` and add this directory to your path, by editing your system environment variable.
## Installing Dapr in standalone mode
## Installing Dapr in self hosted mode
### Install Dapr runtime using the CLI
@ -73,7 +73,7 @@ Install Dapr by running `dapr init` from a command prompt
$ dapr init
⌛ Making the jump to hyperspace...
Downloading binaries and setting up components
✅ Success! Dapr is up and running
✅ Success! Dapr is up and running. To get started, go here: https://aka.ms/dapr-getting-started
```
If you prefer you can also install to an alternate location by using `--install-path`:
@ -100,32 +100,31 @@ runtime version: v0.1.0
### Uninstall Dapr in a standalone mode
Uninstalling will remove the placement container.
Uninstalling removes the Placement service container.
```bash
$ dapr uninstall
```
It won't remove the redis container by default in case you were using it for other purposes. To remove both the placement and redis container:
It won't remove the Redis or Zipkin containers by default in case you were using them for other purposes. To remove Redis, Zipkin and actor Placement container as well as remove the default Dapr dir located at `$HOME/.dapr` or `%USERPROFILE%\.dapr\` run:
```bash
$ dapr uninstall --all
```
You should always run a `dapr uninstall` before running another `dapr init`.
You should always run `dapr uninstall` before running another `dapr init`.
## Installing Dapr on a Kubernetes cluster
When setting up Kubernetes you can do this either via the Dapr CLI or Helm.
When setting up Kubernetes, you can do this either via the Dapr CLI or Helm.
*Note that installing Dapr using the CLI is recommended for testing purposes only.*
Dapr will install the following pods:
Dapr installs the following pods:
* dapr-operator: manages components and k8s services endpoints for Dapr (state stores, pub-subs, etc.)
* dapr-sidecar-injector: injects Dapr into annotated pods
* dapr-placement: used for actors only. creates mapping tables that map actor instances to pods
* dapr-sentry: manages mTLS and acts as a certificate authority
* dapr-operator: Manages component updates and kubernetes services endpoints for Dapr (state stores, pub-subs, etc.)
* dapr-sidecar-injector: Injects Dapr into annotated deployment pods
* dapr-placement: Used for actors only. Creates mapping tables that map actor instances to pods
* dapr-sentry: Manages mTLS between services and acts as a certificate authority
### Setup Cluster
@ -138,10 +137,10 @@ You can install Dapr on any Kubernetes cluster. Here are some helpful links:
### Using the Dapr CLI
You can install Dapr to Kubernetes cluster using CLI.
You can install Dapr to a Kubernetes cluster using CLI.
> Please note, that using the CLI does not support non-default namespaces.
> If you need a non-default namespace, Helm has to be used (see below).
> **Note:** that using the CLI does not support non-default namespaces.
> If you need a non-default namespace, Helm installation has to be used (see below).
#### Install Dapr to Kubernetes
@ -151,7 +150,7 @@ $ dapr init --kubernetes
⌛ Making the jump to hyperspace...
✅ Deploying the Dapr Operator to your cluster...
✅ Success! Dapr has been installed. To verify, run 'kubectl get pods -w' in your terminal
✅ Success! Dapr has been installed. To verify, run 'kubectl get pods -w' in your terminal. To get started, go here: https://aka.ms/dapr-getting-started
```
Dapr CLI installs Dapr to `default` namespace of Kubernetes cluster using [this](https://daprreleases.blob.core.windows.net/manifest/dapr-operator.yaml) manifest.

36
howto/diagnose-with-tracing/zipkin.md
View File

@ -7,9 +7,9 @@
## Configure self hosted mode
For self hosted mode, create a Dapr configuration file locally and reference it with the Dapr CLI.
For self hosted mode, on running `dapr init` the following YAML files are created by default and they are referenced by default on `dapr run` calls unless otherwise overridden.
1. Create the following YAML files:
1. The following file in `$HOME/dapr/components/zipkin.yaml` or `%USERPROFILE%\dapr\components\zipkin.yaml`:
* zipkin.yaml
@ -27,32 +27,33 @@ spec:
- name: exporterAddress
value: "http://localhost:9411/api/v2/spans"
```
2. The following file in `$HOME/dapr/config.yaml` or `%USERPROFILE%\dapr\config.yaml`:
* tracing.yaml
* config.yaml
```yaml
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: tracing
name: daprConfig
namespace: default
spec:
tracing:
samplingRate: "1"
```
2. Copy `zipkin.yaml` to a `/components` subfolder under the same folder where you run your application.
3. The [openzipkin/zipkin](https://hub.docker.com/r/openzipkin/zipkin/) docker container is launched on running `dapr init` or it can be launched with the following code.
3. Launch Zipkin using Docker:
Launch Zipkin using Docker:
```bash
docker run -d -p 9411:9411 openzipkin/zipkin
```
3. Launch your application with Dapr CLI using the `--config` param:
4. The applications launched with `dapr run` will by default reference the config file in `$HOME/dapr/config.yaml` or `%USERPROFILE%\dapr\config.yaml` and can be overridden with the Dapr CLI using the `--config` param:
```bash
dapr run --app-id mynode --app-port 3000 --config ./tracing.yaml node app.js
dapr run --app-id mynode --app-port 3000 node app.js
```
### Viewing Traces
To view traces, in your browser go to http://localhost:9411 and you will see the Zipkin UI.
@ -135,25 +136,6 @@ In your browser, go to ```http://localhost:9411``` and you will see the Zipkin U
![zipkin](../../images/zipkin_ui.png)
## Tracing configuration
The `tracing` section under the `Configuration` spec contains the following properties:
```yml
tracing:
samplingRate: "1"
```
The following table lists the different properties.
Property | Type | Description
---- | ------- | -----------
samplingRate | string | Set sampling rate for tracing to be enabled or disabled.
`samplingRate` is used to enable or disable the tracing. To disable the sampling rate ,
set `samplingRate : "0"` in the configuration. The valid range of samplingRate is between 0 and 1 inclusive. The sampling rate determines whether a trace span should be sampled or not based on value. `samplingRate : "1"` will always sample the traces.By default, the sampling rate is 1 in 10,000
## References
* [How-To: Use W3C Trace Context for distributed tracing](../../howto/use-w3c-tracecontext/readme.md)

9
howto/intellij-debugging-daprd/README.md
View File

@ -1,18 +1,17 @@
# Configuring IntelliJ Community Edition for debugging with daprd
When developing Dapr applications, you typically use the Dapr cli to start your 'Daprized' service similar to this:
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 --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.
This uses the default components yaml files (created on `dapr init`) 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.
>Note: 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.
One approach to attaching the debugger to your service is to first run `daprd` or `dapr` 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.
This document will explain how to use `daprd` directly from IntelliJ. As a pre-requisite, make sure you have initialized the Dapr's dev environment via `dapr init`.
This document explains how to use `daprd` directly from IntelliJ. As a pre-requisite, make sure you have initialized the Dapr's dev environment via `dapr init`.
Let's get started!
@ -70,6 +69,6 @@ Once the one-time config above is done, there are two steps required to debug a
After debugging, make sure you stop both `daprd` and your app in IntelliJ.
>Note: 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.
>Note: Since you didn't launch the service(s) using the **dapr** ***run*** CLI command, but instead by running **daprd**, the **dapr** ***list*** command does not show a list of apps that are currently running.
Happy debugging!

12
walkthroughs/daprrun.md
View File

@ -1,13 +1,13 @@
# Sequence of Events on a dapr run in Self Hosting Mode
The doc describes the sequence of events that occur when `dapr run` is executed in self hosting mode (formerly known as standalone mode). It uses [sample 1](https://github.com/dapr/samples/tree/master/1.hello-world) as an example.
The doc describes the sequence of events that occur when `dapr run` is executed in self hosting mode. It uses [sample 1](https://github.com/dapr/samples/tree/master/1.hello-world) as an example.
Terminology used below:
- Dapr CLI - the Dapr command line tool. The binary name is dapr (dapr.exe on Windows)
- Dapr runtime - this runs alongside each app. The binary name is daprd (daprd.exe on Windows)
In self hosting mode, running `dapr init` copies the Dapr runtime onto your box and starts the placement service (used for actors) and Redis in containers. These must be present before running `dapr run`. The Dapr CLI also creates the default components directory which for Linux/MacOS is: `$HOME/.dapr/components` and for Windows: `%USERPROFILE%\.dapr\components` if it does not already exist.
In self hosting mode, running `dapr init` copies the Dapr runtime onto your machine and starts the Placement service (used for actors placement) Redis and Zipkin in containers. The Redis and Placement service must be present before running `dapr run`. The Dapr CLI also creates the default components directory which for Linux/MacOS is: `$HOME/.dapr/components` and for Windows: `%USERPROFILE%\.dapr\components` if it does not already exist. The CLI creates a default `config.yaml` in `$HOME/.dapr` for Linux/MacOS or `%USERPROFILE%\.dapr` in Windows to enable tracing by default.
What happens when `dapr run` is executed?
@ -20,11 +20,11 @@ First, the Dapr CLI loads the components from the default directory (specified a
You can either add components to the default directory or create your own `components` directory and provide the path to the CLI using the `--components-path` flag.
In order to switch components, simply replace or add the YAML files in the components directory and run `dapr run` again.
For example, by default Dapr will use the Redis state store in the default components dir. You can either override it with a different YAML, or supply your own components path.
For example, by default Dapr uses the Redis state store in the default components dir. You can either override it with a different YAML, or supply your own components path.
Then, the Dapr CLI will [launch](https://github.com/dapr/cli/blob/d585612185a4a525c05fb62b86e288ccad510006/pkg/standalone/run.go#L290) two proceses: the Dapr runtime and your app (in this sample `node app.js`).
Then, the Dapr CLI [launches](https://github.com/dapr/cli/blob/d585612185a4a525c05fb62b86e288ccad510006/pkg/standalone/run.go#L290) two proceses: the Dapr runtime and your app (in this sample `node app.js`).
If you inspect the command lines of the Dapr runtime and the app, observe that the Dapr runtime has these args:
If you inspect the command line of the Dapr runtime and the app, observe that the Dapr runtime has these args:
```bash
daprd.exe --app-id mynode --dapr-http-port 3500 --dapr-grpc-port 43693 --log-level info --max-concurrency -1 --protocol http --app-port 3000 --placement-address localhost:50005
@ -38,7 +38,7 @@ node app.js
### Dapr runtime
The daprd process is started with the args above. `--app-id`, "nodeapp", which is the dapr app id, is forwarded from the Dapr CLI into `daprd` as the `--app-id` arg. Similarly:
The daprd process is started with the args above. `--app-id`, "nodeapp", which is the Dapr app id, is forwarded from the Dapr CLI into `daprd` as the `--app-id` arg. Similarly:
- the `--app-port` from the CLI, which represents the port on the app that `daprd` will use to communicate with it has been passed into the `--app-port` arg.
- the `--port` arg from the CLI, which represents the http port that daprd is listening on is passed into the `--dapr-http-port` arg. (Note to specify grpc instead you can use `--grpc-port`). If it's not specified, it will be -1 which means the Dapr CLI will chose a random free port. Below, it's 43693, yours will vary.