а кстати между делом вопрос - кто как использует screen? и вообще нужно ли - или прямо необходимо перейти на что то другое?

tmux считается более продвинутым последователем, но на самом деле это скорее дело привычки, потому что особенности (в т.ч. неприятные) есть у обоих

tmux считается более продвинутым последователем, но на самом деле это скорее дело привычки, потому что особенности (в т.ч. неприятные) есть у обоих

спасибо, хотел услышать это не только от себя ))

нормальный такой хак, сам его юзал для контейнера jenkins чтобы тот мог например налету сбилдить докер-образ и запустить run-off контейнер

хотя считается что это грубый костыль https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/

вроде dynamic inventory у ansible всегда был в поряде, главное учитывать, что он кэширует где-то IP, можно настроить время “кэша”

Для EC2 он не был в порядке - ломался на разбрасывании EC2-инстансов по группам на основе тегов

Для EC2 он не был в порядке - ломался на разбрасывании EC2-инстансов по группам на основе тегов

интересно, никогда не встречал такое, всегда срабатывало если используется один тэг Name

Подскажите, есть ли какое-то решение, позволяющее автоматически создавать и удалять DNS зоны на slave сервере, при удалении или добавлении их на master сервере? Использую Bind9/

интересно, никогда не встречал такое, всегда срабатывало если используется один тэг Name

тег Name не имеет никакого отношения к автогруппированию инстансов. там, собственно, юзкейс такой: ты указываешь, сколько инстансов определённой роли тебе надо, а дальше оно само

terraform хорош, у нас вся инфра в aws им разворачивается

Ну а как оно состояние держит?) удалили state файл и все, тю-тю?

Да, ansible+cloudformation хорошо себя показало. Плюс для микросервисов удобно генерировать сами темплейты

Ну а как оно состояние держит?) удалили state файл и все, тю-тю?

состояние мы храним в s3, но там много бекендов поддерживается. Никто не запрещает делать бэкапы.

состояние мы храним в s3, но там много бекендов поддерживается. Никто не запрещает делать бэкапы.

а roll back как?

а roll back как?

какой ролбэк? Ты или создал сервер или нет

почитай документацию)

а кстати между делом вопрос - кто как использует screen? и вообще нужно ли - или прямо необходимо перейти на что то другое?

Тмукс юзабельней, имхо. Прокрутки, мышь, деление экрана

ну вот, я о том же CF делает безопасные выкатки-роллбеки, change sets итд

Top Players 1. Andrew Kiselev – 31 2. Maxim Lapkovsky – 26 3. Mihail – 16

Тмукс юзабельней, имхо. Прокрутки, мышь, деление экрана

оно и в скрине есть, на самом деле

прокрутки только нет, по крайней мере мышью

А она ой как нужна иногда

и прокрутка есть

по крайней мере в режиме копирования

А она ой как нужна иногда

это да, Ctrl+A Esc и езда клавой не всегда удобна

какой ролбэк? Ты или создал сервер или нет

еще, можно ли удалить группу ресурсов в terraform c полной валидацией? или он унесет ветром созданные вручную ресурсы тоже?

Top Players 1. Andrew Kiselev – 31 2. Maxim Lapkovsky – 26 3. Mihail – 16

это запрос на "пометьте как спам" или что?

еще, можно ли удалить группу ресурсов в terraform c полной валидацией? или он унесет ветром созданные вручную ресурсы тоже?

ручные ресурсы явно не в стейте, тераформ про них не знает, соотв. не тронет

перед удалением можно посмотреть, что удалиться, есть команда plan

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

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

опять удалять?)

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

Это как? Теги не поменялись?

например, изменяем параметры среды Elastic Beanstalk

Если api отдал ошибку, то в стейт то, что не изменилось не запишется

запускаем, а она сломалась. Какие действия с terraform?

ошибка происходит но не сразу

к примеру, создаем 10 ресурсов, 9 создалось а 1 нет, как быть с терраформ в таком случае?

не в курсе, с Beanstalk не работал, cloudfront, например, долго создается, terraform ждет ответа от api, если api дал ответ и при этом делает что-то асинхронно, то это проблема api

9 запишутся в стейт, а 1 нет

а нам надо все 10, иначе система сломана

атомарность нужна. как быть?

при следующем выполнении plan тебе покажет, что создастся 1 ресурс

без атомарности реально стремно полагаться на это

TF прикольная штука, но когда нужно чтобы все было живо - я ей не доверяю

плюс отстает функционал от CF, иногда сильно, просто игнорят что-то...

а вот еще, что елси 2 или более человека захотят сделать изменение? там lock какой-то наверняка есть?

к примеру, создаем 10 ресурсов, 9 создалось а 1 нет, как быть с терраформ в таком случае?

Значит у него в стейте 9 создалось, а 1 нет. Запускаешь ещё раз и он предлагает тебе создать десятую

Значит у него в стейте 9 создалось, а 1 нет. Запускаешь ещё раз и он предлагает тебе создать десятую

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

а вот еще, что елси 2 или более человека захотят сделать изменение? там lock какой-то наверняка есть?

есть там лок

а вот еще, что елси 2 или более человека захотят сделать изменение? там lock какой-то наверняка есть?

рекомендую почитать документацию, там все написано

если не доверяешь, не используй)

рекомендую почитать документацию, там все написано

да, про лок вопросов нет

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

А в амазоне можно создать сразу 10 ресурсов, а если что-то засбоит, все уже созданные откатятся?

А в амазоне можно создать сразу 10 ресурсов, а если что-то засбоит, все уже созданные откатятся?

да

да

Это как нагуглить можно? Транзакции?

У меня был такой кейс, где именно это нужно было

ну вот это, вероятно, имелось под ролл бэком

мне никогда такое не требовалось, т.к. у нас всегда вручную запускают terraform и следят, что происходит

ну я тоже вышел из положения. если что-то пошло не так - делаю дестрой

я все запихиваю в CI, поэтому хочу быть 100% уверен в повторяемости

я все запихиваю в CI, поэтому хочу быть 100% уверен в повторяемости

ну так вызывай дестрой на падении шага эпплая

ERROR: S client not available

?

ага, и тютю 99.99%

все же должно работать

ага, и тютю 99.99%

ну если ты только что создал эти 99.99% - то конечно тютю

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

изменения на живом происходят

ну было ок. потом бац ,надо сделать изменения

как минимум два стейта: для перманентной/шареной инфраструктуры и для инстанциируемой, которую точно можно всю загасить

например, увеличить размер диска.

...или во сменить размер инстанса!

например, увеличить размер диска.

и что ты собираешься роллбечить в случае неудавшейся смены размера диска?

как что, подключается старый диск

например.

ну диск не уменьшишь обратно, это правда)

aws уже давно умеет менять размер диска на лету

он или поменяется или нет

...или во сменить размер инстанса!

с размером инстанса то же самое. ты либо сменил, либо не сменил. роллбечить нечего

это в идеальных условиях. А в реальных - еще может быть что дисковая системя AWS стухнет

...или во сменить размер инстанса!

для этого инстанс выключается, т.е. у тебя будет downtime

не сменил - билд упал - поджигаешь опять

для этого инстанс выключается, т.е. у тебя будет downtime

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

с размером инстанса то же самое. ты либо сменил, либо не сменил. роллбечить нечего

в смысле? был m3.large все работало хорошо. теперь нужно начать ужимать ресурсы, запланировали t2.small, вроде на бумаге все ок... запиливаем, оно меняется, но healthcheck не проходит...

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

для этого инстанс выключается, т.е. у тебя будет downtime

нет если включены rolling updates.

а не запустить CI и уйти домой

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

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

Запланировать всё невозможно

нет если включены rolling updates.

You must stop your Amazon EBS–backed instance before you can change its instance type http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-resize.html