Dockerless, part 3: Moving development environment to containers with Podman
1–10 of 42 posts
Re: Dockerless, part 3: Moving development environment to containers with Podman
#2For 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 incented to use any products that come from Bluehat.
Re: Dockerless, part 3: Moving development environment to containers with Podman
#3For 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.
Re: Dockerless, part 3: Moving development environment to containers with Podman
#4For 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 image as a system service, its much easier to do that with podman - the docker image will inherit the system.limits and will behave like a Type=simple service with proper start/stop control and logging.
-- add: worth noting, that podman and buildah are very alike "docker" and "docker build" up to the point that you can do alias docker="podman" and can expect all the docker features work. they consume the same docker files, they build the same OCI images and can use the same registries. trying podman/buildah/scopeo really got me thinking - where's the moby inc. business? how can they commercialize a commodity?
Re: Dockerless, part 3: Moving development environment to containers with Podman
#5For 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.
> 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 builder. It's a shipper. It's a runner. It's everything to everyone, which makes for a convenient installation process but means that a subversion of any of these functions potentially allows someone to drill sideways into one of the others.
> Being beholden to a desperate competitor isn't just marketing; it could be a matter of survival and a strategic response seems reasonable.
I'm prepared to go with: the engineers thought it was a good idea and product management didn't gainsay them. It's been a common theme from multiple tech companies in the past year or two. Google, Amazon, Red Hat, Pivotal (which is where I work) have all been chipping away at breaking off parts of the daemon's responsibilities.
Re: Dockerless, part 3: Moving development environment to containers with Podman
#6For 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…
Moby Inc.'s business should be in services related to Docker. On itself, the docker software is just a helper tool to set up some kernel services, any bunch of shell scripts could do that.
Re: Dockerless, part 3: Moving development environment to containers with Podman
#7Earlier 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…
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 config and pass it to runc) or copied directly from Docker (containers/storage, with containers/image honestly having quite a few more problems than Docker's image parsers). When I found CVE-2018-15664, not only was the libpod/cri-o stack also vulnerable but it was as vulnerable as Docker was more than 5 years ago when I fixed the original security flaw in 2014. I feel bad saying this (I don't want to blame the folks working on this, who I do respect immensely) but it really should be a serious consideration if you want to put "more secure" in your advertising.
This is why I argued for several years that we should add OCI runtime (and custom storage driver) support to rkt instead of having to redesign everything (and since we started with cri-o instead of libpod, getting rid of the daemon was a pain there too). But of course, like every other discussion I've had with Dan Walsh, it was brushed away. Whatever.
I do really like the folks behind the project. I just wish we'd spent our collective energy on improving something that already existed instead of repeating mistakes pointlessly. I'm definitely not a fan of Docker's politics either (and at the very least nobody from the cri-o/libpod project has sent me abusive emails calling me stupid and "brainwashed by Red Hat" for criticizing their project's governance model -- which Solomon Hykes did in the past when he was still the CTO of Docker).
Disclaimer: I work for SUSE and maintain runc, and have worked on containers for a depressingly long period of time. Obviously the above are my views not those of my employer (who ships both Docker and cri-o, and my team maintains it in our products). I'm just tired of all the fucking drama.
Re: Dockerless, part 3: Moving development environment to containers with Podman
#8At 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 magic. Just a process on an aws ec2 instance.
Re: Dockerless, part 3: Moving development environment to containers with Podman
#9Earlier 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…
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 Docker 19.03. Even so, "docker requires too many privileges" is marketing speak. Setting up cgroups requires root, setting up mounts (w/o fuse) requires root, setting up network devices requires root, etc... anyone who wants to do these things requires root. Rootless mode on all this tech attempts to work around such limitations, but each workaround comes with trade-offs (slower networking, no cgroup support, slower fs access...).
Definitely agree, though if you want to run services through systemd Docker is not well designed for that purpose.
Re: Dockerless, part 3: Moving development environment to containers with Podman
#10Earlier 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…
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.