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.)
I know I know! They also took out the Linux kernel, leaving only systemd.
https://www.youtube.com/watch?...
I hope centos team will compile this version
No, but it'll get virtualization capability sooner or later. Which might not be bad, you'd be able to run a VM of a distro without systemd.
First time I've heard systemD is "poorly coded". Most people have religious arguments against its philosophy, not the code itself.
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.
you really haven't been reading much about it then have you....
Did they strip it back down to a sane bare bones Unix?
Docker is the reason systemd is being pushed from RedHat. They need systemd to make Docker containers work. RedHat really doesn't care beans about what systemd does or doesn't do for the system admin (or user), they just have to have it.
So when they say stripped down RHEL what they're really saying is systemd and Docker. If it's needed for Docker and it doesn't already exist in systemd, then it will be added to systemd at all costs.
What are we going to be left with when the shiny wears off Docker and next year's flavour of the day comes along?
not everyone knows Docker is yet another piece of cloud wankery
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.
NSFW!!!! NSFW!!!! NSFW!!!!
Less whitespace and/or less repetition.
"warring factions"
No. Every major distro has moved to Systemd. There's no war -- Systemd won, because distro developers (you know, people who actually know their stuff) have chosen to use it. All that's left is a few crybabies on Slashdot who constantly report how they're moving 50,000 servers over to OpenBSD, but never actually do it.
There's no war here -- just a few sad losers. Try going outside or something.
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.
So you failed to upgrade to Testing and the conclusion you made from that is that systemd doesn't work? I wonder what Debian has done to break systemd so hard. Fedora has been using it in production for almost four years now, and it's fine.
What are we going to be left with when the shiny wears off Docker and next year's flavour of the day comes along?
Something better.
As is generally the case with progress.
My best bet would be that he upgraded OpenVZ based VPS, which until recently wasn't providing kernel APIs needed by Debian's systemd version to work. Fortunately OpenVZ guys patched it, though logind still fails under that virtualization (not that it is a big issue, as it doesn't have much use in most VPS based scenarios anyway). Also you can't combine systemd and OpenVZ as host kernel, which is a little bit more painful. All this is about their 2.6.32 based kernel. They wrote about opening development model and give access to 3.x branch this month or so, so let's hope we'll get stable version of it soon.
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.
This brings back bad memories. I generally stay far away from OpenVZ and anything else that requires a hacked kernel.
As I said in my post that you managed to misinterpret.
I was TESTING the dist upgrade to Jessie since jessie had been frozen.
Since the VPS was not booting I was unable to get a console up to do any investigation. This was on XEN by the way. So perhaps the particular config had an issue.
I have in the past used dist upgrade as a test to testing squeeze and testing wheezy when appropriate to spot problems that might arise, and report if not seen in the wild already. This is how open source type software gets developed and kinda works...
There seems to have been a definite change in attitude across Debian and probably other distro's.
When issues get raised responses are often "your doing it wrong" or "you can configure it to get the old behaviour back" rather than the more helpful response of "check out this bug and it's temporary solution, this should be fixed by the time the release candidate comes out..."
I can expect this attitude from the authors of software since I can choose not to use it, however packagers and distributions seem to be taking this stance as well, which means potentially accept the new package and the new way of doing things or become a second class citizen of the distribution or leave.
Perhaps it will all get sorted and perhaps I'll try jessie again and see if I can get it to boot and do some investigation as to how much change there has been, perhaps I can live with systemd. However I am not about to decide that this is the future without testing it...
In the mean time it is wheezy until security support stops and keep testing in the mean time.
wrong, systemd in Federa is pure buggy garbage, avoid it in production systems. playing with a thing as desktop proves nothing