4 ms·

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!
        contingencies 13y ago
        I think you missed, misunderstood or disagree with the phrase in its conventional systems administration utilization with regards to ssh's evilness in production. I think its one of the latter two because of your third paragraph there, where you slam the model under proposal (the disposable service container) as a nonexistant dream. Well, let me tell you, it exists and it works. I think most large companies use something similar (Google, etc.) because scaling any other way is too expensive. Disposable service containers are 100% predictable copies of well tested system images that never, ever get logged in to or altered... only started, communicated with, or destroyed in very well defined ways. They are not allowed to accrue undocumented state, because there be dragons.

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!
      - contingencies 13y ago
        I think you missed, misunderstood or disagree with the phrase in its conventional systems administration utilization with regards to ssh's evilness in production. I think its one of the latter two because of your third paragraph there, where you slam the model under proposal (the disposable service container) as a nonexistant dream. Well, let me tell you, it exists and it works. I think most large companies use something similar (Google, etc.) because scaling any other way is too expensive. Disposable service containers are 100% predictable copies of well tested system images that never, ever get logged in to or altered... only started, communicated with, or destroyed in very well defined ways. They are not allowed to accrue undocumented state, because there be dragons.