typo: small format docs

Signed-off-by: ductnn <trannhuduc531998@gmail.com>
This commit is contained in:
ductnn 2024-05-16 23:23:07 +07:00
parent e2ea14df60
commit 39ef2ed819
2 changed files with 6 additions and 7 deletions

View File

@ -75,15 +75,14 @@ spec:
type: bindings.azure.servicebusqueues
version: v1
metadata:
-name: connectionString
secretKeyRef:
- name: connectionString
secretKeyRef:
name: asbNsConnString
key: asbNsConnString
-name: queueName
value: servicec-inputq
- name: queueName
value: servicec-inputq
auth:
secretStore: <SECRET_STORE_NAME>
```
The above "Secret is a string" case yaml tells Dapr to extract a connection string named `asbNsConnstring` from the defined `secretStore` and assign the value to the `connectionString` field in the component since there is no key embedded in the "secret" from the `secretStore` because it is a plain string. This requires the secret `name` and secret `key` to be identical.
@ -95,7 +94,7 @@ The following example shows you how to create a Kubernetes secret to hold the co
1. First, create the Kubernetes secret:
```bash
kubectl create secret generic eventhubs-secret --from-literal=connectionString=*********
kubectl create secret generic eventhubs-secret --from-literal=connectionString=*********
```
2. Next, reference the secret in your binding:

View File

@ -52,7 +52,7 @@ Since you are running Dapr in the same host as the component, verify that this f
### Component discovery and multiplexing
A pluggable component accessible through a [Unix Domain Socket][UDS] (UDS) can host multiple distinct component APIs . During the components' initial discovery process, Dapr uses reflection to enumerate all the component APIs behind a UDS. The `my-component` pluggable component in the example above can contain both state store (`state`) and a pub/sub (`pubsub`) component APIs.
A pluggable component accessible through a [Unix Domain Socket][UDS] (UDS) can host multiple distinct component APIs. During the components' initial discovery process, Dapr uses reflection to enumerate all the component APIs behind a UDS. The `my-component` pluggable component in the example above can contain both state store (`state`) and a pub/sub (`pubsub`) component APIs.
Typically, a pluggable component implements a single component API for packaging and deployment. However, at the expense of increasing its dependencies and broadening its security attack surface, a pluggable component can have multiple component APIs implemented. This could be done to ease the deployment and monitoring burden. Best practice for isolation, fault tolerance, and security is a single component API implementation for each pluggable component.