On Wed, Oct 15, 2014 at 01:50:08PM -0400, David Vossel wrote:
> Something like LSB init scripts except tailored towards the container use 
> case.
> The primary difference would be that the 'start' action of this new standard
> wouldn't fork. Instead 'start' would be pid 1. The 'status' could be checked
> externally by calling the exact same entry point script to invoke the 'status'
> function.

With the 1.3 release, which introduces "docker exec", you could just
about get there.  Rather than attempting to introspect the container
to find the entrypoint script -- which might not even exist -- I would
say standardize on some top level paths (e.g., '/status') that can be
used to run a status check, and leave the implementation of those
paths up to the image (maybe they're scripts, maybe they're binaries,
just as long as they are executable).

Then you check would boil down to:

  docker exec <container id> /status

The reason why I am trying to avoid assuming some specially
constructed entrypoint script is that many images will simply not have
one -- they simply provide an initial command via CMD. Adding a
/status script or similar in this case is very simple:

   FROM original_image
   ADD status /status

Doing this via an entrypoint script would be a bit more complicated:

- You would have to determine whether or not the original image had an
  existing entrypoint script.
- If so you would need to wrap it or replicate the functionality.
- Some images may have entrypoint scripts that already provide
  "subcommand" like functionality (docker run someimage <keyword>,
  where <keyword> is parsed by the entrypoint script) and might not be
  compatible with an entrypoint-based status check.

Otherwise, I think establishing a "best practice" mechanism for executing
in-container checks is a great idea.

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

Attachment: pgpD1P2Vb3KMF.pgp
Description: PGP signature

OpenStack-dev mailing list

Reply via email to