[Настройка Linux, Системное администрирование, Облачные вычисления, Серверное администрирование, DevOps] Основы Ansible, без которых ваши плейбуки — комок слипшихся макарон, часть 2
Автор
Сообщение
news_bot ®
Стаж: 6 лет 3 месяца
Сообщений: 27286
Я продолжаю выразительно пересказывать документацию Ансибла и разбирать последствия её незнания (ссылка на предыдущую часть).
В этой части мы обсуждаем инвентори. Я обещал ещё и переменные, но инвентори оказалась большой темой, так что посвящаем ей отдельную статью.
Мы будем разбирать каждый элемент инвентори (кроме host_group_vars plugin) и обсуждать зачем он, как его использовать правильно, и как неправильно.
Оглавление:
- Что такое хост? (и немного про транспорты)
- Доступ IP vs FQDN; inventory_hostname vs ansible_host
- ansible_user — писать или не писать?
- Группы
- Переменные: в инвентори или в плейбуку?
- Классификация инвентори по происхождению.
Инвентори — это список хостов, групп, а так же вспомогательные переменные. Изучая основы, мы будем разбирать каждый момент подробно, с поиском того, как "надо" и осуждением того, "как не надо".
Инвентори: хосты
Хост в инвентори — это элементы словаря hosts для группы в yaml-инвентори (в ini-инвентори — это первый элемент строки):
somegroup:
hosts:
somehost1:
somehost2:
somehost1, somehost2 — это хосты.
Что записывать как "хост" в инвентори, а что нет? Для ситуации, когда у вас два сервера, всё понятно — два сервера, два хоста. Но бывают ситуации и посложнее. Например, у нас могут быть гипервизоры и VM, коммутаторы, маршрутизаторы, ipmi'и и т.д.
Правильный подход: мы считаем отдельным хостом каждый объект, к которому может подключиться Ансибл через какой-либо транспорт. Это означает, что хостом являются: аппаратный сервер, виртуалка с ssh (даже если эта виртуалка запущена на сервере, который тоже есть в инвентори); апплайнс вендора (если к нему есть рабочий транспорт); коммутатор с доступом вовнутрь, lxc-контейнер. И даже контейнер докера может быть хостом, если вам что-то приспичило делать внутри него.
Антипаттерн: пытаться что-то сделать на сервере, которого нет в инвентори, через хаки и спецпеременные. Иногда такое возникает у новичков при работе с libvirt. В инвентори есть только гипервизоры, а виртуалки — в словаре "vms" или как-то так. Антипаттерн начинается так: Создали виртуалку на гипервизоре, потом приспичило что-то по ssh посмотреть на виртуалке после её запуска...
… история достигает кульминации где-то в глубоком инклюде, в стиле include_role: configure_vm, внутри которой миллион странных переопределений ansible_host, парсинг вывода ssh vm_ip somecommand,… на что люди не пойдут, лишь бы заставить негодный код работать.
Повторим: инвентори описывает то, на чём Ансиблу надо что-то делать (менять) через доступный транспорт.
Вопрос: если у нас виртуальная машина создаётся Openstack'ом провайдера, надо ли эндпоинт API провайдера вписывать в инвентори? И почему?
Ответ: не надо. Потому что мы не можем иметь к нему полноценный транспорт. При том, что мы подключаемся к нему из соответствующих модулей, это подключение не квалифицируется как "транспорт".
Другой вопрос: а надо ли делать отдельным хостом в инвентори коммутатор у которого есть management_ip и к котому подключены ваши сервера?
Ответ: Если можете что-то поменять на коммутаторе через его модули (Условный dlink_configure) и вам надо что-то там менять, то вписывайте. Если не можете, или можете, но не нужно, то и вписывать не нужно.
Существует ровно две причины, почему вы можете хотеть вписать что-либо в инвентори:
а) Вы его настраиваете штатными методами (у вас есть туда транспорт и вы что-то делаете).
б) Вы на него делегируете (delegate_to).
Ещё один антипаттерн, обратного типа, добавлять в инвентори лишнее. В инвентори добавляется что-то, что не существует (и не будет существовать) и используется в качестве помойки для перменных. Не делайте так. Во-первых у вас уже есть localhost для project-global переменных (хотя помойка переменных — это не очень хорошо само по себе). Во-вторых, если вы вписываете в инвентори что-то, что заведомо не работает, вы ломаете группу all (а группа all у нас существует всегда). Это вызывает мелкие шероховатости и WTF каждый раз, когда вы натыкаетесь на несуществующий хост. Я считаю это анти-паттерном, который делает простой и хорошо работающий механизм (связь хост-плейбука) шатким и полным условностей.
Инвентори: ansible_host vs FQDN
В этой главе мы хорошо разбираемся с тем, что такое inventory_hostname, что такое ansible_host, с понятием транспорта.
При том, что транспорт уже не совсем "инвентори", к содержимому инвентори он относится наипрямейшим образом, потому что смена транспорта внутри play — это уже экстремальный спорт, на который не распространяется ваша медстраховка.
Что такое "транспорт"? Это результат использования "connection plugin" Ансибла, через который модуль копируется в целевую систему (или, в ряде случаев, не копируется, но получает доступ к целевой системе). Какой-то транспорт используется всегда. Самый популярный транспорт ssh (используется по-умолчанию), но их на самом деле много. Каждый плагин может использовать набор переменных, выделенных для подключения: ansible_host, ansible_user, ansible_port и т. д. А может и не использовать. Например, если транспорт lxc (который выполняет код через lxc-execute), то зачем ему порт?
Если же ansible_host не задан, то используется inventory_hostname. Это — имя хоста в инвентори.
Вот пример:
---
somegroup:
hosts:
somehost:
ansible_host: 254.12.11.10
Вот somehost тут — это inventory_hostname. Если нет ansible_host, то используется inventory_hostname. И всё было бы понятно, если бы не следующий уровень преобразований, который не имеет никакого отношения к Ансибл, но может попортить много нервов.
Внутри как inventory_hostname, так и ansible_host может быть либо адрес, либо имя. С адресом всё понятно, а вот с именем уже интереснее. Оно передаётся "как есть" в нижележащий исполнитель. Интерпретация имени оставляется на усмотрение транспорта. Например, lxc использует его для выбора контейнера. А вот ssh (самый распространённый транспорт, напоминаю) использует кое-что более сложное.
Во-первых, он смотрит в конфиг ~/.ssh/ssh_config (или другой, заданный через переменные окружения). Если кто пропустил, напоминаю, что конфиг ssh тьюринг-полный и может делать странное через комбинацию регэкспов и сниппетов для исполнения баша. Т.е. переданное имя становится (в общем случае) аргументом к частично-рекурсивной функции, которая (может быть) выдаёт реальные параметры соеднения на выходе. Может быть, соединение пойдёт через цепочку jump-хостов, редиректов портов и прочего ssh-цирка. А может быть, такого хоста не найдётся. Если же из ssh_config выползает другое имя (или искомого нет в ssh_config), то ssh делает gethostbyname(). Это вызов libc, который получает адрес по имени. Который, в свою очередь, руководствуется пачкой конфигурационных файлов (/etc/nsswitch.conf, /etc/hosts) и ответами DNS-ресолвера (если конфигурационные файлы это разрешают). Который, в свою очередь, может дописывать к имени домен, смотреть на разные рекурсивные DNS-сервера, которые могут отвечать разное, а могут посмотреть на ресурсную запись CNAME пойти куда сказано… Просто у волшебная простыня возможностей того, что может пойти не так.
Из этого вытекает моё, выстраданное, мнение: при работе с SSH, всегда (кроме спецслучаев) использовать ansible_host внутри которого IP-адрес.
Я пробовал другой путь, и он мне местами аукается до сих пор. Давайте разберём этот вопрос подробно.
Если вы используете любое вне-ансибловое, но host-local определение имени (ssh_config, /etc/hosts), то ваши плейбуки перестают быть портабельными между машинами. Вы ссылаетесь на что-то, что существует только у вас в голове и с вами разговаривает только в конфигурации вашего компьютера. Вы не можете перетащить эти плейбуки на CI, на машину коллеги или даже на вторую вашу машину. Точнее, можете, но для этого нужно что-то (что?) прописать в конфигурацию, которой не видно в репозитории. Опечатки трудно отлаживать (у меня всё работает), изменения почти невозможно распространять. НЕ ДЕЛАЙТЕ ТАК.
Хотя, разумеется, есть исключения. Например, моя маленькая уютная оверлейная сеточка для домашних нужд живёт с именами из /etc/hosts и все плейбуки полагаются на эти имена. Но это моё осознанное решение, которое к индустриальному продакшену никакого отношения иметь не должно.
Если вы используете DNS, то вы получаете себе регэксп ещё одну проблему. Когда изменения в DNS дойдут до вашей машины? Негативное/позитивное кеширование, всё такое. А даже если оно дошло до вас, то когда оно дойдёт до резолвера, которым пользуется ваш динамический слейв CI? Слейв-то помер, а DNS-ресолвер — нет. Удачи в отладке. НЕ ДЕЛАЙТЕ ТАК.
Второй момент, куда более тонкий. Надо ли всегда указывать ansible_host или inventory_hostname достаточно?
В плейбуках рано или поздно возникает потребность указать "адрес соседа". В самых трудных случаях этот процесс требует модуля setup и выполнения головоломного кода:
- name: Ping neighbor
command: ping -c 1 {{ neighbor_ip }} -w 1
changed_when: false
vars:
neighbor_ip: '{{ (hostvars[item].ansible_all_ipv4_addresses|ipaddr(public_network))[0] }}'
with_items: '{{ groups[target_group] }}'
(имея на руках public_network мы проверяем, что хосты могут общаться со всеми серверами в группе target_group).
Но, это трудный случай, поскольку у серверов несколько интерфейсов. В 99% случаев вам нужен просто "адрес соседа". Если вы договорились, что у каждого хоста есть ansible_host и внутри там обязательно IP-адрес, то вот он. Никакого setup. Бери и используй. Прелесть ansible_host с IP-адресом трудно переоценить, потому что, помимо "какого-то IP соседа", этот адрес ещё неявно (явно!) отвечает вам на вопрос, какой из IP-адресов сервера является его "access address" при наложении всяких файрвольных правил, конфигурации доступов и т.д. Делайте так. Это хорошо и удобно.
… Но тут может возникнуть вопрос: а если у нас сервера появляются на свет динамически, или у нас внешная система оркестрации (а-ля докер) у которой точно есть хороший DNS? Ну, тогда используйте их. А, заодно, страдайте, если вам понадобились IP. Разумеется, к любой общей рекомендации всегда можно найти частные исключения.
Инвентори: ansible_user
Следующая интереснейшая проблема: надо ли в инвентори хранить имя пользователя? Это важный вопрос, но у него нет однозначного ответа. Вот набор моментов, о которых надо подумать перед выбором.
- Есть ли доступ к этому хосту из-под "спецаккаунта" у других пользователей? Если есть, то ansible_user в инвентори разумно.
- Есть ли доступ к серверу под "своими" аккаунтами у других пользователей? Если есть, то ansible_user в инвентори создаёт проблемы.
- Если вы не указываете пользователя в инвентори, то опция -u у ansible-playbook позволяет пользователя задать, причём так, что его можно переопределить из любого места в инвентори или плейбуке для необычных видов коннектов. Это удобно. Каждый под своим пользователем, CI использует -u (или тоже под своим пользователем), все счастливы.
- Но тогда абстракция протекает. Например, ваш сосед может быть залогинен на своём ноутбуке под именем 'me'. Это ж его ноутбук. А на сервере он — m.gavriilicheynko. Неудобненько.
- В то же самое время, использование опции ansible-playbook -e ansible_user=ci (для CI, например) с одной стороны позволяет использовать правильное имя вне зависимости от содержимого инвентори, с другой стороны ломает все нестандартные подключения (к коммутаторам, например).
- Если у вас стоит проблема "первого логина" (плейбука создаёт всех пользователей, но только после первого запуска), то первый запуск можно сделать и с опцией -u, и никто не помрёт.
В моей практике (и обстоятельствах, в которых я работаю), мне удобно указывать ansible_user для "себя" (т.е. инвентори, к которыми работаю только я). Если инвентори используется более одним человеком — ansible_user используется только для специальных случаев (например, доступ к коммутаторам при первом провизе и т.д.), а обычные хосты ansible_user не используют.
Группы
Как только мы начинаем обсуждать группы, мы уже обсуждаем не только и не столько "что должно быть в инвентори", сколько онтологическое понятие "группы". Это тонкий хрупкий мир архитектурного Ансибла, где одно неловкое движение оставляет от красивого замка колючие обломки. Группы — очень сильный механизм в Ансибл, но его неправильное применение может очень сильно всё поломать.
Для чего использует группы Ansible?
Во-первых, группы используются как встроенные "списки хостов" (в переменной hosts в play и внутри магического словаря groups). Во-вторых, группы предоставляют групповые переменные, наследуемые хостами из группы. В целом, технически, можно писать плейбуки используя только переменные (вы можете использовать в hosts переменные, если переменные хотя бы одного хоста были инициализированы). Но, разумеется, так делать не надо. А надо использовать группы.
Для чего вы используете группы (почувствуйте разницу — использует Ансибл, используете вы):
- Для назначения на них play. (директива hosts). Например, группа 'prometheus' может включать в себя все сервера, на которых надо настраивать Prometheus.
- Для хранения общих переменных у каких-то серверов. Заметим, я не говорю, что перменные надо хранить в инвентори ("где хранить переменные" мы будем разбирать отдельно), я говорю, что вы всё-таки решили, что нужно, то переменные группы — отличное место хранения общих (одинаковых) переменных для всех серверов группы.
- Для семантической аннтоации кода.
Первая задача самоочевидная, ей пронизаны все примеры, так что пропускаем.
Вторая задача — общие переменные. Про переменные мы говорим потом, а пока скажем, что отдельная группа с настройками (группа, для которой нет play) — это не самая плохая идея. Даже, наоборот, отличная идея.
Так что основной фокус будет на семантику. Группа — это возможность дать общее название нескольким серверам. До этого у вас были сервера jc-r4, xcore-lu1 и ams1-se-r2, а теперь появилось имя "netflow_collectors". Насколько у вас увеличилось понимание зачем эти сервера? Я бы сказал, что до появления имени группы, это были просто буковки, а после появления имени, вам даже в содержимое ролей не надо заглядывать, вы плюс/минус и так знаете, что эти сервера делают.
Имена групп позволяют наделить смыслом инвентори. Человек, который читает инвентори уже видит не просто список хостов с машиночитаемой информацией, а некий рассказ — у нас есть сервера такого типа, сервера такого типа, а ещё у нас есть группа серверов, у которых есть доступ в базу данных. А есть группа серверов с включенным эникастом.
Другими словами, инвентори с именами групп — это рассказ про ваш проект. Если ваши имена невнятные или ничего не рассказывают, то и рассказ у вас получается в стиле "этот к тому и так его что тот аж туда".
Имена групп — это первый проблеск смысла в вашем проекте, который встречает читающего.
При этом группы — это компромисс между инвентори и play. Дело в том, что play накладывает требования на инвентори (хочешь получить запущенным докер — положи хост в группу docker). Но инвентори может добавлять свои группы, которые не используются в play (те самые группы для переменных), использовать наследование, то есть мягко корректировать ожидания play.
Отдельно надо рассказать про наследование. Наследование устроено просто — одна группа может быть потомком другой группы.
Вот пример простого наследования:
---
foo:
hosts:
foo1:
foo2:
bar:
hosts:
bar1
foobar:
children:
foo:
bar:
Наследование — это инструмент инвентори и только инвентори. Никогда play не должна полагаться на какое-либо наследование. (Вы не поверите, но между моментом, пока я написал эти строчки и моментом, когда я опубликовал эту статью, я исправил свою же ошибку, в которой плейбука неявно полагалась на то, что группа grafana-servers является потомком группы mons — а я как раз сделал её потомком группы mgrs в новой версии инвентори).
Наследование позволяет передать ещё кусочек семантики "мы размещаем mgrs на хостах mons" в явном виде. Это одновременно и механизм DRY (do not repeat yourself, один из принципов хорошей разработки) для инвентори, и ещё один метод более выразительной передачи смысла читателю.
Немного о динамических группах и динамических инвентори.
Динамическая инвентори — это результат исполнения какого-то кода, выдающего на выходе "обычную" инвентори. Динамические группы создаются модулем group_by или модулем add_host внутри плейбук.
Есть ситуации, когда они оправданы. Например, у вас инвентори всегда генерируется роботом (третий вариант в разделе ниже). Или, вы не хотите загромождать инвентори второстепенными группами, формирующимися по специальным правилам. Такие ситуации есть, но они — очень пограничный случай. Если можете избежать — избегайте, потому что они несут с собой несколько фундаментальных минусов. Например, динамические группы не позволяют нормального --limit. Вам надо выполнить таску group_by, а для каких хостов исполнять не понятно, т.е. мимо --limit оно пролетает. Возникает особый культ тега [always], потому что любая попытка использовать теги натыкается на отсутствие динамических групп. Вообще, group_by — это момент, когда плейбука начинает диктовать вместо inventory что у вас в инвентори. Ой.
Динамические же инвентори делают невозможным воспроизведение проблемы, если источник инвентори "дрожит" (т.е. меняется от запуска к запуску). Вы же помните, что список хостов в группе — это на самом деле словарь? Далеко не все языки программирования сохраняют порядок в словаре (в Питоне это называют "словарь", в других языках это hashmap, map, object, и т.д.). Более того, даже в обычном Питоне порядок сериализации элементов словаря не определён. Ансибл специально прикладывает усилия к тому, чтобы порядок хостов в группе соответствовал порядку перечисления в инвентори (начиная с 2.4 даже есть специальный параметр play: order, дефолтное значение которого inventory).
Когда это портит жизнь? В тот момент, когда:
- Вы полагаетесь на groups.somegroup[0] как на "основной сервер". Не то, чтобы это была уж очень хорошая практика, но встречается. После изменения порядка серверов в динамической инвентори на следующем прогоне Ансибла у вас это окажутся разные сервера. Не всегда взаимнозаменяющие.
- Вы формируете списки (например, pg_hba.conf, allowed в nginx.conf, etc). У вас меняется порядок, файл changed. Мало того, что лишние reload'ы, так ещё и постоянные changed в выводе. Что очень-очень плохо, и во всей документации вам многократно говорили, что надо писать идемпотентно.
Эти проблемы устранимы, но если у вас инвентори "дрожит", вам приходится с этой дрожью бороться.
Второй источник боли для динамической инвентори в некотором пофигизме отдельных механизмов. Например, если у вас инвентори создаётся из содержимого региона openstack'а, то если вы случайно оставили в переменных среды окружения более высокоприоритетную переменную для подключения к Openstack, чем то, что вы используете обычно, то вы получите вывод другого региона или тенанта. (если вы получаете ошибку, всё, проблема обнаружена — я про ситуацию, когда изменение "прокатило"). Вам выдали другой комплект хостов. Один раз. В следующий раз (в соседней консоли) всё будет хорошо. Вы пошли куда-то сделали что-то. Возможно, фатальное. Возможно, записав пароли к продакшен базе в staging сервер. Или вообще, куда-то в публично-доступное место. Боль-боль-боль, а главное, никаких шансов на адекватную отладку. Инвентори-то динамическая. Аналогично вас ждёт боль и неожиданное, если у приложения расслабленная модель обработки ошибок. Нет каких-то данных из-за временной ошибки? Ок, пускай будет "пусто". Что такое пусто? Ну, пусть будет пустой словарь. Ррр… аз, и у вас в списке клиентов базы данных пусто. Вы берёте и пишите в конфиг СУБД новый список разрешённых IP, в котором никаких клиентов нет. Чпок, даунтайм. При следующем прогоне Ансибла всё опять поднялось. Виноваты программисты, а отлаживать вам.
Именно по этой причине я, в проекте, где инвентори формируется роботами, я эту инвентори не использую как инвентори, а сохраняю в файл, который объявлен артефактом для джобы. Это не решает всех проблем, но, по-крайней мере, есть бумажный след случившегося.
Инвентори: переменные
Последняя составляющая инвентори — это переменные. Поскольку внутри инвентори могут быть и хосты и группы, все переменные в инвентори являются либо переменными хоста, либо переменными группы. Оба вида переменных одинаково доступны в play и ролях, разница между ними (кроме эргономики DRY) проявляется при определении, какие переменные "важнее" (variable precedence). Вопросы приоритетов переменных и области их жизни мы будем обсуждать в следующей части, а в этом разделе фокус будет на том, какие переменные класть в инвентори, а какие не в инвентори.
… И это нас подводит к другому вопросу: что есть инвентори?
Давайте сделаем шаг наверх и попытаемся описать структуру проекта на Ансибле общими терминами. У нас есть плейбуки — это код и данные. У нас есть инвентори, которое в нормальном режиме содержит только данные (игнорируем лукапы и программирование на jinja). Мы объединяем плейбуки и инвентори и получаем рабочее "нечто". Как это "нечто" называется?
Кто-то это может назвать "инсталляцией", кто-то "средой", кто-то "стейджем". Точное название не важно (хотя я буду использовать "инсталляция"). Важно, что комбинация инвентори и плейбуки делает конкретные вещи на конкретных серверах (даже если эти сервера появляются на свет в процессе исполнения плейбуки и умирают в по окончанию). Плейбука описывает что делать, а инвентори — где делать.
Плейбука контролирует взаимоотношения между "участниками" инвентори. В ассортименте делегация, списки, изменение ansible_host, заглядывание в hostvars и т.д. (я не говорю, что это хорошо, но может быть). Инвентори в свою же очередь контролирует плейбуку посредством переменных и разной группировки хостов.
Но не смотря на возникающее взаимопроникновение, нужно сохранять принцип, что плейбука (и её переменные) это "что", а инвентори (и её переменные) — "где". Чем меньше эта граница размывается, тем легче сопровождать проект.
… Если бы было всё так просто. Например, пароль в базу данных, очевидно, является объектом инвентори (исходя из best practices, что переиспользовать пароли — зло, и мы хотим на каждую инсталляцию иметь свой пароль). В логику "где" это совсем не укладывается, так что инвентори, это не только указание на то, где выполнять, но и все отличительные особенности инсталляции.
Название "отличительные особенности" мне нравится своей ёмкостью. Мы перечисляем в инвентори чем одна инсталляция отличается от другой. С применением DRY список отличий должен быть настолько малым, насколько можно, а все производные — вычисляться где-то в другом месте. Попробуем применить этот принцип на практике.
Вопрос: Объём памяти, выделяемый под java-приложение должен задаваться в инвентори или внутри плейбуки, которая это приложение настраивает?
Ответ: если разные инсталляции должны иметь разный объём памяти, и мы не можем определить его автоматически (например, по числу хостов в группе), то это переменная для инвентори. Если объём памяти — это результат изысканий специалиста и он должен быть одинаковым в staging и production, то это переменная для роли или плейбуки.
Вопрос: номер порта на localhost, на котором слушает приложение (сверху там nginx в режиме proxy_pass), это переменная плейбуки или инвентори?
Ответ: это переменная плейбуки, если нет специальных причин делать эти порты разными между инсталляциями.
Вопрос: список пользователей — это переменная плейбуки или инвентори?
Ответ: зависит от того, разный у вас список пользователь между инвентори или нет. Если разный, то это переменная инвентори, если во всех инсталляциях список пользователей одинаковый — это плейбука.
Надеюсь, это даёт некоторую интуицию по переменным инвентори. Основной вопрос, который надо себе задавать: "почему эта переменная должна быть в инвентори"? Другими словами, инвентори — это специальное место для перменных, и вам нужны специальные причины записывать их туда.
Происхождение инвентори
Есть ещё один аспект инвентори, про который редко говорят. Кто пишет инвентори?
Общего ответа тут нет, так что я расскажу "как бывает".
Первый вариант — инвентори жёстко привязана к репозиторию с плейбуками. У вас есть production.yaml, staging.yaml, или даже каталоги инвентори production/ и staging/, или же у вас пять регионов, и каждый имеет свою инвентори. В этом случае развитие (изменение) инвентори происходит одновременно с развитием плейбук. В этом случае для вас "происхождение инвентори" звучит странно. Вы придумываете себе схему именования инвентори и правил работы с инвентори и всё хорошо. Это случай обычного инфраструктурного проекта, который пишут и сопровождают одни и те же люди. Это же случай, когда вы пишите "для себя" (конфигурация лабораторий, стендов, конфигурация плейбук для сайта вашей компании, etc).
Второй вариант — инвентори пишут другие люди. Где-то там есть git с плейбуками, и может быть, с примерами инвентори, а где-то есть другой git с инвентори. Такая ситуация часто бывает, если разработка и эксплуатация различаются. Все крупные проекты по развёртыванию чего-либо (ansible, ceph, openshift, etc) пишутся в этом режиме. Пишет одна группа, эксплуатируют разные другие группы. В этой ситуации инвентори становится подобием API, интерфейсом между кодом плейбук и "конфигурацией" инвентори. У меня есть ощущение, что апстрим Ансибла не особо думал про этот случай, потому что тут бывает очень много трудных моментов, но в модели разработки с разными группами людей, это неизбежно.
Ключевым моментом плейбук в этом случае является обеспечение минимального уровня связности с инвентори. Чем меньше, тем лучше. (И именно тут, на уменьшении связности, Ансибл не очень хорош). Ещё этот вариант приводит к понятию "сценария" — у вас один и тот же код (плейбуки) может использоваться в самых разных ситуациях, которые покрываются разными участками плейбук или одни и те же таски имеют разный смысл в разных ситуациях (сравните, например, развёртывание ceph-ansible'а в контейнерах ради RGW в динамической среде приложения или на бареметал в роли хранилища бэкапов на века).
Третий вариант — инвентори пишут роботы (или другие плейбуки). Это подмножество предыдущего варианта, но с ещё более жёсткими ограничениями. Развёртывание среды для тестов в CI с генерацией инвентори — один пример. Другой — использование ансибла для управления слейвами последователями в системах со встроенной оркестрацией. В такой ситуации структура инвентори перестаёт ориентироваться на человеков и начинает служить нуждам машиночитаемости — удобства генерации, отладки, модульности. Можно забывать про DRY, про выразительность и семантику. Зато надо быть очень строгим по типам и наличию значений. Пишут роботы для роботов.
При работе над проектом надо для себя точно определить какие варианты вы хотите делать. Одно дело, когда у вас инвентори — это 3000 коммитов за 10 лет эксплуатации, другое дело, если инвентори — файл, который создаёт одна плейбука для другой плейбуки на время жизни джобы на CI.
Составные инвентори
Есть ещё один режим работы с инвентори — это составные инвентори. Я сомневался писать про них или нет, но, раз уж я посвятил целый раздел только инвентори, видимо, писать.
Ансибл поддерживает больше одной инвентори.
ansible-playbook -i inventory1.yaml -i inventory2.yaml play.yaml
Содержимое инвентори объединяется по принципу "последний побеждает". Первый-второй уровень объединяется (группа состоит из хостов из первой и второй инвентори), дальше перезаписываются последней инвентори (например, если inventory2.yaml даёт users: [...], то она будет перезаписывать аналогичную из inventory1.yaml).
Где это полезно? Например, если у вас часть данных динамическая, вы можете иметь одну инвентори динамической, а вторую статической.
Второй момент: инвентори поддерживает переменные в файлах (host_vars/, group_vars в каталоге с инвентори). Если у вас инвентори пишут роботы, то вы (как авторы плейбук) можете подкладывать дополнительные переменные инвентори в чужую инвентори (робота). Edge case, мягко говоря.
Это точно не "основы Ансибла" и плюсы/минусы применения такого подхода надо взвешивать очень внимательно. Основное, что нужно помнить, что чем сложнее у вас связи в проекте, тем ближе вы к предельному состоянию проекта на Ансибле, который пишут долго и старательно, соблюдая второй закон термодинамики. Это предельное состояние называется "комок слипшихся макарон". И вы этого не хотите.
Навигация:
- Предыдущая часть
- Следующие части: переменные, Jinja всюду, scope и precedence переменных. Куда сохранить порт приложения, который нужен мониторингу? Сколько разных вложенных языков программирования за раз может выдержать человеческий мозг?
===========
Источник:
habr.com
===========
Похожие новости:
- [Системное администрирование] Clickhouse против Postgres — какую базу данных использовать для анализа логов nginx (перевод)
- [DevOps, Настройка Linux] Используем nftables в Red Hat Enterprise Linux 8 (перевод)
- [Django, IT-инфраструктура, Разработка под Linux, Системное администрирование] Как мы автоматизировали весь жизненный цикл серверов
- [Системное администрирование] Zimbra — Генерация HTML подписи на основе данных LDAP
- [DevOps, Kubernetes, Системное администрирование] Валидация Kubernetes YAML на соответствие лучшим практикам и политикам (перевод)
- [DevOps, Open source, Карьера в IT-индустрии, Учебный процесс в IT] Какой совет оказал наибольшее влияние на вашу карьеру в DevOps (перевод)
- [Информационная безопасность, Сетевые технологии, Системное администрирование] SIGRed — новая критическая уязвимость в Windows Server. Как защититься?
- [Сетевые технологии, Системное администрирование] Zextras запускает собственную версию почтового сервера Zimbra 9 Open Source
- [Системное администрирование, Хостинг] Apache & Nginx. Связаны одной цепью
- [DevOps, Системное администрирование] Новые подходы автоматизации Wildfly
Теги для поиска: #_nastrojka_linux (Настройка Linux), #_sistemnoe_administrirovanie (Системное администрирование), #_oblachnye_vychislenija (Облачные вычисления), #_servernoe_administrirovanie (Серверное администрирование), #_devops, #_ansible, #_spasibo_za_chtenie (спасибо за чтение), #_best_practices, #_nastrojka_linux (
Настройка Linux
), #_sistemnoe_administrirovanie (
Системное администрирование
), #_oblachnye_vychislenija (
Облачные вычисления
), #_servernoe_administrirovanie (
Серверное администрирование
), #_devops
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 19-Май 10:11
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 3 месяца |
|
|
Я продолжаю выразительно пересказывать документацию Ансибла и разбирать последствия её незнания (ссылка на предыдущую часть). В этой части мы обсуждаем инвентори. Я обещал ещё и переменные, но инвентори оказалась большой темой, так что посвящаем ей отдельную статью. Мы будем разбирать каждый элемент инвентори (кроме host_group_vars plugin) и обсуждать зачем он, как его использовать правильно, и как неправильно. Оглавление:
Инвентори — это список хостов, групп, а так же вспомогательные переменные. Изучая основы, мы будем разбирать каждый момент подробно, с поиском того, как "надо" и осуждением того, "как не надо". Инвентори: хосты Хост в инвентори — это элементы словаря hosts для группы в yaml-инвентори (в ini-инвентори — это первый элемент строки): somegroup:
hosts: somehost1: somehost2: somehost1, somehost2 — это хосты. Что записывать как "хост" в инвентори, а что нет? Для ситуации, когда у вас два сервера, всё понятно — два сервера, два хоста. Но бывают ситуации и посложнее. Например, у нас могут быть гипервизоры и VM, коммутаторы, маршрутизаторы, ipmi'и и т.д. Правильный подход: мы считаем отдельным хостом каждый объект, к которому может подключиться Ансибл через какой-либо транспорт. Это означает, что хостом являются: аппаратный сервер, виртуалка с ssh (даже если эта виртуалка запущена на сервере, который тоже есть в инвентори); апплайнс вендора (если к нему есть рабочий транспорт); коммутатор с доступом вовнутрь, lxc-контейнер. И даже контейнер докера может быть хостом, если вам что-то приспичило делать внутри него. Антипаттерн: пытаться что-то сделать на сервере, которого нет в инвентори, через хаки и спецпеременные. Иногда такое возникает у новичков при работе с libvirt. В инвентори есть только гипервизоры, а виртуалки — в словаре "vms" или как-то так. Антипаттерн начинается так: Создали виртуалку на гипервизоре, потом приспичило что-то по ssh посмотреть на виртуалке после её запуска... … история достигает кульминации где-то в глубоком инклюде, в стиле include_role: configure_vm, внутри которой миллион странных переопределений ansible_host, парсинг вывода ssh vm_ip somecommand,… на что люди не пойдут, лишь бы заставить негодный код работать. Повторим: инвентори описывает то, на чём Ансиблу надо что-то делать (менять) через доступный транспорт. Вопрос: если у нас виртуальная машина создаётся Openstack'ом провайдера, надо ли эндпоинт API провайдера вписывать в инвентори? И почему? Ответ: не надо. Потому что мы не можем иметь к нему полноценный транспорт. При том, что мы подключаемся к нему из соответствующих модулей, это подключение не квалифицируется как "транспорт". Другой вопрос: а надо ли делать отдельным хостом в инвентори коммутатор у которого есть management_ip и к котому подключены ваши сервера? Ответ: Если можете что-то поменять на коммутаторе через его модули (Условный dlink_configure) и вам надо что-то там менять, то вписывайте. Если не можете, или можете, но не нужно, то и вписывать не нужно. Существует ровно две причины, почему вы можете хотеть вписать что-либо в инвентори: а) Вы его настраиваете штатными методами (у вас есть туда транспорт и вы что-то делаете). б) Вы на него делегируете (delegate_to). Ещё один антипаттерн, обратного типа, добавлять в инвентори лишнее. В инвентори добавляется что-то, что не существует (и не будет существовать) и используется в качестве помойки для перменных. Не делайте так. Во-первых у вас уже есть localhost для project-global переменных (хотя помойка переменных — это не очень хорошо само по себе). Во-вторых, если вы вписываете в инвентори что-то, что заведомо не работает, вы ломаете группу all (а группа all у нас существует всегда). Это вызывает мелкие шероховатости и WTF каждый раз, когда вы натыкаетесь на несуществующий хост. Я считаю это анти-паттерном, который делает простой и хорошо работающий механизм (связь хост-плейбука) шатким и полным условностей. Инвентори: ansible_host vs FQDN В этой главе мы хорошо разбираемся с тем, что такое inventory_hostname, что такое ansible_host, с понятием транспорта. При том, что транспорт уже не совсем "инвентори", к содержимому инвентори он относится наипрямейшим образом, потому что смена транспорта внутри play — это уже экстремальный спорт, на который не распространяется ваша медстраховка. Что такое "транспорт"? Это результат использования "connection plugin" Ансибла, через который модуль копируется в целевую систему (или, в ряде случаев, не копируется, но получает доступ к целевой системе). Какой-то транспорт используется всегда. Самый популярный транспорт ssh (используется по-умолчанию), но их на самом деле много. Каждый плагин может использовать набор переменных, выделенных для подключения: ansible_host, ansible_user, ansible_port и т. д. А может и не использовать. Например, если транспорт lxc (который выполняет код через lxc-execute), то зачем ему порт? Если же ansible_host не задан, то используется inventory_hostname. Это — имя хоста в инвентори. Вот пример: ---
somegroup: hosts: somehost: ansible_host: 254.12.11.10 Вот somehost тут — это inventory_hostname. Если нет ansible_host, то используется inventory_hostname. И всё было бы понятно, если бы не следующий уровень преобразований, который не имеет никакого отношения к Ансибл, но может попортить много нервов. Внутри как inventory_hostname, так и ansible_host может быть либо адрес, либо имя. С адресом всё понятно, а вот с именем уже интереснее. Оно передаётся "как есть" в нижележащий исполнитель. Интерпретация имени оставляется на усмотрение транспорта. Например, lxc использует его для выбора контейнера. А вот ssh (самый распространённый транспорт, напоминаю) использует кое-что более сложное. Во-первых, он смотрит в конфиг ~/.ssh/ssh_config (или другой, заданный через переменные окружения). Если кто пропустил, напоминаю, что конфиг ssh тьюринг-полный и может делать странное через комбинацию регэкспов и сниппетов для исполнения баша. Т.е. переданное имя становится (в общем случае) аргументом к частично-рекурсивной функции, которая (может быть) выдаёт реальные параметры соеднения на выходе. Может быть, соединение пойдёт через цепочку jump-хостов, редиректов портов и прочего ssh-цирка. А может быть, такого хоста не найдётся. Если же из ssh_config выползает другое имя (или искомого нет в ssh_config), то ssh делает gethostbyname(). Это вызов libc, который получает адрес по имени. Который, в свою очередь, руководствуется пачкой конфигурационных файлов (/etc/nsswitch.conf, /etc/hosts) и ответами DNS-ресолвера (если конфигурационные файлы это разрешают). Который, в свою очередь, может дописывать к имени домен, смотреть на разные рекурсивные DNS-сервера, которые могут отвечать разное, а могут посмотреть на ресурсную запись CNAME пойти куда сказано… Просто у волшебная простыня возможностей того, что может пойти не так. Из этого вытекает моё, выстраданное, мнение: при работе с SSH, всегда (кроме спецслучаев) использовать ansible_host внутри которого IP-адрес. Я пробовал другой путь, и он мне местами аукается до сих пор. Давайте разберём этот вопрос подробно. Если вы используете любое вне-ансибловое, но host-local определение имени (ssh_config, /etc/hosts), то ваши плейбуки перестают быть портабельными между машинами. Вы ссылаетесь на что-то, что существует только у вас в голове и с вами разговаривает только в конфигурации вашего компьютера. Вы не можете перетащить эти плейбуки на CI, на машину коллеги или даже на вторую вашу машину. Точнее, можете, но для этого нужно что-то (что?) прописать в конфигурацию, которой не видно в репозитории. Опечатки трудно отлаживать (у меня всё работает), изменения почти невозможно распространять. НЕ ДЕЛАЙТЕ ТАК. Хотя, разумеется, есть исключения. Например, моя маленькая уютная оверлейная сеточка для домашних нужд живёт с именами из /etc/hosts и все плейбуки полагаются на эти имена. Но это моё осознанное решение, которое к индустриальному продакшену никакого отношения иметь не должно. Если вы используете DNS, то вы получаете себе регэксп ещё одну проблему. Когда изменения в DNS дойдут до вашей машины? Негативное/позитивное кеширование, всё такое. А даже если оно дошло до вас, то когда оно дойдёт до резолвера, которым пользуется ваш динамический слейв CI? Слейв-то помер, а DNS-ресолвер — нет. Удачи в отладке. НЕ ДЕЛАЙТЕ ТАК. Второй момент, куда более тонкий. Надо ли всегда указывать ansible_host или inventory_hostname достаточно? В плейбуках рано или поздно возникает потребность указать "адрес соседа". В самых трудных случаях этот процесс требует модуля setup и выполнения головоломного кода: - name: Ping neighbor
command: ping -c 1 {{ neighbor_ip }} -w 1 changed_when: false vars: neighbor_ip: '{{ (hostvars[item].ansible_all_ipv4_addresses|ipaddr(public_network))[0] }}' with_items: '{{ groups[target_group] }}' (имея на руках public_network мы проверяем, что хосты могут общаться со всеми серверами в группе target_group). Но, это трудный случай, поскольку у серверов несколько интерфейсов. В 99% случаев вам нужен просто "адрес соседа". Если вы договорились, что у каждого хоста есть ansible_host и внутри там обязательно IP-адрес, то вот он. Никакого setup. Бери и используй. Прелесть ansible_host с IP-адресом трудно переоценить, потому что, помимо "какого-то IP соседа", этот адрес ещё неявно (явно!) отвечает вам на вопрос, какой из IP-адресов сервера является его "access address" при наложении всяких файрвольных правил, конфигурации доступов и т.д. Делайте так. Это хорошо и удобно. … Но тут может возникнуть вопрос: а если у нас сервера появляются на свет динамически, или у нас внешная система оркестрации (а-ля докер) у которой точно есть хороший DNS? Ну, тогда используйте их. А, заодно, страдайте, если вам понадобились IP. Разумеется, к любой общей рекомендации всегда можно найти частные исключения. Инвентори: ansible_user Следующая интереснейшая проблема: надо ли в инвентори хранить имя пользователя? Это важный вопрос, но у него нет однозначного ответа. Вот набор моментов, о которых надо подумать перед выбором.
В моей практике (и обстоятельствах, в которых я работаю), мне удобно указывать ansible_user для "себя" (т.е. инвентори, к которыми работаю только я). Если инвентори используется более одним человеком — ansible_user используется только для специальных случаев (например, доступ к коммутаторам при первом провизе и т.д.), а обычные хосты ansible_user не используют. Группы Как только мы начинаем обсуждать группы, мы уже обсуждаем не только и не столько "что должно быть в инвентори", сколько онтологическое понятие "группы". Это тонкий хрупкий мир архитектурного Ансибла, где одно неловкое движение оставляет от красивого замка колючие обломки. Группы — очень сильный механизм в Ансибл, но его неправильное применение может очень сильно всё поломать. Для чего использует группы Ansible? Во-первых, группы используются как встроенные "списки хостов" (в переменной hosts в play и внутри магического словаря groups). Во-вторых, группы предоставляют групповые переменные, наследуемые хостами из группы. В целом, технически, можно писать плейбуки используя только переменные (вы можете использовать в hosts переменные, если переменные хотя бы одного хоста были инициализированы). Но, разумеется, так делать не надо. А надо использовать группы. Для чего вы используете группы (почувствуйте разницу — использует Ансибл, используете вы):
Первая задача самоочевидная, ей пронизаны все примеры, так что пропускаем. Вторая задача — общие переменные. Про переменные мы говорим потом, а пока скажем, что отдельная группа с настройками (группа, для которой нет play) — это не самая плохая идея. Даже, наоборот, отличная идея. Так что основной фокус будет на семантику. Группа — это возможность дать общее название нескольким серверам. До этого у вас были сервера jc-r4, xcore-lu1 и ams1-se-r2, а теперь появилось имя "netflow_collectors". Насколько у вас увеличилось понимание зачем эти сервера? Я бы сказал, что до появления имени группы, это были просто буковки, а после появления имени, вам даже в содержимое ролей не надо заглядывать, вы плюс/минус и так знаете, что эти сервера делают. Имена групп позволяют наделить смыслом инвентори. Человек, который читает инвентори уже видит не просто список хостов с машиночитаемой информацией, а некий рассказ — у нас есть сервера такого типа, сервера такого типа, а ещё у нас есть группа серверов, у которых есть доступ в базу данных. А есть группа серверов с включенным эникастом. Другими словами, инвентори с именами групп — это рассказ про ваш проект. Если ваши имена невнятные или ничего не рассказывают, то и рассказ у вас получается в стиле "этот к тому и так его что тот аж туда". Имена групп — это первый проблеск смысла в вашем проекте, который встречает читающего. При этом группы — это компромисс между инвентори и play. Дело в том, что play накладывает требования на инвентори (хочешь получить запущенным докер — положи хост в группу docker). Но инвентори может добавлять свои группы, которые не используются в play (те самые группы для переменных), использовать наследование, то есть мягко корректировать ожидания play. Отдельно надо рассказать про наследование. Наследование устроено просто — одна группа может быть потомком другой группы. Вот пример простого наследования: ---
foo: hosts: foo1: foo2: bar: hosts: bar1 foobar: children: foo: bar: Наследование — это инструмент инвентори и только инвентори. Никогда play не должна полагаться на какое-либо наследование. (Вы не поверите, но между моментом, пока я написал эти строчки и моментом, когда я опубликовал эту статью, я исправил свою же ошибку, в которой плейбука неявно полагалась на то, что группа grafana-servers является потомком группы mons — а я как раз сделал её потомком группы mgrs в новой версии инвентори). Наследование позволяет передать ещё кусочек семантики "мы размещаем mgrs на хостах mons" в явном виде. Это одновременно и механизм DRY (do not repeat yourself, один из принципов хорошей разработки) для инвентори, и ещё один метод более выразительной передачи смысла читателю. Немного о динамических группах и динамических инвентори. Динамическая инвентори — это результат исполнения какого-то кода, выдающего на выходе "обычную" инвентори. Динамические группы создаются модулем group_by или модулем add_host внутри плейбук. Есть ситуации, когда они оправданы. Например, у вас инвентори всегда генерируется роботом (третий вариант в разделе ниже). Или, вы не хотите загромождать инвентори второстепенными группами, формирующимися по специальным правилам. Такие ситуации есть, но они — очень пограничный случай. Если можете избежать — избегайте, потому что они несут с собой несколько фундаментальных минусов. Например, динамические группы не позволяют нормального --limit. Вам надо выполнить таску group_by, а для каких хостов исполнять не понятно, т.е. мимо --limit оно пролетает. Возникает особый культ тега [always], потому что любая попытка использовать теги натыкается на отсутствие динамических групп. Вообще, group_by — это момент, когда плейбука начинает диктовать вместо inventory что у вас в инвентори. Ой. Динамические же инвентори делают невозможным воспроизведение проблемы, если источник инвентори "дрожит" (т.е. меняется от запуска к запуску). Вы же помните, что список хостов в группе — это на самом деле словарь? Далеко не все языки программирования сохраняют порядок в словаре (в Питоне это называют "словарь", в других языках это hashmap, map, object, и т.д.). Более того, даже в обычном Питоне порядок сериализации элементов словаря не определён. Ансибл специально прикладывает усилия к тому, чтобы порядок хостов в группе соответствовал порядку перечисления в инвентори (начиная с 2.4 даже есть специальный параметр play: order, дефолтное значение которого inventory). Когда это портит жизнь? В тот момент, когда:
Эти проблемы устранимы, но если у вас инвентори "дрожит", вам приходится с этой дрожью бороться. Второй источник боли для динамической инвентори в некотором пофигизме отдельных механизмов. Например, если у вас инвентори создаётся из содержимого региона openstack'а, то если вы случайно оставили в переменных среды окружения более высокоприоритетную переменную для подключения к Openstack, чем то, что вы используете обычно, то вы получите вывод другого региона или тенанта. (если вы получаете ошибку, всё, проблема обнаружена — я про ситуацию, когда изменение "прокатило"). Вам выдали другой комплект хостов. Один раз. В следующий раз (в соседней консоли) всё будет хорошо. Вы пошли куда-то сделали что-то. Возможно, фатальное. Возможно, записав пароли к продакшен базе в staging сервер. Или вообще, куда-то в публично-доступное место. Боль-боль-боль, а главное, никаких шансов на адекватную отладку. Инвентори-то динамическая. Аналогично вас ждёт боль и неожиданное, если у приложения расслабленная модель обработки ошибок. Нет каких-то данных из-за временной ошибки? Ок, пускай будет "пусто". Что такое пусто? Ну, пусть будет пустой словарь. Ррр… аз, и у вас в списке клиентов базы данных пусто. Вы берёте и пишите в конфиг СУБД новый список разрешённых IP, в котором никаких клиентов нет. Чпок, даунтайм. При следующем прогоне Ансибла всё опять поднялось. Виноваты программисты, а отлаживать вам. Именно по этой причине я, в проекте, где инвентори формируется роботами, я эту инвентори не использую как инвентори, а сохраняю в файл, который объявлен артефактом для джобы. Это не решает всех проблем, но, по-крайней мере, есть бумажный след случившегося. Инвентори: переменные Последняя составляющая инвентори — это переменные. Поскольку внутри инвентори могут быть и хосты и группы, все переменные в инвентори являются либо переменными хоста, либо переменными группы. Оба вида переменных одинаково доступны в play и ролях, разница между ними (кроме эргономики DRY) проявляется при определении, какие переменные "важнее" (variable precedence). Вопросы приоритетов переменных и области их жизни мы будем обсуждать в следующей части, а в этом разделе фокус будет на том, какие переменные класть в инвентори, а какие не в инвентори. … И это нас подводит к другому вопросу: что есть инвентори? Давайте сделаем шаг наверх и попытаемся описать структуру проекта на Ансибле общими терминами. У нас есть плейбуки — это код и данные. У нас есть инвентори, которое в нормальном режиме содержит только данные (игнорируем лукапы и программирование на jinja). Мы объединяем плейбуки и инвентори и получаем рабочее "нечто". Как это "нечто" называется? Кто-то это может назвать "инсталляцией", кто-то "средой", кто-то "стейджем". Точное название не важно (хотя я буду использовать "инсталляция"). Важно, что комбинация инвентори и плейбуки делает конкретные вещи на конкретных серверах (даже если эти сервера появляются на свет в процессе исполнения плейбуки и умирают в по окончанию). Плейбука описывает что делать, а инвентори — где делать. Плейбука контролирует взаимоотношения между "участниками" инвентори. В ассортименте делегация, списки, изменение ansible_host, заглядывание в hostvars и т.д. (я не говорю, что это хорошо, но может быть). Инвентори в свою же очередь контролирует плейбуку посредством переменных и разной группировки хостов. Но не смотря на возникающее взаимопроникновение, нужно сохранять принцип, что плейбука (и её переменные) это "что", а инвентори (и её переменные) — "где". Чем меньше эта граница размывается, тем легче сопровождать проект. … Если бы было всё так просто. Например, пароль в базу данных, очевидно, является объектом инвентори (исходя из best practices, что переиспользовать пароли — зло, и мы хотим на каждую инсталляцию иметь свой пароль). В логику "где" это совсем не укладывается, так что инвентори, это не только указание на то, где выполнять, но и все отличительные особенности инсталляции. Название "отличительные особенности" мне нравится своей ёмкостью. Мы перечисляем в инвентори чем одна инсталляция отличается от другой. С применением DRY список отличий должен быть настолько малым, насколько можно, а все производные — вычисляться где-то в другом месте. Попробуем применить этот принцип на практике. Вопрос: Объём памяти, выделяемый под java-приложение должен задаваться в инвентори или внутри плейбуки, которая это приложение настраивает? Ответ: если разные инсталляции должны иметь разный объём памяти, и мы не можем определить его автоматически (например, по числу хостов в группе), то это переменная для инвентори. Если объём памяти — это результат изысканий специалиста и он должен быть одинаковым в staging и production, то это переменная для роли или плейбуки. Вопрос: номер порта на localhost, на котором слушает приложение (сверху там nginx в режиме proxy_pass), это переменная плейбуки или инвентори? Ответ: это переменная плейбуки, если нет специальных причин делать эти порты разными между инсталляциями. Вопрос: список пользователей — это переменная плейбуки или инвентори? Ответ: зависит от того, разный у вас список пользователь между инвентори или нет. Если разный, то это переменная инвентори, если во всех инсталляциях список пользователей одинаковый — это плейбука. Надеюсь, это даёт некоторую интуицию по переменным инвентори. Основной вопрос, который надо себе задавать: "почему эта переменная должна быть в инвентори"? Другими словами, инвентори — это специальное место для перменных, и вам нужны специальные причины записывать их туда. Происхождение инвентори Есть ещё один аспект инвентори, про который редко говорят. Кто пишет инвентори? Общего ответа тут нет, так что я расскажу "как бывает". Первый вариант — инвентори жёстко привязана к репозиторию с плейбуками. У вас есть production.yaml, staging.yaml, или даже каталоги инвентори production/ и staging/, или же у вас пять регионов, и каждый имеет свою инвентори. В этом случае развитие (изменение) инвентори происходит одновременно с развитием плейбук. В этом случае для вас "происхождение инвентори" звучит странно. Вы придумываете себе схему именования инвентори и правил работы с инвентори и всё хорошо. Это случай обычного инфраструктурного проекта, который пишут и сопровождают одни и те же люди. Это же случай, когда вы пишите "для себя" (конфигурация лабораторий, стендов, конфигурация плейбук для сайта вашей компании, etc). Второй вариант — инвентори пишут другие люди. Где-то там есть git с плейбуками, и может быть, с примерами инвентори, а где-то есть другой git с инвентори. Такая ситуация часто бывает, если разработка и эксплуатация различаются. Все крупные проекты по развёртыванию чего-либо (ansible, ceph, openshift, etc) пишутся в этом режиме. Пишет одна группа, эксплуатируют разные другие группы. В этой ситуации инвентори становится подобием API, интерфейсом между кодом плейбук и "конфигурацией" инвентори. У меня есть ощущение, что апстрим Ансибла не особо думал про этот случай, потому что тут бывает очень много трудных моментов, но в модели разработки с разными группами людей, это неизбежно. Ключевым моментом плейбук в этом случае является обеспечение минимального уровня связности с инвентори. Чем меньше, тем лучше. (И именно тут, на уменьшении связности, Ансибл не очень хорош). Ещё этот вариант приводит к понятию "сценария" — у вас один и тот же код (плейбуки) может использоваться в самых разных ситуациях, которые покрываются разными участками плейбук или одни и те же таски имеют разный смысл в разных ситуациях (сравните, например, развёртывание ceph-ansible'а в контейнерах ради RGW в динамической среде приложения или на бареметал в роли хранилища бэкапов на века). Третий вариант — инвентори пишут роботы (или другие плейбуки). Это подмножество предыдущего варианта, но с ещё более жёсткими ограничениями. Развёртывание среды для тестов в CI с генерацией инвентори — один пример. Другой — использование ансибла для управления слейвами последователями в системах со встроенной оркестрацией. В такой ситуации структура инвентори перестаёт ориентироваться на человеков и начинает служить нуждам машиночитаемости — удобства генерации, отладки, модульности. Можно забывать про DRY, про выразительность и семантику. Зато надо быть очень строгим по типам и наличию значений. Пишут роботы для роботов. При работе над проектом надо для себя точно определить какие варианты вы хотите делать. Одно дело, когда у вас инвентори — это 3000 коммитов за 10 лет эксплуатации, другое дело, если инвентори — файл, который создаёт одна плейбука для другой плейбуки на время жизни джобы на CI. Составные инвентори Есть ещё один режим работы с инвентори — это составные инвентори. Я сомневался писать про них или нет, но, раз уж я посвятил целый раздел только инвентори, видимо, писать. Ансибл поддерживает больше одной инвентори. ansible-playbook -i inventory1.yaml -i inventory2.yaml play.yaml
Содержимое инвентори объединяется по принципу "последний побеждает". Первый-второй уровень объединяется (группа состоит из хостов из первой и второй инвентори), дальше перезаписываются последней инвентори (например, если inventory2.yaml даёт users: [...], то она будет перезаписывать аналогичную из inventory1.yaml). Где это полезно? Например, если у вас часть данных динамическая, вы можете иметь одну инвентори динамической, а вторую статической. Второй момент: инвентори поддерживает переменные в файлах (host_vars/, group_vars в каталоге с инвентори). Если у вас инвентори пишут роботы, то вы (как авторы плейбук) можете подкладывать дополнительные переменные инвентори в чужую инвентори (робота). Edge case, мягко говоря. Это точно не "основы Ансибла" и плюсы/минусы применения такого подхода надо взвешивать очень внимательно. Основное, что нужно помнить, что чем сложнее у вас связи в проекте, тем ближе вы к предельному состоянию проекта на Ансибле, который пишут долго и старательно, соблюдая второй закон термодинамики. Это предельное состояние называется "комок слипшихся макарон". И вы этого не хотите. Навигация:
=========== Источник: habr.com =========== Похожие новости:
Настройка Linux ), #_sistemnoe_administrirovanie ( Системное администрирование ), #_oblachnye_vychislenija ( Облачные вычисления ), #_servernoe_administrirovanie ( Серверное администрирование ), #_devops |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 19-Май 10:11
Часовой пояс: UTC + 5