Comments 44
Очень, очень долго, и по ощущениям, в прицелом в ограниченную аудиторию. Вот, консалтинговая фирма, расскажите мне про пример. Допустим, мне нужно поднять простенький load ballancer. Это, допустим, комбинация nginx, bird с примесью ovs'а.
И нужно сделать простые операции: выкатить nginx известной конфигурации, выкатить bird известной конфигурации, настроить правила ovs'а, сходить на TOR, сконфигурировать BGP.
И вот вы тут выпекли образ. В нём у нас все конфиги и всеобщее счастье. Осталось только выпечь TOR. А TOR — он такой прямоугольный, и у него в спецификации написано, что диапазон рабочих температур — не выше 60°С. И как вы его выпекать будете?
И куда не пойдёшь, всюду такие исключения. Начиная с сервера СУБД, который нельзя просто так "дропнуть и пересоздать" (даже если есть реплики), и заканчивая (условным) k8s, который тоже как-то нужно раскатывать.
Ansible очень ограничен как оркестратор. Он совсем не оркестратор. Да, на нём нельзя писать логику принятия решений. Но это очень, очень хороший инструмент для выполнения сайд эффектов.
как вариант на ТОРе можете запечь BGP Dynamic Neighbors
p.s. я не консалтинг есличе
II — это не парадигма, это один из приёмов. II прекрасно подходит к задачам, в которых состояния либо нет, либо оно best efforts, либо маленькое.
Ну, например, как вы себе представляете II для (условного) Cern? (Это который данные с большого адронного коллайдера петабайтами сливает на гиперогромный ceph). Огромное количество discardable-кусочков, но в целом вся инфраструктура — живая и с процессами, которые длятся месяцами, не то, что "иммутабельная".
Ближайший сервис с платёжными данными, и вы не можете быть II. Потому что вам надо делать апгрейды СУБД, причём, возможно, в онлайне.
Ближайшая ГЭС имеет компьютеры, которые, мягко говоря, не являются II, и которые такие snoflakes, по сравнению с которым кобольная база 1970 года кажется детским лепетом.
Короче, II — это один из приёмов уменьшения сложности. Правильно применяете — получаете улучшение. Применяете везде и всегда — получаете недоумение и проблемы.
Насчёт TOR'ов тоже всё просто. Теория говорит, что если там избыточность, можно выкинуть и новый накатать в режиме II. Реальность же говорит, что никакая избыточность не решит проблем состояния, которое, внезапно, у TOR'а довольно большое.
Просто for fun, посмотрите, что будет, если во время DoS атаки отключить порт на который идёт атака и сравнить "отсутствие состояния" до выключения и после.
Какой у них там копьют кластер по архитектуре я не знаю. При желании, это тоже можно организовать должным образом с переносом состояния.
Легаси системы на то и легаси. Смысл их вообще обсуждать.
А про базы я даже и не говорю. Автор там вообще про какие-то вольюмы и распределенные системы под низом рассказывает. Чушь и детские забавы, уж простите, а не база данных. Если базы такие простенькие, то конечно можно упарываться II сколько влезет с ними.
ИИ подразумевает, что мы можем пойти и пересоздать инфраструктуру в любой момент времени. data lakes говорят, что даже изменения настроечек (ceph tell mon ....) могут занимать недели (если не месяцы), и ни о какой immutable речи идти не может.
Я не люблю нетапп, но приговорка их сейлзов — сущая правда data have gravity.
Хотя на самом деле мой поинт был, что ИИ — это всего лишь приём, а не методология. Он применим иногда, и не может быть универсальным. Ровно так же, как нельзя создать компьютеры, которые будут только чистыми функциями заниматься, ровно так же нельзя иметь инфраструктуру без состояния.
вообще, меня недавно пробило на "подумать над обобщением жизни",
https://amarao.dreamwidth.org/9493.html
И там как раз у меня и объясняется, в чём разница между программистским подходом к восприятию реальности и инфраструктурным.
А что такое TOR в этом контексте? Из 2024 это всё еще The Onion Router, для обхода блокировок РКН например.
В остальном... вся эта облачная тема и cattle - прям страшная вонь того, как индустрия катится куда-то не туда.
Да и документация не нужна как класс, раз кто-то может залениться в нее записать. Так?
Ну и опять же вопрос — пачку серверов в AWS чем конфигурить? Руками? А если их 100? А если 1000? А если это (о боже!!!) не кубернетис и не микросервисы? И опять мы вернемся к тем вопросам, которые в самом начале статьи признаны неважными:
ansible vs chef?
ansible vs puppet?
и т.д. =)
Даже если не ansible, то какую-то другую систему управления конфигурациями придется освоить.
Зачем учить ансибл, когда в userdata можно всё на баше! Там же совсем чуть-чуть. И не надо вашего противного ансибла, 800 строк на баше не так уж страшно!
/сарказм
Зачем учить ансибл, когда в userdata можно всё на баше!
Кстати да. Если ansible такое хорошее средство накатывания конфигурации, то почему в докерфайлах не он, а bash?
Вообще говоря, в докерфайлах и анисбл тоже. Использование же баша в докерфайлах (чья структура лично у меня вызывает глубокое офигевание примитивностью) во многом объясняется тем, что у баша минимальный boilerplate. У вас есть переменные окружения — поехали код писать. Это особо востребованно в докерфайле, где у вас "одна команда на весь run'. && — это уже выражение баша и без него вторую команду вы в тот же слой уже не напишете.
Вторая причина — всеобщая доступность, сохраняющаяся не смотря на shellshock. Лучше уродливое что-то, что есть всюду, чем shiny new, которое есть иногда.
В целом, баш в однострочнике весьма разумен. Я же не зря написал про 800 строк. Где-то на втором уровне вложенности (ИМХО даже на первом) баш перестаёт быть разумным и становится старым ужасным языком программирования с ужасными дефолтами, для использования которого правильно нужен человек с десятилетиями опыта программирования на баше.
Вообще говоря, в докерфайлах и анисбл тоже.
Неужели кто-то так делает? Вы не скажете, где можно поглядеть?
Использование же баша в докерфайлах (чья структура лично у меня вызывает глубокое офигевание примитивностью)
У меня тоже. Сколько говорили, про то, что конфигурацию надо делать как код и админы должны быть немного программистами, а программисты должны оставаться программистами, даже когда админят. Сколько было разговоров про то, что шелл скрипты это ужасное прошлое, рассчитанное на один successfull path. И что в результате? В результате баш опять везде. Как так вышло то? Ведь вроде признали, что это не правильно.
Вторая причина — всеобщая доступность, сохраняющаяся не смотря на shellshock. Лучше уродливое что-то, что есть всюду, чем shiny new, которое есть иногда.
Почему когда переходили к Ansible, все над этим аргументом только смеялись? Серьёзно, я чувствую себя обманутым. Мне столько рассказывали, что нужно использовать Ansible, что я в конце концов уже отказался от планов изучить баш.
Но как только я начал освоение Ansible, оказалось, что весь мир в один день начал использовать докерфайлы на баше. Как так то? Что случилось о том, что к конфигурации надо подходить серьёзно и баш для этого не подходит?
Неужели кто-то так делает? Вы не скажете, где можно поглядеть?
werf так делает https://ru.werf.io/documentation/v1.2/advanced/building_images_with_stapel/assembly_instructions.html#ansible
Но никто не мешает вам сделать
ADD some_playbook.yml
ADD ansible.cfg
ADD inventory
RUN apt-get install -y ansible
RUN ansible-playbook some_playbook.ymlДелают. В паблике нет (или я не знаю). В целом, вы же понимаете, что нет разницы, что в мультистейдже какой-нибудь mezon запускать или ансибл. Основная проблема — нужен обязательный multistage, потому что ансибл с питоном слишком толстый для приличного образа.
Я повторю, баш с нами, потому что для 1-2 строк ничего лучше не придумали. Там, на самом деле, часто и баша-то нет, только команда и переменные.
Плохой баш начинается где-то в районе if, функций, трапов, массивов и т.д.
В докерфайлах есть тонкий момент — они не замена ансиблу. Где-то над ними у вас либо ансибл, либо compose, либо swarm, либо k8s. Связывать вместе все эти приложения кто-то всё-таки должен.
Я не могу говорить за всю индустрию (в отличие от авторов этого поста), по этому могу сказать, что у нас на работе ансибл есть и его становится всё больше, по мере нарабатывания успешных практик (включая поддержку сценариев в молекуле и хорошей интеграции с testinfra).
Плохой баш начинается где-то в районе if, функций, трапов, массивов и т.д.
И примерно таким же башем написан докерфайл для СУБД Оракл, например. Про кофигурацию не на баше похоже забыли как про страшный сон.
В докерфайлах есть тонкий момент — они не замена ансиблу.
А замена только тому сценарию использования ансибла, которая конфигурирует приложения? Так выходит?
Где-то над ними у вас либо ансибл, либо compose, либо swarm, либо k8s. Связывать вместе все эти приложения кто-то всё-таки должен.
Очень хорошо и понятно написано, спасибо! Но compose же прокидывает порты и настраивает что-то вроде внутренней сети между контейнерами. k8s и swarm тоже такое делают. Вы хотите сказать, что с помощью ансибла можно всё это сделать, пусть это и не специализированный инструмент? Или, что это один из юскейсов под которые ансибл делался?
Ну, я рад за них. Можно ещё autotools принести, чтобы нубы не расслаблялись.
Вообще, с докерами есть две школы: конфиг в докерфайле и конфиг приходит снаружи. Если конфиг в докерфайле, то где-то описано в какие имаджи какие конфиги класть. Это может быть, например, CI. В этой ситуации вы заменили один ямл (ансибла) на другой ямл (условного гитлаба). И поверьте мне, ямл ансибла куда более разумная вещь.
Второй вариант — конфиги приходят снаружи. Либо из оркестратора с etcd и его подобиями (консул), либо кладутся (кем? чем? Ну вы поняли). Если k8s, то там своя религия с helm'ом и т.д., если это compose, то кто compose-файлы генерирует?
В целом, универсальных ответов нет. Разные обстоятельства требуют разных инструментов. Я, например, работаю в хостинговой компании, так что 90% хипстерских инструментов (предполагающих, что грязную работу по начальной настройке сервера за них кто-то сделал — например, выделил IP адреса, аллоцировал их на сетевом оборудовании, настроил аппаратные рейды или собрал софтовые, настроил бондинг и т.д.) просто не применимы или применимы весьма ограничено.
А если нет универсальных ответов, то мы попадаем в царство инструментов. Некоторые инструменты приносят много полиси и это плохо (потому что полиси может мешать свободному применению). Некоторые инструменты приносят много инструментации мало полиси (и это хорошо, потому что из них можно собирать удобное решение).
Как по правильному конфигурировать 1000 серверов в AWS без kubernetes?
А что вы конфигурируете на 1000 серверах одновременно?
Например, конфигурацию конкретных приложений. Или (если это не докер-контейнеры а VM) параметры ядра (/proc/sys/net/*).
Пересобирать и перезаливать образы после таких изменений — долго и менее эффективно, в отличие от точечной перестройки и рестарта приложений (если он вообще требуется — обычно всё подхватывается на лету), не говоря уже о случае когда подстройка происходит штатно, т.е. периодически как реакция на текущее состояние или требования.
Если меняется конфигурация конкретных приложений, то скорее всего, это происходит не на 1000 серверах, а на количестве гораздо меньшем.
Если даже их "всего" 100 то всё равно ручками не особо удобно. Простой пример — что-то вроде частично (или даже полностью) managed VPS, у каждого свои локальные заморочки (т.е. нет одного образа) но в то же время много общего — как это накатывать без чего-то типа Ansible/Puppet? А их реально могут быть тысячи.
Да и вообще любое изменение которое можно накатить онлайн без прерывания сервиса — лучше накатывать онлайн, soft reload всегда быстрее чем пересборка с перезапуском, в этом плане правильные DSC очень сильно помогают — потому что они производят минимально необходимый (и минимально беспокоящий — насколько возможно) набор изменений для приведения конфигурации (всей системы или её частей независимо) в нужное состояние, а в худшем случае их поведение эквивалентно новой сборке и развёртыванию.
как по мне это типичный кейс для иммутбл инфры. SCM обычно нужен, когда надо менеджить приложения со стейтом. Но в облаках и правда непонятно зачем ansible.
Запекаешь образы packer'ом, разворачиваешь их через terraform, pulimi на виртуалках. Все как с контейнерами. Приложеньки со стейтом, обычно есть как готовые сервисы в облаке, их также готовишь через pulimi/terraform.
Хаос появился как раз с популяризацией Ansible, которая обусловлена более низким порогом вхождения: вместо единой конфигурации имеем множество «ролей», которые позволяют обособленно делать различные изменения с одним и тем же инстансом.
Однако даже в среде с puppet может пригодиться ansible =). Самое очевидное — раскатка puppet-агентов =). И как раз необходимость раскатки агентов отпугивает часть людей, которые выбирают себе систему управления конфигурациями.
Очень странное завершение мысли.
В шефе ручные изменения выглядят так: "чпок" и шеф заткнули перед ручными работами. Главный страх же — не в том, что придёт и исправит, а с тем, что будет race между изменениями шефа (неожиданными) и текущей работой. Я растарчу сервис, в этот момент шеф его рестартит, всё сломалось.
Ансибл дал большую предсказуемость.
Роли — вообще не при делах. Возможно, вы хотели сказать "плейбуки"? Да, есть такая проблема — можно иметь пачку плейбук, каждая из которых только кусочек делает.
Но, на самом деле, это и оказалось киллер-фичей ансибла. Потому что иногда нам надо "поправить только это" (декларировать пользователя, например) не задумываясь про остальное состояние. В шефе от этого страдания.
Используйте saltstack, там нет страданий
с «ломают обратную совместимость» не сталкивался.
Если рассматривать Salt как декларативный конфигуратор, то вот это странно слышать:
2. Нет версионности для стейтов. Внес изменения, выкатил их, захотел откатить — и вот тут начинаются танцы с саблями, штатных средств нет.
4. salt не отслеживает, какие файлы он создал. Если вы создали файл в стейте, а в следующей версии этот файл должен отсутствовать вам надо добавить явную логику по удалению этого файла, salt не может этого сделать автоматически.
остальное субъективщина: «сложна отладка,salt не удобен, много питоновской магии»
Отслеживание созданных ресурсов и автоматическое удаление тоже очень удобно и могло бы сэкономить объем стейтов а также предотвратить некоторые досадные ошибки.
Отладка выглядела так:
- меняем стейт
- применяем
- стейт не работает как надо
- запускаем salt-ssh с расширенным логированием
- вычленяем команду, которая запускается на удаленном хосте
- логинимся на удаленный хост
- запускаем там отредактированную команду, вычлененную ранее из логов (чтобы вывод не шел в /dev/null)
- из вывода пытаемся понять, в чем проблема
- переходим на 1
Насчет «много питоновской магии» говорю не голословно. Как я упомянул мне пришлось ловить очень неприятные race conditions и это было ох как не просто. У меня есть знакомый гуру питона, который посмотрев на код сказал, что хуже он не видел.
А так то да, субъективщина.
Я не видел saltstack, но видел мигрантов с него.
С ансибл все так на самом деле, это очень хороший инструмент для своих задач. Что-то не так с людьми которые постоянно пытаются натянуть его на глобус и вколачивать его вместо терраформа или баша.
Главное, куда пытаюстся вколачивать ансибл — это на роль оркестратора. Если бы была какая-то штука как куб, но без кубовой "контейнероцентричности", то все бы писали ему операторы. Но такой штуки нет, и часто этот функционал реализуют на ансибле (с кровывами последствиями для тех, кто этот код сопровождает).
И это показывает адопцию cloud в России. Потому что в России только сейчас появляются более-менее серьезные игроки, на которые уже можно начинать полагаться.
Не вижу взаимосвязи — мало пользуется облаком — несерьезный игрок.
Почти весь финтех живет не в клауде а в собственных датацентрах, где могут и aws сервисы он-премисес развернуть, а могут и не развернуть, потому что security audit важнее удобных devops утилит.
При этом это вполне серьезные игроки, из топ-100 по обороту в мире.
Немного за уши притянуто решение проблемы.
Почему я советую людям не учить Ansible. Переход с Configuration Synchronization на Immutable infra. Андрей Девяткин