-
Notifications
You must be signed in to change notification settings - Fork 426
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Docker Compose v2, wait for healthchecks to pass #8041
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
h doesn't use the cookiecutter (yet) so we can edit these files directly in h 👍
Can you also deleted the requirements/dockercompose.{in,txt}
files?
Also these:
Line 29 in d08ae62
@echo " docker-compose in the 'h_default' network." h/docs/developing/troubleshooting.rst
Line 21 in d08ae62
* Prefix all ``docker`` and ``docker-compose`` commands with ``sudo``.
healthcheck: | ||
test: curl --fail --silent http://localhost:9200 >/dev/null | ||
interval: 3s | ||
start_period: 1m |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this necessary? Does h actually fail to start up if Elasticsearch is not running yet? I know make dev
will actually crash if Postgres isn't up yet, but I'm not sure whether the same is true for Elasticsearch and RabbitMQ. If we can avoid having to wait for Elasticsearch and RabbitMQ then we can keep things simpler (no healthchecks) and save a few seconds on the startup time
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does h actually fail to start up if Elasticsearch is not running yet?
h tries to initialize the Elasticsearch index when it starts, so you get some confusing error messages if it isn't running. Also things will just seem broken if you try to access various pages served by h during the time when Elasticsearch is starting. I think it would be better to direct efforts into speeding up Elasticsearch startup time, as it seems to me that it really ought to be possible for it to start up quicker than it currently does.
Done. I've updated / removed the various references to |
Switch to Docker Compose v2 and change `make services` to use the `--wait` flag to wait for healthchecks to pass before exiting. Also add a healthcheck for Elasticsearch. The Makefile changes follow the pattern in the lms app. Together these changes mean that h and its services can be started with `make services && make dev`, without encountering errors due to Postgres / Elasticsearch not being ready to connect. The `start_period` setting is set to a generous value (1 min) as normal startup times for ES are quite long (15-20s on my 2020 Intel MacBook Pro). See also hypothesis/lms#5556.
This was replaced by use of the globally installed Docker Compose v2 in the previous commit.
68e60f7
to
a2dc2db
Compare
Switch to Docker Compose v2 and change
make services
to use the--wait
flag to wait for healthchecks to pass before exiting. Also add a healthcheck for Elasticsearch. The Makefile changes follow the pattern in the lms app.Together these changes mean that h and its services can be started with
make services && make dev
, without encountering errors due to Postgres / Elasticsearch not being ready to connect.The
start_period
setting is set to a generous value (1 min) as normal startup times for ES are quite long (15-20s on my 2020 Intel MacBook Pro).See also hypothesis/lms#5556.
Example output from
make services
:The startup time for Elasticsearch, as measured by whether
curl http://localhost:9200
returns a non-200 response, seems rather long to me, and also somewhat variable (~17s seems more typical). It might be possible to optimize that, but it is out of scope for this PR.