Seems like a pretty nice Docker-desktop-ish GUI to me.
One remark:
> Application looks the same everywhere, no mental mapping!
That depends on your perspective. If you are on one OS and this non-natve-looking app comes along, you have to mentally map it for your OS so it's none-nativeness requires mapping to the OS-nativeness.
If you, on the other hand, only work "in" this application and just take it with you regardless of the OS, then you would indeed not need to mentally map the application itself. But I doubt this application is used that way in isolation.
More importantly, however, working on : OSes frequently is rare. The developer of the app does it. I, as the user, dominantly use a single OS and want apps to be standard for that OS…
Is the Podman CLI both command-compatible and flag-compatible with the Docker CLI?
If it is, or if there were a command translation layer to transform docker cli stanzas to the podman equivalent, I'd love to dump and forget about docker forever.
Please keep pushing Team Podman! Self-respecting nerds everywhere are rooting for (and counting on) you!
It is! At least 99%, in my experience. The one big difference is that Podman is "daemonless", which is actually a huge advantage in a lot of cases. The one downside is that it won't automatically restart your containers if your host machine reboots.
For that Podman provides a nifty little trick: `podman generate systemd`[0] which allows you to generate systemd unit files for your pods and/or containers.
Once generated and enabled, your pods/containers act as systemd services that can be started, stopped etc.
Even better. It”s API compatible with the docker daemon.
You can run podman-system-service and get a socket/port that you can point the official Docker CLI or any Docker library at and it will just work (tm).
I’ve run into many issues with tools when moving from docker to podman, mostly because they tried to be smart.
Some tools try to detect whether podman exists on the system or not and change their behaviour accordingly. I couldn’t get docker-compose to work properly either even though I had a socket exposed.
I would much prefer if the podman binary/cli also supported the compose command.
Then there are slight differences such as the registry that is used by default when resolving. Docker defaults to docker.io where podman asks. The same when an image is available in multiple registries.
Am not familiar with Rancher Desktop, but briefly looking at their website it has a Docker CLI dependency which surely would land it in the Docker licensing controversy space, no ?
Docker CLI and Docker engine are open source :) Docker Desktop for Windows/Mac are not. So as long as the dependency is on the open source components, AFAIK they'd be fine.
You have to explicitly invoke buildah bud with --arch and --manifest. You can then push the manifest with podman. There is slightly less magic, which is a HUGE advantage if you operate outside of the hairline Docker happy path.
I know this isn’t applicable to every use case but I recently went down the rabbit hole of cross compiling for the Pi using buildx and in my case I was able to use their 64 bit OS which was released to the general public back in Feb of this year. That one takes arm64 images no problem. Obviously no Pi’s before 2016 can use this but it solves a lot of difficulties if you aren’t absolutely requiring a cross compile and an arm64 image is available.
I keep hearing that buildx is a next-gen build tool, but I can't find what exactly it does. What features does it add over the classic `docker build` command?
I am also unsure how buildx works, however I do know that the official docker build-and-push action is not compatible with podman (despite the podman-docker pkg), solely because it uses buildx. As well, compared to buildah builds, building with buildx is much faster--at least with default flags for buildah-build-and-push vs docker-build-and-push. I can say that buildx has an additional cache that must be cleared overtime, which might be related to the build speed difference.
I've managed to push amd64/arm64 images to GitHub a while ago, but I was still using Docker proper at the time, so the registry itself should support this.
The main use case right now is that your company won't spring for a docker desktop license (and you work in a windows/mac shop).
It works well enough for single docker images, but I've never gotten it to work well with a complicated docker-compose set-up (I haven't tried in a couple months though, so go check the docs before you write it off).
The macOS Docker Desktop app (I haven’t experienced other versions) is free and works fine. The paid upgrade is only required for certain features that I would imagine many teams don’t need.
My complaint with it is that I’d prefer if there was a 100% feature-parity CLI interface so it could run in the background, and that it should be open source.
To have a low-level developer tool that’s required to be in my menubar and administered through a closed-source GUI is IMHO an insane departure from web software development norms. I use lazydocker for now but it should be an official utility that replaces the GUI app.
From what I read, the "Personal" $0 tier still has "small businesses" listed, and the little info tooltip for Docker Desktop also explicitly mentions "small businesses."
This can be found at the very bottom of that page:
> Docker Desktop can be used for free as part of a Docker Personal subscription for: small companies (fewer than 250 employees AND less than $10 million in annual revenue), personal use, education, and non-commercial open source projects.
It's possible to run podman in podman in podman in …, which is nice if you containerize the build system but don't want to pack everything into one large image nor want to divide it into stages called by some main script on the host.
Podman has an almost identical CLI to Docker, and can have a daemon that is fully Docker compatible (thus, all Docker integrations work against it including docker-compose). It is literally a drop-in replacement but it doesn't require your company to buy licenses. So yes, you should if you can.
I'm not going to attest for accuracy on the statement, but from my RHCSA training I recall that docker runs as a daemon, while podman runs containers in separate processes; so it should be easier to avoid lockup/blocking.
Readit News
- First binary for Windows, all due to amazing work of podman team
- https://github.com/containers/podman/releases/tag/v4.0.3
- First test flatpak image
- Binaries for ARM
- On Linux, easily switching between native podman and podman machine based setups
- Easily identify where settings are stored
- Debug panel and log level control to know everything that is happening
- Optimization of settings screen
- Toggle for automatically starting the podman service
[1] https://github.com/containers/podman-desktop
One remark:
> Application looks the same everywhere, no mental mapping!
That depends on your perspective. If you are on one OS and this non-natve-looking app comes along, you have to mentally map it for your OS so it's none-nativeness requires mapping to the OS-nativeness.
If you, on the other hand, only work "in" this application and just take it with you regardless of the OS, then you would indeed not need to mentally map the application itself. But I doubt this application is used that way in isolation.
More importantly, however, working on : OSes frequently is rare. The developer of the app does it. I, as the user, dominantly use a single OS and want apps to be standard for that OS…
If it is, or if there were a command translation layer to transform docker cli stanzas to the podman equivalent, I'd love to dump and forget about docker forever.
Please keep pushing Team Podman! Self-respecting nerds everywhere are rooting for (and counting on) you!
Once generated and enabled, your pods/containers act as systemd services that can be started, stopped etc.
[0]: https://docs.podman.io/en/latest/markdown/podman-generate-sy...
You can run podman-system-service and get a socket/port that you can point the official Docker CLI or any Docker library at and it will just work (tm).
Some tools try to detect whether podman exists on the system or not and change their behaviour accordingly. I couldn’t get docker-compose to work properly either even though I had a socket exposed.
I would much prefer if the podman binary/cli also supported the compose command.
Then there are slight differences such as the registry that is used by default when resolving. Docker defaults to docker.io where podman asks. The same when an image is available in multiple registries.
Am not familiar with Rancher Desktop, but briefly looking at their website it has a Docker CLI dependency which surely would land it in the Docker licensing controversy space, no ?
Docker cli is still fair game.
Deleted Comment
- Both docker and podman support rootless containers.
- Rootless podman setup is easier to achieve from experience and it integrates well enough with systemd.
- Docker requires a daemon to run at all times whereas podman doesn't.
- A lot of interesting things are going on with podman ("native" gitlab-runner executor in the works, wsl2 support, among other things)
It works well enough for single docker images, but I've never gotten it to work well with a complicated docker-compose set-up (I haven't tried in a couple months though, so go check the docs before you write it off).
My complaint with it is that I’d prefer if there was a 100% feature-parity CLI interface so it could run in the background, and that it should be open source.
To have a low-level developer tool that’s required to be in my menubar and administered through a closed-source GUI is IMHO an insane departure from web software development norms. I use lazydocker for now but it should be an official utility that replaces the GUI app.
This changed in the last year, previously docker was free to use personally or at non enterprise scale work/office.
This can be found at the very bottom of that page:
> Docker Desktop can be used for free as part of a Docker Personal subscription for: small companies (fewer than 250 employees AND less than $10 million in annual revenue), personal use, education, and non-commercial open source projects.
Podman has an almost identical CLI to Docker, and can have a daemon that is fully Docker compatible (thus, all Docker integrations work against it including docker-compose). It is literally a drop-in replacement but it doesn't require your company to buy licenses. So yes, you should if you can.
https://github.com/containers/podman-tui
https://dev.to/mrstardom/how-to-run-podman-on-windows-subsys...
https://dev.to/thangchung/start-podman-on-wsl2-in-4-steps-3j...