Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Red Hat Software Cloud IBM Linux

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."
This discussion has been archived. No new comments can be posted.

Why Did Red Hat Drop Its Support for Docker's Runtime Engine?

Comments Filter:
  • Because Docker sucks (Score:5, Interesting)

    by Cyberax ( 705495 ) on Saturday January 18, 2020 @01:58PM (#59633180)
    RedHat did it because Docker simply sucks. It's been essentially unmaintained for YEARS now, with barely any new features added to the core container runtime. For example, there's no ability to get the metrics (like max RAM used) from a dead container and there's still no real ability to use IPv6 (enabling it exposes all ports in the container).
    • 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.

      • by Cyberax ( 705495 )
        Uhh? What? sssd is not a replacement for Samba, they serve completely different purposes. And KVM has been mainstream for ages by now. It's Xen that is not "standard" these days.
        • 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

          • by Cyberax ( 705495 )

            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.

            • 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

              • by Cyberax ( 705495 )

                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

                • 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

                  • by Cyberax ( 705495 )

                    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

                    • 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?

                    • by Cyberax ( 705495 )
                      KVM is a kernel-level feature of Linux that allows to run machine code in a sandbox and intercept any privileged instructions that this code executes. That's really all there is to it, this article has an example of a simplistic "hypervisor" that uses it: https://lwn.net/Articles/65851... [lwn.net] .

                      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
      • by Anonymous Coward

        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)

        ....shower though: Has anyone looked into the possibility that RedHat is a super long con game by Microsoft, IBM, or one of the old (now defunct) Unix vendors?

      • by thule ( 9041 )
        It wouldn't bee 389 DS and sssd. It would be FreeIPA/RedHat IdM and sssd. Furthermore it is not "instead of samba". Samba is for Windows clients. FreeIPA is a sort of Active Directory for Linux. It specifically supports things like centrally defining sudo rules. I recall that RedHat was trying to get Samba to have a pluggable Kerberos backend so it would work WITH FreeIPA/RH IdM. I haven't looked at it in awhile, but maybe that work has been completed by now.

        Another reason I think they are dumping Docker
        • by jabuzz ( 182671 )

          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.

      • 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?

        • 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

          • 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.

            • > 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.

              • 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

                • 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

                  • 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.

                    • 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?

                    • 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.

                    • 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] .

                    • 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

        • There are a few reasons the "IBM made them do this take" seems a bit dumb in this particular case: * Podman, CRI-O and friends were being developed in the open well before the IBM acquisition was announced much less closed. * Similarly, RHEL 8 which is when this change really happened also became generally available several months before the acquisition was announced. * The bulk of IBM advocacy seems to be pushing containerd, not podman https://www.ibm.com/cloud/blog... [ibm.com] It seems like the author somehow mi
  • Redhat was a huge proponent of systemd. Their business is selling support contracts. If everything runs smoothly you don't need support.

    • 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)

        by Anonymous Coward

        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)

      by gweihir ( 88907 )

      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.

    • Redhat was a huge proponent of systemd.

      And they kept flogging the Gnome dead horse like the assholes and idiots they are. Good riddance.

  • by quicksand1 ( 6497482 ) on Saturday January 18, 2020 @02:11PM (#59633204)
    Docker-co jumped the shark by injecting the management layer(s) to compete with k8s. That failed. The docker engine itself requires too many security concessions versus the alternatives. Podman, rocket, runc, are all open-source so vendor lock-in doesn't exist: any distro can package and offer though. No tinfoil hat needed here.
    • by Zarjazz ( 36278 )

      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

  • 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)

    by CloneRanger ( 122623 ) on Saturday January 18, 2020 @02:16PM (#59633218)

    "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.

    • by thule ( 9041 )
      Absolutely true. It isn't just RedHat pushing to drop Docker, it is the Kubernetes project. I suspect that Docker will be relegated to simple, single box use. Anything beyond that will not use Docker.
    • Another good tell was that this was written in 2020 and of all the things to complain about the author seems to think Swarm support is still relevant?
  • IBM is evil, so?
  • Controversial I know (Score:3, Interesting)

    by gQuigs ( 913879 ) on Saturday January 18, 2020 @02:21PM (#59633226) Homepage

    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.

    • by phantomfive ( 622387 ) on Saturday January 18, 2020 @03:31PM (#59633304) Journal

      Systemd has one of the best command line UIs of any software I've ever used

      Uh, what?

      • by tokul ( 682258 )

        > Uh, what?

        He forgot to add sarcasm sign or never used anything else or he never had to work as admin debugging startup problems.

      • Systemd has one of the best command line UIs of any software I've ever used

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

    • 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 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.

      • by caseih ( 160668 )

        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)

    by fluffernutter ( 1411889 ) on Saturday January 18, 2020 @02:26PM (#59633232)
    "Seemingly out of the blue"... Pun intended??
  • Makes perfect sense!

  • by bavarian ( 59962 ) on Saturday January 18, 2020 @03:42PM (#59633324)

    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.

    • All true. Not to even mention that people complaining about Fedora using cgroups v2 are beyond dumb as that has been planned for so long yet docker did nothing. It's very, very clear this author has no freaking clue what they're talking about. They should probably spend more time researching and less time speculating to find the answers they think aren't there.
  • Job ads written by clueless hiring managers and HR "professionals" demanding 5-10 years of Podman experience.

  • 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.

  • 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?

  • by wangmaster ( 760932 ) on Saturday January 18, 2020 @04:09PM (#59633362)

    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.

  • because Docker is dead/dying? sleeping with a corpse is not good for your health.
  • I think Red Hat saw the writing on the wall but they're a bit too early, in my opinion. We're in a transition period right now. It looks like docker is going to wither away but it may take years. I admin both docker-ce and Docker Enterprise at my company. We're a Red Hat shop but RH dropping docker support was one item on a small list of reasons why we're bringing in Ubuntu to round out our offering. At the same time I'm preparing for running docker long-term I'm also looking for dockers replacement. For Re
  • 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

  • Docker wasn't written by Lennart Poettering. Podman fixes this ;-)

  • 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

  • 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.

  • dnf install podman-docker

"The lesser of two evils -- is evil." -- Seymour (Sy) Leon

Working...