mirror of https://github.com/dapr/docs.git
Ori Zohar
GitHub
commit
e67ad98a1a
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Dapr Concepts"
|
||||
title: "Dapr concepts"
|
||||
linkTitle: "Concepts"
|
||||
weight: 10
|
||||
description: "Learn about Dapr including its main features and capabilities"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,7 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Overview of the Dapr services"
|
||||
linkTitle: "Dapr services"
|
||||
weight: 800
|
||||
description: "Learn about the services that make up the Dapr runtime"
|
||||
---
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Dapr operator service overview"
|
||||
linkTitle: "Operator"
|
||||
description: "Overview of the Dapr operator process"
|
||||
---
|
||||
|
||||
When running Dapr in [Kubernetes mode]({{< ref kubernetes >}}), a pod running the Dapr operator service manages [Dapr component]({{< ref components >}}) updates and provides Kubernetes services endpoints for Dapr.
|
||||
|
||||
## Running the operator service
|
||||
|
||||
The operator service is deployed as part of `dapr init -k`, or via the Dapr Helm charts. For more information on running Dapr on Kubernetes, visit the [Kubernetes hosting page]({{< ref kubernetes >}}).
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Dapr placement service overview"
|
||||
linkTitle: "Placement"
|
||||
description: "Overview of the Dapr placement process"
|
||||
---
|
||||
|
||||
The Dapr placement service is used to calculate and distribute distributed hash tables for the location of [Dapr actors]({{< ref actors >}}) running in [self-hosted mode]({{< ref self-hosted >}}) or on [Kubernetes]({{< ref kubernetes >}}). This hash table maps actor IDs to pods or processes so a Dapr application can communicate with the actor.Anytime a Dapr application activates a Dapr actor, the placement updates the hash tables with the latest actor locations.
|
||||
|
||||
## Self-hosted mode
|
||||
|
||||
The placement service Docker container is started automatically as part of [`dapr init`]({{< ref self-hosted-with-docker.md >}}). It can also be run manually as a process if you are running in [slim-init mode]({{< ref self-hosted-no-docker.md >}}).
|
||||
|
||||
## Kubernetes mode
|
||||
|
||||
The placement service is deployed as part of `dapr init -k`, or via the Dapr Helm charts. For more information on running Dapr on Kubernetes, visit the [Kubernetes hosting page]({{< ref kubernetes >}}).
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Dapr sentry service overview"
|
||||
linkTitle: "Sentry"
|
||||
description: "Overview of the Dapr sentry process"
|
||||
---
|
||||
|
||||
The Dapr sentry service manages mTLS between services and acts as a certificate authority. It generates mTLS certificates and distributes them to any running sidecars. This allows sidecars to communicate with encrypted, mTLS traffic. For more information read the [sidecar-to-sidecar communication overview]({{< ref "security-concept.md#sidecar-to-sidecar-communication" >}}).
|
||||
|
||||
## Self-hosted mode
|
||||
|
||||
The sentry service Docker container is started automatically as part of [`dapr init`]({{< ref self-hosted-with-docker.md >}}). It can also be run manually as a process if you are running in [slim-init mode]({{< ref self-hosted-no-docker.md >}}).
|
||||
|
||||
<img src="/images/security-mTLS-sentry-selfhosted.png" width=1000>
|
||||
|
||||
## Kubernetes mode
|
||||
|
||||
The sentry service is deployed as part of `dapr init -k`, or via the Dapr Helm charts. For more information on running Dapr on Kubernetes, visit the [Kubernetes hosting page]({{< ref kubernetes >}}).
|
||||
|
||||
<img src="/images/security-mTLS-sentry-kubernetes.png" width=1000>
|
||||
|
||||
## Further reading
|
||||
|
||||
- [Security overview]({{< ref security-concept.md >}})
|
||||
- [Self-hosted mode]({{< ref self-hosted-with-docker.md >}})
|
||||
- [Kubernetes mode]({{< ref kubernetes >}})
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Dapr sidecar injector overview"
|
||||
linkTitle: "Sidecar injector"
|
||||
description: "Overview of the Dapr sidecar injector process"
|
||||
---
|
||||
|
||||
When running Dapr in [Kubernetes mode]({{< ref kubernetes >}}), a pod is created running the dapr-sidecar-injector service, which looks for pods initialized with the [Dapr annotations]({{< ref arguments-annotations-overview.md >}}), and then creates another container in that pod for the [daprd service]({{< ref sidecar >}})
|
||||
|
||||
## Running the sidecar injector
|
||||
|
||||
The sidecar injector service is deployed as part of `dapr init -k`, or via the Dapr Helm charts. For more information on running Dapr on Kubernetes, visit the [Kubernetes hosting page]({{< ref kubernetes >}}).
|
||||
|
|
@ -0,0 +1,51 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Dapr sidecar (daprd) overview"
|
||||
linkTitle: "Sidecar"
|
||||
weight: 100
|
||||
description: "Overview of the Dapr sidecar process"
|
||||
---
|
||||
|
||||
Dapr uses a [sidecar pattern]({{< ref "overview.md#sidecar-architecture" >}}), meaning the Dapr APIs are run and exposed on a separate process (i.e. the Dapr sidecar) running alongside your application. The Dapr sidecar process is named `daprd` and is launched in different ways depending on the hosting environment.
|
||||
|
||||
<img src="/images/overview-sidecar-model.png" width=700>
|
||||
|
||||
## Self-hosted with `dapr run`
|
||||
|
||||
When Dapr is installed in [self-hosted mode]({{<ref self-hosted>}}), the `daprd` binary is downloaded and placed under the user home directory (`$HOME/.dapr/bin` for Linux/MacOS or `%USERPROFILE%\.dapr\bin\` for Windows). In self-hosted mode, running the Dapr CLI [`run` command]({{< ref dapr-run.md >}}) launches the `daprd` executable together with the provided application executable. This is the recommended way of running the Dapr sidecar when working locally in scenarios such as development and testing. The various arguments the CLI exposes to configure the sidecar can be found in the [Dapr run command reference]({{<ref dapr-run>}}).
|
||||
|
||||
## Kubernetes with `dapr-sidecar-injector`
|
||||
|
||||
On [Kubernetes]({{< ref kubernetes.md >}}), the Dapr control plane includes the [dapr-sidecar-injector service]({{< ref kubernetes-overview.md >}}), which watches for new pods with the `dapr.io/enabled` annotation and injects a container with the `daprd` process within the pod. In this case, sidecar arguments can be passed through annotations as outlined in the **Kubernetes annotations** column in [this table]({{<ref arguments-annotations-overview>}}).
|
||||
|
||||
## Running the sidecar directly
|
||||
|
||||
In most cases you do not need to run `daprd` explicitly, as the sidecar is either launched by the CLI (self-hosted mode) or by the dapr-sidecar-injector service (Kubernetes). For advanced use cases (debugging, scripted deployments, etc.) the `daprd` process can be launched directly.
|
||||
|
||||
For a detailed list of all available arguments run `daprd --help` or see this [table]({{< ref arguments-annotations-overview.md >}}) which outlines how the `daprd` arguments relate to the CLI arguments and Kubernetes annotations.
|
||||
|
||||
### Examples
|
||||
|
||||
1. Start a sidecar along an application by specifying its unique ID. Note `--app-id` is a required field:
|
||||
|
||||
```bash
|
||||
daprd --app-id myapp
|
||||
```
|
||||
|
||||
2. Specify the port your application is listening to
|
||||
|
||||
```bash
|
||||
daprd --app-id --app-port 5000
|
||||
```
|
||||
|
||||
3. If you are using several custom components and want to specify the location of the component definition files, use the `--components-path` argument:
|
||||
|
||||
```bash
|
||||
daprd --app-id myapp --components-path <PATH-TO-COMPONENTS-FILES>
|
||||
```
|
||||
|
||||
4. Enable collection of Prometheus metrics while running your app
|
||||
|
||||
```bash
|
||||
daprd --app-id myapp --enable-metrics
|
||||
```
|
||||
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Dapr terminology and definitions"
|
||||
linkTitle: "Terminology"
|
||||
weight: 800
|
||||
weight: 900
|
||||
description: Definitions for common terms and acronyms in the Dapr documentation
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Run Dapr in Self Hosted Mode"
|
||||
title: "Run Dapr in self-hosted mode"
|
||||
linkTitle: "Self-Hosted"
|
||||
weight: 1000
|
||||
description: "How to get Dapr up and running in your local environment"
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Performance and Scalability"
|
||||
linkTitle: "Performance and Scalability"
|
||||
title: "Performance and scalability statistics of Dapr"
|
||||
linkTitle: "Performance and scalability"
|
||||
weight: 700
|
||||
description: "Benchmarks and guidelines for Dapr building blocks"
|
||||
---
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ aliases:
|
|||
|
||||
This table is meant to help users understand the equivalent options for running Dapr sidecars in different contexts--via the [CLI]({{< ref cli-overview.md >}}) directly, via daprd, or on [Kubernetes]({{< ref kubernetes-overview.md >}}) via annotations.
|
||||
|
||||
| daprd | dapr CLI | CLI shorthand | K8s annotations | Description
|
||||
| daprd | Dapr CLI | CLI shorthand | Kubernetes annotations | Description
|
||||
|----- | ------- | -----------| ----------| ------------ |
|
||||
| `--allowed-origins` | not supported | | not supported | Allowed HTTP origins (default "*") |
|
||||
| `--app-id` | `--app-id` | `-i` | `dapr.io/app-id` | The unique ID of the application. Used for service discovery, state encapsulation and the pub/sub consumer ID |
|
||||
|
|
|
|||
Loading…
Reference in New Issue