Для тех кто используетненавидит и в целом измученн puppet'ом, ansible покажется глотком освежающего нарзана, Эдакий фремворк систем управления конфигураций.
Структура работы с системой такова: вносим хосты в список => пишем плейбук под группу хостов => начинаем использовать.
Описываем сеть.
[hardware]
server_1
server_2
Файл hosts очень прост — мы, словно заправские хипстеры добавляющие второй миллион уникальных фотографий в винтажный коллаж только что создали группу [hardware] и внесли в нее два сервера — server_1 и server_2. Таких групп может быть бесконечное количество. И в бесконечном количестве групп может находится бесконечное количество серверов. Попробуйте себе представить эту картину — стройными, узкими рядами группы выстраиваются в колонны и чеканя шаг маршруют мимо благосклонно взирающего на них сисадмина. Рядом с родителями тоже чеканя шаг смешно перебирают маленькими ножками их дети… Стоп! Дети?
[hardware:children]
hypervisors
[hypervisors]
proxmox_1
proxmox_2
proxmox_3
Одна группа может быть подчиненна другой группе — таким образом если мы назначаем копать от забора и до обеда группе [hardware], они, как и любые другие родители, отправляют «на картошку» и своих детей [hypervisors]. А вот [hypervisors] заставлять стареньких маму и папу в лице [hardware] не будет, да и не может: авторитет не тот.
Кстати, как люди передают друг другу в наследство фамильные замки, длинные носы и сервизы, так родитель [hardware] передаст группе [hypervisors] значение своих переменных.
И да, вы не умерли и не попали в рай — переменные могут отлично назначатся группе, отдельному хосту, детям, взрослым, перезаписываться в зависимости от контекста и подгружаться из файлов.
[webservers_fail:vars]
nginx_conf=/usr/local/etc/nginx/var/www/conf/nginx/nginx43/not_delete/vavilon/project15/nginx.conf
Таким образом мы можем подставлять любые переменные в любой конфиг и в зависимости от значения этих переменных исполнять какие-то куски кода и менять что-то на что-то.
Стоит обратить внимание на забавный факт — ansible старается минимум действий оставлять коммандной строке. И если мы хотим сделать что-то нестандартное — надо править файлы.
Таким образом если сервера сидят на нестандартном порту надо это указать в явном виде в конфигурационном файле hosts либо в описание самого хоста, либо в группе.
[webservers]
webserver_super_security ansible_ssh_port=80
no_dns_host ansible_ssh_host=192.168.0.2
webserver_2
webserver_3
[webservers:vars]
ansible_ssh_port=222
Группировку по хостам удобно использовать для определения групп хостов (Хором: «Спасибо, Капитан!»). Таким образом в зависимости от группы мы, используя один единственный плэйбук можем как конфигурить полет на луну, так и исправить внесенные минутой раньше ошибочные конфиги самого важного продакшн сервера.
Плэйбуки: поиграй со мной
Если вы создали плейбук — запустить его можно командой ansible-playbook
— hosts webservers
tasks:
— name: FOO
shell: /bin/foo
tags: foo
— name: install zsh
apt: name=zsh state=latest
tags: install
Постигший красоту плейбуков — постиг дзен, постигшему дзен еще нужна одна бесконечность дабы постичь суть плейбуков. Но если коротко — плейбуки это наборы комманд обьединенные по любым удобным признаком. Команды выполняются друг за другом и могут зависеть от переменных.
— name: Installing smartctl
apt: name=smartmontools state=latest
tags: check_mk
when_set: $install_smartctl
— name: Adding smartctl
template: src=../roles/common/templates/smartctl dest=/usr/lib/check_mk_agent/plugins/smart mode=0755
tags: check_mk
when_set: $install_smartctl
Таким образом описанные выше команды исполнятся только в том случае если переменная Install_smartctl задана.
Кстати о дзене. Любому простофиле известно что дзен не терпит хаоса и повторений, но при этом сам является хаосом и повторением. И детище американского программиста учит нас и этому: мы можем вкладывать плейбуки в плейбуки, в плейбуки вкладывать задачи и списки переменных.
Таким образом написав однажды плейбук который создает юзеров, устанавливает программы, настраивает общие конфиги типа .zshrc и варит кофе мы сможем использовать его снова и снова в любом другом плейбуке верхнего уровня делая обыкновенный include:
— include: firststep.yml
vars_files:
— «softlist.yml»
Однажды написав переменные для нужных операционных систем мы сможем использовать их снова и снова просто подключая их куда угодно. Кстати, однажды написанный список софта может быть использован любым плейбуком-установщиком.
Например напишем такой конфиг:
— hosts: debian
var_files:
— «softlist.yml»
task:
— name: MainSoft Debian
apt: name=$mainsoft state=latest
— hosts: CentOS
var_files:
— «softlist.yml»
task:
— name: MainSoft CentOS
yum: name=$mainsoft state=latest
А файл softlist.yml у нас будет таким:
mainsoft:
— zsh
— htop
— sudo
— less
— iftop
— tcpdump
— mc
— screen
— wget
— vim
Теперь просто добавляя строчки в список мы сможем манипулировать сразу всеми хостами не правя 100500 разных конфигураций.
А как выйти из мертвой петли читайте в следующем номере. Все там — роли и запуск команд.
Естественно мои жалкие попытки вкратце расказать о ansible не смогут отразить всех замыслов великого комбинатора, но, надеюсь, заинтересуют вас достаточно для того что бы вы с ужсом и нетерпением ожидали моих дальнейших потуг на столь актуальном поприще описания самой удобной из систем управления конфигураций.
Автор: ctrlok
