Simple Docker Compose setup: front-end API that takes 5 seconds to start up, and a test harness that hits the API 100 times, failing if it receives any non-20x response codes.
git co fail
docker-compose up
The test should fail with something like:
test_1 | web_test.go:46: Error not expected: Get http://api/: dial tcp 172.17.0.3:80: getsockopt: connection refused
This is because Compose knows the container has started, but not the service within it.
Using Dockerize, we can ensure the tests don't run until the dependent API is up and running:
git co dockerize
docker-compose up
It is common when using tools like Docker Compose to depend on services in other linked containers, however oftentimes relying on links is not enough - whilst the container itself may have started, the service(s) within it may not yet be ready - resulting in shell script hacks to work around race conditions.
This PR gives dockerize the ability to wait for services on a specified protocol (tcp, tcp4, tcp6, http, and https) before starting the main application:
dockerize -wait tcp://web:80 -wait http://web:80
I've found this to be particularly useful when using Docker Compose as a test harness, where one of the containers needs to test another. Instead of netcating my way around the problem, I can just wrap the command using dockerize.