diff --git a/daprdocs/content/en/developing-applications/local-development/multi-app-dapr-run/multi-app-overview.md b/daprdocs/content/en/developing-applications/local-development/multi-app-dapr-run/multi-app-overview.md index 2322aa341..92aa28d1a 100644 --- a/daprdocs/content/en/developing-applications/local-development/multi-app-dapr-run/multi-app-overview.md +++ b/daprdocs/content/en/developing-applications/local-development/multi-app-dapr-run/multi-app-overview.md @@ -10,22 +10,21 @@ description: Run multiple applications with one CLI command Multi-App Run 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. - -Instead, you simply want to run them as local executables in self-hosted mode. However, self-hosted mode requires you to: +Let's say you want to run several applications locally to test them together, similar to a production scenario. Until Multi-App Run, you'd have 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. - 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 start multiple applications in either self-hosted or Kubernetes mode using a template file and running a single command. 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 + {{< tabs Self-hosted Kubernetes>}} {{% codetab %}} -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 When you execute `dapr run -f .`, it generates the multi-app template file (named `dapr.yaml`) present in the current directory to run all the applications. @@ -51,13 +50,28 @@ apps: For a more in-depth example and explanation of the template properties, see [Multi-app template]({{< ref multi-app-template.md >}}). +## Locations for resources and configuration files + +You have options on where to place your applications' resources and configuration files when using Multi-App Run. + +### 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 using Multi-App Run, each application 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. + +If you decide to add a `.dapr` directory in each application 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`, such as, `webapp`, or `backend`. This helps if you'd like to be explicit about resource or application directory paths. + {{% /codetab %}} {{% codetab %}} -With Multi-App Run, you can start multiple applications in a Kubernetes development or test environment using a single `dapr run -f -k` 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 When you execute `dapr run -f .`, Dapr generates the multi-app template file (named `dapr.yaml`) in the `.dapr/deploy` directory within each application. Each time you run `dapr run -f -k .`, the generated Kubernetes Deployment YAML file is overwritten. @@ -91,25 +105,6 @@ For a more in-depth example and explanation of the template properties, see [Mul {{< /tabs >}} - -## Locations for resources and configuration files - -You have options on where to place your applications' resources and configuration files when using Multi-App Run. - -### 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 using Multi-App Run, each application 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. - -If you decide to add a `.dapr` directory in each application 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`, such as, `webapp`, or `backend`. This helps if you'd like to be explicit about resource or application directory paths. - ## Logs The run template provides two log destination fields for each application and its associated daprd process: @@ -118,7 +113,7 @@ The run template provides two log destination fields for each application and it 2. `daprdLogDestination` : This field configures the log destination for the `daprd` process. The possible values are `console`, `file` and `fileAndConsole`. The default value is `file` where the `daprd` logs are written to a file by default. -#### Log file format +### Log file format Logs for application and `daprd` are captured in separate files. These log files are created automatically under `.dapr/logs` directory under each application directory (`appDirPath` in the template). These log file names follow the pattern seen below: @@ -127,13 +122,30 @@ Logs for application and `daprd` are captured in separate files. These log files Even if you've decided to rename your resources folder to something other than `.dapr`, the log files are written only to the `.dapr/logs` folder (created in the application directory). - ## Watch the demo +{{< tabs Self-hosted Kubernetes>}} + +{{% codetab %}} + + Watch [this video for an overview on Multi-App Run](https://youtu.be/s1p9MNl4VGo?t=2456): +{{% /codetab %}} + +{{% codetab %}} + + +Watch [this video for an overview on Multi-App Run in Kubernetes](https://youtu.be/nWatANwaAik?si=O8XR-TUaiY0gclgO&t=1024): + + + +{{% /codetab %}} + +{{< /tabs >}} + ## Next steps - [Learn the Multi-App Run template file structure and its properties]({{< ref multi-app-template.md >}}) diff --git a/daprdocs/content/en/reference/cli/dapr-init.md b/daprdocs/content/en/reference/cli/dapr-init.md index a94c3e19a..bdb93bf5d 100644 --- a/daprdocs/content/en/reference/cli/dapr-init.md +++ b/daprdocs/content/en/reference/cli/dapr-init.md @@ -44,6 +44,9 @@ dapr init [flags] | N/A | DAPR_HELM_REPO_USERNAME | A username for a private Helm chart | The username required to access the private Dapr Helm chart. If it can be accessed publicly, this env variable does not need to be set| | N/A | DAPR_HELM_REPO_PASSWORD | A password for a private Helm chart |The password required to access the private Dapr Helm chart. If it can be accessed publicly, this env variable does not need to be set| | | `--container-runtime` | | `docker` | Used to pass in a different container runtime other than Docker. Supported container runtimes are: `docker`, `podman` | +| `--dev` | | | Creates Redis and Zipkin deployments when run in Kubernetes. | + + ### Examples #### Self hosted environment