Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker's Second Death

tariqislam.com

Post reply on HN
Print view View original

131–140 of 286 posts

Re: Docker's Second Death

#131

Post by nrvn »

pydry wrote: post #99
veeti wrote: post #94

Earlier quoted context omitted.

Podman is 1:1 compatible for running hello world. Your mileage in real projects will vary.

podman in podman doesn't seem to work. that's a showstopper for a lot of work.

I had had some pretty positive experience with docker-in-docker running in podman for ci/cd until podman v2 was released. Then I started getting a lot of weird crashes and segfaults and ditched podman.

Yes, you read it correctly, running privileged docker-in-docker containers with podman to spawn docker containers in dind containers. The good thing is that networking was handled flawlessly. And there were no conflicts between docker and podman

Re: Docker's Second Death

#132

Post by nikisweeting »

nickjj wrote: post #115
hmottestad wrote: post #12

I enjoyed the following: > Though it [Docker] does live on strongly within CI/CD ecosystems and, ostensibly, the inner loop of development thanks to the de facto standard Dockerfile. Docker will still live on for both Windows and Mac developers. As a platform for running production code it might be dead or dying, but as an ecosystem and a development tool it will continue to live and probably thrive. Docker is still…

> As a platform for running production code it might be dead or dying, but as an ecosystem and a development tool it will continue to live and probably thrive. Not everyone needs an over the top Kubernetes cluster in production. I'm plenty happy using Docker Compose in production and foresee myself continuing to use it as long as Docker maintains it. There's even a WIP issue on their roadmap[0] to rewrite Docker Comp…

I second this, we've been running Docker Compose in production for years and love it. It's massively simplified our production environment, and for a company that only serves 100,000-1,000,000 monthly hits it's the perfect middle ground. We've tried k8s several times and have always ended up going back because we didn't need the complexity.

We even run compose v2.4 to retain the ability to set container memory/cpu limits and define startup order with healthchecks because we don't need the complexity of swarm and v2.4 provides everything we need. Sometimes simple is best.

I personally use compose to manage services on my own laptop and homelab as well, it just has the massive advantage of being the greatest common denominator that everyone can pick up in a few days if they're familiar with basic container concepts.

Re: Docker's Second Death

#133

Post by joana035 »

nikisweeting wrote: post #123
joana035 wrote: post #111

Earlier quoted context omitted.

> have you seen the docs on node affinity and taints? Yes, pretty neat and easy way to tag your nodes and tell where your workload will run. What is the deal?

I think you've been using it long enough that you forgot how much of a hurdle learning an extremely high-surface-area piece of tech is. The individual abstractions may be simple once you understand them in hindsight, but making an application developer that normally does not work with cluster management learn 100 new abstractions is not "easy".

Everything looks hard if you lack the fundamental knowledge.

Doesn't mean that the tool itself is complicated, and spreading propaganda is plain wrong.

Instead, I recommend to read the docs, watch videos and, most important, try it out.

Re: Docker's Second Death

#134

Post by danenania »

politelemon wrote: post #67
skrebbel wrote: post #11

I feel like I'm missing some key insight here. To me, the tl;dr of this post is: Kubernetes removed the need for Docker just to run container images in a k8s cluster, ergo, Docker is dead. But Kubernetes is super complicated . The author seems to assume that everybody wants to run everything in Kubernetes, but if I want to run some backend on some server (or maybe on a few servers), then it feels like extreme overkil…

For small-ish setups, Swarm is still great. The cost of abstraction, and cognitive load, that k8s brings is greatly played down during discussions, and I feel it's quite a dangerous game to be playing. The overhead with Swarm though, is low, and I like it. Where possible though, I'd also recommend having a look at ECS Fargate. Make it someone else's problem.

I like the Fargate model. It's far lighter and easier to work with than EKS. I haven't tried GKE so I can't speak to that comparison.

All I've ever really wanted is: "take this container with this config and auto-scale it for me".

Of course it should also be run in a private network, have blue-green deploys, auto-restart containers on failure, have geographic redundancy, etc. etc. but I don't want to have to think about any of that.

Fargate gets reasonably close to this ideal.

Re: Docker's Second Death

#135

Post by heavyset_go »

musicale wrote: post #93
raesene9 wrote: post #48

To me this article conflates the removal of a piece of legacy hard-coding (dockershim) with the overall death of Docker. That removal doesn't mean that Docker won't be used as part of Kubernetes clusters any more, Docker/Mirantis have committed to creating a CRI plugin for Docker. But realistically Docker the product is primarily a developer tool and I don't see that going away. Docker for Windows/Mac is the easiest…

> Docker for Windows/Mac is the easiest way to use containers This is depressing. Even more depressing is that macOS still doesn't seem to have native containers. (Correct me if I'm wrong - perhaps the sandboxing system can be used as a container system including virtual network interfaces attached to process groups?) Docker images depend on Linux which means "Docker" on macOS runs in a Linux VM. Presumably docker fo…

> Even more depressing is that macOS still doesn't seem to have native containers.

Docker containers are reliant on Linux cgroups, so even if macOS had its own native containers, it would need to add a Linux cgroups compatibility layer on top of it for Docker to work natively.

Re: Docker's Second Death

#136

Post by GordonS »

nickjj wrote: post #115
hmottestad wrote: post #12

I enjoyed the following: > Though it [Docker] does live on strongly within CI/CD ecosystems and, ostensibly, the inner loop of development thanks to the de facto standard Dockerfile. Docker will still live on for both Windows and Mac developers. As a platform for running production code it might be dead or dying, but as an ecosystem and a development tool it will continue to live and probably thrive. Docker is still…

> As a platform for running production code it might be dead or dying, but as an ecosystem and a development tool it will continue to live and probably thrive. Not everyone needs an over the top Kubernetes cluster in production. I'm plenty happy using Docker Compose in production and foresee myself continuing to use it as long as Docker maintains it. There's even a WIP issue on their roadmap[0] to rewrite Docker Comp…

I use Docker Swarm (basically multi-node Compose) in production, and am also really happy with it. It's an order of magnitude simpler than k8s, and perfect for small-medium scale deployments.

In terms of configuring your stack, you use regular Compose files, with a few enhancements available (such as better support for secrets). I love it!

Re: Docker's Second Death

#137

Post by pjmlp »

majewsky wrote: post #121
pjmlp wrote: post #108

Earlier quoted context omitted.

Not necessarily, I am yet to bother using it, and know plenty of environments where Docker still is a foreign word. Containers should be about security not cloning local development environment.

Sandboxes are about security. Containers are about deployment tooling. Some containers happen to include/use sandboxing techniques.

I have used container based technology for about 20 years now, starting with Virtual Vault on HP-UX, and happen to know a couple of things about what containers are supposed to be.

Re: Docker's Second Death

#138

Post by pjmlp »

FartyMcFarter wrote: post #122
pjmlp wrote: post #108

Earlier quoted context omitted.

Not necessarily, I am yet to bother using it, and know plenty of environments where Docker still is a foreign word. Containers should be about security not cloning local development environment.

> Containers should be about security not cloning local development environment. Why not? One way to use containers is as a light-weight virtual machine without a kernel, which can be pretty useful.

A workaround for broken development practices.

Re: Docker's Second Death

#139

Post by nikisweeting »

joana035 wrote: post #133
nikisweeting wrote: post #123

Earlier quoted context omitted.

I think you've been using it long enough that you forgot how much of a hurdle learning an extremely high-surface-area piece of tech is. The individual abstractions may be simple once you understand them in hindsight, but making an application developer that normally does not work with cluster management learn 100 new abstractions is not "easy".

Everything looks hard if you lack the fundamental knowledge. Doesn't mean that the tool itself is complicated, and spreading propaganda is plain wrong. Instead, I recommend to read the docs, watch videos and, most important, try it out.

I'm a sysadmin and dev with 10+ years of experience, I've literally written my own cluster container management system, and I've spent probably a hundred hours learning and using kubernetes for months with dozens of services. After a few months I switched everything back to docker compose because it wasn't worth the complexity for our small sized company. k8s is not a magic bullet, it's an incredibly dense and nuanced piece of technology that is only the right solution for a certain class of problems.

Re: Docker's Second Death

#140

Post by [deleted] »

nrvn wrote: post #131
pydry wrote: post #99

Earlier quoted context omitted.

podman in podman doesn't seem to work. that's a showstopper for a lot of work.

I had had some pretty positive experience with docker-in-docker running in podman for ci/cd until podman v2 was released. Then I started getting a lot of weird crashes and segfaults and ditched podman. Yes, you read it correctly, running privileged docker-in-docker containers with podman to spawn docker containers in dind containers. The good thing is that networking was handled flawlessly. And there were no conflict…

[deleted]
Post reply on HN