[GH-ISSUE #238] Hint: Dockerized healthchecks

kerem commented

2026-02-25 23:41:27 +03:00

Owner

Originally created by @denis-ev on GitHub (Apr 2, 2019).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/238

Hello,
...
https://github.com/galexrt/docker-healthchecks

This repo works really well when you want to test/use healthchecks with docker.

All the Best,
Denis

Originally created by @denis-ev on GitHub (Apr 2, 2019). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/238 Hello, ... https://github.com/galexrt/docker-healthchecks This repo works really well when you want to test/use healthchecks with docker. All the Best, Denis

kerem closed this issue

2026-02-25 23:41:27 +03:00

kerem commented

2026-02-25 23:41:28 +03:00

Author

Owner

@rawlk commented on GitHub (May 24, 2019):

I've been using linuxserver.io's:
https://github.com/linuxserver/docker-healthchecks

Seems to work pretty ok as well

@rawlk commented on GitHub (May 24, 2019): I've been using linuxserver.io's: https://github.com/linuxserver/docker-healthchecks Seems to work pretty ok as well

kerem commented

2026-02-25 23:41:28 +03:00

Author

Owner

@decentral1se commented on GitHub (Apr 2, 2020):

Is there any motivation to move this under the project name space and provide more guarantees that it works by integrating it into the CI/CD? That'd be nice and I'd be interested in helping if so.

@decentral1se commented on GitHub (Apr 2, 2020): Is there any motivation to move this under the project name space and provide more guarantees that it works by integrating it into the CI/CD? That'd be nice and I'd be interested in helping if so.

kerem commented

2026-02-25 23:41:28 +03:00

Author

Owner

@alexanderadam commented on GitHub (May 5, 2020):

Well, there are also #194 (an open PR since 2018), #230 (a PR from Mach 2019 that ended being closed after @BobCashStory did some changes and asked whether it is fine now), #118 (another PR from 2017 about adding a Dockerfile) and also #73 (a stale PR from 2016!).

So I guess chances for an official Docker aren't very high after four years of efforts from different people. This is why there are so many inofficial images that become unmaintained at one point.

@alexanderadam commented on GitHub (May 5, 2020): Well, there are also #194 (an open PR since 2018), #230 (a PR from Mach 2019 that ended being closed after @BobCashStory [did some changes and asked whether it is fine now](https://github.com/healthchecks/healthchecks/pull/230#issuecomment-569940487)), #118 (another PR from 2017 about adding a `Dockerfile`) and also #73 (a stale PR from 2016!). So I guess chances for an official Docker aren't very high after four years of efforts from different people. This is why there are so many inofficial images that become unmaintained at one point.

kerem commented

2026-02-25 23:41:28 +03:00

Author

Owner

@cuu508 commented on GitHub (May 5, 2020):

I've been avoiding this topic, because I haven't had time or motivation to look at it properly.

Technical decisions:

What database drivers to bundle in the image? Postgres, MySQL, both?
What web server(s) to bundle in the image? gunicorn, uwsgi? Serve static files with nginx, caddy or whitenoise?
What task runner to use for running the sendalerts management command?
Should users be able to run the webserver and the background workers as separate containers?
What base image to use?
Should the Dockerfile be aimed at production use? Or for development and running tests only?

These can all be figured out, and compromises found, but it takes time and effort. I am not using containers for running the hosted service, and so have no use for the Dockerfile myself.

Now, I could accept one of the PRs, and call it job done. But what's likely to happen is the original author will move on to other things after a year or three, and I will be left maintaining it and providing support for it.

Let's also address the "maybe you don't want self-hosting to be too easy because you run a hosted service" question one might have. I'm happy with people self-hosting Healthchecks, and try to help out when I can. But don't guarantee free dev work and support. I'll accept code changes that make aspects of self-hosting easier, as long as they

fit well in the project
are not too much upfront work to review and integrate
are not too much ongoing work to maintain

In summary, I'm currently not commiting to maintain a Dockerfile. This might change if I start using containers in production for the hosted service, or if somebody sponsors this feature.

@cuu508 commented on GitHub (May 5, 2020): I've been avoiding this topic, because I haven't had time or motivation to look at it properly. Technical decisions: * What database drivers to bundle in the image? Postgres, MySQL, both? * What web server(s) to bundle in the image? gunicorn, uwsgi? Serve static files with nginx, caddy or whitenoise? * What task runner to use for running the `sendalerts` management command? * Should users be able to run the webserver and the background workers as separate containers? * What base image to use? * Should the Dockerfile be aimed at production use? Or for development and running tests only? These can all be figured out, and compromises found, but it takes time and effort. I am not using containers for running the hosted service, and so have no use for the Dockerfile myself. Now, I could accept one of the PRs, and call it job done. But what's likely to happen is the original author will move on to other things after a year or three, and I will be left maintaining it and providing support for it. Let's also address the "maybe you don't want self-hosting to be *too easy* because you run a hosted service" question one might have. I'm happy with people self-hosting Healthchecks, and try to help out when I can. But don't *guarantee* free dev work and support. I'll accept code changes that make aspects of self-hosting easier, as long as they * fit well in the project * are not too much upfront work to review and integrate * are not too much ongoing work to maintain In summary, I'm currently not commiting to maintain a Dockerfile. This might change if I start using containers in production for the hosted service, or if somebody sponsors this feature.

kerem commented

2026-02-25 23:41:28 +03:00

Author

Owner

@alexanderadam commented on GitHub (May 5, 2020):

The component/dependency questions aren't Docker specific at all.
Everyone who wants to host healthchecks has to answer those.

The more important question is: which of those components are recommended?

It is much better if maintainers give a proper default than users making decisions that they will regret.

They might provoke errors with bad decisions and might even believe that it is healthchecks' fault although it was just a bad choice of components.
The answers for the questions you asked are improving security for all users.
Furthermore you can probably improve bug reproducibility by setting sane defaults in the image.

Should the Dockerfile be aimed at production use?

yes, otherwise people will start using development images in production.

These can all be figured out, and compromises found, but it takes time and effort.

Only if you haven't decided about them yet. But I guess you are hosting healthchecks with some of the mentioned components already? Therefore some questions might already be answered?

But what's likely to happen is the original author will move on to other things after a year or three

Well, the current situation is, that people are opening Docker issues and PRs. I'm not sure whether you really would consider this is a good thing.

I will be left maintaining it and providing support for it.

IMHO you probably are already providing support for it. Travis configuration usually already contains information about some Docker specs.
You could even share the same Dockerfile if you provide the build environment as an Docker argument.
The pip commands would be moved to the Dockerfile and the travis.yml would get docker build/run instead.
This way Travis would just build the image and run the tests.

But don't guarantee free dev work and support.

I understand that and I never expected that you should (I hope nobody else does this neither).

@alexanderadam commented on GitHub (May 5, 2020): The component/dependency questions aren't Docker specific at all. _Everyone_ who wants to host healthchecks has to answer those. The more important question is: which of those components are recommended? It is much better if maintainers give a proper default than users making decisions that they will regret. They might provoke errors with bad decisions and might even believe that it is healthchecks' fault although it was just a bad choice of components. The answers for the questions you asked are improving security for all users. Furthermore you can probably improve bug reproducibility by setting sane defaults in the image. > Should the Dockerfile be aimed at production use? yes, otherwise people will start using development images in production. > These can all be figured out, and compromises found, but it takes time and effort. Only if you haven't decided about them yet. But I guess you are hosting healthchecks with some of the mentioned components already? Therefore some questions might already be answered? > But what's likely to happen is the original author will move on to other things after a year or three Well, the _current_ situation is, that people are opening Docker issues and PRs. I'm not sure whether you really would consider this is a good thing. > I will be left maintaining it and providing support for it. IMHO you probably are already providing support for it. [Travis configuration usually already contains information about some Docker specs](https://github.com/healthchecks/healthchecks/blob/master/.travis.yml). You could even share the same `Dockerfile` if you provide the build environment as an Docker argument. The `pip` commands would be moved to the `Dockerfile` and the `travis.yml` would get `docker build/run` instead. This way Travis would just build the image and run the tests. > But don't _guarantee_ free dev work and support. I understand that and I never expected that you should (I hope nobody else does this neither).

kerem commented

2026-02-25 23:41:28 +03:00

Author

Owner

@cuu508 commented on GitHub (May 5, 2020):

Thanks for the followup, good points!

The more important question is: which of those components are recommended?

The way I've been thinking about it is: it is just a Django app. Which web server or which database you use – that's your choice, every person has their favorite set of tools anyway.

But it's interesting to think about it more as an appliance – you don't need to know about everything that happens inside, you just supply some env variables and run it, and it exposes port 80. And that's obviously appealing for people who are not interested in geeking out with systems administration, and instead just want to run it.

Core components of the hosted service are:

App servers

Ubuntu 18.04 as the base system (will look at updating in the coming months)
uwsgi
nginx in front of uwsgi, responsible for serving static files, redirecting http->https, gzipping etc.
systemd services for running uwsgi and sendalerts

Database servers

PostgreSQL 10 (no specific reason for exactly v10. Upgrading major versions without downtime is hard and scary, so I'm currently "stuck" there)

Load balancers

haproxy on separate machines. Terminates TLS connections, and lets me do easy rolling upgrades on app servers

Unfortunately I don't have in-depth knowledge about Docker ecosystem, and so some questions are answered but some are open. And, time-consuming to offer even minimal support for a tool you don't know or use much.

@cuu508 commented on GitHub (May 5, 2020): Thanks for the followup, good points! > The more important question is: which of those components are recommended? The way I've been thinking about it is: it is just a Django app. Which web server or which database you use – that's your choice, every person has their favorite set of tools anyway. But it's interesting to think about it more as an appliance – you don't need to know about everything that happens inside, you just supply some env variables and run it, and it exposes port 80. And that's obviously appealing for people who are not interested in geeking out with systems administration, and instead just want to run it. Core components of the hosted service are: **App servers** * Ubuntu 18.04 as the base system (will look at updating in the coming months) * uwsgi * nginx in front of uwsgi, responsible for serving static files, redirecting http->https, gzipping etc. * systemd services for running uwsgi and `sendalerts` **Database servers** * PostgreSQL 10 (no specific reason for exactly v10. Upgrading major versions without downtime is hard and scary, so I'm currently "stuck" there) **Load balancers** * haproxy on separate machines. Terminates TLS connections, and lets me do easy rolling upgrades on app servers Unfortunately I don't have in-depth knowledge about Docker ecosystem, and so some questions are answered but some are open. And, time-consuming to offer even minimal support for a tool you don't know or use much.

kerem commented

2026-02-25 23:41:28 +03:00

Author

Owner

@SuperSandro2000 commented on GitHub (May 7, 2020):

Also the Dockerfile does not need to support TLS. I would ship both MariaDB and postgres driver. Sendalerts can just be the same container with a different start command.

@SuperSandro2000 commented on GitHub (May 7, 2020): Also the Dockerfile does not need to support TLS. I would ship both MariaDB and postgres driver. Sendalerts can just be the same container with a different start command.

kerem commented

2026-02-25 23:41:28 +03:00

Author

Owner

@cuu508 commented on GitHub (Jan 21, 2021):

I've now added Dockerfile and docker-compose.yml – https://github.com/healthchecks/healthchecks/tree/master/docker

Highly experimental, may eat your cat... but it's a start.

@cuu508 commented on GitHub (Jan 21, 2021): I've now added Dockerfile and docker-compose.yml – https://github.com/healthchecks/healthchecks/tree/master/docker Highly experimental, may eat your cat... but it's a start.

Rows
Columns

[GH-ISSUE #238] Hint: Dockerized healthchecks #174