Slashdot Mirror


Red Hat Strips Down For Docker

angry tapir writes Reacting to the surging popularity of the Docker virtualization technology, Red Hat has customized a version of its Linux distribution to run Docker containers. The Red Hat Enterprise Linux 7 Atomic Host strips away all the utilities residing in the stock distribution of Red Hat Enterprise Linux (RHEL) that aren't needed to run Docker containers. Removing unneeded components saves on storage space, and reduces the time needed for updating and booting up. It also provides fewer potential entry points for attackers. (Product page is here.)

8 of 44 comments (clear)

  1. I know! by Anonymous Coward · · Score: 4, Funny

    I know I know! They also took out the Linux kernel, leaving only systemd.

  2. you can leave your hat on by turkeydance · · Score: 2, Funny
  3. Containers.. by BrookHarty · · Score: 4, Informative

    I've been using debian vservers in the past, and now lxc. RedHat 7 and its LXC integration is amazing. I use KVM as my hypervisor of choice, so I'm already using virtual machine manager, so now I can manage my LXC hosts with VMM, its really a nice touch.

    What really interests me is LXD. LXC containers in a real isolated container that I can just move. Right now, I'm stuck to zipping and moving LXC's directories if I want to move them. I tend to use OS containers stripped down, because I want app/tcp/ssh/nrpe installed, so I can make sure the service is alarmed, and I use ssh for remote management.

    Docker tends to be aimed at enterprise usage, if you have lots of single applications appliances, you can roll out and tear down, docker is a great idea.
    That is a different use case, so I don't need docker, but docker is built on LXC, so I get that added benefits from support from Redhat. (and Centos7 support)

    I'm running an IT shop, so my servers run for years, and I need to be able to manage, and support them. LXC containers is the perfect middle ground for me. LXD is the only thing I'm missing, moving file based containers.

    So, I'm happy docker is pushing technology, because the stack it runs on is also benefiting from it.

    BTW, I wish Redhat would support LXC VM's on its REHV (ovirt) platform, then I could consolidate even more VM's into single VM's. Guests with bridges with macs are filtered due to IP spoofing rules. Kinda silly when RedHat pushes LXC on 7, but doesn't test LXC on its Visualization platform.

  4. Re:Containers with Juju! by Bruzer · · Score: 2

    Juju is able to orchestrate both LXC and KVM on several different cloud environments. Juju employs a slightly different paradigm than Docker, building on top of cloud images rather than an image based workflow. It surprises me that Docker gets so much attention in this space. I have used both and still prefer Juju for the flexibility. With Juju I am able to nest LXC inside Amazon instances or use LXC on my laptop to make it appear as cloud environment.

    A quick google search turns up a document on this very subject (not written by me):
    https://insights.ubuntu.com/wp...

    --
    "Tempt not a desperate man" - Willy S.
  5. Re:define terms in article summary by Anonymous Coward · · Score: 2, Interesting

    Funny thing is, most people working in the DevOps field are generalists (myself included). People with a mix of infra and development backgrounds, with a broad range of skills across multiple disciplines, and maybe one or two "deep" skills. I spent years bouncing between system administration and development and couldn't make my mind up which direction I wanted to take because everything was interesting and I wanted to play with ALL the things. Then DevOps became more than an obscure buzzword and I found my home :)

    Docker isn't perfect, there's still a few issues that they need to address, but the idea of running version controlled micro services in portable, lightweight containers seems like the way of the future.

    I'd be interested to see which distro can get their image down to the smallest (functional) size. Strip the OS down to just the absolute minimum required to boot it up, then leave it upto the docker image creators to decide what services to enable. It's a great way to minimize attack vectors, keep image size down and make the container nice and lightweight.

  6. Re: Systemd is tearing apart the Linux community. by sce7mjm · · Score: 2

    I suggest most sysadmins not wanting systemd haven't upgraded their distribution to the systemd one. So there's a fair chance that your wrong.

    Most sensible sysadmins will be testing their systems to either use systemd and cope with the change or attempting to coerce their distribution to operate without it, before they role out the upgrade.

    Systemd may have won with the sheep, blindly following.

    I tried a dist upgrade from Wheezy to jessie on a VPS and it failed (would not boot). I had to roll back the image.

    Plenty of people looking for a reliable upgrade path like Debian used to have but are wary of what trouble this adoption could cause.

    The exodus probably hasn't even begun. However systemd could prove to be reliable in the long term and the majority might end up using it on desktops and servers, but that hasn't happened yet.

  7. Re:define terms in article summary by Tom · · Score: 3, Insightful

    I'd be interested to see which distro can get their image down to the smallest (functional) size.

    LFS, of course. Or any other non-distro approach. What do you need a distro for if all you want is the kernel and basic system functions? It's not so difficult to start with zero and get to a shell prompt. Been there, done that.

    The really interesting approach would be to have a deployment distro - a way to add packages to such an image from outside, without having all the packaging crap and its dependencies on the image itself.

    I think what you really want is a build system that can install to the image.

    --
    Assorted stuff I do sometimes: Lemuria.org
  8. eh? by coofercat · · Score: 2

    I don't get it... what's the for? is it for the host running the containers, or for the containers themselves?

    I set up a bit of Docker goodness at work because I needed to do some stuff in RHEL5, 6 and 7 sort of simultaneously. I found getting the base image of a RHEL system into a container to be annoyingly hard - first of all, you somehow have to know what all the bajillions of 'base' packages are that you're going to need. Then you make your container and spin it up to a bash prompt. Great - all looking good, right? Wrong. For any other packages you want to install you need an RPM repo, only Redhat give you a satellite - for which you need a client license. You'll need one of those for every container you ever create - that can't be right, can it?

    Maybe I'm completely missing the Chosen Path here, but getting Dockers up and going in an enterprise setting seems remarkably fiddly. That said, being able to spin up a considerably smaller container would be very welcome. I'm not so sure having a stripped down host to run them on necessarily excites me all that much, but whatever it takes to get the bloat out of distributions is fine with me.