Implement docker HEALTHCHECK

[felipecrs]

In order to implement it, I also had to implement a new environment variable JENKINS_HTTP_PORT.

Why?

My Jenkins crashes some times in the weekend, and it would be very helpful if it could auto-recover. By having the HEALTHCHECK someone could easily do:

version: "3"
services:
  jenkins:
    image: jenkins/jenkins:lts-jdk11
    restart: always
    ports:
      - 8080:8080
    labels:
      autoheal: "true"
  autoheal:
    restart: always
    image: willfarrell/autoheal
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

Also, it's useful when used in automated environments, when you could have something like below:

version: "3"
services:
  jenkins:
    image: jenkins/jenkins:lts-jdk11
    restart: always
    ports:
      - 8080:8080
  my-service:
    depends_on:
      jenkins:
        condition: service_healthy
    image: my-service

In the example above, my-service would only be started after jenkins is up and running.

Demo

[timja]

Hmm not sure if we want this or not.

For similar reasons to https://github.com/docker-library/faq#healthcheck
and docker-library/cassandra#76 (comment)

Many Jenkins instances will take a different amount of time to start up and may also setup a prefix that Jenkins runs under instead of the root.

I also don't think we should have a hard dependency on curl being available inside the image, we do plan to remove it once install-plugins.sh is removed.

Why do you want this?

A line in the docs would be fine if that would be helpful

[felipecrs]

Many Jenkins instances will take a different amount of time to start up and may also setup a prefix that Jenkins runs under instead of the root.

This is exactly my case, the startup time was not enough, and I used a prefix so, I had to override the HEALTHCHECK.

The counter measures to this would be:

1. Exposing JENKINS_PREFIX as an environment variable
2. Exposing JENKINS_HEALTHCHECK_RETRY_COUNT as an environment variable, with a reasonable default.

Or, documenting the fact that the built-in healthcheck will not work in such scenarios and thus a custom healthcheck must be implemented.

BTW, I updated the PR description with my reasonings. Can you please check it again?

[felipecrs]

A line in the docs would be fine if that would be helpful

That does the trick for me, and I'm totally okay about it. I just believe that providing a built-in healthcheck would make the image more complete. :)

It's up to you, then.

[olivergondza]

The HEALTHCHECK is a noop for kubernetes/openshift, so it needs to be (re-)declared by users in that case. Other users can add this to their Dockerfile as they pretty much need to have a custom image, if for nothing else, to have plugins installed.

Having said that, I lean towards documenting how to do healthchecking, and leaving it up to the users to implement it. The problem with timeout value is one thing, the actual end-point to use will be another. The login suggested here will not work well with SSO plugins, I presume, as they do redirect / return 401.