mirror of https://github.com/dapr/docs.git
Merge branch 'v0.11' into mchmarny-concept-pubsub
This commit is contained in:
Aaron Crawfis
GitHub
commit
95286a79fe
|
|
@ -7,7 +7,9 @@ description: >
|
|||
Introduction to the Distributed Application Runtime
|
||||
---
|
||||
|
||||
Dapr is a portable, event-driven runtime that makes it easy for enterprise developers to build resilient, stateless and stateful microservice applications that run on the cloud and edge and embraces the diversity of languages and developer frameworks.
|
||||
Dapr is a portable, event-driven runtime that makes it easy for any developer to build resilient, stateless and stateful applications that run on the cloud and edge and embraces the diversity of languages and developer frameworks.
|
||||
|
||||
{{< youtube 9o9iDAgYBA8 >}}
|
||||
|
||||
## Any language, any framework, anywhere
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ Watch this [video](https://www.youtube.com/watch?v=OtbYCBt9C34&feature=youtu.be&
|
|||
|
||||
Now that the secret store is set up, you can call Dapr to get the secrets for a given key for a specific secret store.
|
||||
|
||||
For a full API reference, go [here](https://github.com/dapr/docs/blob/master/reference/api/secrets_api.md).
|
||||
For a full API reference, go [here]({{< ref secrets_api.md >}}).
|
||||
|
||||
Here are a few examples in different programming languages:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
type: docs
|
||||
title: "How-To: Reference secret stores in components"
|
||||
title: "How-To: Reference secrets in components"
|
||||
linkTitle: "How-To: Reference secrets"
|
||||
weight: 200
|
||||
description: "How to securly reference secrets from a component definition"
|
||||
|
|
@ -18,9 +18,93 @@ When running in Kubernetes, if the `auth.secretStore` is empty, the Kubernetes s
|
|||
|
||||
Go to [this]({{< ref "howto-secrets.md" >}}) link to see all the secret stores supported by Dapr, along with information on how to configure and use them.
|
||||
|
||||
## Non default namespaces
|
||||
## Referencing secrets
|
||||
|
||||
If your Dapr enabled apps are using components that fetch secrets from non-default namespaces, apply the following resources to the namespace:
|
||||
While you have the option to use plain text secrets, this is not recommended for production:
|
||||
|
||||
```yml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: statestore
|
||||
namespace: default
|
||||
spec:
|
||||
type: state.redis
|
||||
version: v1
|
||||
metadata:
|
||||
- name: redisHost
|
||||
value: localhost:6379
|
||||
- name: redisPassword
|
||||
value: MyPassword
|
||||
```
|
||||
|
||||
Instead create the secret in your secret store and reference it in the component definition:
|
||||
|
||||
```yml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: statestore
|
||||
namespace: default
|
||||
spec:
|
||||
type: state.redis
|
||||
version: v1
|
||||
metadata:
|
||||
- name: redisHost
|
||||
value: localhost:6379
|
||||
- name: redisPassword
|
||||
secretKeyRef:
|
||||
name: redis-secret
|
||||
key: redis-password
|
||||
auth:
|
||||
secretStore: <SECRET_STORE_NAME>
|
||||
```
|
||||
|
||||
`SECRET_STORE_NAME` is the name of the configured [secret store component]({{< ref supported-secret-stores >}}). When running in Kubernetes and using a Kubernetes secret store, the field `auth.SecretStore` defaults to `kubernetes` and can be left empty.
|
||||
|
||||
The above component definition tells Dapr to extract a secret named `redis-secret` from the defined secret store and assign the value of the `redis-password` key in the secret to the `redisPassword` field in the Component.
|
||||
|
||||
## Example
|
||||
|
||||
### Referencing a Kubernetes secret
|
||||
|
||||
The following example shows you how to create a Kubernetes secret to hold the connection string for an Event Hubs binding.
|
||||
|
||||
1. First, create the Kubernetes secret:
|
||||
```bash
|
||||
kubectl create secret generic eventhubs-secret --from-literal=connectionString=*********
|
||||
```
|
||||
|
||||
2. Next, reference the secret in your binding:
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: eventhubs
|
||||
namespace: default
|
||||
spec:
|
||||
type: bindings.azure.eventhubs
|
||||
version: v1
|
||||
metadata:
|
||||
- name: connectionString
|
||||
secretKeyRef:
|
||||
name: eventhubs-secret
|
||||
key: connectionString
|
||||
```
|
||||
|
||||
3. Finally, apply the component to the Kubernetes cluster:
|
||||
```bash
|
||||
kubectl apply -f ./eventhubs.yaml
|
||||
```
|
||||
## Kubernetes permissions
|
||||
|
||||
### Default namespace
|
||||
|
||||
When running in Kubernetes, Dapr, during installtion, defines default Role and RoleBinding for secrets access from Kubernetes secret store in the `default` namespace. For Dapr enabled apps that fetch secrets from `default` namespace, a secret can be defined and referenced in components as shown in the example above.
|
||||
|
||||
### Non-default namespaces
|
||||
|
||||
If your Dapr enabled apps are using components that fetch secrets from non-default namespaces, apply the following resources to that namespace:
|
||||
|
||||
```yaml
|
||||
---
|
||||
|
|
@ -49,82 +133,8 @@ roleRef:
|
|||
apiGroup: rbac.authorization.k8s.io
|
||||
```
|
||||
|
||||
## Examples
|
||||
These resources grant Dapr permissions to get secrets from the Kubernetes secret store for the namespace defined in the Role and RoleBinding.
|
||||
|
||||
Using plain text:
|
||||
|
||||
```yml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: statestore
|
||||
namespace: default
|
||||
spec:
|
||||
type: state.redis
|
||||
version: v1
|
||||
metadata:
|
||||
- name: redisHost
|
||||
value: localhost:6379
|
||||
- name: redisPassword
|
||||
value: MyPassword
|
||||
```
|
||||
|
||||
Using a Kubernetes secret:
|
||||
|
||||
```yml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: statestore
|
||||
namespace: default
|
||||
spec:
|
||||
type: state.redis
|
||||
version: v1
|
||||
metadata:
|
||||
- name: redisHost
|
||||
value: localhost:6379
|
||||
- name: redisPassword
|
||||
secretKeyRef:
|
||||
name: redis-secret
|
||||
key: redis-password
|
||||
auth:
|
||||
secretStore: kubernetes
|
||||
```
|
||||
|
||||
The above example tells Dapr to use the `kubernetes` secret store, extract a secret named `redis-secret` and assign the value of the `redis-password` key in the secret to the `redisPassword` field in the Component.
|
||||
|
||||
### Creating a secret and referencing it in a Component
|
||||
|
||||
The following example shows you how to create a Kubernetes secret to hold the connection string for an Event Hubs binding.
|
||||
|
||||
First, create the Kubernetes secret:
|
||||
|
||||
```bash
|
||||
kubectl create secret generic eventhubs-secret --from-literal=connectionString=*********
|
||||
```
|
||||
|
||||
Next, reference the secret in your binding:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: eventhubs
|
||||
namespace: default
|
||||
spec:
|
||||
type: bindings.azure.eventhubs
|
||||
version: v1
|
||||
metadata:
|
||||
- name: connectionString
|
||||
secretKeyRef:
|
||||
name: eventhubs-secret
|
||||
key: connectionString
|
||||
```
|
||||
|
||||
Finally, apply the component to the Kubernetes cluster:
|
||||
|
||||
```bash
|
||||
kubectl apply -f ./eventhubs.yaml
|
||||
```
|
||||
|
||||
All done!
|
||||
{{% alert title="Note" color="warning" %}}
|
||||
In production scenario to limit Dapr's access to certain secret resources alone, you can use the `resourceNames` field. See this [link](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#referring-to-resources) for further explanation.
|
||||
{{% /alert %}}
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ The above example uses secrets as plain strings. It is recommended to use a secr
|
|||
|
||||
### Create Blob
|
||||
|
||||
To perform a get blob operation, invoke the Azure Blob Storage binding with a `POST` method and the following JSON body:
|
||||
To perform a create blob operation, invoke the Azure Blob Storage binding with a `POST` method and the following JSON body:
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ type: docs
|
|||
|
||||
For self hosted mode, on running `dapr init`:
|
||||
|
||||
1. The following YAML file is created by default in `$HOME/dapr/config.yaml` (on Linux/Mac) or `%USERPROFILE%\dapr\config.yaml` (on Windows) and it is referenced by default on `dapr run` calls unless otherwise overridden `:
|
||||
1. The following YAML file is created by default in `$HOME/.dapr/config.yaml` (on Linux/Mac) or `%USERPROFILE%\.dapr\config.yaml` (on Windows) and it is referenced by default on `dapr run` calls unless otherwise overridden `:
|
||||
|
||||
* config.yaml
|
||||
|
||||
|
|
@ -24,8 +24,8 @@ metadata:
|
|||
spec:
|
||||
tracing:
|
||||
samplingRate: "1"
|
||||
zipkin:
|
||||
endpointAddress: "http://localhost:9411/api/v2/spans"
|
||||
zipkin:
|
||||
endpointAddress: "http://localhost:9411/api/v2/spans"
|
||||
```
|
||||
|
||||
2. 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.
|
||||
|
|
@ -36,7 +36,7 @@ Launch Zipkin using Docker:
|
|||
docker run -d -p 9411:9411 openzipkin/zipkin
|
||||
```
|
||||
|
||||
3. 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:
|
||||
3. 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 node app.js
|
||||
|
|
|
|||
Loading…
Reference in New Issue