You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -24,148 +24,10 @@ The Distributed Application Runtime (Dapr) is a portable, serverless, event-driv
24
24
25
25
To use Dapr pluggable components, define all the components, then add pluggable component containers to your [deployments](https://docs.dapr.io/operations/components/pluggable-components-registration/). The Dapr component listens to a Unix Domain Socket placed on the shared volume, and Dapr runtime connects with each socket and discovers all services from a given building block API that the component implements. Each deployment must have its own pluggable component defined. This guide shows you how to deploy an application using the Dapr SDK and IoT MQ pluggable components.
26
26
27
-
## Install Dapr runtime
27
+
## Prerequisites
28
28
29
-
To install the Dapr runtime, use the following Helm command. If you completed the provided Azure IoT Operations Preview [quickstart](../get-started/quickstart-deploy.md), you already installed the runtime.
To register MQ's pluggable Pub/sub and State Management components, create the component manifest yaml, and apply it to your cluster.
43
-
44
-
To create the yaml file, use the following component definitions:
45
-
46
-
> [!div class="mx-tdBreakAll"]
47
-
> | Component | Description |
48
-
> |-|-|
49
-
> |`metadata.name`| The component name is important and is how a Dapr application references the component. |
50
-
> |`spec.type`|[The type of the component](https://docs.dapr.io/operations/components/pluggable-components-registration/#define-the-component), which must be declared exactly as shown. It tells Dapr what kind of component (`pubsub` or `state`) it is and which Unix socket to use. |
51
-
> |`spec.metadata.url`| The URL tells the component where the local MQ endpoint is. Defaults to `8883` is MQ's default MQTT port with TLS enabled. |
52
-
> |`spec.metadata.satTokenPath`| The Service Account Token is used to authenticate the Dapr components with the MQTT broker |
53
-
> |`spec.metadata.tlsEnabled`| Define if TLS is used by the MQTT broker. Defaults to `true`|
54
-
> |`spec.metadata.caCertPath`| The certificate chain path for validating the broker, required if `tlsEnabled` is `true`|
55
-
> |`spec.metadata.logLevel`| The logging level of the component. 'Debug', 'Info', 'Warn' and 'Error' |
56
-
57
-
1. Save the following yaml, which contains the component definitions, to a file named `components.yaml`:
58
-
59
-
```yml
60
-
# Pub/sub component
61
-
apiVersion: dapr.io/v1alpha1
62
-
kind: Component
63
-
metadata:
64
-
name: aio-mq-pubsub
65
-
namespace: azure-iot-operations
66
-
spec:
67
-
type: pubsub.aio-mq-pubsub-pluggable # DO NOT CHANGE
1. Apply the component yaml to your cluster by running the following command:
104
-
105
-
```bash
106
-
kubectl apply -f components.yaml
107
-
```
108
-
109
-
Verify the following output:
110
-
111
-
```output
112
-
component.dapr.io/aio-mq-pubsub created
113
-
component.dapr.io/aio-mq-statestore created
114
-
```
115
-
116
-
## Set up authorization policy between the application and MQ
117
-
118
-
To configure authorization policies to Azure IoT MQ, first you create a [BrokerAuthorization resource](../manage-mqtt-connectivity/howto-configure-authorization.md).
119
-
120
-
> [!NOTE]
121
-
> If Broker Authorization is not enabled on this cluster, you can skip this section as the applications will have access to all MQTT topics.
122
-
123
-
1. Annotate the service account `mqtt-client` with an [authorization attribute](../manage-mqtt-connectivity/howto-configure-authentication.md#create-a-service-account):
@@ -194,11 +56,9 @@ After you finish writing the Dapr application, build the container:
194
56
195
57
## Deploy a Dapr application
196
58
197
-
To deploy the Dapr application to your cluster, you can use either a Kubernetes [Pod](https://kubernetes.io/docs/concepts/workloads/pods/) or [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)
198
-
199
-
The following Pod definition defines the different volumes required to deploy the application along with the required containers.
59
+
The following [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) definition defines the different volumes required to deploy the application along with the required containers.
200
60
201
-
To start, you create a yaml file that uses the following definitions:
61
+
To start, create a yaml file with the following definitions:
202
62
203
63
>| Component | Description |
204
64
>|-|-|
@@ -210,6 +70,14 @@ To start, you create a yaml file that uses the following definitions:
210
70
1. Save the following yaml to a file named `dapr-app.yaml`:
211
71
212
72
```yml
73
+
apiVersion: v1
74
+
kind: ServiceAccount
75
+
metadata:
76
+
name: dapr-client
77
+
namespace: azure-iot-operations
78
+
annotations:
79
+
aio-mq-broker-auth/group: dapr-workload
80
+
---
213
81
apiVersion: apps/v1
214
82
kind: Deployment
215
83
metadata:
@@ -231,6 +99,8 @@ To start, you create a yaml file that uses the following definitions:
231
99
dapr.io/app-port: "6001"
232
100
dapr.io/app-protocol: "grpc"
233
101
spec:
102
+
serviceAccountName: dapr-client
103
+
234
104
volumes:
235
105
- name: dapr-unix-domain-socket
236
106
emptyDir: {}
@@ -250,11 +120,11 @@ To start, you create a yaml file that uses the following definitions:
The Distributed Application Runtime (Dapr) is a portable, serverless, event-driven runtime that simplifies the process of building distributed application. Dapr enables developers to build stateful or stateless apps without worrying about how the building blocks function. Dapr provides several [building blocks](https://docs.dapr.io/developing-applications/building-blocks/): pub/sub, state management, service invocation, actors, and more.
18
+
19
+
Azure IoT MQ Preview supports two of these building blocks, powered by [Azure IoT MQ MQTT broker](../manage-mqtt-connectivity/overview-iot-mq.md):
20
+
21
+
- Pub/sub
22
+
- State Management
23
+
24
+
To use Dapr pluggable components, register the components, then add the pluggable component containers to your [deployments](https://docs.dapr.io/operations/components/pluggable-components-registration/). The Dapr component listens to a Unix Domain Socket placed on the shared volume, and Dapr runtime connects with each socket and discovers all services from a given building block API that the component implements.
25
+
26
+
This guide shows you how to deploy an application using the Dapr SDK and IoT MQ pluggable components.
27
+
28
+
## Install Dapr runtime
29
+
30
+
To install the Dapr runtime, use the following Helm command:
31
+
32
+
> [!NOTE]
33
+
> If you completed the provided Azure IoT Operations Preview [quickstart](../get-started/quickstart-deploy.md), you already installed the Dapr runtime and the following steps are not required.
To register MQ's pluggable Pub/sub and State Management components, create the component manifest yaml, and apply it to your cluster.
47
+
48
+
To create the yaml file, use the following component definitions:
49
+
50
+
> [!div class="mx-tdBreakAll"]
51
+
> | Component | Description |
52
+
> |-|-|
53
+
> |`metadata.name`| The component name is important and is how a Dapr application references the component. |
54
+
> |`spec.type`|[The type of the component](https://docs.dapr.io/operations/components/pluggable-components-registration/#define-the-component), which must be declared exactly as shown. It tells Dapr what kind of component (`pubsub` or `state`) it is and which Unix socket to use. |
55
+
> |`spec.metadata.url`| The URL tells the component where the local MQ endpoint is. Defaults to `8883` is MQ's default MQTT port with TLS enabled. |
56
+
> |`spec.metadata.satTokenPath`| The Service Account Token is used to authenticate the Dapr components with the MQTT broker |
57
+
> |`spec.metadata.tlsEnabled`| Define if TLS is used by the MQTT broker. Defaults to `true`|
58
+
> |`spec.metadata.caCertPath`| The certificate chain path for validating the broker, required if `tlsEnabled` is `true`|
59
+
> |`spec.metadata.logLevel`| The logging level of the component. 'Debug', 'Info', 'Warn' and 'Error' |
60
+
61
+
1. Save the following yaml, which contains the component definitions, to a file named `components.yaml`:
62
+
63
+
```yml
64
+
# Pub/sub component
65
+
apiVersion: dapr.io/v1alpha1
66
+
kind: Component
67
+
metadata:
68
+
name: aio-mq-pubsub
69
+
namespace: azure-iot-operations
70
+
spec:
71
+
type: pubsub.aio-mq-pubsub-pluggable # DO NOT CHANGE
1. Apply the component yaml to your cluster by running the following command:
108
+
109
+
```bash
110
+
kubectl apply -f components.yaml
111
+
```
112
+
113
+
Verify the following output:
114
+
115
+
```output
116
+
component.dapr.io/aio-mq-pubsub created
117
+
component.dapr.io/aio-mq-statestore created
118
+
```
119
+
120
+
## Create authorization policy for IoT MQ
121
+
122
+
To configure authorization policies to Azure IoT MQ, first you create a [BrokerAuthorization](../manage-mqtt-connectivity/howto-configure-authorization.md) resource.
123
+
124
+
> [!NOTE]
125
+
> If Broker Authorization is not enabled on this cluster, you can skip this section as the applications will have access to all MQTT topics, including those needed to access the IoT MQ State Store.
126
+
127
+
1. Save the following yaml, which contains a BrokerAuthorization definition, to a file named `aio-dapr-authz.yaml`:
128
+
129
+
```yml
130
+
apiVersion: mq.iotoperations.azure.com/v1beta1
131
+
kind: BrokerAuthorization
132
+
metadata:
133
+
name: my-dapr-authz-policies
134
+
namespace: azure-iot-operations
135
+
spec:
136
+
listenerRef:
137
+
- my-listener # change to match your listener name as needed
138
+
authorizationPolicies:
139
+
enableCache: false
140
+
rules:
141
+
- principals:
142
+
attributes:
143
+
- group: dapr-workload # match to the attribute annotated to the service account
0 commit comments