fetchstatus.py was a Django management command, and is now
a standalone script. This way we avoid doing Django housekeeping
every time it runs (every 10 seconds). It still needs to access
the ALLOWED_HOSTS setting, to make the HTTP request with
a correct Host header.
Fixes: #1071
... and install psycopg-c using instuctions in Dockerfile.
This way, getting a development environment or CI environment ready
is quick and easy, but Docker images still get the C optimizations.
Commit 8fed685f12 added a HEALTHCHECK
instruction in the Dockerfile. The healthcheck script calls http://localhost:8000/api/v3/status/, which fails if localhost is not in ALLOWED_HOSTS.
With this change, the healthcheck script is now a Django management
command. It reads Django's ALLOWED_HOSTS setting, grabs the first
element, and uses it in the "Host:" HTTP header when making a HTTP
request.
cc: #1051
* Healthchecks depends on python library "fido2"
* fido2 depends on python library "cryptography"
* building cryptography requires recent (1.65+) rustc
* cryptography has prebuilt binary wheels for most architectures
but not for arm/v7
* Dockerfile uses bookworm as base, which ships rustc 1.63
* So we now install rust using rustup
This is all terrible.
This commit adds a HEALTHCHECK instruction in Dockerfile.
The HEALTHCHECK instruction calls /docker/fetchstatus.sh
which in turn makes a HTTP request to
http://localhost:8000/api/v3/status/
This endpoint makes a test database query and returns non-200
response if the query fails. So, in short, if the Healthchecks
container for any reason is unable to query database, `docker ps`
will now show the container as "unhealthy".
cc: #1045
Changes:
- Switch to Python 3.10
- Drop pywheels.org repository. Build cryptography, uwsgi, psycopg2
etc. from source. This means builds on armhf will be slower, but
hopefully fewer worries about the piwheels binary package
not finding a .so file in our base image
- Don't ship the .git folder (facepalm)
The binary uwsgi package from piwheels.org crashes with:
uwsgi: error while loading shared libraries: libxml2.so.2:
cannot open shared object file: No such file or directory
(when run in a docker environment, with python:3.9-slim-buster
base image. It works fine in Raspbian)
The workaround is to build uwsgi from source, hence the "--no-binary"
flag.
The problem:
- the first "pip wheel" collects a specific version of requests
- the second "pip wheel" collects the latest version of requests
- later "pip install" tries to install both and fails
The fix is to run "pip wheel" once, and it will then pick a single
version of requests that satisfies all constraints.
Fixes: #594
Fixes: #565
Also, split Dockerfile into two stages, so rust
and other build dependencies don't end up in the final image.
Note cryptography has binary wheels for various architectures,
but unfortunately not for 32-bit arm. And, starting from v35.0.0,
cryptography requires rust to build from source.
