- 13 конвенций по осям arch / lang / stack / common; репозитории берут оттуда копии в свой docs/conventions/ и коммитят их у себя - conv — синхронизация копий: add / status / diff / pull / push, локальные регионы исключены из сравнения, поэтому расхождение не даёт шума
69 lines
3.9 KiB
Markdown
69 lines
3.9 KiB
Markdown
---
|
||
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`. Какая модель
|
||
принята — фиксируется ниже.
|
||
|
||
<!-- local:модель-владельца -->
|
||
<!-- /local -->
|
||
|
||
## Список бэкапа
|
||
|
||
Плейбук кладёт в `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 на диске. Приложение, умеющее файловые секреты, переводится на
|
||
первый способ при ближайшем касании.
|
||
|
||
<!-- local:отступления -->
|
||
<!-- /local -->
|
||
|
||
## Связано
|
||
|
||
<!-- local:связано -->
|
||
<!-- /local -->
|