8 ms·

Project Atomic: Deploy and Manage Your Docker Containers

67 points by crb 13y ago

eloff 13y ago
What's the advantages/disadvantages when compared with CoreOS? They seem to be direct competitors.
- ermintrude 13y ago
  It's Redhat trying not to get left out when the container revolution starts.
  - pinko 13y ago
    That's actually a very helpful piece of information, as I hadn't noticed the tiny RedHat line at the bottom--thank you! But it still leaves open the original question about advantages/disadvantages vs. CoreOS.
    - contingencies 13y ago
      Concerns: http://www.projectatomic.io/docs/inter-container-networking/ http://www.projectatomic.io/docs/inter-container-networking/ is obtuse. IPv4 only. Complete lack of any nod to portability (off systemd, off iptables, off Linux...). Daemon-centric architecture where http://www.projectatomic.io/docs/geard/ http://www.projectatomic.io/docs/geard/ always runs as root. SSH access to live applications is apparently encouraged as a feature. How many of these also hold for CoreOS? Probably less, but definitely some.
      - peterwwillis 13y ago
        If by 'obtuse' you mean 'clear to anyone who has used iptables', sure. Sure, IPv6 would be nice, and it's probably not hard to add support for. Portability? You're talking about a Fedora-based Linux distribution and complaining that it might not be as portable as CoreOS, a completely custom distribution, running a Linux-only container system?! And "daemon-centric architecture", what the hell is that? Anything that sits in the background is a daemon. Considering it supports SELinux out of the box, and geard supports HTTP instead of unix socket controls, root isn't necessary or a safety concern. And what exactly is the problem with SSH access?
        contingencies 13y ago
        By obtuse I meant arguing that local port forwarding was somehow adding something elegant here. Arbitrary protocols would be ideal. I didn't mention portability to where, but we agree there's a clear limitation. By daemon-centric architecture I mean that state is maintained and exchanged between the guest and host rather than the host inflicting its version of truth upon the guest (shut down, start again with new settings), which is arguably cleaner for disposable service containers (even those requiring persistent storage). Linux has supported SELinux out of the box for 15 years, but it doesn't mean that it is easy to configure or gets used properly. Manipulating live services via SSH is an anti-pattern because it removes repeatability/predictability by causing undocumented state to accrue in guests, ultimately resulting in wasted time chasing down bugs that someone introduced by accident. To put this another way - the whole attraction of containers is disposable environments: SSH in its conventional systems administration utilization is their antithesis.
        peterwwillis 13y ago
        SSH is an encrypted protocol for communication with remote hosts. You don't have to allow the use of 'bash', but can still take advantage of all the networking, encryption, authentication, etc capabilities afforded by SSH. Nobody's stopping you from scp'ing files and then calling puppet using ssh. Seeing as virtually all modern network appliances support using SSH for transferring configs as well as a maintenance and rescue channel, it's probably not harmful to allow its use in a virtual container, and each org can decide how it manages its use. I for one don't really care much about root vs non-root in terms of host security. Even if you patch your kernel, without using grsec/SELinux/etc somebody'll just find another priv escalation hole next year and own your host with an unprivd user. If you actually focus on securing the host and applications, userland exploits have the same effect: little. I don't think there's such a thing as a disposable service container. If it's a multi-user service it's got certain intrinsic properties you can't avoid. You have to be able to configure it, run it, use it, maintain it, troubleshoot/debug it, monitor it, etc. Who's "inflicting truth" doesn't matter as long as you can do all of the normal administration tasks required of multi-user network services. This, by the way, is where SSH becomes incredibly useful. Configuration management is not a panacea. Things like Docker already do weird custom things to your service very similar to iptables-mangling rules, and nobody seems to have complained about it yet. It was only recently that they stopped mangling stock binaries like init in your image!
- peterwwillis 13y ago
  CoreOS uses a "dual root" setup to stage upgrades. Atomic uses rpm-ostree to stage upgrades. Both require reboots and the bootloader to roll back changes. Both will let you run Docker containers. CoreOS doesn't seem to support SELinux natively, but Atomic does. (Probably related to the fact that Atomic is a normal-ish linux distro and CoreOS is totally custom) Atomic gives you a web interface to manage running services. I am not aware of a similar tool [Cockpit] on CoreOS. Atomic uses geard as an interface to installing Docker containers into systemd and running them. It's a part of OpenShift. It seems to be abstraction that you can use to control more parts of the "orchestration" of large systems, plugging in zookeeper/etcd/serf for the backend configs. Seems like they have a strong focus on the real-world security of their application clusters. https://github.com/openshift/geard/blob/master/docs/orchestrating_geard.md https://github.com/openshift/geard/blob/master/docs/orchestr...
sciurus 13y ago
Interesting to see that this is based on OStree, a tool for managing "bootable, immutable, versioned filesystem trees.". Project page: https://wiki.gnome.org/Projects/OSTree https://wiki.gnome.org/Projects/OSTree Relevant HN discussion: https://news.ycombinator.com/item?id=6277518 https://news.ycombinator.com/item?id=6277518
peterwwillis 13y ago
Is there some new law of software engineering that says you can't release a server tool if it doesn't first have a flashy website?
- wmf 13y ago
  Marketing works. I don't think it's a new law.
  - teacup50 13y ago
    Unfortunately, what it works at isnt presenting complex technical information in a way that allows engineers to concretely evaluate the implementation and claims. Quite the opposite: bereft implementations and retread ideas are pasted over by fancy marketing. The rise of buzzword marketing shine has been bad for our industry.
- bencord0 12y ago
  There are exceptions. http://www.libressl.org/ http://www.libressl.org/

67 points by crb 13y ago

eloff 13y ago

What's the advantages/disadvantages when compared with CoreOS? They seem to be direct competitors.

ermintrude 13y ago
It's Redhat trying not to get left out when the container revolution starts.
- pinko 13y ago
  That's actually a very helpful piece of information, as I hadn't noticed the tiny RedHat line at the bottom--thank you! But it still leaves open the original question about advantages/disadvantages vs. CoreOS.
  - contingencies 13y ago
    Concerns: http://www.projectatomic.io/docs/inter-container-networking/ http://www.projectatomic.io/docs/inter-container-networking/ is obtuse. IPv4 only. Complete lack of any nod to portability (off systemd, off iptables, off Linux...). Daemon-centric architecture where http://www.projectatomic.io/docs/geard/ http://www.projectatomic.io/docs/geard/ always runs as root. SSH access to live applications is apparently encouraged as a feature. How many of these also hold for CoreOS? Probably less, but definitely some.
    - peterwwillis 13y ago
      If by 'obtuse' you mean 'clear to anyone who has used iptables', sure. Sure, IPv6 would be nice, and it's probably not hard to add support for. Portability? You're talking about a Fedora-based Linux distribution and complaining that it might not be as portable as CoreOS, a completely custom distribution, running a Linux-only container system?! And "daemon-centric architecture", what the hell is that? Anything that sits in the background is a daemon. Considering it supports SELinux out of the box, and geard supports HTTP instead of unix socket controls, root isn't necessary or a safety concern. And what exactly is the problem with SSH access?
      - contingencies 13y ago
        By obtuse I meant arguing that local port forwarding was somehow adding something elegant here. Arbitrary protocols would be ideal. I didn't mention portability to where, but we agree there's a clear limitation. By daemon-centric architecture I mean that state is maintained and exchanged between the guest and host rather than the host inflicting its version of truth upon the guest (shut down, start again with new settings), which is arguably cleaner for disposable service containers (even those requiring persistent storage). Linux has supported SELinux out of the box for 15 years, but it doesn't mean that it is easy to configure or gets used properly. Manipulating live services via SSH is an anti-pattern because it removes repeatability/predictability by causing undocumented state to accrue in guests, ultimately resulting in wasted time chasing down bugs that someone introduced by accident. To put this another way - the whole attraction of containers is disposable environments: SSH in its conventional systems administration utilization is their antithesis.
        peterwwillis 13y ago
        SSH is an encrypted protocol for communication with remote hosts. You don't have to allow the use of 'bash', but can still take advantage of all the networking, encryption, authentication, etc capabilities afforded by SSH. Nobody's stopping you from scp'ing files and then calling puppet using ssh. Seeing as virtually all modern network appliances support using SSH for transferring configs as well as a maintenance and rescue channel, it's probably not harmful to allow its use in a virtual container, and each org can decide how it manages its use. I for one don't really care much about root vs non-root in terms of host security. Even if you patch your kernel, without using grsec/SELinux/etc somebody'll just find another priv escalation hole next year and own your host with an unprivd user. If you actually focus on securing the host and applications, userland exploits have the same effect: little. I don't think there's such a thing as a disposable service container. If it's a multi-user service it's got certain intrinsic properties you can't avoid. You have to be able to configure it, run it, use it, maintain it, troubleshoot/debug it, monitor it, etc. Who's "inflicting truth" doesn't matter as long as you can do all of the normal administration tasks required of multi-user network services. This, by the way, is where SSH becomes incredibly useful. Configuration management is not a panacea. Things like Docker already do weird custom things to your service very similar to iptables-mangling rules, and nobody seems to have complained about it yet. It was only recently that they stopped mangling stock binaries like init in your image!
peterwwillis 13y ago
CoreOS uses a "dual root" setup to stage upgrades. Atomic uses rpm-ostree to stage upgrades. Both require reboots and the bootloader to roll back changes. Both will let you run Docker containers. CoreOS doesn't seem to support SELinux natively, but Atomic does. (Probably related to the fact that Atomic is a normal-ish linux distro and CoreOS is totally custom) Atomic gives you a web interface to manage running services. I am not aware of a similar tool [Cockpit] on CoreOS. Atomic uses geard as an interface to installing Docker containers into systemd and running them. It's a part of OpenShift. It seems to be abstraction that you can use to control more parts of the "orchestration" of large systems, plugging in zookeeper/etcd/serf for the backend configs. Seems like they have a strong focus on the real-world security of their application clusters. https://github.com/openshift/geard/blob/master/docs/orchestrating_geard.md https://github.com/openshift/geard/blob/master/docs/orchestr...

sciurus 13y ago

Interesting to see that this is based on OStree, a tool for managing "bootable, immutable, versioned filesystem trees.". Project page: https://wiki.gnome.org/Projects/OSTree https://wiki.gnome.org/Projects/OSTree Relevant HN discussion: https://news.ycombinator.com/item?id=6277518 https://news.ycombinator.com/item?id=6277518

peterwwillis 13y ago

Is there some new law of software engineering that says you can't release a server tool if it doesn't first have a flashy website?

wmf 13y ago
Marketing works. I don't think it's a new law.
- teacup50 13y ago
  Unfortunately, what it works at isnt presenting complex technical information in a way that allows engineers to concretely evaluate the implementation and claims. Quite the opposite: bereft implementations and retread ideas are pasted over by fancy marketing. The rise of buzzword marketing shine has been bad for our industry.
bencord0 12y ago
There are exceptions. http://www.libressl.org/ http://www.libressl.org/