On Tue, Oct 14, 2014 at 04:06:22PM -0400, Jay Pipes wrote: > I understand that general feeling, but system administration tasks like > debugging networking issues or determining and grepping log file locations > or diagnosing packaging issues for OpenStack services or performing database > logfile maintenance and backups don't just go away because you're using > containers, right?
They don't go away, but they're not necessarily things that you would
do inside your container.
Any state (e.g., database tables) that has a lifetime different from
that of your container should be stored outside of the container
proper. In docker, this would be a "volume" (in a cloud environment,
this would be something like EBS or a Cinder volume).
Ideally, your container-optimized applications logs to stdout/stderr.
If you have multiple processes, they each run in a separate container.
Backups take advantage of the data volumes you've associated with your
container. E.g., spawning a new container using the docker
"--volumes-from" option to access that data for backup purposes.
If you really need to get inside a container for diagnostic purposes,
then you use something like "nsenter", "nsinit", or the forthcoming
"docker exec".
> they very much seem to be developed from the point of view of application
> developers, and not so much from the point of view of operators who need to
> maintain and support those applications.
I think it's entirely accurate to say that they are
application-centric, much like services such as Heroku, OpenShift,
etc.
--
Lars Kellogg-Stedman <l...@redhat.com> | larsks @ {freenode,twitter,github}
Cloud Engineering / OpenStack | http://blog.oddbit.com/
pgp29hOhB_K2x.pgp
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
