Как только канал алертов реально включился (#3126), профиль alerts впервые
дошёл до проверки конфига — и деплой встал:
amtool: error: failed to validate 1 file(s)
Checking '/tmp/am.yml' FAILED: open /tmp/am.yml: permission denied
Отрендеренный конфиг пишется с правами 600 и принадлежит деплой-пользователю,
а и amtool, и сам Alertmanager в образе prom/alertmanager работают под nobody
(65534). Прочитать чужой файл 600 они не могут. Проверка падала не на
содержимом конфига, а на доступе к нему — и контейнер после подъёма упал бы
ровно там же.
Дефект не поймали раньше по понятной причине: без токена профиль alerts не
включался, и эта ветка не исполнялась НИ РАЗУ с момента появления гейта в
#3111. Проверка, которая никогда не запускалась, ничем не отличается от
отсутствующей — это ровно тот класс тихой поломки, ради которого весь стек и
заводится.
Права не ослабляем: в файле лежит токен бота. Вместо chmod 644 (который внёс
бы токен в список файлов, читаемых любым локальным пользователем машины)
отдаём файл во владение 65534 одноразовым контейнером от root — passwordless
sudo на хосте нет, а бинд-маунт правит host-инод напрямую. Доступ остаётся
ровно у того, кто конфиг читает.
Следствие, которое легко проглядеть: после смены владельца `>` в этот файл
на следующем деплое уже не запишет, поэтому добавлен rm перед рендером —
каталог принадлежит деплой-пользователю, пересоздать файл он может.
