Почти любую инфраструктуру рано или поздно приходится расширять. Если вы — сисадмин в компании с собственными серверами, возможно, для вас этот вопрос стоит не так остро. Но когда работаешь с публичными облаками, вопрос расширения встаёт регулярно. Особенно, если существует несколько регионов.
Установить один сервер раз в месяц — не особенная проблема. Но что делать, если приходится добавлять по 100 серверов в месяц в разные локации? Мы в EdgeCloud для себя ответили на этот вопрос созданием пайплайнов для деплоя серверов. Благодаря этому гениальному решению, как правило, нам даже не приходится заходить на серверы — всё сделает автоматизация.
В этой статье расскажу, как мы автоматизировали добавление физических серверов в кластеры Openstack. Сразу скажу, что в самом Openstack достаточно много инструментов для автоматизации. Тот же openstack-ansible или kolla-ansible для установки и настройки серверов, Terraform или ansible для «наполнения» кластера. Но вот для установки операционной системы, к сожалению, таких удобных инструментов нет (что-то есть, но далеко не всё удобное). И поэтому об этом мы поговорим подробнее.
Первичная настройка серверов
Настраиваем правильные адреса серверов
Давайте разберём конкретную ситуацию. DCIM отдали нам сервер с паролем от IPMI после установки в стойку и коммутации. Но сеть в RMI никто не настраивал. И возникла проблема — RMI сервера получила случайный адрес через DHCP. На этот случай у нас есть специальный скрипт, который работает так:
Брутфорсит сеть (которую можно указать при запуске пайплайна).
Если есть совпадения, заходит в IPMI и берет оттуда MAC-адрес и серийник.
Сравнивает серийник в Netbox с серийником из сервера.
Если есть совпадение, MAC-адрес добавляется в Netbox в RMI-интерфейс сервера (Netbox, кстати, у нас является источником истины, но об этом чуть позже).
Как только MAC добавлен, DHCP-серверы увидят разницу и закрепят адрес сервера за этим MAC. В течении получаса сервер станет доступен.
А вот и чуть позже – про Netbox! Это удобная CMDB, которая имеет API, Python клиента и к тому же бесплатная! Но мы собрались тут не о достоинствах Netbox говорить.
В Netbox мы храним всю информацию о серверах, и интегрировали с ним много наших сервисов, например, DNS и DHCP. Про DHCP я писал выше. DNS интегрирован таким же образом – смотрит на интерфейсы серверов, и если они появляются, добавляет записи в DNS с именем сервера в зависимости от типа интерфейса. Для RMI-интерфейсов появляется такая запись: server-role-rmi. Так же с Netbox интегрирован и наш пайплайн – он тоже берет всю необходимую информацию оттуда: начиная от производителя сервера, заканчивая типом RAID-массива.
Итак, после не сложных манипуляций у нас есть пачка серверов с правильными адресами и с известными паролями. Дело осталось за малым – настроить их и установить ОС.
Настраиваем серверы
Настройка сервера у нас разделена на несколько этапов: bios, users, update.
На каждом из этих этапов с помощью Ansible, python, bash и такой-то матери выполняется настройка сервера для облака. Пайплайн так же посматривает в Netbox и проверяет, нужно ли ему запускать определенный стейдж, или его необходимо пропустить. Полезно, если сервер передеплоивается, либо если это повторный запуск. Статус сервера обновляет сам пайплайн.
Провиженинг серверов и установка ОС с помощью Ironic
Все публичные облака у нас построены на базе Openstack, а предоставление клиентских bare metal серверов происходит через Ironic. Поэтому было логично выбрать Ironic и для провиженинга своих же серверов.
У нас есть специальный, технический регион — по сути, это просто ВМ, на котором установлен очень урезанный Openstack. На нём нам необходимы следующие компоненты: Ironic, Horizon и Glance. В Glance хранятся модифицированные образы ОС, которые мы используем в продакшене.
Для людей, знакомых с Ironic, по названиям стейджей будет примерно понятно, что за что отвечает. Но я распишу:
1. В inspect происходит добавление сервера в Ironic, если его до этого там не было. Создается конфигурация для доступа к IPMI, IDRAC, ILO на основе данных в Netbox. Дальше эта конфигурация записывается в конфиг сервера и запускается сам inspect. Во время работы inspect Ironic собирает информацию о дисках, памяти, процессоре и прочих вещах. Но главное — здесь можно получить информацию об интерфейсах с помощью lldp. На следующем шаге нам это пригодится.
2. В validate происходит проверка, что интерфейсы подключены к правильным портам в правильных свичах. DCIM тоже люди и могут ошибаться.
3. Shred создает или пересоздает RAID на сервере, если сервер до этого использовался.
4. Setup устанавливает ОС.
5. Done дожидается загрузки сервера, пингует его и, если все хорошо, удаляет из Ironic.
Далее на сцену выходит Kolla Ansible, которая привозит и настраивает Openstack на новых серверах.
Подведём итог
Благодаря этому большому, но на самом деле несложному пайплайну для нас нет особой разницы, сколько серверов задеплоить — 1 или 100. Это занимает примерно одинаковое время.
Автоматизируйте ребята, даже автоматизацию автоматизируйте! Оно вам пригодится в автоматизации.