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 <[email protected]> | larsks @ {freenode,twitter,github} Cloud Engineering / OpenStack | http://blog.oddbit.com/
pgpD1P2Vb3KMF.pgp
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
