103 lines
6.0 KiB
Markdown
103 lines
6.0 KiB
Markdown
# Roadmap
|
||
|
||
Планируемые улучшения инфраструктурного репозитория. Файл фиксирует будущие работы, эксплуатационные риски и технический долг.
|
||
|
||
`CHANGELOG.md` описывает уже сделанные изменения, а этот файл хранит то, что еще нужно спланировать или выполнить.
|
||
|
||
## Высокий приоритет
|
||
|
||
### Обновить Nextcloud с EOL-версии
|
||
|
||
- Текущая версия: `nextcloud:30.0.6`.
|
||
- Риск: ветка Nextcloud 30 достигла EOL и не получает исправления безопасности.
|
||
- Что сделать:
|
||
- изучить upgrade path и release notes Nextcloud;
|
||
- сделать backup `data/nextcloud/`;
|
||
- проверить совместимость используемых apps;
|
||
- обновляться по поддерживаемому пути между major versions;
|
||
- после обновления проверить web UI, `occ status`, фоновые задачи и healthcheck.
|
||
|
||
### Обновить Gitea из-за security advisory
|
||
|
||
- Текущая версия: `docker.gitea.com/gitea:1.26.2`.
|
||
- Риск: для Gitea `<= 1.26.4` опубликован SSRF advisory, patched version указана как `1.27.0`.
|
||
- Что сделать:
|
||
- изучить release notes Gitea `1.27.0+`;
|
||
- сделать backup `data/gitea/`;
|
||
- обновить image version в `docker-compose.yml`;
|
||
- проверить web UI, git clone/push, Actions и healthcheck.
|
||
|
||
### Переделать backup перед деплоем
|
||
|
||
- Текущее поведение: workflow архивирует весь `data/` в `backups/` на том же диске.
|
||
- Риск: backup может падать из-за нехватки места до начала деплоя.
|
||
- Что сделать:
|
||
- добавить preflight-проверку свободного места;
|
||
- чистить старые backups до создания нового архива;
|
||
- рассмотреть backup только затронутого service data вместо всего `data/`;
|
||
- рассмотреть off-host backup или streaming backup на другую машину;
|
||
- документировать ручной backup/restore для отдельных сервисов.
|
||
|
||
## Средний приоритет
|
||
|
||
### Закрепить оставшиеся Docker image versions
|
||
|
||
- Сейчас floating images остаются у:
|
||
- `henrygd/beszel`;
|
||
- `henrygd/beszel-agent`;
|
||
- `gitea/act_runner:latest`;
|
||
- `rustdesk/rustdesk-server:latest`.
|
||
- Риск: деплой может неожиданно подтянуть несовместимую версию или, наоборот, не обновиться предсказуемо.
|
||
- Что сделать:
|
||
- подобрать актуальные стабильные версии;
|
||
- закрепить tags в `docker-compose.yml`;
|
||
- обновить `README.md` и `CHANGELOG.md`;
|
||
- для stateful-сервисов делать отдельные коммиты и backup перед деплоем.
|
||
|
||
### Пересмотреть безопасность Gitea Actions runner
|
||
|
||
- Текущее поведение: `git-runner` имеет доступ к `/var/run/docker.sock`.
|
||
- Риск: доступ к Docker socket фактически дает workflow root-equivalent доступ к хосту.
|
||
- Что сделать:
|
||
- явно определить trust boundary для Actions;
|
||
- ограничить запуск workflow только доверенными репозиториями/пользователями;
|
||
- рассмотреть отдельный runner host или VM;
|
||
- рассмотреть rootless/isolated runner setup, если это совместимо с нужными jobs.
|
||
|
||
### Уйти от password-based SSH deploy
|
||
|
||
- Текущее поведение: workflow использует `sshpass` и `sudo -S`.
|
||
- Риск: парольный deploy хуже аудируется и более хрупкий, чем key-based доступ с ограниченными правами.
|
||
- Что сделать:
|
||
- завести отдельного deploy user;
|
||
- перейти на SSH key;
|
||
- ограничить sudoers только нужными командами;
|
||
- убрать передачу sudo password из workflow.
|
||
|
||
## Низкий приоритет
|
||
|
||
### Добавить healthcheck для сервисов без проверки готовности
|
||
|
||
- Кандидаты:
|
||
- `pwd`;
|
||
- `sup-hbbs`;
|
||
- `sup-hbbr`.
|
||
- Цель: после деплоя видеть, что сервис не просто запущен, а реально отвечает.
|
||
|
||
### Почистить test Telegram workflow
|
||
|
||
- В `test_telegram_deploy_bot.yaml` есть неиспользуемая переменная `MESSAGE`, которая ссылается на несуществующий `steps.prepare_message`.
|
||
- Риск низкий: workflow сейчас не использует эту переменную, но она путает чтение и сопровождение.
|
||
|
||
### Разобраться с использованием диска
|
||
|
||
- После неудачной попытки backup занятое место на диске выросло.
|
||
- Первичные наблюдения:
|
||
- `backups/` не содержит крупного архива;
|
||
- `lsof +L1` не показал большого удаленного файла;
|
||
- Docker images занимают заметный объем, но не должны были измениться, если workflow упал до Docker-шагов.
|
||
- Что сделать:
|
||
- найти крупные каталоги через `du -xhd 1`;
|
||
- проверить `/var`, `/tmp`, Docker storage и filesystem reserve;
|
||
- только после диагностики решать, что можно чистить.
|