Комментарии 13
У вас все отступы в коде пропали...
ну, как бы... нормальных пакетов (.deb, .rpm) - нету. поддержки *BSD в качестве run platform - нету. поставить через go install на не поддерживаемой платформе - нету. от вашего покорного слуги есть issue по данному поводу. от разрабов реакции - 0
deb и rpm нету потому что другая логика доставки https://www.pulumi.com/docs/iac/download-install/versions/ и https://github.com/pulumi/pulumi/releases просто качаете архив с бинарниками и используете
под *BSD даже не знал что нету, давно не использовал unix
видимо логика у разрабов такая что или сам клади в go и сам собирай deb, rpm и под unix тоже. Как я говорил pulumi не панацея и статья не нацелена на то что бы сказать что terraform плохо. Тут вопрос гибкости, иногда без pulumi просто не обойтись а terraform что называется не вывозит.
Использую Ansible + Terraform.
Анлиблом делаю конфигурации не требующие трекинга ресурсов и генерю конфиги терраформа, терраформом - требующее трекинга. Пишу модули и фильтры для первого, поэтому подерживаю ansible код в достаточно декларативном стиле (императивный подход остается под капотом).
Концеп Pulumi вообще не понимаю.
Помоему это тулза не нового поколения, это шаг назад в 70-80e к шелл портянам с размазаным по всему файлу контекстом выполнения и императивщиной в полный рост.
А вот это заявление:
появились привычные нам языки программирования... Go, .NET.
вызывает у меня опасения за тех кто это придумал, за их ментальное здоровье. Почему бы не пойти дальше? Где C, Fortran, Cobol... и asm разумеется?
Такое чувство что люди совершенно оторвались от реальности. Зачем вам интеграция инфраструктурной тулзы в ваш язык программирования, а особенно компилируемые? Вам что нужно запускать её раз в 100мкс? Точно нужно, да? А зачем? Ведь в противном случае задача решается самым прямым образом: запускайте самые обычные инструменты через exec. Это не настолько плохо как люди об этом думают, особенно если вы делаете это реже чем раз в секунды. Или если вы делаете не mvp колхоз, лишь бы заработало, и вам нужна изоляция, границы модулей - вот это все, то дергаете их по API (например ansible можно дергать через AWX или Semaphore, terraform тоже чем-то, вроде тоже через последний). Зачем миксовать в коде приложения принципильно разные сущности? Не понимаю.
А еще к вопросу безопасности, вы забиваете в свой код credentials позволяющие, допустим, управлять инстансами VM... Угадайте что произойдет если это сервис сломают? На каком количестве инстансов вылезет злоумышленик? Конечно, можно сделать и безопасно. Но это как будто бы вариант тем кому "нужны шашечки", в другом случае (обычная тулза по api) у тех кому "ехать" сразу работает достаточно безопасно.
Тезис про собственные языки ansible и terraform на мой взгляд ошибочен. Их нельзя сравнивать с обычными языками программирования - это dsl поверх стандартного формата сериализации. В ансибле точно можно юзать для сериализаци json вместо yml, в terraform вроде тоже можно json вместо hcl. Таким образом остается только ознакомиться с самим dsl, который очень простой, потому что ограниченный. Это близко нельзя сравнить с изучением языка программирования. Разные порядки сложности.
Вобщем очередной раз не убедили.
Статья не для убедить а открыть глаза тем кому нужно что-то больше чем скудные возможности terraform. В наших реалиях большим корпорациям требуются большие и гибкие возможности и множество устоявшихся приложений уже просто так сказать не вывозят
Все что вы написали 7 лет назад я читал про Kubernetes. Делайте выводы
А еще к вопросу безопасности, вы забиваете в свой код credentials позволяющие, допустим, управлять инстансами VM... Угадайте что произойдет если это сервис сломают?
Ну вот с этого места всё понятно - автор комментария не то что не использовал, а даже документацию не читал. Но осуждает.
Этот бы возмущенный комментарий да в производительное русло.
подерживаю ansible код в достаточно декларативном стиле (императивный подход остается под капотом)
Сможет ли сторонний человек посмотрев на ваш код ansible понять в какой состоянии находится инфраструктура на данный момент? Ведь это одно из основных достоинств декларативного подхода. И насколько будут корректны (показательны) тесты такого кода?
Зачем вам интеграция инфраструктурной тулзы в ваш язык программирования, а особенно компилируемые? Вам что нужно запускать её раз в 100мкс? Точно нужно, да? А зачем?
Когда проект большой на десяток окружений (есть такие) из кластеров kubernetes, serverless решений, виртуалок, S3 хранилищ и кучи сетевых правил ждать по 15-20 минут, а то и больше пока terrafom (на самом деле terragrunt) очухается и очухается ли - дело такое. Особенно когда надо сделать срочные измнения, что имеет место случаться в самый не подходящий момент.
Ведь в противном случае задача решается самым прямым образом: запускайте самые обычные инструменты через exec. Это не настолько плохо как люди об этом думают, особенно если вы делаете это реже чем раз в секунды.
Автор как раз отметил это в своей статье: Можно создавать инфраструктуру, которая сама подстраивается под нагрузку, автоматически разворачивает тестовые окружения, оптимизирует затраты...
И это ни разу не фантастика, особенно когда начинается оптимизация затрат на инфраструктуру или игра в cast cutting. Либо проект настолько громозкий, что для тестов надо генерить определённую часть окружения. Причём, для разных тестов разные варианты ландшафтов надо генерить. Потом их удалять на выходные или в конце рабочего дня (cast cutting).
А еще к вопросу безопасности, вы забиваете в свой код credentials позволяющие, допустим, управлять инстансами VM...
Как инструмент управления инфраструктурой pulumi не должен управлять инстансами. Это как раз задача инструментов императивного управления. В коде pulumi может быть описана установка агента управления или создания пользователя / пользователей с закидыванием соответствующих публичных ключей ssh.
А так уже каждый может извращаться как хочет. Встречал рассказ, как в компании даже дашборды мониторинга в Grafana накатываются с помощью terrafom.
Или если вы делаете не mvp колхоз, лишь бы заработало, и вам нужна изоляция, границы модулей - вот это все, то дергаете их по API (например ansible можно дергать через AWX или Semaphore, terraform тоже чем-то, вроде тоже через последний). Зачем миксовать в коде приложения принципильно разные сущности?
Ничто не мешает не миксовать и не варганить кастрюлю венегрета. Это больше по части code style. Для демонстрационной статьи вполне пойдёт.
Тезис про собственные языки ansible и terraform на мой взгляд ошибочен. Их нельзя сравнивать с обычными языками программирования
Всё верно пишите. В ansible и terraform это не более чем формат описания конфигурации, но никак не программирования.
Таким образом остается только ознакомиться с самим dsl, который очень простой, потому что ограниченный. Это близко нельзя сравнить с изучением языка программирования.
Не сказать что очень простой. Тот же hcl свои причуды и нюансы имеет. Для описания инфраструктуры не обязательно изучать ЯП и алгоритмы до состояния готовности пройти лайвкодиниг и алгособес в яндекс или т-банк.
Ansible + Terraform это такая боль, такая боль...
Pulumi после этого несколько мозговзрывающий, но в целом приятный.
Ой, сплю уже, комvентарий удалил случайно про отсутствие dry run\plan
как же отсутствует - ну pulumi preview же
У терраформа есть CDKTF
Года 4-е назад на одном проекте был соблазн использовать Pulimni именно из-за поддержки в нем обычных языков программирования. Но потом все же выбор был сделан в пользу Terraform из-за его понятности и близости DevOps инженерам. С Pulimni, к сожалению, все намного сложнее было. Не скажу, как сейчас обстоят дела. Но в компании, где работаю, тоже Terraform. Да и в объявлениях о работе Pulumni упоминается нечасто.
Terraform уже не тот? Как Pulumi меняет правила игры в Infrastructure as Code