# 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;
  - только после диагностики решать, что можно чистить.