Use health checks for Docker Compose startups

[mraible]

Overview of the feature request

Demos can be painful with Docker Compose because apps wait for 60 seconds to startup. As developers get faster machines, it might only take a few seconds for dependent containers to startup. Is it possible to do health checks to determine startup rather than waiting?

Motivation for or Use Case

It'd be nice if demos could be faster when running docker compose up.

Related issues or PR

• [x] Checking this box is mandatory (this is just to show you read everything)

[atomfrede]

You mean this generated compose file? As a starting point we could define dependencies with required healthiness.

I guess not every container implements a healthcheck which will be used, so some work to find the right solution per dependency is needed.

[mraible]

No, not app.yml. The file is named docker-compose.yml and is generated by the Docker Compose sub-generator.

[mshima]

Depends on https://github.com/jhipster/generator-jhipster/issues/19462. There are a few new features available at docker-compose v2 like health dependency. app.yml currently contains the full stack configured and is base for docker-compose generator. With service import we can organize better compose files. I've started at https://github.com/jhipster/generator-jhipster/pull/18877, but base structure refactoring should be implemented before, I will generators written in typescript =)

[sonallux]

I have just stumbled across this issue because I also do not like that a app has to wait 60 seconds for the database.

The mentioned healthcheck option in docker-compose v2 is not available in the current docker-compose version 3. So I would argue that this built-in healthcheck is not an option, because it is already outdated. Unfortunately, there is no new built-in alternative in docker-compose version 3. I really like the reasoning why docker compose has no built-in healthcheck (from https://docs.docker.com/compose/startup-order):

The problem of waiting for a database (for example) to be ready is really just a subset of a much larger problem of distributed systems. In production, your database could become unavailable or move hosts at any time. Your application needs to be resilient to these types of failures.

[mraible]

Good point. I've learned how to dance and complain about this wait for 60 seconds during demos. 😊

[mshima]

The mentioned healthcheck option in docker-compose v2 is not available in the current docker-compose version 3

Actually I think it is available at the new version https://docs.docker.com/compose/compose-file/ which is called Compose specification.

It's quite confusing but docker-compose had cli v1 and v2, while the compose file specification are version 1, 2 and 3.

The so called docker-compose v2 compose specification is version-less (the field was removed).

About the production problem, IMO is't not a problem, the compose file is fine tuned for development and testing: https://github.com/jhipster/generator-jhipster/blob/c40674efbb7ef0828627f9a6f04058e8993b2562/generators/server/templates/src/main/docker/app.yml.ejs#L19

[sonallux]

Oh, I didn't know that 👍 But it is also really confusing...

[mshima]

I wonder why keycloak became so slow to start.

[mraible]

Related to Docker Compose, I noticed the JHipster Oh My Zsh plugin needs to be updated to use docker compose instead of docker-compose or it won't work with the main branch.On Oct 27, 2022, at 12:50, Marcelo Shima @.***> wrote: I wonder why keycloak became so slow to start.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>