Red Hat Enterprise Linux 7 Atomic Host Beta [LWN.net]

Red Hat has announced the availability of the first public beta of Red Hat Enterprise Linux 7 Atomic Host. "Red Hat Enterprise Linux 7 Atomic Host Beta provides a streamlined host platform that is optimized to run application containers. The software components included in Red Hat Enterprise Linux 7 Atomic Host Beta, as well as the default system tunings, have been designed to enhance the performance, scalability and security of containers, giving you the optimal platform on which to deploy and run application containers."

to post comments

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 11, 2014 19:49 UTC (Tue) by SEJeff (guest, #51588) [Link] (36 responses)

This is likely bad/bittersweet news for CoreOS. It is hard to compete against a company like RedHat when you're trying to build a distro.

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 11, 2014 21:14 UTC (Tue) by johannbg (guest, #65743) [Link] (19 responses)

They have the best container solution so I think they will be fine...

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 11, 2014 21:19 UTC (Tue) by SEJeff (guest, #51588) [Link] (18 responses)

What do you mean exactly? They use docker for their container solution, same as Project Atomic.

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 11, 2014 22:02 UTC (Tue) by johannbg (guest, #65743) [Link] (17 responses)

Dont focus on Docker and the fact it can be and probably will be replaced with something better in the long run and that CoreOS was riding that hyped wave from it's early start , focus on the CoreOS itself, it's bare bones design and automatic updates etc.

CoreOS takes the OS itself out of the equation while being flexible and adaptable to frequent changes on the coreOS itself while allowing complete focus on the application.

Redhat and the rest of the docker tail is stuck in the ( traditional ) past since they cant sacrifice the OS which their end users have grown accustomed to.

Try to view atomic more of Redhat validation of the CoreOS approach then a competing solution.

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 11, 2014 22:12 UTC (Tue) by dowdle (subscriber, #659) [Link] (3 responses)

I know CoreOS wants to be able to update the OS automatically without breaking things... like Google did for their Chrome Browser (their analogy, not mine)... and that it is based on Gentoo... but other than that, I'm not aware of any significant underlying architectural change.

Virtualization product makers have been building stripped down OS install releases just for virtualization (machine or OS/container) hosts for a decade now. I fail to see what is unique or innovative about CoreOS... so please enlighten me.

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 11, 2014 22:37 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

CoreOS is used to host _applications_, not virtual machines. There's a big difference here.

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 11, 2014 22:49 UTC (Tue) by dowdle (subscriber, #659) [Link]

Yeah, that's the Docker part of it... that we were told not to focus on.

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 11, 2014 23:15 UTC (Tue) by johannbg (guest, #65743) [Link]

Their focus on how to deploy containers as an first approach, not the traditional/classic physical or virtual deployment and ( small ) base infrastructure with applied updates and integration into systemd and baseOS/coreOS and the tools that come with it, is what's brilliant about it.

Bundled the cloud-config.yml into the initramfs in the PXE image, boot the CoreOS via PXE and off you go, scale fast, the sky is the limit.

I see fresh mindset,flexibility and innovation in it and I love it.

You see more of the same or blast from the past.
Bottom line not all great minds think alike.

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 11, 2014 22:49 UTC (Tue) by SEJeff (guest, #51588) [Link] (11 responses)

Not sure what you really mean. RHEL Atomic uses ostree[1] pretty much *exactly* in the same way CoreOS uses the same update mechanism ChromeOS does for binary deltas and "atomic" upgrade or rollback bits. Project Atomic (the Fedora or RHEL variant) aren't a traditional OS by any remote stretch of imagination. The are an unbelievably minimal operating system built to only run containers exactly like CoreOS. Additionally, they don't use rpms for their package manager, but ostree.

So... your entire comment is pretty much misguided. While I agree that this validate's CoreOS's approach, RedHat's Atomic is almost like for like a competitor against CoreOS:

[1] https://github.com/projectatomic/rpm-ostree

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 11, 2014 23:18 UTC (Tue) by johannbg (guest, #65743) [Link] (1 responses)

Are updates automatically applied on Atom?

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 12, 2014 14:12 UTC (Wed) by walters (subscriber, #7396) [Link]

Not at the moment, but adding this as an easy to use available feature is on the road map.

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 11, 2014 23:26 UTC (Tue) by johannbg (guest, #65743) [Link] (8 responses)

If RedHat's Atomic is an almost like for like a competitor against CoreOS it says more about Redhat with all it's engineering powers inability to innovate then anything else.

I guess that's what they get in return for killing innovation in Fedora.

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 12, 2014 8:22 UTC (Wed) by misc (subscriber, #73730) [Link] (7 responses)

Given that coreos reuse docker ( where RH heavily invest ), and systemd ( where RH heavily invest too ), I do not see why this is a inability to innovate from RH. Innovation is not just "we have this great idea", this is mostly a set of smaller innovation, of reusing ideas in differents settings, etc. If you go this way, coreos just reused the idea of ostree, who predate it by several years, and the idea itself have been used by chromeos ( and who was likely coming by phones and embedded setup since years, due to operational constraint ). This is also the approach used by edeploy, to manage openstack nodes.

Are you still bitter that the community didn't follow you on Fedora, as it may be better for you to maybe just move on instead of endlessly being bitter on comments systems around.

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 12, 2014 14:14 UTC (Wed) by johannbg (guest, #65743) [Link] (6 responses)

Invest != invention

Elaborate what you mean by "community didn't follow you on Fedora"

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 12, 2014 19:46 UTC (Wed) by fandingo (guest, #67019) [Link] (5 responses)

Why are you always so obtuse on this matter? You used to be active in the Fedora project, and then, something happened maybe 2-3 years ago. Now in every article that is tangentially related to Red Hat or Fedora is your soapbox to take derogatory, snide comments at them. You never elaborate on the specifics of any criticism; it's just a couple of sentences that's nothing more than *RH/Fedora bad*.

We get it: you have a personal grudge against them for whatever reason. I'm convinced you'd immediately find a way to hate them if they cured cancer.

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 12, 2014 21:03 UTC (Wed) by johannbg (guest, #65743) [Link] (4 responses)

Allow the Red Hatter to respond to his remark and sugarcoat Red Hat's oppression and misuse of contributors time in Fedora's community while it elevates it's own products over community made ones when doing so.

I will return Red Hat the same courtesy it and it's employees showed me and my contributed time in the project for the same amount of time they did ( 8 years or so or up to the point I see it change it's behaviour )while undoing my Fedora ambassador work where I encouraged individuals to participate and thus dedicate and contribute their free time to the project and inadvertently subject them to it's corporate misuse of their own free time.

And yes something happened there is always a trigger and while I'm powerless in changing the past, it is certainly within my power to change the future.

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 12, 2014 21:47 UTC (Wed) by fandingo (guest, #67019) [Link] (3 responses)

> And yes something happened there is always a trigger and while I'm powerless in changing the past, it is certainly within my power to change the future.

I can't tell if this is intentional irony. Usually when people use statements like this it's to communicate that they've "grown up" and moved beyond retribution and reprisal tactics.

I guess the most frustrating thing about your war against Red Hat and Fedora is that there doesn't seem to be *any* description anywhere on the internet of what happened and why you feel the way that you do. (This is at least the second time that I've spent time searching for what happened between you, Red Hat, and Fedora; unfortunately, I can't find even a single mailing list post that points at any friction or discord.) Instead, you criticize every new piece of technology and development that they do, but your negative experiences don't appear to have anything to do with the technology. Why can't you just give us an account of what happened, by my reckoning, around 2011? It would be far more effective at possibly convincing other people than these empty and generally baseless technical complaints about what they do. Nobody is swayed by the litany of complaints in which you engage.

This thread of comments about CoreOS vs. Atomic either isn't supported by technical facts and arguments, isn't described in enough detail for a reader to come to your conclusions or both.

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 12, 2014 22:22 UTC (Wed) by johannbg (guest, #65743) [Link] (2 responses)

There are things that happen outside mailinglists at various events and there is enough evidence publicly available on mailinglist, in trackers etc. that span my entire lifecycle with the project.

It's not my problem if you cant find it and even if you will ever be capable of finding it that wont change anything. I wont turn tail and bow down to arrogant Red Hatters that bully people and threaten to out them from the project if they dont suck up to the Red Hat desktop team and systematically prevent them from doing work in the project. What is done is done and certain things are in motion now and time will tell the outcome of those things.

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 12, 2014 23:40 UTC (Wed) by fandingo (guest, #67019) [Link] (1 responses)

Dang, I can't understand your attitude; it's baffling. What sorts of things? I don't even know what start searching. Why can't you just provide an example or two?

If you're not going to explain your position on anything, what's the point of commenting? Surely, most people comment to persuade others to their point of view or to share information, but you don't seem to care about either. Are all of your LWN comments just angry lamentations? That seems like a waste of effort.

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 13, 2014 0:22 UTC (Thu) by jspaleta (subscriber, #50639) [Link]

I have a perfect analogy for you to frame the commentary. Divorce, A very bitter divorce. As bystanders, all we can do is grieve and hope the anger dissipates.

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 11, 2014 23:21 UTC (Tue) by raven667 (subscriber, #5198) [Link]

> Try to view atomic more of Redhat validation of the CoreOS approach then a competing solution.

Given that for a container service console you aren't relying on OS libraries for your application, there is probably very little difference between running a RedHat or CoreOS or whatever brand for the underlying kernel technology, it's really competing which management console fits into your workflow better. Unlike RHEL which has a large ISV system that depends on it, CoreOS or Atomic are much more easily replaceable components and I expect competition to be fierce.

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 11, 2014 21:29 UTC (Tue) by PaXTeam (guest, #24616) [Link] (14 responses)

compete on what exactly? bullshit marketing? ;)

some choice quotes:

> applications are only run within containers, not directly on the host, creating a clear security boundary

and just the other day there was a big discussion here about this very thing and how containers don't actually contain, as far as security is concerned.

> Each container is then confined using a combination of SELinux in enforcing mode, control groups, and kernel namespaces.

and all that worked out so well in the past. i hope you guys enabled user namespaces too, just for kicks ;).

> These technologies prevent a compromised container from affecting other containers or the host

no, they don't.

speaking of bad/bittersweet news, imagine the faces of RH customers who will get owned despite the false promises...

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 11, 2014 22:15 UTC (Tue) by dowdle (subscriber, #659) [Link] (11 responses)

The whole "containers do not contain" mantra came from Red Hat's own Dan Walsh... and he is the master of SELinux... so I'm sure Red Hat isn't making outrageous claims about Atomic Host and SELinux... nor Docker. There has been quite a bit of discussion on the mailing list where the release announcement was made... but alas, I haven't been keeping up with it... mainly because I use a mature container technology for Linux... that unfortunately isn't in the mainline kernel... OpenVZ. :)

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 11, 2014 22:29 UTC (Tue) by drag (guest, #31333) [Link] (3 responses)

> The whole "containers do not contain" mantra came from Red Hat's own Dan Walsh...

No, I don't think so. I think a lot of it comes from the realization that the Linux kernel itself provides a large and difficult to manage attack surface and due to it's history of local privilege escalation exploits it's probably not going to be able to provide a very secure container environment at this time. Selinux or other things may help, but certainly not how they are shipped now in 'stable' distros. (Not to mention that most people just turn that off because it's too much of a pain for them to deal with.)

Security may benefit from containers, but it's going to be dependent on the specific circumstances and it's certainly not true in a general sense.

The real reason to containers, or any other type of virtualization, is that Linux userland makes it very difficult to run many copies of the same software side by side in the same OS image in a manageable way. It's too difficult to deploy software and configuration management is painful. Using containers to alleviate these issues can lead to cost savings on many different levels without the overhead of full virtualization.

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 11, 2014 22:43 UTC (Tue) by dowdle (subscriber, #659) [Link] (1 responses)

I'm not positive but I believe that Atomic Host has / will have container specific SELinux policies... at least that's how OpenShift works. Turning off SELinux will probably break functionality and as a result no one should be turning it off. The point is that Atomic Host is NOT a general purpose distro.

SELinux has gotten a lot easier to use... for mere mortals even... and turning it off is kinda like doing a "chmod -R 755 /" rather than learning file ownership and permissions.

While SELinux isn't a silver bullet, it is a worthy added layer in the burrito of security.

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 12, 2014 0:06 UTC (Wed) by dowdle (subscriber, #659) [Link]

Err, I meant 777 not 755. Silly fingers.

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 11, 2014 23:02 UTC (Tue) by dowdle (subscriber, #659) [Link]

A quick note on Dan Walsh and the mantra of "Containers do not contain", please see about 30 seconds into this video:

https://www.youtube.com/watch?v=zWGFqMuEHdw

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 11, 2014 22:36 UTC (Tue) by PaXTeam (guest, #24616) [Link] (6 responses)

> so I'm sure Red Hat isn't making outrageous claims about Atomic Host and SELinux[...]

in case you didn't RTFA, i was quoting from it so the above is flat out false i'm afraid (not that it was the first time either ;).

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 11, 2014 22:57 UTC (Tue) by dowdle (subscriber, #659) [Link] (5 responses)

Well they are combining it with namespaces and cgroups so it isn't just SELinux. You are part of the PAX team so you don't trust your own mother (that's a compliment, really)... but I get your point. Press releases are where one expects to find distorted reality and since I prefer technical details, yes, I avoided reading it. :)

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 11, 2014 23:59 UTC (Tue) by PaXTeam (guest, #24616) [Link] (1 responses)

> Well they are combining it with namespaces and cgroups so it isn't just SELinux.

the two features with the cleanest code and best security track record in the kernel. no.

PS: i actually trust my family over any piece of software, and i'm hopefully not the exception with that attitude ;).

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 12, 2014 14:04 UTC (Wed) by utoddl (guest, #1232) [Link]

> PS: i actually trust my family over any piece of software, and i'm hopefully not the exception with that attitude ;).

I would have perhaps said the same thing, except that I've had two family members in the last few months both independently fall for the "We're calling to help you fix your ailing computer" phone scam. I would have thought both were too savvy for that. On the plus side, they are both running Linux now, finally off of their old XP installs.

I'm getting to where the only software I trust is

yes no

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 12, 2014 1:34 UTC (Wed) by raven667 (subscriber, #5198) [Link]

It may prove irresistible to overstate the security claims to sell this stuff, which works out ok until it doesn't. Containers may not contain but that doesn't mean they aren't broadly useful to efficiently share hardware as long as all the applications on the same box are in the same security domain.

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 12, 2014 1:37 UTC (Wed) by jb.1234abcd (guest, #95827) [Link] (1 responses)

"Well they are combining it with namespaces and cgroups so it isn't just SELinux."

Failure on both counts (SELinux, namespaces):
http://www.projectatomic.io/blog/2014/09/yet-another-reas...

This is hot air ...

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 12, 2014 8:42 UTC (Wed) by misc (subscriber, #73730) [Link]

Docker use namespaces ( and while it doesn't contains everything perfectly, it still contains and so still contribute to proper security by preventing part of the information leakage from one container to the others ).

And systemd use cgroups to limit one container to make the others be unavailable by making a dos. That count as security, if we take in account the availability part of the service.

So I am not sure what you mean by "this is hot air", unless you want to say "this is the cloud" ?

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 12, 2014 8:36 UTC (Wed) by misc (subscriber, #73730) [Link] (1 responses)

While exploits can always exist for all technology, they are exploits, not design.

There is a difference between the trivial "I add someone to the docker group and he can do a magic bind mount on /etc/passwd to edit it" and "someone found a 0 day in the kernel and got root". The first one is what is tried to be prevented inside project atomic, by using selinux, by using cgroups to limit dos ( at least actual ), the 2nd one is a bit harder and will likely happen anyway ( with a frequency that depend on the quality of the software and the number of people motivated to make audit and find issues ).

And regarding competition, it seems there is demand out there for this, so this is were the competition will be. The fact that you seems to not need or not want this just mean that you have a different set of priority and a different workload than a different set of people, which is not unsurprising.

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 12, 2014 12:28 UTC (Wed) by PaXTeam (guest, #24616) [Link]

> While exploits can always exist for all technology, they are exploits, not design.

exploits don't exist for technology. exploits exist for exploitable bugs. bugs can occur either in the design, or the implementation or the configuration or other parts of the system's lifecycle.

> There is a difference between the trivial [one bug] and [some general bug category].

what is that difference (besides the former being part of the latter)?

> The first one is what is tried to be prevented inside project atomic[...]

wrong, this is straight from the article (that i already cited btw):

> These technologies prevent a compromised container from affecting other containers or the host[...]

you can't achieve that by doing only the former.

> the 2nd one is a bit harder

while you're explaining what this 2nd one is exactly (see my question above the difference), i'd also like to learn how it's only a 'bit harder' (hint: kernel security is one of the hardest and still unsolved problems).

> and will likely happen anyway

what is likely to happen? and how do you think it'll happen?

> The fact that you seems to not need or not want this[...]

what fact? quote me back or you made this up ;).

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 13, 2014 0:59 UTC (Thu) by dowdle (subscriber, #659) [Link]

Just wanted to reiterate that Atomic Host is really Red Hat's second container system... with the various flavors of OpenShift being the first. Red Hat wasn't really fond of the term container so for OpenShift they call(ed) them gears... and they have geard to manage them. As I understand it, a gear is really nothing more than an alternative directory tree (perhaps with some bind mounts from the host) from where a service/process is executed within a namespace... controlled by cgroups... and secured as best as possible with a highly customized SELinux policy... and git as the recommended deployment tool.

I think Red Hat took quite a bit of the design of and techniques used in OpenShift (which they obviously still promote and support) and applied them to Docker and ostree. If Atomic Host is kinda like CoreOS (and I don't know enough about CoreOS to say), I definitely wouldn't call it a blatant rip-off.

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 11, 2014 21:57 UTC (Tue) by cyperpunks (subscriber, #39406) [Link] (4 responses)

Is it really possible to get customers to paid for something like this?

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 12, 2014 0:27 UTC (Wed) by eean (subscriber, #50420) [Link]

I would trust Red Hat to understand the answer to that question very well.

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 12, 2014 4:23 UTC (Wed) by mmeehan (subscriber, #72524) [Link] (2 responses)

Sure. It's about trust, relationship, and support. Clients that already have RHEL contracts will use it. Potential clients that are running into limitations in CoreOS will find that Red Hat is very good at converting client dollars into OS features, thus driving them to Atomic. In time, a CentOS variant will emerge for low cost/entry level consumers.

Why do you think customer interest would be low?

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 12, 2014 8:52 UTC (Wed) by misc (subscriber, #73730) [Link]

There is already a centos version for people wanting to test :
http://www.projectatomic.io/blog/2014/11/centos-atomic-si...

And people would pay for the stability, the support and the longer lifecycle. Project atomic reuse the RHEL kernel, so you kinda get tested and validated on the hardware before receiving the update, which seems to be something that people would be happy to pay for. I did had from time to time regression on rawhide or Fedora with newer kernel, especially when the intel wifi driver was a bit in flux. Things got better now ( or , but I can see why "we decide to not pay our software, but our 500 nodes cluster is having intermittent crashs, we posted on lklm to have a patch that we will deploy maybe in 3 months" is not something that may be accepted by all.

ANd I think that there is also people that realize that free software contributors also need to eat, so paying for their work permit to have them work full time, push new features, and give a bargaining advantage with others editors. There is indeed people paying for the feedback path between a company that serve as intermediary between free software communities and the said communities. ( ie, you enter feedback and money on one side, and there is patch and feedback on the other ).

Red Hat Enterprise Linux 7 Atomic Host Beta

Posted Nov 13, 2014 3:34 UTC (Thu) by salimma (subscriber, #34460) [Link]

Those already exist, in fact:

http://www.projectatomic.io/download/

In-container userspace updates?

Posted Nov 12, 2014 23:55 UTC (Wed) by wtogami (subscriber, #32325) [Link] (16 responses)

In practice how good of a job is done in container deployments to keep the userspace within the container updated? From what I've seen many users of containers don't bother to update the OS inside containers.

In-container userspace updates?

Posted Nov 13, 2014 0:48 UTC (Thu) by dowdle (subscriber, #659) [Link] (15 responses)

From what I've gathered... the biggest use case for containers, from a Docker-ish point of view, is to... create a container that services something and when you don't need it anymore throw it away. In that use case you often don't care about keeping it around... so periodically you update the base image(s) so that when new containers are created they are up-to-date. That is to say, they often don't live long enough to want to update a running container.

In-container userspace updates?

Posted Nov 13, 2014 7:41 UTC (Thu) by mbunkus (subscriber, #87248) [Link] (3 responses)

That's one thing I still don't understand about all this shiny new container-based app world. Pretty much each and every application I run on a server needs either special configuration (think port number to listen on or path to web pages to deliver etc) or stores some kind of data (think databases). How is this kind of data supposed to be managed if to update means to throw away the container and re-deploy a newer version?

The other thing I don't get is security handling. If libssl.so has yet another bug do I… throw away all containers that I have running that might do something with SSL, re-download them from some repository hoping those new containers come with a newer and patched version of libssl.so and re-deploy those?

In-container userspace updates?

Posted Nov 13, 2014 7:47 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Data is kept in a dedicated storage, mounted separately from the other system.

In-container userspace updates?

Posted Nov 13, 2014 7:58 UTC (Thu) by mbunkus (subscriber, #87248) [Link] (1 responses)

That makes sense.

And what about major version updates of the application in question? Distributions are usually pretty good in making the appropriate adjustments themselves; e.g. for PostgreSQL this often means a full dump, re-creating the clusters, restoring the dumps. Do containerized apps think about such things as well?

In-container userspace updates?

Posted Nov 14, 2014 8:12 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

Major upgrades are not handled well. And you really can't do them automatically in many cases, especially if there are breaking changes between package versions or if you have huge amounts of data to convert.

In-container userspace updates?

Posted Nov 14, 2014 7:51 UTC (Fri) by wtogami (subscriber, #32325) [Link] (10 responses)

Developers around me are very excited about Docker because it easily enables the development, testing and deployment environment to be identical. It is touted as far more than a temporary environment.

That does have some real benefits but I'm concerned that most of these containers will not be adequately updated. That is on top of the current impossibility of nested LSM enforcement within containers.

In-container userspace updates?

Posted Nov 14, 2014 19:14 UTC (Fri) by dlang (guest, #313) [Link] (9 responses)

I understand how developers love this, but having been there and done that, managing systems strictly by the 'make this gold image and replicate it everywhere' isn't enough for the long term.

you need to plan for the major upgrades where you have to recreate the gold image.

And once you have the tools in place to do that, then the difference between the 'gold image replicated' and 'build an identical system' shrink drastically.

That's not to say that replicating a gold image doesn't still have a place, it's far faster to install and bring up fully prepped gold images than to bring up a base OS and install all the needed packages.

In-container userspace updates?

Posted Nov 14, 2014 19:22 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

Except that with the old set of tools you can only update the _whole_ image, including local configuration bits and logs in /var/log.

It's very hard to separate classic dumb images into static code and dynamic configuration/data parts.

So in lots of cases people have to use complicated software configuration management tools like Chef or Puppet to maintain the systems.

In-container userspace updates?

Posted Nov 14, 2014 20:15 UTC (Fri) by dlang (guest, #313) [Link] (5 responses)

> It's very hard to separate classic dumb images into static code and dynamic configuration/data parts

having written my own configuration management tools, it really isn't that hard.

It does mean that you need to think about your layout and where you have configuration data. You also have to figure out how to migrate your configurations over time (including when you have to migrate configs from one software package to a different package that replaces it's functionality)

I've done completely automated migrations from one linux distro to another (unrelated distros, not like debian/ubuntu) and across major version upgrades that not only changed versions, but changed what packages are used for key functionality.

The problem is that anything you do requires figuring out where all your configs are, and people would very much like to not have to do that, so the Docker approach of 'just replicate everything' is extremely attractive.

It's even a good first step from maintaining everything manually. The mistake is in thinking it's the solution rather than just a useful tool

In-container userspace updates?

Posted Nov 14, 2014 20:37 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

The problem with classic tools is that you have to do upgrades within each instance. You can't just drop in new image with baked-in updated packages and expect everything to continue working unless you do everything extremely carefully.

We've tried to use an immutable base images with AUFS (I think) overlays with local configuration back in the early 2000-s. It turned out to be too much hassle for little return.

> The problem is that anything you do requires figuring out where all your configs are, and people would very much like to not have to do that, so the Docker approach of 'just replicate everything' is extremely attractive.
Exactly. If that step can be easily automated then why bother?

In-container userspace updates?

Posted Nov 14, 2014 20:45 UTC (Fri) by dlang (guest, #313) [Link] (3 responses)

>> The problem is that anything you do requires figuring out where all your configs are, and people would very much like to not have to do that, so the Docker approach of 'just replicate everything' is extremely attractive.
>Exactly. If that step can be easily automated then why bother?

I'm not sure which step you are meaning.

I don't believe that figuring out where your configs are is automatiable at all, let alone easily.

You can just replicate everything, but that falls apart when you try to upgrade. I expect that just like virtualization, people are going to try and use container tools like Docker to try and avoid upgrades. This will work for a while, but eventually you will need to upgrade and it will be very painful.

It's better to upgrade frequently so that it is a known and well understood process, becoming a non-event, than it is to try and avoid upgrades.

In-container userspace updates?

Posted Nov 15, 2014 5:52 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> You can just replicate everything, but that falls apart when you try to upgrade. I expect that just like virtualization, people are going to try and use container tools like Docker to try and avoid upgrades. This will work for a while, but eventually you will need to upgrade and it will be very painful.

Docker _forces_ you to separate configuration/data and static code by discarding all the changes each time you stop a container.

In the bad old days, it was just too easy to overlook something and accidentally rewrite it during an image upgrade. And since upgrades were considered risky, sysadmins were often reluctant to update the base image, preferring instead to resort to: "I'll just execute this small apt-get update script on all nodes"

In-container userspace updates?

Posted Nov 15, 2014 15:10 UTC (Sat) by walters (subscriber, #7396) [Link] (1 responses)

Only if you "docker run --rm", which is a very good idea, but not the default.

In-container userspace updates?

Posted Nov 15, 2014 17:18 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

Without --rm the files you modified in the container are left on the host after Docker container exits. However, the next invocation of "docker run" will NOT use them, it'll start from scratch.

In-container userspace updates?

Posted Nov 15, 2014 1:40 UTC (Sat) by kjp (guest, #39639) [Link] (1 responses)

Bingo. This is total hype. We have the Amazon AMI building down to a few short and sweet shell scripts, to rebase on a new OS at any team. (And dev/test/prod uses the same AMI of course, duh why would anyone not do this. The real issue is configs being different, which is always a hard problem).

Hype Cycle: NoSql "eventual consistency", "chef/puppet", now "docker". Please. It's amazing how often one needs to call 'bullshit' in the IT industry.

In-container userspace updates?

Posted Nov 15, 2014 2:02 UTC (Sat) by dlang (guest, #313) [Link]

yep, the trick for long term success is to look at each of the new things and figure out where it's useful and what the nugget of good is in the middle of all the hype

It's been that way for decades, and I have no expectation that this will ever change.