Для настройки окружения проекта можно использовать (а многие так и делают) стандартные средства операционной системы. Такие, как пакетный менеджер (yum, apt), прямое редактирование конфигурационных файлов, bash-скрипты, curl/wget и многое другое.
Этот подход, с одной стороны, самый простой, но он обладает рядом недостатков, некоторые из которых критические.
Первая проблема - это отсутствие повторяемости. Обычно изменения в первую очередь делаются локально, потом их нужно перенести на рабочие машины ваших коллег, а в конце концов все изменения должны оказаться на сервере. При этом иногда вам придется пересобирать локальное окружение (по множеству причин). Такой подход всегда приводит к рассогласованию настроек на разных машинах, появляются разные версии программного обеспечения, неправильно настроенные конфиги, забытые ключи.
Обычно, когда в компанию, использующую такой подход, приходит новый человек, первые три дня он сидит и пытается завести проект. И в процессе составляет инструкцию по настройке окружения, которая, естественно, устаревает и про нее все забывают. Дальше все повторяется.
Подписывайтесь на канал Кирилла Мокевнина в Telegram — чтобы узнать больше о программировании и профессиональном пути разработчика
Следующая проблема является продолжением предыдущей. Это невозможность увидеть и быстро оценить текущее состояние инсталяции. Информация о том, что сейчас актуально, разбросана по всей системе. Если происходит какой-то сбой, то очень сложно найти концы. Нет возможности увидеть, какое изменение повиляло или могло повлиять на поломку. Со временем эта проблема начинает мешать все больше. Любые инфраструктурные изменения будут проходить болезненно и почти наверняка приведут к ошибкам.
Может показаться, что решением является написание, например, bash-скриптов. И в любом случае это уже шаг вперед. Но есть одна серьезная проблема. Это обеспечение идемпотентности. Идемпотентная операция в информатике — действие, многократное повторение которого эквивалентно однократному. Что на практие означает отсутствие идемпотентности? То, что повторный запуск bash-скрипта (кроме тривиальных случаев) приведет к ошибке и остановке выполнения.
Примеры:
Вызов mkdir упадет с ошибкой что "директория существует". Операции перенаправления вывода повторно запишут данные. Любая операция, связанная с удалением, закончится с ошибкой (mv, rm, rmdir). Клонирование git репозитория упадет с ошибкой. ln упадет с ошибкой. И многое другое. Это означает, что вам нужно либо всегда накатывать bash-скрипт на чистую систему, что невозможно, либо вам нужно будет все скрипты обвешивать проверками, которые и будут обеспечивать идемпотентность.
Также, поскольку bash это полноценный язык программирования, это приводит к тому, что каждый пишет одну и ту же задачу по-разному. Ну, и нельзя не упомянуть, что с ростом сложности и размера читать bash-скрипты становится достаточно сложно.
Кроме этого, в инфраструктуре проектов от среднего и выше присутствует, как правило, не один тип серверов. А серверов одного типа может быть даже не 5. Не говоря уже о том, что эти bash-скрипты нужно каким-то образом доставлять на сервера и выполнять их (желательно паралелльно), а так же обеспечивать контроль выполнения. А иногда бывают задачи, которые требуют перезагрузки сервера, обмена данными между узлами системы, выполнения задач только на группах серверов.
К счастью, решение существует, и это не ручные скрипты, а системы управления конфигурацией. Их достаточно много и все они предлагают концепцию «управление инфраструктурой как программным кодом». Это означает, что описание инфраструктуры хранится в файлах (плейбуках, кукбуках и так далее), находящихся под контролем версий, а сама инфраструктура изменяется только посредством запуска процесса накатки изменений. Также эти системы знают про топологию серверов и позволяют вам гибко указывать, что к чему относится, дают возможности легко переиспользовать повторяющиеся сценарии, а так же выполнять множество других полезных функций. Например, Ansible, кроме настройки инфраструктуры, отлично подходит для настройки облаков, таких как aws, а также для деплоя проектов. Отличительной чертой Ansible является то, что конфигурация описывается в yaml-файлах и не требует программирования.
Пример работы Ansible
$ ansible-playbook playbook.yml -i inventory.ini -u ubuntu
inventory.ini
[webservers]
web1.hexlet.internal
web2.hexlet.internal
playbook.yml
hosts: webservers
tasks:
- name: install packages
apt: pkg=postgresql state=latest
become: yes
Как освоить Ansible
Самый простой способ — пройти практический курс по Ansible на Хекслете. Вы научитесь работать с плейбуками, тегами, хендлерами, переменными, условиями, фильтрами и другими важными аспектами работы. После прохождения курса вы сможете уверенно пользоваться этим инструментом как для личных локальных целей (например, автоматическая настройка локального окружения), так и для рабочих целей (например, массовая настройка сети серверов).
К тому же, на сайте Ansible есть раздел с документацией.
