Why Did Red Hat Drop Its Support for Docker's Runtime Engine? (techrepublic.com) 70
"I've grown quite fond of the docker container runtime. It's easy to install and use, and many of the technologies I write about depend upon this software," writes TechRepublic/Linux.com contributor Jack Wallen.
"But Red Hat has other plans." The company decided -- seemingly out of the blue -- to drop support for the docker runtime engine. In place of docker came Podman. When trying to ascertain why Red Hat split with Docker, nothing came clear. Sure, I could easily draw the conclusion that Red Hat had grown tired of the security issues surrounding Docker and wanted to take matters in their own hands. There was also Red Hat's issue with "no big fat daemons." If that's the case, how do they justify their stance on systemd?
Here's where my tinfoil hat comes into play. Understand this is pure conjecture here and I have zero facts to back these claims up... Red Hat is now owned by IBM. IBM was desperate to gain serious traction within the cloud. To do that, IBM needed Red Hat, so they purchased the company. Next, IBM had to score a bit of vendor lock-in. Using a tool like docker wouldn't give them that lock-in. However, if Red Hat developed and depended on their own container runtime, vendor lock-in was attainable....
Red Hat has jettisoned a mature, known commodity for a less-mature, relatively unknown piece of software -- without offering justification for the migration.... Until Red Hat offers up a sound justification for migrating from the docker container engine to Podman, there's going to be a lot of people sporting tinfoil hats. It comes with the territory of an always-connected world. And if it does turn out to be an IBM grab for vendor lock-in, there'll be a lot of admins migrating away from RHEL/CentOS to the likes of Ubuntu Server, SUSE/openSUSE, Debian, and more.
Red Hat's product manager of containers later touted Podman's ability to deploy containers without root access privileges in an interview with eWeek. "We felt the sum total of its features, as well as the project's performance, security and stability, made it reasonable to move to 1.0. Since Podman is set to be the default container engine for the single-node use case in Red Hat Enterprise Linux 8, we wanted to make some pledges about its supportability."
And a Red Hat spokesperson also shared their position with The New Stack. "We saw our customer base wanting the container runtime lifecycle baked-in to the OS or in delivered tandem with OpenShift."
"But Red Hat has other plans." The company decided -- seemingly out of the blue -- to drop support for the docker runtime engine. In place of docker came Podman. When trying to ascertain why Red Hat split with Docker, nothing came clear. Sure, I could easily draw the conclusion that Red Hat had grown tired of the security issues surrounding Docker and wanted to take matters in their own hands. There was also Red Hat's issue with "no big fat daemons." If that's the case, how do they justify their stance on systemd?
Here's where my tinfoil hat comes into play. Understand this is pure conjecture here and I have zero facts to back these claims up... Red Hat is now owned by IBM. IBM was desperate to gain serious traction within the cloud. To do that, IBM needed Red Hat, so they purchased the company. Next, IBM had to score a bit of vendor lock-in. Using a tool like docker wouldn't give them that lock-in. However, if Red Hat developed and depended on their own container runtime, vendor lock-in was attainable....
Red Hat has jettisoned a mature, known commodity for a less-mature, relatively unknown piece of software -- without offering justification for the migration.... Until Red Hat offers up a sound justification for migrating from the docker container engine to Podman, there's going to be a lot of people sporting tinfoil hats. It comes with the territory of an always-connected world. And if it does turn out to be an IBM grab for vendor lock-in, there'll be a lot of admins migrating away from RHEL/CentOS to the likes of Ubuntu Server, SUSE/openSUSE, Debian, and more.
Red Hat's product manager of containers later touted Podman's ability to deploy containers without root access privileges in an interview with eWeek. "We felt the sum total of its features, as well as the project's performance, security and stability, made it reasonable to move to 1.0. Since Podman is set to be the default container engine for the single-node use case in Red Hat Enterprise Linux 8, we wanted to make some pledges about its supportability."
And a Red Hat spokesperson also shared their position with The New Stack. "We saw our customer base wanting the container runtime lifecycle baked-in to the OS or in delivered tandem with OpenShift."
Because Docker sucks (Score:5, Interesting)
Re: (Score:3)
I believe Red Hat is pushing for podman, a less popular technology with far less support than docker. They've done this for some other technologies, such as KVM over the Xen virtualization preferred by the CentOS users, and 389 Directory Server and sssd instead of Samba, which the rest of the Linux and UNIX worlds standardize on and support more effectively. I'm afraid that Red Hat has made some peculiar choices on which choices to support and sponsor.
Re: (Score:2)
Re: (Score:2)
KVM is only "mainstream" in that Red Hat will support it commercially. It is consistently rejected and discarded by individual users, and by commercial installations, seeking virtualization technologies. The support from Red Hat for complex installations, especially complex network environments, has not been up to the standard I'd expect for commercial support. The CentOS community is using Xen far more extensively and effectively, or simply using AWS based cloud instances.
sssd is what Red Hat tells their c
Re: (Score:3)
KVM is only "mainstream" in that Red Hat will support it commercially. It is consistently rejected and discarded by individual users, and by commercial installations, seeking virtualization technologies
What? The largest cloud computing provider (AWS) is built on KVM, only some legacy instance types there use Xen. It's also used everywhere Google Cloud.
sssd is what Red Hat tells their customers to use to manage _client_ access to LDAP and Kerberos (the basis of AD and Samba), and SAML.
Indeed. It's the only caching solution for client access. Windows supports caching natively but without sssd Linux falls flat if there's no LDAP/Kerberos connectivity during login. If you can tell me how to achieve the same with Samba, I'm all ears.
Re: (Score:3)
The AWS version of KVM is internal, proprietary, and not relevant to the public or RHEL's version in my observation. One of the keys to good virtualization toolkits is the wrappers, the integration and management tools. RHEL's have been poor.
sssd's caching behavior is unfortunately fragile. It requires a successful cache of the _entire_ LDAP_, and crashes _all_ of the sssd daemons if the cache fails. There are ways around it, but spending the time and effort to do so generally outweighs any of the unnoticea
Re: (Score:3)
The AWS version of KVM is internal, proprietary, and not relevant to the public or RHEL's version in my observation.
AWS uses mainline KVM with only a few out-of-tree patches that haven't been yet integrated. I worked at AWS, so I know.
Toolkits for Xen are also mediocre. And these days people just use OpenStack which supports KVM better than Xen (more features and better community).
sssd's caching behavior is unfortunately fragile. It requires a successful cache of the _entire_ LDAP_, and crashes _all_ of the sssd daemons if the cache fails. There are ways around it, but spending the time and effort to do so generally outweighs any of the unnoticeable benefits of LDAP caching.
I haven't seen this, and I've used sssd with an LDAP directory with more than several million objects, not all of them visible. The problem is that without sssd a computer becomes basically useless without an Internet connection, you won't be
Re: (Score:3)
I'm startled to hear that AWS's kernel is so little modified from the mainline KVM. Do you have any pointers to this in whitepapers or source code? I was under the impression that AWS was doing a great deal with network integration, hypervisor tuning, and instance migration tuning. The configuraiton and mangement suite is _far_ superior to what KVM supported, especially Red Hat's management suite.
The management tools for Xen were better than Red Hat's tools for KVM, the last few times I had to work with the
Re: (Score:3)
I'm startled to hear that AWS's kernel is so little modified from the mainline KVM. Do you have any pointers to this in whitepapers or source code?
Sorry, inside info - I worked on implementing support for instance hibernation on AWS. But you can check the source of Firecracker (it powers AWS Lambda) and you'll see that it doesn't use anything special, just the stock KVM interface. There are also AWS-on-prem devices that have all the GPL source code available, they don't have anything unusual there either.
I was under the impression that AWS was doing a great deal with network integration, hypervisor tuning, and instance migration tuning.
Sure, but that's done mostly either in custom silicon (network cards and top-of-the-rack devices) or in userspace. There's little kernel-level tuning
Re: (Score:3)
I'm looking at some notes about "FireCreacker that describe it as "a kernel based virtual machine". From the description I found "Firecracker isn't a complete device model, it doesn't have any emulated BIOS". So does it count as KVM software meaning "based on the KVM project"? Or is it just using the descriptive name?
Re: (Score:2)
Userspace is then responsible for everything else, like BIOS functionality and device emulation. Normally KVM is used with QEMU that emulates a fairly complete machine, with a virtual display adapter, legacy BIOS and s
Re: (Score:1)
I believe Red Hat is pushing for podman, a less popular technology with far less support than docker. They've done this for some other technologies, such as KVM over the Xen virtualization preferred by the CentOS users, and 389 Directory Server and sssd instead of Samba, which the rest of the Linux and UNIX worlds standardize on and support more effectively. I'm afraid that Red Hat has made some peculiar choices on which choices to support and sponsor.
and systemd
and PulseAudio
and probably a whole bunch of POS (programs of shit)
Re: (Score:2)
Another reason I think they are dumping Docker
Re: (Score:2)
Samba has been able to do all the bits of sssd since before sssd existed in terms of identity management on Linux machines attached to Active Directory.
Re: (Score:2)
I'm afraid that Red Hat has made some peculiar choices on which choices to support and sponsor.
Could that have something to do with why Redhat no longer exists as an independent entity?
Re: Because Docker sucks (Score:1)
companies can be bought out because of their position of strength and market dominance that another company wants. Or a company can be bought out when itâ(TM)s running out of cash and funding, someone buys them out thinking they can turn it around
The red hat purchase is the former, sun is the later
Re: (Score:2)
companies can be bought out because of their position of strength and market dominance that another company wants
Fairy tale. If a company is that strong then its asking price will be out of reach. No, companies get bought when they weaken, always has been that way and always will be.
Re: (Score:2)
> Fairy tale. If a company is that strong then its asking price will be out of reach.
If I may say, _that_ is a fairy tale. There are many ways, some legitimate and some fraudulent, to lure a competitor into accepting an offer. Mere "strength" is not enough to resist an offer.
Re: (Score:2)
High price is the standard way of resisting an offer. Good luck in the long journey ahead of you, towards a basic understanding of corporate finance.
Red hat got bought because it started to lose data center share to Ubuntu and other, better distributions that don't piss off their users with perennially creaky old out of date software, and let's not forget: RPM sucks ass. Most of Red Hat's big ideas suck ass, they pissed off way too many influential geeks for their own good and it came back to bite them on t
Re: (Score:2)
Let's not confuse changing our claims with a deeper "understanding of corporate finance" Setting a higher price not the same thing as making a company out of reach. Even if a company is strong and its owners set the price quite high, what company is so strong that they can resist an outrageously high offer? Or resist during the occasional business disaster that leaves them reeling for a year?
I actually agree that Red Hat has made some poor choices. Their OS release cycle has been long, and they've insisted
Re: (Score:2)
Red hat is down to roughly 3% share of servers now, that is why they got bought. In the glory days revenue increased 30%/year, now it's 9% and heading in the wrong direction.
Re: (Score:2)
Red Hat, and various of their product lines, have real problems with market share. Where are you getting your number from? And what numbers are there for CentOS, AWS Linux, all of which are linked to and depend on development from Red Hat?
Re: (Score:2)
See "Market share by category" here. [wikipedia.org] This does not include non-web servers but I don't see why that would be significantly different. Centos is given as 20%, Debian 31%. There was a time when it would have been the other way round.
Re: (Score:2)
3% sounded _very_ low, but I'd normally class CentOS and RHEL as the same OS. CentOS is now published by Red Hat and they use the same git repos for almost all of their source code over at https://git.centos.org/ [centos.org] .
Re: (Score:2)
Agree that CentOS and RHEL are essentially the same product. The customer doesn't get support for the former, and Red Hat doesn't get money. For Red Hat, that is the issue that ended its run as an independent entity. I should also have mentioned, 35% share for Ubuntu besides 31% for Debian. It is abundantly clear that Debian derivatives have won the data center mind share battle versus RPM derivatives. IBM may be able to slow this down but can't reverse it. Eventually, IBM too will shift its weight fully be
Re: (Score:1)
No surprise (Score:1)
Redhat was a huge proponent of systemd. Their business is selling support contracts. If everything runs smoothly you don't need support.
Re: (Score:2)
Redhat was a huge proponent of systemd. Their business is selling support contracts. If everything runs smoothly you don't need support.
If every customer is a preeminent expert on RHEL and never has a question on how to do something or how to troubleshoot something and everything runs smoothly.
Fortunately for Redhat, most customers aren't those things. For people who don't need support there is CentOS.
Re: (Score:2, Interesting)
Red Hat has been replacing their own development people with CentOS "extras" development. Think I'm kidding? Take a good look at who's left working their Westford offices, and how development for RHEL comes from the CentOS discussion groups. Every Red Hat customer does their testing and proof-of-concept work on CentOS.
Re: (Score:2, Troll)
Indeed. Obscure behavior, complex failure modes, binary file formats, etc. all are good for their business. Of course, anybody sane will stay the hell away from this crap, but sanity is in short supply in the human race. Most are just mindless herd-animals.
Re: (Score:2)
Redhat was a huge proponent of systemd.
And they kept flogging the Gnome dead horse like the assholes and idiots they are. Good riddance.
Docker should have been jettisoned long ago (Score:5, Insightful)
Re: (Score:2)
There's certainly a lot to like about podman *in principle*. Anything that can act as a drop-in docker replacement with better security, no daemon required and can run completely as a user process sounds great. How much traction it gets is hard to say at this stage.
I'm actually more interested in the buildah tool because personally being able to build OCI container images from a Dockerfile without having to have docker installed and running is a huge benefit. No more docker-inside-docker just to build my ap
Not the customer. (Score:2)
If you're not paying IBM to have their marketing reps come tell you what you need then you're not their customer.
There is a slideshow somewhere what has all of these justifications that they parade out to mid level managers making these decisions.
See also: DOORS, DOORS Next Generation, Clearcase, What ever the fuck Jazz is, and everything else they purchase/down.
Pure conjecture? (Score:4, Interesting)
"Understand this is pure conjecture here" this is the only true part of this piece. This is all made up. It's a technology decision many years in the making if you've paid attention. Blogged about, speeches made, etc. Nothing out of the blue about it.
Re: (Score:2)
Re: (Score:1)
Damn commies! (Score:1)
Controversial I know (Score:3, Interesting)
but I find docker itself overrated. I have also seen a lot of interest in many other container techs. Podman is open source - if it's awesome, I'm sure someone will bring it to other distros.
I prefer LXD*, but then again I work for Canonical. We actually just added VM support to LXD because people wanted one system to manage both (feel free to insert another conspiracy theory here) - https://discuss.linuxcontainer... [linuxcontainers.org].
Systemd has one of the best command line UIs of any software I've ever used. If anything replaces systemd in the future, it will be building on units in some way - definitely not be going back to shell scripts.
*I am aware it's targeted for a different kind of container user.
Re:Controversial I know (Score:5, Insightful)
Systemd has one of the best command line UIs of any software I've ever used
Uh, what?
Re: (Score:1)
> Uh, what?
He forgot to add sarcasm sign or never used anything else or he never had to work as admin debugging startup problems.
Re: Controversial I know (Score:2)
Uh, what?
Yeah, don't you know? It also has a wicked kernel. The bootloader is coming along fine too. Only thing missing is a proper init system...
Re: (Score:2)
I see some irony here. Units that work only under a monolithic system(d) vs. shell scripts that can work standalone. If there's anything that Roland Emmerich has taught us in ID4 [wikipedia.org], besides the dangers that lurk behind the Cloud [dailymail.co.uk], it's that monolithic systems are doomed to catastrophic failure.
Re: (Score:2)
You've got an interesting definition of failure. Apple's system has been in use for over 14 years now. Solaris has had their system for even longer. HP had a similar system before then. Systemd has been in use for nearly a decade now. Solaris and HPUX are dead really, but I'm not sure their init systems were the reason. Apple is going strong. And systemd on Linux has proven to be quite reliable.
So yes. Total catastrophic failure in every case. Thank goodness for visionary film makers to alert us to
Meh heh (Score:5, Funny)
Doubtless, systemD will do that soon! (Score:2, Troll)
Makes perfect sense!
Re: (Score:2)
"no big fat daemons"
Meant to say "There can be only one!"
Re: Doubtless, systemD will do that soon! (Score:2)
systemd-nspawn can be used to launch containers. It's not part of systemd, but it's integrated really nicely.
Everyone is moving away from Docker! (Score:4, Informative)
First of all, claiming that this decision came out of the blue just proves that the author doesn’t know how Red Hat does upstream open source work. All of this has happened in the open and was easy to predict if you watch what’s going on in Fedora (and openSUSE Tumbleweed just the same).
Second, it’s not at all a Red Hat only thing, and there’s no IBM conspiracy behind this. Everyone but the Docker guys themselves is going for the Podman stack and the cri-o runtime (for Kubernetes) and ditching the Docker stack. And this all started way before IBM acquired Red Hat.
As an end user, you won’t experience a real difference because the alternative stack has drop-in replacements for all of the parts of Docker and is compatible with the same container images and registries.
Re: (Score:2)
You know what's coming real soon . don't you? (Score:2)
Job ads written by clueless hiring managers and HR "professionals" demanding 5-10 years of Podman experience.
Re: (Score:2)
You just reply "yeah I was using it back when it was called Docker"
Docker is cancer (Score:1)
Because docker is a cancer. It was created by people who don't understand packaging.
"docker run -ti true /bin/true" lol.
Yea, because every executable needs its own VM.
Maybe because container users should go back to (Score:1)
Windows!
Instead of trying to turn Linux into Windows with all its stupid problems (like duplication, lack of library updates or cumbersome updates, etc).
Seriously, do you want Unix or do you want Windows/macOS/apps?
Or do you simply have no clue what the former even is, and truly cannot think outside of your little proprietary walled garden box?
Simple answer. They didn't. (Score:3)
Red hat doesn't directly support any recent version of docker. They've had a forked (atomic) version of the docker engine for as long as I recall. If you install docker-ce or docker-ee the support for that game from docker (community or from the company for EE).
The recent change in fedora didn't stop supporting docker. They made cgroupsv2 the default which docker doesn't support. They document how to enable cgroupsv1 and how to install the moby-engine (open source upstream for the docker project) and technically that's still "supported" depending on how you want to define supported with open source.
One could turn this around and say what the hell is taking docker so long to support cgroupsv2. Speaking of which, when this happened in fedora there was a pretty massive flurry of activity on cgroupsv2 support for docker. Probably not a coincidence :)
Disclaimer: I use docker every day for my job and as an integral part of my dev environment and I also use Fedora as my daily driver and I've switched to podman and so far it's been decent. Some growing pains but nothing horrible.
Docker is dead. (Score:1)
Re: Docker is dead. (Score:2)
No conspiracy Red Hat just moved early (Score:1)
Red Hat releases Poettering update soon? (Score:2)
That starting next version Systemd will also will be doing containers. systemd-containerd will by default get launched at boot. SystemD can then also block any attempts to install a 3rd party container software.
For its next trick just like the days of Win95 and IE, SystemD add their own custom web browser and file manager all in one. Any attempt to uninstall the systemd web browser or file manager will cause system to not be able to boot. /s of course, but I'm waiting on SystemD to start thinking Win95 had
Systemd on a Chip (Score:2)
it's probably much simpler... (Score:2)
Docker wasn't written by Lennart Poettering. Podman fixes this ;-)
Docker is a load of trouble. (Score:2)
I am not a big fan of Docker. The lack of ability to start a Docker outside of root is one reason.
Another one is I had immense trouble figuring out how to access the filesystem inside a container when the container when it is shut down, without software running inside the container such as sshd, containers don't often have their own sshd and that would be ridiculous if they had to. The inevitable responses may come, "why do you need that...". It does not matter why I need it, I should be able to do it. Its
no vendor lock-in (Score:2)
vendor lock-in has nothing to do with it, however, red hat does have a bit of a NIH problem.
still their projects are fully OSS.
Problem solved? (Score:1)