Local Developer Experience - Run multiple dapr apps using dapr run -f

[shubham1172]

Describe proposal

This is related to the implementation of the proposal https://github.com/dapr/proposals/blob/main/0003-I-enhance-dapr-run-multiple-apps.md

Targets for v1.10

The main requirements for the command:

• being able to configure multiple dapr apps from a single configuration file

• users should be able to use normal dapr CLI commands for self hosted mode against any apps that are started through dapr run -f

• Initial implementation will only support Linux & macOs.

• dapr run -f <path> will be an interactive process running completely for the lifecycle of applications, on exiting the process,

• all other spawned processes will also quit.

• logs will be written to a predefined location. Users will need to manually tail the file.

• Get Sign off on feature proposal enhance dapr run to run multiple applications proposals#6

• Create a template for configuring multiple applications to be run with dapr run command #1141

• Implement the new precedence rules for resources_dir for dapr run -f #1142

• Add capability to run multiple apps from a given run configuration file #1143

• Docs for dapr run -f

• [Proposal] dapr list --output json includes related Dapr Compose configuration file metadata #1153

Future enhancements - moved to #1240

Describe the proposal (Old version)

This issue derives from dapr/community#207 to propose two new commands -
dapr compose up and dapr compose down.

Compose file structure

version: 1
common:
  environment:  # any environment variable shared among apps
    - DEBUG: true
services:
  - id: kafka
    image: docker.io/bitnami/kafka
    port: 4040
    environment:
      - KAFKA_BROKER_ID: 1
apps:
  - id: webapp
    root_directory: ./webapp/
    components_directory: ./webapp/components # can be default by convention too, ignore if dir is not found.
    config_file: ./webapp/config.yaml # can be default by convention too, ignore if file is not found.
    protocol: HTTP
    port: 8080
    command: python3 app.py
  - id: backend
    root_directory: ./backend/
    components_directory: ./backend/components # can be default by convention too, ignore if dir is not found.
    config_file: ./backend/config.yaml # can be default by convention too, ignore if file is not found.
    protocol: GRPC
    port: 3000
    env:
      - DEBUG: false
    command: ./backend

User experience

• The user can run dapr compose up to start these services and apps
• If something crashes, it will be restarted with exponential back-off until a back-off limit
• If ports are missing, compose automatically finds a free port
• The user can run dapr compose down to gracefully stop everything

Open questions

1. Should we separate services into another proposal?
2. Should we support running apps in containers directly?
3. Should we support running alternate container runtime (like podman) since CLI already does that?

Release Note

RELEASE NOTE: ADD Dapr compose up and down

[mukundansundar]

Related PR dapr/proposals#6

[mukundansundar]

Issues to be created

• Implement YAML template processing with UTs for the run configuration file.

• Add capability to look for resources under given input directory and fallback to default if not present with UTs

• Implement basic dapr run -f with E2Es. Generate the ports automatically and inject as env var into app (HTTP, GRPC, Internal GRPC and Metrics). Write logs to file and STDOUT See io.MultiWriter)(Run apps sequentially)

• (Optional if not in future release)Enhance the template to have a depends_on field and run apps in parallel

• Enhance dapr run to store logs temporarily for any run not only dapr run -f.

• Enhance dapr logs to view logs (Use the folder path defined above and tail log files)

• Add a detached mode for run command -d

[mukundansundar]

@yaron2 Please take a look on the issues list ... Will be creating them soon

[mukundansundar]

Related PR dapr/proposals#6

This proposal has been accepted for implementation ...

[philliphoff]

@mukundansundar I've created several proposals (#1153, #1154, #1155) based on our earlier conversation as to how best accommodate tooling with this new feature.

[greenie-msft]

@mukundansundar is there a docs issue for this effort already?

[hhunter-ms]

@mukundansundar is there a docs issue for this effort already?

Docs issue: dapr/docs#3047

[mukundansundar]

moving this Epic to another milestone ... initial implementation as part of 1.10 is done as seen in the linked issues above.

[philliphoff]

Where does "native" Windows support sit relative to other tasks (if at all)?

[artursouza]

@mukundansundar Please, create a new issue for enhancements in 1.10