mirror of https://github.com/dapr/docs.git
Merge branch 'master' into use-cases
This commit is contained in:
commit
f2c9a16a5b
|
@ -27,6 +27,7 @@ Every binding has its own unique set of properties. Click the name link to see t
|
|||
| [RabbitMQ](../../reference/specs/bindings/rabbitmq.md) | ✅ | ✅ | Experimental |
|
||||
| [Redis](../../reference/specs/bindings/redis.md) | | ✅ | Experimental |
|
||||
| [Twilio](../../reference/specs/bindings/twilio.md) | | ✅ | Experimental |
|
||||
| [SendGrid](../../reference/specs/bindings/sendgrid.md) | | ✅ | Experimental |
|
||||
|
||||
### Amazon Web Service (AWS)
|
||||
|
||||
|
|
|
@ -21,3 +21,7 @@ The following table shows all the supported pod Spec annotations supported by Da
|
|||
| `dapr.io/sidecar-memory-limit` | Maximum amount of Memory that the Dapr sidecar can use. See valid values [here](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/). By default this is not set
|
||||
| `dapr.io/sidecar-cpu-request` | Amount of CPU that the Dapr sidecar requests. See valid values [here](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/). By default this is not set
|
||||
| `dapr.io/sidecar-memory-request` | Amount of Memory that the Dapr sidecar requests .See valid values [here](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/). By default this is not set
|
||||
| `dapr.io/sidecar-readiness-probe-delay-seconds` | Number of seconds after the sidecar container has started before readiness probe is initiated. Read more [here](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes). Default is `3`
|
||||
| `dapr.io/sidecar-readiness-probe-timeout-seconds` | Number of seconds after which the sidecar readiness probe times out. Read more [here](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes). Default is `3`
|
||||
| `dapr.io/sidecar-readiness-probe-period-seconds` | How often (in seconds) to perform the sidecar readiness probe. Read more [here](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes). Default is `6`
|
||||
| `dapr.io/sidecar-readiness-probe-threshold` | When the sidecar readiness probe fails, Kubernetes will try N times before giving up. In this case, the Pod will be marked Unready. Read more about `failureThreshold` [here](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes). Default is `3`
|
||||
|
|
|
@ -33,7 +33,7 @@ docker run -e APPINSIGHTS_INSTRUMENTATIONKEY=<Your Instrumentation Key> -e APPIN
|
|||
|
||||
> Note: dapr-localforwarder is created by using [0.1-beta1 release](https://github.com/microsoft/ApplicationInsights-LocalForwarder/releases/tag/v0.1-beta1). If you want to create your own image, please use [this dockerfile](./localforwarder/Dockerfile).
|
||||
|
||||
1. Copy *tracing.yaml* to a *components* folder under the same folder where you run you application.
|
||||
1. Copy native.yaml and tracing.yaml to a *components/* sub-folder under the same folder where you run you application.
|
||||
|
||||
* native.yaml
|
||||
|
||||
|
@ -68,7 +68,7 @@ spec:
|
|||
3. When running in the local mode, you need to launch Dapr with the `--config` parameter:
|
||||
|
||||
```bash
|
||||
dapr run --app-id mynode --app-port 3000 --config ./tracing.yaml node app.js
|
||||
dapr run --app-id mynode --app-port 3000 --config ./components/tracing.yaml node app.js
|
||||
```
|
||||
|
||||
#### Kubernetes environment
|
||||
|
|
|
@ -0,0 +1,105 @@
|
|||
# Using PubSub across multiple namespaces
|
||||
|
||||
In some scenarios, applications can be spread across namespaces and share a queue or topic via PubSub. In this case, the PubSub component must be provisioned on each namespace.
|
||||
|
||||
In this example, we will use the [PubSub sample](https://github.com/dapr/samples/tree/master/4.pub-sub). Redis installation and the subscribers will be in `namespace-a` while the publisher UI will be on `namespace-b`. This solution should also work if Redis was installed on another namespace or if we used a managed cloud service like Azure ServiceBus.
|
||||
|
||||
The table below shows which resources are deployed to which namespaces:
|
||||
| Resource | namespace-a | namespace-b |
|
||||
|-|-|-|
|
||||
| Redis master | X ||
|
||||
| Redis slave | X ||
|
||||
| Dapr's PubSub component | X | X |
|
||||
| Node subscriber | X ||
|
||||
| Python subscriber | X ||
|
||||
| React UI publisher | | X|
|
||||
|
||||
## Pre-requisites
|
||||
|
||||
* [Dapr installed](https://github.com/dapr/docs/blob/master/getting-started/environment-setup.md.) on any namespace since Dapr works at the cluster level.
|
||||
* Checkout and cd into directory for [PubSub sample](https://github.com/dapr/samples/tree/master/4.pub-sub).
|
||||
|
||||
## Setup `namespace-a`
|
||||
|
||||
Create namespace and switch kubectl to use it.
|
||||
```
|
||||
kubectl create namespace namespace-a
|
||||
kubectl config set-context --current --namespace=namespace-a
|
||||
```
|
||||
|
||||
Install Redis (master and slave) on `namespace-a`, following [these instructions](https://github.com/dapr/docs/blob/master/howto/setup-pub-sub-message-broker/setup-redis.md).
|
||||
|
||||
Now, configure `deploy/redis.yaml`, paying attention to the hostname containing `namespace-a`.
|
||||
|
||||
```
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: messagebus
|
||||
spec:
|
||||
type: pubsub.redis
|
||||
metadata:
|
||||
- name: "redisHost"
|
||||
value: "redis-master.namespace-a.svc:6379"
|
||||
- name: "redisPassword"
|
||||
value: "YOUR_PASSWORD"
|
||||
```
|
||||
|
||||
Deploy resources to `namespace-a`:
|
||||
```
|
||||
kubectl apply -f deploy/redis.yaml
|
||||
kubectl apply -f deploy/node-subscriber.yaml
|
||||
kubectl apply -f deploy/python-subscriber.yaml
|
||||
```
|
||||
|
||||
## Setup `namespace-b`
|
||||
|
||||
Create namespace and switch kubectl to use it.
|
||||
```
|
||||
kubectl create namespace namespace-b
|
||||
kubectl config set-context --current --namespace=namespace-b
|
||||
```
|
||||
|
||||
Deploy resources to `namespace-b`, including the Redis component:
|
||||
```
|
||||
kubectl apply -f deploy/redis.yaml
|
||||
kubectl apply -f deploy/react-form.yaml
|
||||
```
|
||||
|
||||
Now, find the IP address for react-form, open it on your browser and publish messages to each topic (A, B and C).
|
||||
```
|
||||
kubectl get service -A
|
||||
```
|
||||
|
||||
## Confirm subscribers received the messages.
|
||||
|
||||
Switch back to `namespace-a`:
|
||||
```
|
||||
kubectl config set-context --current --namespace=namespace-a
|
||||
```
|
||||
|
||||
Find the POD names:
|
||||
```
|
||||
kubectl get pod # Copy POD names and use in the next commands.
|
||||
```
|
||||
|
||||
Display logs:
|
||||
```
|
||||
kubectl logs node-subscriber-XYZ node-subscriber
|
||||
kubectl logs python-subscriber-XYZ python-subscriber
|
||||
```
|
||||
|
||||
The messages published on the browser should show in the corresponding subscriber's logs. The Node.js subscriber receives messages of type "A" and "B", while the Python subscriber receives messages of type "A" and "C".
|
||||
|
||||
## Clean up
|
||||
|
||||
```
|
||||
kubectl delete -f deploy/redis.yaml --namespace namespace-a
|
||||
kubectl delete -f deploy/node-subscriber.yaml --namespace namespace-a
|
||||
kubectl delete -f deploy/python-subscriber.yaml --namespace namespace-a
|
||||
kubectl delete -f deploy/react-form.yaml --namespace namespace-b
|
||||
kubectl delete -f deploy/redis.yaml --namespace namespace-b
|
||||
kubectl config set-context --current --namespace=default
|
||||
kubectl delete namespace namespace-a
|
||||
kubectl delete namespace namespace-b
|
||||
```
|
|
@ -47,7 +47,7 @@ This document shows how to enable Azure Key Vault secret store using [Dapr Secre
|
|||
5. Assign the Managed Identity Operator role to the AKS Service Principal
|
||||
|
||||
```bash
|
||||
$aks = az aks show -g [your resource group] -n [your AKS name] | ConvertFrom-Json
|
||||
$aks = az aks show -g [your resource group] -n [your AKS name] -o json | ConvertFrom-Json
|
||||
|
||||
az role assignment create --role "Managed Identity Operator" --assignee $aks.servicePrincipalProfile.clientId --scope $identity.id
|
||||
```
|
||||
|
|
|
@ -35,7 +35,7 @@ Each of these building blocks is independent, meaning that you can use one, some
|
|||
| Building Block | Description |
|
||||
|----------------|-------------|
|
||||
| **[Service Invocation](../concepts/service-invocation)** | Resilient service-to-service invocation enables method calls, including retries, on remote services wherever they are located in the supported hosting environment.
|
||||
| **[State Management](../concepts/state)** | With state management for storing key/value pairs, long running, highly available, stateful services can be easily written alongside stateless services in your application. The state store is pluggable and can include Azure CosmosDB, AWS DynamoDB or Redis among others.
|
||||
| **[State Management](../concepts/state-management)** | With state management for storing key/value pairs, long running, highly available, stateful services can be easily written alongside stateless services in your application. The state store is pluggable and can include Azure CosmosDB, AWS DynamoDB or Redis among others.
|
||||
| **[Publish and Subscribe Messaging](../concepts/publish-subscribe-messaging)** | Publishing events and subscribing to topics | tween services enables event-driven architectures to simplify horizontal scalability and make them | silient to failure. Dapr provides at least once message delivery guarantee.
|
||||
| **[Resource Bindings](../concepts/bindings)** | Resource bindings with triggers builds further on event-driven | chitectures for scale and resiliency by receiving and sending events to and from any external | source such as databases, queues, file systems, etc.
|
||||
| **[Distributed Tracing](../concepts/observability/traces.md)** | Dapr supports distributed tracing to easily diagnose and | serve inter-service calls in production using the W3C Trace Context standard.
|
||||
|
|
|
@ -0,0 +1,41 @@
|
|||
# SendGrid Binding Spec
|
||||
|
||||
```
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: sendgrid
|
||||
spec:
|
||||
type: bindings.twilio.sendgrid
|
||||
metadata:
|
||||
- name: emailFrom
|
||||
value: "testapp@dapr.io" # optional
|
||||
- name: emailTo
|
||||
value: "dave@dapr.io" # optional
|
||||
- name: subject
|
||||
value: "Hello!" # optional
|
||||
- name: apiKey
|
||||
value: "YOUR_API_KEY" # required, this is your SendGrid key
|
||||
```
|
||||
|
||||
- `emailFrom` If set this specifies the 'from' email address of the email message. Optional field, see below.
|
||||
- `emailTo` If set this specifies the 'to' email address of the email message. Optional field, see below.
|
||||
- `emailCc` If set this specifies the 'cc' email address of the email message. Optional field, see below.
|
||||
- `emailBcc` If set this specifies the 'bcc' email address of the email message. Optional field, see below.
|
||||
- `subject` If set this specifies the subject of the email message. Optional field, see below.
|
||||
- `apiKey` is your SendGrid API key, this should be considered a secret value. Required.
|
||||
|
||||
You can specify any of the optional metadata properties on the output binding request too (e.g. `emailFrom`, `emailTo`, `subject`, etc.)
|
||||
|
||||
Example request payload
|
||||
```
|
||||
{
|
||||
"metadata": {
|
||||
"emailTo": "changeme@example.net",
|
||||
"subject": "An email from Dapr SendGrid binding"
|
||||
},
|
||||
"data": "<h1>Testing Dapr Bindings</h1>This is a test.<br>Bye!"
|
||||
}
|
||||
```
|
||||
|
||||
> **Note:** In production never place passwords or secrets within Dapr components. For information on securely storing and retrieving secrets refer to [Setup Secret Store](../../../howto/setup-secret-store)
|
Loading…
Reference in New Issue