Когда в компании парк из тысячи серверов, хочется наладить процесс для удобной работы с ними. Один из вариантов — автоматизировать установку и настройку операционных систем. 

Я Иван Протченко, инженер из команды Cloud.ru, и сегодня я расскажу, как немного нестандартное использование Foreman помогло нам оптимизировать процесс установки и настройки операционных систем на серверное оборудование в облачной инфраструктуре. Даже отсыплю немного кода для тех, кто тоже хочет накатить ось на сотню-другую серверов и не сойти с ума. Очень пригодится всем, кто имеет дело с территориально распределенной инфраструктурой или масштабируется за счет аренды bare metal серверов.

В 2019-2020 годах перед нашей командой стояла задача запустить вендорское решение. Планировалось, что инфраструктура будет включать два географически разнесенных ЦОДа, а это более 500 серверов. Стало очевидно — без автоматизированной установки операционных систем на физические серверы нам не обойтись. 

Про решение для первого вендора долго думать не пришлось — договорились использовать стандартный компонент Ironic. В случае со вторым готового инструмента не было, зато была абсолютная свобода выбора. Мы понимали: в какой-то момент нужно будет погрузиться в тему и найти решение самим. 

Начинаем работу 

Чтобы не нагружать OOB-фабрику, мы сразу метили в установку по PXE. В итоге создали два PXE-сервера — по одному для каждой площадки.

Сложность заключалась в том, что для каждого сервера, куда мы планировали вкатить ОС, нужно было описывать отдельную конфигурацию, ведь у серверов с одинаковой версией операционной системы были разные IP-адреса, могла быть разная конфигурация сетевых устройств и дисков. В этом и заключалась основная сложность.

Поскольку первоначально все файлы конфигураций инженеры Cloud.ru создавали вручную, на донастройку пачки серверов уходило по меньшей мере полтора часа.

Можно себе представить, что пришедший на работу «бодрый инженер», под конец дня, после десятков однотипных итераций превращался в довольно «уставшего» и грустного инженера.

Как обычно и бывает, скучная и однотипная работа приводит к пониманию того, что можно накрутить автоматизации.  

Что мы пробовали сначала

В качестве первого подхода к снаряду мы пробовали подготовить деплой ОС с использованием обычного PXE-сервера. Это довольно простой и понятный способ. 

Итак, что нужно, чтобы установить ОС по сети?

1. DHCP-сервер;

2. PXE-сервер;

3. веб-сервер;

4. виртуальная машина, работающая в режиме legacy.

По этой ссылке можно с помощью ansible развернуть готовый к использованию стенд и изучить его работу. Параметры окружения такие:

1. Сеть 192.168.1.0/24

2. DHCP pool 192.168.1.155 - 192.168.1.254

3. DHCP, TFTP, web - 192.168.1.11

Так как нет железа, то включим ВМ в этой сети, зайдем в boot mode и выберем загрузку по сети. ОС ставится исходя из default-конфигурации:

Кастомизация:

Если вы заранее знаете MAC-адрес, то можете подготовить файлы, чтобы персонализировать для конкретного сервера cloud init. Имя директории с файлами может быть одним из представленных:

И, соответственно, после нужно подготовить файлы на веб-сервере, например так:

После этих ручных манипуляций сервер с указанным MAC-адресом будет разлит с тем cloud-init, который сделан только под него.

Очевидные плюсы такого подхода, которые мы заметили, — простота конфигурации и минимум используемых компонентов, как следствие низкий порог входа. 

Из минусов — все эти серверы будут после установки ОС на DHCP; придется вручную создавать файлы, если нужна специальная конфигурация под конкретный сервер, например, установка статического IP. 

Поэтому мы начали смотреть в сторону шаблонизаторов для PXE, которые умеют управлять по API, чтобы сделать свои интеграции. По итогу ресерча поняли, что лучше всего нашим требованиям удовлетворяет open source проект Foreman, его мы и взяли как основной компонент решения

Продумываем альтернативное решение

Чтобы еще больше облегчить задачу нашим «бодрым инженерам» и избавить их от необходимости вручную готовить конфигурации для 500+ серверов, нам нужны были инструменты для шаблонизации настроек и их распределения по серверам. И вот какой конструктор нам для этой задачи удалось собрать. 

Основные компоненты

Netbox 

Отличная IPAM-система, в нашем случае — master-система или источник правды. В ней описаны сети, интерфейсы и конфигурации сетевого и серверного оборудования, а также многое другое.

Важно отметить, что на тот момент мы также активно описывали и внедряли модель данных для IPAM-системы. Например, у сервера обязательно должны быть заполнены следующие атрибуты: hostname, OS version и Management IP. Также у самой сущности «сервер» имеются «подсущности» — физические и виртуальные интерфейсы. 

И вот когда стандарт данных Netbox был разработан, в систему было занесено всё наше оборудование с таким описанием, что мы пришли к общему решению — можно начинать использовать Foreman.

Foreman 

Сама система состоит из двух частей:

• Foreman Server, где реализуется Web UI и API-интерфейсы. Сам может быть и DHCP, и PXE-сервером.

• Foreman proxies — это подсистемы решения Foreman, которыми управляет центральный сервер. Необходимы для реализации подхода, подобного «edge-computing» , то есть, чтобы не «гонять трафик» между дата-центрами, размещаем foreman-proxy серверы максимально близко к тем серверам, на которые устанавливаем операционную систему.

Данные Netbox, о которых я писал ранее, а именно: hostname, OS version и Management IP используются для формирования конфигураций серверов с использованием переменных.

С Foreman у нас также появилась возможность динамического описания конфигурации в виде шаблонов для post-настройки (сетевые интерфейсы ОС, разметка диска и тд.) и мы даже добавили несколько новых образов ОС.

О том, как именно происходит подготовка Foreman к «проливке» оборудования я расскажу ниже.

Второстепенные компоненты решения

FTP-сервер

FTP-сервер — это сервер, работающий по протоколу Secure File Transfer Protocol и предназначенный для хранения установочных образов операционных систем.

Sonatype Nexus

Платформа, которая проксирует, хранит и управляет образами Docker, RPM-пакетами и другими компонентами операционных систем, которые используются в пост-настройке.

GitLab

В настоящее время уже классический инструмент организации CI/CD-пайплайнов. Его мы и используем для построения зависимостей между Netbox, Foreman и Nexus.

Как работаем теперь 

Получается, мы внедрили целый процесс для Foreman:

1. В Netbox «Бодрый инженер 1» заполняет карточку оборудования (коммутатор, сервер, кабельный журнал) согласно выработанной модели данных.

2. В Netbox «Бодрый инженер 2» распределяет адреса из выделенного префикса по IPMI-интерфейсам серверов.

3. В дата-центре «Бодрый инженер 3» устанавливает оборудование, коммутирует его и настраивает IPMI-интерфейсы.

4. «Бодрый инженер 4» заранее подготовил установочный образ ОС, настроил конфигурацию в Foreman, нацелил его на серверы, используя Netbox, и запустил установку.

Техническая реализация

Устанавливаем рабочую конфигурацию foreman + foreman-proxy, запускаем из репозитория плейбук для установки foreman и 3 команды, чтобы наполнить его сущностями:

source env/bin/activate

ansbile-playbook -i inventory foreman.yml

python3 sr/run.py

Окружение такое же, как и для DHCP, только добавлю, что пакеты foreman есть под Ubuntu 20. Под Ubuntu 22 пакетов нет, поэтому всё буду ставить на Ubuntu 20.04.6.

После этого можно открыть веб-интерфейс, авторизоваться admin:admin и посмотреть, какие сущности есть и какие связи между ними.

Первое, что проверим, подключилась ли смарт прокси:

Далее смотрим, создались ли нужные шаблоны подготовки:

Проверяем их связи с операционной системой (должна создаться автоматически):

Проверяем, что создались подсети:

Проверяем, что создался установочный носитель для прокси:

Проверяем, что узел создался:

Тут можно изучить параметры и посмотреть, как шаблоны применятся для этого хоста, нажав на их имя.

Посмотреть, есть ли активные сборки, можно вот так:

На этом автоустановка должна отработать, нужно только перезагрузить целевое устройство и убедиться, что сетевые интерфейсы находятся в legacy-режиме. По завершении установки на хосте будет установлен статический ip 192.168.1.42, а также этот хост пропадет из списка build.

Если иметь инвентарные данные о хостах, то можно с помощью ipmitool или redfish в связке с Foreman управлять автодеплоем операционных систем через PXE.

Выводы

После внедрения Foreman мы:

• Ускорили процесс установки операционных систем на серверы примерно в три раза, вот статистика:

• Получили полностью самостоятельный продукт с возможностью доработки: решение можно перестраивать в зависимости от задачи, к тому же оно независимо от платформ виртуализации, возможностей серверного оборудования и ПО.

• Реализовали возможность динамического описания конфигурации сервера в виде шаблона, который используется для пост-настройки. Настроили шаблон однажды — и конфигурация для десятков и сотен серверов будет уже подтягиваться автоматически.

Уверен, опытные администраторы заметили избыточную сложность в процессе подготовки инфраструктуры до того, как Foreman дотягивается до нее. Когда мы с этим столкнулись, поняли, что еще есть что улучшать и начали активно работать над Zero-Touch Provisioning, чтобы ускорить процесс предоставления подготовленных серверов и убрать человеческий фактор при настройке систем, но об этом уже как-нибудь в следующих сериях.

Интересное в блоге:

• Запускаем кластер OpenSearch для централизованного хранения логов

• Как внедрить двухфакторную аутентификацию в веб-приложения, не предусматривающие ее изначально

• Бороздим облака будущего: впечатления айтишника о конференции GoCloud