Управление инфраструктурой даже средней организации является непростой задачей. Большое количество серверов требует постоянного внимания. Установка обновлений и развертывание новых систем все это трудоемкие задачи. Поговорим о том, каким способами можно автоматизировать выполнение данных задач.
Ад ручного конфигурирования
К вопросу установки и настройки программного обеспечения можно подходить по-разному. Самый распространенный способ конфигурирования - это конечно ручная настройка. Мы сами вручную вбиваем все команды, смотрим результат и ... снова вводим команды для исправления ошибок.
При ручном конфигурировании значительную роль играет человеческий фактор. Например: ошибка "Ой, забыл перезапустить", или установка не той версии потому что: "Я забыл добавить репозиторий с MongoDB и установил старую версию из репозитория ОС".
Установка многих громоздких приложений порой требует выполнения целой цепочки команд, и сбой в выполнении одной из них может привести к тому, что система остается в непонятном состоянии, когда мы не знаем какие компоненты уже установились, а какие еще нет. Конечно, если у вас виртуальная инфраструктура и вы предусмотрительно сделали снапшот, вы можете просто откатиться к предыдущему состоянию, но в противном случае вам придется долго и нудно изучать логи установки, разыскивая какая команда и почему не применилась и что вообще с этим делать дальше.
Снежинки и Фениксы
Отдельно хотелось бы обратить внимание на типы серверов из которых обычно состоит инфраструктура. В любой организации обычно присутствуют два типа серверов: Снежинки и Фениксы. Первые это использование уникального как снежинка набора установленного ПО. Обычно такие узлы являются наиболее критичными и находятся под особым мониторингом. Вторые - как птица Феникс могут возродиться из пепла, то есть, у них типовая конфигурация, предсказуемое поведение после установки необходимого ПО.
Примерами первого типа серверов являются различные серверы СУБД и приложений. Вторые это тестовые и учебные машины, которые не жаль потерять и легко восстановить.
Поддержка серверов первого типа является занятием весьма трудоемким, так как необходимо постоянно актуализировать резервные копии для того, чтобы иметь под рукой образ с необходимым набором установленных компонентов. Отсутствие актуального бэкапа влечет за собой необходимость долгого и продолжительного процесса установки и настройки отдельных компонент системы.
Жарка и запекание
К созданию готовых образов виртуальных машин существуют два диаметрально противоположных подхода. Первый предполагает создание минимального образа виртуалки с последующей настройкой после запуска (метод Fry), а второй наоборот предлагает поместить в образ все необходимые компоненты (Bake).
Рассмотрим достоинства и недостатки каждого из этих методов. В первом случае мы готовим виртуалку с минимальными настройками, тем самым экономя время на подготовку образа и место в хранилище, так как минимальный образ очевидно занимает меньше места. Однако, после развертывания такого образа необходимо потратить время на дополнительные настройки, что существенно снижает скорость деплоя. Кроме того, для обновления таких образов требуется доступ в интернет или собственный репозиторий.
Подход Bake предлагает включать все необходимые компоненты и настройки на этапе создания образа. Тем самым мы можем существенно ускорить развертывание образов. Кроме того, есть возможность подготовить различные образы для разных версий. Недостатками такого подхода является необходимость тратить значительное время на подготовку и последующую актуализацию образов. Также для хранения образов требуется больше места в хранилище.
На практике обычно используют некий средний вариант, при котором часть компонентов и настроек включается, а часть дополняется уже после развертывания образа.
Жизнь в облаках
При работе с облачными сервисами заказчику как правило предлагаются уже готовые образы операционных систем. Этот образ уже содержит все необходимые компоненты для работы на предоставляемым облачным провайдером железе.
Существует несколько решений для автоматизации процесса управления виртуальной инфраструктурой. Начнем с решения от Ubuntu – MaaS (Metal as a Service). Это решение с открытым исходным кодом представляет собой систему для работы непосредственно с железом. Этот инструмент очень полезен для обычных предприятий при управлении виртуализированной инфраструктурой. С помощью MAAS можно работать с такими ОС как Ubuntu, CentOS, Windows и RedHat.
Еще одно достаточно известное средство для работы как с обычными, так и с виртуальными машинами это Razor от Puppet. Принцип работы Razor следующий: после создания виртуальных машин с помощью Razor будет загружаться посредством PXE из специального образа микроядра Razor, затем регистрироваться, предоставлять Razor информацию об инвентаре и ждать дальнейших инструкций.
В Razor имеются настроенные администратором правила, которые определяют, какие типы задач должны выполняться на том или ином узле. Исходя из этих правил на новом узле начинается выполнение задач. О статусах выполнения этих задач Razor может сообщать в Puppet, vCenter И другие системы управления.
И еще один инструмент, предназначенный для работы с кластерами Kubernetes это Cluster API. Проект Cluster API позволяет с помощью API и шаблонов в стиле Kubernetes осуществлять автоматизацию управления жизненным циклом кластера.
Script ’Em All
Типичная ситуация, думаю знакомая многим, это когда вам необходимо установить приложение по чек листу или инструкции, но в процессе установки выясняется, что необходимо применить дополнительное обновление, в результате чего дальнейший процесс установки уже совершенно не совпадает с инструкцией и превращается в сущий ад.
Первое, что приходит в голову админам и инженерам в такой ситуации это написание скриптов для автоматизации установки и базовой настройки. Мы тратим время на написание и отладку скрипта, начинаем его использовать и тут выясняется, что вышла новая версия ПО, обновление или нужно поменять настройки и в результате переписывание скриптов превращается в бесконечный процесс. С этим, конечно, уже можно жить, но согласитесь, это не самое эффективное расходование времени.
Альтернативный вариант развития событий, это когда мы наоборот, один раз написав нужный скрипт затем используем его в исходном виде до тех пор пока это возможно, а затем пишем новый и также используем его не внося никаких изменений пока это возможно.
Вариант управления инфраструктурой с помощью скриптов конечно может упростить жизнь инженерам DevOps и администраторам но только в небольших организациях, где количество серверов не более 20, а число пользовательских узлов не превышает сотню.
Для сетей больших размеров требуются более сложные решения, такие как Инфраструктура как Код.
IaC, Infrastructure as a Code
Понятие Инфраструктура как код (англ. Infrastructure-as-Code; Iac) появилось в 2006 году, когда был запущен сервис AWS Elastic Compute Cloud и появился фреймворк Ruby on Rails. С появлением новых инструментов для решения проблем автоматизации администрирования и появился подход Инфраструктуры как кода.
IaC — это подход к управлению и описанию инфраструктуры ЦОД через конфигурационные файлы. Основными преимуществами инфраструктуры как сервиса являются: цена, скорость и уменьшение рисков. Понятие цены здесь рассматривается как капитальные и операционные затраты. Если капитальные затраты предполагают закупку дополнительного оборудования и ПО, то операционные затраты это не только стоимость сопровождения системы, но и затрачиваемое время на рутинные операции. Автоматизация инфраструктуры позволяет эффективнее использовать существующие ресурсы. Кроме того, правильно настроенная и качественно протестированная автоматизация позволяет минимизировать риск возникновения человеческой ошибки.
В блоге Отус подробно рассматривалось использование Terraform от HashiCorp в качестве системы IaC, поэтому здесь мы не будем подробно останавливаться на данной технологии.
Vagrant
Еще одно решение от HashiCorp для создания и управления VM. В зависимости от того, какая среда виртуализации используется мы можем с помощью Vagrant развернуть виртуальные машины в необходимой конфигурации, провести необходимые тесты и за тем удалить. Это будет гораздо быстрее ручного создания VM. Поддерживаются следующие среды виртуализации: Virtualbox, VMWare, Hyper-V, Docker и облачные провайдеры.
Замечу, также, что в большинстве курсов Отус для практических работ используется именно Vagrant.
Итак, давайте установим Vagrant под Linux.
wget -O- https://apt.releases.hashicorp.com/gpg | gpg --dearmor | sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install vagrant
Далее необходимо провести инициализацию. Так как нам необходимо создавать отдельную конфигурацию под каждый проект, мы создаем файл vagrantfile в котором на языке Ruby описана конфигурация виртуальной машины.
vagrant init ubuntu/xenial64
В результате выполнения этой команды мы получим файл конфигураций и загруженный образ операционной системы под именем ubuntu/xenial64.
Для создания и запуска виртуальной машины выполним команду
vagrant up
а для остановки и перезагрузки соответственно
vagrant halt
vagrant reload
Ну и когда потребность в виртуальной машине отпала и необходимо все удалить, можно воспользоваться командой
vagrant destroy
Одним из важнейших средств автоматизации, используемых в Vagrant являются плагины. В репозитории https://github.com/hashicorp/vagrant/wiki/Available-Vagrant-Plugins можно найти множество различных плагинов для работы с виртуалками.
В качестве примера установим плагин vagrant-vbguest. Данный плагин позволяет синхронизировать содержимое папок с кодом при обновлении виртуальных машин. Для установки выполним команду
vagrant plugin install vagrant-vbguest
Как уже упоминалось ранее, для работы с виртуальными машинами необходим конфигурационный файл Vagrantfile. Но, помимо возможности разворачивать свои виртуалки, разработчики также предлагают использовать уже готовые образы (box), которые находятся в Vagrant Cloud (https://app.vagrantup.com/boxes/search). Для этого необходимо воспользоваться командами вида:
vagrant init автор/box
vagrant up
Заключение
В этой статье мы рассмотрели несколько решений, предназначенных для автоматизации работы с инфраструктурой. Начав с ручного конфигурирования и написания скриптов, затем мы перешли IaC и Vagrant. Конечно это не полный набор средств автоматизации и в следующей статье мы подробно поговорим про Ansible и управлении инфраструктурой с помощью данного решения.
А сейчас пригласить всех на бесплатный урок курса DevOps практики и инструменты, где мы разберем, как в docker организована работа с данными и сетями, узнаем о концепциях Storage и Network Drivers. Узнаем о важных тонкостях и ограничениях при работе с ними. Познакомимся с инструментом docker-compose и закрепим полученные знания на практике.