23
Notice: failed container health check for example.org (feddit.org)
submitted 5 months ago by to c/selfhosted@lemmy.world
18 comments fedilink hide all child comments
 

Don't exactly know what the problem is, but it seems that healthcheck curl commands to https://example.com/ currently fail, probably because of a ssl failure. This causes container that rely on this to fail. Just wanted to let you guys know.

you are viewing a single comment's thread
view the rest of the comments
[–] [S] 4 points 5 months ago (3 children)

I honestly didn't know this was the case. Still learning on this journey of self hosting. What exactly do I use for the health check then?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 10 points 5 months ago (1 child)

    The purpose of the health check is to allow docker itself to talk to whatever service is running on the container to make sure it's always responding happily, connected to everything it needs to be connected to for proper operation, and is not overloaded or stuck somehow.

    Docker does this by pretending to be a web browser, and going to the specified "health check URL". The key thing I think you're missing here is that the health check URL is supposed to be a URL that, ideally, runs on your container and does some meaningful checks on the health of your service, or at the very least, proves that when you connect to it, it is able to serve up a working static page or login page or something (which doesn't actually prove it's working completely, but is often good enough)

    Now, you're probably wondering why this isn't automatic, and the answer is because there's no standard "health check URL" that fits all services. Not all services even respond to URLs at all, and the ones that do may have different URLs for their health checks, they may need different hostnames to be used, etc.

    By setting health check URL to example.com, basically what you're doing is constantly testing whether the real-world website https://example.com/ way over there somewhere is working, and as long as it is, docker assumes your container is fine. Which it might be, or it might not be, it has no idea and you have no idea, because it's not even attempting to connect to the container at all, it's going to the URL you specified, which is way out there on the internet somewhere, and this effectively does nothing useful for you.

    It's understandable why you probably thought this made sense, that it was testing network connectivity or something, but that is not the purpose of the health check URL, and if you don't have a meaningful URL to check, you can probably just omit or disable the healthcheck in this case. Docker only uses it to decide if it needs to restart the container or alert you of the failure.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] [S] 2 points 5 months ago (1 child)

    Thank you so much for your detailed answer. That brought me up to speed. I just never questioned it and, as you said, assumed that it was to test network connectivity.

    It also finally explains the issues with those containers I kept having every few months. It always fixed itself before I had the time to actually look into it, but it has always been bugging me. This time I was able to actually catch it.

    I'll update the health checks to the proper URL im using, or should I use localhost:port?

    Anyway, thanks again!

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 5 months ago* (last edited 5 months ago) (1 child)

    the healthcheck URL should point to some HTTP API that the container makes available, so it should point to the container.

    in place of localhost should be the container's name, and port should be the port the container exposes as the web server. some services, like Jellyfin, have a specific webpage path for this purpose: https://jellyfin.org/docs/general/post-install/networking/advanced/monitoring/

    and others, like gitea, hide the fact well that they have a health check endpoint, because its not mentioned in documentation: https://github.com/go-gitea/gitea/pull/18465

    but check if docker's way of doing healthchecks produces a lot of spam in the system log, in which case you could choose to just disable health checking, because it would push out useful logs

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 5 months ago (1 child)

    If the container you're hosting has a http web service on say port 8080, then you'd want to curl something at http://localhost:8080/. The particular URL/path you hit will depend on the app. If the app is particularly cloud-y, it might even have a specific endpoint for health checking by a container platform. If you share the name of the app I might be able to point you in the right direction.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] [S] 1 point 5 months ago

    Ah, that makes sense, thanks for clearing it up for me. It's several containers but now that I know what I'm looking for, I'll be able to figure it out. I was just living in blissful ignorance until now.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 5 months ago (1 child)

    Still learning on this journey of self hosting

    No worries mate. I bet if we all posted some of the boners even seasoned selfhosters have pulled, it would make a hilarious book for nerds and geeks. Sometimes I think, 'gosh I sure am glad there wasn't anyone around to see that!'

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •