❔ Как не дублировать плейбуки в Ansible

Роли — это как готовые наборы LEGO для вашей инфраструктуры. Вместо того чтобы писать однообразный код заново, вы собираете инфраструктуру из модулей. Сейчас покажем как это сделать.

1️⃣ Подготовка структуры роли

Для создания роли можно самостоятельно подготовить набор директорий:

myrole/
├── tasks/           # Основные задачи (playbook внутри роли)
│   └── main.yml     # Точка входа задач
├── handlers/        # Обработчики — команды, которые срабатывают при изменениях
│   └── main.yml
├── files/           # Статические файлы для копирования на целевые хосты
├── templates/       # Jinja2-шаблоны — конфиги с переменными
├── defaults/        # Значения переменных по умолчанию (низший приоритет)
│   └── main.yml
├── vars/            # Переменные с более высоким приоритетом
│   └── main.yml
├── meta/            # Метаинформация о роли, в том числе зависимости от других ролей
│   └── main.yml
├── library/         # Пользовательские модули (если нужны)
├── tests/           # Плейбуки и окружение для тестирования роли
└── README.md        # Документация по роли — зачем, как использовать

Но для этого есть лайфхак — команда ansible-galaxy init myrole. С помощью неё можно создать всю структуру без единого mkdir.

2️⃣ Пишем задачи

Роль в Ansbile это по сути отдельный плейбук. Внутри tasks/main.yml мы опишем свои таски, которые он должен выполнять.

Пример: установим htop и создадим файл приветствия.

- name: Устанавливаем htop
  apt:
    name: htop
    state: present
  become: yes

- name: Создаём файл приветствия
  copy:
    dest: /tmp/welcome.txt
    content: "Hello from Ansible role!»

3️⃣ Подключим роль в плейбуке

В основной плейбук нужно добавить нашу роль:

- hosts: all
  become: yes
  roles:
    - myrole

4️⃣ Всё готово к запуску.

Остаётся только воспользоваться командой:

ansible-playbook -i inventory.ini site.yml

В Ansible Galaxy есть коллекция ролей, написанных сообществом. От самых простых до ролей, которые используются в крупных компаниях.

➡️ Посмотреть роли сообщества

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера

В Kubernetes вы хотите реализовать blue-green deployment, чтобы минимизировать риски при выкатывании новой версии приложения. Какой подход будет наиболее правильным?

👾 — Обновить Deployment стратегией RollingUpdate и выставить maxUnavailable=0
👍 — Запустить новую версию как отдельный Deployment/Service и переключить трафик на неё после проверки
🥰 — Удалить старый Deployment и сразу задеплоить новый
⚡️ — Настроить HPA (HorizontalPodAutoscaler), чтобы он автоматически включал новую версию

🐸Библиотека задач по DevOps

❓ Как узнать, когда вы запускали команду

По умолчанию Bash хранит историю команд без времени выполнения.

Чтобы добавить дату и время, выполните:

export HISTTIMEFORMAT="%F %T "

Теперь можно искать команды вместе с временными метками:

history | grep ssh

Полезно, когда нужно вспомнить:

✅ когда подключались к серверу
✅ когда запускали скрипт
✅ когда вносили изменения вручную

А для быстрого поиска по истории используйте:

Ctrl + R

Введите часть команды — Bash найдёт совпадения прямо во время набора.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#root@prompt

🔐 OpenTofu умеет шифровать state-файлы

Многие воспринимают state как обычный технический артефакт. На практике внутри часто оказываются:

🔹 пароли
🔹 токены доступа
🔹 параметры БД
🔹 данные облачных ресурсов

🔜 Поэтому компрометация state-файла может быть не менее опасной, чем утечка секретов.

В OpenTofu есть встроенный механизм шифрования state и plan-файлов. Это позволяет защитить данные не только в удалённом backend, но и при хранении локальных артефактов.

Если используете OpenTofu в production, стоит проверить:

✅ где хранится state
✅ кто имеет к нему доступ
✅ включено ли шифрование

🔗 Документация

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера