Podman Desktop 1.2 Released: Compose and Kubernetes Support
podman-desktop.io
podman-desktop.io
Very much unlike Kubernetes, where even a small deployment can sometimes be maddening to debug. Great for larger deployments where complexity is basically guaranteed, but anything that could run on one server with a hot spare is a great fit for Compose!
It almost necessitates deeper monitoring and/or extra tools to give a dashboard/'single pane of glass', whereas I can run Compose and just log into the individual server and jump around logs.
Sidecars do not exist in kubernetes, unless you install something that adds them.
Containers are... containers? The same containers you'd see in docker.
Kubernetes does not need deeper monitoring compared to docker. You can jump around kubernetes logs just like you do with docker. Except you don't even need to log into individual server.
I don't use any kind of dashboard for my kubernetes cluster. I installed kubernetes-dashboard, so developers and managers can enjoy their dashboards but I've found no value with it. kubectl is more than enough.
Ingress is also more complicated/bespoke - the best I've found is traefik with labels for routing/config.
My advice today would be to scale Docker compose vertically (eg: on a dedicated server) - then move to Kubernetes.
The swarm middle ground isn't really worth it IMNHO.
Fwiw I found swarm lovely and just so much easier to work with than anything else solving the same problems.
For a new app, one generally should and can embrace 12-facors, and delegate state to stateful services (managed databases, key-value stores, s3 etc).
Do note that for simple services, local disk can be very hard to beat for low complexity, extremely high performance - with the caveat that horizontal scaling might be tricky.
Ed: also depending on privacy requirements - self- hosted s3 (eg minio) might be tricky for a production load. OTOH self-hosted Kubernetes is no walk in the park either!
One way round that is to use an NFS volume. However, I've hit problems with too many client NFS connections on a docker swarm and so found it better to mount the NFS volume on each host and use a bind mount instead.
Also the volume plugin spec is so simple that it is possible to maintain your own plugin (even without csi).
Ultimately, I would love for something to exist out there that had the opinions and scope of deployment like Swarm in terms of simplicity, but didn't conflate other tools out there so that ergonomics and documentation were better and less confusing. Kubernetes gives you so much, but I do feel like it's a misstep that the only reasonable way we've simplified Kubernetes for production workflows is to pay a large PaaS to manage it for us.
I will say Kubernetes being as open as it is and all the overlapping tooling would seem incredibly overwhelming for someone trying to enter that space.
the inevitable "you could have used something simpler than Kubernetes!" comments that appear every time it's mentioned neglect to note that you're more likely to find a Kubernetes example for whatever you're doing readily available in the wild.
The A and B group can be implemented with docker compose and deployed to each cluster with pulumi/Terraform. Two or a hundred, it doesn't really matter how many cluster groupings you have.
However with Kubernetes your infrastructure will be ready to scale. You need to expose both front-end and back-end services under the same host? No need to tinker with nginx configs, you just create two ingresses and do it in a standardized way. You need to run your service with two replicas and rolling zero-downtime update? Kubernetes has it out of the box. Good luck implementing all the necessary dances with custom docker-compose setup without dropped requests. You want to customize healthcheck? Kubernetes got you covered with all the imaginable scenarios.
The only missing block in Kubernetes is support for building containers. This is implemented with docker-compose extremely elegantly and simple. That I admit.
That is true if you already have Kubernetes. If you don't, then you still need to run and configure the Kubernetes' control plane (e.g. kube-apiserver, etcd, scheduler, etc). Doing that alone may exceed the complexity of a simple setup.
I say this as someone who has looked at Kubernetes a lot and wanted to use it, but could never justify it. I have concluded multiple times that docker compose is a better fit for my use case.
> However with Kubernetes your infrastructure will be ready to scale.
True, but for many purposes you aren't gonna need it.
I hope you're not putting something like that in production.
Every time you hear yourself saying Kubernetes, "only", and "just" on the same sentence, please pause for a moment.
This Cult of Kubernetes has to go.
90% of the projects won't need scale. You're paying forward for something you won't use most of the time.
Speaking as a k8s admin.
"Simple setups" in Kubernetes will have massive amounts of complexity and overhead, they're just buried in a different abstraction layer.
If you have "free" k8s and don't need to touch it operationally? Sure, do everything with it!
But somebody is going to have to run that k8s environment. If it's you, and you're not a k8s expert, then you'd better buckle up, because all that hidden complexity is now your problem.
In the world where you need to deploy "an app" to "a VM", the simplicity of docker-compose is a sweet spot that any developer can grok without needing an encyclopedic knowledge of how to manage it.
Yup thanks for noticing, that's why I use it
https://github.com/operator-framework/awesome-operators archived since 2021 and now https://operatorhub.io/
I hadn't heard of this, interesting. Layers and layers of abstractions. What an interesting way to solve things. "It's YAML all the way down"?
- Prometheus operator
Lets us spin up a prometheus monitoring stack on our kubernetes cluster for monitoring metrics and scraping metrics from our services pretty much automatically.
- Thanos Operator
Spins up prometheus monitoring aggregations across multiple clusters with object storage backends, basically you can store metrics for years and query them with grafana.
- Strimzi Operator (Kafka)
Orchestrates a kafka cluster for kafka connect or even full blown kafka brokers with zookeeper.
- Istio Operator
Builds a service mesh on the cluster, offering MTLS and an envoy load balancer with some incredible flexibility
- Cert-manager operator
Lets us auto-generate certificates for resources via letsencrypt. This one is so nice for internal services and keeps certs valid without any hand holding
- Argo CD operator
We use this operator to deploy argocd pipelines and ship new services and updates via github actions in a very standardized way, and gives our users a UI to see what's going on.
- Actions runner controller
Using this actions runner controller we can offload github actions runners to self-hosted runners that automatically scale for pipeline workloads. Another set up and forget system and saves us from buying more github actions minutes.
Ultimately we use a ton of operators because it gives us an out of the box framework for tooling we need to deploy without reinventing the wheel. Of course some operators aren't worth using and it's definitely worth checking them out to see if they worth your time. A lot of them are really open to updates and changes also so you can help evolve them as you grow into other cases.
I will say, it's very important to understand what you are abstracting with these, you can absolutely blindly deploy services with operators and have it blow up in your face if you aren't sure what's going on behind the scenes or lack distributed service knowledge in production.
Initially the main advantage it had over Docker was rootless mode, but this has been available in Docker for a while now. What currently sets Podman (Desktop/Compose) apart from its Docker counterparts?
I've also run into issues running some containers with Podman that work fine with Docker. I still use it for some simple use cases, but I'm wondering more why bother with a copycat product that only plays catch-up to Docker, and has its own set of issues. And, incidentally, is run by Red Hat, and by extension IBM, which are increasingly hostile to OSS.
For example, Deno (https://deno.land/) initially launched with precarious compatiliblity with Node.js, but eventually had to make compromises and adapt so Node.js projects could migrate easier.
Do you like having to have a daemon running? I don’t.
Also, the “pod” in the name may yield a few hints.
Finally, despite all the recent and undeserved hate, I know that Red Hat will keep their source open. I have no such faith in Docker.
Have you priced out Docker Desktop and Podman Desktop lately?
And we have yet to see if that ends up being the right call. These things are always really tough. On the one hand, compatibility with existing stuff makes migration easier, but then if it's not actually different enough, we have no reason to change to the new thing.
It has tons of features, but people don't pay attention to them due to the Docker being the lowest common denominator.
For example, there is absolutely no need for Compose. You create a pod and all the containers in it. You can then ask podman to generate all the systemd units for it.
I am also very worried about the IBM issue though, I wonder how long it will be until they slay this golden goose.
Someone else has already mentioned built in pod support, plus you can generate kube files from existing pods for easy deployment.
So you end up with this nice progression of managing:
1. one-off/short term containers with podman run
2. longer running containers with podman generated systemd units
3. generation deployment of above long running containers with Quadlet
4. pods and more complicated setups on one machine with kube files
5. pods and more complicated setups across multiple machines with kubernetes
Which is a really nice stack to work with since they all use the same toolbox.
And that's outside of other small features like not having to worry about the docker package updating restarting the daemon and taking it all down, socket activation (through systemd units), and auto-updates.
[0] https://docs.podman.io/en/latest/markdown/podman-generate-sy... [1] https://docs.podman.io/en/latest/markdown/podman-systemd.uni...
Have you tried running with Pods? Have you tried Quadlet? Have you tried to generate kube yaml from running pods and containers on your system? Have you used podman to generate pods and containers from existing kubernetes yaml files? Have you launched containers each in their own User Namespace with --userns=auto?
> Podman Desktop quit unexpectedly.
I was about to ask whether it works on macOS yet. I guess I've got my answer.
How does it work? Why is it fast?
OrbStack uses a lightweight Linux virtual machine with tightly-integrated, purpose-built services and networking written in a mix of Swift, Go, Rust, and C. See Architecture for more details.
It's a very interesting product, it does use a VM, but seems to have some "special sauce" code to improve the speed of things. It also says it shares the kernel among multiple VMs. Very cool stuff.
I found there is not much diffence in performance between both on my intel macbook.
I think it will not take long until rancher also updates to latest lima to support apple virtualization. but I haven't checked the latest release notes.
For simplicity, the tooling often tries to make this simple and transparent to use.
https://docs.docker.com/desktop/faqs/linuxfaqs/#why-does-doc...
1. You only have to deal with one Linux distro in the VM. Managing things across many distros can be difficult at that level.
2. There are times you want to blow away your environment. Can't do this if things running on the host.
3. You'll want to controll the resources your workloads uses so they don't make the Linux desktop unresponsive. VMs provide that level of separation.
I could go on but you get the point. If you're a power user who wants it on the host you can do that. For the masses of this kind of product, a VM has a lot of advantages.
I could never get bind mounts working consistently, relying instead on volumes, which are more awkward/less explicit when persisting local DBs used when testing.
I've had zero problems with Rancher Desktop + dockerd - definitely recommend it for M1 users that are having issues with podman.
What type of problems were you seeing? Was it with podman or through podman desktop, and possibly some issue with what it was attempting?
bind mounts are a pretty standard kernel feature, so I'm wondering how podman/podman desktop could have been screwing it up, unless it was some user level permissions thing.
FWIW, it could simply be chalked up to M1 weirdness. We have an ongoing list of various workarounds for the M1, whereas those using Intel MacBooks seem to be mostly fine.
Just like how a shell script is easier to manage than stringing lots of commands in the terminal, defining services in yaml is easier to manage than adding a million flags to your docker commands.
Of course at a certain point you may need further abstractions, but I agree with you that these should only be used if they're actually needed.
If you want to run a container, just run the container? K8s is here for scaling, not for running stuff in local.
Antd or MUI (React) feel much more mature.
But they are working on it.
(Although honestly most of the time I'm using Podman it's on native Linux, so I don't use 99% of the stuff that's there anyway.)
Disclaimer, I started Rancher Desktop.
I mean... if you're going to say nothing at all, no need to announce it...
Lazydocker is awesome, though. Thanks for introducing it to me. I just installed it and I'm loving it. I've used Portainer in the past, but didn't like it enough to leave it running continuously.
As far as Vagrant being faster than Docker, it's possible the qemu backend it uses was hardware accelerated and for whatever reason the Docker VM wasn't? Or perhaps you were using Docker Desktop which does take up a lot of compute capacity away? Try using the docker cli without docker desktop and see if it works better for you.
WSL2 even supports running Linux GUI applications and GPU passthrough.
I think the support for Linux GUI applications is achieved by running an X server on the Windows side of things.
When I do `podman ps` my client connects to my development VM that is not managed by podman, but I can't seem to find a way to make Podman Desktop do that.
That command will let you manage what instance the podman cli is connecting to
https://docs.podman.io/en/latest/markdown/podman-system-conn...
Compose, "the binary" [1]. It used to be "just" a Python helper script that called Docker, used to deploy multiple containers in a common network easily. It was rewrited in Go, and now it's kind of a plugin for Docker. I think it's strongly tied to Docker primitives, and wouldn't be that easy to modify it to work on different container orchestrators.
But there's also Compose "the file format" [2]. There are tools, like Kompose[3], that understand the Compose format, and can use it to deploy in Kubernetes.
1: https://github.com/docker/compose
2: https://compose-spec.io/
3: https://kompose.io/