Пулуми против Террафрома: что лучше?
4 апреля 2024 г.Я заключил новый контракт, по которому мне поручено консолидировать инфраструктуру компании под AWS. Они (компания) начинают видеть серьезный рост, и у них есть команда, которая в настоящее время использует PaaS и различных других облачных провайдеров. Инфраструктура как инструмент кодирования уже давно популярна; По большей части я немного скептически относился к их использованию, учитывая, что при небольшом размере команды пользовательского интерфейса часто бывает более чем достаточно.
Но когда вам нужно запустить несколько сред (разработки, промежуточной среды, рабочей среды, демо-версии и т. д.), это начинает вызывать большие накладные расходы. Проблема, с которой я часто сталкивался, заключается в том, что за поддержание этого становится ответственность одного или двух разработчиков, поскольку остальная часть команды не знакома с инструментом и синтаксисом языка. Очевидно, что это не идеально, поэтому я хотел изучить эту область, чтобы выяснить, существует ли средний путь, позволяющий получить преимущества IaC без затрат на изучение нового языка и инструмента.
Раньше я использовал Terraform в других компаниях, в которых работал, но никогда с нуля, и (полное раскрытие информации) всегда находил этот опыт довольно разочаровывающим. Итак, я начал искать альтернативы terraform и наткнулся на Pulumi, который позволяет предоставлять ресурсы с использованием ряда языков программирования (включая Go), а поддержка провайдеров AWS у Pulumi превосходна.
Но, как и в любой другой ситуации, когда вы подумываете о том, чтобы жениться на новом инструменте, очень полезно провести некоторое исследование и желательно создать небольшое доказательство концепции, прежде чем принимать решение. В ходе этого процесса я сделал несколько интересных открытий: почему я предпочитаю пулуми Терраформу и когда я бы предпочел Терраформ Пулуми.
Краткое введение в Terraform
Я думаю, будет справедливо сказать, что Terraform долгое время был большой собакой в сфере IaC. Они поддерживают большинство облачных провайдеров, прошли масштабные испытания и имеют множество отличных учебных пособий. Раньше у них также была лицензия с открытым исходным кодом, использующая Mozilla Public License v2, но недавно они решили перейти на так называемую Бизнес-лицензию, BSL, которую можно рассматривать как «доступную для исходного кода».
Я не буду вдаваться в более длительные дебаты о том, почему это не идеально и справедливо это или нет, но это представляет угрозу для разработки сторонних инструментов и ваших возможностей внесения изменений в случае необходимости.
Для незнакомых: Terraform написан на собственном «DSL», известном как HCL. Это декларативный язык, поэтому вы указываете ему желаемое состояние, в котором должна находиться ваша инфраструктура, а Terraform определяет, как привести вашу инфраструктуру в это состояние.
Краткий пример того, как вы можете подготовить корзину S3, будет выглядеть так:
1resource "aws_s3_bucket" "my_bucket" {
2 bucket = "my-bucket"
3 acl = "private"
4}
Это будет записано в файле с расширением .tf. Как мы увидим позже, у вас есть множество вариантов структурирования вашего кода на модули и различные типы вариантов повторного использования кода: блоки data, переменные, < код>выходы и т. д.
Краткое введение в Пулуми
Пулуми — просто очень странное имя. В детстве у меня был друг, которого мы почему-то звали Пумми (или, может быть, он был ненормальным, точно не помню), и все, что я вижу, читая имя, — это его лицо. Они также довольно новички в сфере IaC, но добились значительных успехов. Несколько лет назад я работал в компании, где использовался CDK AWS, и я думаю, что люди сочли бы пулуми очень похожими.
У вас есть широкий выбор языков, которые вы хотите использовать: JS/TS, Python, Go и т. д. Все они имеют один и тот же API, поэтому переключение не должно быть самой большой проблемой. Сейчас я пишу все на Go, поэтому приведенный выше пример, написанный с использованием Go и Pulumi, будет выглядеть так:
1func main() {
2 pulumi.Run(func(ctx *pulumi.Context) error {
3 _, err := s3.NewBucket(ctx, "my-bucket", &s3.BucketArgs{
4 Bucket: pulumi.String("my-bucket"),
5 Acl: pulumi.String("private"),
6 })
7 if err != nil {
8 return err
9 }
10 return nil
11 })
12}
Для любого, кто когда-либо писал Go, это сразу должно иметь смысл, даже не зная API Pulumi или экосистемы AWS. И это одно из главных преимуществ, к которому мы будем возвращаться снова и снова на протяжении этой статьи.
Pulumi также является «настоящим открытым исходным кодом» в том смысле, что он работает под лицензией Apache 2.0, которая гораздо более либеральна, чем лицензия BSL, которую использует terraform. Это хорошо для сообщества и скорости принятия, но в какой-то момент то же самое произошло и с Terraform. На данный момент это огромный плюс.
Однако не все так радужно и солнечно. Пулуми еще молод, поэтому документация для написания кода все еще не очень хороша. Их универсальная документация компенсирует это, но может быть неприятно заходить в редактор и выходить из него, чтобы посмотреть, над чем вы сейчас работаете.
Создание POC
Все приложения являются контейнерными, поэтому мы можем в полной мере воспользоваться преимуществами службы эластичных контейнеров AWS, поэтому POC представлял собой простой API-интерфейс hello world, упакованный в образ Docker, обслуживаемый с использованием Fargate и балансировщика нагрузки впереди. Я был знаком с ECS и Fargate (а также с виртуальными компьютерами, подсетями, группами безопасности и т. д.), но никогда ими не пользовался, так что мне тоже пришлось немного поучиться.
Первое, что стало ясно, это то, что у Terraform есть много отличной документации и учебных пособий. Хотя у Pulumi также есть документация и доступные учебные пособия, они не такие «полные», как то, что вы найдете в Terraform. Однако я столкнулся с проблемой в настройке инфраструктуры с помощью Terraform и переключился на pulumi, и даже с меньшим количеством доступной информации я смог найти выход из проблемы, потому что мне просто нужно было прочитать код Go.
Накладные расходы на новый язык и платформу были бы неприятными, но сохранение того, что я уже знал, устранило одну часть сложности, и теперь концепции AWS были единственным, что мне нужно было понять. Я подозреваю, что это одно из главных чувств других инженеров, которые не занимаются DevOps на постоянной основе.
Мне удалось запустить POC, используя оба инструмента, но большую помощь мне оказало пребывание в среде, с которой я уже был знаком. Я активно использую (нео)vim, и хотя для Terraform существует множество хороших плагинов, среда Go — это то, чем я пользуюсь каждый день; ничего нового не требовалось.
Если бы я посвятил время, я не подозреваю, что мне потребовалось бы очень много времени, чтобы ознакомиться с HCL и Terraform до такой степени, что среда стала бы такой же знакомой, как Go. Но, учитывая, что мне не придется каждый день работать с Terraform после выполнения первоначальной настройки, это знакомство вскоре начнет исчезать.
Это означает, что каждый раз, когда нужно было добавлять новую часть инфраструктуры, мне нужно было заново знакомиться. А для остальной команды это было бы то же самое, но с дополнительными накладными расходами, связанными с изучением части кода, которую они не помогали писать. Это можно смягчить, вовлекая всех с самого начала, но это тоже бизнес, есть и другие приоритеты, которые необходимо развивать.
Документация может быть ответом, о котором некоторые из вас сейчас кричат в экран, и я вас слышу, но документация быстро устаревает. Это особенно актуально для небольших команд, где дела идут быстро: если большую часть можно задокументировать в самом коде, вы избавите себя от многих проблем.
Почему я предпочитаю Пулуми Терраформу
В итоге я остановился на Пулуми. По опыту я знаю, что «правильность» этого выбора проявляется только после того, как вы уже прошли точку, в которой переход к другому кандидату становится возможным. Но, с моей нынешней точки зрения, именно это принесет наибольшую пользу команде, с которой я сейчас работаю.
Когда я пытался решить, какой инструмент использовать, у меня постоянно возникали два вопроса:
- Каковы наши требования к инфраструктуре сейчас и в будущем? (то есть, понадобится ли нам когда-нибудь штатный DevOps)
- Что знает нынешняя команда? (т. е. языки программирования, поставщики облачных услуг и т. д.)
Первое может показаться произвольным, но вероятность найти штатного DevOps-инженера, знающего Terraform, намного выше, чем знающего Go и pulumi. Учитывая, что необходимая инфраструктура сейчас и в обозримом будущем, скорее всего, не потребует постоянной роли DevOps, terraform начинает казаться немного излишним.
Это новый язык, и всем членам команды придется изучить его, а также все лучшие практики, связанные с ним. А пока я углубляюсь в тонкости AWS, что также станет новым опытом обучения для команды (включая меня).
Второе, для меня, было очень важно, так как я на основе многолетнего опыта видел, что происходит, когда у вас есть большая установка Terraform, за создание которой, возможно, отвечал один инженер. В большинстве случаев поддерживать и исправлять его приходится одному человеку, фактически превращая его в специалиста по DevOps (что может быть против его воли —> они меняют работу —> команда — пиздец). Остальная часть команды, несмотря на то, что человек пишет документацию, делает презентации и т. д., до сих пор очень неохотно к этому прикасается.
Это то, с чем они незнакомы; инфраструктурную систему может быть довольно сложно «иметь в голове». Потенциально вы можете отключить все, не зная, как вернуться в рабочее состояние. Это создает много трений.
Вы можете возразить: «Ну, им просто придется этому научиться», и я согласен; это было бы разумным путем вперед. Но мы сейчас пытаемся решить не техническую проблему, а скорее человеческую. А без выделения времени на то, чтобы люди этому научились, скорее всего, этого не произойдет. Итак, вместо команды DevOps вам необходимо оптимизировать то, что заставляет людей действительно хотеть изучать инфраструктуру.
За две недели, которые я потратил на исследование и создание POC, я часто находил очень хорошие руководства и материалы по настройке инфраструктуры с помощью Terraform. Но как только я ударился головой о стену, не зная конкретного синтаксиса/настройки/подхода, используемого в руководстве, или того, что представляют собой конкретные сервисы AWS, мне стало очень трудно двигаться дальше.
Несколько раз я возвращался к Pulumi, где в их документации были примеры кода на Go, и мне было гораздо легче разобраться в этом, поскольку я уже знал Go. Мне «только» нужно было разобраться с частью AWS. После этого я снова переключился на Terraform и исправил ситуацию, используя свое новое понимание из pulumi/go. Но важно отметить, откуда взялись эти знания: путем чтения кода, что большинство из нас делает практически каждый день.
Устранение накладных расходов на изучение нового языка и поставщика облачных услуг только для поставщика облачных услуг очень помогает. Вы также получаете дополнительное преимущество, зная лучшие практики, а также то, когда и почему их следует нарушить. Вы получаете API от pulumi, поэтому можете начать предоставлять инфраструктуру непосредственно в своих приложениях, что упрощает создание демонстрационных сред для процессов продаж.
Когда я бы выбрал Terraform
До определенного момента что-то становится стандартом из-за своего качества и привлекательности для значительной части целевой группы инструмента. После этого момента действительно могут существовать лучшие альтернативы, но поскольку стандартным требованием является знание этого инструмента, все остальные просто продолжают его изучать (я смотрю на вас, React. Переключите эти интерфейсы обратно на HTML и используйте htmx для интерактивности! ).
Трудно сказать, происходит ли это с Терраформом и Пулуми. На самом деле у меня был гораздо лучший опыт изучения терраформирования по сравнению с предыдущим опытом, когда мне нужно было лишь немного его подправить.
Если в вашей команде есть члены, которые уже знают Terraform, или вы знаете, что в ближайшем будущем у вас возникнут крупномасштабные потребности в инфраструктуре, включая специальную команду DevOps, Terraform по-прежнему кажется лучшим выбором. Я выбрал Terraform и HCL довольно быстро, но я все еще вполне уверен, что они снова исчезнут, если не использовать их ежедневно, поэтому, если у вас нет этого ограничения, terraform для меня выиграет.
Главный аргумент с моей стороны — устранить разногласия в вашей команде, когда они не занимаются инфраструктурой ежедневно; Выучить новый язык, пока ваш премьер-министр выдает новые билеты по-вашему, как будто от этого зависела его жизнь, это тяжело. И ждать, пока один член команды, который действительно знает код инфраструктуры, вернется из отпуска и исправит ситуацию, очень неоптимально.
Было ли это хорошее решение?
Пока рано говорить об этом; Я вернусь к этому вопросу через несколько месяцев, когда у нас появится больше опыта работы с ним, и команда тоже начнет больше с ним работать.
Оригинал