Ansible 2.9 и Collections: переписываем корпоративные роли и понимаем, зачем это было нужно

Ansible 2.9 вышел в октябре 2019-го, и первое что мы почувствовали - не новые фичи, а перемену в том, как вообще устроены модули. Collections - это не просто переименование, это другая модель организации кода. И когда в январе мы сели разбираться как это накладывается на наши роли, стало ясно что несколько вещей придётся переделать.

Хорошая новость: Ansible 2.9 при этом ещё поддерживает «плоское» пространство имён - модуль ios_vlan работает без префикса, как раньше. Плохая новость: это совместимость на переходный период, и строить на ней новые роли уже не стоит. В managed-сопровождении у нас несколько клиентов с большими playbook-репозиториями - там уже начали болеть от конфликтов версий модулей, и Collections оказался ответом на вопрос, который мы пока правильно не формулировали.

Что такое Collections на практике

Если коротко: раньше все модули Ansible жили в одном плоском namespace. ios_vlan, yum, copy, vmware_vm_facts - всё в одной куче, и за версионирование отвечал только сам Ansible. Хочешь новую версию модуля для Cisco - жди нового Ansible. Хочешь откатить один модуль - никак.

Collections меняет это: каждый вендор или проект пакует модули, плагины и роли в свою коллекцию с собственной версией. Установить можно через ansible-galaxy collection install. Пространство имён выглядит как cisco.ios, junipernetworks.junos, community.general. Обращение к модулю соответственно - cisco.ios.ios_vlan вместо просто ios_vlan.

Для новых ролей это чище. Для существующего кода - работа.

Почему network-automation коллекции важны именно нам

В 2018-м мы автоматизировали конфигурацию VLAN на тридцати Cisco-коммутаторах через network-модули. Это был первый нормальный опыт, и мы написали роли для нескольких клиентов на базе тех ios_* и junos_* модулей из Ansible 2.6.

Теперь у нас ситуация: одна роль для Cisco-конфигурации работает на Ansible 2.6, другой клиент обновился до 2.9, и модуль ios_vlan там ведёт себя немного иначе - в 2.9 network-модули переехали в cisco.ios collection и часть параметров переименована. Плейбук формально запускается, но в одном месте выдаёт deprecated warning, в другом - тихо игнорирует параметр которого больше нет под старым именем.

Это и есть та боль, от которой Collections по идее защищает: когда коллекция версионирована отдельно, requirements.yml фиксирует что cisco.ios 1.0.0 стоит везде, и никаких сюрпризов от обновления Ansible.

Как мы переписываем роли

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

Первое - инвентаризация зависимостей. Мы прошли по ролям и выписали какие именно модули используются. Часть модулей из community.general (там сейчас несколько сотен модулей, которые раньше просто жили в ansible/ansible), часть из cisco.ios, часть - builtin. Без этого шага непонятно что вообще устанавливать через ansible-galaxy collection install.

Второе - FQCN в задачах. Fully Qualified Collection Name - это cisco.ios.ios_vlan вместо ios_vlan. Ansible 2.9 понимает оба варианта, но если не прописать FQCN, при установленных нескольких версиях одной коллекции поведение непредсказуемо. Механически замена несложная, но в крупных ролях с template-задачами и include - нужно смотреть руками, grep не всегда ловит всё.

Третье - collections: в роли. В meta/main.yml роли можно прописать collections: список, тогда внутри роли можно снова писать короткие имена модулей без FQCN, и Ansible будет искать их в указанных коллекциях по порядку. Это компромисс для миграции - роль работает с коротким синтаксисом, но зависимость зафиксирована явно.

# meta/main.yml
collections:
  - cisco.ios
  - junipernetworks.junos

Мы выбрали гибридный подход: новые роли - FQCN везде, старые критичные - collections: в meta с минимальными правками. Переписывать всё разом нет смысла, Ansible 2.9 это терпит.

Galaxy NG: что с ним сейчас

Galaxy NG - это следующая версия Ansible Galaxy, которая разрабатывается как корпоративный хаб для Collections с поддержкой private namespace и контроля доступа. Сейчас это upstream-проект в активной разработке, продакшн-версии нет.

Нам это интересно в контексте корпоративного хранилища: сейчас наши приватные роли живут в GitLab, установка через ansible-galaxy install git+https://.... Это работает, но неудобно: нет версионирования на уровне API, нет dependency resolution как у настоящего registry. Galaxy NG обещает именно это - внутренний хаб с теми же возможностями что и публичный galaxy.ansible.com, но за корпоративным firewall. Следим, но пока не трогаем: ждём стабильного релиза.

Что реально даёт namespace-изоляция

Это тот момент, который понимаешь только когда сталкиваешься с реальным конфликтом.

У одного из клиентов большой playbook-репозиторий: инфраструктурные роли, application-деплой, сетевая конфигурация - всё в одном repo, запускается из AWX. Роли писались разными людьми в разное время. Там есть кастомная роль с модулем-плагином который называется user - и одноимённый builtin-модуль Ansible. В плоском namespace-е это конфликт, и поведение зависит от порядка путей в ANSIBLE_LIBRARY. Плейбук работал, потому что порядок случайно оказался правильным.

С Collections такого конфликта нет в принципе: ansible.builtin.user и client_corp.infra.user - разные объекты с разными именами, порядок загрузки не имеет значения. Это не теоретическое преимущество, это реальная история из нашей практики.

Где сейчас

Активные network-роли для Cisco и Juniper переписаны под Collections - заняло примерно две недели с тестированием через Molecule. Molecule пришлось немного адаптировать: в converge.yml нужно явно устанавливать коллекции до прогона роли, иначе в чистом Docker-контейнере модулей нет.

Роли для серверной автоматизации - пока в процессе. Там нет сетевых конфликтов, и давление меньше. Идём постепенно: трогаем роль - переводим на FQCN. Специально ради миграции не трогаем.

Collections - это правильное направление, видно сразу. Но как со многими правильными направлениями в Ansible: первые полгода работы с этим выглядят как «зачем это усложнили», а потом начинаешь понимать от чего именно тебя избавили.