Автоматизируем всё, что можно автоматизировать, параллельно создавая документацию, а также разобьём всё по нодам.
Представим ситуацию: вам поступила задача подготовить рабочее место для пользователя (или развернуть сервис) и установить необходимый софт. Вы прекрасно справились с задачей, но на следующий день поступает аналогичный запрос: один из отделов расширяется, поэтому необходимо настроить ещё несколько рабочих мест (или серверов) по вчерашней схеме.
Будете повторять действия вручную или примените готовый скрипт? Оба варианта имеют место быть, но что, если через день - два потребуется на одном из компов (серверов) что-то удалить или что-то добавить? А как в коде разберётся коллега в случае вашего отсутствия?
Нам необходимо устранить несколько больших проблем:
- Отсутствие общих правил написания скриптов.
- Автоматическое выполнение только тех изменений, которые не были применены во время предыдущего запуска скрипта.
- Отсутствие лёгкой группировки серверов/рабочих станций.
- Отсутствие автоматического отчёта о результатах.
Обрисовав основные проблемы, мы затронули тему IaC:
IaC: Infrastructure as Code
Когда мы не лезем управлять сервером/ПК вручную, а делаем всё через скрипты/конфигурационные файлы, то нашу инфраструктуру можно представить как код.
Как правило, это достаточно понятные файлы, взглянув на которые, можно сразу понять какое значение принимает каждый параметр:
Другими словами, когда инфраструктура описана кодом и этот код применим к какой-либо системе управления конфигурациями, это называется Infrastructure as Code.
Что такое Ansible?
Ansible представляет собой решение для управления конфигурациями в строгом соответствии с IaC, причём имеет открытый исходный код и немало готовых плагинов.
Теперь простыми словами: Ansible - это то, что настроит машины в соответствии с вашими потребностями в автоматическом режиме.
Для работы он использует конфигурационные файлы, называемые плейбуками (playbook), которые пишутся в соответствии с языком разметки YAML (скорее всего вы с ним уже имели дело, в нём нет абсолютно ничего сложного).
Почему Ansible?
- Решение обозначенных ранее проблем.
- Востребованность на рынке IT.
- Лёгкость в освоении.
- Отсутствие потребности в установке клиентов на целевые хосты.
- Наличие большого количества готовых плейбуков, плагинов, ролей и коллекций.
Как это работает?
Control node
Ansible устанавливается на одном из хостов, именуемым control node (узел управления). В этом качестве может использоваться сервер, ПК или виртуальная машина. Нод управления может быть сколь угодно много, каждая из них может одновременно быть управляемой нодой.
Managed node
Управляемый узел (managed node) представляет из себя устройство под управлением Windows (Server)/Linux/Unix и других ОС, поддерживающее протоколы ssh и telnet или имеющее свой API.
Обращаю внимание, что компьютер/сервер под управлением Windows не может выступать в качестве управляющей ноды (даже с активной wsl)!
Заключение
На этапе внедрения Ansible потребует гораздо больше времени, чем при обычном выполнении задач. У вас всегда остаётся вариант подключиться и сделать всё "ручками", но не стоит им злоупотреблять. Представив свою инфраструктуру как код, вы автоматически получите своего рода документацию по каждому устройству в сети, а в случае его замены - автоматическую настройку нового узла в полном соответствии с предыдущим.
В следующих статьях покажу установку и первый запуск Ansible (начнём с ping-pong).
Спасибо, что дочитали статью до конца. Поддержите канал лайком или подпиской, чтобы чаще видеть в ленте подобный контент. Всего вам доброго!)
---
Следующая часть:
Все части: