Is there an healthcheck entrypoint?

[pascalandy]

As I plan to use this project along traefik in prod, an healthcheck is required. I would expect something to configure something like:

version: "3.3"

services:

  socketproxy:
    image: tecnativa/docker-socket-proxy
    container_name: socketproxy
    hostname: socketproxy
    restart: unless-stopped
    healthcheck:
      test: curl -fail http://localhost:8181/health || exit 1
      interval: 5s
      timeout: 2s
      retries: 3
      start_period: 5s
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      CONTAINERS: 1

[SuperSandro2000]

Can't you just request the /info endpoint and parse some docker specific response?

[yajo]

I never faced this yet, so if you can open a PR on how to do that, either with fixes or at least with docs, I'll be glad to review and merge.

[pascalandy]

@SuperSandro2000 I'm not sure to understand your logic.

# RUN: docker-compose -f compose-socketproxy.yml up -d
version: "3.7"

services:

  socketproxy:
    image: tecnativa/docker-socket-proxy
    container_name: socketproxy
    hostname: socketproxy
    restart: unless-stopped
    healthcheck:
      disable: true
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      CONTAINERS: 1

What do you see when you start the container and go to: http://localhost/info ?

[pascalandy]

Me either but we never know :-p

I never faced this yet

[yajo]

Since the container is exposing a subset of the docker API, I guess @SuperSandro2000 means that you should just use that API and, if it responds, it means the proxy is doing its work.

[pascalandy]

I see your logic.

But within the healthcheck context, I don't think the healthcheck function can access the docker's API (specially for this very container which is a proxy). That's why the healthcheck is using a classic ping to know if the container is alive or not.

    healthcheck:
      test: curl -fail http://localhost:8181/health || exit 1
      interval: 5s
      timeout: 2s
      retries: 3
      start_period: 5s

[yajo]

But within the healthcheck context, I don't think the healthcheck function can access the docker's API (specially for this very container which is a proxy).

Why?

[pascalandy]

Why

The healthcheck function exist because the Docker API cannot know if an APP is up or down. The test needs to happen within the container. When it fails, the the Docker API reboot the container.

[SuperSandro2000]

Just access the docker api trough the proxy. If that works the proxy works, if not the proxy does not work.

So that could work:

  healthcheck:
      test: curl -fail http://localhost:2375/v1.24/info || exit 1

[pascalandy]

I tried but the container does not start:

  socketproxy:
    image: tecnativa/docker-socket-proxy
    hostname: socketproxy
    networks:
      - ntw_proxy
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      NETWORKS: 1
      SERVICES: 1
      TASKS: 1
      # SWARM: 1
      # CONTAINERS: 1
    deploy:
      update_config:
        order: start-first
      restart_policy:
        condition: any
        delay: 10s
        max_attempts: 50
      mode: global
      resources:
        limits:
          cpus: '0.20'
          memory: 8M
    healthcheck:
      test: curl -fail http://localhost:2375/v1.24/info || exit 1
      interval: "10s"
      timeout: "5s"
      retries: 5
      start_period: "40s"

[yajo]

Are you running it on swarm? If so, make sure to run it in manager nodes.

[Ranbato]

I didn't see curl in the image so I'm doing the healthcheck with the following
healthcheck: test: ["CMD", "wget", "http://localhost:2375/version"] interval: 29s timeout: 2s retries: 3 start_period: 21s
I use it to force the containers that depend on it to start up after it.

[SuperSandro2000]

You need to pass --spider to wget.

[pascalandy]

I didn't test it yet, but I feel this makes sense:

version: "3.7"

services:

  socketproxy:
    image: tecnativa/docker-socket-proxy
    container_name: socketproxy
    hostname: socketproxy
    restart: unless-stopped
    healthcheck:
      test: curl -fail http://localhost:2375/version || exit 1
      interval: "29s"
      timeout: "5s"
      retries: 3
      start_period: "21"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      CONTAINERS: 1

[jwillmer]

Executing curl -fail http://localhost:2375/version on my server returns: curl: (7) Failed to connect to localhost port 2375: Connection refused. Using it as healthcheck in the container put's the container to unhealthy. I use tecnativa/docker-socket-proxy:arm32v7.

test: curl -fail http://localhost:2375/version || exit 1 works for me after going into the image and installing curl. Just forgot the port mapping at first

[jwillmer]

I can confirm, that this is working:

  docker-socket-proxy:
    image: tecnativa/docker-socket-proxy:arm32v7
    container_name: docker-socket-proxy
    restart: unless-stopped
    healthcheck:
      test: wget --spider http://localhost:2375/version || exit 1
      interval: "29s"
      timeout: "5s"
      retries: 3
      start_period: "21s"
    privileged: true
    networks:
      - socket-proxy
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - CONTAINERS='1'
    # - ...
    ports:
      - 127.0.0.1:2375:2375

[alpe12]

Didn't work for me.
But:
test: wget -q "http://localhost:2375/version" -O /dev/null || exit 1
Worked.

[masterwishx]

today got unhealthy after updated docker to 26.0 i think

[masterwishx]

Working after changed to :

test: wget --spider http://docker-proxy:2375/version || exit 1

[jonasgeiler]

FYI there is also a /_ping endpoint in the Docker Engine API. Here is the command I am using: wget --spider --tries=1 http://localhost:2375/_ping || exit 1

[andrebrait]

The --tries=1 is very important, as I came to find out later. Without it and with a long enough timeout and whatnot, it would cause the docker daemon to die after a while, with a nil pointer dereferenced in some line of the health.go file.

The default --tries is 20.

[pascalandy]

I tested using docker stack deploy stkproxy -c stack-proxy.yml and I could not make healthcheck work. I guess it's a limitation of docker stack? I can't find docs about this.

Using healthcheck along docker service create is OK.

[pascalandy]

@jwillmer typo: you are missing a s

start_period: "21s"

[joao-p-marques]

If @jwillmer's solution is working, maybe we can add it to the docs and close this, then? @yajo

[yajo]

I just enabled discussions, converted this issue, and marked his as answer. It should be easy to find for others now 😊