то есть надо добавить еще условий проверки "чтобы это понравилось ELB"

Парни у вас такая задушевная беседа, прям завидно! Пойду кая конфигурировать VPC на амазоне! Стану умным, как вы :)

воскресенье...

суббота

а, да ?

человек проверит HC, а ELB может начать плеваться

проверить, что все работает, значит проверить, что ELB после переключения HC работает корректно

вообще это все должно быть замониторено

ну дело в том, что HC невозможно проверить без изменения

то есть что-то должно измениться изначально

да, замониторено, но это опять довод в сторону снижения рисков

я то знаю что оно упадет если что-то не так.

я пессимист)

(в этом плане)

если HC не сработал, то именно он откатывается на старую версию вручную, а т.к. SG еще не удален, то все ок

тогда какой ресурс от какого зависит?)

HC от SG или наоборот?

я надеялся что что-то поменялось. год назад пересматривал terraform и CF... TF подкупал вообще всем

синтаксис, кросс-платформенность...

В данном случае HC может зависеть от SG, т.к. без SG HC не сработает

но опять же, эта зависимость не гарантирует ни от чего, приложение может не слушать нужный порт или iptables на системе почему-то работает или еще что-то

В данном случае HC может зависеть от SG, т.к. без SG HC не сработает

тогда как сработает, разве SG не должна обновиться? > если HC не сработал, то именно он откатывается на старую версию вручную, а т.к. SG еще не удален, то все ок

хотя если мы захламляем старым SG то тогда да. но я не уверен как оно на уровне ресурсов реализуется...

>тогда как сработает, разве SG не должна обновиться я же говорил, что одновременно созданы две SG, первая удаляется только, когда все ок, соотв. у HC меняется просто зависимость на новую SG

и боюсь представить сколько работы это )

и сколько рисков

в terraform ELB это один ресурс

Security group в смысле, не Service Group

не знаю к чему я сказал это, но имелось в виду что нужно изменить настройки самой Secuity Group. service group это из мира железных балансировщиков

AWS::ElasticLoadBalancing::LoadBalancer и AWS::EC2::SecurityGroup

aws_elb и aws_security_group

смотрите, состояние 1. HC порт 80 2. SG открыт порт 80. теперь надо сменить порты на 443. меняем конфиг. HC порт 443 2. SG порт 443. запускаем конфиг, что-то меняется первым, допустим SG. на 443. круто ELB не меняет HC, например, что происходит с SG? что происходит с приложением?

запустить ещё раз

вы сообщили терраформу что вы хотите иметь

Ну еще наверне terraform в России знать полезнее, там полно своих облак, и AWS это небольшая часть, поэтому я понимаю.

вы можете эплаить стейт хоть до посинения, пока терраформ не сделает вам всё так как нужно

запустить ещё раз

а в это время сайт / сервис у меня лежит, а я должен разбираться что пошло не так

а в это время сайт / сервис у меня лежит, а я должен разбираться что пошло не так

а что вы хотели? если что-то одно произойдёт, а второе нет - то независимо от инструмента, они будут отличаться

а что вы хотели? если что-то одно произойдёт, а второе нет - то независимо от инструмента, они будут отличаться

Я хочу чтобы как в CF произошел roll back до корректного состяния конфига

потому что если что-то и сломается - то 99% на моменте применения (сеть пропала, амазон сглючил)

Я хочу чтобы как в CF произошел roll back до корректного состяния конфига

а заэплаить всё ещё раз?

а заэплаить всё ещё раз?

можно, да. Если принимаете неатомарность и инфраструктуру в одном предложении.

нет, ну если вы имеете дело с какой-то экспериментальной конфигурацией и вы даже не знаете, применится она или нет (пусть даже всё с сетью ок и с амазоном ок) - то может быть стоит проверить её на тестовом стенде

Я хочу чтобы как в CF произошел roll back до корректного состяния конфига

ну какбэ хочу=делаю - вроде же терраформ опенсорсный?

чтобы потом быть уверенным в том, что если что-то упадёт - достаточно перезапустить ещё раз

ну какбэ хочу=делаю - вроде же терраформ опенсорсный?

))) ну да ну да

а не что-то упадёт - разбираться, может мы не то придумали и надо что-то ещё придумать

Я к тому, что на словах быть Львом Толстым весьма легко, а вот уметь довести существующий инструмент до реализации своих хотелок либо за это заплатить - тут слишком часто, увы, вспоминается вторая часть поговорки.

Про экспериментальный конфиг - да, правильно. Но люди делают ошибки везде, даже в давно известных параметах, типа TCP:80 / HTTP:80/

Я к тому, что на словах быть Львом Толстым весьма легко, а вот уметь довести существующий инструмент до реализации своих хотелок либо за это заплатить - тут слишком часто, увы, вспоминается вторая часть поговорки.

Да, я согласен. Но зачем, если можно просто взять и использовать родной инструмент)

Да, я согласен. Но зачем, если можно просто взять и использовать родной инструмент)

CF уныл чуть более, чем полностью.

CF для амазона и ART для Azure

CF уныл чуть более, чем полностью.

Но он позволяет конфигурировать 100% инфраструктуры, он протестирован, поддерживается амазоном итд

а уныние можно исправить парой таблеточек jinja2

Он уныл, недружелюбен, требует для параметризации внешние инструменты и т.д. Да и вообще - это не инструмент, а документированный способ вызова внутреннего API амазона.

Ну ок, как скажете)

но оно как бы и плюс, то что всегда в ногу с api идет

но оно как бы и плюс, то что всегда в ногу с api идет

Только тогда его плюсы становятся эфемерными - это плюсы самого API.

Ну я не сказал бы что уж на столько эфемерными. Работает ведь. А другие реализации работают но не полностью

Само API - типа чоткое, ровное, выверенное временем и факапами амазона и его пользователей. ЗдОрово. Но от этого JSON с кучей параметров внутри не становится настоящим инструментом.

yaml

?

а terraform интегрируется с vault, работает не только с aws, имеет удобный синтаксис

ERROR: S client not available

а terraform интегрируется с vault, работает не только с aws, имеет удобный синтаксис

Да, в этом плюс, но я vault как сервису не особо доверяю, s3- да

yaml

Это всегда было форматом, тащем-та

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

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

Здесь важный момент!!!! Этот факт говорит только о том, что сочетание тебя, прода и терраформа до сих пор не сдетонировало. Это НЕ говорит о том, что смена любого компонента - безопасна, что оно НЕ сдетонирует в будущем. Это, в общем, информация о прошлом.

wtf

Да, в этом плюс, но я vault как сервису не особо доверяю, s3- да

>но я vault как сервису не особо доверяю это не сервис, а программное обеспечение, которое можно поднимать на своей инфраструктуре

Здесь важный момент!!!! Этот факт говорит только о том, что сочетание тебя, прода и терраформа до сих пор не сдетонировало. Это НЕ говорит о том, что смена любого компонента - безопасна, что оно НЕ сдетонирует в будущем. Это, в общем, информация о прошлом.

не я один с ним работаю)

terraform кстати зафакапнулся при развретывании-уничтожении EMR с нуля - амазон подбрасывает свои SG для мастера и слейв ноды, которые не могут быть видны в terraform (автоматически) - и вызов destroy происходить с обломом

terraform кстати зафакапнулся при развретывании-уничтожении EMR с нуля - амазон подбрасывает свои SG для мастера и слейв ноды, которые не могут быть видны в terraform (автоматически) - и вызов destroy происходить с обломом

А вот и пример детонации ?))

terraform кстати зафакапнулся при развретывании-уничтожении EMR с нуля - амазон подбрасывает свои SG для мастера и слейв ноды, которые не могут быть видны в terraform (автоматически) - и вызов destroy происходить с обломом

упс

EMR вообще плохо с terraform дружит, это скорей косяк aws

EMR вообще плохо с terraform дружит, это скорей косяк aws

хм?

но это решается так terraform destroy -target cost.resources

EMR сделан через жопу)

там мало что конфигурируется

ИМХО терраформ идеален для разовых деплойментов, или деплойментов где поддерживать ничего не надо. типа разовый devops

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

я не говорю что это плохой инструмент. напротив, он прекрасен.

Ага. Главное нагрузку не давать

но даже маленький шанс чего-то непредсказуемого может превратиться в катастрофу, а когда компания теряет сотни тысяч (и неважно какой валюты) за час простоя.. ...непредсказуемость уменьшается со временем, когда одни и те же люди обслуживают систему... но 1. на это просто нет времени, 2. приходят новые люди которые ни сном ни духом о тех процессах деплоя (проверить порт, удалить итд). умножаем на количество процессов умножаем на риск факапа. получаем не очень красивую картину

... раз за разом вдумчиво читают документацию и переписывают конфиги чтоб держали нагрузку

да нагрузка имхо не причем, можно и на низкой нагрузке риски минимальные иметь.

Вот на низкой нагрузке - все пучком.

блин. эко меня проперло. Извините.

Проблемы начинаются когда когда "ебануть ещё n+1 нод в прод" не вариянт

https://www.terraform.io/docs/providers/aws/r/cloudformation_stack.html кек

ахах

и причем тут нагрузка и система конфигурации?

да?