Earlier quoted context omitted.
For me, I really enjoy how basic it is. I’ve never missed any of these things for my simple single-host scenarios.
Simple setups will be as simple with Kubernetes. 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…
Podman Desktop 1.2 Released: Compose and Kubernetes Support
71–80 of 132 posts
Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support
#72Earlier quoted context omitted.
For me, I really enjoy how basic it is. I’ve never missed any of these things for my simple single-host scenarios.
Simple setups will be as simple with Kubernetes. 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…
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.
Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support
#73Earlier quoted context omitted.
Docker network effect is too important to ignore. That would be like swimming against the current. 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.
All of that can be accomplished by being compatible with the broader OCI ecosystem. But Red Hat explicitly tries to be a Docker replacement (they suggest `alias docker=podman`, which actually breaks in many ways), to the point where I'm not sure why I should bother using a product that will always play catch-up to the real thing. This Desktop and Compose announcement is part of that roadmap, and I'm just wondering wh…
Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support
#74Earlier quoted context omitted.
For me, I really enjoy how basic it is. I’ve never missed any of these things for my simple single-host scenarios.
Simple setups will be as simple with Kubernetes. 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…
This Cult of Kubernetes has to go.
Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support
#75Earlier quoted context omitted.
Docker swarm is supposed to be the migration target for these cases, but I’ve never actually used it.
Swarm works, but has poor support for volumes - which means it's tricky to run legacy applications on swarm (which eg uploads files to local disk, not s3 - or keeps state/cache on disk, not a database). 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 Kubernet…
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.
Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support
#76I'm very happy to see you better support for docker compose. I think about 50% of the time I find Kubernetes used in production/development when it could have just used Compose along with a simple Terraform or Pulumi deploy script.
Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support
#77Earlier quoted context omitted.
For me, I really enjoy how basic it is. I’ve never missed any of these things for my simple single-host scenarios.
Simple setups will be as simple with Kubernetes. 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…
Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support
#78Earlier quoted context omitted.
Simple setups will be as simple with Kubernetes. 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…
> Simple setups will be as simple with Kubernetes. 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…
Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support
#79Why does Compose still only work on one server? I am perpetually perplexed that nobody has patched Compose to manage k8s resources, have its own multi-node support, or push Swarm more. How has nobody fixed this? The tool is 9 years old.
Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support
#80Earlier quoted context omitted.
Docker compose falls apart when you need something clustered across nodes or any other multi-host deployment. Once you have to rip it apart it becomes way less appealing. Though I haven't tried it in a while and perhaps the ergonomics have changed.
Docker swarm is supposed to be the migration target for these cases, but I’ve never actually used it.
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.