Комментарии 59
Потому что ансибл не нужен. Я бы сказал, что сейчас за ансиблом стоит редхат со всеми вытекающими, но и шеф, и солт, и паппет тоже коммерческие продукты, если подумать.
Как насчёт того, чтобы выучить матчасть?
Например, в импераптивном ансибле таски исполняются по-очереди, в декларативном же паппете это бессмысленно, так как когда объявляется конечное состояние, очередности тут нет. Оборотная сторона — невозможность переприсваивания переменных
Вообще-то sHaggY_caT прав
Ансибл — это некий движок выполнения задач. Описание задач — декларативно в ТОМ ЖЕ ПЛАНЕ, что и любой язык программирования (никто же не говорит, что python декларативен?). Но по сути — порядок выполнение ИМПЕРАТИВЕН. Идемпотентность — это вообще не в кассу — это может как свойство всего плейбука (но, простите, я и на баше могу писать условный if [[ -e $FILENAME ]] rm $FILENAME или вообще rm -f $FILENAME || true), либо свойство модуля (но под капотом все равно логика, которую я описал на условном баше). Теоретически — никто не мешает на ансибле писать как попало.
Поэтому история с терраформом и паппетом ИДЕОЛОГИЧЕСКИ выглядит вернее. У тебя должен движок сначала выяснять ЧТО должно быть изменено, а далее строить ГРАФ изменений и их применять. Проблема в том, что реальный мир — это не состояние, куда надо придти, а набор состояний и правил перехода между ними. И в том же паппете я хапал очень много боли, когда нужно выйти за рамки подхода "хочу А, Б, В" и приходится описывать именно способ получения этого Б (в частности, если оно может быть получено только после В и чего-то еще).
Помимо того, что нужно "правильно" писать плейбуки — у ансибла еще куча проблем. Начиная с того, что Пайтон экосистема токсична сама по себе (я проводил опрос и большинство фигачат pip install прямо в системное окружение, venv — что это такое !?) и кончая тем, что половина модулей сломана тем или иным способом (господи, реально проще на башне написать, только там скрипты очень сложно отлаживать и юнит-тестировать)
Где вы видите хоть что-то императивное здесь?
это именно, что императивность (на уровне движка). Как условный #include в C++, или вызов функции с аргументами. Реализации модели модульности в ансибле. Ну, или пускай примитивная форма ООП. Как хотите.
Люди не различают движок ансибл как таковой и его модули.
это ко всем относится, и к Вам в том числе. От того, что некто запихнул некий DSL в YAML формат (=плейбуки) — они более декларативными не стали. О чем собственно и речь.
как будем оценивать уровень декларативности для пользователя? Ваш ход.
Где конкретно тут проявляется декларативность терраформа против императивности ансибла?
ну, например, в порядке создания ресурсов? В случае терраформ — насколько я помню, все ресурсы создаются конкурентно, если явно не указан порядок. Я же говорил про граф. Ансибл же тупой — он будет таски все делать по порядку. Что приводит к интересным кейсам — когда я могу в трех тасках подряд, например, создать ресурс, потом удалить, а потом создать заново (я не отрицаю, что иногда ЭТО НУЖНО, но выглядит как косяк "объектной" модели ансибла — слово взял в кавычки намеренно).
Я уж не говорю о том, что если бы я писал на python в ансибл-стиле — это выглядело условно как
from openstack import create_vm_if_not_exist
### создает ВМ, если она не была создана
create_vm_if_not_exist("openstack.cloud.server", "fdfd5d39-a76d-45df-abec-17f768ba3054", security_group:"default", userdata:"", hostname:"instance_1.example.com")но на самом деле нормальная автоматизация выглядит по-другому )))))
Конечно не в кассу, человек не понимает что такое идемпотентность вообще. Это именно свойство модуля, роли и т.д., при чем тут ансибл как движок? Бред какой-то.
Это либо энфорсится целиком для всей экосистемы, как для паппета, либо опционально. Но дело в том, что
N*(идемпотентность) + M*(не-идемпотентность) => не-идемпотентность
(где N и M соотвествующее число модулей)
Ну и ещё раз, сам по себе дизайн ансибла таков, что он описывает процесс а не состояние. Таски можно и асинхронно, конечно, делать, но это не важно. Ансибл не «компилирует каталог»(с)
Если писать ансибл модуль с прямыми руками
Вообще-то речь об официальных модулях
. Начиная с того, что Пайтон экосистема токсична сама по себе (я проводил опрос и большинство фигачат pip install прямо в системное окружение, venv — что это такое !?)
У меня совсем другой опыт. Ну и venv нужен не всегда, например, он довольно хорошо заменяется контейнерами. Или тем более для AWS лябды. И, в общем, с контейнерами или с лямбдами чаще всего тебе больше и не нужен конфигурейшен менеджмент — разве что немного терраформа для EKS/GKE или лямбд.
и кончая тем, что половина модулей сломана тем или иным способом (господи, реально проще на башне написать, только там скрипты очень сложно отлаживать и юнит-тестировать)
Да, с качеством модулей и частотой их сломанности между релизами проблемы. А ещё в ансибл-галактике код почти никогда не работает, в отличие от, кстати, паппетфорджа
общем, с контейнерами или с лямбдами чаще всего тебе больше и не нужен конфигурейшен менеджмент — разве что немного терраформа для EKS/GKE или лямбд.
Это так. Одноразовые контейнеры. Одноразовая инфра. Не понравилось — выкинул — пересобрал. Никакого стейта — значит, проблем по минимуму (есть нюансы). Не готов говорить хорошо это или плохо, но действительно контейнеры заменяют необходимость scm (но нужен оркестратор!) — поэтому salt/ansible/puppet скоро для большинства станут утраченными знаниями. Знания Великих Древних, выбитые в манускриптах покрытых пылью, на задворках интернета )))) Точно так же контейнерные среды убивают необходимость получать фундаментальные знания о слое ОС. О сетях. Об архитектуре ПК. Ничего — живем дальше
как ансибл хранит состояние о развернутых ресурсах?
хранение состояния у терраформа — это его же Ахиллесова пята. Никогда не приходилось чинить tfstate? А строить зависимости ресурсов через null_resource (фу-фу-фу)? А конкурентные запуски терраформа как блокируете? Вот оно и есть.
Я не говорю, что у ансибла нет проблем. Но они другие в массе своей.
Если ансибл не нужен, то что использовать?
Иначе не совсем понятно почему есть провижинеры Chef, Puppet, Salt, но нет Ansible
Ну вообще то уже отказываются
The built-in vendor (third-party) provisioners, which include habitat, puppet, chef, and salt-masterless are now deprecated and will be removed in a future version of Terraform
А что взамен? Т.е. хочется понимать логику такого шага и последствия
Консул (как источник конфигурации) и консул темплейт (как способ доставки)? И все в пределах стека хашикорпа. Они очень грамотные ребята и реально предлагают… хорошие продукты. Хотя насчёт терраформ очень большие сомнения. Для Амазона тот же CF будет как минимум не хуже
да и опять же преимущества terraform как-раз в его универсальности
нет ) В смысле — конечно, терраформ более универсальное решение, но все эти рекламные истории про мультиклауд — это ложь. Потому что инкапсулировать специфику каждого конкретного провайдера и предоставлять пользователю более абстрактные объекты (скажем не просто "виртуальная машина", а "сервер БД PSQL" или вообще "инстанс бизнес-приложения) — это там еще писать и писать обертку. Но, да, это, конечно, возможно )
возможности интеграции с другими провайдерами
Звездочка — при наличии этих самых провайдеров. Либо их можно написать самим — там достаточно простой интерфейс. Как пример боли — провайдер для k8s. Лучше б его в ТФ вообще не было :-)
В общем — инструмент неплохой, но вокруг него слишком много хайпа.
tectonic? Это, который coreos? Так нет его )
Далее, мультиклауд — это не тоже не для конечной инфраструктуры, это для продукта, который изначально разрабатывается как мультиклаудное решение
- Но многие сейчас очень гипнотизированы "мультиклаудом", который им не нужен на самом деле
Опять же — банальная экономия ресурсов разработчика, ведь написать решение под другой клауд, если уже знаешь терраформ, проще, чем что-то еще осваивать.
спорно — потому что проще сказать "дайте кубернетес" и разворачивать в нем — он уже практически стал таким "универсальным" платформенным решением. И не нужно пытаться корчить из себя мультиоблако с непонятными расходами на поддержку
Вы путаете ) в моей модели все правильно.
Если поставщик предполагает менеджед сервисы — вам как потребителю все равно как они реализованы. Берёте и используете.
Для коробочных продуктов от 3rd party — кубернетес уже является одним из вариантов целевых платформ. Например, так устанавливаются GitLab, Artifactory и прочие. Потому что вендору нет никакого резона пытаться учесть специфику любого облака.
Для собственной же разработки — тоже зачастую проще отбазироваться от кубернетеса. Не берём сейчас историю «как его развернуть» — с ней действительно ТФ может помочь. И здесь я ни в коем разе не спорю )
Если у вас, например, есть MongoDB, который запускается на EC2 и вам нужно поставить новый mongodb exporter для Prometheus — что будете делать? И все без даунтайма.
Без даунтайма — решается кластерными базами. То же обновление MongoDB в случае единственного инстанса (скажем, в монге CVЕ нашли и НУЖНО обновляться) тоже нельзя без даунтайма сделать. Это только лишь говорит нам, что нужно переходить от парадигмы pets к парадигме cattle.
А еще лучше — использовать managed services от самого амазона....
У меня терраформ генерит несколько файлов переменных для ансибль и собственно. hosts.ini.
Используя стандартные шаблоны, никакой магии.
Причина — нужно разворачивать множество очень похожих но не одинаковых кластеров.
Так что все раскидано по workspace-ам в терраформе и по директориям как завещано в. best practices в ансибле.
И что-бы не мучаться с гигантскими строками командной строки все это завернуто в Makefile,
Полгода, пока полет нормальный.
/ в процессе прочтения не покидало чувство дежавю, что я это уже читал… и точно! тьфу! только время потратил/
А точно надо переводить статью которой больше двух лет и которую все кто хотел уже прочитали давно в оригинале?
Дополнение Ansible для Terraform, которое у меня не заработало
Ну спустя то два года, даже переводчик уже мог бы добиться, чтобы заработало. Но нет(
Вообще есть еще 3ий вариант интеграции через встроенный host_list inventory plugin https://docs.ansible.com/ansible/latest/collections/ansible/builtin/host_list_inventory.html
- Terraform экспортит список хостов
- Ansible принимает их через -i списком
Проблемы несвоевременных коннектов в ансибле тривиально решаются вот так:
- hosts: target_group
gather_facts: false
tasks:
- wait_for_connection:
А почему просто не создавать инстансы на базовом образе, а provision делать в userdata?
Userdata хорошо управляется с помощью terraform, а там внутри используйте хоть bash хоть ansible.
Только начал изучать terraform, и не придумал, как мне с помощью tf поднять у себя виртуальную машину, и закинуть в неё публичный ключ от ssh. Чтобы уже потом ансиблом подключиться по ssh, и настроить приложения.
Виртуалки у себя в vSphere, поэтому ресурсы с ключами не доступны :(
Используем Ansible вместе с Terraform