podman: переход на Podman, Minikube, локальные образы и док для новичков

- Molecule: драйвер delegated, коллекция containers.podman, create/destroy/verify на Podman
- Makefile: все вызовы docker заменены на podman, сокет /run/podman/podman.sock
- Сборка образов: podman build (без buildx), buildall/buildall-image — только локально без push
- Ansible-controller: Podman в образе, docker-compose на podman compose, сокет Podman
- K8s: Kind заменён на Minikube (драйвер podman), скрипты и Makefile обновлены
- Пресеты: проверка локальных образов, без podman pull (registry запрещён)
- Документация: docs/podman.md, docs/quickstart-for-dummies.md (роли, плейбук, линт, тесты, пресеты, инвентори)
- README: ссылка на quickstart-for-dummies

Made-with: Cursor
This commit is contained in:
Sergey Antropoff
2026-03-11 19:59:47 +03:00
parent 23e1a6037b
commit 05881e8d74
16 changed files with 859 additions and 790 deletions

86
docs/podman.md Normal file
View File

@@ -0,0 +1,86 @@
# Работа с Podman (ветка podman)
**Автор:** Сергей Антропов
**Сайт:** https://devops.org.ru
В ветке `podman` проект переведён на использование **только Podman** (без Docker и Docker Compose).
## Требования
- **Podman** установлен и запущен (rootful: сокет `/run/podman/podman.sock`)
- **podman compose** (встроен в Podman 4.1+ или пакет `podman-compose`)
- Для K8s: **Minikube** и **kubectl** на хосте
## Основные изменения
### Molecule
- Драйвер: `delegated` (создание/удаление контейнеров в `create.yml` / `destroy.yml` через Ansible).
- Используется коллекция **containers.podman** (`podman_network`, `podman_container`).
- Сокет: `/run/podman/podman.sock` (DOoD-узлы заменены на POoD с монтированием сокета Podman).
- Инвентарь: `ansible_connection=containers.podman.podman`.
### Makefile
- Все вызовы `docker` заменены на `podman`.
- Сборка образов: `podman build --platform ...` (без buildx).
- Compose: `podman compose` (вместо `docker-compose`).
- Сокет в целях контроллера: `PODMAN_SOCKET ?= /run/podman/podman.sock`, монтируется в контейнер ansible-controller.
### Ansible-controller
- Образ собирается и запускается через Podman.
- В образе установлен **Podman** (вместо Docker).
- При запуске монтируется сокет хоста: `-v $(PODMAN_SOCKET):/run/podman/podman.sock`.
- Переменная окружения: `CONTAINER_HOST=unix:///run/podman/podman.sock`.
### Kubernetes
- Вместо **Kind** используется **Minikube** с драйвером `podman`.
- Кластер создаётся на хосте: `minikube start --driver=podman`.
- Скрипт: `scripts/create_minikube_cluster.py` (читает пресет из `molecule/presets/k8s/*.yml`).
- В пресетах K8s: `minikube_profile`, `minikube_addons`, `minikube_cpus`, `minikube_memory` (вместо `kind_clusters`).
## Локальные образы (без доступа к registry)
Во всех пресетах при использовании Podman **используются только локальные образы**. Выгрузка из registry отключена.
1. Соберите все образы локально один раз:
```bash
make buildall
```
2. Либо один образ для нужного пресета:
```bash
make buildall-image IMAGE=ubuntu22
make buildall-image IMAGE=debian11
```
3. После этого Molecule при `create` проверяет наличие образов локально и не выполняет `podman pull`. Если какого-то образа нет — выведет сообщение с указанием выполнить `make buildall`.
## Быстрый старт
```bash
# 1. Собрать локальные образы (без registry)
make buildall
# 2. Сеть labnet для compose (если нужен controller)
podman network create labnet 2>/dev/null || true
# 3. Запуск ansible-controller
make controller run
# 4. Тест ролей (контейнеры создаются через Podman из локальных образов)
make role test minimal
# Minikube (на хосте)
make k8s create k8s-minimal
make k8s status
kubectl get nodes
```
## Переменные
- **PODMAN_SOCKET** — путь к сокету Podman на хосте (по умолчанию `/run/podman/podman.sock` для rootful).
## CI/CD
Секция CI/CD (**cicd/**) в этой ветке **не менялась** — рассчитана на окружения с Docker. Для Podman в пайплайнах нужно отдельно устанавливать Podman и вызывать `podman` / `podman compose` в jobах.

View File

@@ -0,0 +1,332 @@
# DevOpsLab: пошаговое руководство для новичков
**Автор:** Сергей Антропов
**Сайт:** https://devops.org.ru
Это руководство описывает по шагам: создание роли, объединение ролей в плейбук, линт, тестирование на контейнерах (подах) с разным количеством и разными ОС, а также формирование инвентори для деплоя на реальные серверы. Подходит и для **Docker**, и для **Podman** (отличия указаны в конце).
---
## Что нужно установить
- **Make** (обычно уже есть в Linux/macOS).
- **Podman** (ветка podman) или **Docker** (ветка main) — для контейнеров.
- **Ansible** не обязателен на хосте: тесты и деплой можно запускать через контейнер из Makefile.
Клонируйте репозиторий и перейдите в каталог проекта. Все команды ниже выполняются из корня проекта.
---
## Шаг 1. Создать новую роль
Роль — это набор задач (tasks), шаблонов и переменных для одной цели (например, установка nginx или настройка пользователей).
**Команда:**
```bash
make role create
```
Скрипт спросит имя роли (латиницей, например `nginx` или `myapp`). Будет создана структура:
- `roles/<имя_роли>/tasks/main.yml` — основные задачи
- `roles/<имя_роли>/handlers/main.yml`
- `roles/<имя_роли>/defaults/main.yml` — переменные по умолчанию
- `roles/<имя_роли>/meta/main.yml`
- и др.
**Что сделать после создания:**
1. Открыть `roles/<имя_роли>/tasks/main.yml` и добавить свои задачи (модули `package`, `copy`, `template`, `service` и т.д.).
2. При необходимости задать переменные в `roles/<имя_роли>/defaults/main.yml`.
Роль автоматически попадёт в общий плейбук развёртывания после следующего шага (обновления плейбуков).
---
## Шаг 2. Объединить роли в один плейбук
Все роли, которые должны выполняться на серверах, собираются в один плейбук: **`roles/deploy.yml`**.
**Вариант А — обновить плейбук автоматически (все роли из `roles/`):**
```bash
make update-playbooks
```
Скрипт перезапишет `roles/deploy.yml`: для каждой роли в каталоге `roles/` будет добавлен свой play (hosts: all, одна роль в play).
**Вариант Б — править вручную:**
Откройте `roles/deploy.yml`. Каждая роль описывается своим блоком:
```yaml
- name: Установка роли repo
hosts: all
become: true
roles:
- repo
- name: Установка роли devops
hosts: all
become: true
roles:
- devops
```
- Чтобы **включить** роль — добавьте такой блок или раскомментируйте существующий.
- Чтобы **выключить** роль — закомментируйте блок (перед каждой строкой поставьте `#`).
- Порядок блоков задаёт порядок применения ролей.
Итог: в `roles/deploy.yml` перечислены все роли, которые будут и тестироваться в контейнерах, и деплоиться на реальные серверы (см. шаги 4 и 6).
---
## Шаг 3. Запуск линт-проверок
Линт проверяет синтаксис и типичные ошибки в ролях (и в плейбуках, которые их вызывают).
**Проверить все роли:**
```bash
make role lint
```
**Проверить одну роль:**
```bash
make role lint <имя_роли>
# Пример:
make role lint repo
make role lint devops
```
При ошибках будут указаны файл и строка. Исправьте замечания и запустите линт снова. Без ошибок линт завершится без падения.
---
## Шаг 4. Тестирование ролей на контейнерах (подах)
Тесты поднимают контейнеры с разными ОС, применяют к ним плейбук (в т.ч. ваши роли) и проверяют результат. Контейнеры в этом шаге — это и есть «поды» (тестовые хосты).
### 4.1. Подготовка образов (чтобы не качать из registry)
**Если используете Podman (ветка podman):**
Образы должны быть собраны **локально**. Один раз выполните:
```bash
make buildall
```
Собираются все образы (Ubuntu, Debian, CentOS и т.д.). Долго, но делается один раз. Для одного образа, например для минимального теста:
```bash
make buildall-image IMAGE=ubuntu22
make buildall-image IMAGE=debian12
```
**Если используете Docker (ветка main):**
```bash
make docker build
```
(при необходимости сначала `make docker setup-builder`).
### 4.2. Запуск тестов
**С пресетом по умолчанию (обычно 2 хоста):**
```bash
make role test
```
**С конкретным пресетом:**
```bash
make role test minimal
make role test default
make role test all-images
```
Что происходит: создаются контейнеры по выбранному пресету, к ним применяется плейбук (converge), затем они удаляются. Результат виден в выводе команды.
---
## Шаг 5. Менять количество подов и ОС (пресеты)
Количество «подов» (контейнеров) и их ОС задаются **пресетами** — файлами в `molecule/presets/` и `molecule/presets/examples/`.
### 5.1. Посмотреть доступные пресеты
```bash
make presets list
```
Будет выведен список пресетов и краткое описание (в т.ч. количество хостов).
### 5.2. Что задаёт пресет
В пресете задаётся:
- **hosts** — список хостов (контейнеров): имя, семейство ОС (`family`), группы.
- **images** — соответствие `family` и образа (например `ubuntu22: "inecs/ansible-lab:ubuntu22-latest"`).
- Общие настройки (сеть, systemd и т.д.).
От количества элементов в **hosts** и от выбранных **family** зависит, сколько подов поднимется и какие ОС будут использоваться.
### 5.3. Примеры пресетов по количеству и ОС
| Пресет | Описание | Кол-во хостов |
|-------------|------------------------------------|----------------|
| `minimal` | Один хост (быстрый тест) | 1 |
| `default` | Два хоста (например Ubuntu + Debian) | 2 |
| `all-images`| Максимум образов/ОС | много |
Запуск:
```bash
make role test minimal
make role test default
make role test all-images
```
### 5.4. Создать свой пресет (свои поды и ОС)
1. Скопируйте существующий пресет, например:
```bash
cp molecule/presets/default.yml molecule/presets/my-preset.yml
```
2. Откройте `molecule/presets/my-preset.yml`.
3. В секции **hosts** укажите свои хосты. Формат одного хоста:
```yaml
hosts:
- name: web1
family: ubuntu22
groups: [web, test]
- name: db1
family: centos9
groups: [db, test]
- name: lb1
family: debian12
groups: [lb, test]
```
- **name** — уникальное имя контейнера (пода).
- **family** — ключ из секции **images** (ubuntu20, ubuntu22, ubuntu24, debian9debian12, centos7centos9, alma, rocky, rhel, redos, astra, alt9, alt10 и т.д.).
- **groups** — группы для инвентори (можно использовать в плейбуках через `hosts: web` или `hosts: db`).
4. Сохраните файл. Запуск теста с вашим пресетом:
```bash
make role test my-preset
```
Количество подов = количество элементов в списке **hosts**. Разные ОС = разные **family** при наличии соответствующих образов в **images** (и собранных локально при Podman через `make buildall`).
---
## Шаг 6. Инвентори и деплой на реальные серверы
Когда роли и плейбук готовы и протестированы в контейнерах, их можно применять к реальным серверам. Для этого нужен **инвентори** и команды деплоя.
### 6.1. Где лежит инвентори
Файл инвентори по умолчанию:
- **`inventory/hosts.ini`**
Именно его используют команды `make role deploy` и `make role dryrun` (см. ниже).
### 6.2. Как сформировать инвентори
Откройте `inventory/hosts.ini`. Формат — обычный ini-инвентори Ansible.
**Пример минимального инвентори:**
```ini
# Группа веб-серверов
[web_servers]
web1 ansible_host=192.168.1.10 ansible_user=deploy
web2 ansible_host=192.168.1.11 ansible_user=deploy
# Группа БД
[db_servers]
db1 ansible_host=192.168.1.20 ansible_user=deploy
# Общие переменные для всех хостов
[all:vars]
ansible_ssh_private_key_file=~/.ssh/id_rsa
ansible_ssh_common_args='-o StrictHostKeyChecking=no'
```
- **Группы** — `[web_servers]`, `[db_servers]`. Имена можно менять и добавлять свои.
- **Хосты** — каждая строка: имя хоста + переменные. Обязательно укажите **ansible_host** (IP или hostname) и **ansible_user** (пользователь для SSH).
- **all:vars** — переменные для всех хостов (ключ SSH, опции подключения и т.д.).
Чтобы применять плейбук только к части серверов, в плейбуке можно использовать группы (например `hosts: web_servers`) или ограничивать запуск через `--limit` (см. ниже).
### 6.3. Проверка без изменений (dry-run)
Перед реальным деплоем полезно проверить, что плейбук выполнится без ошибок и что изменения именно те, что нужны:
```bash
make role dryrun <имя_роли>
# Пример:
make role dryrun repo
```
Команда запускает плейбук в режиме **check** (без реальных изменений) для указанной роли. Убедитесь, что в `inventory/hosts.ini` указаны ваши серверы и что с них есть SSH-доступ.
### 6.4. Реальный деплой плейбука на серверы
Когда инвентори заполнен и dry-run устраивает:
```bash
make role deploy
```
Будет выполнен плейбук **roles/deploy.yml** на всех хостах из **inventory/hosts.ini** (с подтверждением перед применением). При необходимости можно запускать Ansible вручную, например:
- Только на одной группе:
```bash
ansible-playbook -i inventory/hosts.ini roles/deploy.yml --limit web_servers
```
- Только проверка (аналог dry-run для всего плейбука):
```bash
ansible-playbook -i inventory/hosts.ini roles/deploy.yml --check --diff
```
(Если Ansible запускается через контейнер в Makefile, пути и вызов могут отличаться; логика та же: тот же инвентори и тот же плейбук.)
### 6.5. Кратко по шагам деплоя
1. Заполнить **inventory/hosts.ini** (группы, хосты, ansible_host, ansible_user, ключ SSH).
2. Проверить доступ: `ansible -i inventory/hosts.ini all -m ping` (если Ansible установлен локально).
3. Запустить **make role dryrun &lt;роль&gt;** для проверки.
4. Запустить **make role deploy** для применения плейбука к реальным серверам.
---
## Универсальность: Docker и Podman
Один и тот же сценарий (роли, плейбук, пресеты, инвентори) работает и с Docker, и с Podman. Отличия только в подготовке образов и в том, как вызываются контейнеры внутри Makefile.
| Действие | Podman (ветка podman) | Docker (ветка main) |
|-----------------------|---------------------------|----------------------------|
| Сборка образов | `make buildall` | `make docker build` |
| Один образ | `make buildall-image IMAGE=ubuntu22` | `make docker build-image IMAGE=ubuntu22` |
| Запуск тестов | `make role test [preset]` | то же |
| Линт | `make role lint` | то же |
| Деплой / инвентори | `make role deploy`, `inventory/hosts.ini` | то же |
- **Пресеты, роли, deploy.yml, inventory** — одни и те же.
- **Линт, тесты, деплой** — одни и те же команды `make role ...`.
- Разница только в том, как и откуда берутся образы (локальная сборка через `buildall` у Podman или сборка/пулл через `docker build` у Docker).
K8s в этом руководстве не рассматривается; см. отдельную документацию по Kubernetes при необходимости.