Is this enabling any use case other than a shortcut for apt update && apt-install -y curl?

If it isn't, then I'd be a little wary of introducing a new dependency just for the sake of it.

Personally, I would use it as a Health Check for the Docker Container when running Docker Compose, against the Ready or Health Endpoint

I support the idea of incorporating curl to facilitate easier health checks. Our setup uses Podman, where health checks are performed within the container. Consequently, accessing the /-/ready endpoint directly is challenging.

For those encountering this issue, an alternative is to employ exec health checks. The following command can serve as a workaround:

/bin/bash -c 'echo -e "GET /-/ready HTTP/1.1\nHost: localhost\nConnection: close\n\n"> /dev/tcp/localhost/<application-port>'

This uses the /dev/tcp system utility to report the endpoint status!

@tpaschalis I stumbled on this when trying to install Grafana Alloy for the first time, on my cluster.

I understand the reason, for not introducing a new dependency, but curl or wget are pretty standard to have and pretty much the common way to do health checks in containers.

Having the health endpoint is kind useless if I can´t call it :)

A health endpoint would also be useful in a non-containerized situation. For example, when Grafana Alloy is installed directly on Windows or Linux, it is used to receive traces, and there is a requirement for some sort of redundancy. Would be nice to take into consideration this use case when establishing the solution.

I support the idea of incorporating curl to facilitate easier health checks. Our setup uses Podman, where health checks are performed within the container. Consequently, accessing the /-/ready endpoint directly is challenging.

For those encountering this issue, an alternative is to employ exec health checks. The following command can serve as a workaround:

/bin/bash -c 'echo -e "GET /-/ready HTTP/1.1\nHost: localhost\nConnection: close\n\n"> /dev/tcp/localhost/'

This uses the /dev/tcp system utility to report the endpoint status!

Thankyou for this kind stranger!

Method with piping to TCP descriptor (this is bash based btw!) will not take into account layer 7 HTTP request/response at all. So any endpoint would work as long as the TCP connection is established.

This already is super hacky and ugly and probably better to just extend the image for curl/wget, but we could pipe the response back by using a descriptor of our choice (i.e 42 but whatever >2 should do):

root@2d2b65251d23:/# exec 42<>/dev/tcp/localhost/12345
root@2d2b65251d23:/# echo -e "GET /-/ready HTTP/1.1\nHost: localhost\nConnection: close\n\n" >&42
root@2d2b65251d23:/# cat <&42
HTTP/1.1 200 OK
Date: Mon, 21 Apr 2025 17:21:36 GMT
Content-Length: 16
Content-Type: text/plain; charset=utf-8
Connection: close

Alloy is ready.

and then we can parse actual HTTP response and test for something like 200 status code. Whole thing;

    healthcheck:
      test: 
        - CMD-SHELL
        - |
          bash -c '
          exec 42<>/dev/tcp/localhost/12345;
          echo -e "GET /-/ready HTTP/1.1\nHost: localhost\nConnection: close\n\n" >&42;
          head -1 <&42 | cut -d" " -f2 | grep -q "^200$" || exit 1;
          exec 42<&-;
          exec 42>&-'

Seems to work, but if HC could race each other, this has some potential for side effects