Podman Desktop 1.6 released: Even more Kubernetes and Containers features(podman-desktop.io)
podman-desktop.io
Podman Desktop 1.6 released: Even more Kubernetes and Containers features
https://podman-desktop.io/blog/podman-desktop-release-1.6
82 comments
You can actually use podman as a backend for docker-compose
If you install docker-compose, podman and enable the podman service, it does work quite well.
If you also install podman-docker you basically can run: `docker-compose`, `docker compose` or `podman compose`, all three will leverage podman in the backend.
I use it with podman rootless and I'm quite happy with it.
If you install docker-compose, podman and enable the podman service, it does work quite well.
If you also install podman-docker you basically can run: `docker-compose`, `docker compose` or `podman compose`, all three will leverage podman in the backend.
I use it with podman rootless and I'm quite happy with it.
I wasn't able to get podman + docker compose working after they upgraded docker-compose from Python to Go. Does everything work for you with the newest versions?
All good now, it was an issue for a bit indeed.
The only thing not compatible that I know off is buildkit so you have to make sure it's disabled, they do seem to plan to implement buildkit APIs but it's not done yet
The only thing not compatible that I know off is buildkit so you have to make sure it's disabled, they do seem to plan to implement buildkit APIs but it's not done yet
Is docker-compose python version still supported? I thought they moved everything to docker and rewrote in Go.
Not sure if the python version is still supported, i'm using the v2 (go based)
Genuine question: I'm curious to know why you deploy with docker-compose and not Docker swarm (eg like described at https://dockerswarm.rocks/ ). I'm deploying the same kind of apps, and ended up with Swarm which seems to fit perfectly. I also found Kubernetes much too complex for my use case. Curious to know why we ended up with different outcomes.
Btw, I also use Compose, but for local runs (of other apps).
Btw, I also use Compose, but for local runs (of other apps).
Nobody uses Swarm. Everyone understands compose, all projects ship with compose files.
Swarm reuses docker compose files...
By looking at HN activity on docker swarm, I can see many good comments: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
By looking at HN activity on docker swarm, I can see many good comments: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
Docker Swarm uses compose files too.
Swarm is still used and maintained, though I agree it is much smaller than k8s.
But that's not a reason to dismiss it I think. I went for it because it's so easy to use that if I need to migrate off of it, I would not loose a lot of investment in it anyway.
Do they? I have never actually seen that. Do you have examples?
I'm sure swarm would work for what I need and rationally its probably worth using, but I only trust docker as far as I could throw them and if I needed to really deploy I would probably just suck it up and figure out k8s.
I'm not sure how podman fits into this thought but I feel what's needed to make kubernetes as easy to use as docker-compose is a bunch of sane defaults for things that you mostly don't want to care about for smaller projects. And then maybe an option to easily "eject" the configuration when the project grows.
There has to be some attempt at this right?
There has to be some attempt at this right?
I would recommend https://www.devspace.sh
I use for just about everything.
It also works well as a good gateway into the kubernetes world when coming from docker compose.
We're trying to do this at Kurtosis! (https://github.com/kurtosis-tech/kurtosis)
The idea is to write your environment in Starlark (a minimal Python subset) and we'll handle running it on Docker or Kubernetes for you.
We started with "reduce Kubernetes complexity" so we don't yet have the full Kubernetes ejection seat, but we're slowly marching towards it - feedback welcome!
The idea is to write your environment in Starlark (a minimal Python subset) and we'll handle running it on Docker or Kubernetes for you.
We started with "reduce Kubernetes complexity" so we don't yet have the full Kubernetes ejection seat, but we're slowly marching towards it - feedback welcome!
Can you clarify what's hard about using kubernetes for smaller projects and what do you want to omit?
It's been a while but iirc my primary issues weren't about configuring a small project, it was the effort of setting up and administering a k8s cluster that was the problem.
With docker-compose you realize you need a persistent volume and go "volumes: ..." and you're good.
With your own k8s cluster you go, "okay I need a persistentVolumeClaim to a PersistentVolume with a particular StorageClass that my cluster needs to offer". Then you go learn the "Right Way" to set up a StorageClass and 2 hours later you finally have a persistent volume. Repeat every time you try to do something that would be one line in a docker-compose file.
If you have easy access to an administered k8s cluster then kubernetes becomes way more approachable. What would be ideal for me is an offering that presents itself as a batteries included k8s cluster running on your local machine. That way I could make pod definitions and run them without having to understand k8s internals while gaining the option of deploying on a real cluster in the future.
With docker-compose you realize you need a persistent volume and go "volumes: ..." and you're good.
With your own k8s cluster you go, "okay I need a persistentVolumeClaim to a PersistentVolume with a particular StorageClass that my cluster needs to offer". Then you go learn the "Right Way" to set up a StorageClass and 2 hours later you finally have a persistent volume. Repeat every time you try to do something that would be one line in a docker-compose file.
If you have easy access to an administered k8s cluster then kubernetes becomes way more approachable. What would be ideal for me is an offering that presents itself as a batteries included k8s cluster running on your local machine. That way I could make pod definitions and run them without having to understand k8s internals while gaining the option of deploying on a real cluster in the future.
Setting up kubernetes is easy with kubeadm. There are other distros like k3s, but I don't have personal experience with them.
For storage, just use hostpath volume and that's about it. You don't need to deal with PersistentVolumes at all. I never used named docker volumes, honestly, and I don't understand why they're useful, I always prefer to explicitly specify disk location, so I can back it up, etc. PersistentVolumes are useful, when you have separate storage system and full-fledged multi-node cluster, but for simple setup, there's nothing wrong with hostpath volume, IMO. Just don't forget about backups.
For storage, just use hostpath volume and that's about it. You don't need to deal with PersistentVolumes at all. I never used named docker volumes, honestly, and I don't understand why they're useful, I always prefer to explicitly specify disk location, so I can back it up, etc. PersistentVolumes are useful, when you have separate storage system and full-fledged multi-node cluster, but for simple setup, there's nothing wrong with hostpath volume, IMO. Just don't forget about backups.
helm + go-templating in YAML is pure madness.
I've found k8s more manageable with straight manifests, or tooling to generate the manifests from some other source.
I do need to give jsonnet a hard look, as I hear it's less crazy than yaml+templates
I've found k8s more manageable with straight manifests, or tooling to generate the manifests from some other source.
I do need to give jsonnet a hard look, as I hear it's less crazy than yaml+templates
There's a number of solutions. One is to use a maintained Helm Library Chart that exposes all the values most could ever want like The Helmet [1]. The other is to move over to something like Timoni that is analogous to Helm but with better templating [2].
[1] https://github.com/companyinfo/helm-charts/tree/main/charts/...
[2] https://timoni.sh/comparison/
[1] https://github.com/companyinfo/helm-charts/tree/main/charts/...
[2] https://timoni.sh/comparison/
You definitely don't have to use helm and go-templating for small projects. I never used it (other than from the user side to install 3-rd party software). Just ordinary yamls is absolutely fine. Kustomize might be useful for configmaps and secrets, but that's a small layer of complexity.
What I want to try to generate yamls is to write typescript code. Emitting JSON is natural in typescript. Adding types for schema compliance is doable. And then you've got full typescript power on top of it to remove any kind of duplication.
What I want to try to generate yamls is to write typescript code. Emitting JSON is natural in typescript. Adding types for schema compliance is doable. And then you've got full typescript power on top of it to remove any kind of duplication.
I agree with that approach, and it's one I want to try as well. I'm an old Perl guy, but the transition to being a JS/TS native to use modern interfaces + toolings has proven a pretty straightforward path, especially with nodejs systems side for scripts and what not.
The 'declarative' nature of YAML + configuration for defining infrastructure is definitely a good thing, but the tooling for producing those declarations are in a very rough state. I think a "TS => YAML => git => deploy" workflow for deployments could make using K8S a breeze, especially if there is a sensible library in TS that could provide the base classes for manifests, that could be subclassed or wrapped with defaults + definitions for the local environment
The 'declarative' nature of YAML + configuration for defining infrastructure is definitely a good thing, but the tooling for producing those declarations are in a very rough state. I think a "TS => YAML => git => deploy" workflow for deployments could make using K8S a breeze, especially if there is a sensible library in TS that could provide the base classes for manifests, that could be subclassed or wrapped with defaults + definitions for the local environment
Sounds like cdk8s+
https://cdk8s.io/docs/latest/plus/
https://cdk8s.io/docs/latest/plus/
Thanks for that pointer, that does look excellent
Perhaps I'm biased by working on mostly big projects. I haven't tried a very small project recently so I might be on thin ice.
The thing that I would expect would be a bit complicated in a small project is networking rules, load balancing, mounting directory from host. That kind of thing.
The thing that I would expect would be a bit complicated in a small project is networking rules, load balancing, mounting directory from host. That kind of thing.
Kubernetes networking requires installing CNI plugin. Something simple like flannel will work fine and does not require any configuration. That's the only required addon for kubernetes, I think.
With docker you'll probably bind container port to the host. With kubernetes you can create Service of type NodePort and it's exactly the same.
Load balancing: I'm not really sure what do you mean, what do you use for docker load balancing? Just expose your kubernetes host to the Internet and that's about it. Or hide it behind separate reverse proxy, if you want.
Mounting directory from the host is supported with kubernetes, no problems here. Use hostPath volume in the pod spec.
With docker you'll probably bind container port to the host. With kubernetes you can create Service of type NodePort and it's exactly the same.
Load balancing: I'm not really sure what do you mean, what do you use for docker load balancing? Just expose your kubernetes host to the Internet and that's about it. Or hide it behind separate reverse proxy, if you want.
Mounting directory from the host is supported with kubernetes, no problems here. Use hostPath volume in the pod spec.
Besides CNI networking potentially encompasses Services, Endpoints/Slices, Load Balancers, Ingresses and most recently the Gateway API. I'd say that's quite a bit complex.
Kubernetes allows you to make complex networking, which is especially useful for cluster setups involving multiple nodes. But if you're comparing kubernetes with docker, docker does not have load balancers, ingresses, so you can just skip it, if you feel that it's too much of complexity. They're not mandatory.
k8s is a kit of (very useful) parts imho. The abstractions it presents are not human-usable. It needs some layer that adapts concepts that make intuitive sense to a human to its internal model. e.g. Vercel. You can make a tool for example that will deploy compose files onto a k8s cluster, and that thing will be totally useable by someone who already understands k8s. But give them raw k8s and they will spend a month scratching their head.
Abstractions are absolutely human-usable. My only issue is overly verbose yamls, but some people might even find it a good thing.
Are you talking about pods/deployments/etc or lower level abstractions like informers and things like that?
My podman installations (Mac, Fedora) both ship the compose subcommand which works as expected. See https://podman-desktop.io/docs/compose
This article describes using podman with a pod containing multiple containers.
https://www.redhat.com/sysadmin/compose-podman-pods
https://www.redhat.com/sysadmin/compose-podman-pods
podman can't replace docker-compose. it can only replace docker. if you install podman-docker any docker command you run will be translated to a podman command. I think that should work when you run docker-compose as well.
podman works great with docker-compose through the docker socket emulation.
I just use the upstream vanilla docker-compose with it (also works with docker compose as a plugin for Docker CLI).
Podman Desktop also offers to set the socket emulation and Docker compatibility up for you, if you like.
Podman Desktop also offers to set the socket emulation and Docker compatibility up for you, if you like.
It's not quite enough. You also have to run a server too - docker-compose won't run without a docker service running.
podman-compose will and it behaves more or less the same way but it's quite a neglected piece of software - lots of bugs, lots of open PRs.
A lot of people talk about quadlets or k8s as alternatives but I don't think these are generally good substitutes for compose.
podman-compose will and it behaves more or less the same way but it's quite a neglected piece of software - lots of bugs, lots of open PRs.
A lot of people talk about quadlets or k8s as alternatives but I don't think these are generally good substitutes for compose.
If your distro is relatively recent, enable podman.socket (available as system and user unit) and things should just work as they do with docker. You may have to set CONTAINER_HOST though, and the new Docker CLI has the concept of contexts where you need to point the CLI at the right socket, but confusingly using docker as a library does not automatically add contexts as functionality, so Tools like flyctl (from fly.io) and melange (chainguard's APK builder) may still need CONTAINER_HOST anyway...
can you please clarify, from technical perspective
> enable podman.socket (available as system and user unit)
Won't it make podman be daemon then if it'd be activated by socket?
Won't such a daemon be run as root then to be able to handle creation of networks/ports forwardings/multiple-users?
> enable podman.socket (available as system and user unit)
Won't it make podman be daemon then if it'd be activated by socket?
Won't such a daemon be run as root then to be able to handle creation of networks/ports forwardings/multiple-users?
As I said, there's a user unit (systemctl --user status podman.socket) that will run rootless just like using the podman CLI without elevation.
> podman can't replace docker-compose.
podman-compose[1] replaces docker-compose.
[1] https://docs.podman.io/en/latest/markdown/podman-compose.1.h...
podman-compose[1] replaces docker-compose.
[1] https://docs.podman.io/en/latest/markdown/podman-compose.1.h...
I like to develop with VS Code and devcontainers. I've never been able to get that setup to work with podman as the backend. Has anyone successfully done this or perhaps know of a blog detailing how to accomplish this that I haven't been able to find?
Yes, I have docker as an alias to root podman and VS Code is able to build a devcontainer with it. Rootless also works but was a lot slower for me. There are a couple of minor incompatibilities I've noticed in other areas:
* Podman doesn't have a unix socket like /var/run/docker.sock but it can be set up with podman-system-service if needed.
* Some applications check if /.dockerenv exists. They shouldn't, but you can just touch a file there to work around it.
* Podman doesn't have a unix socket like /var/run/docker.sock but it can be set up with podman-system-service if needed.
* Some applications check if /.dockerenv exists. They shouldn't, but you can just touch a file there to work around it.
I think I did at one point. Podman is 1:1 compatible with the docker CLI. I _think_ VSCode had an option to specify the docker command, in which case you can simply `podman` into it. Alternatively, if that doesn't then you can always put this script in your path as `docker`:
#!/bin/sh
exec podman "$@"
Podman as a devcontainers engine doesn't currently work rootlessly (the default) if you use devcontainer features [1] or (and this sounds like you're issue) if you use WSL2.
I haven't submitted the WSL2 issue to the Podman team yet. If you get to it before I do, can you link it here?
I've worked around the features bug by just using `devbox generate devcontainer` then adding all my desired container apps and services inside a `devbox.json` file.
[1] https://github.com/containers/podman/issues/18691#issuecomme...
I haven't submitted the WSL2 issue to the Podman team yet. If you get to it before I do, can you link it here?
I've worked around the features bug by just using `devbox generate devcontainer` then adding all my desired container apps and services inside a `devbox.json` file.
[1] https://github.com/containers/podman/issues/18691#issuecomme...
VS Code devcontainers have been working fine for me with rootless podman in Fedora for over a year now. The one adjustment I had to make was manually provide args to podman to mount the workspace volume:
"runArgs": [
"--userns=keep-id",
"--volume=${localWorkspaceFolder}:/workspaces/${localWorkspaceFolderBasename}:Z"
],
I've been using VSCode with devcontainers and podman for a couple of months now and everything seems to work fine for me. Is there a particular issue you're hitting?
Honestly, it's been a long time; I should probably just try again. The last attempt I made was on windows before WSL2 existed. At the time I assumed the issue was with podman on HyperV/WSL.
If everything else fails, you can always run code-server inside a podman container.
Just recently set up Podman Desktop on Mac for work (on my old computer, I'd used Rancher Desktop on Windows).
Getting everything installed was a little bit annoying, since I use a nonstandard Homebrew prefix, and Homebrew doesn't currently provide a 'cask' for the pre-built Podman binaries. That means that `brew install --cask podman-desktop` requires building a bunch of things from source for me. But writing one wasn't hard, and the install process was good after that.
One issue I seem to have consistently though is that the VM `podman machine` uses hangs. I haven't investigated it, but I think it might hang every time my laptop sleeps, because it's most often hung when I come back to my computer in the mornings, and that seems so damn near every time.
Anyone else have this problem on macOS?
Getting everything installed was a little bit annoying, since I use a nonstandard Homebrew prefix, and Homebrew doesn't currently provide a 'cask' for the pre-built Podman binaries. That means that `brew install --cask podman-desktop` requires building a bunch of things from source for me. But writing one wasn't hard, and the install process was good after that.
One issue I seem to have consistently though is that the VM `podman machine` uses hangs. I haven't investigated it, but I think it might hang every time my laptop sleeps, because it's most often hung when I come back to my computer in the mornings, and that seems so damn near every time.
Anyone else have this problem on macOS?
Correct me if I'm wrong, but I feel like podman is by and for linux devs. Once you move to Mac or Windows, you give up podman's main benefit of running containers without a daemon since you're still having to run a VM.
It's for folks who deploy to Linux. In the most recent case, I just needed it to mirror some images from DockerHub to an Amazon ECR.
Not having a Linux box for a dev machine, I'd have to involve one somewhere, and it'd either be a local VM or a remote one.
In my case, the main benefit of running Podman is not versus Docker. I don't want to run Docker Desktop because of its licensing. Podman doesn't have to offer me a technological benefit that Docker doesn't, at least for development use cases.
For development use cases like devcontainers, I agree, though. For that kind of stuff on macOS, I use Nix instead of a VM-based solution like Podman Desktop or Docker for Mac or whatever.
Not having a Linux box for a dev machine, I'd have to involve one somewhere, and it'd either be a local VM or a remote one.
In my case, the main benefit of running Podman is not versus Docker. I don't want to run Docker Desktop because of its licensing. Podman doesn't have to offer me a technological benefit that Docker doesn't, at least for development use cases.
For development use cases like devcontainers, I agree, though. For that kind of stuff on macOS, I use Nix instead of a VM-based solution like Podman Desktop or Docker for Mac or whatever.
I was hoping not to read your comment because thats the reason why i stoped playing around with podman.
The frustration of the background VM having some issues on my mac made me switch to paid docker again. I don't have the time to play around with something which i need for work and costs 10$ per month.
And i do prefer opensource
The frustration of the background VM having some issues on my mac made me switch to paid docker again. I don't have the time to play around with something which i need for work and costs 10$ per month.
And i do prefer opensource
My employer stopped paying for Docker Desktop licenses but I never really understood the appeal in the first place, we definitely faced some issues with our enterprise setup (proxy and registry mirrors, nothing out of the ordinary for a big company).
Colima works pretty well, and documenting a reproducible setup is easy.
If I were willing to spend my own money, I'd pick OrbStack.
Colima works pretty well, and documenting a reproducible setup is easy.
If I were willing to spend my own money, I'd pick OrbStack.
It looks like this might be the issue:
https://gitlab.com/qemu-project/qemu/-/issues/334
I wouldn't think that qemu would be associated with a display in the required way here, but maybe being launched by a GUI app that's not a terminal emulator is somehow enough?
Related bug affecting Lima (blocked by this one): https://github.com/lima-vm/lima/issues/2
This is the first I'd heard of 'app nap'. I guess macOS does iOS things and actively freezes apps it thinks are idle.
Maybe it has to do this to get passable battery life during sleep, now that Macs don't actually sleep (S3) anymore?
https://gitlab.com/qemu-project/qemu/-/issues/334
I wouldn't think that qemu would be associated with a display in the required way here, but maybe being launched by a GUI app that's not a terminal emulator is somehow enough?
Related bug affecting Lima (blocked by this one): https://github.com/lima-vm/lima/issues/2
This is the first I'd heard of 'app nap'. I guess macOS does iOS things and actively freezes apps it thinks are idle.
Maybe it has to do this to get passable battery life during sleep, now that Macs don't actually sleep (S3) anymore?
Regularly - including at random times not related to sleep. It also randomly blows away mounts on the underlying VM from time to time which means recreating the machine and any images - and every time on qemu update. There have been some very rough edges on Mac for some time now.
podman on macOS has always been a huge pain in the ass for me, but I stick with it anyway.
My podman VM also hangs after putting my M2 Mac to sleep. It's not a big deal for me to restart it in the morning, but it's just about the 1,000th papercut/bug/inconsistency I've encountered.
My podman VM also hangs after putting my M2 Mac to sleep. It's not a big deal for me to restart it in the morning, but it's just about the 1,000th papercut/bug/inconsistency I've encountered.
looks like this issue: https://github.com/containers/podman/issues/20639
I've attempted destroying my default podman-machine VM and recreating it as described in that issue, since I hadn't done that after upgrading to Podman 4.8 (incidentally, I am using the binaries from upstream, not a Homebrew build).
Maybe I'll remember to post back here about whether that works. :)
Maybe I'll remember to post back here about whether that works. :)
I'm a very happy podman user. It works really well to run amd64 containers on aarm64 thanks to qemu and it also has great modern features like rootless.
I made even podman quadlet ansible template for that (excluding x86 emulation part). It is dead simple and easy to fix.
https://github.com/Mati365/hetzner-podman-bunjs-deploy
https://github.com/Mati365/hetzner-podman-bunjs-deploy
I might look at switching our users over to Podman, considerably less bloat than Docker Desktop. Installing Docker Desktop is a PITA via MDM as it requires the user to have admin rights on first launch (unless they follow additional steps)
I did not realize a Flatpak exists (apparently for several years):
https://flathub.org/apps/io.podman_desktop.PodmanDesktop
It's an electron app, so if you're on Wayland executing like this will make it look decent: flatpak run io.podman_desktop.PodmanDesktop --enable-features=UseOzonePlatform --ozone-platform=wayland (after also enabling the wayland socket permission).
It's an electron app, so if you're on Wayland executing like this will make it look decent: flatpak run io.podman_desktop.PodmanDesktop --enable-features=UseOzonePlatform --ozone-platform=wayland (after also enabling the wayland socket permission).
Is there a method to set these flags for all Electron apps on Linux?
No, it looks like you have to do it on an application basis.
https://github.com/flatpak/flatpak/issues/2913
https://github.com/flatpak/flatpak/issues/2913
Podman is still considered experimental with KinD clusters.
I wish more efforts were spent getting better integration with KinD clusters as they're much easier to spinup and work with.
I wish more efforts were spent getting better integration with KinD clusters as they're much easier to spinup and work with.
What do you find easier to work with compared to minikube?
As for the easiness to spinup, minikube also introduced a way to spinup a cluster in a container - so it's as smooth and simple than Kind.
https://minikube.sigs.k8s.io/docs/drivers/podman/ and https://minikube.sigs.k8s.io/docs/drivers/docker/
IIRC, on windows, podman(+ docker) desktop create a Linux HyperV VM, and run the containers on that.
As a Linux native dropped into Windows, I've already been able to bring up docker, podman, k8s, and anything else in linux with more control over the linux VM I've created.
What does the 'Desktop' version of docker or podman bring to windows, that I don't already have by shelling into my on-device VM and using docker/podman tools directly?
As a Linux native dropped into Windows, I've already been able to bring up docker, podman, k8s, and anything else in linux with more control over the linux VM I've created.
What does the 'Desktop' version of docker or podman bring to windows, that I don't already have by shelling into my on-device VM and using docker/podman tools directly?
Podman on Windows creates a WSL2 distribution (`podman-machine-default` or whatever name one had picked shows up in `wsl --list` right next to other "normal" GNU/Linux distros), it doesn't create any VMs in Hyper-V sense (that show up in Get-VM or HyperV GUI tools).
So, essentially, it's an automation that sets up stuff in WSL for you, plus creates some interoperability from the Windows side such as Docker API named pipe or podman CLI. Nothing you can't do yourself, if you want to do it yourself.
Plus it bundles with those extensions like pre-setup dev Kubernetes or whatever, if you care about those.
So, essentially, it's an automation that sets up stuff in WSL for you, plus creates some interoperability from the Windows side such as Docker API named pipe or podman CLI. Nothing you can't do yourself, if you want to do it yourself.
Plus it bundles with those extensions like pre-setup dev Kubernetes or whatever, if you care about those.
We love graphical tools, and usually leave the CLI for scripting automation.
Also, Windows containers do matter in some environments, and they are exposed via the Docker APIs.
Also, Windows containers do matter in some environments, and they are exposed via the Docker APIs.
They exist for the same reason several git GUIs and Kubernetes dashboards exist.
Does it support working with a custom default system connection yet? I use podman in parallels because I get way better performance than with the qemu podman machine but podman desktop hasn’t worked with it so I stick to the cli which works seamlessly.
I can't find what the underlying OS is on the website, how do you know what version it is/how is the underlying OS updated?
"By default, the VM distribution is Fedora CoreOS except for WSL which is based on a custom Fedora image. While Fedora CoreOS upgrades come out every 14 days, the automatic update mechanism Zincata is disabled by Podman machine."
Source: https://docs.podman.io/en/latest/markdown/podman-machine-ini...
Source: https://docs.podman.io/en/latest/markdown/podman-machine-ini...
It’s an application that can run on Mac, Linux, or Windows.
They're probably talking about the Linux VM that hosts the containers.
By default it's using Fedora CoreOS.
How does OrbStack compare; anyone tried it yet?
The website makes some big claims.
https://orbstack.dev/
EDIT: why the downvotes?
The website makes some big claims.
https://orbstack.dev/
EDIT: why the downvotes?
[deleted]
I just read Podman, went on the website, saw the brew install command, opened the app and noticed it's not a podcast client.
Most of the time my docker-compose projects only need to run on one or two machines without much horizontal scaling or fault tolerance and portability/ease of spin-up are more important than high 9s edge cases.
If that's my use case should I just stick with docker-compose, or does podman simplify kubernetes config enough that its worth considering the switch? I'd like the flexibility of being able to deploy to a k8s cluster if the cost is cheap in terms of mental overhead and how easy it is for another developer to pick up and run with.