Re:The Curious Case of Linux Containers
by contingencies on Saturday December 05, 2015 @09:26PM
(#10684123)
The author's 'platform' concerns are in fact infrastructure automation concerns generic to any service-oriented architecture and not specific to containers.
My take as an early LXC adopter (way pre docker) and from-concept builder of two production clusters using custom automation:
1. Service state. The author essentially requests master-slave promotion. Corosync/pacemaker is an excellent place to look for well tested solutions here. The normal approach used there is superior to the author's, ie. a floating IP used by all clients is switched to an already live replacement master, which is first jabbed in to action, and which shares the same backing storage as the nodes which has failed. (A great solution for shared backing storage on standard hardware is DRBD)
2. MySQL update. Change management with SOA has to be far more rigid due to complex interdependencies. Typically you version your entire service, exhaustively test it against peer services, and only then deploy the updated service. This implies a workflow process more formalized than the series of manual operations the author hand-waves about. That said, in a typical database scenario it is often possible to upgrade across minor versions simply by updating the binary, since it will read the old on-disk database store fine.
3. Heartbleed. With an appropriately automated approach to service builds, this should be trivial. Mask the affected packages or versions, rebuild all services, test and deploy. This really goes back again to overall workflow formalization and automation. (Solid infrastructure would have cryptographic signoff on stuff before it runs, eg. production demands a signature from test infrastructure that all tests have passed before executing a new service)
4. Service dependencies. This is far more complex than people assume. My advice is to use corosync/pacemaker, a well tested approach. (There are others)
5. Hadoop. Same as any other service.
There are many other problems with SOA-type infrastructure automation; some ideas I wrote up ages ago can be seen at http://stani.sh/walter/pfcts/ as well as the sketch/documentation of the solution I built.
My take as an early LXC adopter (way pre docker) and from-concept builder of two production clusters using custom automation:
1. Service state. The author essentially requests master-slave promotion. Corosync/pacemaker is an excellent place to look for well tested solutions here. The normal approach used there is superior to the author's, ie. a floating IP used by all clients is switched to an already live replacement master, which is first jabbed in to action, and which shares the same backing storage as the nodes which has failed. (A great solution for shared backing storage on standard hardware is DRBD)
2. MySQL update. Change management with SOA has to be far more rigid due to complex interdependencies. Typically you version your entire service, exhaustively test it against peer services, and only then deploy the updated service. This implies a workflow process more formalized than the series of manual operations the author hand-waves about. That said, in a typical database scenario it is often possible to upgrade across minor versions simply by updating the binary, since it will read the old on-disk database store fine.
3. Heartbleed. With an appropriately automated approach to service builds, this should be trivial. Mask the affected packages or versions, rebuild all services, test and deploy. This really goes back again to overall workflow formalization and automation. (Solid infrastructure would have cryptographic signoff on stuff before it runs, eg. production demands a signature from test infrastructure that all tests have passed before executing a new service)
4. Service dependencies. This is far more complex than people assume. My advice is to use corosync/pacemaker, a well tested approach. (There are others)
5. Hadoop. Same as any other service.
There are many other problems with SOA-type infrastructure automation; some ideas I wrote up ages ago can be seen at http://stani.sh/walter/pfcts/ as well as the sketch/documentation of the solution I built.