Support for podman (or also, removing hard docker dependency)

[bureado]

Describe the proposal

In standalone mode, it'd be nice to have podman support in dapr (and perhaps daprd) at least for dapr init and basic dapr run use cases. I don't have docker in my system.

Even if I alias docker=podman in my system, the github.com/docker/docker/client library is used in dapr/cli which makes dapr init fail.

If I remove the isDockerInstalled() functionality from standalone.go and nix the dependency, and then also change RunCmdAndWait() instances of docker for podman, I'm able to dapr init with some hacks (see #255):

$ podman ps | grep dapr
231a26a31000  docker.io/library/redis:latest   redis-server          4 minutes ago  Up 4 minutes ago  0.0.0.0:6379->6379/tcp    dapr_redis
f49eb9753492  docker.io/daprio/dapr:latest                           4 minutes ago  Up 4 minutes ago  0.0.0.0:50005->50005/tcp  dapr_placement

Those conmon processes are running unprivileged, dapr run --app-id foo -- cat starts up successfully and I'm able to run samples/1.hello-world. Things I haven't tested include binding to a particular network. I also haven't looked into any dapr/dapr hard dependencies on docker.

[yaron2]

daprd (dapr/dapr) doesn't have any dependencies on docker.

The only reason why there's a Docker dependency for the CLI is to install Redis as a default development statestore/pubsub for the developer, so they only need to focus on writing code.

There's also an optional placement service for actors, that we install as a Docker container but that could just as well run as a binary.

In effect, Docker just makes setting up a consistent dev environment very easy, and takes care of lifecycle/restarts/versioning etc that would otherwise involve a lot of boilerplate logic to do.

[bureado]

Got it. Here are the rough changes I made to use podman instead of docker. If the docker usage in dapr/cli is expected to be limited to the scenarios you describe, perhaps the easiest solution here would be to try for podman and if not available, fallback to docker, perhaps with a flag to select. If it's valuable, let me think of something and I'll send a PR.

[yaron2]

Can podman run on Windows?

[yaron2]

Hmm.. only with WSL2 it seems.

I think there's no risk in trying podman first, even though (at least in the current state of things) it's likely to fallback to docker most of the time.

@msfussell what do you think? as far as the user's concerned there's no change.

[bureado]

Here's another suggestion -- if alias docker=podman is widespread enough (it was the case in my machine and it's a meme in the Fedora ecosystem) then perhaps the more durable solution here would be to run docker in a shell so that the alias is honored, and test for docker in the shell rather than with the ghc/docker/docker/client library. What I don't know is how that would impact Windows. Let me know which path do you think it's more reasonable and I can work on a patch.

[mhoad]

My understanding of the issue is the following:

• There is no hard dependency on Docker itself
• It's only used as a way to provide a consistent dev environment for things like Redis etc
• In theory another Docker API compatible solution like Podman should work
• That isn't currently possible because we test for a a Docker like solution by using the Docker SDK and that isn't compatible with a solution like Podman

Some potential solutions could be:

1. Change how we check for Docker: As @bureado suggested, this solution seems to be the way the Podman community expects things to work I guess. It's API compatible and the command itself can be aliased so most things SHOULD just work expect for situations like this.
2. Check for Podman and fallback if not found: Sounds like another simple enough solution potentially.
3. Expose via configuration option: Another solution could be to implement a flag that allows the CLI to understand the environment it will be running in. For example podman rather than docker and microk8s kubectl rather than kubectl as mentioned below. ' Sidenote: This same problem comes up again for Kubernetes kubectl when trying to run Dapr on a system with Microk8s (A self-contained, single node but otherwise production quality Kubernetess implementation from the Ubuntu team). There commands are prefixed with microk8s so kubectl would be run as microk8s kubectl. However when running dapr init -k you will get an error because of the assumption around how kubectl itself is invoked. The current workaround for this is to install kubectl as normal and then set it up to work with the local MicroK8s instance.

@yaron2 / @msfussell Does that seem correct to you?

[jfmatth]

Would it be easier if we just added a flag to not check for Docker? Assuming the API works with whatever container system we have installed?

[mark-dropbear]

@greenie-msft I was just wondering if you could share some insight on why this was removed from the roadmap? I would love to be able to work locally without Docker just from a security perspective. This change would allow that for the entire community and as @jfmatth mentioned it may be a really low cost feature to implement

[dapr-bot]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

[dapr-bot]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

[mhoad]

Should we still consider this?

[mukundansundar]

@mhoad This is an issue to consider.

@yaron2 Thoughts on this?

[dapr-bot]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

[esride-jts]

Any progress on this request? We would love to use dapr with our current podman development and staging infrastructure. Unluckily, I can only offer some ready to use integration tests for geospatial intelligence workflows like analysing wildfires using Sentinel-2 image services.

[yaron2]

@esride-jts there's a great PR from @martin-bucinskas for this.

[auvansangit]

I would love to see this pr is merged, I use podman too!!

[martin-bucinskas]

/assign

[thanhhh]

I solved this issue by using the following script for Dapr init and uninstall:

• Dapr Init

  podman run --name "dapr_zipkin" --restart always -d -p 9411:9411 openzipkin/zipkin
  podman run --name "dapr_redis" --restart always -d -p 6379:6379 redis
  podman network create dapr-network
  dapr init --slim --network dapr-network
  

• Dapr uninstall

  dapr uninstall --network dapr-network
  podman network rm dapr-network
  podman stop dapr_zipkin
  podman stop dapr_redis
  podman rm dapr_zipkin
  podman rm dapr_redis
  

[dapr-bot]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

[mhoad]

This is still being worked on I believe?

[martin-bucinskas]

This is still being worked on I believe?

Yes, will push out the changes the upcoming weekend.

[dapr-bot]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

[mukundansundar]

Not stale