search

dotnet / aspire

Tools, templates, and packages to accelerate building observable, production-ready apps
https://learn.microsoft.com/dotnet/aspire
MIT License
3.91k stars 476 forks source link

9.0.0-rc.1.24511.1 does not detect podman #6629

Open paulomorgado opened 2 weeks ago

paulomorgado commented 2 weeks ago

To detect podman, I need to set the app host DOTNET_ASPIRE_CONTAINER_RUNTIME configuration to podman.

Is that the intended behavior?

Alirexaa commented 2 weeks ago

Do you have Docker installed?

If your host environment has both Docker and Podman installed, .NET Aspire defaults to using Docker. You can instruct .NET Aspire to use Podman instead, by setting the DOTNET_ASPIRE_CONTAINER_RUNTIME environment variable to podman

see: https://learn.microsoft.com/en-us/dotnet/aspire/fundamentals/setup-tooling?tabs=windows&pivots=visual-studio#container-runtime

paulomorgado commented 2 weeks ago

@Alirexaa, I don't have Docker installed, but I have docker CLI working with podman.

danegsta commented 1 week ago

The detection is based on the CLI interface, not the backend daemon, so we're detecting and defaulting to the Docker CLI. If both are installed, we have to pick one and chose to default to the Docker CLI (we do attempt to detect the scenario where docker is just a symlink to the podman binary and choose Podman in that scenario).

paulomorgado commented 1 week ago

The detection is based on the CLI interface, not the backend daemon, so we're detecting and defaulting to the Docker CLI. If both are installed, we have to pick one and chose to default to the Docker CLI (we do attempt to detect the scenario where docker is just a symlink to the podman binary and choose Podman in that scenario).

That doesn't seem to be a fail-safe approach.

danegsta commented 1 week ago

The detection is based on the CLI interface, not the backend daemon, so we're detecting and defaulting to the Docker CLI. If both are installed, we have to pick one and chose to default to the Docker CLI (we do attempt to detect the scenario where docker is just a symlink to the podman binary and choose Podman in that scenario).

That doesn't seem to be a fail-safe approach.

We don't use any daemon API directly; our Docker vs. Podman support just represents our ability to run commands and parse the output from the different CLI implementations. The Podman CLI can be used to access a Docker daemon backend and the Docker CLI can target a Podman daemon's Docker compatible API and our tooling will still work in those cases, but we also see those as edge cases compared to Docker users running the Docker CLI and Podman users running the Podman CLI. We've been using this same approach since the first GA release of Aspire without any major issues.