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,

Lars Kellogg-Stedman <l...@redhat.com> | larsks @ {freenode,twitter,github}
Cloud Engineering / OpenStack          | http://blog.oddbit.com/

Attachment: pgp29hOhB_K2x.pgp
Description: PGP signature

OpenStack-dev mailing list

Reply via email to