Files
dev-conventions/stack/ansible/app-directories.md
T
av 4a59c71737 заведён канон общих конвенций для личных проектов
- 13 конвенций по осям arch / lang / stack / common; репозитории берут
  оттуда копии в свой docs/conventions/ и коммитят их у себя
- conv — синхронизация копий: add / status / diff / pull / push, локальные
  регионы исключены из сравнения, поэтому расхождение не даёт шума
2026-07-25 18:18:18 +03:00

3.9 KiB
Raw Blame History

status, extends
status extends
рекомендуемая arch/app-directories.md

Категории директорий: реализация в Ansible

Как arch/app-directories.md раскладывается на сервере плейбуком.

Переменные и создание

  • Директория объявляется переменной плейбука внутри base_dir, имя переменной оканчивается на _dir. Для случая «одна директория на категорию» это config_dir, data_dir, cache_dir; когда категория состоит из нескольких, имя даётся по содержимому (media_dir, uploads_dir, dumps_dir), а категория читается из списка бэкапа.
  • Директории создаются одной задачей циклом по списку: список и есть декларация того, что приложение пишет на диск. Разнесение по нескольким задачам прячет эту декларацию.
  • Владелец — пользователь, от имени которого работает приложение. Модель выбирается на репозиторий: выделенный пользователь на приложение (app_owner_uid == app_owner_gid) или общий primary_user. Какая модель принята — фиксируется ниже.

Список бэкапа

Плейбук кладёт в base_dir файл backup-targets — его читает оркестратор бэкапов. Строки списка собираются из тех же переменных *_dir, что и задача создания директорий: тогда переименование или перенос директории не может разойтись с бэкапом.

В список идут директории категории «данные», включая директорию дампов, и не идут конфигурация и кеш.

Монтирование в контейнер

  • Конфигурация — :ro, где приложение это позволяет. Приложение, которое переписывает свой конфиг, монтируется на запись — это отступление, и оно записывается.
  • Данные и кеш — на запись.
  • docker-compose.yml остаётся в корне base_dir: туда смотрит project_src модуля docker_compose_v2.

Секреты

Секреты приходят из vault-переменных и рендерятся шаблоном. Два способа, в порядке предпочтения:

  1. В файл конфигурации (роль secrets) — предпочтительный: секрет лежит под 0600 у пользователя приложения, не наследуется дочерними процессами и не виден в docker inspect.
  2. В environment: compose-файла — когда приложение не умеет читать секреты из файла. Задача рендера идёт с no_log: true.

Второй способ — вынужденный: он кладёт секрет в метаданные контейнера и в файл compose на диске. Приложение, умеющее файловые секреты, переводится на первый способ при ближайшем касании.

Связано