mirror of https://github.com/dapr/docs.git
Merge branch 'aacrawfi/concepts' of https://github.com/dapr/docs into aacrawfi/concepts
This commit is contained in:
Aaron Crawfis
commit
33c5f260a3
|
|
@ -16,7 +16,7 @@ Dapr uses a modular design where functionality is delivered as a component. Each
|
|||
|
||||
## State stores
|
||||
|
||||
State store components are databases that store key-value pairs as part of the [state management]({{< ref "state-management-overview.md" >}}) building block.
|
||||
State store components are data stores (databases, files, memory) that store key-value pairs as part of the [state management]({{< ref "state-management-overview.md" >}}) building block.
|
||||
|
||||
- [List of state stores]({{< ref supported-state-stores >}})
|
||||
- [State store implementations](https://github.com/dapr/components-contrib/tree/master/state)
|
||||
|
|
@ -35,21 +35,21 @@ Dapr allows custom [middleware]({{<ref "middleware-concept.md">}}) to be plugge
|
|||
|
||||
## Pub/sub brokers
|
||||
|
||||
Pub/sub broker components are message busses that can pass messages to/from services as part of the [publish & subscribe]({{< ref pubsub-overview.md >}}) building block.
|
||||
Pub/sub broker components are message brokers that can pass messages to/from services as part of the [publish & subscribe]({{< ref pubsub-overview.md >}}) building block.
|
||||
|
||||
- [List of pub/sub brokers]({{< ref supported-pubsub >}})
|
||||
- [Pub/sub broker implementations](https://github.com/dapr/components-contrib/tree/master/pubsub)
|
||||
|
||||
## Bindings
|
||||
|
||||
External resources can connect to Dapr in order to trigger a service or be invoked from a service as part of the [bindings]({{< ref bindings-overview.md >}}) building block.
|
||||
External resources can connect to Dapr in order to trigger a service or be called from a service as part of the [bindings]({{< ref bindings-overview.md >}}) building block.
|
||||
|
||||
- [List of supported bindings]({{< ref supported-bindings >}})
|
||||
- [Binding implementations](https://github.com/dapr/components-contrib/tree/master/bindings)
|
||||
|
||||
## Secret stores
|
||||
|
||||
In Dapr, a [secret]({{<ref "secrets-overview.md">}}) is any piece of private information that you want to guard against unwanted users. Secrets stores, used to store secrets, are Dapr components and can be used by any of the building blocks.
|
||||
In Dapr, a [secret]({{<ref "secrets-overview.md">}}) is any piece of private information that you want to guard against unwanted users. Secrets stores are used to store secrets that can be retrieved and used in services.
|
||||
|
||||
- [List of supported secret stores]({{< ref supported-secret-stores >}})
|
||||
- [Secret store implementations](https://github.com/dapr/components-contrib/tree/master/secretstores)
|
||||
- [Secret store implementations](https://github.com/dapr/components-contrib/tree/master/secretstores)
|
||||
|
|
|
|||
|
|
@ -6,27 +6,23 @@ weight: 400
|
|||
description: "Change the behavior of Dapr sidecars or globally on Dapr system services"
|
||||
---
|
||||
|
||||
Dapr configurations are settings that enable you to change both the behavior of individual Dapr application sidecars, the the global behavior of the system services in the Dapr control plane.
|
||||
Dapr configurations are settings that enable you to change both the behavior of individual Dapr applications, or the global behavior of the system services in the Dapr control plane.
|
||||
|
||||
Configurations are defined and deployed as a YAML file. An example would look like:
|
||||
Configurations are defined and deployed as a YAML file. An application configuration example is like this:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Configuration
|
||||
metadata:
|
||||
name: default
|
||||
name: daprConfig
|
||||
namespace: default
|
||||
spec:
|
||||
mtls:
|
||||
enabled: true
|
||||
allowedClockSkew: 15m
|
||||
workloadCertTTL: 24h
|
||||
tracing:
|
||||
samplingRate: "1"
|
||||
zipkin:
|
||||
endpointAddress: "https://..."
|
||||
endpointAddress: "http://localhost:9411/api/v2/spans"
|
||||
```
|
||||
|
||||
This configuration configures mtls for secure communication and tracing for telemetry recording. It can be loaded in self-hosted mode by editing the default configuration file in your `.dapr` directory, or by applying it to your Kubernetes cluster with kubectl/helm.
|
||||
This configuration configures tracing for telemetry recording. It can be loaded in self-hosted mode by editing the default configuration file called `config.yaml` file in your `.dapr` directory, or by applying it to your Kubernetes cluster with kubectl/helm.
|
||||
|
||||
Read [this page]({{<ref "configuration-overview.md">}}) for a list of all configuration options.
|
||||
|
|
|
|||
|
|
@ -85,7 +85,7 @@ To make using Dapr more natural for different languages, it also includes [langu
|
|||
- Python
|
||||
- Rust
|
||||
- .NET
|
||||
- PHP.
|
||||
- PHP
|
||||
|
||||
These SDKs expose the functionality of the Dapr building blocks through a typed language API, rather than calling the http/gRPC API. This enables you to write a combination of stateless and stateful functions and actors all in the language of their choice. And because these SDKs share the Dapr runtime, you get cross-language actor and functions support.
|
||||
|
||||
|
|
|
|||
|
|
@ -11,11 +11,11 @@ This page details all of the common terms you may come across in the Dapr docs.
|
|||
| Term | Definition | More information |
|
||||
|:-----|------------|------------------|
|
||||
| App/Application | A running service/binary, usually that you as the user create and run.
|
||||
| Building block | A piece of functionality that Dapr provides to users to help in the creation of microservices and applications. | [Dapr building blocks]({{< ref building-blocks-concept.md >}})
|
||||
| Component | A modular piece of functionality that make up, either by itself or with a collection of other components, a Dapr building block. | [Dapr components]({{< ref components-concept.md >}})
|
||||
| Configuration | A YAML file declaring all of the settings for Dapr sidecars and the Dapr control plane. It is here where you can configure mTLS, tracing, and middleware. | [Dapr configuration]({{< ref configuration-concept.md >}})
|
||||
| Building block | An API that Dapr provides to users to help in the creation of microservices and applications. | [Dapr building blocks]({{< ref building-blocks-concept.md >}})
|
||||
| Component | Modular types of functionality that are used either individually or with a collection of other components, by a Dapr building block. | [Dapr components]({{< ref components-concept.md >}})
|
||||
| Configuration | A YAML file declaring all of the settings for Dapr sidecars or the Dapr control plane. It is here where you can configure control plane mTLS settings, or the tracing, and middleware settings for an application instance. | [Dapr configuration]({{< ref configuration-concept.md >}})
|
||||
| Dapr | Distributed Application Runtime. | [Dapr overview]({{< ref overview.md >}})
|
||||
| Dapr control plane | A collection of services that are part of a Dapr installation on a hosting platform such as a Kubernetes cluster. Allow Dapr enabled applications to run on that platform and handles Dapr capabilities such as service discovery or sidecar injection. | [Self-hosted overview]({{< ref self-hosted-overview >}})<br />[Kubernetes overview]({{< ref kubernetes-overview >}})
|
||||
| Self-hosted | Your local Windows/macOS/Linux machine where you run your applications with Dapr. Dapr provides capabilities to run on your machine in "self-hosted" mode. | [Self-hosted mode]({{< ref self-hosted-overview.md >}})
|
||||
| Dapr control plane | A collection of services that are part of a Dapr installation on a hosting platform such as a Kubernetes cluster. Allow Dapr enabled applications to run on that platform and handles Dapr capabilities such as actor placement, Dapr sidecar injection or certificate issuance/rollover. | [Self-hosted overview]({{< ref self-hosted-overview >}})<br />[Kubernetes overview]({{< ref kubernetes-overview >}})
|
||||
| Self-hosted | Windows/macOS/Linux machine(s) where you can run your applications with Dapr. Dapr provides capabilities to run on machines in "self-hosted" mode. | [Self-hosted mode]({{< ref self-hosted-overview.md >}})
|
||||
| Service | A running application or binary. Can be used to refer to your application, or a Dapr application.
|
||||
| Sidecar | A program that runs along side your application as a separate binary or pod. | [Sidecar pattern](https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar)
|
||||
| Sidecar | A program that runs alongside your application as a separate process or container. | [Sidecar pattern](https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar)
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ You will now run the sidecar and call the API directly (simulating what an appli
|
|||
|
||||
## Step 1: Run the Dapr sidecar
|
||||
|
||||
One the most useful Dapr CLI commands is [`dapr run`]({{< ref dapr-run.md >}}). This command launches an application together with a sidecar. For the purpose of this tutorial you'll run the sidecar without an application.
|
||||
One of the most useful Dapr CLI commands is [`dapr run`]({{< ref dapr-run.md >}}). This command launches an application together with a sidecar. For the purpose of this tutorial you'll run the sidecar without an application.
|
||||
|
||||
Run the following command to launch a Dapr sidecar that will listen on port 3500 for a blank application named myapp:
|
||||
|
||||
|
|
@ -23,7 +23,20 @@ With this command, no custom component folder was defined, so Dapr uses the defa
|
|||
|
||||
## Step 2: Save state
|
||||
|
||||
In a separate terminal run:
|
||||
We will now update the state with an object. The new state will look like this:
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"key": "name",
|
||||
"value": "Bruce Wayne"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
Notice, the object contained in the state has a `key` assigned with the value `name`. You will use the key in the next step.
|
||||
|
||||
Run the command shown below to store the new state.
|
||||
|
||||
{{< tabs "HTTP API (Bash)" "HTTP API (PowerShell)">}}
|
||||
{{% codetab %}}
|
||||
|
|
@ -44,7 +57,7 @@ Invoke-RestMethod -Method Post -ContentType 'application/json' -Body '[{ "key":
|
|||
|
||||
## Step 3: Get state
|
||||
|
||||
Now get the state you just stored using a key with the state management API:
|
||||
Now get the object you just stored in the state by using the state management API with the key `name`:
|
||||
|
||||
{{< tabs "HTTP API (Bash)" "HTTP API (PowerShell)">}}
|
||||
|
||||
|
|
|
|||
|
|
@ -33,6 +33,7 @@ spec:
|
|||
value: "[your_service_principal_tenant_id]"
|
||||
- name: spnClientId
|
||||
value: "[your_service_principal_app_id]"
|
||||
value : "[pfx_certificate_contents]"
|
||||
- name: spnCertificateFile
|
||||
value : "[pfx_certificate_file_fully_qualified_local_path]"
|
||||
```
|
||||
|
|
@ -42,12 +43,25 @@ The above example uses secrets as plain strings. It is recommended to use a loca
|
|||
|
||||
## Spec metadata fields
|
||||
|
||||
| Field | Required | Details | Example |
|
||||
|--------------------|:--------:|-------------------------------------------------------------------------|--------------------------|
|
||||
| vaultName | Y | The name of the Azure Key Vault | `"mykeyvault"` |
|
||||
| spnTenantId | Y | Service Principal Tenant Id | `"spnTenantId"` |
|
||||
| spnClientId | Y | Service Principal App Id | `"spnAppId"` |
|
||||
| spnCertificateFile | Y | PFX certificate file path. <br></br> For Windows the `[pfx_certificate_file_fully_qualified_local_path]` value must use escaped backslashes, i.e. double backslashes. For example `"C:\\folder1\\folder2\\certfile.pfx"`. <br></br> For Linux you can use single slashes. For example `"/folder1/folder2/certfile.pfx"`. <br></br> See [configure the component](#configure-the-component) for more details | `"C:\\folder1\\folder2\\certfile.pfx"`, `"/folder1/folder2/certfile.pfx"` |
|
||||
### Self-Hosted
|
||||
|
||||
| Field | Required | Details | Example |
|
||||
|--------------------|:--------:|---------|---------|
|
||||
| vaultName | Y | The name of the Azure Key Vault | `"mykeyvault"`
|
||||
| spnTenantId | Y | Service Principal Tenant Id | `"spnTenantId"`
|
||||
| spnClientId | Y | Service Principal App Id | `"spnAppId"`
|
||||
| spnCertificateFile | Y | PFX certificate file path. <br></br> For Windows the `[pfx_certificate_file_fully_qualified_local_path]` value must use escaped backslashes, i.e. double backslashes. For example `"C:\\folder1\\folder2\\certfile.pfx"`. <br></br> For Linux you can use single slashes. For example `"/folder1/folder2/certfile.pfx"`. <br></br> See [configure the component](#configure-the-component) for more details | `"C:\\folder1\\folder2\\certfile.pfx"`, `"/folder1/folder2/certfile.pfx"`
|
||||
|
||||
|
||||
### Kubernetes
|
||||
|
||||
| Field | Required | Details | Example |
|
||||
|----------------|:--------:|---------|---------|
|
||||
| vaultName | Y | The name of the Azure Key Vault | `"mykeyvault"`
|
||||
| spnTenantId | Y | Service Principal Tenant Id | `"spnTenantId"`
|
||||
| spnClientId | Y | Service Principal App Id | `"spnAppId"`
|
||||
| spnCertificate | Y | PKCS 12 encoded bytes of the certificate. See [configure the component](#configure-the-component) for details on encoding this in a Kubernetes secret. | `secretKeyRef: ...` <br /> See [configure the component](#configure-the-component) for more information.
|
||||
|
||||
|
||||
## Setup Key Vault and service principal
|
||||
|
||||
|
|
@ -63,7 +77,7 @@ The above example uses secrets as plain strings. It is recommended to use a loca
|
|||
```bash
|
||||
# Log in Azure
|
||||
az login
|
||||
|
||||
|
||||
# Set your subscription to the default subscription
|
||||
az account set -s [your subscription id]
|
||||
```
|
||||
|
|
@ -80,7 +94,7 @@ The above example uses secrets as plain strings. It is recommended to use a loca
|
|||
|
||||
```bash
|
||||
az ad sp create-for-rbac --name [your_service_principal_name] --create-cert --cert [certificate_name] --keyvault [your_keyvault] --skip-assignment --years 1
|
||||
|
||||
|
||||
{
|
||||
"appId": "a4f90000-0000-0000-0000-00000011d000",
|
||||
"displayName": "[your_service_principal_name]",
|
||||
|
|
@ -96,7 +110,7 @@ The above example uses secrets as plain strings. It is recommended to use a loca
|
|||
|
||||
```bash
|
||||
az ad sp show --id [service_principal_app_id]
|
||||
|
||||
|
||||
{
|
||||
...
|
||||
"objectId": "[your_service_principal_object_id]",
|
||||
|
|
@ -165,11 +179,12 @@ In Kubernetes, you store the certificate for the service principal into the Kube
|
|||
1. Create a kubernetes secret using the following command:
|
||||
|
||||
```bash
|
||||
kubectl create secret generic [your_k8s_spn_secret_name] --from-file=[pfx_certificate_file_fully_qualified_local_path]
|
||||
kubectl create secret generic [your_k8s_spn_secret_name] --from-file=[your_k8s_spn_secret_key]=[pfx_certificate_file_fully_qualified_local_path]
|
||||
```
|
||||
|
||||
- `[pfx_certificate_file_fully_qualified_local_path]` is the path of PFX cert file you downloaded above
|
||||
- `[your_k8s_spn_secret_name]` is secret name in Kubernetes secret store
|
||||
- `[your_k8s_spn_secret_key]` is secret key in Kubernetes secret store
|
||||
|
||||
2. Create a `azurekeyvault.yaml` component file
|
||||
|
||||
|
|
@ -194,7 +209,7 @@ spec:
|
|||
- name: spnCertificate
|
||||
secretKeyRef:
|
||||
name: [your_k8s_spn_secret_name]
|
||||
key: [pfx_certificate_file_fully_qualified_local_path]
|
||||
key: [your_k8s_spn_secret_key]
|
||||
auth:
|
||||
secretStore: kubernetes
|
||||
```
|
||||
|
|
|
|||
Loading…
Reference in New Issue