Podman Desktop 1.6 released: Even more Kubernetes and Containers features
podman-desktop.io
podman-desktop.io
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.
There has to be some attempt at this right?
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
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.
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
[1] https://github.com/companyinfo/helm-charts/tree/main/charts/...
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.
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-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.
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.
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!
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.
> 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?
Podman Desktop also offers to set the socket emulation and Docker compatibility up for you, if you like.
podman-compose[1] replaces docker-compose.
[1] https://docs.podman.io/en/latest/markdown/podman-compose.1.h...
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.
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
Btw, I also use Compose, but for local runs (of other apps).
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...
* 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.
#!/bin/sh
exec podman "$@"
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...
"runArgs": [
"--userns=keep-id",
"--volume=${localWorkspaceFolder}:/workspaces/${localWorkspaceFolderBasename}:Z"
],
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?
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
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?
Colima works pretty well, and documenting a reproducible setup is easy.
If I were willing to spend my own money, I'd pick OrbStack.
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.
Maybe I'll remember to post back here about whether that works. :)
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.
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).
I wish more efforts were spent getting better integration with KinD clusters as they're much easier to spinup and work with.
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?
Also, Windows containers do matter in some environments, and they are exposed via the Docker APIs.
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.
Source: https://docs.podman.io/en/latest/markdown/podman-machine-ini...
The website makes some big claims.
EDIT: why the downvotes?