private/haproxy
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: add README in English and Russian

Browse Source 
Same structure as the bitmessage and bitcoind repositories: intro, usage with
compose and cli examples, a parameter table, and notes carrying the traps —
why the certificate must exist before start-up, why the runtime API is a unix
socket, why there are two loggers, and why HSTS is one day rather than a year.
This commit is contained in:
bitdeals
2026-08-07 13:38:54 +00:00
parent ab75b21cb4
commit a66944077d
2 changed files with 459 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+228
View File
@@ -0,0 +1,228 @@
# Intro
> Русская версия: [README.ru-RU.md](README.ru-RU.md)
[HAProxy](https://www.haproxy.org/) is a TCP/HTTP load balancer and reverse proxy. Here it is the public edge of a BitDeals site: it terminates TLS on 443, forwards everything to the web container, and routes ACME challenges to certbot.
HAProxy running in a docker container with a baked-in configuration.
This repository covers the docker deployment only. The image is `bitnami/haproxy` with one file copied into it.
# Usage
The container has two ports, **80** and **443**, and both are the public site.
The third channel is not a port: the HAProxy runtime API listens on a unix
socket at `/var/lib/haproxy/admin.sock`, on a volume shared with the
[certbot](https://git.bitdeals.org/private/certbot) container, which uses it to
install a renewed certificate into the running process without a restart. The
API is `level admin` and has no authentication, so who can open it is decided by
file permissions — see Notes.
There is one environment variable, `XFF_HMAC_KEY`, and it is optional.
Everything else is in `docker/haproxy.cfg`, which is copied into the image at
build time, so changing the routing means rebuilding and redeploying.
The certificate is read from `/usr/local/etc/haproxy/certificates/site.pem`,
mounted **read-only** from a volume shared with certbot. It must exist before
the container starts — see Notes.
## docker-compose
```yaml
services:
haproxy:
build:
context: https://git.bitdeals.org/private/haproxy.git
dockerfile: ./docker/Dockerfile
image: registry.bitdeals.org/haproxy
restart: unless-stopped
depends_on:
- nginx
- certbot
volumes:
- certificates:/usr/local/etc/haproxy/certificates:ro
- haproxy_admin:/var/lib/haproxy # runtime API socket — certbot only
ports:
- "80:80"
- "443:443"
volumes:
certificates:
haproxy_admin:
```
The two backends are named after the services they reach: `nginx:80` for the
site and `certbot:380` for ACME challenges. Both names have to resolve inside
the compose project, so those services must share a network with this one.
## docker cli
```sh
docker run -d \
-p 80:80 \
-p 443:443 \
-v certificates:/usr/local/etc/haproxy/certificates:ro \
registry.bitdeals.org/haproxy
```
Anything after the image name replaces the daemon's own arguments, so a config
check against a mounted file needs no new image:
```sh
docker run --rm -v "$PWD/docker/haproxy.cfg:/tmp/haproxy.cfg:ro" \
registry.bitdeals.org/haproxy -c -f /tmp/haproxy.cfg
```
## build and publish
A push to `main` builds and publishes the image
(`.gitea/workflows/build.yaml`), tagging it three ways: `<version>.<sha7>` to
deploy by, `<version>` to read, and `latest` for compose and Watchtower. A
nightly cron rebuilds from the same sources. By hand, when the registry
credentials are at hand:
```sh
docker build . --file docker/Dockerfile --tag registry.bitdeals.org/haproxy
docker push registry.bitdeals.org/haproxy
```
**The build context is the repository root**, not `docker/`: the Dockerfile
copies `./docker/haproxy.cfg`, so a context of `./docker` cannot see it and the
build fails on the `COPY`.
# Parameters
Container images are configured using parameters passed at runtime.
|Parameter|Function|
|:--------|:-------|
|-p 80|Plain HTTP. Redirects to HTTPS with a 301, except the ACME challenge path, which must stay reachable here for renewals to work|
|-p 443|HTTPS. Needs `site.pem` in the certificates volume before the container starts|
|-v /usr/local/etc/haproxy/certificates|Certificate directory, read-only. Only `site.pem` is read, at bind time. certbot writes it through the same volume mounted read-write at `/etc/certificates`|
|-v /var/lib/haproxy|Runtime API socket (`admin.sock`, `level admin`, **no authentication**). Mount it into certbot and nothing else — see Notes|
|-e XFF_HMAC_KEY|Optional, base64. Set, the visitor's address is replaced by an HMAC of it in `X-Client-Id` and never passed on; empty, no such header is sent. Generate with `openssl rand -base64 32` — see Notes|
Routing, timeouts and TLS settings are not parameters: they live in
`docker/haproxy.cfg` and ship inside the image.
# Notes
- **`site.pem` must exist before the container starts.** `bind ... ssl crt` is
resolved while the configuration is parsed, so an empty volume is a fatal
start-up error, not a warning — HAProxy exits, and without a restart policy it
stays down. certbot writes a self-signed placeholder on its own first start
precisely to break this circle, which is why the service ships with
`restart: unless-stopped`; order it after certbot with `depends_on` in a
project that defines one.
- **A certificate installed over the runtime API lives in memory only.** That is
why the volume is mounted read-only here: `set ssl cert` + `commit ssl cert`
never write to disk. The file on the volume is certbot's copy, and it is what
HAProxy re-reads after a restart — so the two paths agree without HAProxy
needing write access.
- **The runtime API is a full administrative channel with no password.** Anyone
who can open it can install a different certificate and private key, redirect
a backend to another address, or take servers out of rotation — that is,
silently man-in-the-middle the site. Treat access to `admin.sock` as
equivalent to holding the TLS private key, and mount that volume into certbot
and nothing else. `expose-fd listeners`, which would additionally hand a
client of the socket the listening sockets themselves, is deliberately **not**
set: it exists for seamless reloads, which this image never performs.
- **A unix socket, because a port cannot be restricted.** `expose:` publishes
nothing to the host but restricts nothing either, and docker networks have no
per-port rules — so a TCP runtime API is open to every container sharing a
network, which here includes nginx, since HAProxy must be able to call *it*.
A socket on a volume is reachable only by containers that mount the volume,
and that is the whole access-control story. It also keeps the private key,
which crosses this channel on every renewal, off the network.
- **HAProxy needs write access to the socket's directory, not just the file.**
It binds by creating `<path>.<pid>.tmp` and renaming it over the target — so
the image creates `/var/lib/haproxy` owned by uid 1001, and docker carries
that ownership onto an empty named volume mounted there. The rename is also
why a stale socket left by a previous run is harmless. certbot connects as
root and is unaffected by the `mode 660`.
- **The redirect to HTTPS carries one exception, and it is load-bearing.**
Port 80 answers 301 for everything except `/.well-known/acme-challenge/`,
which Let's Encrypt validates over plain HTTP — redirect that and every
renewal stops. The rule is written above `use_backend` because that is the
order it runs in: `http-request` rules are evaluated before backend selection
whatever the file says, and HAProxy warns when the two disagree.
- **HSTS is one day, not the customary year.** It is a one-way door: a browser
that has seen the header refuses plain HTTP to this host until it expires, and
nothing server-side can call that back. A day keeps a lapsed certificate
recoverable. Raise it in steps — 86400, 2592000, 31536000 — once renewals have
been seen to work. `includeSubDomains` and `preload` are deliberately absent:
the first binds names this proxy does not serve, the second is effectively
permanent.
- **Backend addresses are re-resolved, and that is not the default.** Both
`server` lines carry `resolvers docker`, so the `nginx` and `certbot` names
are looked up again while HAProxy runs. Without it a name is resolved once at
boot and kept for the life of the process, and a container recreated on a new
IP — which is what Watchtower does on every deploy — is never noticed.
`init-addr libc,none` is the other half: it lets HAProxy start when a backend
is not up yet, instead of refusing to parse a name it cannot resolve.
- **Logging goes to stdout, and `option dontlog-normal` makes it errors-only.**
`log stdout format raw local0` needs no syslog daemon — `docker logs` collects
it. A successful request writes nothing; a 503, a backend with no server, a
refused handshake do. Drop `dontlog-normal` deliberately if a full access log
is wanted, and understand that it is also what keeps the volume down.
- **There are two loggers, and forgetting the second one leaks addresses.**
`option httplog` is never used: its default format opens with `%ci:%cp`, which
would put every visitor's address into `docker logs` and undo the pseudonym the
frontends mint. A hand-written `log-format` puts the pseudonym in that first
field instead. The trap is `error-log-format`, which covers what happens
*before* a transaction exists — a refused TLS handshake, and TLS 1.2 is now
the floor — and whose default opens the same way. Both are set here. The
pseudonym is therefore computed by a `tcp-request connection` rule on accept,
in `sess` scope, because an http-phase rule would not have run yet when a
handshake fails.
- **Only the method and path are logged, never the query string.** `%{+Q}r`
would carry it, and a token that ever appeared in a URL would be written down
for as long as the log is kept.
- **The visitor's address stops here.** There is no `option forwardfor`:
`X-Forwarded-For` is deleted in both frontends and never filled in, so nothing
behind this proxy can log an address it was never given. `X-Client-Id` carries
a pseudonym instead — HMAC-SHA256 of the address under `XFF_HMAC_KEY`. Being
one-to-one with the address it is exactly as good a rate-limiting key, and
without the key it is not reversible. HMAC rather than a bare digest because
IPv4 is 2^32 values and an unkeyed hash of an address is brute-forced in
seconds.
- **`XFF_HMAC_KEY` is optional, and an empty one disables the feature rather
than weakening it.** Unset, no `X-Client-Id` is sent at all and a rate limit
downstream falls back to one bucket shared by every visitor; set, each visitor
gets their own. What never happens is a pseudonym derived from an empty key.
A value that is not valid base64 stops the container at configuration
parsing — it cannot degrade quietly. Rotating the key resets rate-limit
buckets (invisible to users) and changes every pseudonym, so activity either
side of a rotation cannot be linked.
- **Both deletes are unconditional.** `X-Forwarded-For` and `X-Client-Id` are
dropped whether or not a key is configured, so a header a client sent can
never be mistaken downstream for one this proxy minted. Same for
`X-Forwarded-Proto`, which each frontend sets to its own scheme rather than
passing on the client's claim.
- **The consumer must still be told to use it.** A downstream rate limit keyed
on the socket address — nginx's `$binary_remote_addr`, ДС's
`request.client.host` — sees this proxy for every request and degenerates to
one shared bucket. It has to key on `X-Client-Id`, and trust that header only
from this proxy's address; `frontend/docker/rate-limit.conf` in the bitdeals-ng
repository is the worked example.
- **TLS is pinned in `global`, not left to OpenSSL.** TLS 1.2 is the floor,
the cipher list is ECDHE-only in both ECDSA and RSA variants — certbot issues
ECDSA, the self-signed placeholder is RSA — and session tickets are off so
forward secrecy is not undone by a long-lived ticket key. `alpn h2,http/1.1`
on the bind offers HTTP/2 to browsers; the backend stays HTTP/1.1 and HAProxy
translates. **No HSTS header is sent**, deliberately: it would be premature
while port 80 still serves the site rather than redirecting, and it is hard to
take back once browsers have cached the policy.
- **`timeout http-request 10s` is what bounds the header phase**, and
`timeout client` cannot stand in for it: that one is an *inactivity* timeout
and resets on every byte received, so a client dripping a byte at a time holds
a connection open indefinitely. This one is absolute.
- **The process runs as uid 1001 and still binds 80 and 443.** That works
because Docker sets `net.ipv4.ip_unprivileged_port_start=0` in containers by
default; a host or runtime that restores the traditional value will make the
container fail to bind.
- **The base image is unpinned.** `FROM bitnami/haproxy` means `:latest`, and
the nightly rebuild cron picks up whatever that tag points at — a HAProxy
minor version can change under a build nobody triggered, and Watchtower then
rolls it out. Pin `FROM bitnami/haproxy:<version>` for reproducible builds.
README.ru-RU.md
+231
View File
@@ -0,0 +1,231 @@
# Общие сведения
> English version: [README.md](README.md)
[HAProxy](https://www.haproxy.org/) — балансировщик и обратный прокси для TCP и HTTP. Здесь он служит публичным краем сайта BitDeals: терминирует TLS на 443, передаёт всё остальное веб-контейнеру и направляет ACME-проверки в certbot.
HAProxy, работающий в docker-контейнере с конфигурацией, вшитой в образ.
Репозиторий описывает только развёртывание в docker. Образ — `bitnami/haproxy`, в который скопирован один файл.
# Использование
У контейнера два порта, **80** и **443**, и оба — публичный сайт.
Третий канал портом не является: runtime API HAProxy слушает unix-сокет
`/var/lib/haproxy/admin.sock` на томе, разделяемом с контейнером
[certbot](https://git.bitdeals.org/private/certbot), — тот через него
устанавливает обновлённый сертификат в работающий процесс без перезапуска. API
имеет уровень `admin` и не защищён аутентификацией, поэтому кто может его
открыть, определяют права на файл, — см. «Замечания».
Переменная окружения одна — `XFF_HMAC_KEY`, и она необязательна. Всё остальное
задано в `docker/haproxy.cfg`, который копируется в образ при сборке, поэтому
изменение маршрутизации означает пересборку и повторное развёртывание.
Сертификат читается из `/usr/local/etc/haproxy/certificates/site.pem`, том
подключён **только на чтение** и разделяется с certbot. Файл обязан
существовать до старта контейнера — см. «Замечания».
## docker-compose
```yaml
services:
haproxy:
build:
context: https://git.bitdeals.org/private/haproxy.git
dockerfile: ./docker/Dockerfile
image: registry.bitdeals.org/haproxy
restart: unless-stopped
depends_on:
- nginx
- certbot
volumes:
- certificates:/usr/local/etc/haproxy/certificates:ro
- haproxy_admin:/var/lib/haproxy # сокет runtime API — только для certbot
ports:
- "80:80"
- "443:443"
volumes:
certificates:
haproxy_admin:
```
Оба бэкенда названы по сервисам, к которым обращаются: `nginx:80` — сайт,
`certbot:380` — ACME-проверки. Эти имена должны разрешаться внутри
compose-проекта, то есть названные сервисы обязаны быть с этим в одной сети.
## docker cli
```sh
docker run -d \
-p 80:80 \
-p 443:443 \
-v certificates:/usr/local/etc/haproxy/certificates:ro \
registry.bitdeals.org/haproxy
```
Всё, что указано после имени образа, заменяет собственные аргументы демона,
поэтому проверка подключённого файла конфигурации не требует нового образа:
```sh
docker run --rm -v "$PWD/docker/haproxy.cfg:/tmp/haproxy.cfg:ro" \
registry.bitdeals.org/haproxy -c -f /tmp/haproxy.cfg
```
## Сборка и публикация
Push в `main` собирает и публикует образ (`.gitea/workflows/build.yaml`) с тремя
тегами: `<версия>.<sha7>` — для развёртывания, `<версия>` — для чтения и
`latest` — для compose и Watchtower. Ночной cron пересобирает образ из тех же
исходников. Вручную, если под рукой учётные данные реестра:
```sh
docker build . --file docker/Dockerfile --tag registry.bitdeals.org/haproxy
docker push registry.bitdeals.org/haproxy
```
**Контекст сборки — корень репозитория**, а не `docker/`: Dockerfile копирует
`./docker/haproxy.cfg`, поэтому при контексте `./docker` этот файл не виден и
сборка падает на `COPY`.
# Параметры
Образы контейнера настраиваются параметрами, передаваемыми при запуске.
|Параметр|Назначение|
|:--------|:-------|
|-p 80|Обычный HTTP. Перенаправляет на HTTPS кодом 301, кроме пути ACME-проверки: он обязан оставаться доступным здесь, иначе перевыпуск не проходит|
|-p 443|HTTPS. Требует наличия `site.pem` в томе сертификатов до старта контейнера|
|-v /usr/local/etc/haproxy/certificates|Каталог сертификатов, только на чтение. Читается лишь `site.pem` и лишь при связывании портов. certbot пишет его через тот же том, подключённый на запись как `/etc/certificates`|
|-v /var/lib/haproxy|Сокет runtime API (`admin.sock`, уровень `admin`, **без аутентификации**). Подключайте этот том к certbot и больше никуда — см. «Замечания»|
|-e XFF_HMAC_KEY|Необязательная, base64. Задана — адрес посетителя заменяется на HMAC от него в `X-Client-Id` и дальше не передаётся; пуста — такой заголовок не отправляется. Создать: `openssl rand -base64 32`, см. «Замечания»|
Маршрутизация, тайм-ауты и настройки TLS параметрами не являются: они находятся
в `docker/haproxy.cfg` и поставляются внутри образа.
# Замечания
- **`site.pem` обязан существовать до старта контейнера.** `bind ... ssl crt`
разбирается при чтении конфигурации, поэтому пустой том — это фатальная
ошибка запуска, а не предупреждение: HAProxy завершается и без политики
перезапуска больше не поднимается. certbot при первом старте создаёт
самоподписанную заглушку именно чтобы разорвать этот круг, — поэтому сервис
поставляется с `restart: unless-stopped`; в проекте, где certbot определён,
добавьте ещё и `depends_on`.
- **Сертификат, установленный через runtime API, живёт только в памяти.** Именно
поэтому том здесь подключён только на чтение: `set ssl cert` и
`commit ssl cert` на диск ничего не пишут. Файл на томе — копия certbot, и
именно её HAProxy перечитывает после перезапуска, так что оба пути согласуются
без права записи у HAProxy.
- **Runtime API — полноценный административный канал без пароля.** Любой, кто
способен его открыть, может установить другой сертификат с другим приватным
ключом, перенаправить бэкенд на иной адрес или вывести серверы из
обслуживания — то есть незаметно устроить сайту «человека посередине».
Считайте доступ к `admin.sock` равноценным владению приватным ключом TLS и
подключайте этот том к certbot и больше никуда. `expose-fd listeners`, которая
вдобавок отдала бы клиенту сокета сами слушающие сокеты, намеренно **не**
задана: она нужна для бесшовной перезагрузки, которой этот образ не выполняет.
- **Unix-сокет — потому что порт ограничить нельзя.** `expose:` наружу ничего не
публикует, но и не ограничивает, а правил по портам у docker-сетей нет: значит
runtime API на TCP открыт любому контейнеру в общей сети, включая nginx, — ведь
HAProxy обязан дозваниваться до *него*. Сокет на томе доступен только тем
контейнерам, которые этот том подключают, и это исчерпывающее описание
разграничения доступа. Заодно приватный ключ, идущий по этому каналу при
каждом перевыпуске, больше не покидает пределы тома.
- **HAProxy нужны права на запись в каталог сокета, а не только на сам файл.**
Он связывается с сокетом, создавая `<путь>.<pid>.tmp` и переименовывая его
поверх целевого, — поэтому образ создаёт `/var/lib/haproxy` с владельцем 1001,
а docker переносит это владение на пустой именованный том, подключённый сюда.
Переименование заодно объясняет, почему оставшийся от прошлого запуска сокет
безвреден. certbot подключается от root, и `mode 660` его не касается.
- **У редиректа на HTTPS есть одно исключение, и оно несущее.** Порт 80
отвечает 301 на всё, кроме `/.well-known/acme-challenge/`, — этот путь
Let's Encrypt проверяет по обычному HTTP, и его перенаправление останавливает
любой перевыпуск. Правило записано выше `use_backend`, потому что в этом
порядке оно и выполняется: правила `http-request` вычисляются до выбора
бэкенда независимо от порядка в файле, и HAProxy предупреждает, когда одно
расходится с другим.
- **HSTS выставлен на сутки, а не на привычный год.** Это дверь в одну сторону:
браузер, увидевший заголовок, отказывается ходить по обычному HTTP на этот
хост до истечения срока, и отменить это с сервера нельзя. Сутки оставляют
просроченный сертификат исправимым. Поднимать ступенями — 86400, 2592000,
31536000, — когда перевыпуск устоится. `includeSubDomains` и `preload`
намеренно отсутствуют: первый связывает имена, которых этот прокси не
обслуживает, второй практически необратим.
- **Адреса бэкендов перечитываются, и по умолчанию это не так.** Обе строки
`server` несут `resolvers docker`, поэтому имена `nginx` и `certbot`
разрешаются заново по ходу работы. Без этого имя разрешается один раз при
загрузке и держится всё время жизни процесса, а пересозданный с новым IP
контейнер — то, что Watchtower делает при каждом развёртывании, — остаётся
незамеченным. `init-addr libc,none` — вторая половина: она позволяет HAProxy
стартовать, когда бэкенд ещё не поднят, вместо отказа разобрать неразрешимое
имя.
- **Журнал идёт в stdout, а `option dontlog-normal` оставляет в нём только
ошибки.** `log stdout format raw local0` не требует syslog-демона — вывод
забирает `docker logs`. Успешный запрос не пишется ничем; 503, бэкенд без
сервера, отклонённое рукопожатие — пишутся. Убирайте `dontlog-normal`
осознанно, если нужен полный журнал обращений: он же удерживает объём.
- **Логгеров два, и забытый второй сдаёт адреса.** `option httplog` здесь не
используется: его формат по умолчанию начинается с `%ci:%cp`, то есть адреса
посетителей попали бы в `docker logs` и свели бы на нет псевдоним, который
выставляют фронтенды. Собственный `log-format` ставит в это первое поле
псевдоним. Ловушка — `error-log-format`: он покрывает то, что происходит *до*
появления транзакции (отклонённое TLS-рукопожатие, а нижняя граница теперь
TLS 1.2), и его умолчание начинается так же. Здесь заданы оба. Поэтому
псевдоним вычисляется правилом `tcp-request connection` на приёме соединения и
в области `sess`: правило http-фазы к моменту провала рукопожатия ещё не
выполнялось бы.
- **В журнал идут только метод и путь, никогда не строка запроса.** `%{+Q}r`
унёс бы и её, и токен, однажды оказавшийся в URL, был бы записан на всё время
хранения журнала.
- **Адрес посетителя дальше не идёт.** `option forwardfor` не задан:
`X-Forwarded-For` в обоих фронтендах удаляется и никогда не заполняется,
поэтому ничто за этим прокси не может записать в журнал адрес, которого ему не
давали. Вместо адреса передаётся псевдоним в `X-Client-Id` — HMAC-SHA256 от
адреса на ключе `XFF_HMAC_KEY`. Он взаимно однозначен с адресом, то есть как
ключ ограничения частоты ничем не хуже, и без ключа необратим. Именно HMAC, а
не просто хеш: IPv4 — это 2³² значений, и хеш адреса без ключа перебирается за
секунды.
- **`XFF_HMAC_KEY` необязателен, и пустой ключ выключает функцию, а не
ослабляет её.** Не задан — `X-Client-Id` не отправляется вовсе, и ограничение
частоты ниже по цепочке вырождается в одну корзину на всех посетителей;
задан — у каждого посетителя своя. Чего не происходит никогда, так это
псевдонима, выведенного на пустом ключе. Значение, не являющееся корректным
base64, останавливает контейнер при разборе конфигурации — тихо испортиться
оно не может. Ротация ключа сбрасывает корзины (пользователь этого не видит) и
меняет все псевдонимы, поэтому активность до и после ротации связать нельзя.
- **Оба удаления безусловны.** `X-Forwarded-For` и `X-Client-Id` удаляются
независимо от того, задан ключ или нет, — чтобы присланный клиентом заголовок
ниже по цепочке нельзя было принять за выставленный этим прокси. То же с
`X-Forwarded-Proto`: каждый фронтенд выставляет собственную схему, а не
передаёт дальше клиентское утверждение.
- **Потребителя всё равно нужно научить этим пользоваться.** Ограничение
частоты, построенное на адресе сокета — `$binary_remote_addr` у nginx,
`request.client.host` у ДС, — видит этот прокси на каждом запросе и
вырождается в общую корзину. Ключом должен быть `X-Client-Id`, и доверять ему
следует только с адреса этого прокси; готовый пример —
`frontend/docker/rate-limit.conf` в репозитории bitdeals-ng.
- **TLS задан в `global`, а не отдан на усмотрение OpenSSL.** Нижняя граница —
TLS 1.2, список шифров только ECDHE и в вариантах ECDSA и RSA (certbot
выпускает ECDSA, а самоподписанная заглушка — RSA), билеты сессий выключены,
чтобы совершенная прямая секретность не сводилась на нет долгоживущим ключом
билета. `alpn h2,http/1.1` в строке `bind` предлагает браузерам HTTP/2;
бэкенд остаётся на HTTP/1.1, преобразованием занимается HAProxy. Заголовок
**HSTS не отправляется**, и это намеренно: он был бы преждевременным, пока
порт 80 отдаёт сайт вместо перенаправления, а отменить его после того, как
браузеры запомнили политику, трудно.
- **Фазу чтения заголовков ограничивает `timeout http-request 10s`**, и
`timeout client` его не заменяет: тот является таймаутом *бездействия* и
сбрасывается на каждом полученном байте, поэтому клиент, шлющий по байту,
держит соединение открытым сколько угодно. Этот — абсолютный.
- **Процесс работает под uid 1001 и всё же занимает порты 80 и 443.** Это
работает потому, что docker по умолчанию выставляет в контейнерах
`net.ipv4.ip_unprivileged_port_start=0`; хост или среда выполнения, вернувшие
традиционное значение, приведут к тому, что контейнер не сможет занять порты.
- **Базовый образ не зафиксирован.** `FROM bitnami/haproxy` означает `:latest`,
а ночной cron пересборки берёт то, на что этот тег указывает сейчас, — минорная
версия HAProxy может смениться в сборке, которую никто не запускал, после чего
Watchtower выкатит её. Для воспроизводимых сборок фиксируйте
`FROM bitnami/haproxy:<версия>`.