Feature request: add HEALTHCHECK

[rnavarropiris]

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

• https://docs.docker.com/engine/reference/builder/#healthcheck

Adding this to this image with the semantic "the postgres server 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 postgres image.

[tiredpixel]

@rnavarropiris, you might be interested to know that I've just added healthchecks to the Postgres-XL Docker project, which provides Docker images for Postgres-XL, the open-source database cluster based on PostgreSQL. The healthchecks can certainly be improved, and would in any case be slightly different to PostgresSQL healthchecks themselves (the Coordinator definitions are closest).

tiredpixel/postgres-xl-docker@9510f57

[yosifkit]

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

[rnavarropiris]

@yosifkit
I disagree:

• users will have their own idea of what is "healthy"

That's exactly what I meant in my comment when I said "images based on this one could define their own healthcheck". The image could provide a generic healthcheck with the semantic of "the server was successfully started and is ready".

If someone needs a more refined semantic for the healthcheck, then overriding it in a new image based on the official is the way to go.

• it does not actually test that the service is listening to connections outside of localhost

Fair enough, external network connectivity is hard to guarantee, but as long as the documentation states what the healthcheck does and its limitations to a local context, I don't see any problem with that.

Again, if someone has special needs for healthcheck, he can rewrite it when building his own image or just ignore the healthcheck and use custom logic.

• 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

A single "SELECT 1" query executed using the command line client directly in the server every X seconds can hardly be considered "load on their systems" (imo).

If this is indeed considered to be an issue, I find this proposal an adequate solution.

[tiredpixel]

@yosifkit, for what it's worth, I too respectfully disagree, and support @rnavarropiris 's comments. Healthchecks are really, really useful when running multiple containers in a stack, allowing not only for easy detection of basic health (yes, admittedly not through external access, but that doesn't matter so much to me; the container is more likely to be down than my entire network), but also for nice integration with restart policies. Simply having a healthcheck and a restart policy applied means that if the worst happens and my container because unresponsive, it will be restarted automatically after some time.

When I wrote the healthchecks for my Postgres-XL Docker images (https://github.com/tiredpixel/postgres-xl-docker), I took a rather extreme approach, not only checking connections but also defining a healthcheck user automatically and connecting to a database without using superuser privileges (so as to avoid the typical reserved connections). The healthchecks I wrote can certainly be improved (since they currently report an error every time regarding a user which already exists, and indeed there's no need to perform setup in the main healthcheck execution path; I'll likely change this at some point), but they allow me to check even that there are enough connections free for a client to connect. This can cause an entire broken cluster to auto-heal within a few minutes. I can't stress enough how useful these healthchecks are.

Admittedly, I could define them myself for main PostgreSQL installation-time, but then I would have to do so for every stack, and keep all of those healthchecks in sync. I would much sooner have a canonical, maintainer-supported healthcheck, which I could easily override or disable entirely if I wished.

[Mobe91]

@yosifkit I also support the comments of @rnavarropiris.
In my case I have a simple docker-compose.yml like:

version: '3.3'
services:
  postgresql:
    image: postgres:9.6.6-alpine
  web:
    depends_on:
      - postgresql

which sadly does not work out of the box because postgresql does not come with a basic health check. If users are conerned by additional load they can override or deactivate the health check either

• by extending the official docker image (HEALTHCHECK NONE, HEALTHCHECK myCustomHealthcheckCmd)
• using declarations in the docker-compose.yml:

  healthcheck:
    disable: true

  or

  healthcheck:
    test: ["myCustomHealthcheckCmd"]
    interval: 1m30s
    timeout: 10s
    retries: 3

So there is a lot of flexibility in how users can customize any predefined health check.

[tjamet]

users will have their own idea of what is "healthy"

I tend to agree with @rnavarropiris I think a health check is quite interesting, and even tried to implement such a feature in #421 that should be compatible with this statement as long as the defintion fits in a SQL query to the database defined as environment variable

it does not actually test that the service is listening to connections outside of localhost

It does not solve the assertion that service is listening outside of localhost but can be done using non loopback tcp connection to postgres.
It would not either assert that a foreign container is able to connect. This is by design as the docker healthcheck, unlike AWS ELB, executes a command within the container

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

I would not think that, if using the default 30 seconds interval, selecting one value would have a noticeable impact on system load.

[mr-bo-jangles]

I agree, I'm currently using postgres docker as part of my circleci testing and by default I'm having to bundle additional dependencies on the app side to detect if postgres is up, configured and ready (not just the port bound, but the specified role created, etc).

Such a check covering the basics of "We're exposing a port, we created the user you asked for, and db you wanted" are bare basics. if you want anything more in depth, then @rnavarropiris is right, define your own health checks.

Also if you're worried about the additional load a periodic healthcheck query is going to add, then you've got to be red-lining your setup pretty hard and so this container probably isn't for you in the first place.

tl;dr: Healthcheck should just say if we're ready to provide what we've been asked for yet, no more, no less.