Учусь Ansible: от пинга до Nginx на Raspberry Pi и Orange Pi

[NightShad0w]

А вот опытные эксперты, подскажите, есть ли какой-то DevOps инструмент для настройки парка техники, но более ориентированный на ментальную модель инженера-программиста, без вот этой вот развесистой малины ямлов, сотни папок с неочевидными функциями и многословностью, обусловленной тотальной и неконтролируемой расширяемостью? Не могу найти современный инструмент, который бы по элегантности превзошел шелл скрипты, мейкфайлы и немного магии .env.

[Tanner]

Есть, Fabric.

[Tony-Sol]

Мб что-то типа pulumi?

[d3d11]

Не работал с Ansible. Подскажите, чем все это отличается от bash скрипта с командами установки?

[HiLander]

"Инфраструктура как код". Вы пишете Yaml который описывает вашу инфраструктуру. При необходимости повторить - запускаете еще раз. Повторяемость и масштабируемость улетают в небеса. Создание целого парка машин со сложными зависимостями в два клика...

[d3d11]

Но здесь же прописываются именно команды установки софта, т.е. это императивные конфиги, а не декларативные?

[Tony-Sol]

Не совсем, есть разница между "установи nginx" и "nginx должен быть" - первое императивный подход, второй - декларативный

[DanLin]

В Ansible декларативность - это именно декларация конечного состояния системы, а не просто «запись команд в YAML», который тупо ставит софт.

Bash: «Выполни эти 10 команд».

Ansible: «На узле должен быть установлен и запущен nginx актуальной версии».

Пример:

- name: Install nginx      
  apt:        
    name: nginx        
    state: latest

Это задача означает что-то типа «На машине должен быть установлен Nginx последней версии». Если Nginx УЖЕ стоит (и версия последняя) - Ansible ничего не делать. Если старая версия - Ansible обновит. Если нет Nginx - установит.
Это и есть «декларация состояния». То есть ты описываешь не «КАК» устанавливать, а описываешь" что должно быть в итоге. В примере модули apt сам поймёт, что ему нужно делать.
А вот в bash такого нет - каждый шаг выполняется всегда без проверки текущего состояния (разве что если сам не предусмотрел и не написал вручную логику проверки/обновления).

[d3d11]

Понял, спасибо )

[Tony-Sol]

inventory.ini — сердце Ansible

Вкусовщина, но ИМХО, инвентарь в yaml удобнее

ansible_user=root

Не надо так, лучше создать отдельного пользователя

Первый Nginx (простой плейбук)

Такие штуки как установка и конфигурация сервисов, лучше размещать в отдельные роли, а в плейбуке уже собственно подключать нужные роли

become: yes

Не надо так, лучше применять к конкретной таске если она требует повышения привилегий

apt:

state: latest

Снова ИМХО, но я бы взял package чтобы не прибиваться гвоздями к apt, а не ИМХО - стейт лучше указывать present с указанием конкретной версии, иначе, если запускать в разное время на разные группы хостов можно получить разное состояние хостов

Динамические переменные:

Здесь стоило упомянуть про то как ansible их получает - gathering_facts и модуль setup

Создал конфигурационный файл в корне проекта

Крайне рекомендую добавить:

• gathering = explicit - значительно укоряет плейбуки, в которых не используются факты с хостов

• roles_path = ./roles:$ANSIBLE_HOME/roles:/usr/share/ansible/roles:/etc/ansible/roles - иногда бывает удобно расположить роли рядом с плейбуками в проекте, например для их разработки и/или отладки

• vault_password_file = .vault_pass - ansible-vault - в любом проекте рано или поздно появятся секреты и очевидно у каждого проекта они должны быть свои (а сам .vault_pass естественно в gitignore)

• [ssh_connection]
retries = 2 - поможет при обрывах коннекта, а то особенно больно когда хостов много и приходится гонять плейбук несколько раз, чтобы точно все везде прокатилось
  ssh_args = -o ForwardAgent=yes - на случай если на удаленном хосте нужен ssh, например склонить репу (потому что клони через https с авторизацией, а уж тем более копирование ключей - зло)

И убрать become = True

Ну и поделюсь своим плейбуком, вдруг будет что интересно полезно