Skip to content
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

Feature request: add HEALTHCHECK #91

Closed
rnavarropiris opened this issue May 4, 2017 · 9 comments
Closed

Feature request: add HEALTHCHECK #91

rnavarropiris opened this issue May 4, 2017 · 9 comments
Labels
Request Request for image modification or feature

Comments

@rnavarropiris
Copy link

Docker supports defining a command to determine if the container is running as intended (healthy), broken for some reason (unhealthy) or still initializing (starting):

Adding this to this image with the semantic "the redis store is online and functional" would be quite nice.

Since the last HEALTHCHECK defined by a Dockerfile is the one actually used, images based on this one could define their own healthcheck without "interference" by the one provided by the redis image.

@rturk
Copy link

rturk commented May 30, 2017

This can be really helpful when running this image in a Kubernetes cluster

@yosifkit
Copy link
Contributor

Copying comment from docker-library/cassandra#76 (comment)

I do not feel that generalized healthchecks on the official images are really that useful.

  • users will have their own idea of what is "healthy"
  • it does not actually test that the service is listening to connections outside of localhost (see https://github.com/docker-library/healthcheck for some examples that do more than what's proposed here, including attempting to check whether the service is listening remotely)
    • some of the Official Images even purposely start in a localhost only mode for database initialization and then kill and start the main service with full network availability
  • after upgrading their images, current users will have extra unexpected load on their systems for healthchecks they don't necessarily need/want and may be unaware of

@rturk
Copy link

rturk commented Jun 21, 2017

@yosifkit humbly disagree with your comment, any service should report if can perform what is expected/required to do.

@rnavarropiris
Copy link
Author

@yosifkit
I also disagree, please see this comment

@tiredpixel
Copy link

@yosifkit, I also respectfully disagree. Please see my comment docker-library/postgres#282 (comment).

@wglambert wglambert added the Request Request for image modification or feature label Apr 25, 2018
@paulotruta
Copy link

@yosifkit , I can see the point, but also disagree with this. Docker provides this, and Kubernetes cluster maintainers use this to have basic health check capabilities with their deploys.

@wglambert
Copy link

Copying comment from docker-library/cassandra#76 (comment)

I still don't think healthchecks should be added to official images.

@tianon
Copy link
Contributor

tianon commented Oct 25, 2018

Indeed, see also https://github.com/docker-library/faq#healthcheck.

@tianon tianon closed this as completed Oct 25, 2018
@tgross35
Copy link

Very late to the party but for anyone from the future -

In general I feel that healthchecks shouldn't be enabled by default. However, it certainly isn't a bad idea to provide and document a good basic healthcheck (script included in image, command, etc) - something along the lines of "the running service considers itself to be healthy if X, and 80%+ of users would probably agree".

We're in luck; redis already has this. The following compose tidbit works well:

healthcheck:
    test: ["CMD", "redis-cli", "ping"]
    timeout: 10s
    retries: 3
    start_period: 10s

The command returns PONG if the ping successfully connects. Won't catch everything but is at least enough to report that redis is up and running.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Request Request for image modification or feature
Projects
None yet
Development

No branches or pull requests

8 participants