Even though services are deployed with the restart=always docker parameter meaning when the service fails to boot (for instance, song-api wll not boot if it cannot create a connection to the song-db database), it restarts automatically.
Without this, the user will know that all services were successfully deploy, but will not know if they are healthy and ready to use. In the genomics data playground, readyness was manually checked on a per service basis by doing curl or docker exec commands.
With this feature, we can not only deploy song-api when the song-db is ready, but we can also block program exit until something exceeds the retry count or until everything succeeds.
This will require:
- ability to query and process the state of a depoyment
- retry the healthcheck with a back-off retry schedule, and report the failures
- make healthchecking optional, with a switch (cli)
Even though services are deployed with the
restart=alwaysdocker parameter meaning when the service fails to boot (for instance, song-api wll not boot if it cannot create a connection to the song-db database), it restarts automatically.Without this, the user will know that all services were successfully deploy, but will not know if they are healthy and ready to use. In the genomics data playground, readyness was manually checked on a per service basis by doing curl or docker exec commands.
With this feature, we can not only deploy song-api when the song-db is ready, but we can also block program exit until something exceeds the retry count or until everything succeeds.
This will require: