заведён канон общих конвенций для личных проектов
- 13 конвенций по осям arch / lang / stack / common; репозитории берут оттуда копии в свой docs/conventions/ и коммитят их у себя - conv — синхронизация копий: add / status / diff / pull / push, локальные регионы исключены из сравнения, поэтому расхождение не даёт шума
This commit is contained in:
@@ -0,0 +1,68 @@
|
||||
---
|
||||
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 -->
|
||||
Reference in New Issue
Block a user