Ansible: hosts и ansible.cfg. Lesson 1
Уважаемые читатели, в данной статье разберем основы при работе с Ansible. Материал будет интересен в первую очередь новичкам. Для начала рекомендуем также прочитать данные 2 статьи:
- Установка Ansible на Debian
- Установка и настройка SSH для авторизации без пароля
* Здесь мы не будем затрагивать вопрос установки, и настройки SSH соединения с серверами (об этом есть материал выше).
1. Ansible — что это и для чего? Разбираем основы
Если вы только установили Ansible, необходимо перейти в его каталог и проверить содержимое:
Ansible — это система управления конфигурациями, написанная на Python. Более простым языком: это универсальный инструмент позволяющий выполнять некий структурированный список команд (написанный на языке YML, в виде скрипта) на нескольких серверах.
Если у вас несколько серверов 5. 100, то при попытке даже простого обновления пакетов, вы потеряете уйму времени на подключение к каждому из этих серверов по отдельности. Ansible дает универсальное средство решить данную проблему, как? читаем дальше!
2. Настройка файла hosts под наши сервера
Прежде всего нам надо настроить список наших серверов, на которые мы будем отправлять наши данные. Для этого заходим в файл hosts:
Содержимое файла hosts будем примерно таким:
Допустим у нас есть сервера c IP 192.168.0.10 и 192.168.0.20 (локальный). Добавим наши сервера в файл выше и укажем данные для подключения к ним (пояснения прямо в коде):
Пример заполнения выше, с данными пользователя, не совсем корректный. Лучше использовать SSH. О том как его настроить, ссылка на статью в самом начале. Смотрим где у нас находится ключ SSH:
Вносим эти данные в наш файл hosts:
Можно попробывать подключиться к серверу. Есть один момент, при подключении первый раз к серверу он спросит отпечаток: «Are you sure you want to continue connecting (yes/no)». После подтверждения, он больше не спрашивает. Но если вы подключаетесь первый раз к 100 серверам, то придеться отвечать по каждому. Простая команда для примера:
Чтобы отменить проверку отпечатка на каждый сервер и не прописывать файл сервера, заполняем файл ansible.cfg. Обычно эти значения уже есть в шаблоне, надо только их раскомментировать:
Повторяем команду выше, но уже сокращенный вариант:
3. Создаем файл inventory или hosts
Допустим у вас много серверов: сервера баз, сервера приложений, сервера итогового проекта PROD. Тогда это можно записать в файл hosts в разных вариантах:
Тем самым, вот так просто вы можем составлять группы, а в созданные группы еще группы. Это удобно, главное не переборщить.
Теперь объединим данные для авторизации для серверов debi:
Или в виде графа:
4. Выносим общие переменные из файла hosts
В пункте 3 мы вынесли общие переменные с данными пользователя в отдельный блок. Но на практике, такие данные более професионально выносить в отдельный файл. Это мы сейчас и сделаем:
Проверям что у нас в каталоге Ansible:
Создаем директорию group_vars и переходим в неё:
Создаем файл с нашим именем группы серверов debi_servers:
Сохраняем. В файле hosts эти строчки полностью стираете:
Стал чистый файл hosts который содержит только сервера и группы серверов. Все данные с vars теперь в отдельном файле, расположенном в директории group_vars. Так и должно быть, это более профессиональное написание.
На этом статья заканчивается, продолжение читаем в следующих статьях!
Источник: http://linuxsql.ru
Инструмент автоматизации Ansible
Статья также доступна на украинском (перейти к просмотру).
Оглавление
- Существующие подходы к удаленному управлению конфигурациями серверов
- Общие сведения о Ansible
- Практическое использование Ansible
- Развертывание
- Формирование списка управляемых узлов
- Настройка конфигурации системы
- Тестирование
Задача автоматизации процессов управления конфигурациями удаленных серверов наиболее востребована среди DevOps-специалистов. Это связано с отсутствием единого подхода к их решению и сложностью обеспечения надежного и быстрого управления большим количеством различных типов серверов. Предлагаемый инструментарий может стать наиболее удачным решением для более чем 99 % случаев удаленного администрирования.
Существующие подходы к удаленному управлению конфигурациями серверов
Можно выделить два принципиально разных подхода, касающихся удаленного управления машинами. Первый из них заключается в использовании императивных методов управления, когда формируется набор обязательных для выполнения на клиентских машинах директив, задающих детальный алгоритм реализации задачи. Критерием успешности выполнения задачи является одинаковое состояние конфигурации каждой из машин группы серверов. Среди недостатков подхода можно отметить сложность программ, задающих конфигурацию клиентов, а также невозможность обеспечения достаточного уровня надежности выполнения из-за сложности соблюдения условий критерия успешности – обеспечения одинаковых состояний конфигураций. Среди наиболее известных реализаций указанного подхода – использование bash-скриптов для формирования директив, определяющих конфигурацию клиентов.
Второй подход опирается на декларативные методы управления конфигурациями, когда в управляющей программе описывается только результат выполнения задачи без алгоритма ее реализации, то есть фактически она является спецификацией будущей конфигурации. Реализация такой управляющей программы является задачей конкретных клиентских машин со своим программно-аппаратным наполнением. Это отражение известной в мире концепции IaC (Infrastructure as Code), рассматривающей разветвленную инфраструктуру серверов в виде кода, определяющего идемпотентные изменения в ее состоянии. Такой подход обеспечивает стопроцентную надежность выполнения задачи независимо от предыдущего состояния конфигурации системы любой из машин группы серверов. Сколько раз программа не запускалась бы, результат будет тот же. Это более перспективный подход и поэтому существует достаточно много его реализаций.
Сущность одной из реализаций декларативного подхода заключается в использовании предметно-ориентированного языка разметки для формирования управляющих программ – спецификаций задач – и их последующей передачи на клиентские машины для обработки заранее установленным и настроенным специальным программным обеспечением (ПО). Недостатком здесь сложность подготовки клиентского ПО, хотя надежность и качество достаточно высоки. Наиболее известными примерами являются Puppet и Chef.Сущность одной из реализаций декларативного подхода заключается в использовании предметно-ориентированного языка разметки для формирования управляющих программ – спецификаций задач – и их последующей передачи на клиентские машины для обработки заранее установленным и настроенным специальным программным обеспечением (ПО). Недостатком здесь сложность подготовки клиентского ПО, хотя надежность и качество достаточно высоки. Наиболее известными примерами являются Puppet и Chef.
В другой реализации декларативного подхода также используется декларативный язык разметки для описания конфигураций клиентов, однако здесь не требуется наличие дополнительного клиентского ПО для формирования заданной конфигурации. Ее формирование происходит за счет использования защищенного канала, образованного протоколом ssh и возможностями языка Python, установленного на всех клиентских машинах. То есть, управление запуском модулей с описанием конфигурации узлов происходит посредством push-сообщений канала ssh, а их выполнение осуществляется на языке Python. Поэтому метод получил название «push-based», то есть, базирующийся на push-сообщениях. Примером является SaltStack. Определенным недостатком здесь является большое количество дополнительных сервисов, усложняющих его использование.
Альтернативой SaltStack является использование более упрощенной программы Ansible, которая позволяет выполнять те же задачи, что и указанный сервис, однако более проста в использовании. Рассмотрим ее более подробно.
Общие сведения о Ansible
Как уже отмечалось, Ansible опирается на декларативный подход и использует push-сообщения для управления удаленными машинами. В качестве языка разметки используется YAML (Yet Another Markup Language), который ориентирован на описание типовых структур данных и является более простым в использовании по сравнению с XML (eXtensible Markup Language).
В целях абстрагирования от менее значимых вещей, можно выделить три основных компонента инфраструктуры под управлением Ansible:
- Управляющий узел;
- Управляемые узлы или клиенты;
- Список хостов или inventory в терминологии Ansible.
Управляющий узел может быть размещен как на локальном компьютере, так и на удаленном сервере. Для его функционирования достаточно установить соответствующее ПО. Все определения конфигураций клиентов хранятся здесь. Ansible может быть установлен на компьютере с операционной системой (ОС) на базе Linux. ОС Windows не поддерживается в качестве узла управления Ansible, однако возможно установить его на ОС Windows 10 на подсистему WSL (Windows Subsystem for Linux). При этом будут действовать некоторые ограничения по функциональности программы, поэтому лучше использовать ее только для обучения и ознакомления. Среди других требований требуется наличие Python 2 версии 2.7 или Python 3 3.5 или выше. Также необходимо наличие установленного протокола ssh.
Конфигурация программной среды узла может быть задана с помощью файла /etc/ansible/ansible.cfg. Другие файлы ansible.cfg могут быть размещены в текущем каталоге проекта или в домашней пользовательской директории. При этом самый высокий приоритет будет иметь файл текущей директории проекта.
Управляемые узлы могут включать в себя от одного до бесконечного количества машин (существуют только технические ограничения), на которых сконфигурирован сервер ssh и установлен Python соответствующей версии. Этого вполне достаточно для возможности управления клиентом из управляющего узла.
Список хостов является списком IP-адресов управляемых узлов с учетной информацией, обычно находится в файле /etc/ansible/hosts.
Практическое использование Ansible
Подготовка к работе с Ansible заключается в выполнении нескольких шагов. Это развертывание управляющего узла на сервере, формирование списка управляемых узлов с добавлением учетной информации по каждому из них, настройка конфигурации системы и ее тестирование. Рассмотрим эти шаги более подробно.
Развертывание
Развертывать управляющий узел будем на сервере под управлением ОС Ubuntu 20.04. В соответствии с требованиями, необходимыми для ПО, проверим существующую версию языка Python. Для этого наберем в терминале:
$ python3 --version
Установленная версия Python 3.8 полностью отвечает установленным требованиям.
После этого включим PPA (Personal Package Archive) в список источников нашей системы с помощью следующей команды:
$ sudo apt-add-repository ppa:ansible/ansible
После подтверждения согласия процесс подключения продолжится:
Теперь обновим индекс пакетов системы, чтобы стали доступны новые пакеты. Для этого введем в терминале:
$ sudo apt update
Начнем процесс установки программы с помощью следующей команды:
$ sudo apt install ansible
Требуемый дополнительный объем дискового пространства для программы составляет 324 MB. После подтверждения нашего согласия на его выделение процесс установки продолжится.
Конечный экран вывода программы установки выглядит следующим образом:
Убедимся, что программа установлена ??и выясним названия и местонахождение ее основных компонентов. Для этого введем в терминале:
$ ansible –version
Как можно убедиться, программа Ansible успешно установлена ??и определены локации ее основных модулей.
Формирование списка управляемых узлов
Список удаленных клиентов формируется в файле /etc/ansible/hosts с вводом необходимой учетной информации для автоматического подключения к узлам по ssh. Этот путь к файлу hosts со списком хостов устанавливается по умолчанию программой. Однако местонахождение файла может быть и другим в зависимости от потребностей проекта. Это следует учитывать при запуске команд Ansible, о чем будет сказано ниже. Откроем файл в редакторе:
$ sudo nano /etc/ansible/hosts
В открывшемся файле создадим группу webservers, в которой пропишем имена хостов, IP-адреса и учетные данные для каждого из хостов. В нашем случае, подключение к хосту server1 будет происходить по паролю, а к хосту server2 – с использованием ключей ssh. Здесь мы указали путь доступа к местонахождению файла секретного ключа для server2. Это необходимо в случае если удаленный хост потребует подтверждения наличия указанного ключа на управляющем узле. Открытый или публичный ключ в это время должен находиться на server2 в специальном файле аккаунта пользователя, который мы используем для входа. Адрес этого файла: ~/.ssh/authorized_keys.
В разделе all:vars мы указали общие для всех групп хостов параметры – логин пользователя для входа (alexandr75001) и указание использования Python3.
Сохраним введенную в файл информацию (Ctrl+O) и выйдем из редактора (Ctrl+X).
Теперь выведем список доступных для Ansible управляемых узлов и одновременно убедимся, что программа правильно идентифицировала введенную нами информацию по клиентским узлам. Для этого введем следующую команду:
$ ansible-inventory --list -y
По результатам вывода команды можно убедиться, что все группы и узлы программой идентифицированы верно.
Настройка конфигурации системы
Как уже отмечалось, программная среда управляющего узла настраивается с помощью конфигурационных файлов, которые могут располагаться на разных уровнях. Приведем пример настройки файла конфигурации, расположенного на самом низком уровне. Для этого введем в терминале:
$ nano /etc/ansible/ansible.cfg
В открывшемся файле в комментариях можно посмотреть примеры его заполнения. Добавим в него информацию по трем разделам – defaults, ssh_connection и diff. Установленные параметры позволяют регулировать автоматический процесс соединения по протоколу ssh и изменять значения стандартных настроек, например, касающихся местоположения файла логов программы, выдачи системных сообщений и многих других. Сохраним изменения и выйдем из редактора (Ctrl+O, Ctrl+X).
Тестирование
Сущность тестирования заключается в выяснении ситуации относительно доступности управляемых узлов, достоверности их учетных данных для соединения по протоколу ssh и возможность запуска на узлах модулей Ansible с помощью установленного на них Python. Для этого Ansible имеет модуль ping, который может быть запущен на управляющем узле с разным набором параметров. В частности, там можно указать логин пользователя узлов, если он не указан в файле hosts. Например, протестируем управляемые узлы нашего проекта, запустив соответствующий модуль Ansible:
$ ansible all –m ping
Проанализируем результат. По сообщениям, оба хоста недоступны и это понятно, поскольку они действительно недоступны в сети. Вместе с тем команда верно определила все данные наших настроек – имена хостов, соответствующие IP-адреса и порты, что говорит о том, что управляющий узел сконфигурирован верно. В случае доступности узлов, по каждому из них должен был быть ответ, вроде следующего:Проанализируем результат. По сообщениям, оба хоста недоступны и это понятно, поскольку они действительно недоступны в сети. Вместе с тем команда верно определила все данные наших настроек – имена хостов, соответствующие IP-адреса и порты, что говорит о том, что управляющий узел сконфигурирован верно. В случае доступности узлов, по каждому из них должен был быть ответ, вроде следующего:
server | SUCCESS =>
Именно этот ответ говорил бы о полной готовности всей разветвленной инфраструктуры узлов к работе.
Работа с командами Ansible
После проверки работоспособности всей инфраструктуры можно управлять узлами с помощью команд Ansible. Все эти команды начинаются с ключевого слова ansible и могут иметь значительный набор параметров. Например, можно управлять таким образом как всей группой клиентов, так и выбранными машинами даже одной.
Например, для того, чтобы вывести информацию по всем группам управляемых узлов о типах файловых систем дисковых устройств и их загруженности, используется следующий формат соответствующей команды Ansible:
$ ansible all -a "df -h"
Та же команда, но только для узлов нашей группы webservers будет выглядеть следующим образом:
$ ansible webservers -a "df -h"
Для одного узла той же группы:
$ ansible server1 -a "df -h"
Также можно перечислять нужные узлы прямо в команде:
$ ansible server1:server2 -a "df -h"
Вместо команды «df –h» может быть использована любая другая, но принцип управления узлами остается прежним.
Как отмечалось выше, при запуске команд Ansible необходимо учитывать местонахождение файла hosts со списком управляемых узлов. Для этого следует использовать параметр –i. Например, укажем в команде местоположение файла hosts в другом месте:
$ ansible webservers -a "df -h" –i /etc/mmm/hosts
Работа с Playbook
В терминологии Ansible playbook это файл в формате yml со списком задач для управляемых узлов. Вместо того, чтобы набирать каждую команду в терминале, лучше сформировать список команд в одном файле, а затем одной командой запустить его во исполнение для всех узлов. Таким образом получаем двойную автоматизацию процесса управления удаленными узлами. Команды формируются с помощью деклараций языка разметки YAML, о чем уже говорилось ранее.
Код в playbook является четко структурированным. Он разбит на несколько разделов, в каждом из которых описываются определенные области данных. Приведем названия этих разделов и их назначение:
hosts – указываются названия узлов, прописанных в общем списке.
become – прописывается уровень пользовательской привилегии, от имени которого запускается playbook.
vars – определение пользовательских переменных.
tasks – список команд для исполнения.
Для примера, приведем код реального playbook, который содержит информацию из нашего файла hosts:
hosts: webservers become: 'yes' vars: user: - name: "alexandr75001" password: "aGRJt3gaOb" ssh_key: "ssh-rsa . " packages: - htop - wget - curl tasks: [. ]
Вышеприведенный код после запуска приведет к установке указанных в коде пакетов htop, wget и curl на всех узлах нашей группы webservers. Значение yes в разделе become говорит о том, что playbook будет запущен от имени пользователя с правами sudo. В разделе tasks могут быть и другие задачи, которые были бы выполнены. Ниже приведена структура указанного раздела:
tasks: - name: Task name user: [. ] loop: [. ]
В подразделе name прописывается сокращенное описание нашей задачи для самодокументирования playbook.
Модуль user запускается для выполнения и настраивается этой задачей. Он является объектом, инкапсулирующим требуемое состояние конфигурации. Такие модули могут управлять системными ресурсами и любыми службами.
Модуль loop представляет собой цикл по переменным. Он дает возможность организовать автоматическое повторение выполнения задачи любое количество раз с разными входными данными. Для этого достаточно запустить playbook только раз.
Дата-центр FREEhost.UA предлагает услуги аренды выделенных и виртуальных серверов по самым выгодным ценам в Украине. Гарантия доступности оборудования 99,99%, круглосуточная техподдержка, резервное электропитание. Приглашаем Вас воспользоваться нашими услугами.Подписывайтесь на наш телеграмм-канал https://t.me/freehostua, чтобы быть в курсе новых полезных материалов.
Мы в чем-то ошиблись, или что-то пропустили?
Напишите Об этом в комментариях, мы с удовольствием ответим и обсуждаем Ваши замечания и предложения.
Инвентарный файл
это то с чего надо начинать работу, по умолчанию хранится в /etc/ansible/hosts , Можно создать свой , и указать его при запуске с помощью команды -i myhosts.ini либо прописать путь к нему в конфигурационном файле inventory = ./myhosts.ini ( о нем поговорим позднее ) .
в этом инвентарном файле храниться информация о хостах, с которыми мы будем работать . файл может быть в формате ini или yaml, я привык использовать формат ini . На схеме ниже приведена логика конфигурации инвентарного файла в формате ini:
создадим простой инвентарный файл myhosts.ini :
[cisco_routers]
Router1 ansible_host=10.101.101.64
Router2 ansible_host=10.101.101.63
Router3 ansible_host=10.101.101.65[cisco_routers:vars]
ansible_connection=network_cli
ansible_network_os=ios
ansible_user=cisco
ansible_password=cisco123Конфигурационный файл
Конфигурационный файл Ansible может храниться в разных местах (файлы перечислены в порядке уменьшения приоритета):
- ANSIBLE_CONFIG (переменная окружения)
- ansible.cfg (в текущем каталоге)
- ~/.ansible.cfg (в домашнем каталоге пользователя)
- /etc/ansible/ansible.cfg
Ansible ищет конфигурационный файл в выше приведенном порядке , и использует первый найденный, все остальные игнорируются. Ниже приведен простой конфигурационный файл :
[defaults]
inventory = ./myhosts.ini
remote_user = cisco
ask_pass = True
gathering = explicit
host_key_checking=False
interpreter_python = /usr/bin/python3- [defaults] — эта секция конфигурации описывает общие параметры по умолчанию
- inventory = ./hosts.ini — параметр inventory позволяет указать местоположение инвентарного файла. Если настроить этот параметр, не придется указывать, где находится файл, при каждом запуске Ansible
- remote_user = cisco — от имени какого пользователя будет подключаться Ansible
- ask_pass = True — этот параметр аналогичен опции –ask-pass в командной строке. Если он выставлен в конфигурации Ansible, то уже не нужно указывать его в командной строке.
- gathering = explicit — По умолчанию Ansible собирает факты об устройствах. Факты — это информация о хостах, к которым подключается Ansible. Сбором фактов, по умолчанию, занимается модуль setup. Но для сетевого оборудования модуль setup не подходит, поэтому сбор фактов надо отключить. Это можно сделать в конфигурационном файле Ansible или в playbook.
- host_key_checking=False — Параметр отвечает за проверку ключей при подключении по SSH. Если указать в конфигурационном файле False , проверка будет отключена. Это полезно, когда с управляющего хоста Ansible надо подключиться к большому количеству устройств первый раз.
Ad Hoc команды
c помощью Ad-hoc команд — мы можем запускать различные действия из командной строки . Это самый простой и быстрый способ использования Ansible. Для начала нужно создать новый инвентарный файл, мы уже создали myhosts.ini . сейчас наша рабочая директория выглядит так :
.
├── ansible.cfg
├── myhosts.iniтеперь сделаем запрос с использованием ad-hoc команды :
ansible Router3 -i myhosts.ini -c network_cli -e ansible_network_os=ios -u cisco -k -m ios_command -a "commands='sh ip arp '"Разберемся с параметрами команды:
- Router3 — устройство, к которому нужно применить действие
это устройство должно существовать в инвентарном файле
это может быть группа, конкретное имя или адрес
если нужно указать все хосты из файла, можно использовать значение all или *
- -i myhosts.ini — параметр -i позволяет указать инвентарный файл
- -c network_cli — параметр -c позволяет указать тип подключения. Тип network_cli подразумевает передачу команд через SSH имитируя человека. Для работы network_cli обязательно нужно указывать network_os, в данном случае, это IOS -e ansible_network_os=ios
- -u cisco — подключение выполняется от имени пользователя cisco
- -k — параметр, который нужно указать, чтобы аутентификация была по паролю, а не по ключам
- -m ios_command — параметр указывает какой модуль используется
- -a «commands=’sh ip arp'» — параметр -a указывает, какую команду отправить
Большинство параметров можно указать в инвентарном файле или в файле переменных( о них еще поговорим) . В нашем инвентарном файле уже указана часть параметров, поэтому команду запроса можно сократить :
ansible Router3 -m ios_command -a "commands='sh ip arp '"результат выполнения будет таким :
Модули
Это небольшие программы, каждый модуль выполняет конкретную задачу . Модули можно выполнять отдельно в ad-hoc командах , как мы это сделали выше, указав используемый модуль с помощью -m ios_command , затем передали этому модулю аргумент -a “commands=’sh ip arp ‘“ , в нашем случае аргумент это команда которую надо выполнить на удаленном устройстве, есть так же аргументы которые влияют на поведение модулей. Модули так же можно прописывать в Playbook . После выполнения модуль возвращает результаты в формате JSON.
В Ansible модули разделены на следующие категории :
- core — модули, которые поддерживает основная команда разработчиков Ansible.
- network — поддерживает Ansible Network Team.
- certified — поддерживают партнеры Ansible
- community — поддерживает сообщество Ansible
Playbooks
это файлы в которых прописаны сценарии действий , которые нужно выполнить с какой то группой хостов .
playbook состоит из :
- Play — набор задач которые нужно выполнить для группы хостов
- task — конкретная задача .
ниже схема простого playbook’a использующего модуль ios_command:
Мы создали playbook и назвали его playbook-1, и того в нашей рабочей директории теперь три файла :
.
├── ansible.cfg
├── myhosts.ini
└── test1-playbook.yamlдля запуска ansible с использование playbook нужно ввести ansible-playbook, затем название плейбука :
$ ansible-playbook playbook-1.yamlвывод будет таким :
По дефолту ansible при использовании плейбука возвращает статус, корректно ли отработали сценарии плейбука. Если при вводе добавить ключ -v , то мы увидим процесс выполнения выполнения и вывод примененных команда , но он будет довольно трудным для прочтения. Чтоб вывод был более понятным используются специальные параметры register и debug , первый записывает вывод в указанную переменную , второй выводит данные переменной. В общем в плейбуке применение этих параметров будет выглядеть так :
---- name: show clock
hosts: all
gather_facts: falsetasks:
- ios_command:
commands: show clock
register: sh_vr
- debug: var=sh_vr.stdout_lines- name: show arp play
hosts: all
gather_facts: falsetasks:
- name: show arp
ios_command:
commands:
- show arp
- show ip arp
register: sh_result
- name: debug register
debug: var=sh_result.stdout_linesрезультат работы такого плейбука будет довольно наглядным :
Сохранение выходных данных
Для сохранения данных используется специальный параметр copy , работает примерно так же как debug, только записывает данные в указанный файл.
---
- name: show clock
hosts: all
gather_facts: false
tasks:
- ios_command:
commands: show clock
register: sh_vr
- debug: var=sh_vr.stdout_lines
- name: show arp play
hosts: all
gather_facts: false
tasks:
- name: show arp
ios_command:
commands:
- show arp
- show ip arp
register: sh_result
- name: debug register
debug: var=sh_result.stdout_lines- name: copy to file result
copy:
content: ">"
dest: "~/output/>_sh_arp.json"после этого в указанной директории появятся файлы с выводными данными, обратите внимание на переменную inventory_hostname мы ее не где не указывали, это дефолтная переменная в которую подставляются хосты из инвентарного файла. Более сложные задачи разберем в следующих статьях .
Установка и настройка Ansible в Linux
09.02.2023
itpro
CentOS, Debian, Linux, Ubuntu
Комментариев пока нет
Ansible популярная система управления конфигурациями, позволяющая удаленно управлять множеством серверов. Ansbile используют для автоматизации настройки и развертывания программного обеспечения. Основное преимущество Ansible – она не требует установки агентов на управляемых хостах (как Chef или Puppet). На хостах достаточно установить Python и сервер SSH. В этой статье мы рассмотрим, как установить и настроить сервер Ansible на Linux, и как использовать Ansible для управления другими хостами Linux.
Установка Ansible в Linux
Для работы Ansible нужно установить на управляющем и управляемых хостах ssh и python. Сам Ansible нужно установить только на управляющем сервере.
OpenSSH сервер обычно установлен по умолчанию во всех версиях Linux, поэтому осталось установить Python 3+ и сам Ansible.
Команды для Ubuntu/Debian:
$ sudo apt install python3
Python 3.8.10
$ sudo apt install ansible
ansible 2.9.6
Установка в CentOS, Rocky Linux, RHEL, Oracle:
$ dnf install epel-release
$ dnf makecache
$ dnf install python3
$ dnf install ansibleНачало работы с Ansible
При установке пакет будет создан каталог /etc/ansible со следующими конфигурационными файлами:
- /etc/ansible/hosts – здесь можно указано список хостов, которыми вы будет управлять через ansible;
- /etc/ansible/ansible.cfg — файл с настройками ansible.
В файле /etc/ansible/hosts можно создать несколько отдельных групп хостов. Например, все хосты с nginx, с базами mariadb и т.д. В этом примере мы создадим одну группу с именем servers_all.
$ sudo nano /etc/ansible/hosts
[servers_all] srvubunt1 ansible_host=192.168.14.144 ansible_user=sysops srvubunt2 ansible_host=192.168.14.142 ansible_user=sysops srv-db01 ansible_host=192.168.14.151 ansible_user=sysops
Можно указать хосты по DNS имени или IP. В ansible_user указан пользователь, который будет использоваться для подключения по SSH.
Одинаковые параметры группы хостов можно вынести в секцию с добавлением :vars, например:
[servers] srvubunt1 ansible_host=192.168.14.144 srvubunt2 ansible_host=192.168.14.142 [servers_all:vars] ansible_port=22 ansible_user=sysops
Чтобы вывести содержимое файла инвентаризации в виде дерева, выполните:
По умолчанию для подключения к удаленным хостам используется SSH. Чтобы автоматически принимать ssh fingerprint и не вводить yes при первоначальном доступе к хосту, нужно добавить параметр в файл /etc/ansible/ansible.cfg:
"host_key_checking = false"
Теперь с помощью встроенного модуля ping можно протестировать подключение. Модуль ping проверяет:
- доступность хостов;
- учетные данные SSH;
- возможность запускать модули Ansible на хостах с помощью Python.
Проверим доступность всех хостов в файле инвентаризации:
$ ansible all -m ping —ask-pass
Все хосты доступны.
Чтобы ansible мог аутентифицироваться по SSH с помощью пароля, нужно установить пакет sshpass:
$ sudo apt install sshpass
Иначе при использовании параметра —ask-pass будет появляться ошибка:
to use the 'ssh' connection type with passwords, you must install the sshpass program.
В предыдущем примере для подключения к удаленным хостам нужно каждый раз вводить пароль пользователя. Чтобы при выполнении команд и плейбуков ansible не запрашивался пароль, нужно настроит SSH аутентификацию по ключам.
Сгенерируйте RSA ключи на управляющем сервере:
$ ssh-keygen -t rsa
Не указывайте пароль для защиты SSH ключа.
Теперь нужно скопировать ключ на каждую ноду с помощью ssh-copy-id:
На удаленных серверах должна быть включена SSH аутентификация по ключам:
PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys
# service sshd restart
Теперь вы можете выполнить команду через ansible без ввода пароля. Проверим uptime на всех серверах в группе servers_all:
$ ansible servers_all -a ‘uptime’
Приведем несколько примеров интерактивного выполнения команд на хостах в файле инвентаризации.
Выполним инвентаризацию состояния хостов. В этом примере нам нужна только информацию о RAM на серверах:
$ ansible -m setup -a ‘filter=ansible_memtotal_mb’ all
С помощью модуля shell проверим uptime на всех хостах:
$ ansible -m shell -a ‘uptime’ all
Плейбуки в Ansible
Вы можете отправлять команды на управляемые сервера через консоль (ad-hoc) или с помощью специального файла playbook в формате YAML. В плейбуке можно описать требуемое состояние системы. Ansible при запуске будет проверять, соответствует ли конфигурация управляемого хоста описанию в плейбуке.
Рассмотрим пример простого плейбука, который должен установить на хостах файловый менеджер Midnight Commander (mc).
Создайте каталог для плейбуков:
$ sudo mkdir -p /etc/ansible/playbooks
Теперь создайте YML файл:
$ sudo nano /etc/ansible/playbooks/mc-deploy.yml
- hosts: servers_all become: yes become_method: sudo tasks: - name: update apt: update_cache=yes - name: Install mc apt: name=mc state=latest
Если управляемые хосты работают на CentOS-подобной версии Linux, нужно заменить последнюю строку на yum: name=mc state=latest .
В синтаксисе YAML-файлов используется строгая система отступов, как в Python. Используйте пробелы, а не табуляцию.
Чтобы выполнить плейбук на хостах в группе:
$ ansible-playbook /etc/ansible/playbooks/mc-deploy.yml —ask-become-pass
В данном случае для выполнения apt вам нужно ввести пароль для повышения привилегий через sudo.
Чтобы отключить пароля при использовании sudo в Ubuntu нужно на управляемых хостах выполнить команду:
$ echo «sysops ALL=(ALL) NOPASSWD:ALL» | sudo tee /etc/sudoers.d/sysops
После этого можно запускать плейбук без параметра —ask-become-pass .
В результатах плейбука видно, на каких серверах он отработал успешно.
В качестве графической оболочки можно использовать Ansible Tower (платная от RedHat) и Ansible AWX (бесплатная). С помощью Ansible вы можете управлять не только серверами Linux, но и Windows системами (потребует настроенный WinRM). Особенности управления Windows через Ansible мы рассмотрим в следующей статье.
Предыдущая статья Следующая статья 