Skip to content

Commit

Permalink
Merge branch 'v1.12' into endgame_v1.12_prep
Browse files Browse the repository at this point in the history
  • Loading branch information
hhunter-ms authored Oct 11, 2023
2 parents 9e09c13 + 5010459 commit 96c0a92
Show file tree
Hide file tree
Showing 55 changed files with 4,655 additions and 827 deletions.
2 changes: 1 addition & 1 deletion daprdocs/content/en/concepts/building-blocks-concept.md
Original file line number Diff line number Diff line change
Expand Up @@ -28,5 +28,5 @@ Dapr provides the following building blocks:
| [**Secrets**]({{< ref "secrets-overview.md" >}}) | `/v1.0/secrets` | Dapr provides a secrets building block API and integrates with secret stores such as public cloud stores, local stores and Kubernetes to store the secrets. Services can call the secrets API to retrieve secrets, for example to get a connection string to a database.
| [**Configuration**]({{< ref "configuration-api-overview.md" >}}) | `/v1.0/configuration` | The Configuration API enables you to retrieve and subscribe to application configuration items for supported configuration stores. This enables an application to retrieve specific configuration information, for example, at start up or when configuration changes are made in the store.
| [**Distributed lock**]({{< ref "distributed-lock-api-overview.md" >}}) | `/v1.0-alpha1/lock` | The distributed lock API enables you to take a lock on a resource so that multiple instances of an application can access the resource without conflicts and provide consistency guarantees.
| [**Workflows**]({{< ref "workflow-overview.md" >}}) | `/v1.0-alpha1/workflow` | The Workflow API enables you to define long running, persistent processes or data flows that span multiple microservices using Dapr workflows or workflow components. The Workflow API can be combined with other Dapr API building blocks. For example, a workflow can call another service with service invocation or retrieve secrets, providing flexibility and portability.
| [**Workflows**]({{< ref "workflow-overview.md" >}}) | `/v1.0-beta1/workflow` | The Workflow API enables you to define long running, persistent processes or data flows that span multiple microservices using Dapr workflows or workflow components. The Workflow API can be combined with other Dapr API building blocks. For example, a workflow can call another service with service invocation or retrieve secrets, providing flexibility and portability.
| [**Cryptography**]({{< ref "cryptography-overview.md" >}}) | `/v1.0-alpha1/crypto` | The Cryptography API enables you to perform cryptographic operations, such as encrypting and decrypting messages, without exposing keys to your application.
73 changes: 73 additions & 0 deletions daprdocs/content/en/concepts/dapr-services/placement.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,3 +14,76 @@ The placement service Docker container is started automatically as part of [`dap
## Kubernetes mode

The placement service is deployed as part of `dapr init -k`, or via the Dapr Helm charts. For more information on running Dapr on Kubernetes, visit the [Kubernetes hosting page]({{< ref kubernetes >}}).

## Placement tables

There is an [HTTP API `/placement/state` for placement service]({{< ref placement_api.md >}}) that exposes placement table information. The API is exposed on the sidecar on the same port as the healthz. This is an unauthenticated endpoint, and is disabled by default. You need to set `DAPR_PLACEMENT_METADATA_ENABLED` environment or `metadata-enabled` command line args to true to enable it. If you are using helm you just need to set `dapr_placement.metadataEnabled` to true.

### Usecase:
The placement table API can be used for retrieving the current placement table, which contains all the actors registered. This can be helpful for debugging and allows tools to extract and present information about actors.

### HTTP Request

```
GET http://localhost:<healthzPort>/placement/state
```

### HTTP Response Codes

Code | Description
---- | -----------
200 | Placement tables information returned
500 | Placement could not return the placement tables information

### HTTP Response Body

**Placement tables API Response Object**

Name | Type | Description
---- | ---- | -----------
tableVersion | int | The placement table version
hostList | [Actor Host Info](#actorhostinfo)[] | A json array of registered actors host info.

<a id="actorhostinfo"></a>**Actor Host Info**

Name | Type | Description
---- | ---- | -----------
name | string | The host:port address of the actor.
appId | string | app id.
actorTypes | json string array | List of actor types it hosts.
updatedAt | timestamp | Timestamp of the actor registered/updated.

### Examples

```shell
curl localhost:8080/placement/state
```

```json
{
"hostList": [{
"name": "198.18.0.1:49347",
"appId": "actor1",
"actorTypes": ["testActorType1", "testActorType3"],
"updatedAt": 1690274322325260000
},
{
"name": "198.18.0.2:49347",
"appId": "actor2",
"actorTypes": ["testActorType2"],
"updatedAt": 1690274322325260000
},
{
"name": "198.18.0.3:49347",
"appId": "actor2",
"actorTypes": ["testActorType2"],
"updatedAt": 1690274322325260000
}
],
"tableVersion": 1
}
```

## Related links

[Learn more about the Placement API.]({{< ref placement_api.md >}})
26 changes: 13 additions & 13 deletions daprdocs/content/en/contributing/daprbot.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,24 +6,24 @@ weight: 15
description: "List of Dapr bot capabilities."
---

Dapr bot is a GitHub script that helps with common tasks in the Dapr organization. It is set up individually for each repository ([example](https://github.com/dapr/dapr/blob/master/.github/workflows/dapr-bot.yml)) and can be configured to run on specific events. This reference covers the Dapr bot capabilities from the `dapr` and `components-contrib` repositories only.
Dapr bot is triggered by a list of commands that helps with common tasks in the Dapr organization. It is set up individually for each repository ([example](https://github.com/dapr/dapr/blob/master/.github/workflows/dapr-bot.yml)) and can be configured to run on specific events. Below is a list of commands and the list of repositories they are implemented on.

## Command reference

| Command | Target | Description | Who can use | Repository |
|---------|--------|-------------|-------------|------------|
| `/assign` | Issue | Assigns an issue to a user or group of users | Anyone | `dapr`, `components-contrib` |
| `/ok-to-test` | Pull request | `dapr`: trigger end to end tests <br/> `components-contrib`: trigger conformance and certification tests | Users listed in the [bot](https://github.com/dapr/dapr/blob/master/.github/scripts/dapr_bot.js) | `dapr`, `components-contrib` |
| `/ok-to-perf` | Pull request | Trigger performance tests. | Users listed in the [bot](https://github.com/dapr/dapr/blob/master/.github/scripts/dapr_bot.js) | `dapr` |
| `/make-me-laugh` | Issue or pull request | Posts a random joke | Users listed in the [bot](https://github.com/dapr/dapr/blob/master/.github/scripts/dapr_bot.js) | `dapr`, `components-contrib` |
| Command | Target | Description | Who can use | Repository |
| ---------------- | --------------------- | -------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | -------------------------------------- |
| `/assign` | Issue | Assigns an issue to a user or group of users | Anyone | `dapr`, `components-contrib`, `go-sdk` |
| `/ok-to-test` | Pull request | `dapr`: trigger end to end tests <br/> `components-contrib`: trigger conformance and certification tests | Users listed in the [bot](https://github.com/dapr/dapr/blob/master/.github/scripts/dapr_bot.js) | `dapr`, `components-contrib` |
| `/ok-to-perf` | Pull request | Trigger performance tests. | Users listed in the [bot](https://github.com/dapr/dapr/blob/master/.github/scripts/dapr_bot.js) | `dapr` |
| `/make-me-laugh` | Issue or pull request | Posts a random joke | Users listed in the [bot](https://github.com/dapr/dapr/blob/master/.github/scripts/dapr_bot.js) | `dapr`, `components-contrib` |

## Label reference

You can query issues created by the Dapr bot by using the `created-by/dapr-bot` label ([query](https://github.com/search?q=org%3Adapr%20is%3Aissue%20label%3Acreated-by%2Fdapr-bot%20&type=issues)).

| Label | Target | What does it do? | Repository |
|-------|--------|------------------|------------|
| `docs-needed` | Issue | Creates a new issue in `dapr/docs` to track doc work | `dapr` |
| `sdk-needed` | Issue | Creates new issues across the SDK repos to track SDK work | `dapr` |
| `documentation required` | Issue or pull request | Creates a new issue in `dapr/docs` to track doc work | `components-contrib` |
| `new component` | Issue or pull request | Creates a new issue in `dapr/dapr` to register the new component | `components-contrib` |
| Label | Target | What does it do? | Repository |
| ------------------------ | --------------------- | ---------------------------------------------------------------- | -------------------- |
| `docs-needed` | Issue | Creates a new issue in `dapr/docs` to track doc work | `dapr` |
| `sdk-needed` | Issue | Creates new issues across the SDK repos to track SDK work | `dapr` |
| `documentation required` | Issue or pull request | Creates a new issue in `dapr/docs` to track doc work | `components-contrib` |
| `new component` | Issue or pull request | Creates a new issue in `dapr/dapr` to register the new component | `components-contrib` |
Original file line number Diff line number Diff line change
Expand Up @@ -219,7 +219,7 @@ namespace CheckoutService.controller
Navigate to the directory containing the above code, then run the following command to launch both a Dapr sidecar and the subscriber application:

```bash
dapr run --app-id checkout --app-port 6002 --dapr-http-port 3602 --dapr-grpc-port 60002 --app-ssl dotnet run
dapr run --app-id checkout --app-port 6002 --dapr-http-port 3602 --dapr-grpc-port 60002 --app-protocol https dotnet run
```

{{% /codetab %}}
Expand Down Expand Up @@ -465,7 +465,7 @@ namespace EventService
Navigate to the directory containing the above code, then run the following command to launch both a Dapr sidecar and the publisher application:

```bash
dapr run --app-id orderprocessing --app-port 6001 --dapr-http-port 3601 --dapr-grpc-port 60001 --app-ssl dotnet run
dapr run --app-id orderprocessing --app-port 6001 --dapr-http-port 3601 --dapr-grpc-port 60001 --app-protocol https dotnet run
```

{{% /codetab %}}
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -302,10 +302,10 @@ In the example above, `bulkSubscribe` is _optional_. If you use `bulkSubscribe`,
- `enabled` is mandatory and enables or disables bulk subscriptions on this topic
- You can optionally configure the max number of messages (`maxMessagesCount`) delivered in a bulk message.
Default value of `maxMessagesCount` for components not supporting bulk subscribe is 100 i.e. for default bulk events between App and Dapr. Please refer [How components handle publishing and subscribing to bulk messages]({{< ref pubsub-bulk >}}).
If a component supports bulk subscribe, then default value for this parameter can be found in that component doc. Please refer [Supported components]({{< ref pubsub-bulk >}}).
If a component supports bulk subscribe, then default value for this parameter can be found in that component doc.
- You can optionally provide the max duration to wait (`maxAwaitDurationMs`) before a bulk message is sent to the app.
Default value of `maxAwaitDurationMs` for components not supporting bulk subscribe is 1000 i.e. for default bulk events between App and Dapr. Please refer [How components handle publishing and subscribing to bulk messages]({{< ref pubsub-bulk >}}).
If a component supports bulk subscribe, then default value for this parameter can be found in that component doc. Please refer [Supported components]({{< ref pubsub-bulk >}}).
If a component supports bulk subscribe, then default value for this parameter can be found in that component doc.

The application receives an `EntryId` associated with each entry (individual message) in the bulk message. This `EntryId` must be used by the app to communicate the status of that particular entry. If the app fails to notify on an `EntryId` status, it's considered a `RETRY`.

Expand Down Expand Up @@ -473,9 +473,41 @@ public class BulkMessageController : ControllerBase
{{< /tabs >}}
## How components handle publishing and subscribing to bulk messages

Some pub/sub brokers support sending and receiving multiple messages in a single request. When a component supports bulk publish or subscribe operations, Dapr runtime uses them to further optimize the communication between the Dapr sidecar and the underlying pub/sub broker.

For components that do not have bulk publish or subscribe support, Dapr runtime uses the regular publish and subscribe APIs to send and receive messages one by one. This is still more efficient than directly using the regular publish or subscribe APIs, because applications can still send/receive multiple messages in a single request to/from Dapr.
For event publish/subscribe, two kinds of network transfers are involved.
1. From/To *App* To/From *Dapr*.
1. From/To *Dapr* To/From *Pubsub Broker*.

These are the opportunities where optimization is possible. When optimized, a Bulk requests are, which reduce number of overall calls and thus increase throughput and provide better latency.

On enabling Bulk Publish and/or Bulk Subscribe, the communication between the App and Dapr sidecar (Point 1 above) is optimized for **all components**.

Optimization from Dapr sidecar to the pub/sub broker would depend on a number of factors, for example:
- If the broker inherently supports Bulk pub/sub
- If the Dapr component is updated to support the use of bulk APIs provided by the broker.

Currently, the following components are updated to support this level of optimization:
<table width="100%">
<tr>
<th>Component</th>
<th>Bulk Publish</th>
<th>Bulk Subscribe</th>
</tr>
<tr>
<td>Kafka</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Azure Servicebus</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Azure Eventhubs</td>
<td>Yes</td>
<td>Yes</td>
</tr>
</table>

## Demos

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -96,6 +96,10 @@ For more information on message routing, read [Dapr pub/sub API reference]({{< r

Sometimes, messages can't be processed because of a variety of possible issues, such as erroneous conditions within the producer or consumer application or an unexpected state change that causes an issue with your application code. Dapr allows developers to set dead letter topics to deal with messages that cannot be delivered to an application. This feature is available on all pub/sub components and prevents consumer applications from endlessly retrying a failed message. For more information, read about [dead letter topics]({{< ref "pubsub-deadletter.md">}})

### Enabling the outbox pattern

Dapr enables developers to use the outbox pattern for achieving a single transaction across a transactional state store and any message broker. For more information, read [How to enable transactional outbox messaging]({{< ref howto-outbox.md >}})

### Namespace consumer groups

Dapr solves multi-tenancy at-scale with [namespaces for consumer groups]({{< ref howto-namespace >}}). Simply include the `"{namespace}"` value in your component metadata for consumer groups to allow multiple namespaces with applications of the same `app-id` to publish and subscribe to the same message broker.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -79,6 +79,52 @@ localhost:3500/v1.0/invoke/<appID>/method/<my-method>
curl http://localhost:3602/v1.0/invoke/orderprocessor/method/checkout
```

## TLS authentication

Using the [HTTPEndpoint resource]({{< ref httpendpoints-schema.md >}}) allows you to use any combination of a root certificate, client certificate and private key according to the authentication requirements of the remote endpoint.

### Example using root certificate

```yaml
apiVersion: dapr.io/v1alpha1
kind: HTTPEndpoint
metadata:
name: "external-http-endpoint-tls"
spec:
baseUrl: https://service-invocation-external:443
headers:
- name: "Accept-Language"
value: "en-US"
clientTLS:
rootCA:
secretKeyRef:
name: dapr-tls-client
key: ca.crt
```
### Example using client certificate and private key
```yaml
apiVersion: dapr.io/v1alpha1
kind: HTTPEndpoint
metadata:
name: "external-http-endpoint-tls"
spec:
baseUrl: https://service-invocation-external:443
headers:
- name: "Accept-Language"
value: "en-US"
clientTLS:
certificate:
secretKeyRef:
name: dapr-tls-client
key: tls.crt
privateKey:
secretKeyRef:
name: dapr-tls-key
key: tls.key
```
## Related Links
- [HTTPEndpoint reference]({{< ref httpendpoints-schema.md >}})
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -94,6 +94,21 @@ The diagram below shows an example of how this works. If you have 1 instance of

Dapr can run on a variety of [hosting platforms]({{< ref hosting >}}). To enable service discovery and service invocation, Dapr uses pluggable [name resolution components]({{< ref supported-name-resolution >}}). For example, the Kubernetes name resolution component uses the Kubernetes DNS service to resolve the location of other applications running in the cluster. Self-hosted machines can use the mDNS name resolution component. The Consul name resolution component can be used in any hosting environment, including Kubernetes or self-hosted.

### Streaming for HTTP service invocation

You can handle data as a stream in HTTP service invocation. This can offer improvements in performance and memory utilization when using Dapr to invoke another service using HTTP with large request or response bodies.

The diagram below demonstrates the six steps of data flow.

<img src="/images/service-invocation-simple.webp" width=600 alt="Diagram showing the steps of service invocation described in the table below" />

1. Request: "App A" to "Dapr sidecar A"
1. Request: "Dapr sidecar A" to "Dapr sidecar B"
1. Request: "Dapr sidecar B" to "App B"
1. Response: "App B" to "Dapr sidecar B"
1. Response: "Dapr sidecar B" to "Dapr sidecar A"
1. Response: "Dapr sidecar A" to "App A"

## Example Architecture

Following the above call sequence, suppose you have the applications as described in the [Hello World tutorial](https://github.com/dapr/quickstarts/blob/master/tutorials/hello-world/README.md), where a python app invokes a node.js app. In such a scenario, the python app would be "Service A" , and a Node.js app would be "Service B".
Expand Down
Loading

0 comments on commit 96c0a92

Please sign in to comment.