Ansible centos 7. начало работы
Содержание:
- Создание плейбука
- Interdependence of Ansible Tower and OneLogin
- Демо «Реальное приложение»
- Собираем свой playbook
- Troubleshooting
- Зачем нужна оркестрация локальной машины?
- Пробуем Ansible
- External credential vaults
- Теги
- Deprecation Updates
- Improvements in the AWX Collection
- Playbook копирование SSL, перезапуск Apache
- Ansible shell module output
- Controlling errors with failed_when
- Настройка Ansible
- Playbook установка Nginx, PHP, MySQL и Redis
- When to use the yum module vs package module
- Changing Default Directory and Shell
Создание плейбука
Создаем файл для playbook:
vi /etc/ansible/play.yml
—
— hosts: redhat-servers
become:
true
become_method:
su
become_user:
root
remote_user:
ansible
roles:
— epel
— nginx
— hosts: debian-servers
become:
true
become_method:
sudo
become_user:
root
remote_user:
ansible
roles:
— nginx
* где:
- — — начало файла YAML. Данный формат имеет строгую структуру — важен каждый пробел;
- hosts — группа хостов, к которым будут применяться правила плейбука (если мы хотим, чтобы правила применялись ко всем хостам, указываем hosts: all);
- become — указывает на необходимость эскалации привилегий;
- become_method — метод эскалации привилегий;
- become_user — пользователь под которым мы заходим с помощью become_method;
- remote_user — пользователь, под которым будем подключаться к удаленным серверам;
- roles — список ролей, которые будут применяться для плейбука.
* В данном случае мы задействуем нашу группы хостов, которые создали в самом начале; повышаем привилегии методом su под пользователем root (su — root) для группы redhat-servers и методом sudo для debian-servers; подключение к серверам выполняется от пользователя ansible; используем созданную нами роль nginx (саму роль мы создадим позже). Для систем RPM сначала выполним роль epel — она будет отвечать за установку репозитория EPEL, так как в стандартном репозитории nginx нет.
Стоит отдельно уделить внимание вопросу повышения привилегий. IT-среды могут применять разные политики относительно безопасности
Например, на серверах CentOS, по умолчанию, нет sudo и повышать привилегии нужно с помощью su. В Ubuntu наоборот — по умолчанию есть sudo, а su не работает, так как пароль на root не устанавливается. В данном случае есть несколько путей при работе с Ansible:
- Как в нашем примере, разделить группы хостов на разные семейства операционных систем и применять к ним разные методы повышения привилегий. Чтобы данный плейбук корректно отработал, учетная запись, под которой идет удаленное подключение к серверу (в нашем примере ansible) должна иметь такой же пароль, как у пользователей root на серверах семейства Red Hat. Данный метод удобен с точки зрения отсутствия необходимости приводить к единому виду безопасность серверов разного семейства. Однако, с точки зрения безопасности лучше, чтобы пароли у root и ansible были разные.
- Использовать метод для создания плейбука, как описан выше, но запускать его с ключом —limit, например, ansible-playbook —limit=debian-servers … — таким образом, мы запустим отдельные задания для каждого семейства операционных систем и сможем ввести индивидуальные пароли для каждого случая.
- Мы можем на всех серверах deb установить пароль для пользователя root, таким образом, получив возможность для become_method: su.
- И наконец, можно для серверов Red Hat установить sudo и проходить become с помощью метода sudo.
Interdependence of Ansible Tower and OneLogin
Defined in Ansible Tower, needed by OneLogin:
- ACS URL
- Entity ID
Defined in OneLogin, needed by Ansible Tower:
- Issuer URL
- SAML 2.0 Endpoint (HTTP)
- X.509 Certificate
Ansible Tower and OneLogin Definitions
|
Ansible Tower |
OneLogin |
|---|---|
|
SAML ASSERTION CONSUMER SERVICE (ACS) URL |
ACS (Consumer) URL |
|
SAML SERVICE PROVIDER ENTITY ID |
Audience |
|
SAML ENABLED IDENTITY PROVIDERS (python dictionary where entity_id is the “magic” key) |
Issuer URL |
|
SAML ENABLED IDENTITY PROVIDERS (python dictionary where url is the “magic” key) |
SAML 2.0 Endpoint (HTTP) |
|
SAML ENABLED IDENTITY PROVIDERS (python dictionary where x509cert is the “magic” key)* |
X.509 Certificate |
The multi-line One Login x.509 cert needs to be made into a single line via https://www.samltool.com/format_x509cert.php
Демо «Реальное приложение»
Цель этой демонстрации — установить приложение Laravel в VPS. Для этого используем lightsail.
-
- .
- .
- .
- .
- .
- .
- .
- .
- .
- .
- .
- .
- .
- .
- .
Рассмотрим каждый пункт подробнее.
Создание экземпляра Ubuntu Lightsail
Перейдите на панель управления Lightsail и нажмите «Создать экземпляр».
Выберите свою любимую ОС.
Выберите «Добавить скрипт запуска», который запускается после создания вашего экземпляра. Не забудьте получить SSH-ключ.
Установка зависимостей Ansible на нашем VPS
Добавьте эти sh-команды для установки зависимостей Ansible:
Теперь у нас есть готовый экземпляр, перейдём к построению Ansible Project.
hosts.ini
ansible.cfg
Определение роли в Ansible
Используем модуль Ping, чтобы убедиться, что хост работает, после чего нужно обновить все пакеты и установить два модуля: git и htop.
Установка модулей PHP
Чтобы вызвать обработчик в Ansible, мы должны использовать notify: Restart PHP-FPM, имена обработчиков должны быть уникальными.
В этом руководстве мы определили php как тег, поэтому, например, если вы хотите запустить только эту задачу из своего playbook, вам необходимо выполнить её с —tags = ”php”, которая будет исполнять только её.
Как использовать Ansible-Vault
Создайте секретный файл хранилища, содержащий ключ шифрования, который шифрует ваши переменные.
Чтобы зашифровать переменные, используйте:
Чтобы расшифровать переменные, используйте:
Генерирование .env
Ansible использует шаблонизатор Jinja2 для динамических выражений и доступа к переменным. Создадим файл env.conf.
Определим , чтобы переместить этот шаблон в директорию нашего приложения.
Создание playbook
Как видно, мы определили aws как хост для этого playbook, и sudo yes даёт нам возможность выполнять команду как пользователю sudo. У нас есть vars_files, где мы храним наши vars. Мы установили roles, каждая role выполняет определённую задачу. И, наконец, у нас есть handlers, которые содержат все обработчики проекта.
Собираем свой playbook
Мы уже знаем, что по большей части playbook — это набор задач разной степени вложенности. Теперь научимся писать эти задачи.
Главное, что нужно усвоить, — для выполнения каждой задачи требуется использовать модуль. Модуль — это actor, который может совершать действия определенного типа. К примеру:
- устанавливать и обновлять пакеты;
- создавать и удалять файлы;
- клонировать репозитории;
- пинговать хосты;
- отправлять сообщения в Slack.
Для каждой задачи передаем модуль и набор параметров его запуска, например список пакетов для установки. Модулей очень много, с их полным списком ты можешь ознакомиться здесь. А пока пройдемся по тем, которые нам понадобятся.
1. Обновление системы и установка пакетов
Модули pacman, apt, brew и другие пакетные менеджеры для языков и систем.
Для обновления системы и установки базовых пакетов программ напишем пару тасков с использованием модуля pacman. Вот пример подобной задачи:
Здесь мы определили две задачи: в первой обновляем систему, во второй передаем модулю список пакетов, которые нужно установить, и инструкцией сообщаем, что надо поднять привилегии до суперпользователя.
Кстати, мы можем также передать имя юзера, которым нужно стать при выполнении этой команды, как мы сделали бы это при использовании . Например, таким образом можно поменять шелл для себя при установке zsh в задаче с модулем command:
Обрати внимание на блочный конфиг задачи install zsh: это удобный (но необязательный) способ записи для группировки нескольких действий, не требующих выноса в отдельные (под)задачи. Для установки из AUR можно использовать и yaourt (правда, сейчас его уже подвинул новый yay)
Поскольку устанавливать из AUR под рутом нельзя, а мы определили повышение привилегий в корневой задаче, создадим отдельного юзера и будем переходить под него в задачах установки из AUR:
Для установки из AUR можно использовать и yaourt (правда, сейчас его уже подвинул новый yay). Поскольку устанавливать из AUR под рутом нельзя, а мы определили повышение привилегий в корневой задаче, создадим отдельного юзера и будем переходить под него в задачах установки из AUR:
Теперь при установке пакетов мы можем включить блок установки из AUR:
Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!
Подробнее
Вариант 2. Открой один материал
Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя!
Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.
Я уже участник «Xakep.ru»
Troubleshooting
Authentication failed: SAML login failed: (towersam is not a valid audience for this Response).Cause: Mismatching Ansible Tower Entity ID and One Login Audience
Authentication failed: SAML login failed: (Invalid issuer in the Assertion/Response).Cause: Mismatching Ansible Tower SAML ENABLED IDENTITY PROVIDERS entity_id and One Login Issuer URL
Cause: Mismatching Ansible Tower SAML ENABLED IDENTITY PROVIDERS url and One Login SAML 2.0 Endpoint (HTTP)
Authentication failed: SAML login failed: (Signature validation failed. SAML Response rejected).Cause: Mismatching Ansible Tower SAML ENABLED IDENTITY PROVIDERS x509cert and One Login X.509 Certificate
u’name_ids’.Cause: Incorrect Ansible Tower SAML ENABLED IDENTITY PROVIDERS attr_user_permanent_id
Зачем нужна оркестрация локальной машины?
Давай для начала определимся, зачем мы хотим управлять своим компьютером с помощью оркестратора. Под оркестрацией твоего компьютера мы будем понимать:
- автоматическую установку программ;
- размещение файлов конфигураций;
- выполнение единовременных команд (вроде установки плагинов);
- клонирование рабочих репозиториев;
- настройку среды разработки
и так далее. В рамках этой статьи мы научимся автоматизировать действия, которые нужно совершить от установки базовой системы до получения готового к работе компьютера.
Зачем это может потребоваться? Несмотря на то что большинство людей годами не переустанавливают систему, причин дисциплинированно держать свои конфиги в порядке может быть масса. Для себя я выделил следующие.
Воспроизводимость
Мне важно иметь возможность быстро поднять привычную рабочую среду на новой машине. Ситуации бывают разные:
- внезапно отказал диск;
- появилась необходимость поработать на другом железе;
- эксперименты с Линуксом породили необъяснимые глюки, а время поджимает.
В подобных случаях часто приходится раскатывать ОС с нуля, ставить весь необходимый софт и, что самое неприятное, мучительно вспоминать все пляски с бубном, которые устраивал при предыдущей настройке ОС. Поясню: в моем случае это установка Arch Linux (сама по себе довольно муторная), допиливание оконного менеджера i3, донастройка железа (вплоть до чувствительности BT-мыши), стандартная ерунда вроде локалей, шрифтов, systemd-юнитов и shell-скриптов. И все это без учета установки и настройки непосредственно рабочего софта.
Ничего страшного в этой процедуре нет, но она занимает почти день. При этом все равно что-то забудешь и вспомнишь об этом, только когда выяснится, что оно не работает, не настроено или не установлено.
Предсказуемость
Очень полезно знать, что в системе установлено и как настроено. Когда конфиг перед глазами, быстрее понимаешь, почему ОС так работает (или не работает).
Если не представляешь четко, что, как и когда ты сконфигурировал в системе (а в Linux невозможно запомнить все даже с опорой на ArchWiki), ты вскоре обнаружишь, что также не понимаешь, почему эта программа сейчас работает так, хотя раньше работала иначе. Возможно, ты ставил какой-то плагин или что-то исправлял в конфиге, но забыл?
Имея под рукой полное описание всех настроек в одном месте, ты с меньшей вероятностью столкнешься с этими проблемами.
Декларативность и поддерживаемость
Декларативный подход к конфигурированию (читай: описание, как должно быть, а не что нужно сделать) значительно упрощает понимание настроек. Вносить необходимые изменения в них становится куда проще, а вот свои костыли поддерживать в итоге сложнее, чем стороннее, но проверенное решение.
Пример наивного «инсталлятора» пакетов в одном из моих скриптов. И это только одна функция
Кстати, если ты тоже без ума от декларативного подхода к описанию ОС, обрати внимание на дистрибутив NixOS.
Другие решения?
Разумеется, для быстрого развертывания можно приспособить и другие инструменты, например системы образов вроде эппловской Time Machine или Norton Ghost. Можно подойти и более радикально: запускать софт в контейнерах Docker или даже виртуалках в AppVM. Проблема в том, что сложно их поддерживать, управлять ими и обновлять софт на регулярной основе. Другими словами, они созданы для решения несколько других задач и не так бесшовно встраиваются в повседневную жизнь, если это не твоя работа 24/7.
Пробуем Ansible
Что нужно для работы Ansible?
Linux, Python и в некоторых случаях SSH. Сразу оговорим термины:
- master — машина, с которой мы осуществляем управление, другими словами — на которой мы запускаем Ansible со скриптом. Она выполняет команды на удаленной (целевой) машине;
- target — машина, над которой мы выполняем задачи, другими словами — целевая машина, на которой по скрипту нужно развернуть рабочее окружение.
Строго говоря, в отличие от других систем оркестрации, устанавливать Ansible на целевом хосте не обязательно. Если у тебя есть еще один компьютер (я проделывал это, например, с Raspberry Pi 3), Ansible нужно иметь именно на нем.
Но мы провернем трюк: используем одну машину и как target-хост, и как master-хост. Поэтому просто установим Ansible через .
Только что установленный Arch Linux с Python и Ansible через pip. Больше ничего не нужно
Перечисляем хосты и запускаем playbook
С этого момента договоримся, что мы не разделяем master- и target-машины, все действия выполняем на одной машине. Для удаленных хостов процедура будет почти такая же.
Перед запуском скрипта укажи Ansible список хостов, над которыми нужно совершать операции. Обычно список по группам указывается в файле . Создай этот файл и напиши следующее:
Этими строками мы:
- создали группу ;
- определили в ней один хост c адресом (можно указать любой доступный IP);
- дополнительно для хоста указали тип соединения .
Здесь необходимо пояснение. Обычно при работе с удаленными хостами Ansible соединяется с ними по SSH и выполняет определенные в скрипте операции. Однако, поскольку мы выполняем действия над «самим собой», было бы излишне поднимать sshd-демон, чтобы законнектиться к самому себе. Для таких случаев Ansible позволяет указать дополнительный параметр ansible_connection, который определит тип соединения. В нашем случае это local.
Попробуем пропинговать хосты на отклик (в нашем случае единственный хост):
Ответ по — работает.
External credential vaults
Ansible Tower 3.5 brings support for external credential vaults. The existing credential store is still available for use. However, as enterprises grow credentials often need to be made more available for distributed applications. In this release, Ansible Tower now supports corporate standard password and key storage directly from Ansible Tower.
With a special thanks to our partners, Ansible Tower 3.5 now supports the following external vaults:
- HashiCorp Vault
- CyberArk AIM
- CyberArk Conjur
- Microsoft Azure Key Vault
If you’d like to learn more about incorporating any of these new credentials vaults please read the Secret Management System documentation.
Теги
В нашем примере нам не довелось использовать теги — еще одну удобную возможность управления запуском плейбука.
Теги позволяют отметить роль и при запуске плейбука запустить именно ее, проигнорировав другие роли. Например, есть такой плейбук:
…
roles:
— role: nginx
tags: web1
— role: apache
tags: web2
* в данном плейбуке есть две роли — одна называется nginx, вторая — apache; для каждой роли мы задали свой тег.
Теперь, чтобы запустить плейбук, но выполнить в нем определенную роль, нам достаточно указать тег:
ansible-playbook —tags web2 /etc/ansible/play.yml -kK
* данная команда запустит плейбук с выполнением только роли с тегом web2 (в нашем примере, apache).
Deprecation Updates
During the removal of tower-cli, we attempted to keep the modules as similar as possible to ease the transition from the old Core modules to the new collection. Inevitably, some minor changes had to be made; details of these changes can be found in the “Release and Upgrade” section of the AWX Collections file. Some changes to mention include:
- extra_vars parameters no longer support load of variables from a file by specifying a @<file name> notation. Instead, they now take dictionaries. If you were previously loading a file, please use the lookup plugin to load the file instead.
- Some modules no longer return values the way they used to. All returns have been unified across the modules and primarily return the ID of the object modified.
Improvements in the AWX Collection
The modules delivered by Ansible Core and the initial versions of the AWX Collection had a dependency on libraries provided by the tower-cli project. Due to the deprecation of tower-cli, there is work currently being done to remove that dependency. This has led to a major update to the AWX Collection.
During the removal of tower-cli, we have tried to keep the modules backwards-compatible with their corresponding version that shipped in Ansible Core. This way, if you have already leveraged the tower_* modules from Ansible Core, there should be very little work required when switching to the AWX Collection. For more information, see the section below.
In addition, we have standardized the modules’ operational logic, thus making the collections modules more uniform. Previously, each module was written individually (sometimes by different authors). This caused subtle differences of behavior for the individual modules. The modules distributed in the AWX Collection follow a standard pattern, which provides consistency even if written by different authors.
The syncing of the collection to the Red Hat Ansible Tower versions also allows the modules’ parameters to be kept in sync with the options available within the web UI and API. As part of the recent changes, we have added some new tooling as well as updated many of the modules to now include parameters for functionality which have been added to Ansible Tower since the modules were initially released.
The collection now also provides better support for idempotency as well as check_mode. In previous versions using check_mode, older modules would simply ensure that they could connect to the Ansible Tower server but not indicate if they would have actually made a change to an Ansible Tower object. The AWX Collections modules will now more accurately indicate if they would have changed a Tower object via check_mode.
Playbook копирование SSL, перезапуск Apache
Обновление файла hosts
nano /etc/ansible/hosts
host-01 ansible_user=adminX host-02 ansible_user=adminX host-03 ansible_user=adminX
в этом блоке явно указывается имя пользователя, от имени которого будут выполняться действия на конечном хосте. Если пользователи совпадают(на ansible-сервер и ansible-клиенте), то это действие можно опустить. Создание Playbook-а:
nano /etc/ansible/playbooks/ssl-update.yml
---
- hosts: SSL-UPDATE
become: yes
tasks:
- name: COPY SSL FILES-1
copy:
src: /etc/nginx/ssl/vist.od.ua/certificate.crt
dest: /etc/apache2/ssl/certificate.crt
- name: COPE SSL FILES-2
copy:
src: /etc/nginx/ssl/vist.od.ua/private.key
dest: /etc/apache2/ssl/private.key
- name: APACHE2 RESTART
service:
name: apache2
state: restarted
Ansible shell module output
When you execute a command using the shell module, it also returns some fields, which you can use to debug the tasks. You can see the command executed, the output, the errors etc. The full list of return values for this module is available at . You can store the result of the command in a ‘register’. And you can either see the full list of return values or specific ones.
In the following example, the output of the echo command will be stored in a register named ‘command_result’. It will contain all the return values of the shell module. So if you print the value, then it will contain the ‘command you executed’, the ‘output shown in the remote system’, ‘time when the command was executed’ etc. If you don’t want the full list and only the output or command, then you can do it by specifying it like command_result.stdout or command_result.cmd.
- hosts: loc
tasks:
- name: Ansible shell module output
shell: echo $PWD
register: command_result
- name: Ansible shell register result
debug: msg="{{ command_result }}"
- name: Return only the shell standard output
debug: msg="{{ command_result.stdout }}"
The first debug task will show the output similar to below.
ok: => {
"msg": {
"changed": true,
"cmd": "echo $PWD",
"delta": "0:00:00.003216",
"end": "2017-03-26 07:45:25.055561",
"rc": 0,
"start": "2017-03-26 07:45:25.052345",
"stderr": "",
"stdout": "/home/mdtutorials2",
"stdout_lines": [
"/home/mdtutorials2"
],
"warnings": []
}
}
The second debug task will show just the stdout value.
ok: => {
"msg": "/home/mdtutorials2"
}
Controlling errors with failed_when
When you are running the shell module or the command module, you might want it to fail only if particular conditions are met and not the default errors. Ansible provides a ‘failed_when’ parameter for this. This is a common parameter and not part of the shell module or command module.
In the following Ansible task, I am trying to remove the shell.txt file. When you repeat the task, the task will fail in the normal case. But using the failed_when parameter, I changed the fail condition as to only fail when the string ‘Permission denied’ is in the stderr. I had already captured the output of the command in a variable(register) called output.
- name: Executing a command using command module
command: rm shell.txt
args:
chdir: /root/ansible
register: output
failed_when: "'Permision denied' in output.stderr"
The shell module provides some return values like ‘stderr’ and ‘stdout’. You can find more return values in the Ansible .
For more details on both modules refer shell module and command module.
Настройка Ansible
Ниже будет приведен пример с возвратами ошибок, после исполнения команд. Этот режим позволил найти некоторые недочеты в описании конфигураций.
nano /etc/ansible/hosts
файл имеет вид
нужно добавить группу и её членов
192.168.1.60
Поддержи автора статьи, просмотри рекламу ↓↓↓
проверить выполнение команды ansible можно способом
ansible -m ping all
текущий вывод не возвращает ошибок, но содержит информации о том, что доверительные отношения между ansible-сервером и ansible-клиентом ещё не установлены. Этот пункт нужно выполнить на опережение, чтобы в лишний раз не вводить Y, YES или видеть ошибку в SSH соединении
ssh-keygen -t rsa
параметры ключа не изменялись, т.е. во всех трех предложениях был введен “Enter”.
Сгенерированный ключ нужно скопировать на ansible-клиент для того, чтобы при установки SSH соединение не требовалось вводить пароль. Ещё один способ – утилита sshpass, но по критериям безопасности этот способ был исключён.
ssh-copy-id adminX@192.168.1.60
результат
Поддержи автора статьи, просмотри рекламу ↓↓↓
проверить работу ключа можно командой
ssh adminX@192.168.1.60
По выполнению которой терминал должен переключиться на ansible-клиент без запроса пароля, установки ключей, сертификатов. Если возвращаются какие-либо запросы, то скорей всего есть несоответствие между ключом ansible-сервера и конечным каталогом при копировании на ansible-клиенте(зависит от пользователя, режима sudo и тд.)
Возвращаясь к выполнению команды Ansible
ansible -m ping all
в результате ошибка, в которой указано что доступ запрещен. Если проверка беспарольного доступа “ssh adminX@192.168.1.60” не возвращает дополнительных запросов, значит проблема в пользователе ansible-сервера и ansible-клиента. А ведь и правда, на ansible-сервере стоит CentOS7.5 и команды выполняются под пользователем root, а ansible-клиенте стоит Ubuntu и команды выполняются под пользователем adminX.
nano /etc/ansible/hosts
добавить пользователя, от чего имени будет выполняться команда ping
192.168.1.60 ansible_user=adminX
повторное выполнение
ansible -m ping all
В некоторых случаях может быть возврат сообщения
Поддержи автора статьи, просмотри рекламу ↓↓↓
который указывает на то, что на сервере отсутствует пакет python 2-ой версии. Для исправления нужно выполнить на конечном хосте:
sudo bash -c "test -e /usr/bin/python || (apt -qqy update && apt install -qy python-minimal)"
Результатом проделанных операций есть установленный Ansible, который выполняет команды на конечном сервере-клиенте через беспарольный SSH.
Playbook установка Nginx, PHP, MySQL и Redis
Задание такое: описать конфигурацию playbook-а на Ansible по установке пакетов на сервера CentOS:
- обновление ОС;
- php7 с модулями (bcmach, imagik, pdo, amqp);
- phpmyadmin;
- nginx;
- mysql;
- redis;
- mc.
В исходной позиции подготовлены три сервера на CentOS 7.5 в виде виртуальных машин.
adminX@s-vmm-2:~$ virsh list --all Id Name State ---------------------------------------------------- 14 S-COS-03 running 15 S-COS-02 running 16 S-COS-01 running
Добавление новых серверов в окружение Ansible(основные принципы описаны )
nano /etc/ansible/hosts
192.168.1.
копирование ssh ключа для беспарольного доступа
ssh-copy-id adminX@192.168.1.60 ssh-copy-id adminX@192.168.1.61 ssh-copy-id adminX@192.168.1.62
проверка доступности узлов через Ansible
ansible -m ping all
Поддержи автора статьи, просмотри рекламу ↓↓↓
создание playbook-а для обновление CentOS с последующей перезагрузкой
nano /etc/ansible/playbooks/cos-lemp-update.yml
---
- hosts: COS-LEMP
tasks:
- name: Update OS
yum:
name="*" state=latest
- name: restart system to reboot to newest kernel
shell: "sleep 5 && reboot"
async: 1
poll: 0
- name: wait for 10 seconds
pause:
seconds: 10
- name: wait for the system to reboot
wait_for_connection:
connect_timeout: 60
sleep: 5
delay: 5
timeout: 120
- name: install epel-release
yum:
name=epel-release state=latest
вывод
Поддержи автора статьи, просмотри рекламу ↓↓↓
nano /etc/ansible/playbooks/cos-lemp.yml
---
- hosts: COS-LEMP
tasks:
- name: Install PHP+Nginx+MC
yum: name={{ item }} state=present
with_items:
- 'php'
- 'php-bcmath'
- 'ImageMagick'
- 'php-pdo'
- 'php-amqp'
- 'php-mysql'
- 'phpmyadmin'
- 'nginx'
- 'redis'
- 'mc'
- name: Add mysql repo
yum: name=http://dev.mysql.com/get/mysql80-community-release-el7-1.noarch.rpm state=present
- name: Install MySQL
yum: name="mysql-community-server"
- name: start services
service: name={{ item }} state=started enabled=yes
with_items:
- 'nginx'
- 'mysqld'
- 'redis'
Установка пакетов производилась только на двух серверах, чтобы иметь “чистую” копию в резерве. Однако с такой конфигурацией количество серверов не имеет значения, вывод
When to use the yum module vs package module
The module manages packages using whichever package manager is present on the remote host, such as , or . This appears to be the most convenient way to manage packages, but I advise you to avoid using the module in any situation.
The biggest reason to avoid it is because the same package may have different names on different distros.
For example: the server package for the popular in-memory database Redis is called on Debian based distros and on Red Hat based distros.
Unless you (and everyone on your team) is intimately familiar with the naming differences for packages across all distributions, using drastically increases the chance of an error due to package naming. I highly recommend you manage packages using the module specific to the remote host.
The most common pattern for creating roles that can be run across all distributions is to run tasks conditionally based on the variable:
Changing Default Directory and Shell
In the last examples, the command will always be executed in the default directory. You can change this behavior, and specify the directory path where you want to run the command using chdir parameter. This is available for both shell and command modules.
You can also change the default shell by specifying the absolute path of the require shell in the executable parameter.
- hosts: loc
tasks:
- name: Ansible Shell chdir and executable parameters
shell: ls -lrt > temp.txt
args:
chdir: /root/ansible/shell_chdir_example
executable: /bin/bash
- hosts: loc
tasks:
- name: Ansible command module with chdir and executable parameters
command: ls -lrt
args:
chdir: /home/mdtutorials2/command_chdir_example
executable: /bin/bash
In both examples, I am using the ‘Bourne Again SHell’ by giving the absolute path /bin/bash. And I have changed the directory to /root/ansible/shell_chdir_example.
Note: Shell and command modules are among the few modules in Ansible which are not idempotent by default. So if you rerun a task, the system status is not checked before running. For some tasks like the last example, it is also desired.
Making tasks idempotent by using creates keyword
You can make the shell and command modules idempotent using the ‘creates‘ keyword and ‘removes‘ keyword. This depends on the presence or absence of a file. i.e., we can specify the task should run only if a file exists or removed.
In the below example, we are creating a new file. If the file is already present, we do not need to run the command again. So we can set the filename in the ‘creates’ parameter.
- name: Ansible shell module creates parameter example.
command: touch shell.txt
args:
chdir: /root/ansible
creates: shell.txt
You can see the difference in the below GIF. The playbook shell_no_creates.yaml do not have the ‘creates’ parameter and the ‘shell_creates.yaml’ has it.
You can use the ‘removes‘ parameter in a similar manner. Here I am checking if the file already exists before trying to remove it. Else it would throw an error if the file doesn’t exist.
- name: Ansible command module creates parameter example.
command: rm shell.txt
args:
chdir: /root/ansible
removes: shell.txt
