Dockerless, part 3: Moving development environment to containers with Podman • Hacker News Board

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

#11

Post by hardwaresofton » Tue, Jul 23, 2019, 2:19 AM UTC

wmf wrote: post #3

windexh8er wrote: post #2

For a while I could understand divergent ecosystems for container architectures. But all Redhat did was reinvent tooling, and not particularly to any significant advantage. I feel like all these tools were the brainchild of Dan Walsh as a rogue marketing campaign via Redhat to compete with Docker. All these articles are the same... How to replace your exact Docker workflow with Buildah! Now, less than ever, am I ince…

They keep claiming their stuff is more secure; is that wrong? Being beholden to a desperate competitor isn't just marketing; it could be a matter of survival and a strategic response seems reasonable.

It has to do also with the use of user namespaces (LXC also does this). User namespaces (user/group id mapping) + userspace file systems (FUSE) is what enables building & running containers without root.

Unfortunately the documentation is not really there yet[0], but that's the gist of how it's more secure outside of the general reduction-of-responsibility ways that others have mentioned.

[0]: https://github.com/containers/buildah/issues/1469#issuecomme...

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

#12

Post by paulddraper » Tue, Jul 23, 2019, 2:39 AM UTC

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…

I think this works fine for a lot of things.

The argument though is that can't run an EC2 (AMI) anywhere except AWS.

The advantage of Virtual box images or Docker/OCI images is that you can run them in multiple places (locally, AWS, GCP, Raspberry Pi, etc.) with consistent results.

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

#13

Post by cat199 » Tue, Jul 23, 2019, 2:43 AM UTC

altmind wrote: post #4

windexh8er wrote: post #2

For a while I could understand divergent ecosystems for container architectures. But all Redhat did was reinvent tooling, and not particularly to any significant advantage. I feel like all these tools were the brainchild of Dan Walsh as a rogue marketing campaign via Redhat to compete with Docker. All these articles are the same... How to replace your exact Docker workflow with Buildah! Now, less than ever, am I ince…

I was never happy with the way docker was designed - it tried to steal too much work from the operating system. Docker should never had logging framework not should it be a daemon+client talking over socket, creating permission, indirection and async problems. Docker is straigh hostile to systemd, tried to bite part of its responsibilities and does not cooperate with it in many parts. If you want to run a docker imag…

> I was never happy with the way docker was designed - it tried to steal too much work from the operating system. Docker should never had logging framework not should it be a daemon+client talking over socket, creating permission, indirection and async problems.

> Docker is straigh hostile to systemd, tried to bite part of its responsibilities and does not cooperate with it in many parts.

you had me until the rationale for this was protecting systemd, which is doing the exact same thing..

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

#14

Post by cyphar » Tue, Jul 23, 2019, 2:44 AM UTC

cpuguy83 wrote: post #10

cyphar wrote: post #7

Earlier quoted context omitted.

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…

Amen. There is a heap of mess from the land-grab war. We are all on the same team, just want to make this stuff better, but people still seem intent on fighting.

For the sake of balance -- I do want to clarify that there is definitely land-grabbing happening on both sides of the aisle here. cri-containerd is a good example of the "Docker side" trying to land-grab cri-o's niche.

But again, I don't like all of this stupid politics over such trivial crap. It's ridiculously draining that I have to deal with people from the Docker project demanding me to apologise for things that Dan Walsh has said (or playing dumb when someone else from the SUSE makes a snide comment about several-year-old PRs that have burned out several of our engineers -- and then asking me to try to force them to apologise for it), as well as having to deal with the issues I outlined above. All of this back-and-forth has no benefit to anyone involved (or outside) and is just a waste of our collective lives. Posting this publicly probably won't help either, but I really don't know what the solution is other than to just quit and work on something else where we aren't just collectively accelerating human entropy.

To be frank, this is the main reason I've been working more with the LXC folks in recent years -- there are more interesting problems there and I don't have to deal with this crap. They also have really brilliant engineering, but that's not the main thing that attracted me to working with them.

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

#15

Post by altmind » Tue, Jul 23, 2019, 2:59 AM UTC

cat199 wrote: post #13

altmind wrote: post #4

Earlier quoted context omitted.

I was never happy with the way docker was designed - it tried to steal too much work from the operating system. Docker should never had logging framework not should it be a daemon+client talking over socket, creating permission, indirection and async problems. Docker is straigh hostile to systemd, tried to bite part of its responsibilities and does not cooperate with it in many parts. If you want to run a docker imag…

> I was never happy with the way docker was designed - it tried to steal too much work from the operating system. Docker should never had logging framework not should it be a daemon+client talking over socket, creating permission, indirection and async problems. > Docker is straigh hostile to systemd, tried to bite part of its responsibilities and does not cooperate with it in many parts. you had me until the rationa…

i had a specific operating system that already come with systemd. and all our company's programs are packaged as systemd services. i dont like the way systemd treated system.limits, udev, logind, dbus that is impossible to remove and logging that is worse than rsyslog, but hell, we already paid the price for adopting systemd, why paying extra for docker exibiting same behavior?

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

#16

Post by jzelinskie » Tue, Jul 23, 2019, 3:11 AM UTC

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…

Before Kubernetes existed, this is how most people used CoreOS [Container] Linux. Ignition/cloudconfig to configure the systemd unit files that start just the main container and sidecars.

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

#17

Post by windexh8er » Tue, Jul 23, 2019, 3:18 AM UTC

jacques_chester wrote: post #5

wmf wrote: post #3

Earlier quoted context omitted.

They keep claiming their stuff is more secure; is that wrong? Being beholden to a desperate competitor isn't just marketing; it could be a matter of survival and a strategic response seems reasonable.

> 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…

You don't have to use Docker in prod. Keep in mind the most popular runtime is also contributed by Docker: containerd.

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

#18

Post by windexh8er » Tue, Jul 23, 2019, 3:23 AM UTC

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…

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.

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

#19

Post by brainflake » Tue, Jul 23, 2019, 3:42 AM UTC

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?

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

#20

Post by techntoke » Tue, Jul 23, 2019, 4:15 AM UTC

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.