2.Ansible: модули

Thank you for reading this post, don't forget to subscribe!

Боль­шин­ство дей­ствий на уда­лён­ных хостах (нодах) мож­но выпол­нить с помо­щью моду­лей Ansible.

Напри­мер — модуль shell поз­во­ля­ет выпол­нять кон­соль­ные коман­ды на сервере:

1 $ ansible all -m shell -a 'echo $HOSTNAMEE'
2 cent_ans_serv | success | rc=0 >>
3
4 cent_ans_client1 | success | rc=0 >>

Ключ -a для моду­ля shell исполь­зу­ет­ся для пере­да­чи ему аргументов.

Так же мож­но уста­но­вить и какое-то при­ло­же­ние, напри­мер — lftp.

Доба­вим поль­зо­ва­те­ля mid в sudoers, и раз­ре­шим ему выпол­не­ние коман­ды без вво­да паро­ля — вызы­ва­ем visudo, добав­ля­ем строку:

1 mid ALL=(ALL)       NOPASSWD: ALL

Повто­ря­ем на обо­их хостах, после чего выпол­ня­ем установку:

1 $ ansible all -s -m shell -a 'yum -y install lftp'
2 ...
3 cent_ans_serv | success | rc=0 >>
4 Loaded plugins: fastestmirror, security
5 ...
6 Installed:
7   lftp.i686 0:4.0.9-1.el6_5.1
8
9 Complete!

Конеч­но, такой под­ход к уста­нов­ке паке­тов не самый удоб­ный. Поэто­му — мож­но исполь­зо­вать модуль yum.

Напри­мер, уста­нов­ка nmap на всех хостах с помо­щью моду­ля yum выгля­дит так:

1 $ ansible all -s -m yum -a 'name=nmap state=latest'

Про­ве­ря­ем:

1 $ yum list installed | grep nmap
2 nmap.i686              2:5.51-4.el6       @base

Ansible име­ет огром­ное коли­че­ство встро­ен­ных моду­лей, даже такие как ec2 — для управ­ле­ния сер­ве­ра­ми EC2 в AWS, или portinstall — для управ­ле­ния пор­та­ми FreeBSD. Име­ют­ся и моду­ли сто­рон­них раз­ра­бот­чи­ков, напри­мер — ansible-bamboo для управ­ле­ния сер­ве­ром Bamboo.

 

Рас­смот­рим наи­бо­лее часто исполь­зу­е­мые моду­ли и их параметры.

Модуль command при­ни­ма­ет коман­ду и аргу­мен­ты, раз­де­лен­ные про­бе­лом. Аргу­мен­та­ми могут быть:

  • chdir — пере­ход в ката­лог для выпол­не­ния команды;
  • creates — созда­ние фай­ла по ука­зан­но­му пути;
  • removes — уда­ле­ние фай­ла по ука­зан­но­му пути.

Для про­вер­ки рабо­ты моду­ля command напи­шем набор инструк­ций /etc/ansible/playbooks/install_ntpdate.yml тако­го вида:

Модуль shell — это ана­лог моду­ля command с важ­ным отли­чи­ем: для выпол­не­ния команд исполь­зу­ет­ся обо­лоч­ка /bin/sh. Пара­мет­ры такие же, как и у моду­ля command — chdircreates и removes.

Модуль script исполь­зу­ют при необ­хо­ди­мо­сти копи­ро­ва­ния скрип­та на уда­лен­ный хост с после­ду­ю­щим выпол­не­ни­ем. Под­дер­жи­ва­ют­ся пара­мет­ры creates и removes. Для про­вер­ки рабо­ты дан­но­го моду­ля напи­шем про­стей­ший скрипт /etc/ansible/playbooks/scripts/count_dir.sh со сле­ду­ю­щим содержимым:

При­ме­ча­ние. Скрипт посчи­та­ет коли­че­ство дирек­то­рий в /var/log.

Playbook в этом слу­чае будет выгля­деть так:

Модуль file пред­на­зна­чен для создания/удаления ката­ло­гов, сим­во­ли­че­ских ссы­лок и фай­лов, а так­же для рабо­ты с атри­бу­та­ми фай­лов. Параметры:

  • group — имя груп­пы-вла­дель­ца файла/каталога;
  • owner — имя поль­зо­ва­те­ля-вла­дель­ца файла/каталога;
  • mode — пра­ва досту­па к файлу/каталогу;
  • path — путь к файлу/каталогу (мож­но исполь­зо­вать али­а­сы dest или name);
  • src — путь к фай­лу, для созда­ния сим­лин­ка (исполь­зу­ет­ся при state=link);
  • recurse — рекур­сив­но уста­но­вить атри­бу­ты файла/каталога (исполь­зу­ет­ся при state=directory);
  • state — опре­де­ля­ет типы фай­лов, над кото­рым про­во­дят­ся опе­ра­ции (filelinkdirectoryhardtouch и absent).

При­мер исполь­зо­ва­ния моду­ля в набо­ре инструкций:

 

Модуль copy исполь­зу­ет­ся для копи­ро­ва­ния фай­лов на уда­лен­ный хост. Кро­ме уже опи­сан­ных выше пара­мет­ров groupownermode может при­ни­мать следующие:

  • backup — созда­ет резерв­ную копию фай­ла (в име­ни фай­ла будет допи­сан timestamp);
  • dest — куда будет ско­пи­ро­ван файл (абсо­лют­ный путь на уда­лен­ном хосте);
  • directory_mode — исполь­зу­ет­ся для рекур­сив­но­го копи­ро­ва­ния каталогов;
  • force — копи­ро­вать файл на уда­лен­ный хост, если содер­жи­мое фай­ла было изменено;
  • src — отку­да копи­ро­вать файл — локаль­ный путь (абсо­лют­ный или относительный).

При­мер исполь­зо­ва­ния в набо­ре инструкций:

Для управ­ле­ния пла­ни­ров­щи­ком задач исполь­зу­ет­ся модуль cron. Может при­ни­мать сле­ду­ю­щие параметры:

  • backup — созда­ет резерв­ную перед изменением;
  • cron_file — исполь­зу­ет ука­зан­ный файл из ката­ло­га cron.d вме­сто поль­зо­ва­тель­ско­го crontab;
  • day — день запус­ка зада­чи (1-31, *, */2);
  • hour — час запус­ка зада­чи (0-23, *, */2);
  • minute — мину­та запус­ка зада­чи (0-59, *, */2);
  • month — месяц запус­ка зада­чи (1-12, *, */2);
  • weekday — неде­ля запус­ка зада­чи (0-6 for Sunday-Saturday, *);
  • disabled — заком­мен­ти­ро­вать ранее добав­лен­ную задачу;
  • job — задача;
  • name — опи­са­ние зада­чи в crontab (ком­мен­та­рий);
  • state — суще­ству­ет ли такая задача(принимает зна­че­ния present и absent);
  • user — поль­зо­ва­тель, в чей crontab сле­ду­ет доба­вить задачу;
  • special_time — спе­ци­аль­ное вре­мя запус­ка зада­чи (reboot, yearly, annually, monthly, weekly, daily и hourly).

При­мер playbook с исполь­зо­ва­ни­ем моду­ля cron:

 

Playbook с исполь­зо­ва­ни­ем моду­ля template полу­чит­ся такой:

На уда­лен­ном хосте по ука­зан­но­му нами пути появил­ся файл со сле­ду­ю­щим содержимым:

При­ме­ча­ние. Дан­ный модуль так­же поз­во­ля­ет исполь­зо­вать функ­цию validate, кото­рая про­ве­ря­ет файл перед его копи­ро­ва­ни­ем на уда­лен­ный сервер.