Comments 30
Транспорт ансибла - blessing & a curse. Каждый раз, когда "медленно", к нему прикручивают "быстро" (hello, mitogen). Каждый раз, когда прикручивают быстро, возникает желание вернуться на ванильный ансибл, потому что "точно работает".
Все создатели всех систем конфигурации ради удобства архитектуры сделали неудобно в эксплуатации. Точнее, не неудобно, а "шероховато". Условный ансибл способен прорваться через любую бездну. ssl proxy с терминацией на jump хост? Без проблем, только чуть медленее. У каждого сервера свой номер порта, и IP'шник, который плавает? Без проблем, динамическое инвентори твой друг. Можно даже и на уровне плейбуки подвигать ansible_host/port.
Транспортный уровень ансибла медленный, но работает как танк с ковшом бульдозера. Всюду проедет, всё может. Но, да, за гоночной машиной ему не угнаться.
Сейчас сага со вторым питоном ещё не закончена, но когда закончится, исчезнут все следы старья, и будет просто: есть ssh и питон - ансибл работает. Есть ssh - ансибл работает, но не так удобно. Нет ssh, но есть хоть что-то для cli? Чуть-чуть подфигачить молотком и ансибл работает.
Ни одна система управления даже близко не подошла к этому уровню универсальности.
Ансибл - это не система управления конфигурацией.
Это тул для автоматизации. Да, он может быть использован как SCM. В частности - если речь про установку пакетов на одиночную машину. Но оркестрация на нем - это мрак. Посмотрите хотя бы на kubespray. Нет, никогда в жизни, увольте.
SCM - это папет и Солт, простите. Причем у папета еще относительно вменяемая объектная модель есть. Объектна модель и ансибл? Не смешите мои тапочки...
Я плохо видел солт и паппет, но наблюдал chef в самом кровавом режиме (когда на нём пытались описывать всё, включая квантовую физику на коммутаторах), и там я понял, что ни одна из систем этого поколения, на самом деле, не подходит, в основном из-за слабой типизации данных.
Есть тайная мечта узрить хороший язык конфигурации с фашизмом уровня rust (ownership, traits, generics), но пока я вижу jinja в момент принятия решения - на этом нельзя писать надёжный код. Можно более-менее делать сайд-эффекты, да, но не решения, особенно, с трансляцией в уровень исполнения.
В этом смысле Ансибл, который и не пытается (в отличие от ряда его пользователей) - разумный компромисс.
И нет, у меня нет в ассортименте хорошего инструмента для оркестрации. Ни одного. Я страдаю.
Я согласен про строгую типизацию и прочее и хочу заметить что Соль идет в эту сторону в проекте под названием Idem. Нам нем сейчас переписывают небольшой кусок, но в перспективе это позволит писать значительно более надежную логику.
Пока что мы живем за счет сильного CI с проверками каждого куска логики
Есть тайная мечта узрить хороший язык конфигурации с фашизмом уровня rust (ownership, traits, generics)
Посмотрите Dhall.
Посмотрел. На этом невозможно писать в продакшене. Даже если в компании образуется админ-хаскелист, то он будет писать это в гордом одиночестве и оно сдохнет.
Кроме того, проблема же не столько в типах данных для шаблонов, сколько в описании конфигурации, т.е. возможность введения разумных сущностей DSL'ного порядка. Выделываться с map/fold, кстати, можно и на jinja, с меньшим успехом, правда, но можно. И оно никогда не решает проблемы конфигурации.
Главного, что не хватает, это хорошего DAG-подобного языка с ясным описанием ввода/вывода стейджей, зависимостей между ними и т.д. Есть consourse, который почти хорош, но без фашизма и без нормального single mode (только серверный). Есть миллион клонов make, которые все хотят файлы, а не абстрактные сущности.
Мне бы хотелось что-то такое:
impl VM for guest<libvirt<kvm>>{
...
}
impl VM for guest<openstack<mytype>>{
...
}и т.д. Я не до конца понимаю, где проходит разумная грань между "программируй" и "описание инфраструктуры", но мне точно хочется, чтобы до сайд-эффектов мне ругнулись вида
"Can't construct VM for openstack<mytype>, trait AccessIP not implemented for openstack<mytype>" вместо runtime сообщения от опенстека, что FIP не завезено.
Есть тайная мечта узрить хороший язык конфигурации с фашизмом уровня rust (ownership, traits, generics)
cfengine не оно ?
к нему прикручивают "быстро" (hello, mitogen)
Мы очень хотели что бы эта штука взлетела и решила все наши проблемы, но это pet project который не поддерживается RedHat и ломает половину логики.
В остальном я в целом согласен, но ssh транспорт не такой простой как о нем часто думают.
C условной Солью у вас либо есть подключение либо нет и если оно есть то все будет работать. Открыть надо два порта в одну сторону. Работает за натами и прочим.
У нас было много проблем с ssh timeouts, sudo escalation timeouts и тд при работе с Ансиблом.
У нас было много проблем с ssh timeouts, sudo escalation timeouts и тд при работе с Ансиблом.
поддержу. Просто модель у солта совершенно другая. Хочешь ssh - не вопроc, salt-ssh, нелюбимый ребенок SaltStack'а. В целом даже работает.
А вот ZMQ позволяет управлять узлами из-за Ната. Что может быть важно для рестриктед окружений. А ансибл - приходится костылять всякие ssh proxy jump etc.
И большинство из них уже исправлены. Сейчас, обычно, таймаут - признак сломанного коннективити.
Вот что интересно - Кубер активно сжирает сейчас весь рынок SCM... По крайней мере для новых проектов - он прекрасно заменяет ансибл (описание конфигурации + деплой + что-то еще)
Не совсем так. Куб решает другого рода задачи. Он "ест" проблему сверху, заменяя парадигму эксплуатации. Если приложение ложится на кубовую архитектуру и компания готова терпеть вытекающие из него расходы, то ок, ура, ура. Но куб - это архитектура, это не инструмент. Я бы, даже, сказал, это идеология в первую очередь.
А ансибл, наоборот, никакой архитектуры с собой не приносит - это просто инструмент, как молоток или паяльник.
Согласен. Но дело в том, что куб уже много где есть. И возникает вполне логичное желание - унифицироваться на нем... Что в случае монолитов порождает достаточно странных гомункулов.
куб - это решение.
Например, квартира - это решение жилищных проблем. Большинства из них. Ансибл - инструмент. Как, например, экскаватор. Экскаватор как решение жилищной проблемы звучит странно, однако, не отменяет пользы экскаваторов для людей, которые строят что-то своё.
Возможно, они могут обойтись типовым жильём, но если они строят новый телескоп или стартовую площадку для ракеты, то экскаватор им пригодится, а вот полиси многоквартирного дома начнёт мешать.
SaltStack без особых усилий может обслуживать тысячи нод. При желании он может обслуживать десятки тысяч нод.
Мне удалось заставить salt работать на 10к+ машин. Для этого пришлось переключиться на salt-ssh. Использование мастеров-миньонов было бесконечной болью с крэшами как мастеров так и миньонов. Заставить это работать надежно не удалось. С другой стороны salt-ssh с грехом пополам тянул всю инфрастуктуру.
Язык инструмента казалось бы не должен иметь принципиального значения, но именно в этой сфере он очень важен.
Не могли бы вы раскрыть это утверждение?
В плане отладки SaltStack ведет себя так как бы вы ожидали от обычного приложения на Python.
В случае salt-ssh отладка выглядела так:
- меняем стейт
- применяем
- стейт не работает как надо
- запускаем salt-ssh с расширенным логированием
- вычленяем команду, которая запускается на удаленном хосте
- логинимся на удаленный хост
- запускаем там отредактированную команду, вычлененную ранее из логов (чтобы вывод не шел в /dev/null)
- из вывода пытаемся понять, в чем проблема
- переходим на 1
Не могли бы вы раскрыть это утверждение?
Я думаю, что это важно по двум причинам. Первая - python есть почти везде, что гарантирует хотя бы возможность бутстрапа salt. С другой стороны, в каком-то смысле это же и является проблемой, т.к. фиксация на версии системного python может приводить к несовместимостям, невозможности использовать определённые модули и прочие приключения, которые случаются ещё и с ансиблом. Второе - доработать или разобраться в том, как работает salt, может средней руки админ. У нас был кейс, когда очень долго отрабатывал кейс для создания юзеров. Т.к. код на python и написан адекватно - мы смогли быстро разобраться. Оказалось, что достаточно было доустановить определённый системный пакет и все поехало. Был бы salt на erlang - я даже не знаю, получилось бы решить проблему
Не могли бы вы раскрыть это утверждение?
Да я плоховато его раскрыл.
Я вел к тому что одно из главных преимуществ Ансибла на мой взгляд что его могут подхватить вчерашние сисадмины знающие только Баш. И в целом успешно им пользоватся.
Что бы успешно пользоватся Солью, Папетом и особенно Шефом - надо уметь програмировать на Питоне или Рубях. Хотя бы чуть-чуть.
И то что Ансибл и Соль написаны на Питоне дает им преимущество перед остальными в 2021 году когда Питон давно стал вторым Башем для нового поколения Ops\SRE.
В случае salt-ssh отладка выглядела так:
Мы не пользуемся salt-ssh - не могу прокоментировать. Жаль если так. Вроде бы ребята из Lyft тоже не пользуеются мастером но они делают masterless деплой просто через salt-call -local
Мы не пользуемся salt-ssh - не могу прокоментировать. Жаль если так. Вроде бы ребята из Lyft тоже не пользуеются мастером но они делают masterless деплой просто через salt-call -local
я бы разделил этап разработки и прода. В проде salt-ssh на уже известной инфре прекрасно работал. А вот в момент отладки - я активно не его гонял, а salt-call -local.
И то что Ансибл и Соль написаны на Питоне дает им преимущество перед остальными в 2021 году когда Питон давно стал вторым Башем для нового поколения Ops\SRE.
Спорное утверждение. Мой опыт показывает, что несовместимости между версиями и проблемы с конфликтующими зависимостями зачастую привносят ну очень много проблем. Так что преимущество быстро превращается в очередную боль.
Да, дебаг salt-ssh иногда весёлый бывает. Но во многих случаях можно отлаживать просто через salt-call локально, а если прям нужно понять что сломалось именно в salt-ssh, то есть способ включить нормальное логгирование и забыть о вычленении команд из логов:
Т.к. код на python и написан адекватно
К сожалению это не так. Salt использует очень много питоновской магии. Говорю не голословно, мне пришлось ловить очень неприятные race conditions в salt и это было ох как не просто. У меня есть знакомый гуру питона, который посмотрев на код salt сказал, что хуже он не видел.
У вас опыт негативный - у меня позитивный. 1:1?
Касательно race condition - к сожалению, они возможны в любом коде. Даже на таких «надёжных» языках как Java, rust и golang. Но я представляю себе систему управления сотнями узлов на голанге… с необходимостью перекомпиляции всех бинарников, если понадобится подключить новую архитектуру или плагин. Не, нужно использовать подходящие инструменты.
От вас (не ради стеба, а ради самообразования и возможно Вы кого-то отвадите от ошибок) я очень хотел бы услышать две вещи:
Конкретные примеры проблем (кроме того, что Вы уже написали в сообщении выше про salt-ssh)
Какие альтернативы Вы видите для управления конфигурацией сотен или тысяч узлов? Тот же ансибл с головной машины на 1000 узлов без лимитов и разбивки на батчи точно так же прекрасно выедает всю доступную память и падать. Или работает как маленький слоупочек
Конкретные примеры проблем (кроме того, что Вы уже написали в сообщении выше про salt-ssh)
Вот то, что было самым болезненным: github.com/saltstack/salt/issues/33223
А вот все isues, которые я зафайлил: github.com/saltstack/salt/issues?q=is%3Aissue+author%3Akt97679
У вас опыт негативный — у меня позитивный. 1:1?
Я не могу сказать, что у меня опыт абсолютно негативный. В конце концов у меня все заработало. И если знать, куда соваться не стоит, то солтом вполне можно пользоваться.
Какие альтернативы Вы видите для управления конфигурацией сотен или тысяч узлов?
На сегодняшний день я, к сожалению, не вижу безпроблемного решения. У меня есть опыт работы с chef, salt и puppet. Ни от одного из них я не в восторге.
Соль в целом очень сложный проект с историей.
Там много магии, вендер пинов(не могут смигрировать с Tornado 4.5x уже года три) и большая и грустная история с тем что до 2019 года они принимали плюс-минус любые PR без регрессионых тестов.
Мы тоже активные контрибьюторы и все патчи пытаемся вернуть в апстрим.
Но надо заметить что в Ансибле мы нашли не меньше багов и проблем и до сих пор чешем голову когда вызов крупного template на 50 машинах может отесть до 10Гб ОЗУ на Ансибл контролере.
В целом любая такая система будет сложной особенно если посмотреть на предоставляемый функционал.
Ansible -- единственное решение для интерпрайза.
В договорах на поддержку "аппаратно-программных" комплексов IBM и Oracle (про других не знаю) напрямую говорится, что заказчик несет ответственность за неисправности, вызванные установкой 3rd-party software.
И да, если ваш менеждер поверил вам, что вы легко докажете поддержке, что "этот маленький агент точно не мог вызвать kernel panic", то бегите из этой конторы немедленно.
Ansible -- единственное решение для интерпрайза.
какой-то очень голословный тезис. Salt и Puppet тоже вполне себе энтерпрайз. Напомню, что за первым стоит Vmware, а второй сам по себе разрабатывается одноименной компанией. Я уж не говорю о том, что если рассуждать так - ансибл - это редхат. Значит, редхат несет какие-то гарантии, то нет, это ошибочно и так это не работает (((
вызванные установкой 3rd-party software.
установкой, а не запуском? Точно так же IBM/Oracle могут доказать, что ваш сканер безопасности, который запускается по ссш или просто сканирует порты на IBM/Oracle решениях, лишает вас гарантии?
SaltStack — Темная лошадка систем управления конфигурациями