Foreman — это платформа для автоматизации повторяющихся задач, развертывания приложений и управления жизненным циклом серверов как в локальной инфраструктуре, так и в облаке. Ранее мы уже рассказывали о различных подходах к автоматизации установки ОС на серверы, а также делились опытом работы с PXE-деплоем ESXI через Foreman и развертыванием Windows UEFI.

Теперь же поговорим о более комплексном подходе к организации инфраструктуры установки операционных систем, к которому мы пришли с учетом накопленного опыта. Подобную схему установки операционных систем на bare metal серверы используют многие крупные компании, включая представителей отечественного IT-рынка. В данной статье мы сосредоточим внимание на архитектуре и общих принципах организации инфраструктуры и расскажем о тех проблемах, с которыми столкнулись на практике.
Серверы на базе процессоров AMD EPYC и Ryzen последних поколений |
В нашем случае Foreman выступает в роли PXE-сервера для массовой установки операционных систем на bare-metal серверы и виртуальные машины (когда нет готового шаблона или его создание нецелесообразно). Для тех, кто интересуется техническими деталями работы с загрузочными образами, рекомендуем ознакомиться с нашим материалом о Linux LiveCD на базе CentOS и техниках PXE-загрузки через Foreman.
Система предоставляет удобный API для интеграции с другими инструментами. Стоит отметить, что решение может быть менее интересно для администраторов, предпочитающих классические подходы или активно использующих Puppet.
Архитектура до модернизации
Ранее у нас функционировало 2,5 локации, каждая из которых имела собственный экземпляр Foreman с публичным IP-адресом. «2,5 локации» означает, что было развернуто 2 полноценных площадки в России и Нидерландах, а также локация в США, где отсутствовала серая сеть и был развернут Foreman с особой структурой. В настоящее время у нас функционирует 13 унифицированных локаций (Россия, Нидерланды, США, Турция, Франция, Великобритания, Испания, Италия, Исландия, Польша, Германия, Швейцария, Финляндия). Как мы уже описывали в статье о мониторинге geo-распределенной инфраструктуры, управление несколькими локациями требует особого подхода. С точки зрения управления все локации работали полностью автономно.
На каждом Foreman были развернуты наборы конфигураций:
Production — рабочие конфигурации для продуктивной среды;
Development — тестовые конфигурации для отладки и экспериментов.
Администратор при внесении изменений брал малоиспользуемый development-сервер в US-локации, там тестировал, затем заливал изменения в production соответствующей локации. Использование белого IP несло риски безопасности: доступ сюда мог получить и клиент. Защитой был только файрвол и авторизация на Foreman.
Поскольку DHCP-сервер располагался непосредственно на Foreman, а инфраструктура включала множество VLAN, требовалось:
Постоянное поддержание актуального списка активных сетей на Foreman;
Конфигурирование и мониторинг DHCP-сервера;
Обеспечение наличия DHCP helper-адресов для корректной маршрутизации запросов между сегментами сети.
Миграция на изолированную сетевую архитектуру
В рамках повышения безопасности инфраструктуры мы кардинально изменили сетевую архитектуру Foreman. Все экземпляры Foreman во всех локациях больше не используют публичные IP-адреса и размещены в выделенном VLAN 75 (в каждой локации свой 75 VLAN). Помимо существующих локальных файрволов на каждом Foreman, вся инфраструктура дополнительно защищена общим файрволом Cisco ASA. Такая архитектура обеспечивает полную изоляцию сетей — доступ извне категорически исключен.
Для тестирования изменений мы развернули отдельный Foreman develop в изолированном VLAN 75 с приватными IP-адресами. Этот экземпляр предназначен исключительно для взаимодействия с development-хостами Invapi, защищен файрволом ASA и не имеет никакой связи с продуктивными экземплярами Foreman. Продуктивные экземпляры Invapi взаимодействуют с соответствующими Foreman согласно архитектурной схеме:

Механизм установки теперь работает следующим образом: в момент создания конфигурации на Foreman сервер автоматически переключается в приватный VLAN, где и происходит весь процесс установки. После завершения установки операционной системы скрипт из самой ОС отправляет запрос в Invapi с просьбой переключить сервер в публичный VLAN. Предварительно скрипт модифицирует сетевые настройки на публичные параметры — это может быть как DHCP, так и статическая конфигурация, что регулируется непосредственно на Foreman в зависимости от требований клиента:

По завершении установки конфигурация автоматически удаляется, а IP-адрес возвращается в пул доступных адресов. Дополнительно функционирует автоматизированная система очистки конфигураций, а адреса из VLAN 75 выдаются посредством DHCP:



Все необходимые для установки параметры — публичные сети, эндпоинты, теги — добавляются в конфигурацию дополнительными функциями и становятся доступными в процессе установки:

func SetparametrForHost(UserName, Pass, Url, HOSTNAME, Domain, name string, value string) foreman.ParameterForHostanswer {
url := Url + "/" + HOSTNAME + Domain + "/parameters"
obj := foreman.ParameterForHost{}
obj.Parameter.Name = name
obj.Parameter.Value = value
ret := foreman.ParameterForHostanswer{}
request1 := tool.NewRequestJson(url)
request1.Header.AuthorizationBasic(UserName, Pass)
request1.POST(&obj, &ret)
return ret
}
Вся конфигурация теперь хранится в GitLab в отдельных ветках prod и develop. Рабочий процесс администратора значительно упростился: после работы с шаблоном выполняется push в GitLab, что сохраняет изменения в репозитории. GitLab автоматически активирует webhook, который через API обращается к development-экземпляру Foreman и обновляет все шаблоны, включая модифицированный администратором.
После тестирования в development-среде администратор вносит финальные изменения, которые автоматически распространяются по всем продуктивным локациям.


Наша реализация включает два основных компонента: Foreman Server выступает центральным элементом и включает веб-интерфейс, API и веб-сервер на базе Apache HTTPD, а Smart Proxy обеспечивает интеграцию с сервисами DHCP, DNS и TFTP. DHCP-сервер представлен стандартным dhcpd, управление которым осуществляется через Smart Proxy.
Развертывание плагина происходит одновременно с установкой Foreman. Для автоматизации развертывания используется Ansible, при этом базу данных мы получаем с другого хоста и модифицируем под текущие требования:

Реализованные улучшения и нерешенные задачи
Миграция принесла несколько критически важных изменений: централизованное хранение всех конфигураций в GitLab, автоматизированное развертывание Foreman, размещение всех экземпляров Foreman в приватных сетях и выделение отдельного Foreman для разработки.
Основной проблемой остается архитектура «одна локация — один Foreman». В перспективе планируется решить этот вопрос через внедрение архитектуры с прокси-Foreman, где один центральный Foreman в локации будет обслуживать остальные, получающие данные от него. Это решение устранит текущую проблему отсутствия автоматизации при добавлении новых операционных систем — сейчас администратору приходится обходить все экземпляры Foreman для регистрации новой ОС, например, при выходе Rocky Linux или AlmaLinux новых версий.
Заключение
Миграция на изолированную сетевую архитектуру Foreman стала важным шагом в развитии нашей инфраструктуры автоматизации. Переход от публичных IP-адресов к полностью приватным сетям с многоуровневой защитой значительно повысил безопасность системы, исключив возможность несанкционированного доступа извне.
Внедрение централизованного управления конфигурациями через GitLab с автоматическим развертыванием изменений существенно упростило работу администраторов и снизило вероятность ошибок при обновлении шаблонов. Разделение сред разработки и продукции обеспечило безопасное тестирование изменений без риска влияния на рабочие системы.
Несмотря на достигнутые успехи, перед нами стоят задачи дальнейшего совершенствования архитектуры. Планируемый переход к централизованной модели с прокси-Foreman позволит унифицировать управление операционными системами и полностью автоматизировать процессы обновления. Это станет следующим этапом эволюции нашей платформы автоматизации развертывания.
Серверы на базе процессоров AMD EPYC и Ryzen последних поколений |
taxonein
Очень интересно, а что если имеется 5 и более операционных систем? Можно ли в таком случае как-то ужать текущие оси чтобы грузить через сеть меньше? Если да то было бы интересно увидеть, т.к не очень хочется грузить пару гигов через сеть, особенно если нужно устанавливать на 20 машин одновременно) Одно дело винду установить раз в год, но если обновлять целый парк- то это проблема.
tkrylova2200
все hkm установки ставятся через один образ , сначала вгружается livecd , дальше раскатывается минимальный образ ос , сеть внутреняя минимум на гибабите , дальнейшее обновление идет через внешние зеркала , система выдерживает проверено 200 установок)