Почему все так любят предлагать нерешения проблемы 😂

Он делает immutable infrastructure

и?

И не нужно думать ни о каких зависимостях

Просто описываете декларативно свою инфраструктуру, а он ее делает

Максимально параллельно

Что там от чего зависит - вас вообще волновать перестаёт

Даже если это так, к сожалению, это не решает основной проблемы, когда ansible деплой тесно связан с деплоем инфраструктуры

деплой любого DB, message queue итд и нецелостное решение не поможет

elasticsaerch + app1 + ECS, например

И в чем проблема?

я же хочу задеплоить сначала vpc, потом 3 виртуалки для ES, конфиг ES, а уже потом потом виртуалку для app1, конфиг для app1 и ECS одновременно

И в чем проблема?

Я, лично, не вижу возожности это сделать в один подход

Разворачиваете инфраструктуру терраформом и накатываете роли параллельно

Разворачиваете инфраструктуру терраформом и накатываете роли параллельно

ну и какой failure rate при таком подходе?

как app1 узнает endpoint для ES?

ну и какой failure rate при таком подходе?

Зависит от того, насколько хорошо продуман дизайн

как app1 узнает VPC?

как app1 узнает VPC?

Зачем апликухе vpc?

одни вопросы)

когда происходит запуск ec2 ты должен указать vpcid, subnet, итд

когда происходит запуск ec2 ты должен указать vpcid, subnet, итд

И?

И?

ты не сможешь его указать если VPC еще не создан

тоже самое с подсетями

А вам и не надо это делать

Терраформ сделает

ок, это частный пример. в случае частного примера где мы деплоим раннер гитлаба это нужно, все равно будет. как насчет ES/DB endpoint?

ок, это частный пример. в случае частного примера где мы деплоим раннер гитлаба это нужно, все равно будет. как насчет ES/DB endpoint?

Что именно нужно будет? Я не очень понимаю суть вашего вопроса

Что именно нужно будет? Я не очень понимаю суть вашего вопроса

приложение должно подключиться к DB, ES или Message queue. Как оно узнает его если у нас нет никакой гарантии последновательности?

ответ простой: нам необходимо все стадии делаь вручную

сначала тераформ, потом все остальное

Но это всего лишь 1 прстейшая зависимость. Отсюда и вопрос, когда их 10 или 20 или 100

Но это всего лишь 1 прстейшая зависимость. Отсюда и вопрос, когда их 10 или 20 или 100

Вы хотите обсудить архитектуру решения?

Как сделать солюшен таким, чтобы минимизировать зависимости?

Так это уже не вопрос ансибла

Если речь идёт о зависимостях между микросервисами, то для этого тоже не ансибл нужен, а другие решения

Ансибл тут вообще параллелен

Хендлинг зависимостей между сервисами - не его задача

Да, все верно)

Спасибо за мнение

Пора бежать, чуть позже еще появлюсь

Такое впечатление, что статью какой-то откровенный нуб писал, который ансибл неделю назад впервые увидел

Надо же. Не нуб, а целый Senior Architect for Red Hat Consulting 🤟 https://www.ansible.com/blog/author/allen-eastwood Куда катится Red Hat...

ответ простой: нам необходимо все стадии делаь вручную

Ну если так, то добро пожаловать в боль и унижение. Вообще смею напомнить, что Ансибл - это про идемпотентность. Правильно написанный плейбук как бы ни запускали - выхлоп будет строго один: тот, что описан плейбуком. Ну и развёртывание VPC и окружения в нём Ансиблом было возможно уже в 2015 😉

Причём в multiregion-варианте.

Ну если так, то добро пожаловать в боль и унижение. Вообще смею напомнить, что Ансибл - это про идемпотентность. Правильно написанный плейбук как бы ни запускали - выхлоп будет строго один: тот, что описан плейбуком. Ну и развёртывание VPC и окружения в нём Ансиблом было возможно уже в 2015 😉

Ну если так, то добро пожаловать в боль и унижение. Вообще смею напомнить, что Ансибл - это про идемпотентность. Правильно написанный плейбук как бы ни запускали - выхлоп будет строго один: тот, что описан плейбуком. Ну и развёртывание VPC и окружения в нём Ансиблом было возможно уже в 2015 😉

)) из контекста, конечно вручную не вариант. Все давно повторяемо, вопрос зависимостей и порядка

)) из контекста, конечно вручную не вариант. Все давно повторяемо, вопрос зависимостей и порядка

В целом awx workflow решает проблему, но в идеале хочу на ядре провернуть

Ну если так, то добро пожаловать в боль и унижение. Вообще смею напомнить, что Ансибл - это про идемпотентность. Правильно написанный плейбук как бы ни запускали - выхлоп будет строго один: тот, что описан плейбуком. Ну и развёртывание VPC и окружения в нём Ансиблом было возможно уже в 2015 😉

Надеюсь проблема ясна, плейбуком достаточно сложно описать когда можно запускать другой плейбук асинхронно а когда необходимо блокирование. Если плейбук А не зависим от плейбука Б то ждать выполнения Б бессмысленно

Разворачиваете инфраструктуру терраформом и накатываете роли параллельно

Кстати, в чем цимес терраформа?

В декларативном и лаконичном подходе к описанию инфраструктуры

Ну и immutable

Т.е. описали в темплейте все, что вам нужно - от vpc и подсетей до деталей конфигурации машинок и всех остальных облачных сервисов, запустили - и все поднялось в нужном виде в нужной последовательности

Понадобилось внести изменения в конфигурацию (например добавить или удалить пару машинок) - изменили один параметр в шаблоне и запустили роль ещё раз. Терраформ внесёт именно те изменения, какие нужно

По сути Терраформ - это такой ансибл для облачных инфраструктур

Кстати, в чем цимес терраформа?

в мифической кросс-платформенности)

в том что если не описывать управление инфраструктурой в коде, получится говняканье в веб интерфейсе облака

@arno49 тут за терраформ говорят. Твой выход 😉

в мифической кросс-платформенности)

+1. Она не мифическая, но чтобы ее достигнуть придется кучу бойлерплейта написать

+1. Она не мифическая, но чтобы ее достигнуть придется кучу бойлерплейта написать

Мифическая в том плане что можно с таким же успехом нормально использовать и, что самое главное, понимать родные средства типа Cloudformation

Только терраформ от поставщика не зависит...

Только терраформ от поставщика не зависит...

А в чем разница где писать бойлерплейт?

А вдруг надо переехать на всферу?

Время в конечном итоге тратим и там и там

Амазон в полном блоке ркн например

А вдруг надо переехать на всферу?

Опять писать бойлерплейт в террафорсме)

вмваре отвратительно поддерживается

Есть вообще их сравнение?

Типа props-cons

клаудформейшен сраное говно, зачем его использовать

клаудформейшен сраное говно, зачем его использовать

Необоснованное высказывание.

клаудформейшен сраное говно, зачем его использовать

Давай свой негативный опыт )

Есть вообще их сравнение?

В интернете много чего есть) Каждый хвалит свое. https://www.terraform.io/intro/vs/cloudformation.html

Офсайтов не надо, понятно что там они лучшие

вот другое сравнение, типа непредвзятое https://hackernoon.com/your-infrastructure-as-code-cloudformation-vs-terraform-34ec5fb5f044

клаудформейшен сраное говно, зачем его использовать

Пруфы где? Есть претензии - выкладывай. Не осилил - не гони. А так многим интересно похоже

вот другое сравнение, типа непредвзятое https://hackernoon.com/your-infrastructure-as-code-cloudformation-vs-terraform-34ec5fb5f044

Гляну, спс

клаудформейшен сраное говно, зачем его использовать

+1

я его только слегка потыкал пару лет назад, поблевался и пошел юзать тераформ. Говорят что сейчас он стал сильно лучше. Тогда он был монструозным по абстракциям и размеру кода. И код на json

Знать минусы порой важнее чем плюсы

Я вот знаю минусы заббикса, но они мне не мешали его использовать много лет

Есть вообще их сравнение?

Плюс cloudformation в его нативности, и в том, что это целая система управления, в то Время как Терраформ Это всего лишь надстройка над API. Весь бенефит терраформа, на мой взгляд его синтаксисе, И то многие люди недовольны. Я не вижу необходимости использовать инструмент который не факт что ещё будет гарантировать кроссплатформенность. Но это дело каждого и холивар не моя стихия...