Размышляя над проницательной и наводящей на размышления статьей zwischenzugs Кто должен писать Terraform?», вывод TL;DR, к которому я пришел, — Никто.

Это довольно простое утверждение для меня с самого начала, но оставайтесь со мной, и мы можем отправиться в путешествие. Проработав почти два десятилетия в различных ролях: от техника, ремонтирующего студенческие ноутбуки, до системного администратора, работающего с командой, управляющей операциями предприятия, работающего круглосуточно и без выходных, и единственным разработчиком, создающим хостинговое решение VoIP в стартапе; Теперь мы работаем с десятками инженеров-программистов и помогаем им работать более эффективно. Все это, и я синеволосый парень со своим мнением!

Проблема

За годы работы я использовал множество инструментов автоматизации конфигурации. С тех пор, как я работал с Zenworks Configuration Management, переупаковывая приложения Windows для корпоративных развертываний, писал невозможные средства поддержки Linux, CloudFormation для развертывания больших массивов ресурсов AWS или Terraform для связывания ресурсов вместе независимым от платформы способом. Независимо от того, какой инструмент я выбрал, я всегда сталкивался с довольно похожим набором проблем.

Теперь этот комикс очень ироничен и недооценивает то, чего можно достичь, используя DevOps не только как инструмент, но и как фундаментальный способ работы с технологиями. Однако это точно подводит итог общей проблеме всех вышеупомянутых инструментов: они чисто декларативны. Каждый из них предлагает определенный для предметной области способ введения программных способов, но у того, кто изо дня в день работает над приложением, не будет достаточно пропускной способности, чтобы изучить новый инструмент только для того, чтобы создать корзину. Не говоря уже о понимании последствий копирования/вставки привязки IAM из Stack Overflow, что приводит к конфигурации, делающей кучу частных данных общедоступными.

Так какой здесь ответ? Откажемся ли мы от всех этих инструментов и вернемся в мир, где разработчики занимаются вещами разработчиков, а системные администраторы — сварливыми привратниками?

Так что я должен признаться, как человек с СДВГ, я часто воспринимаю вещи буквально. Для меня, и я не имею в виду это как способ охранять ворота или смотреть свысока на кого-то, чей волшебник в их любимом инструменте; потому что все эти вещи требуют значительных навыков, чтобы делать хорошо. Но в моем мозгу это была конфигурация с контролем исходного кода, и я всегда видел в ней ступеньку к истинной конечной цели использования «Кода» через функциональный или объектно-ориентированный язык. Это не потому, что я какой-то самоуверенный разработчик. Скорее, я вырос и провел раннюю часть своей карьеры, ненавидя программирование. Со временем я понял, что незнание того, как программировать, сдерживает меня как инженера, поэтому я потратил сотни часов, обучая себя делать именно это.

Возвращаясь в нужное русло, в прежней роли мы довольно сильно полагались на CloudFormation. Несмотря на то, что нас было всего два человека, мы все равно сталкивались с проблемами, с которыми я сталкивался в более крупных командах.

Последовательность
Несмотря на то, что у нас были схожие образы мышления, нам все равно было трудно убедиться, что мы оба делаем одно и то же. Лично для меня СДВГ может означать, что Леон, который сделал что-то утром, отличается от Леона, который сделал это позже в тот же день.

Большие декларативные файлы
Убедиться, что пара тысяч строк YAML/JSON правильно отформатированы, с правильными фрагментами в нужных местах, сложно. Это до того, как вы захотите начать писать большие наборы команд в качестве сценария запуска!

Дублирование усилий
Мы тратили много времени на выполнение одной и той же работы снова и снова, что также означало, что по мере нашей занятости изменения не учитывались в службах из-за того, что они глубоко вложены в YAML. файлы.

Медленные циклы обратной связи
Изменения подразумевали применение обновлений, обновления могли занимать много времени. Особенно, если вы допустили опечатку или ошибку, то есть вам пришлось ждать некоторого внутреннего тайм-аута. Слишком много раз я просто собирал вещи на день, потому что какие-то изменения портили стек и застревали на несколько часов.

Переключение контекста
Было очень сложно провести весь день, погрузившись в какую-то малоизвестную проблему с планом набора номера Asterisk, чтобы затем переключиться на выяснение проблемы с инструментами. Теперь эта проблема может затронуть кого-то с СДВГ в большей степени, так что с ней по-прежнему сталкиваются все.

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

Решение

Однажды ко мне пришел мой начальник на работе[-1], залезший в кроличью нору с Тропосферой. Для тех, кто не в курсе, это библиотека для создания корректного CloudFormation через Python. Вот и все, наконец-то я смог сделать то, о чем вся индустрия говорила повсюду, я мог начать писать Инфраструктура как код!

В последующие недели я сосредоточился на решении проблем, которые меня действительно расстраивали. Я добавил автомасштабирование, балансировщики нагрузки, ведение журналов по умолчанию и многое другое. Базовая платформа перешла от нескольких разрозненных инструментов для ведения журналов к их автоматическому получению, поскольку я добавил их к одному из других сервисов, которые нуждались в централизованном ведении журналов гораздо больше.

Мы медленно, но верно тратили меньше времени на управление гигантской коллекцией файлов YAML и вместо этого нашли способы оптимизировать наши рабочие процессы, повысить нашу безопасность, ужесточить наши средства управления IAM и вернуться к основным частям работы, поскольку мы единственные 2 разработчика. в быстрорастущем стартапе.

Когда пришло время уйти от этой роли, внутренний рекрутер предложил мне роль DevOps, которая предполагала, что их разработчики и платформа будут двигаться к более эффективным процессам, что позволит поддержать рост электронной коммерции. версия Вечного сентября в марте 2020 года.

Теперь, в рамках этого, я переключился с Amazon Web Services на Google Cloud. Поскольку Troposphere очень сильно зависит от CloudFormation и учитывая, что даже AWS начинает инвестировать в инструменты, не относящиеся к конкретным поставщикам, Terraform казался очевидным выбором.

Однако, когда я искал даже что-то вроде Troposphere для GDM, который активно поддерживался, ничего не нашел. И тут меня осенило: я провел большую часть десятилетия, думая, что «инфраструктура как код» — это просто использование чего-то вроде Python для автоматизации изменений инфраструктуры. Я находился в достаточно экзистенциальном кризисе, так как испытав на себе тяготы чисто декларативного ИаК, я не знал, что делать!

В какой-то момент я наткнулся на правильный набор ключевых слов, я узнал, что в отрасли был введен термин «CDK» или Cloud Development Kit для процесса использования функциональных или объектно-ориентированных языков программирования, с которыми разработчики уже знакомы. Поэтому, посоветовавшись с коллегами, продавцами и друзьями, я пришел к разным мнениям. От непонимания сути дела до прямого предположения, что еще слишком рано смотреть на CDK для Terraform, но, что наиболее важно, поддержка моего босса в то время, чтобы придумать концепцию MVP, которая поможет нам двигаться дальше.

Краткое содержание

Прошло чуть более 12 месяцев с тех пор, как я сделал тот первый коммит, но с тех пор мы перешли от одного типа «стека» к нескольким десяткам. Он выполнил › 5000 автоматизированных развертываний и прошел путь от того, что я представлял для наших MicroServices, до поддержки всех видов вариантов использования, требуемых от разработчиков. Момент, который действительно выделялся в последнее время, это то, что разработчик на второй или третьей неделе хотел поэкспериментировать с новым сервисом, и я даже не знал, что они создают конфигурацию, пока у них не возник вопрос! Я ответил и вернулся к делу, над которым работал. Я проверил позже, и их сервис был создан, развернут, с балансировщиком нагрузки, автоматическим масштабированием, автоматическим восстановлением, полностью управляемым через GitHub Actions и без прямого участия со стороны Ops. Комментарий, который я получил от них: «Да, я был немного сбит с толку около дня, а потом все это обрело смысл», что, поскольку кто-то, кто проработал в компании меньше месяца, смог развернуть совершенно новый сервис в нашем тесте. среда. Вероятно, это было довольно освежающим для них и действительно полезным для меня.

В следующей статье я углублюсь в детали, но, когда я говорил об этом с людьми, которым представил эту концепцию, на ум приходят три вещи.

  • Полностью модульное тестирование IaC. Мы можем изменить любую часть кода, которая генерирует нашу результирующую конфигурацию, и быть уверенными, что то, что мы передаем Terraform для применения, является правильным.
  • Файлы состояния. Поскольку нам не нужно пытаться уменьшить количество управляемых стеков, разбить их на отдельные стеки очень просто. Любые проблемы с состоянием не создают каких-либо масштабных последствий для операций.
  • Версии провайдера и доступность. Инструменты обеспечивают доступность провайдера с правильной версией, их миграция является лишь частью ответственности инструментов. Поскольку мы можем тщательно протестировать эти пути, применить их шире так же просто, как выпустить новую версию нашей внутренней оболочки CDK.

Настоящий TL;DR

За все время работы с Terraform я написал ‹ 100 строк HCL. Никто не должен писать Terraform, даже я.