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

Dockerless, part 3: Moving development environment to containers with Podman

mkdev.me

Post reply on HN
Print view View original

21–30 of 42 posts

Re: Dockerless, part 3: Moving development environment to containers with Podman

#21

Post by [deleted] »

cyphar wrote: post #7
jacques_chester wrote: post #5

Earlier quoted context omitted.

> They keep claiming their stuff is more secure; is that wrong? The docker daemon has a large surface area and also has fairly hefty privileges. It's a juicy target of attack. A platform can take various actions to further lock down the runtime with AppArmor or SELinux, but out of the box you wind up hearing the motto that "containers don't contain". Notably, the docker daemon has too many responsibilities. It's a bu…

I hate to engage in this petty in-fighting (especially since I want podman to succeed and actually be as secure and well-designed as rkt was but with OCI runtime support). Unfortunately, I don't agree with this whole "it must be more secure because we broke it into bits" argument. That alone is not sufficient in order to increase security. The vast majority of the code in libpod/cri-o is very similar to (generate a c…

[deleted]

Re: Dockerless, part 3: Moving development environment to containers with Podman

#22

Post by meddlepal »

brainflake wrote: post #19
algesten wrote: post #8

At my company we did our own docker execution environment. We generally like docker's layers and packaging, but dislike the runtime. With AWS you already have a virtualization, why do we need another layer? We packaged a super slim Linux with an init that just has some minimal code reading out of AWS EC2 user info the conf. Downloads docker hub image and runs it as a process. No virtual networking or ssh access. No m…

It sounds very inefficient to be honest. Containers don't add much overhead - they are essentially processes that run in constrained environments (see http://man7.org/linux/man-pages/man7/namespaces.7.html ). Why dedicate an entire ec2 instance to a single container?

It wasn't that long ago that we were doing service-per-VM and really OP has just described an implementation of that strategy with containers.

You would scale the virtual machines to try and reach optimal resource usage rather than pick a standard fleet of virtual machines for all workloads and let a scheduler do some kind of knapsack scheduling based on available resources.

Re: Dockerless, part 3: Moving development environment to containers with Podman

#23

Post by cyphar »

windexh8er wrote: post #18
cpuguy83 wrote: post #9

Earlier quoted context omitted.

Docker's runtime is long spun out into containerd (though there is more work to do here). Builder is in buildkit, which sits on top of containerd. Would be nice to decouple networking, this will take some work. Docker is more and more becoming an API that sits on top of a bunch of other services. It does take time to make this happen without breaking compatibility, though. Docker can also run without root as of Docke…

Agreed. One other point is containerd isn't a Kubermetes specific runtime. Why cri-o chose to lock in like that doesn't seem to make long term sense except with regard to ease of development.

The long-term goal is to switch users to use podman (and buildah I guess), with cri-o being a daemon that uses the same underlying code. The only reason a daemon is required in the first place is because the CRI uses gRPC.

This is loosely similar to how rkt operated, with rktnetes just being a front-end for rkt (though at the time, the CRI didn't exist so it was all hardcoded in Kubernetes).

The goal isn't to have a differently-named daemon required in order to do any operation, and podman enables that (though again, so did rkt).

Re: Dockerless, part 3: Moving development environment to containers with Podman

#24

Post by ec109685 »

algesten wrote: post #8

At my company we did our own docker execution environment. We generally like docker's layers and packaging, but dislike the runtime. With AWS you already have a virtualization, why do we need another layer? We packaged a super slim Linux with an init that just has some minimal code reading out of AWS EC2 user info the conf. Downloads docker hub image and runs it as a process. No virtual networking or ssh access. No m…

Scaling up another ec2 instance is slower than a container.

So if you have 10 services deployed on 10 ec2 instances each, you will need 200 ec2 instances to give yourself 50% headroom for each service.

With containers, you can give each container 10x headroom for the same amount of hardware.

Re: Dockerless, part 3: Moving development environment to containers with Podman

#26

Post by jchw »

reilly3000 wrote: post #25

I’m dense about alt-containers but why? Is this all about Docker security issues? Is Docker too passé now that it’s in production everywhere? Why should I spend money on not using Docker in 2019?

Shouldn’t spend literal money. As for why, well I don’t use Podman but Rkt had a similar fork-exec model and it came with loads of benefits, like having containers that integrated well with your init daemon.

Docker has the issue of needing a daemon that runs as another user. Aside from being a security issue it’s just inconvenient and Docker has to go through great lengths to make it all transparent.

Re: Dockerless, part 3: Moving development environment to containers with Podman

#27

Post by geezerjay »

meddlepal wrote: post #22
brainflake wrote: post #19

Earlier quoted context omitted.

It sounds very inefficient to be honest. Containers don't add much overhead - they are essentially processes that run in constrained environments (see http://man7.org/linux/man-pages/man7/namespaces.7.html ). Why dedicate an entire ec2 instance to a single container?

It wasn't that long ago that we were doing service-per-VM and really OP has just described an implementation of that strategy with containers. You would scale the virtual machines to try and reach optimal resource usage rather than pick a standard fleet of virtual machines for all workloads and let a scheduler do some kind of knapsack scheduling based on available resources.

Comparatively, service-per-vm approaches are very wasteful and ineficcient, moreso if a container orchestration system is used to manage the deployment. It makes no sense to fine-tune VMs just to match the resource requirements of a single process, particularly as they change over time and as that approach leads you to a collection of custom-tayloted VMs that are needlessly cumbersome to manage and scale.

Meanwhile containers enable you to run multiple services on the same VM, scale them horizontally as you need on the same pre-determined amount of resources, use blue/green deployments to spread your services throughout your VMs automatically, and achieve all of this automatically and effortlessly.

Re: Dockerless, part 3: Moving development environment to containers with Podman

#28

Post by politelemon »

reilly3000 wrote: post #25

I’m dense about alt-containers but why? Is this all about Docker security issues? Is Docker too passé now that it’s in production everywhere? Why should I spend money on not using Docker in 2019?

> Why should I spend money on not using Docker in 2019?

You should use what works for you - ultimately you know your context and circumstances better and you can make the decisions that affect you/your team better than any of us.

HN is not an indicator of industry trends, but more of a set of interesting articles and viewpoints that come together, though you will often see authors and commenters pushing hard in certain directions.

In this instance, have a look at the author's part 1 under 'Reasons to switch', see if any of the reasons given work for you.

https://mkdev.me/en/posts/dockerless-part-1-which-tools-to-r...

Re: Dockerless, part 3: Moving development environment to containers with Podman

#29

Post by reilly3000 »

politelemon wrote: post #28
reilly3000 wrote: post #25

I’m dense about alt-containers but why? Is this all about Docker security issues? Is Docker too passé now that it’s in production everywhere? Why should I spend money on not using Docker in 2019?

> Why should I spend money on not using Docker in 2019? You should use what works for you - ultimately you know your context and circumstances better and you can make the decisions that affect you/your team better than any of us. HN is not an indicator of industry trends, but more of a set of interesting articles and viewpoints that come together, though you will often see authors and commenters pushing hard in certa…

Thanks for sharing that, it provides a lot more context. I don’t run a lot of containers, but the few I do I’ve naively run on an EC2 VM and ran into many issues with the docker daemon. I’ve since embraced Fargate and haven’t looked back. This takes me back to those hours spent troubleshooting (PSA: don’t use snap to install docker if you want to have a good time) and see the appeal in a daemonless container, and the root access definitely is a concern as well.

Re: Dockerless, part 3: Moving development environment to containers with Podman

#30

Post by cyphar »

techntoke wrote: post #20

If only Minikube could support installing rootless Kubernetes directly in Podman containers on Linux. I love the concept of Podman, but without an easy installer for Kubernetes it seems mostly pointless for most use cases.

I'm pretty sure (though it's been a while since I worked on it) that the usernetes project gives you all of the helpful scripts you need to get rootless Kubernetes running. I don't think you really need MiniKube to support it unless you have some specific requirement to use it.
Post reply on HN