Как сделать чтобы network access control list (ACL) создавался только после полного provision of instance?

Question

[Вадим]

Привет всем,

хотел спросить как можно добавить network access control list (ACL) в Террафоме, но только после того как завершилось исполнение user_data на инстанс. Как мне кажется можно null_resource использовать, но не совсем понимаю как?

хорошего выходного,
Вадим

Answer 1

[Иван Шумов]

В чем проблема использовать dependencies?

Comments

[Амир Авербах]

Не уверен на 100%, но может быть такое, что instance state отмечается как ready на более ранних стадиях запуска ОС, еще до выполнения user_data. Автор, если вы тестировали и это действительно так, то вам дорога в null_resource. Внутри придется добавить remote_exec provisioner и запускать какую-нибудь команду, которая подтвердит, что ваш user_data выполнен успешно.
Вообще сама задача на мой взгляд поставлена неверно. Если у вас достаточно строгие требования к безопасности, из-за которых вы внедряете ACL, то вы по сути нарушаете их, создавая окно, в котором инстанс остается не защищен. Советую воспользоваться HashiCorp Packer и загатавливать AMI. Заодно и сократите время запуска инстанса, т.к. не придется ждать user_data.

[Иван Шумов]

Амир Авербах, на самом деле тут все еще хуже. Человек не разделяет провижининг инфраструктуры и ресурсов, а их надо разделять вообще на разные стеки

[Вадим]

Амир Авербах

На самом деле окно ведь будет очень короткое время пока user_data не завершиться! Этот вопрос скорее из интереса возник, чем из практики. Зато много полезных идей получил!

[Иван Шумов]

Вадим, в нормальных условиях ec2 инстансы не запускаются таким образом - их ставят за ELB и он контролирует их запуск. Или, адекватные люди вообще переезжают на ECS + Fargate. Еще раз повторюсь - если у вас появляется зависимость сетевой инфраструктуры и вычислительных ресурсов то у вас проблема и очень большая: либо "все смешалось: кони, люди", либо с критическим мышлением что-то не то

[Вадим]

Я же говорю, этот вопрос скорее из интереса возник... а так да, надо свой ami делать.

[Иван Шумов]

Вадим, контейнеры и в путь) ECS + ECR

[Евгений Хлебников]

добавлю еще из неожиданных идей:
используйте cloudformation (можно даже внутри terraform,ага :D )
в CF AWS предоставляет отличные инструменты для контроля практически любой ситуации.
Например в вашем случае можно организовать nested stacks - в первом стеке создается и провижинится инстанс, с минимально необходимыми достуами в сеть, во втором - настраиваются SG и NACL
Второй стек может быть запущен только после полностью успешного завершения первого стека - вы даже можете написать тесты на приложение прямо в CF и только по их успешному прохождению послать cfn-signal в CF, чт можно продолжать провижининг и открывать порты в NACL\SG в следующем стеке.

Одно но: порог вхождения в CF сильно выше чем у TF и это не просто инструмент а сервис, со своим контролем и хранением состояния и всеми причитающимися, что является и плюсом(для работоспособности) и минусом(для обновлений, контроля и, конечно, вхождения в управление CF стеками)

[Иван Шумов]

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

[Евгений Хлебников]

Иван Шумов, вхождение в управление инфраструктурой с помощью CF сильно сложнее чем в TF, поскольку CF в том числе следит за состоянием инфраструктуры (о чем надо помнить и дебажить если что-то не получается), и до сих пор обладает меньшими возможностями по интерполяции чем активно развивающийся TF.
Мнение, конечно, у каждого может быть свое, но организовать полноценную инфраструктуру "под ключ" в TF сильно легче чем в CF (именно поэтому TF получил такую популярность в свое время)
А про terraform - есть несколько кейсов когда нужно запускать CF стек из TF модулей в работе, так что "запустить скрипт" и "запустить CF" в данном случае равнозначны =)

[Иван Шумов]

Евгений, полностью не согласен, но у всех свой опыт и знания, да.