update per Mark review

Signed-off-by: Hannah Hunter <hannahhunter@microsoft.com>
This commit is contained in:
Hannah Hunter 2023-01-30 09:44:57 -06:00
parent 4a2440dbc6
commit 716d75f2cb
5 changed files with 65 additions and 59 deletions

View File

@ -1,7 +1,7 @@
---
type: docs
title: "Multi-app support"
linkTitle: "Multi-app support"
title: "Multi-app run"
linkTitle: "Multi-app run"
weight: 300
description: "Support for running multiple Dapr applications with one command"
---

View File

@ -1,13 +1,13 @@
---
type: docs
title: Run multiple applications with one command
linkTitle: Multi-app Run overview
title: Multi-app Run (MapR) overview
linkTitle: MapR overview
weight: 1000
description: Learn the scenarios around running multiple applications with one Dapr command
description: Learn the scenarios around running multiple applications with one CLI command
---
{{% alert title="Note" color="primary" %}}
Multi-app `dapr run -f` is currently a preview feature only supported in Linux/MacOS.
MapR (Multi-app Run using `dapr run -f`) is currently a preview feature only supported in Linux/MacOS.
{{% /alert %}}
Let's say you want to run several applications locally to test them together, similar to a production scenario. With a local Kubernetes cluster, you'd be able to do this with helm/deployment YAML files. You'd also have to build them as containers and set up Kubernetes, which can add some complexity.
@ -15,23 +15,25 @@ Let's say you want to run several applications locally to test them together, si
Instead, you simply want to run them as local executables in self-hosted mode. However, self-hosted mode requires you to:
- Run multiple `dapr run` commands
- Keep track of all ports opened (you cannot have duplicate ports for different applications)- Remember the resources folders and configuration files that each application refers to
- Keep track of all ports opened (you cannot have duplicate ports for different applications).
- Remember the resources folders and configuration files that each application refers to.
- Recall all of the additional flags you used to tweak the `dapr run` command behavior (`--app-health-check-path`, `--dapr-grpc-port`, `--unix-domain-socket`, etc.)
With Multi-app Run, you can easily start multiple applications in self-hosted mode using a single `dapr run -f` command.
With Multi-app Run, you can start multiple applications in self-hosted mode using a single `dapr run -f` command using a template file. The template file describes how to start multiple applications as if you had run many separate CLI `run`commands. By default, this template file is called `dapr.yaml`.
## Multi-app Run template file
## MapR template file
When you execute `dapr run -f`, Dapr parses the multi-app template file initialized with `dapr init`. By default, this template file is called `dapr.yaml`.
When you execute `dapr run -f`, uses the multi-app template file to run all the applications.
You can customize the template file by executing `dapr run -f ./<your-preferred-file-name>.yaml`.
You can name template file with preferred name other than the default. For example `dapr run -f ./<your-preferred-file-name>.yaml`.
The following `dapr.yaml` example includes some of the configurations you can customize to your applications. For a more in-depth example and explanation of variables, see [Multi-app template]({{< ref multi-app-template.md >}}).
The following `dapr.yaml` example includes some of the template properties you can customize for your applications. In the example, you can simultaneously launch 2 applications with app IDs of `processor` and `emit-metrics`.
```yaml
version: 1
apps:
- appDirPath: ../../../apps/processor/
- appID: processor
appDirPath: ../../../apps/processor/
appPort: 9081
daprHTTPPort: 3510
command: ["go","run", "app.go"]
@ -43,23 +45,25 @@ apps:
command: ["go","run", "app.go"]
```
## Approaches for using Multi-app Run
For a more in-depth example and explanation of the template properties, see [Multi-app template]({{< ref multi-app-template.md >}}).
You have several options when using Multi-app Run.
## Locations for resources and configuration files
### Point to one location (with convention)
You have options on where to place your applications' resources and configuration files when using MapR.
### Point to one file location (with convention)
You can set all of your applications resources and configurations at the `~/.dapr` root. This is helpful when all applications share the same resources path, like when testing on a local machine.
### Separate file locations for each application (with convention)
When developing multiple applications, each app directory can have a `.dapr` folder, which contains a `config.yaml` file and a `resources` directory. Otherwise, if the `.dapr` directory is not present within the app directory, the default `~/.dapr/resources/` and `~/.dapr/config.yaml` locations are used.
You can set all of your applications and resources at the `~/.dapr` root. This is helpful when all applications share the same resources path.
### Point to separate locations (with convention)
If you decide to add a `.dapr` directory in each app directory, with a `/resources` directory and `config.yaml` file, you can specify different resources paths for each application. This approach remains within convention by using the default `.dapr`
### Point to separate locations (custom)
You can also name each app directory's `.dapr` directory something other than `.dapr`, like `mymagicapp`, `webapp`, or `backend`. This helps if you'd like to be explicit about resource or application directory paths.
You can also name each app directory's `.dapr` directory something other than `.dapr`, such as, `webapp`, or `backend`. This helps if you'd like to be explicit about resource or application directory paths.
## Logs
@ -68,18 +72,17 @@ Logs are included by default within each app directory and are tracked in the fo
- `app.log`
- `daprd.log`
Even if you've decided to rename your resources folder to something other than `.dapr`, the logs will remain there.
### Precedence rules
Even if you've decided to rename your resources folder to something other than `.dapr`, the logs file are written to `.dapr` folder.
## Try it out
## Watch the demo
Watch [this video for an overview on Multi-app Run](https://youtu.be/s1p9MNl4VGo?t=2456):
Watch [this video for an overview on MapR](https://youtu.be/s1p9MNl4VGo?t=2456):
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/s1p9MNl4VGo?start=2456" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
## Next steps
## Next steps
[Unpack the MapR template file and its properties]({{< ref multi-app-template.md >}})

View File

@ -1,28 +1,30 @@
---
type: docs
title: Multi-app template file
linkTitle: Multi-app Run template
title: MapR template file
linkTitle: MapR template
weight: 2000
description: Unpack the multi-app template file and its variables
description: Unpack the MapR template file and its properties
---
{{% alert title="Note" color="primary" %}}
Multi-app `dapr run -f` is currently a preview feature only supported in Linux/MacOS.
MapR (Multi-app Run using `dapr run -f`) is currently a preview feature only supported in Linux/MacOS.
{{% /alert %}}
The multi-app template file is a single YAML configuration file that you can use to configure multiple applications alongside a Dapr sidecar. Execute the following command for Dapr to parse the multi-app template file, named `dapr.yaml` by default:
The MapR template file is a YAML file that you can use to run multiple applications at once. Execute the following CLI command to read the MapR template file, named `dapr.yaml` by default:
```cmd
// the template file needs to be called `dapr.yaml` by default
dapr run -f
```
To name the multi-app template file something other than `dapr.yaml`, run:
If the MapR template file is named something other than `dapr.yaml`, run:
```cmd
dapr run -f ./<your-preferred-file-name>.yaml
```
The multi-app template file can include any of the following parameters.
The MapR template file can include the following properties. Below is an example template showing two applications that are configured with some of the properties.
```yaml
version: 1
@ -49,42 +51,43 @@ apps:
command: ["./backend"]
```
## Parameters
## Template properties
The properties for the MapR template align with the `dapr run` CLI flags, [listed in the CLI reference documentation]({{< ref run.md >}}).
| Parameter | Required | Details | Example |
| Properties | Required | Details | Example |
|--------------------------|:--------:|--------|---------|
| `appID` | Y | Your application's app ID | `webapp`, `backend` |
| `appDirPath` | Y | Path to the your application | `./webapp/`, `./backend/` |
| `appID` | Y | Application's app ID | `webapp`, `backend` |
| `appDirPath` | Y | Path to the your application code | `./webapp/`, `./backend/` |
| `resourcesPath` | N | Path to your Dapr resources. Can be default by convention; ignore if directory isn't found | `./app/components`, `./webapp/components` |
| `configFilePath` | N | Path to your application's configuration file | `./webapp/config.yaml` |
| `appProtocol` | N | Application protocol | `HTTP`, `GRPC` |
| `appPort` | N | Designated port for your application | `8080`, `3000` |
| `appProtocol` | N | The protocol Dapr uses to talk to the application. | `HTTP`, `GRPC` |
| `appPort` | N | The port your application is listening on | `8080`, `3000` |
| `daprHTTPPort` | N | Dapr HTTP port | |
| `daprGRPCPort` | N | Dapr GRPC port | |
| `daprInternalGRPCPort` | N | | |
| `metricsPort` | N | | |
| `unixDomainSocket` | N | Path to the Unix Domain Socket | `/tmp/test-socket` |
| `profilePort` | N | | |
| `enableProfiling` | N | | |
| `metricsPort` | N | The port that Dapr sends its metrics information to | |
| `unixDomainSocket` | N | Path to a unix domain socket dir mount. If specified, communication with the Dapr sidecar uses unix domain sockets for lower latency and greater throughput when compared to using TCP ports. Not available on Windows. | `/tmp/test-socket` |
| `profilePort` | N | The port for the profile server to listen on | |
| `enableProfiling` | N | Enable profiling via an HTTP endpoint | |
| `apiListenAddresses` | N | Dapr API listen addresses | |
| `logLevel` | N | | |
| `appMaxConcurrency` | N | | |
| `logLevel` | N | The log verbosity. | |
| `appMaxConcurrency` | N | The concurrency level of the application; default is unlimited | |
| `placementHostAddress` | N | | |
| `appSSL` | N | | |
| `daprHTTPMaxRequestSize` | N | | |
| `daprHTTPReadBufferSize` | N | | |
| `appSSL` | N | Enable https when Dapr invokes the application | |
| `daprHTTPMaxRequestSize` | N | Max size of the request body in MB. | |
| `daprHTTPReadBufferSize` | N | Max size of the HTTP read buffer in KB. This also limits the maximum size of HTTP headers. The default 4 KB | |
| `enableAppHealthCheck` | N | Enable the app health check on the application | `true`, `false` |
| `appHealthCheckPath` | N | Path to the health check file | `/healthz` |
| `appHealthProbeInterval` | N | App health check interval time range | |
| `appHealthProbeTimeout` | N | When the app health check will timeout | |
| `appHealthThreshold` | N | | |
| `enableApiLogging` | N | | |
| `appHealthProbeInterval` | N | Interval to probe for the health of the app in seconds
| |
| `appHealthProbeTimeout` | N | Timeout for app health probes in milliseconds | |
| `appHealthThreshold` | N | Number of consecutive failures for the app to be considered unhealthy | |
| `enableApiLogging` | N | Enable the logging of all API calls from application to Dapr | |
| `daprPath` | N | Dapr install path | |
| `env` | N | Map to environment variable; environment variables applied per application will overwrite environment variables shared across applications | `DEBUG`, `DAPR_HOST_ADD` |
## Scenario
## Next steps
todo
## Next steps
[Try out the MapR template using the Distributed Calculator tutorial]

View File

@ -20,4 +20,4 @@ For CLI there is no explicit opt-in, just the version that this was first made a
| **App Middleware** | Allow middleware components to be executed when making service-to-service calls | N/A | [App Middleware]({{<ref "middleware.md#app-middleware" >}}) | v1.9 |
| **App health checks** | Allows configuring app health checks | `AppHealthCheck` | [App health checks]({{<ref "app-health.md" >}}) | v1.9 |
| **Pluggable components** | Allows creating self-hosted gRPC-based components written in any language that supports gRPC. The following component APIs are supported: State stores, Pub/sub, Bindings | N/A | [Pluggable components concept]({{<ref "components-concept#pluggable-components" >}})| v1.9 |
| **Multi-app Run** | Configure multiple Dapr applications from a single configuration file and run from a single command | `dapr run -f` | [Multi-app Dapr Run]({{< ref multi-app-dapr-run.md >}}) | v1.10 |
| **MapR** | Configure multiple Dapr applications from a single configuration file and run from a single command | `dapr run -f` | [MapR]({{< ref multi-app-dapr-run.md >}}) | v1.10 |

View File

@ -35,7 +35,7 @@ dapr run [flags] [command]
| `--dapr-http-port` | `DAPR_HTTP_PORT` | `3500` | The HTTP port for Dapr to listen on |
| `--enable-profiling` | | `false` | Enable "pprof" profiling via an HTTP endpoint |
| `--help`, `-h` | | | Print the help message |
| `--run-file`, `-f` | | Linux/Mac: `$HOME/.dapr/dapr.yaml` | Run multiple applications at once via the multi-app template file |
| `--run-file`, `-f` | | Linux/Mac: `$HOME/.dapr/dapr.yaml` | Run multiple applications at once using a multi-app run (MapR) template file |
| `--image` | | | Use a custom Docker image. Format is `repository/image` for Docker Hub, or `example.com/repository/image` for a custom registry. |
| `--log-level` | | `info` | The log verbosity. Valid values are: `debug`, `info`, `warn`, `error`, `fatal`, or `panic` |
| `--enable-api-logging` | | `false` | Enable the logging of all API calls from application to Dapr |