Docker yields a "start" event when containers start. This, however, does not necessarily mean they can be considered up and running. Boot fills this gap.
+-----------------+ +---------+ +--------------+
| | | | | |
| Docker Daemon | | Boot | 3) started | Application |
| | 1) started! | | and ready! | using Docker |
| +-------------> [*] >>> +-------------> Socket, e.g. |
| | | v | | Traefik |
| | | | | | |
+-------------+---+ +-+-------+ +--------------+
| |
+-------v---+ | 2) ready?
| | |
| Container <---------------+
| |
+-----------+
`------------------------------------´`--------------------------------´
/var/run/docker.sock /var/run/boot.sock
When a "start" event is received on the Docker socket, Boot inspects the container and checks for boot label. If present, Boot runs this command in the container and waits for it to return. The "start" event is then passed on to the Boot socket for other applications to consume.
In the other direction, Boot simply passes all communication on to the Docker socket and replies with what it receives. This means it will work with any application currently using Docker's API to drive its business logic.
The only prerequisite to using Boot semantics is to add the label and the boot script. To set the label, either use the LABEL instruction inside the Dockerfile or pass -l boot=/boot.sh on the docker command line.
FROM debian:jessie
LABEL boot CMD /boot.sh
HEALTHCHECK CMD /health.sh
CMD ...The boot script may be something as simple as sleep 5, but you're encouraged to write more sophisticated checks to determine whether your service is actually up and running.
- docker/compose#374 and docker/docker#21142- Related issues / motivation
- fsouza/go-dockerclient - The extensive BSD-licensed docker client library used to realize this project
To contribute to Boot, use the 
way - fork, hack, and submit a pull request! If you're unsure where to start, look out for issues labeled with help wanted.
Enjoy!