сегодня поговорим про тестирование ansible ролей

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

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

Всё началось в момент увеличивающихся вычислительных мощностей. Тогда в голову инженерам пришла мысль: а давайте все автоматизируем! Сказано - сделано. Были написаны скрипты на баше и перле. Но время шло, количество компьютеров увеличивалось, а вместе с ним уменьшался уровень образованности и интереса людей к их работе. В итоге начали появляться системы управления конфигурациями.

И вот вылупились salt, puppet и ansible. С тех пор жизнь системных администраторов кардинально изменилась и уже никогда не вернется к прежнему.

Толковым парням и девчонкам сразу было понятно: вот теперь наделаем кучу ошибок и надо как-то этого избежать. Решением стали тесты на питоне. Одноклеточные существа имитирующие облик и поведение людей просто не заморачивались. Как известно: нет тестов - нет проблем.

Отсутствие тестирования ansible ролей само по себе не так чтобы и плохо. Плохо станет потом. Например, когда не учли какие-то особенности или написали неидемпотентно. Или написали предельно криво и в какой-то счастливый момент нужно внести изменения.

Во всех этих случаях написание роли будет радующе быстро и чрезвычайно долго искать проблему и исправлять её. Потому что исправить правильно сделанное - просто. Кривое же придется переделывать и переделывать. Тратя время значительно превышающее для нормального написания. Самое радостное - один раз криво поправив кривое, придется исправлять его раз за разом.

Один из простых и рутинных способов тестирования - тестирование на чистой виртуалке. Пишем роль и запускаем её отлавливая ошибки, неточности и упущения.

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

Как вариант тестирования натравливать роль на заранее подготовленный докер образ. В этом варианте пересоздание тестовой среды проходит крайне быстро. Но не всегда просто и доступно. Например, не все могут подготовить докер имедж для тестирования systemd unit запускающего докер контейнер.

И как в варианте с виртуалкой - нужно глазами смотреть на результат. Можно, конечно, написать скрипты проверяющие состояние. Но так почти никто не делает из-за существования молекулы. О ней будет позже.

Если вы дочитали до этого момента - поздравляю! Здесь начинается самое интересное.

В природе существует такая библиотека - molecule. С помощью неё можно запускать подготовленные докер имеджи, запускать роль в этом докер имедже, и, самый сок - проверять соответствует ли полученное ожидаемому!

Создаем несколько конфигов molecule (create.yml, destroy.yml и т.д). Добавляем в verify.yml проверку на разные необходимые нам вещи. Добавляем линтер и жизнь заиграет совсем другими красками!

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

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

* будем отлавливать ошибки при запуске тестов, а не при установке в рабочий контур

* при незначительном изменении не надо мучительно вспоминать и перечитывать код на предмет, где оно еще может использоваться

* при встреченной ошибке в рабочей среде, просто добавляем нужный тест и не лезем в вики за чеклистом проверок

* довольно хорошо встраивается в ci/cd

* доказываем принадлежность к виду человека разумного

Использование тестов , в том числе на молекуле, сделает жизнь в айти менее каторжной.

---

Для утоления жажды знания по тестированию ролей обращайтесь к книге "Ansible Up and Running, 3rd Edition" и официальной документации molecule.