mirror of https://github.com/dapr/docs.git
Update docs with new heirarchy
This commit is contained in:
Aaron Crawfis
parent
e26af19d76
commit
01d6e2b165
|
|
@ -5,22 +5,22 @@ weight: 30
|
|||
description: "HTTP or gRPC APIs that can be called from user code and uses one or more Dapr components."
|
||||
---
|
||||
|
||||
A [building block](./architecture/building_blocks.md) is as an HTTP or gRPC API that can be called from user code and uses one or more Dapr components. Dapr consists of a set of building blocks, with extensibility to add new building blocks.
|
||||
A [building block](/docs/concepts/architecture/building-blocks) is as an HTTP or gRPC API that can be called from user code and uses one or more Dapr components. Dapr consists of a set of building blocks, with extensibility to add new building blocks.
|
||||
|
||||
The diagram below shows how building blocks expose a public API that is called from your code, using components to implement the building blocks' capability.
|
||||
|
||||
<img src="../images/concepts-building-blocks.png" width=250>
|
||||
<img src="/images/concepts-building-blocks.png" width=250>
|
||||
|
||||
The following are the building blocks provided by Dapr:
|
||||
|
||||
<img src="../images/building_blocks.png" width=800>
|
||||
<img src="/images/building_blocks.png" width=1000>
|
||||
|
||||
| Building Block | Endpoint | Description |
|
||||
|----------------|----------|-------------|
|
||||
| [**Service-to-Service Invocation**](./service-invocation/README.md) | `/v1.0/invoke` | Service invocation enables applications to communicate with each other through well-known endpoints in the form of http or gRPC messages. Dapr provides an endpoint that acts as a combination of a reverse proxy with built-in service discovery, while leveraging built-in distributed tracing and error handling.
|
||||
| [**State Management**](./state-management/README.md) | `/v1.0/state` | Application state is anything an application wants to preserve beyond a single session. Dapr provides a key/value-based state API with pluggable state stores for persistence.
|
||||
| [**Publish and Subscribe**](./publish-subscribe-messaging/README.md) | `/v1.0/publish` `/v1.0/subscribe`| Pub/Sub is a loosely coupled messaging pattern where senders (or publishers) publishes messages to a topic, to which subscribers subscribe. Dapr supports the pub/sub pattern between applications.
|
||||
| [**Resource Bindings**](./bindings/README.md)| `/v1.0/bindings` | A binding provides a bi-directional connection to an external cloud/on-premise service or system. Dapr allows you to invoke the external service through the Dapr binding API, and it allows your application to be triggered by events sent by the connected service.
|
||||
| [**Actors**](./actors/README.md) | `/v1.0/actors` | An actor is an isolated, independent unit of compute and state with single-threaded execution. Dapr provides an actor implementation based on the Virtual Actor pattern which provides a single-threaded programming model and where actors are garbage collected when not in use. See * [Actor Overview](./actors#understanding-actors)
|
||||
| [**Observability**](./observability/README.md) | `N/A` | Dapr system components and runtime emit metrics, logs, and traces to debug, operate and monitor Dapr system services, components and user applications.
|
||||
| [**Secrets**](./secrets/README.md) | `/v1.0/secrets` | Dapr offers a secrets building block API and integrates with secret stores such as Azure Key Vault and Kubernetes to store the secrets. Service code can call the secrets API to retrieve secrets out of the Dapr supported secret stores.
|
||||
| [**Service-to-Service Invocation**](./service-invocation) | `/v1.0/invoke` | Service invocation enables applications to communicate with each other through well-known endpoints in the form of http or gRPC messages. Dapr provides an endpoint that acts as a combination of a reverse proxy with built-in service discovery, while leveraging built-in distributed tracing and error handling.
|
||||
| [**State Management**](./state-management) | `/v1.0/state` | Application state is anything an application wants to preserve beyond a single session. Dapr provides a key/value-based state API with pluggable state stores for persistence.
|
||||
| [**Publish and Subscribe**](./publish-subscribe-messaging) | `/v1.0/publish` `/v1.0/subscribe`| Pub/Sub is a loosely coupled messaging pattern where senders (or publishers) publishes messages to a topic, to which subscribers subscribe. Dapr supports the pub/sub pattern between applications.
|
||||
| [**Resource Bindings**](./bindings)| `/v1.0/bindings` | A binding provides a bi-directional connection to an external cloud/on-premise service or system. Dapr allows you to invoke the external service through the Dapr binding API, and it allows your application to be triggered by events sent by the connected service.
|
||||
| [**Actors**](./actors) | `/v1.0/actors` | An actor is an isolated, independent unit of compute and state with single-threaded execution. Dapr provides an actor implementation based on the Virtual Actor pattern which provides a single-threaded programming model and where actors are garbage collected when not in use. See * [Actor Overview](./actors#understanding-actors)
|
||||
| [**Observability**](./observability) | `N/A` | Dapr system components and runtime emit metrics, logs, and traces to debug, operate and monitor Dapr system services, components and user applications.
|
||||
| [**Secrets**](./secrets) | `/v1.0/secrets` | Dapr offers a secrets building block API and integrates with secret stores such as Azure Key Vault and Kubernetes to store the secrets. Service code can call the secrets API to retrieve secrets out of the Dapr supported secret stores.
|
||||
|
|
@ -10,7 +10,7 @@ Using the service invocation API, your microservice can find and reliably commun
|
|||
|
||||
Below is a high level overview of how Dapr's service invocation system works.
|
||||
|
||||
|
||||
|
||||
|
||||
1. Service A makes a http/gRPC call meant for Service B. The call goes to the local Dapr sidecar.
|
||||
2. Dapr discovers Service B's location and forwards the message to Service B's Dapr sidecar
|
||||
|
|
|
|||
|
|
@ -2,5 +2,5 @@
|
|||
title: "Dapr Building Blocks"
|
||||
linkTitle: "Building Blocks"
|
||||
weight: 200
|
||||
description: ""
|
||||
description: "HTTP or gRPC APIs that can be called from user code"
|
||||
---
|
||||
|
|
@ -2,10 +2,9 @@
|
|||
title: "Middleware Pipeline"
|
||||
linkTitle: "Middleware"
|
||||
weight: 300
|
||||
description: "Custom processing pipelines of chained middleware components"
|
||||
---
|
||||
|
||||
# Middleware pipeline
|
||||
|
||||
Dapr allows custom processing pipelines to be defined by chaining a series of middleware components. A request goes through all defined middleware components before it's routed to user code, and then goes through the defined middleware, in reverse order, before it's returned to the client, as shown in the following diagram.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -6,21 +6,8 @@ description: >
|
|||
Introduction to the Distributed Application Runtime
|
||||
---
|
||||
|
||||
# Dapr overview
|
||||
|
||||
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.
|
||||
|
||||
## Contents:
|
||||
|
||||
- [Any language, any framework, anywhere](#any-language-any-framework-anywhere)
|
||||
- [Microservice building blocks for cloud and edge](#microservice-building-blocks-for-cloud-and-edge)
|
||||
- [Sidecar architecture](#sidecar-architecture)
|
||||
- [Developer language SDKs and frameworks](#developer-language-sdks-and-frameworks)
|
||||
- [Designed for operations](#designed-for-operations)
|
||||
- [Run anywhere](#Run-anywhere)
|
||||
- [Running Dapr on a local developer machine in self hosted mode](#running-dapr-on-a-local-developer-machine-in-self-hosted-mode)
|
||||
- [Running Dapr in Kubernetes mode](#running-dapr-in-kubernetes-mode)
|
||||
|
||||
## Any language, any framework, anywhere
|
||||
|
||||
<img src="/images/overview.png" width=1000>
|
||||
|
|
@ -43,13 +30,13 @@ Each of these building blocks is independent, meaning that you can use one, some
|
|||
|
||||
| Building Block | Description |
|
||||
|----------------|-------------|
|
||||
| **[Service Invocation]({{< ref "/docs/building-blocks/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](/building-blocks/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, Azure SQL Server, PostgreSQL, AWS DynamoDB or Redis among others.
|
||||
| **[Publish and Subscribe Messaging](/building-blocks/pubsub)** | 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](/building-blocks/bindings)** | Resource bindings with triggers builds further on event-driven architectures for scale and resiliency by receiving and sending events to and from any external source such as databases, queues, file systems, etc.
|
||||
| **[Actors](/building-blocks/actors)** | A pattern for stateful and stateless objects that make concurrency simple with method and state encapsulation. Dapr provides many capabilities in its actor runtime including concurrency, state, life-cycle management for actor activation/deactivation and timers and reminders to wake-up actors.
|
||||
| **[Observability](/building-blocks/observability)** | Dapr emit metrics, logs, and traces to debug and monitor both Dapr and user applications. Dapr supports distributed tracing to easily diagnose and serve inter-service calls in production using the W3C Trace Context standard and Open Telemetry to send to different monitoring tools.
|
||||
| **[Secrets](/building-blocks/secrets)** | Dapr provides secrets management and integrates with public cloud and local secret stores to retrieve the secrets for use in application code.
|
||||
| **[Service Invocation](/docs/building-blocks/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](/docs/building-blocks/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, Azure SQL Server, PostgreSQL, AWS DynamoDB or Redis among others.
|
||||
| **[Publish and Subscribe Messaging](/docs/building-blocks/pubsub)** | 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](/docs/building-blocks/bindings)** | Resource bindings with triggers builds further on event-driven architectures for scale and resiliency by receiving and sending events to and from any external source such as databases, queues, file systems, etc.
|
||||
| **[Actors](/docs/building-blocks/actors)** | A pattern for stateful and stateless objects that make concurrency simple with method and state encapsulation. Dapr provides many capabilities in its actor runtime including concurrency, state, life-cycle management for actor activation/deactivation and timers and reminders to wake-up actors.
|
||||
| **[Observability](/docs/building-blocks/observability)** | Dapr emit metrics, logs, and traces to debug and monitor both Dapr and user applications. Dapr supports distributed tracing to easily diagnose and serve inter-service calls in production using the W3C Trace Context standard and Open Telemetry to send to different monitoring tools.
|
||||
| **[Secrets](/docs/building-blocks/secrets)** | Dapr provides secrets management and integrates with public cloud and local secret stores to retrieve the secrets for use in application code.
|
||||
|
||||
## Sidecar architecture
|
||||
|
||||
|
|
@ -68,7 +55,7 @@ In self hosted mode Dapr runs as a separate side-car process which your service
|
|||
|
||||
In container hosting environments such as Kubernetes, Dapr runs as a side-car container with the application container in the same pod.
|
||||
|
||||
<img src="../images/overview-sidecar-kubernetes.png" width=600>
|
||||
<img src="/images/overview-sidecar-kubernetes.png" width=600>
|
||||
|
||||
## Developer language SDKs and frameworks
|
||||
|
||||
|
|
@ -119,7 +106,7 @@ Dapr can be configured to run on your local developer machine in [self hosted mo
|
|||
|
||||
You can use the [Dapr CLI](https://github.com/dapr/cli#launch-dapr-and-your-app) to run a Dapr enabled application on your local machine. Try this out with the [getting started samples](../getting-started).
|
||||
|
||||
<img src="../images/overview_standalone.png" width=800>
|
||||
<img src="/images/overview_standalone.png" width=800>
|
||||
|
||||
### Running Dapr in Kubernetes mode
|
||||
|
||||
|
|
@ -127,6 +114,6 @@ Dapr can be configured to run on any [Kubernetes cluster](../concepts/hosting/).
|
|||
|
||||
The `dapr-sentry` service is a certificate authority that enables mutual TLS between Dapr sidecar instances for secure data encryption. For more information on the `Sentry` service read the [security overview](../concepts/security/README.md#dapr-to-dapr-communication)
|
||||
|
||||
<img src="../images/overview_kubernetes.png" width=800>
|
||||
<img src="/images/overview_kubernetes.png" width=800>
|
||||
|
||||
Deploying and running a Dapr enabled application into your Kubernetes cluster is a simple as adding a few annotations to the deployment schemes. You can see some examples [here](https://github.com/dapr/quickstarts/tree/master/hello-kubernetes/deploy) in the Kubernetes getting started sample. Try this out with the [Kubernetes getting started sample](https://github.com/dapr/quickstarts/tree/master/hello-kubernetes)
|
||||
|
|
|
|||
|
|
@ -1,7 +0,0 @@
|
|||
---
|
||||
title: "Dapr Walkthroughs"
|
||||
linkTitle: "Walkthroughs"
|
||||
weight: 40
|
||||
description: >
|
||||
Step-by-step walkthoughs on what happens under the hood of Dapr.
|
||||
---
|
||||
|
|
@ -1,58 +0,0 @@
|
|||
---
|
||||
title: "Sequence of Events on a dapr run in Self Hosting Mode"
|
||||
linkTitle: "Dapr Run"
|
||||
weight: 1000
|
||||
---
|
||||
|
||||
The doc describes the sequence of events that occur when `dapr run` is executed in self hosting mode. It uses [sample 1](https://github.com/dapr/quickstarts/tree/master/hello-world) as an example.
|
||||
|
||||
Terminology used below:
|
||||
|
||||
- Dapr CLI - the Dapr command line tool. The binary name is dapr (dapr.exe on Windows)
|
||||
- Dapr runtime - this runs alongside each app. The binary name is daprd (daprd.exe on Windows)
|
||||
|
||||
In self hosting mode, running `dapr init` copies the Dapr runtime onto your machine and starts the Placement service (used for actors placement) Redis and Zipkin in containers. The Redis and Placement service must be present before running `dapr run`. The Dapr CLI also creates the default components directory which for Linux/MacOS is: `$HOME/.dapr/components` and for Windows: `%USERPROFILE%\.dapr\components` if it does not already exist. The CLI creates a default `config.yaml` in `$HOME/.dapr` for Linux/MacOS or `%USERPROFILE%\.dapr` in Windows to enable tracing by default.
|
||||
|
||||
What happens when `dapr run` is executed?
|
||||
|
||||
```bash
|
||||
dapr run --app-id nodeapp --app-port 3000 --dapr-http-port 3500 node app.js
|
||||
```
|
||||
|
||||
First, the Dapr CLI loads the components from the default directory (specified above) for the state store and pub/sub: `statestore.yaml` and `pubsub.yaml`, respectively. [Code](https://github.com/dapr/cli/blob/51b99a988c4d1545fdc04909d6308be121a7fe0c/pkg/standalone/run.go#L196-L266).
|
||||
|
||||
You can either add components to the default directory or create your own `components` directory and provide the path to the CLI using the `--components-path` flag.
|
||||
|
||||
In order to switch components, simply replace or add the YAML files in the components directory and run `dapr run` again.
|
||||
For example, by default Dapr uses the Redis state store in the default components dir. You can either override it with a different YAML, or supply your own components path.
|
||||
|
||||
Then, the Dapr CLI [launches](https://github.com/dapr/cli/blob/d585612185a4a525c05fb62b86e288ccad510006/pkg/standalone/run.go#L290) two proceses: the Dapr runtime and your app (in this sample `node app.js`).
|
||||
|
||||
If you inspect the command line of the Dapr runtime and the app, observe that the Dapr runtime has these args:
|
||||
|
||||
```bash
|
||||
daprd.exe --app-id mynode --dapr-http-port 3500 --dapr-grpc-port 43693 --log-level info --app-max-concurrency -1 --app-protocol http --app-port 3000 --placement-host-address localhost:50005
|
||||
```
|
||||
|
||||
And the app has these args, which are not modified from what was passed in via the CLI:
|
||||
|
||||
```bash
|
||||
node app.js
|
||||
```
|
||||
|
||||
### Dapr runtime
|
||||
|
||||
The daprd process is started with the args above. `--app-id`, "nodeapp", which is the Dapr app id, is forwarded from the Dapr CLI into `daprd` as the `--app-id` arg. Similarly:
|
||||
|
||||
- the `--app-port` from the CLI, which represents the port on the app that `daprd` will use to communicate with it has been passed into the `--app-port` arg.
|
||||
- the `--dapr-http-port` arg from the CLI, which represents the http port that daprd is listening on is passed into the `--dapr-http-port` arg. (Note to specify grpc instead you can use `--dapr-grpc-port`). If it's not specified, it will be -1 which means the Dapr CLI will chose a random free port. Below, it's 43693, yours will vary.
|
||||
|
||||
### The app
|
||||
|
||||
The Dapr CLI doesn't change the command line for the app itself. Since `node app.js` was specified, this will be the command it runs with. However, two environment variables are added, which the app can use to determine the ports the Dapr runtime is listening on.
|
||||
The two ports below match the ports passed to the Dapr runtime above:
|
||||
|
||||
```ini
|
||||
DAPR_GRPC_PORT=43693
|
||||
DAPR_HTTP_PORT=3500
|
||||
```
|
||||
|
|
@ -15,14 +15,13 @@ Dapr is a portable, event-driven runtime that makes it easy for enterprise devel
|
|||
|
||||
* **Components** encapsulate the implementation for a building block API. Example implementations for the state building block may include Redis, Azure Storage, Azure Cosmos DB, and AWS DynamoDB. Many of the components are pluggable so that one implementation can be swapped out for another.
|
||||
|
||||
To learn more, see [Dapr Concepts](../concepts).
|
||||
To learn more, see [Dapr Concepts](/docs/concepts).
|
||||
|
||||
## Setup the development environment
|
||||
|
||||
Dapr can be run locally or in Kubernetes. We recommend starting with a local setup to explore the core Dapr concepts and familiarize yourself with the Dapr CLI. Follow these instructions to [configure Dapr locally and on Kubernetes](./environment-setup.md).
|
||||
Dapr can be run locally or in Kubernetes. We recommend starting with a local setup to explore the core Dapr concepts and familiarize yourself with the Dapr CLI. Follow these instructions to [configure Dapr locally and on Kubernetes](/docs/concepts/getting-started/install-dapr).
|
||||
|
||||
## Next steps
|
||||
|
||||
1. Once Dapr is installed, continue to the [Hello World quickstart](https://github.com/dapr/quickstarts/tree/master/hello-world).
|
||||
2. Explore additional [quickstarts](https://github.com/dapr/quickstarts) for more advanced concepts, such as service invocation, pub/sub, and state management.
|
||||
3. Follow [How To guides](../howto) to understand how Dapr solves specific problems, such as creating a [rate limited app](../howto/control-concurrency).
|
||||
2. Explore additional [quickstarts](https://github.com/dapr/quickstarts) for more advanced concepts, such as service invocation, pub/sub, and state management.
|
||||
Loading…
Reference in New Issue