интеллектуальная карта

Предисловие

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

HCL2

В версии Terraform 0.12 базовый язык полностью обновлен с HCL до HCL2. Обновление включает поддержку первоклассных выражений (поэтому нет необходимости заключать переменные в ${...}), расширенные ограничения типов, отложенное вычисление условных выражений, поддержку null, for_each и выражений, поддержку динамических встроенных выражений. блоки и многое другое

Вы можете не только использовать Terraform для управления другими типами облачных платформ (таких как Alicloud, Oracle Cloud Infrastructure, VMware vSphere и т. д.), вы также можете использовать Terraform для управления системами, отличными от облачных платформ, в виде кода: включая системы контроля версий ( такие как GitHub, GitLab или BitBucket), системы хранения данных (такие как MySQL, PostreSQL или InfluxDB), системы мониторинга и оповещения (такие как DataDog, New Relic или Grafana), инструменты платформы (такие как Kubernetes, Helm, Heroku, Rundeck или Rightscale) и т. д.

https://github.com/brikis98/terraform-up-and-running-code

Миссия Gruntwork — в 10 раз упростить разработку и развертывание программного обеспечения.

Зачем использовать Терраформ

Доставка программного обеспечения — это процесс окончательной «видимости и доступности» кода для клиентов посредством ряда работ. Например, запуск кода на рабочем сервере позволяет коду справляться с резкими скачками трафика данных и непредвиденными простоями, а также защищать его. Код защищен от злоумышленников

Расцвет DevOps

Поначалу это работает нормально, но со временем по мере роста вашей компании вы сталкиваетесь с проблемами. Проблема часто заключается в следующем: поскольку выпуск программного обеспечения выполняется вручную, по мере увеличения количества серверов процесс выпуска становится медленным, болезненным и непредсказуемым. Операционные группы иногда допускают ошибки, в результате которых каждый сервер в среде настраивается более или менее иначе, чем любой другой сервер (эта проблема называется конфигурацией). drift,Прямо сейчас Дрейф конфигурация), а не стандартизированная конфигурация сервера снежинок（snowflake сервер), что приводит к большему количеству ошибок.

DevOps имеет четыре основные ценности: культура, автоматизация, измерение и совместное использование, иногда сокращенно CAMS.

Что такое инфраструктура как код

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

Terraform по сравнению с другими инструментами IaC

Chef, Puppet, Ansible и SaltStack принадлежат Инструментам. управления конфигурацией,иCloudFormation、TerraformиOpenStack HeatВсе Инструмент активации услуги. На самом деле разница не очевидна, Инструменты управления Конфигурация обычно допускает определенный уровень подготовки (например, использование сервера Ansibleразвертывание), Инструмент активации услуг обычно также позволяет осуществлять некоторый уровень управления конфигурацией (например,,Используйте Terraform для настройки сервера и запуска скрипта конфигурации).

По умолчанию Ansible, CloudFormation, Heat и Terraform — все Нет основного программного обеспечения сервера управления.。Точнее,Некоторые из них могут зависеть от главного сервера.,Но эти серверы уже являются частью инфраструктуры, которую вы используете.,Не требуя от вас управления дополнительными компонентами. Например,Terraform использует API поставщика облачных услуг для связи с облачной платформой.,в некотором смысле,Сервер API играет роль главного сервера.,Просто им не требуется никакой дополнительной инфраструктуры или дополнительных механизмов аутентификации (просто используйте существующие ключи API).

Рисунок 1-8. Архитектура Terraform с использованием бессерверного режима и безагентного программного обеспечения.

Инструмент активации услуги + инструмент управления конфигурацией

Например, используйте Terraform и Ansible вместе, как показано на рисунке 1-9. Вы можете использовать Terraform для развертывания всей инфраструктуры, включая топологию сети (например, виртуальное частное облако VPC, подсети, таблицы маршрутизации), хранилища данных (например, MySQL, Redis), балансировщики нагрузки и серверы. Затем приложение развертывается на этих серверах с помощью Ansible.

Рисунок 1-9: Использование Terraform с Ansible

Инструмент активации службы + инструмент шаблона сервера

Например, используйте Terraform и Packer вместе, как показано на рисунке 1-10. Используйте Packer для упаковки приложений в образы виртуальных машин. Затем Terraform используется для развертывания: серверов, на которых работают эти образы виртуальных машин, а также другой инфраструктуры, включая топологию сети (например, VPC, подсети, таблицы маршрутов), хранилища данных (например, MySQL, Redis) и балансировщики нагрузки.

Рисунок 1-10. Совместное использование Terraform и Packer.

Инструмент активации службы + шаблон сервера + инструмент оркестрации

Например, используйте Terraform, Packer, Docker и Kubernetes вместе, как показано на рис. 1-11. Вы можете использовать Packer для создания образов виртуальных машин, включающих службы Docker и Kubernetes. Затем через Terraform развертывается кластер серверов, при этом на каждом сервере выполняется этот образ виртуальной машины вместе с остальной инфраструктурой, включая топологию сети (т. е. VPC, подсети, таблицы маршрутизации), хранилища данных (например, MySQL, Redis) и балансировщики нагрузки.

Рисунок 1-11. Совместное использование Terraform, Packer, Docker и Kubernetes.

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

Таблица 1-4: Сравнение использования популярных инструментов IaC

Начало работы с Терраформом

Развертывание одного сервера

где PROVIDER — имя провайдера (например, aws). TYPE — это тип ресурса, созданный в этом провайдере (например, экземпляр). NAME — это идентификатор, по которому вы можете ссылаться на ресурс (например, my_instance) по всему блоку кода Terraform. CONFIG включает один или несколько параметров или групп параметров, специфичных для ресурса.

существовать По умолчанию,Код провайдера будет загружен в папку .terraform.,Эта папка является временным каталогом Terraform (пользователю может потребоваться добавить ее в .gitignore).,чтобы предотвратить загрузку этого временного каталога в систему контроля версий).

Вывод команды плана,Аналогично команде diff, используемой в UNIX, Linux и Git: знак плюса (+) обозначает любое новое добавленное содержимое.,Знак минус (-) обозначает удаленное содержимое.,Тильда (~) обозначает все содержимое, которое будет изменено.

Создайте файл с именем .gitignore, который сообщит Git игнорировать определенные типы файлов, чтобы вы случайно не сохранили временные файлы в своей системе контроля версий.

содержимое предыдущего файла .gitignore,Попросите Git игнорировать временный каталог Terraform, папка .terraform.,И файл *.tfstate, используемый Terraform для хранения состояния.

Развертывание одного веб-сервера

Любой объект в Terraform, имеющий возвращаемое значение, называется выражением. Вы видели простейшие типы выражения, такие как строки (например, «ami-0c55b159cbfafe1f0») и числа (например, 5).

Ссылка — особенно полезный тип выражения.,Это позволяет пользователю получить доступ к значению из других частей кода. Если вы хотите получить доступ к идентификатору ресурса группы безопасности,Необходимо использовать ссылку на атрибут ресурса (resource attribute ссылка), синтаксис этой ссылки следующий.

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

Формат приведенного выше вывода — язык описания графов DOT. С помощью таких инструментов, как настольные приложения, такие как Graphviz, или веб-приложения GraphvizOnline (см. Ссылки, глава 2 [20]), экземпляр EC2, аналогичный показанному на рисунке 2-7. может быть автоматически создан график зависимостей его групп безопасности.

Развертывание настраиваемого веб-сервера

type

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

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

Вы также можете установить начальное значение входных переменных через переменные среды. Соглашение об именах — TF_VAR_, где — имя входной переменной, которую вы хотите установить.

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

Ниже приведен пример установки параметров from_port и to_port ресурса группы безопасности в значение переменной server_port.

При настройке порта в скрипте пользовательских данных,Лучше использовать одну и ту же входную переменную. Использование переменных кавычек в строковых литералах,Нужно передать своего рода интерполяцию (интерполяцию) выражения,Его синтаксис следующий.

Пользователь может поместить любую допустимую ссылку на переменную в фигурные скобки, и Terraform преобразует ее в строку. Например, используйте следующий метод, чтобы вставить значение var.server_port в пользовательские данные в виде строки.

Terraform также позволяет определять выходные переменные, используя следующий синтаксис:

NAME — это имя выходной переменной, а VALUE — любое выражение Terraform, которое вы хотите вывести. CONFIG содержит два необязательных параметра.

senstitive

Если для этого параметра установлено значение true, Terraform не будет записывать выходную информацию в журнал при запуске команды terraform apply. Это очень полезный способ предотвратить запись конфиденциальной информации, такой как пароли или закрытые ключи, в выходные переменные.

Запустите команду вывода terraform, чтобы просмотреть значение конкретной выходной переменной с именем.

Статус терраформирования

Файл статуса карантина

У вас есть 3 доступных рабочих пространства, которые можно просмотреть с помощью команды списка рабочих пространств terraform.

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

Рекомендуется использовать отдельные папки Terraform (и, следовательно, отдельные файлы состояния) для каждой среды (предварительная версия, производственная и т. д.) и каждого компонента (VPC, сервис, база данных).

Terraform apply необходимо запускать несколько раз для каждой папки (обратите внимание, что с помощью Terragrunt этот процесс можно автоматизировать с помощью команды apply-all).

источник данных terraform_remote_state Обратите внимание, что перед командой экспорта намеренно имеется пробел, чтобы предотвратить сохранение конфиденциальной информации в истории Bash.

Лучший способ избежать случайного сохранения секретов в виде обычного текста на диске — использовать хранилище секретов, дружественное к командной строке, например pass (см. главу 3 [10]), используя подпроцесс «Безопасное чтение секретов из pass в переменные среды».

Доступ к коду кластера веб-сервера можно получить, используя источник данных terraform_remote_state для чтения данных этого файла состояния. этап/услуги/вебсерверкластер/ Источник данных в main.tf определяется следующим образом.

Запустите консольную команду терраформирования, чтобы открыть интерактивную консоль.,Интерактивная консоль — отличный способ поэкспериментировать со встроенными функциями. Запустить синтаксис Terraform,Запрос состояния инфраструктуры,и немедленно возвращает результаты.

Эта функция читает файлы, определенные в параметре PATH.,и возвращает его содержимое в виде строки. Например,Вы можете поместить скрипт пользовательских данных в файл stage/services/webserver-cluster/user-data.sh.,и загрузите его содержимое как строку,Как показано ниже.

Трудность в том,,В скрипте пользовательских данных кластера веб-серверов,Нужны некоторые динамические данные из Terraform.,Включая порт сервера, адрес базы данных и порт базы данных. Раньше вы могли использовать интерполяцию Terraform.,Вставить цитату вTerraform代码из用户数据脚本中。Но это не работает дляфайловая Функция, необходимо передать источник данных template_file работает вместе.

источник данных template_file имеет два параметра: template, который определяет обрабатываемые строковые переменные, которые представляют собой отображение коллекции переменных, которая будет использоваться при обработке строк. Он имеет выходной атрибут, называемый rendered, который создается после обработки результата шаблона. Давайте выполним фактическую операцию и изменим следующий источник данных Код template_file добавлен в stage/services/ в файле webserver-cluster/main.tf.

Как видно из приведенного выше кода, параметр шаблона указывает на сценарий user_data.sh, а параметр vars включает три переменные, необходимые в сценарии пользовательских данных: порт сервера, адрес базы данных и порт базы данных. Чтобы использовать эти переменные, вам необходимо обновить сценарий stage/services/webserver-cluster/user-data.sh следующим образом.

Последний шаг — Обновить ресурс Параметр user_data в aws_launch_configuration, чтобы он указывал на источник. данных template_fileизrenderedвыходпеременная。

Создайте многоразовую инфраструктуру с помощью модулей Terraform.

Рисунок 4-3. Помещение кода в модуль позволяет повторно использовать его в нескольких средах.

Модульность — ключевой элемент в написании многократно используемого, поддерживаемого и тестируемого кода Terraform. Как только вы начнете использовать,Вам понравятся модули, и вы начнете их пробовать: Модульизируйте всю функцию своего кода.,Создать общую библиотеку модулей в компании,Используйте модули, найденные в Интернете,Даже представьте себе всю инфраструктуру как набор повторно используемых модулей.

Основы модуля

Создайте новую папку верхнего уровня с именем Modules и переместите все файлы из папки stage/services/webserver-cluster в папку elements/services/webserver-cluster. Окончательная структура папок с модулями и предварительными средами показана на рис. 4-4.

Рис. 4-4. Окончательная структура папок с модулями и предварительной версией среды.

Откройте файл main.tf в каталоге elements/services/webserver-cluster и удалите определение провайдера. Потому что соответствующее определение провайдера должно появиться в пользовательском коде, вызывающем модуль, а не в конфигурации самого модуля.

Теперь используйте синтаксис этого модуля в предварительной версии.

Среди них NAME — это идентификатор, который можно использовать для ссылки на этот модуль (например, веб-сервис) в коде Terraform, SOURCE — это путь к коду модуля (например, модули/сервисы/кластер веб-сервера), а CONFIG включает в себя один или несколько параметров, уникальных для этого модуля. Например, вы можете создать новый файл stage/services/webservercluster/main.tf и вызвать модуль webserver-cluster следующим образом.

вход модуля

Модули Terraform также могут иметь входные параметры. Чтобы определить их, вы используете уже знакомый механизм: входные переменные. Откройте модули/сервисы/webserver-cluster/variables.tf и добавьте 3 новые входные переменные.

Затем в файле elements/services/webserver-cluster/main.tf используйте var.cluster_name вместо статически закодированного имени (например, вместо terraform-asg-example). Это модификация группы безопасности ALB.

Теперь в файле stage/services/webserver-cluster/main.tf предварительной версии эти новые входные переменные необходимо установить соответствующим образом.

Теперь в предварительной версии среды (stage/services/webserver-cluster/main.tf) вы можете сохранить небольшой размер кластера и низкие накладные расходы, установив для параметра instance_type значение «t2.micro», а для min_size и max_size — 2 соответственно.

С другой стороны, в производственной среде вы можете использовать тип экземпляра с большим количеством ЦП и памяти, например m4.large (обратите внимание, что этот тип экземпляра не является частью уровня бесплатного пользования AWS. Так что, если вы просто учитесь и не если вы хотите нести накладные расходы, продолжайте устанавливать тип экземпляра на «t2.micro»), а затем вы можете установить max_size на 10, позволяя кластеру уменьшаться или расти в зависимости от нагрузки (не волнуйтесь, кластер только запустится). изначально два экземпляра).

Контроль версий модуля

Рисунок 4-6: Структура файла с несколькими репозиториями.

Чтобы настроить эту структуру папок, сначала необходимо переместить папки stage, prod и global в папку live. Затем настройте папки live и модули как независимые репозитории Git. Ниже приведен пример настройки папки модулей в качестве репозитория Git.

Вы можете указать исходные параметры в модуле предварительной версии среды и модуле производственной среды на разные URL-адреса Git, чтобы реализовать контроль версий модуля. Если репозиторий модулей находится в репозитории GitHub github.com/foo/modules, следующий формат исходного параметра в файле live/stage/services/webserver-cluster/main.tf (обратите внимание, что двойная косая черта в требуется следующий URL-адрес Git).

Вы можете использовать эту новую версию, просто обновив исходный URL-адрес в предварительной среде (live/stage/services/webserver-cluster/main.tf).

В производственной среде (live/prod/services/webserver-cluster/main.tf) вы можете продолжать использовать версию 0.0.1.

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

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

цикл

Чтобы добиться чего-то подобного в Terraform, вы можете использовать переменную count.index для получения значения индекса для каждой итерации цикла.

Терраформирующая ловушка

Есть два основных урока.

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

Когда часть инфраструктуры уже находится под управлением Terraform,Никогда не меняйте его вручную. в противном случае,Вы не только столкнетесь со всевозможными странными ошибками Terraform.,И вы упустите многие преимущества использования Инфраструктуры в виде кода (IaC).,Потому что код больше не точно отражает вашу инфраструктуру.

Для информации об уже существующей инфраструктуре, пожалуйста, обратитесь к существующей инфраструктуре.

Если вы уже создали инфраструктуру до того, как начнете использовать Terraform, вы можете использовать команду импорта terraform, чтобы добавить инфраструктуру в файл состояния Terraform, чтобы Terraform мог управлять инфраструктурой. Команда импорта имеет два параметра. Первый параметр — это «адрес» ресурса в файле конфигурации Terraform. Здесь используется тот же синтаксис, что и для ссылок на ресурсы: _ (например, aws_iam_user.existing_user). Второй параметр — это идентификатор ресурса, который идентифицирует импортируемый ресурс. Например, идентификатор ресурса aws_iam_user совпадает с именем пользователя (evgeniy.brikman), а идентификатор ресурса aws_instance — это идентификатор экземпляра EC2 (i-190e22e5). Внизу страницы каждого ресурсного документа обычно есть описание того, как его импортировать.

4 основных урока.

Всегда используйте команду плана

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

Создать, прежде чем уничтожить

Если вы заменяете ресурс, внимательно подумайте, нужно ли вам его создавать, прежде чем удалять. Если вам это нужно, вы можете добиться этого с помощью параметра create_before_destroy. Альтернативно, того же эффекта можно добиться двумя действиями вручную: сначала добавьте новый ресурс в конфигурацию и запустите команду Apply, затем удалите старый ресурс из конфигурации и снова запустите команду Apply;

Изменение идентификатора требует изменения файла состояния

Если вы хотите изменить идентификатор, связанный с ресурсом (например.,Переименуйте aws_security_group из экземпляра в кластер_экземпляр),без случайного удаления и пересоздания ресурса,тогда необходимо Статус Файлы терраформирования обновляются соответствующим образом. Никогда не обновляйте Статус вручную терраформированиядокумент,и要использование Команда терраформированияstate для завершения обновления. Запуск необходим при переименовании идентификатора терраформирование state mv, которая имеет следующий синтаксис.

Где ORIGINAL_REFERENCE — это текущая ссылка на выражение ресурса, а NEW_REFERENCE — это новое место, в которое вы хотите его переместить. Например, если вы хотите переименовать aws_security_group из экземпляра в кластер ter_instance, вам нужно запустить следующую команду.

Указывает Terraform изменить все состояния, ранее связанные с aws_security_group.instance, на связанные с aws_security_group.cluster_instance. Если вы запустите эту команду после переименования идентификатора, в дальнейшем Запустить терраформирование Команда plan не покажет никаких изменений.

Некоторые параметры неизменяемы

Многие параметры ресурса изменить нельзя. Если вы измените их,Terraform удалит старый ресурс и создаст вместо него новый. В документации к каждому ресурсу обычно объясняется, что произойдет, если вы измените параметры.,Поэтому, пожалуйста, выработайте у себя хорошую привычку просматривать документацию. Снова,пожалуйста Всегда используйте команду спланируйте и подумайте, следует ли использовать create_before_ уничтожить стратегию.

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

Код Terraform промышленного уровня

Таблица 6-1. Время, необходимое для создания инфраструктуры производственного уровня с нуля

Возможности модуля инфраструктуры производственного уровня

1. Модули необходимо миниатюризировать.
2. Сборные модули
3. Тестируемые модули
4. съемные модули
5. контент вне модуля Terraform

Контрольный список инфраструктуры производственного уровня

Таблица 6-2: Контрольный список инфраструктуры производственного уровня

Возможности модуля инфраструктуры производственного уровня

Модули необходимо миниатюризировать.

Новички в Terraform и IaC часто определяют всю инфраструктуру и все среды (например, Dev, Stage, Prod и т. д.) в одном файле или одном модуле.

Упоминается в «Чистом коде»: первое правило функций — они должны быть маленькими; второе правило — они должны быть меньше;

Рисунок 6-2. Рефакторинг относительно сложной архитектуры AWS на множество небольших модулей.

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

Инструменты ручного тестирования

При разработке модуля asg-rolling-deploy,На основе этого примера кода,Можно сделать вручную,неоднократно Запустить терраформирование применить и терраформировать destro, чтобы проверить, работает ли она должным образом.

Инструменты автоматического тестирования

Как вы увидите в главе 7, пример кода аналогичен созданию автоматических тестов для ваших модулей. Обычно я рекомендую помещать тесты в папку с тестами.

исполняемый документ

Если этот пример (включая README.md) будет отправлен в систему контроля версий, другие члены команды смогут использовать его, чтобы понять, как работает модуль, и опробовать модуль без написания кода. Это одновременно и способ обучения других членов команды, и обеспечение того, чтобы «учебное пособие» всегда работало должным образом путем добавления автоматических тестов.

Каждый модуль Terraform, который у вас есть в папке модулей, должен иметь соответствующий пример в папке примеров, а каждый пример в папке примеров должен иметь соответствующий тест в папке тестов. Фактически, каждый модуль может иметь несколько примеров (и, следовательно, несколько тестов), демонстрирующих различные конфигурации и варианты модуля. Например, добавьте дополнительные примеры для модуля asg-rolling-deploy, показывающие, как использовать его с политиками автомасштабирования, как подключить балансировщик нагрузки к модулю, как устанавливать пользовательские метки и т. д.

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

Другой способ опубликовать модули — опубликовать их в реестре Terraform. Публичный реестр Terraform расположен в справочной главе 6 [6] и включает в себя сотни повторно используемых, поддерживаемых сообществом модулей с открытым исходным кодом для AWS, Google Cloud, Azure и многих других поставщиков. Публикация модуля в общедоступном реестре Terraform имеет следующие требования. [2]

● Модуль должен быть размещен в общедоступном репозитории GitHub. ● Репозитории должны следовать соглашению об именах terraform: где PROVIDER указывает целевого поставщика модуля (например, aws), а NAME — это имя модуля (например, vault). ● Модули должны следовать определенной файловой структуре, включая определение кода Terraform в корневом каталоге репозитория, предоставление файла README.md и использование обычных имен файлов, таких как main.tf,variable.tf и outputs.tf. ● База кода должна быть выпущена с использованием тегов Git (x.y.z), которые соответствуют правилам семантического управления версиями.

Если ваш модуль соответствует этим требованиям, вы можете войти в центр регистрации Terraform с учетной записью GitHub и опубликовать модуль с помощью веб-интерфейса, чтобы поделиться им с другими. Когда модуль будет опубликован в центре регистрации, он будет иметь красивый интерфейс для отображения сведений о модуле, как показано на рисунке 6-4 для модуля HashiCorp Vault в центре регистрации Terraform. Центр регистрации Terraform может автоматически анализировать входные и выходные данные модуля, поэтому эти входные и выходные переменные также будут отображаться в интерфейсе, включая поля типа и описания, как показано на рисунке 6-5.

Рисунок 6-4: Модуль HashiCorp Vault в реестре Terraform.

Сотрудничество

Золотые правила Terraform

Основная ветка кода действующего репозитория должна представлять собой 1:1 фактическое развертывание в рабочей среде.。

«…что на самом деле развернуто»

Единственный способ гарантировать, что код Terraform в активном репозитории представляет новейшую целевую среду, — никогда не вносить изменений за пределы инструментов. После того, как вы начнете использовать Terraform, не вносите изменения через веб-интерфейс, вызовы API вручную или любой другой механизм. Как вы узнали из главы 5, изменения вне инструмента могут не только привести к сложным ошибкам, но и свести на нет многие преимущества, которые уже дает использование IaC.

«...формат 1:1 представляет...»

При просмотре живого репозитория,Путем быстрого сканирования кода,Должна быть возможность увидеть, какие ресурсы в каких средах используются. другими словами,Каждый ресурс должен иметь возможность найти совпадение 1:1.,Проверьте строки кода в реальном репозитории. То, что кажется простой истиной, легко может пойти не так. как я только что упомянул,Один из способов вызвать ошибки — внести изменения вне инструмента.,Это приводит к тому, что код существует,但实时基础设施却是不同из。一种更微妙из错误是由于использовать Терраформировать рабочее пространство для управления средой привело к тому, что, хотя инфраструктура реального времени была установлена, код не был сохранен. То есть, если вы используете Терраформировать рабочее пространстворазвернуть на 3 или 30 сред,Но также возможно, что в базе действующего кода имеется только одна копия кода. Просто просмотрев код,Невозможно узнать, какие ресурсы на самом деле доступны.,Это приведет к ошибкам и усложнит обслуживание. поэтому,Как описано в главе 3 «Изоляция посредством рабочих пространств».,Старайтесь избегать использования рабочих пространств для управления средой.,Вместо этого используйте отдельные файлы и папки для определения каждой среды.,Для достижения цели точного понимания среды развертывания путем просмотра базы кода в реальном времени. далее в этой главе,Мы научимся это делать с помощью небольшого копирования/вставки.

«Главное отделение...»

Вам достаточно взглянуть на одну ветку, чтобы увидеть, как выглядит фактическая развертывание в продакшене. Обычно эта ветка будет основной. это означает,Все изменения, влияющие на производственную среду, должны поступать непосредственно в основную ветку (для разработки можно создать отдельную ветку).,Но в конце концов это должно пройтиpull запрос объединяется с основной веткой). развертывание для производственной среды должно происходить на главной ветке Запустить терраформирование применить команду.

В Terraform даже есть встроенная команда fmt, которая может автоматически переформатировать стиль кода.

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

Terragrunt

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

Terragrunt будет использовать указанную команду для вызова Terraform и добавит некоторые дополнительные варианты поведения на основе конфигурации файла terragrunt.hcl. Основная идея заключается в том, что в репозитории модулей определен один и тот же код Terraform, а файл terragrunt.hcl в реальном репозитории обеспечивает краткий способ настройки и развертывания отдельных модулей в каждой среде. На рис. 8-5 показано расположение файлов после использования Terragrunt, что значительно сократит количество файлов и строк кода в репозитории реального времени.

Сначала добавьте конфигурацию провайдера в файлы elements/data-stores/mysql/main.tf и elements/services/hello-world-app/main.tf.

Рисунок 8-5: Структура файла после использования Terragrunt

Затем в файлах elements/data-stores/mysql/main.tf и elements/services/hello-world-app/main.tf добавьте конфигурацию бэкэнда, но оставьте блок конфигурации пустым (вы увидите, как использовать Terragrunt через мгновение заполните этот пустой блок).

Зафиксируйте эти изменения и опубликуйте новую версию модуля.

Теперь перейдите в действующий репозиторий и удалите все файлы с суффиксом .tf. Вместо копирования/вставки кода Terraform пользователям необходимо создать файл terragrunt.hcl для каждого модуля. Например, вот файл live/stage/datastores/mysql/terragrunt.hcl.

Как видите, файл terragrunt.hcl использует тот же синтаксис языка конфигурации HashiCorp (HCL), что и Terraform. При запуске команды terragrunt apply код найдет исходный параметр в файле terragrunt.hcl, а затем Terragrunt выполнит следующие операции.

1. Проверьте код URL-адреса, указанного в исходном коде, во временную папку. Параметр source поддерживает тот же синтаксис URL-адресов, что и модули Terraform, поэтому вы можете использовать пути к локальным файлам, URL-адреса Git, URL-адреса Git с поддержкой версий (через параметр ref, как показано в примере выше) и т. д.
2. Во временной папке Запустить терраформирование применить команду, входные данные = { … }Входная переменная, определенная в блоке кода, передается ему. Преимущество этого подхода заключается в том, что код в активном репозитории будет сокращен до одного файла terragrunt.hcl для каждого модуля, который содержит указатель на используемый модуль (указывающий на конкретную версию) и настройки для конкретной версии. Environment Вход переменная. Это самый чистый код, который вы можете получить. Terragrunt также может упростить конфигурацию серверной части. Нет необходимости повторно определять Bucket, Key, dynamodb_table и другие параметры для каждого модуля. Вместо этого он определяется в файле terragrunt.hcl для каждой среды. Например, файл live/stage/terragrunt.hcl.

В блоке кода Remote_state настройте параметр backend так же, как обычно, но с немного другим значением ключа. В значении ключа используется встроенная функция Terragrunt path_relative_to_include(). Эта функция возвращает относительный путь между корневым файлом terragrunt.hcl и всеми подмодулями, содержащими этот файл. Например, чтобы включить этот корневой файл в live/stage/data-stores/mysql/terragrunt.hcl, просто добавьте блок включения.

во включаемый блок кода,Найдите файл terragrunt.hcl в корневом каталоге с помощью встроенной функции Terragrunt find_in_parent_folders(). Автоматически наследовать все настройки из этого родительского файла.,Включает конфигурацию Remote_state. оказаться,Модуль mysql будет использовать все те же настройки серверной части из корневого файла.,Только значение ключа будет автоматически анализироваться как data-stores/mysql/terraform.tfstate. Это означает, что файлы Статуса терраформирования будут сохранены в той же структуре папок, что и действующий репозиторий.,Это позволит легко определить, какой модуль создал какой файл состояния.

Чтобы развернуть этот модуль, запустите terragrunt применить команду.

В выводе журнала вы можете видеть, что Terragrunt прочитал файл terragrunt.hcl и загрузил указанный модуль, Запустить терраформирование команда init для настройки бэкэнда (он даже автоматически создаст S3, если он еще не существует) корзину и таблицу DynamoDB), затем Запустить терраформирование applyЗаказразвертыватьвсесодержание。 Теперь запустите terragrunt в предварительной версии, добавив файл live/stage/services/hello-world-app/terragrunt.hcl. Команда Apply для развертывания модуля hello-world-app.

Этот модуль использует блок включения для наследования тех же настроек серверной части из файла terragrunt.hcl в корневом каталоге.,И ключевое значение соответствует ожиданиям,Будет автоматически обновлено до Services/hello-world-app/terraform.tfstate. После того, как все работает правильно в предварительной версии,Далее вы можете создать аналогичный файл terragrunt.hcl в каталоге live/prod.,通过существовать每个模块中Запустить террагрунт Apply команду, чтобы перенести те же самые артефакты версии v0.0.7 в производственную среду.

Соединяем вышеперечисленные пункты вместе

Таблица 8-1: Сравнение рабочих процессов кода приложения и кода инфраструктуры

Рисунок 8-6. Продвижение версионных неизменяемых артефактов в каждую среду.