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

31–40 of 42 posts

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

#31

Post by goatinaboat »

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?

Docker the command and Dockerfile the format are great but Docker the company have burnt a lot of people with breaking changes and shonky QA, whereas Podman/Buildah seem to be taking the time to do it right. I get why Docker the company did what they did as a land grab but they sacrificed too much goodwill in the process. Lots of people were like, I want to use containers but I can’t risk or justify using Docker. It’s not clear what their business model is now.

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

#32

Post by jacques_chester »

cpuguy83 wrote: post #9
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…

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…

> Docker is more and more becoming an API that sits on top of a bunch of other services.

Which is a good thing. With Cloud Foundry we moved from using a pre-Docker container engine to using runc as soon as it was available; containerd is the next move.

> Even so, "docker requires too many privileges" is marketing speak.

I don't agree. The API surface still exists and includes too many disparate purposes. The modularisation of Docker is improving that risk profile, but it still exists. Fully segregating the API and the modules is worthy.

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

#33

Post by jacques_chester »

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…

> I'm just tired of all the fucking drama.

I wasn't aware there was any, my perspective comes from working from a different end (dockerless builds).

I know what it can be like to work in communities fraught with vendor politics and other troublesome dynamics and have come close to burning out a few times.

It always feels too important to walk away from, even temporarily, but I promise, it's not true. Your own health is important.

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

#34

Post by windexh8er »

cyphar wrote: post #23
windexh8er wrote: post #18

Earlier quoted context omitted.

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…

Thanks for your insight! I guess I don't understand why having multiple runtimes helps. If CRI is just an agnostic interface to the tooling what is the advantage of cri-o over containerd? Why make the ecosystem harder when it's all a standard runtime interface anyway? Couldn't Docker tooling, podman and buildah all talk directly to any runtime?

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

#35

Post by cpuguy83 »

jacques_chester wrote: post #32
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…

> Docker is more and more becoming an API that sits on top of a bunch of other services. Which is a good thing. With Cloud Foundry we moved from using a pre-Docker container engine to using runc as soon as it was available; containerd is the next move. > Even so, "docker requires too many privileges" is marketing speak. I don't agree. The API surface still exists and includes too many disparate purposes. The modulari…

Modularization improves maintenance overhead, it does not reduce privilege.

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

#37

Post by MuffinFlavored »

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.

Does Kubernetes orchestrate Docker images into the Docker dameon as pods? aka does Kubernetes sit on top of Docker?

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

#38

Post by techntoke »

MuffinFlavored wrote: post #37
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.

Does Kubernetes orchestrate Docker images into the Docker dameon as pods? aka does Kubernetes sit on top of Docker?

Sort of but it uses the Docker daemon in the Minikube VM currently, but Minikube currently supports a --vm-driver=none option to deploy Minikube Kubernetes without using a VM (which is currently not recommended due to security issues of sharing the Docker daemon). However, deploying Kubernetes in a container (or containers) would greatly speed up the deployment and make it a lot easier to manage than a VM.

Since Podman supports rootless containers it should mitigate this security risk. Really there needs to be an easy way to deploy Kubernetes to Podman on Linux. It would make things a lot easier overall and make Podman the ideal option for local Kubernetes on Linux.

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

#39

Post by techntoke »

cyphar wrote: post #30
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.

I still haven't found an easy and reliable way to do this. Do you have some simple instructions, cause it looks way more complicated than it should be.

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

#40

Post by MuffinFlavored »

techntoke wrote: post #38
MuffinFlavored wrote: post #37

Earlier quoted context omitted.

Does Kubernetes orchestrate Docker images into the Docker dameon as pods? aka does Kubernetes sit on top of Docker?

Sort of but it uses the Docker daemon in the Minikube VM currently, but Minikube currently supports a --vm-driver=none option to deploy Minikube Kubernetes without using a VM (which is currently not recommended due to security issues of sharing the Docker daemon). However, deploying Kubernetes in a container (or containers) would greatly speed up the deployment and make it a lot easier to manage than a VM. Since Podm…

I'm down to work on this. Do you want to team up and give it a shot?
Post reply on HN