Initialize Dapr without docker

[youngbupark]

Describe the proposal

This is the issue to track the Gitter conversation.

This is the proposal to run dapr init without docker or provide the document to run dapr without docker.

[orizohar]

Per recent discussion in the dapr core team, this will be implemented via an addition of an optional flag to allow dapr init to run while skipping docker container init steps, by so removing dependency to docker for users who wish to avoid it.

[mukundansundar]

@orizohar @youngbupark @yaron2

This is my idea for implementing this:

1. Introduce a command line flag for dapr init such as --without-docker or --no-docker
2. Update docs with a how-to that describes how to install without docker running
   -- run the placement service as part of the installation steps https://github.com/dapr/dapr/releases/download/v0.8.0/placement_darwin_amd64.tar.gz
   -- run redis
   -- modify redis-host in the ~/.dapr/components/redis.yaml etc.
3. Update samples/1.hello-world to include the example where dapr is run without docker.

[LMWF]

I don't think the design for this was finished. Both sample 1 and actors need a state store. If we're going to have a "no docker" mode either it should have either:

1. only service invocation and no other building blocks or
2. the same things as today, but the state store and placement don't run in containers.

Option 1 makes for reduced functionality, but it allows the user to see one key feature of dapr.

Option 2 implies that the state store either be
a. local, but not containerized or
b. somewhere else (e.g. in a cloud) or
c. a emulated/in-memory state store/local shared file - meant for this scenario only and not supported in any other way.

Option a tends to have the problems that it is difficult to set up and may have a lot of env dependencies. This would probably take longer and have more resulting problems than setting up docker.

Option b requires the user have an account and set up the component themselves, which might a bit of a hassle to run a local sample.

Option c seems like a reasonable direction - we can achieve the aims of the issue without increasing env problems or user set up.

[mukundansundar]

@LMWF good point. This also brings into the discussion on whether this "no docker" mode should have tracing enabled as part of it or not. #342

For tracing also we have the same issue of either emulating a zipkin service(or other exporters) or run it locally or run it in cloud.

[yaron2]

1. Introduce a command line flag for dapr init such as --without-docker or --no-docker

I would opt to use for some more standardized terms to signify a reduced set of capabilities.
In addition, --without-docker isn't really WITHOUT docker, as Dapr doesn't install Docker, it installs containers.

For this reason, I think that dapr init --slim might be a way to signify to the user that Dapr is installed in a slim version, ie. only the runtime without the local dev environment.

If a user wants to run the placement service for example, they will run dapr init again to get Dapr to try and install the placement container.

[mukundansundar]

Based on the comments in the issue, there are a couple of options that we can do.

1. Limited functionality for dapr init without docker (possibly dapr init --slim)

• Only the daprd binary is downloaded and installed in this option. No components or config files are added in the default path. (folder alone might be created)
• With this actors, statestore, tracing, and pubsub will not work out of the box. The user needs to download and run placement service for actors and provide configurations for enabling statestore and tracing.
• A doc is provided with steps needed to enable state store/actors.
• Sample needs to be reworked/added to, to work without a basic state store/actors.

2. We maintain parity with the current dapr init behavior

• In this scenario, placement service needs to be downloaded and some ability to start the placement service from dapr cli is a bonus.
• For state stores:
  • An emulated store in-memory/local file store
  • Spin up a local store without containers
• For the second option, the emulated store is better compared to additional setup instructions and possible errorprone setup for local state store without containers.
• Tracing:
  • Spin up a local instance of an exporter (say zipkin)
  • Disable tracing
• Here again the options are limited and disabling tracing seems the less error prone/short setup option

3. Limited functionality for dapr init with placement service binary downloaded

• Here it is the same as the first option, but with the placement service downloaded and installed along with daprd binary

My recommendation would either be option 1 or 3.
@orizohar @amanbha @yaron2 @youngbupark @msfussell

[youngbupark]

Based on the comments in the issue, there are a couple of options that we can do.

1. Limited functionality for dapr init without docker (possibly dapr init --slim)

• Only the daprd binary is downloaded and installed in this option. No components or config files are added in the default path. (folder alone might be created)
• With this actors, statestore, tracing, and pubsub will not work out of the box. The user needs to download and run placement service for actors and provide configurations for enabling statestore and tracing.
• A doc is provided with steps needed to enable state store/actors.
• Sample needs to be reworked/added to, to work without a basic state store/actors.

1. We maintain parity with the current dapr init behavior

• In this scenario, placement service needs to be downloaded and some ability to start the placement service from dapr cli is a bonus.

• For state stores:

  • An emulated store in-memory/local file store
  • Spin up a local store without containers

• For the second option, the emulated store is better compared to additional setup instructions and possible errorprone setup for local state store without containers.

• Tracing:

  • Spin up a local instance of an exporter (say zipkin)
  • Disable tracing

• Here again the options are limited and disabling tracing seems the less error prone/short setup option

1. Limited functionality for dapr init with placement service binary downloaded

• Here it is the same as the first option, but with the placement service downloaded and installed along with daprd binary

My recommendation would either be option 1 or 3.
@orizohar @amanbha @yaron2 @youngbupark @msfussell

I vote for the option 3.

[amanbha]

ACK for option#3 with proper documentation