Средний

15 мин

13

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

Наша задача была достаточно прагматичной: понять, можно ли сократить время доставки конфигураций до минут, сохранив при этом контроль изменений, аудит и предсказуемость откатов. Пилот показал: подход работает. Но отсутствие полноценного dry-run и каскадные зависимости внутренних объектов вендора заставили нас попотеть. Под катом — разбор архитектурного подхода, а не инструкция «как перевести всё на GitOps за выходные». 

Почему автоматизация ADC до сих пор остаётся сложной задачей

По своей архитектуре ADC находится на стыке сетевой инфраструктуры и прикладных сервисов, обрабатывая трафик от L3 до L7 OSI, что естественным образом дробит ответственность между командами: 

• Инженеры сопровождения традиционно работают через GUI или CLI, согласовывают изменения через тикет-системы и применяют их в строго определённые окна обслуживания. 

• DevOps-команды используют другой подход: модель «инфраструктура как код», версионирование, CI/CD и минимизацию ручных операций.

На практике это создаёт классический «сломанный телефон»: требования передаются через тикет-системы, изменения применяются вручную, а при каждом инциденте команда тратит время не на устранение проблемы, а на восстановление цепочки событий — что, где и когда изменили.

Технически ручное управление ADC вполне оправдано. Балансировщики — это системы с большим количеством внутренних зависимостей. Например, изменение SSL-профиля может затронуть политики, пулы и виртуальные серверы. Также вендорные API часто не поддерживают полноценную проверку без применения изменений (dry-run) и не гарантируют идемпотентность операций. Дополнительную сложность создают кастомные механизмы вроде iRules, Lua-скриптов и regex-маршрутизации, которые плохо укладываются в универсальные декларативные модели.

На практике проблему часто пытаются решать «автоматизацией по случаю»: bash- и Python-скриптами или отдельными CLI-сценариями. Но на масштабе в сотни сервисов такая лоскутная автоматизация ломается. Сценарии не хранят состояние, не гарантируют идемпотентность, а любое экстренное изменение быстро приводит к конфигурационному дрейфу. В результате откат изменений становится непредсказуемым, аудит усложняется, а поддержка самих сценариев постепенно превращается в отдельную эксплуатационную задачу.

Именно поэтому инфраструктурный слой ADC во многих компаниях до сих пор остаётся заложником ручных процессов. Чтобы преодолеть этот разрыв без потери контроля, нужен не набор разрозненных скриптов, а единая инженерная модель.

Архитектура пилота: IaC + GitOps для ADC

Проблемы автоматизации ADC во многом похожи на задачи, которые уже давно решаются в других инфраструктурных слоях. Поэтому в качестве основы мы выбрали подход IaC + GitOps: декларативное описание сервисов, версионирование, обязательное ревью, CI/CD и сквозной аудит изменений.

Однако архитектуру пришлось адаптировать под специфику балансировщиков. Вендоры не предоставляют нативные GitOps-контроллеры, поэтому от классического pull-подхода мы отказались. Вместо этого реализовали push-модель через отдельный CI/CD-раннер. 

Тем не менее ключевые принципы сохранились: 

• Git-репозиторий является единственным источником истины

• Изменения проходят обязательное ревью

• Конвейер доставки автоматически проверяет конфигурацию

• Все операции фиксируются и могут быть воспроизведены через историю изменений.

Важно оговориться сразу: перед нами не готовый продукт, а архитектурный прототип. Он проектировался с прицелом на production, но требует доработки перед реальным внедрением.

Ниже — схема потока:

Как выглядит цикл доставки

Любое изменение начинается с push в Git-репозиторий. Конфигурации описываются декларативно, а параметры окружений вынесены в отдельные файлы. Прямые изменения через консоль ADC ограничиваются процедурно, чтобы Git действительно оставался единственным источником актуального состояния.

Следом запускается CI-конвейер: линтинг и структурная проверка конфигурации. В пилоте мы сознательно ограничились базовой валидацией. В production-сценарии можно добавить policy-as-code проверки и автоматическую блокировку изменений, нарушающих требования безопасности.

Далее - обязательное кросс-функциональное ревью. Инженеры сопровождения ADC проверяют архитектурную корректность, а DevOps-команда - соответствие параметрам приложения. Без подтверждённого merge изменения не могут попасть в production-контур.

После CI/CD-раннер применяет изменения на балансировщике, выполняя проверку статуса операций, журналирование и базовую обработку ошибок.

Почему для пилота выбрали F5 и Ansible

В качестве платформы мы использовали связку F5 BIG-IP + Ansible. Причины выбора прагматичны: F5 по-прежнему остаётся одним из наиболее распространённых ADC на enterprise-рынке, а для платформы существует готовая коллекция f5networks.f5_modules. Мы осознанно не использовали AS3, несмотря на рекомендации F5 и устаревший статус модулей f5_modules. Причина — в архитектурном приоритете: нам важно было сохранить вендор-независимую структуру и не завязывать подход на конкретный способ описания конфигурации.

Ansible, в свою очередь, хорошо подходит для постепенного внедрения автоматизации в инфраструктурных командах: порог входа относительно невысокий, а сама модель работы остаётся близкой к привычным эксплуатационным процессам.

Структура репозитория

На текущий момент структура репозитория выглядит следующим образом:

├── ansible.cfg

├── inventories

│   └── prod

│       ├── group_vars

│       │   └── all

│       │       ├── main.yml

│       │       └── vault.yml

│       ├── hosts.yml

│       └── vips

│           ├── app1.yml

│           └── app2.yml

├── requirements.txt

├── requirements.yml

├── roles

│   └── f5_ltm

│       ├── files

│       │   ├── certs

│       │   │   ├── app.crt

│       │   │   └── app.key

│       │   └── irules

│       │       └── Common

│       │           ├── app1_trace_irule.tcl

│       │           ├── redirect_http_irule.tcl

│       │           └── xff_insert_irule.tcl

│       └── tasks

│           ├── irules.yml

│           ├── main.yml

│           ├── monitors.yml

│           ├── nodes.yml

│           ├── pools.yml

│           ├── ssl.yml

│           └── vip.yml

└── site.yml

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

В корне находятся базовые служебные файлы:

• ansible.cfg — настройки выполнения Ansible; 

• requirements.yml — список используемых коллекций, включая f5networks.f5_modules; 

• requirements.txt — Python-зависимости; 

• site.yml — основная точка запуска автоматизации. 

Каталог inventories содержит описание окружения. Внутри:

• hosts.yml определяет сами BIG-IP-устройства; 

• group_vars/all/main.yml хранит общие параметры окружения; 

• vault.yml содержит чувствительные данные в зашифрованном виде; 

• каталог vips описывает отдельные виртуальные сервисы. 

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

• виртуальные адреса; 

• backend-ноды; 

• пулы; 

• профили; 

• мониторы; 

• привязанные iRules. 

Основная логика сосредоточена внутри роли roles/f5_ltm. Она разбита на отдельные файлы задач:

• nodes.yml — создание backend-нод; 

• pools.yml — управление пулами и pool members; 

• monitors.yml — создание health-monitor’ов; 

• ssl.yml — загрузка сертификатов и создание SSL-профилей; 

• vip.yml — создание virtual server; 

• irules.yml — загрузка и привязка iRules; 

• main.yml — управляющая точка входа, определяющая порядок выполнения задач. 

Отдельно выделен каталог files. Внутри него хранятся необходимые файлы:

• сертификаты; 

• ключи; 

• iRules. 

Такой подход оказался заметно удобнее вставок кода внутри YAML-конфигураций: iRules можно нормально версионировать, просматривать через ревью, тестировать и изменять независимо от основной конфигурации балансировщика. iRule загружаются на устройство как отдельные объекты BIG-IP, после чего уже привязываются к виртуальным сервисам через задачи внутри irules.yml.

Для пилота такая структура оказалась достаточно удобной: она упрощает сопровождение, позволяет изолировать изменения отдельных сервисов и нормально масштабируется по мере роста количества приложений.

Что удалось проверить в пилоте

Под нашу задачу мы собрали отдельный лабораторный стенд, архитектура которого приближена к типовым проектам заказчиков в уменьшенном масштабе: несколько backend-нод, виртуальные серверы, health-мониторы и кастомные iRules. И в таком контуре мы успешно отработали базовый цикл доставки конфигураций: коммит, автоматическую валидацию, ревью и применение изменений. Типовые сценарии — VIP, пулы, профили, мониторы и простые политики — успешно отрабатывались через конвейер доставки без ручного вмешательства.

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

name: app1_https_vip
partition: Common
destination: 172.16.14.130
port: 443
snat: Automap
pool:
  name: app1_pool
  lb_method: round-robin
  members:
    - name: web-1
      address: 172.16.14.3
      port: 80
    - name: web-2
      address: 172.16.14.4
      port: 80
    - name: web-3
      address: 172.16.14.5
      port: 80
  monitor:
    name: app1_http_monitor
    type: http
    send: "GET / HTTP/1.1\\r\\nHost: app1.local\\r\\nConnection: Close\\r\\n\\r\\n"
    receive: "HTTP\\/1\\.(0|1) (200|301|302)"


ssl:
  cert: app.crt
  key: app.key
  profile_name: app1_clientssl


irules:
  - redirect_http_irule
  - xff_insert_irule
  - app1_trace_irule

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

Health-монитор создаётся первым. В секции monitor описывается HTTP-проверка: BIG-IP отправляет запрос GET / HTTP/1.1 с заголовком Host: app1.local и ожидает ответ с кодом 200, 301 или 302.

Backend-пул описывается в секции pool. Три сервера (web-1, web-2, web-3) с адресами 172.16.14.3-5 на порту 80 объединяются в группу app1_pool с алгоритмом балансировки round-robin.

SSL-терминация настраивается через секцию ssl. Сертификат app.crt и ключ app.key загружаются из каталога files/certs репозитория, на их основе создаётся SSL-профиль app1_clientssl, который затем привязывается к виртуальному серверу.

iRules подключаются через секцию irules. Три TCL-скрипта (redirect_http_irule, xff_insert_irule, app1_trace_irule) загружаются из каталога files/irules/Common/ как отдельные объекты BIG-IP.

Виртуальный сервер создаётся последним. Он объединяет все предыдущие компоненты: VIP-адрес 172.16.14.130:443, пул app1_pool, SSL-профиль app1_clientssl и iRules.

Даже в лабораторных условиях удалось получить вполне ощутимый практический эффект. История изменений превратилась в полностью трассируемую цепочку действий, а откат конфигурации стал выполняться через возврат к предыдущему коммиту. Ручные операции сократились только до ревью. Мы также предполагаем, что в реальной среде доставка изменений может сократиться с нескольких часов согласований до нескольких минут работы конвейера.

С какими проблемами столкнулись

Несмотря на успешный пилот, ряд сложностей проявился уже на ранних этапах. В первую очередь — особенности работы F5 BIG-IP API и соответствующих Ansible-модулей. Многие ограничения проявились только во время реальных прогонов конфигурации и стали заметны лишь при попытке построить воспроизводимый процесс доставки изменений. 

1. Проверка без применения изменений (dry-run) оказалась бесполезной

Одним из первых сюрпризов стала некорректная работа режима --check. На первый взгляд проверка без применения изменений выглядит обязательной частью безопасного CI/CD-процесса: она должна показать будущие изменения без их фактического применения. Однако в случае с F5 BIG-IP такой подход оказался практически бесполезным.

Большинство модулей из коллекции f5networks.f5_modules не поддерживают полноценную работу в check_mode. Во время выполнения конвейера возникала следующая ситуация:

TASK [Create pools] -> changed
TASK [Manage pool members] -> Pool not found

С точки зрения Ansible пул уже существовал, поскольку предыдущая задача в режиме проверки сообщила об успешном изменении состояния (changed=true). Однако объект фактически не был создан на устройстве BIG-IP.

Поведение конвейера становилось непредсказуемым: dry-run падал с ошибкой, тогда как реальное применение конфигурации работало корректно. В итоге мы полностью отказались от --check и построили безопасность на ревью.

2. Node objects и «почти» идемпотентность

На первый взгляд задача выглядела достаточно простой: backend-серверы описываются внутри конфигурации виртуального сервиса, после чего playbook автоматически создает необходимые nodes на устройстве. Однако внутренняя модель данных BIG-IP оказалась значительно сложнее и довольно быстро проявила ограничения такого подхода. 

Node представляет собой не часть пула, а самостоятельный глобальный объект уровня устройства. В рамках пилота мы работали с одним partition Common, поэтому идентичность node определялась исключительно IP-адресом:

Node = IP address

(В multi-partition окружениях уникальность определяется парой partition + IP.)

При этом pool member — уже производный объект:

Pool Member = Node + Port

Например, следующие конфигурации:

pool:
  members:
    - name: web-1
      address: 10.1.1.1
      port: 80

и:

pool:
  members:
    - name: web-1
      address: 10.1.1.1
      port: 443

используют один и тот же node-объект BIG-IP.

Именно эта особенность и стала источником проблем с идемпотентностью.

Конфигурации виртуальных сервисов описывались независимо друг от друга, поэтому одинаковые backend-серверы регулярно встречались сразу в нескольких сервисах. В результате playbook несколько раз пытался создать один и тот же node и получал ошибку:

0107176c:3: Invalid Node, the IP address already exists.

Формально playbook переставал быть идемпотентным: повторный запуск не приводил инфраструктуру к целевому состоянию, а завершался ошибкой из-за повторного создания уже существующего объекта.

Вместо ручного описания nodes было принято решение формировать глобальный список node-объектов — на основании всех pool members из конфигураций виртуальных сервисов.

Для этого использовался агрегирующий блок:

- name: Build node inventory from VIP definitions
  ansible.builtin.set_fact:
    f5_nodes: >-
      {{
        f5_vips
        | map(attribute='pool.members', default=[])
        | flatten
        | selectattr('address', 'defined')
        | unique(attribute='address')
        | list
      }}

Ключевой этап — устранение дублирующихся node-объектов: unique(attribute='address')

Фактически этот блок превращал разрозненные описания backend-серверов в единый глобальный inventory. 

3. Порядок применения конфигурации

Ещё одна проблема проявилась уже при попытке превратить набор отдельных Ansible-задач в воспроизводимый процесс доставки изменений. Теоретически конфигурация ADC выглядит декларативной: описываются виртуальные сервисы, SSL-профили, пулы и политики, после чего система должна привести устройство к нужному состоянию. На практике же BIG-IP представляет собой набор тесно связанных объектов с большим количеством внутренних зависимостей.

Практически любой объект зависит от существования других:

• virtual server ссылается на pool; 

• pool использует monitors; 

• virtual server подключает профили; 

• iRules могут обращаться к data-groups или другим объектам BIG-IP. 

Из-за этого последовательность применения конфигурации становится критически важной. Например, virtual server не может быть создан раньше:

• необходимых профилей; 

• pool; 

• iRule. 

В противном случае BIG-IP возвращает ошибку привязки зависимостей:

01020036:3: The requested pool was not found.

или:

0107149c:3: Virtual server references invalid SSL profile.

Проблема осложнялась тем, что Ansible не строит зависимости между объектами BIG-IP. С точки зрения playbook задачи выглядят независимыми, однако внутри BIG-IP порядок выполнения напрямую влияет на корректность итогового состояния устройства.

В результате от «плоской» модели playbook пришлось отказаться. Логику применения зависимостей реализовали непосредственно внутри main.yml, который начал выполнять функцию координатора применения конфигурации. Все задачи были разбиты на отдельные стадии с жёстко заданным порядком выполнения:

- import_tasks: nodes.yml
- import_tasks: monitors.yml
- import_tasks: pools.yml
- import_tasks: ssl.yml
- import_tasks: irules.yml
- import_tasks: vip.yml

Такой порядок появился не случайно. Сначала создаются базовые объекты инфраструктуры:

• backend-ноды; 

• health monitors; 

• pools. 

После этого загружаются зависимые сущности:

• SSL-сертификаты; 

• SSL-профили; 

• iRules. 

И только после этого создаются virtual servers, которые уже ссылаются на все ранее подготовленные объекты. Вместо попытки «залить всю конфигурацию сразу» начали пошагово собирать итоговое состояние устройства, последовательно устраняя зависимости между объектами.

4. Конфигурационный дрейф

Теоретически подход предполагает, что Git остаётся единственным источником истины, а фактическое состояние инфраструктуры всегда соответствует описанию в репозитории. Однако в случае с ADC такая модель довольно быстро сталкивается с реальностью эксплуатации.

Балансировщики — это инфраструктура, в которой возможны частые экстренные изменения. Во время инцидентов инженеры работают напрямую в GUI или CLI. Для бизнеса это оправдано: восстановление сервиса важнее «чистоты GitOps». 

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

Это порождало три взаимосвязанные проблемы:

• Потеря воспроизводимости. Повторный запуск playbook переставал давать предсказуемый результат.

• Усложнение аудита. После нескольких ручных правок становилось невозможно определить, какое состояние актуально — в Git или на устройстве.

• Риск отката рабочих изменений. Запуск playbook автоматически перезатирал аварийные правки, внесённые через GUI.

В результате стало очевидно: контроль конфигурационного дрейфа — обязательная часть архитектуры. 

При этом сам механизм drift detection в рамках пилота мы пока полноценно не реализовали. Основной задачей было проверить саму применимость GitOps-подхода к ADC и выявить архитектурные ограничения автоматизации BIG-IP.

Наиболее реалистичным выглядит следующий механизм контроля:

• Периодический сбор текущего состояния BIG-IP через API; 

• Сравнение фактического состояния с описанием сервисов в Git; 

• Формирование diff для анализа и отправки уведомлений инженерам. 

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

Важно понимать: все озвученные ограничения — не аргумент против GitOps для ADC, а следствие специфики самих балансировщиков и их внутренней модели объектов. При этом сами проблемы оказались вполне решаемыми. Как только подобные особенности становятся частью архитектуры, автоматизация перестаёт быть источником нестабильности и начинает выполнять свою основную задачу — снижать объём ручных операций, уменьшать количество ошибок и делать изменения инфраструктуры воспроизводимыми.

Что осталось за рамками пилота

Сложную прикладную логику с каскадными зависимостями пока разумнее оставить в ручном режиме как legacy конфигурации и постепенно упрощать их логику. Глобальную балансировку (GSLB) и синхронизацию между дата-центрами мы также вынесли в отдельную задачу: они завязаны на DNS и репликацию состояния, что превращает задачу из «применения конфигурации» в полноценное управление распределённым состоянием.

Параллельно прорабатываем интеграции с внешними системами — например, с NetBox для автоматического резервирования IP-адресов и OpenBao для хранения и ротации сертификатов. Следующим этапом планируем расширение интеграции с системами мониторинга и SIEM, чтобы централизовать аудит изменений и контроль состояния инфраструктуры. 

Дорожная карта внедрения

Внедрение GitOps для балансировщиков — это не просто миграция конфигураций в репозиторий. По сути, речь о перестройке процессов эксплуатации, которая затрагивает безопасность, требования соответствия, культуру команд и архитектурные решения.

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

Первый этап всегда начинается с аудита и фиксации текущего состояния. Команда инвентаризирует устройства, экспортирует конфигурации, выстраивает карту зависимостей между объектами и определяет, какие конфигурации вообще готовы к автоматизации.

После этого разворачивается изолированный пилотный контур: репозиторий, Ansible-роли, CI/CD-конвейер, механизмы проверки, хранилище секретов и защищённый раннер. На этом этапе команда получает полностью автоматизированный цикл доставки конфигураций, но ручные изменения пока ещё разрешены и логируются для последующего анализа. Команды начинают отрабатывать сценарии отката изменений и фиксировать первые случаи конфигурационного дрейфа.

После отладки конвейера происходит полноценный переход в production-режим: Git становится единственным каналом плановых изменений. Ручное вмешательство допускается только для аварийных операций с обязательным последующим возвратом изменений в репозиторий.

Заключение

Главный результат пилота — не в том, что подход «заработал» с балансировщиками: это было ожидаемо. Важнее другое: инфраструктура ADC требует значительно более тщательной адаптации IaC-подходов, чем большинство современных инфраструктурных платформ. Зависимости между объектами, ограничения API и сложная прикладная логика быстро превращают «простую автоматизацию» в полноценную инженерную задачу. Однако эти ограничения не мешают построить управляемый и воспроизводимый процесс доставки изменений. 

Переход к GitOps для балансировщиков — это не разовая миграция, а постепенная перестройка процессов эксплуатации. Самое сложное здесь — не технологии. Это организационные изменения: новые процедуры ревью, перераспределение ответственности и адаптация сетевых команд к модели «конфигурация как код». Без административного закрепления новых процессов - технология останется просто инструментом, который команды будут обходить в стрессовых ситуациях.

Именно поэтому результат пилота - не только техническая проверка гипотезы, но и подтверждение того, что инфраструктуру ADC можно интегрировать в CI/CD. Когда балансировщики управляются через Git - они перестают быть “черным ящиком” и источником рисков: изменения трассируются, а откаты занимают минуты. В итоге инфраструктура получает предсказуемость и скорость доставки, а бизнес - снижение операционных расходов и издержек.