Георгий Турманидзе — системный администратор в компании «Живой сайт». Больше года он плотно работает с Ansible. Георгий осваивал инструмент на практике, а также в 2021 году проходил наш курс по Ansible.
Редакция Слёрма попросила Георгия рассказать, как он изучил эту систему управления конфигурациями и дать советы тем, кто только знакомится с инструментом. Передаём слово Георгию.
Ansible разложился, как скатерть-самобранка
В «Живой сайт» я пришёл два года назад обычным системным администратором и был вскользь знаком с Linux. Всему, в том числе работе с Ansible, научился здесь.
У нас обширная инфраструктура, подавляющая часть которой описана в Ansible. Мы его используем каждый день. Через Ansible работаем с Kubernetes, CloudFormation, Amazon: поднимаем инстансы, делаем снапшоты.
Ansible — крутой инструмент: его просто внедрить, легко обслуживать, он позволяет в понятном виде изобразить всю инфраструктуру и работать с ней.
Не скажу, что с Ansible возникли сложности. У нас всё основано на микросервисах, и сначала мне было трудно разобраться во взаимосвязях между ними. Но как только я понял зависимости, Ansible разложился, как скатерть-самобранка.
Ещё первое время я делал нелепые ошибки, например, указывал не тот inventory, но сверхъестественных фейлов не случалось. Как только я закрыл пробелы: научился пользоваться разными модулями, разобрался, как они между собой взаимодействуют и т. д. — всё пошло по накатанной.
Первая мозговыносящая задача заняла 3 дня
Нам понадобилось в hosts записывать строчки из inventory Ansible. Задачу поручили мне. Я тогда был джуном, и задание вынесло мне мозг. Я просидел три дня, прежде чем понял, как это организовать. В моём браузере было открыто 50 вкладок со Stack Overflow. В итоге придумал: брал кусок кода из inventory-файла, регистрировал как переменную и текстом вставлял в файл hosts. Потом брал другую строку, регистрировал как переменную и вставлял в hosts. Так делал до тех пор, пока не перенёс все строчки.
Фактически я программировал на Ansible. Правда, мой руководитель говорит, что лучше не писать на Ansible — получается нагромождение кода, в котором неподготовленному человеку трудно разобраться. Но в этом случае пришлось.
Советы тем, кто знакомится с Ansible
Сейчас я достаточно хорошо разбираюсь в Ansible и нет задачи, которую я не смог бы сделать с его помощью. Вот что я могу посоветовать тем, кто хочет быстрее освоить инструмент:
1. Вникать в проект.
Основная проблема, с которой я столкнулся вначале — я не видел взаимосвязи микросервисов, поэтому не понимал, что делает отдельный плейбук. Если какой-то плейбук выдавал ошибку, я не мог разобраться, почему. Шёл к тимлиду, а он говорил: «Чувак, всё в проекте» или «Чувак, погугли». Как только я выстроил взаимосвязи между всеми элементами проекта, то увидел полную картину.
Самый главный совет, который я могу дать новичкам — вникайте в проект. Читайте документацию и почаще пользуйтесь текстовым поиском. Например, увидели какую-то переменную — вбейте её в поиск и посмотрите, где она ещё используется. Такой подход позволит избежать большинства ошибок.
2. Использовать все возможности Ansible.
В Ansible множество инструментов, которые позволяют решить практически любую задачу наименьшими усилиями. Прежде чем писать суперсложный плейбук самому, следует посмотреть, есть ли готовый модуль или плагин, который делает то, что нужно. Также при составлении плейбуков стоит не хардкодить, а использовать переменные, secrets и т. д. Это поможет создавать плейбуки, которые будут одинаково хорошо работать на любом окружении до скончания времён.
Представим, что у нас часть серверов на CentOS 7, другая часть — на CentOS 8 и ещё несколько серверов — на Ubuntu. Нам нужно написать плейбук, который будет работать на всех трёх ОС. Как решить задачу? Можно было бы написать три разных плейбука, но вряд ли это оптимальное решение. Можно было бы похардкодить и создать монстра, который бы проигрывался на всех трёх ОС. Но со временем его стало бы сложно поддерживать. Наконец, можно написать один плейбук, но расставить условия: на CentOS 7 будут проигрываться одни роли, на CentOS 8 — вторые, а на Ubuntu — третьи. Последний вариант — лучше всего.
3. Не создавать плейбуки, в которых много других плейбуков.
Я не рекомендую запихивать в один плейбук множество других плейбуков. За прогоном такого плейбука сложно следить, а если он вдруг сломается на середине, придётся запускать его заново. Это лишняя трата времени и нервов. Если всё же хочется составить плейбук с 10-20-30 плейбуками внутри, может, стоит подумать о контейнеризации и создавать образы?
У нас есть плейбук, состоящий из 20 плейбуков. Он собирает dev-серверы, на которые установлена вся наша инфраструктура в миниатюре. Dev-серверы используют разработчики и администраторы для экспериментов. Плейбук проигрывается полтора часа. Если он сломается на середине — будет катастрофа. Сломать его может любая непродуманная правка, при этом ошибка вылетит не сразу, а только тогда, когда плейбук дойдёт до правки. При исправлении ошибки снова придётся ждать, чтобы проверить, правка починила плейбук, сделала хуже или ничего не изменилось.
Однажды я вносил правки в этот плейбук. Как это выглядело: я вносил правку и ждал 23 минуты — сломается или нет? Если не ломался, я радовался, добавлял следующую правку и опять ждал 23 минуты. В итоге я просидел очень долго, но смог починить плейбук. Правда, ситуация была стрессовой. Чувствовал себя героем сериала «Остаться в живых», которому надо раз в определённый промежуток времени нажимать на кнопку в бункере, иначе всё взорвётся.
4. Стараться комментировать каждую функциональность проекта.
В гигантском проекте-долгожителе не используется множество вещей. При этом ненужные куски кода продолжают работать наравне с нужными и на проигрывание плейбука уходит больше времени.
Мой совет: если в вашей компании только внедряют Ansible, старайтесь максимально комментировать каждую функциональность. Это пригодится людям, которые будут дальше поддерживать проект. Более того, провести рефакторинг кода с подробными комментариями гораздо легче и быстрее.
5. Не сдаваться 😊.
У меня была масса случаев, когда я шёл к тимлиду и оказывалось, что для решения задачи мне не хватило во-о-от столечко. Так я понял, что если хочется попросить помощи — значит, ответ близко. Главное — не сдаваться и копать до последнего.
Однако не стоит пренебрегать помощью, если проекту грозит опасность и надо быстро предпринять какие-то действия. В этом случае надо даже не идти, а бежать к тимлиду.
Курс Слёрма
Курс Слёрма по Ansible я проходил осенью 2021 года, мне его оплатила компания. На тот момент я уже полгода вдумчиво работал с Ansible и многое знал. Но курс всё равно оказался полезным. Он помог систематизировать знания и заполнить пробелы, о которых я даже не подозревал. Например, на курсе я узнал, что с помощью тега start-at-task можно начать проигрывание длинного-предлинного плейбука с определённого таска. Если честно, я это ни разу не использовал, но показалось интересным.
От редакции: несколько слов о курсе Слёрма «Ansible: Infrastructure as Code»
Всеволод Севостьянов, автор курса, говорит, что его цель — научить студентов мыслить как Ansible, делать как Ansible, быть как Ansible. Хотя… Быть как Ansible всё-таки перебор, наверное. Но решать вам.
Быть или не быть, вот в чём вопрос: https://slurm.io/ansible
