deploy: переход на локальную сборку образа и доставку docker save/load
- task image принимает BUILD_ID и тегает <app>:$BUILD_ID (контракт роли app_image в umbar) - добавлен ADR-2026-07-24-local-image-build, старый docker-deploy помечен superseded - README/architecture/roadmap/Dockerfile обновлены под новую схему (без сборки на сервере)
This commit is contained in:
@@ -1,6 +1,7 @@
|
||||
# Docker как единица деплоя, образ собирается на сервере
|
||||
|
||||
- Дата: 2026-06-13
|
||||
- Статус: заменено на ADR-2026-07-24-local-image-build
|
||||
|
||||
## Контекст
|
||||
|
||||
|
||||
@@ -0,0 +1,71 @@
|
||||
# Образ собирается локально и едет на сервер через docker save/load
|
||||
|
||||
- Дата: 2026-07-24
|
||||
|
||||
## Контекст
|
||||
|
||||
Заменяет [ADR-2026-06-13-docker-deploy](ADR-2026-06-13-docker-deploy.md).
|
||||
|
||||
Docker как единица деплоя и распределение ответственности (`Dockerfile`
|
||||
— упаковка — живёт в jellybit; оркестрация — в umbar) остаются в силе.
|
||||
Пересматривается только **как** образ попадает на сервер.
|
||||
|
||||
Прежняя схема собирала статический бинарь на control-хосте, копировала
|
||||
на сервер бинарь + `Dockerfile` и делала `docker build` **на месте**.
|
||||
У этого два неудобства. Во-первых, на сервере остаётся шаг сборки: пусть
|
||||
дешёвый на Intel N150, но результат косвенно завязан на состояние сервера
|
||||
(его docker, его кэш), а не только на исходник. Во-вторых, схема
|
||||
одноразовая — она была вписана в `playbook-jellybit.yml` и не
|
||||
переиспользовалась. Появление второго такого же приложения (trackers)
|
||||
потребовало вынести доставку образа в общую ansible-роль `app_image` и
|
||||
заодно унифицировать контракт с приложением.
|
||||
|
||||
## Рассмотренные варианты
|
||||
|
||||
- **Оставить сборку на сервере** — прежнее решение. Держит на сервере шаг
|
||||
`docker build` и делает результат зависимым от состояния сервера;
|
||||
переиспользовать без копипасты плейбука неудобно.
|
||||
- **Реестр (CI пушит образ, сервер тянет)** — каноничнее, но в домашней
|
||||
лаборатории это лишний реестр и пайплайн ради одного узла. Отвергнуто по
|
||||
той же причине, что и в исходной ADR.
|
||||
- **Собрать полный образ локально и доставить его `docker save`/`load`** —
|
||||
выбрано: сборка целиком на control-хосте, сервер — только получатель, и
|
||||
реестр не нужен.
|
||||
|
||||
## Решение
|
||||
|
||||
Доставку образа ведёт переиспользуемая роль `app_image` в umbar. Схема:
|
||||
|
||||
- **Контракт с приложением.** Приложение реализует команду `task image`:
|
||||
получает `BUILD_ID` из окружения и собирает **полный** образ
|
||||
`<app>:$BUILD_ID`. Без `BUILD_ID` собирается `<app>:dev` — обратная
|
||||
совместимость для локальной работы. Приложение полностью владеет тем,
|
||||
как собирается его образ (`Dockerfile` — в репозитории приложения).
|
||||
- **Сборка локальна.** Роль генерит случайный `BUILD_ID` и гоняет с ним
|
||||
`task image` на control-хосте → образ `<app>:$BUILD_ID`. На сервере
|
||||
Go-тулчейн и `docker build` больше не нужны.
|
||||
- **Тег = BUILD_ID.** Deploy-тег — тот самый случайный `BUILD_ID`.
|
||||
Дедупликации по содержимому нет: тег нов на каждый прогон. Content-адресацию
|
||||
(тег из хеша слоёв/конфига образа) рассматривали и отвергли — на сценариях
|
||||
ручного нечастого деплоя выгода от неё не окупала сложности.
|
||||
- **Доставка без реестра.** `docker save` → copy tar → `docker load`.
|
||||
Каждый деплой везёт образ и пересоздаёт контейнер.
|
||||
- **Уборка.** Старые образы на сервере (тег каждого прошлого деплоя)
|
||||
подчищает `docker image prune -af` по крону (`playbook-system.yml`).
|
||||
|
||||
## Последствия
|
||||
|
||||
- `+` Сервер — только получатель образа: без Go-тулчейна и без шага
|
||||
`docker build`.
|
||||
- `+` Сборка целиком на control-хосте — воспроизводимее; состояние
|
||||
сервера на результат не влияет.
|
||||
- `+` Реестр по-прежнему не нужен — доставка дешёвая (`save`/`load` tar).
|
||||
- `+` Механизм общий (роль `app_image`), а не вписан в один плейбук —
|
||||
им же доставляется trackers.
|
||||
- `-` Дедупликации нет: тег = случайный `BUILD_ID`, поэтому каждый деплой
|
||||
везёт образ и пересоздаёт контейнер, даже если ничего не менялось. Для
|
||||
ручного нечастого деплоя это осознанный размен — простота роли важнее
|
||||
экономии одного рестарта.
|
||||
- `-` `save`/`load` везёт весь образ (базовый слой + бинарь), а не только
|
||||
бинарь, как в прежней схеме. Для `distroless/static` это единицы
|
||||
мегабайт — дёшево.
|
||||
+2
-1
@@ -56,8 +56,9 @@
|
||||
|
||||
| Дата | Запись | Статус |
|
||||
| ---------- | ---------------------------------------------------------------- | ------ |
|
||||
| 2026-07-24 | [Локальная сборка образа + доставка docker save/load](ADR-2026-07-24-local-image-build.md) | — |
|
||||
| 2026-07-23 | [Конвейер ревью: гейт, generative-проходы и триаж](ADR-2026-07-23-review-pipeline-generative.md) | — |
|
||||
| 2026-06-13 | [Авто-раскладка только при матче в метабазе](ADR-2026-06-13-auto-link-requires-db-match.md) | — |
|
||||
| 2026-06-13 | [Docker как единица деплоя](ADR-2026-06-13-docker-deploy.md) | — |
|
||||
| 2026-06-13 | [Docker как единица деплоя](ADR-2026-06-13-docker-deploy.md) | заменено на ADR-2026-07-24-local-image-build |
|
||||
| 2026-06-13 | [Хардлинки вместо копирования и симлинков](ADR-2026-06-13-hardlinks.md) | — |
|
||||
| 2026-06-13 | [Go и доставка одним бинарём](ADR-2026-06-13-go-single-binary.md) | — |
|
||||
|
||||
Reference in New Issue
Block a user