Чтобы следовать с этой главой, вам потребуется обладать базовыми знаниями о различных вариантах IaC, включая шаблоны ARM и AWS CloudFormation, в то время как полезным будет также и понимание основ главных поставщиков облачных решений, таких как GCP, AWS и Azure.

Прежде чем изучать Terraform, давайте попробуем разобраться с тем, что он в своей основе значит для нас и как он помогает нам превращать жизнь пользователей ИТ отрасли в более простую. Самое первое что приходит в голову потребителям, когда им требуется некая ИТ инфраструктура, например, если они хотят некую виртуальную машину, им потребуется поднять некий билет в каком- то портале билетов, скажем, ServiceNow, и кто- то из серверной части зарегистрирует его в портале билетов и возьмёт данный билет из общей очереди и развернёт для его пользователя необходимую виртуальную машину, либо в среде VMware, либо в среде HyperV через свой портал управления применяя некоторые клики по заданиям. Именно таков традиционный подход для развёртывания инфраструктуры, который до некоторой степени удобен когда требуется управлять инфраструктурой в их частном центре обработки данных и имеется очень небольшая вероятность выполнения масштабирования таких развёрнутых ресурсов, что означает, что после их предоставления уже никто не будет запрашивать последующее изменение такого созданного ресурса.

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

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

В таком случае потребителям потребуется выставить 1000 билетов на выполнение расширения масштаба и снова ещё 1000 билетов для масштабирования вниз под конец дня, управляющий этим системный администратор будет залит под занавес таким большим числом запросов и ему в действительности было бы невозможно обрабатывать их. Итак, здесь у нас имеется нечто, носящее название IaC, что является неким способом развёртывания или управления всей инфраструктурой неким автоматическим способом. Все те ресурсы, которыми требуется управлять, будут определяться в формате кода и мы сможем удерживать такой код в любом репозитории управления исходным кодом, скажем, в GitHub или Bitbucket. Затем мы запросто можем воспользоваться неким DevOps подходом для управления своей инфраструктурой. Существует большое число преимуществ IaC и мы намерены обсудить некоторые из них.

Давайте обсудим некоторые преимущества IaC.

Применяя IaC вы будете способны раскрутить полную архитектуру инфраструктуры простым выполнением некого сценария.

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

Всё это вы можете сделать написав простые строки кода.

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

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

Когда мы вручную управляли инфраструктурой, было замечено, что лишь горстка специалистов в предметной области (Subject Matter Experts, SME) знает как выполнять это, а прочие члены команды оставались свободными, что вводит зависимость и риски безопасности для вашей организации. Просто задумайтесь о ситуации, при которой тот человек, который отвечает за управление всей инфраструктурой целиком покидает вашу организацию; это означает, что он мог не делиться всем что он знал, либо он мог не обновить установленные документы. В конце концов, в вашу организацию вносится риск по причине того что работник покидает организацию. Во многих случаях в подобной ситуации вашей организации придётся пройти обратную инженерную подготовку для исправления каких бы то ни было проблем.

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

В наши дни, при привлечении IaC для предоставления инфраструктуры и управления ею, разработчики получают больше времени на то, чтобы сосредоточиться на производительности. Всякий раз когда им требуется запускать среду песочницы для разработки сетевого кода, они запросто могут это сделать. Аналитик качества (quality analyst, QA) будут иметь возможность обладать копией кода и проверять его в обособленно среде. Аналогично, тестирование безопасности и приемлемости пользователю также могут выполняться в различных промежуточных средах. Всего лишь одним кликом и код приложения, и код инфраструктуры могут выполняться совместно следуя технологиям непрерывной интеграции и непрерывного развёртывания (Continuous Integration and Continuous Deployment, CI/CD).

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

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

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

Для получения представления об IaC и преимуществах его применения, давайте двинемся далее и попытаемся узнать некие подробности об одной технологии IaC - Terraform.

Добро пожаловать в этот вводный курс в Terraform. Для каждого, для кого Terraform внове, и он не знал ранее о нём, а также для цели сопоставления с прочими инструментами IaC, которые в настоящее время ассоциированы с основными поставщиками облачного решения, включая AWS, Azure и Google, мы надеемся что это наилучшее руководство для того чтобы начать. В этом руководстве мы сосредоточимся на том что такое Terraform и какие задачи можно решать с его помощью, предпринимая сопоставление с прочими программными инструментами, включая шаблоны ARM, AWS CloudFormation и Диспетчером развёртывания Google Cloud и изучим как вы можете начинать действенно применять Terraform в своих повседневных заданиях, относящихся к предоставлению и сопровождению вашей инфраструктуры ИТ.

Terraform это один из инструментов с открытым исходным кодом, который был предложен н рынке HashiCorp в 2014 в качестве программного обеспечения IaC (IaC означает, что мы можем писать для своей инфраструктуры код) то есть в основном применять для безопасной и эффективной сборки, изменения и управления инфраструктурой. Terraform способен помочь со средами множества облачных решений, обладая единственным рабочим потоком, иными словами, terraform init, terraform plan, terraform apply и тому подобное, причём для всех облачных решений. Такая инфраструктура, которой управляет Terraform, может выставляться в общедоступных облачных решениях, таких как AWS, Microsof Azure и GCP, либо в частных облачных решениях на площадке, таких как VMware vSphere, OpenStack или CloudStack. Terraform обрабатывает IaC, поэтому вам никогда нет нужды беспокоиться о своей инфраструктуре, отклоняющейся от желаемой ею конфигурации.

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

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

После изучения относительно того, что представляет собой Terraform, у вас в вашем сознании может остаться ещё один вопрос: что именно делает настолько популярным Terraform? Для ответа на этот вопрос, прежде всего и в первую очередь, Terraform не зависит от облачного решения, что означает, что вы можете предоставлять свою инфраструктуру и управлять ею в любой облачной платформе. Второй момент, который превращает Terreform в очень востребованный, это его стандартный рабочий процесс. Вам не требуется запоминать N частей общего рабочего потока; будет достаточно простых init, plan и apply с точки зрения Terraform и это в равной степени относится ко всем частям платформы. Третий момент состоит в синтаксисе Terraform. Terraform применяет унифицированный синтаксис кода, будь это исполнение в любом облачном решении или на площадке. Существует ещё множество исключительных факторов, которые могут побуждать корпоративных клиентов применять Terraform.

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

 

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

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

 

Планы исполнения

Рабочий процесс Terraform обладает тремя этапами - init, plan и apply. На протяжении этапа планирования вырабатывается некий план исполнения. Такой план исполнения снабжает вас сведениями относительно того, что будет осуществлять Terraform когда вы вызовете apply. Это означает, что вы не получите сюрприза ни в каком виде при осуществлении terraform apply.

 

Граф ресурсов

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

 

Автоматизация изменений

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

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

 

Настройка прикладных приложений Heroku

Heroku это одна из популярных PaaS (Platforms as a Service, Платформ как служб) для размещения прикладных веб приложений. Разработчики применяют её для создания некоторого прикладного приложения с последующим подключением прочих служб, таких как базы данных ил поставщики электронной почты. Одной из наилучших функциональных возможностей такого прикладного приложения Heroku это способность эластично масштабировать общее число дайно (dyno) и исполнителей. Тем не менее, большинство нетривиальных приложений быстро начинают требовать множества добавлений и внешних служб:

Применяя Terraform, все те моменты, которые требуются для настройки облачного приложения Heroku могут кодироваться в неком конфигурационном файле, тем самым обеспечивая что все требуемые добавления доступны и наилучшая часть этого состоит в том, что при помощи Terraform всего этого можно достичь всего лишь за 60 секунд. Любые запрашиваемые самим разработчиком в прикладном приложении Heroku изменения могут активироваться немедленно с использованием Terraform, будь то сложная задача, относящаяся к настройке DNS для установки CNAME или о настройке Cloudflare в качестве CDN (content delivery network, сети доставки содержимого) для соответствующего прикладного приложения и так далее, и тому подобное.

 

Приложения со множеством уровней

Развёртывание N- уровневой архитектуры достаточно распространено в отрасли пр размышлении относительно необходимой инфраструктуры для некого приложения. Обычно более запрашиваемой является архитектура с двумя уровнями. Это некий пул веб серверов и уровень баз данных. Что касается требований соответствующего приложения, дополнительные уровни могут добавляться для серверов API, серверов кэширования, сеток маршрутизации и тому подобного. Этот шаблон применяется по причине того, что каждый уровень может масштабироваться независимо и без распространения на прочие уровни:

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

 

Самостоятельно обслуживающиеся кластеры

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

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

 

Демонстрации программного обеспечения

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

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

 

Одноразовые среды

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

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

 

Программно определяемые сети

SDN (Sofware-Defned Networking, Программно определяемые сетевые среды) достаточно известны в центрах обработки данных, поскольку они позволяют операторам очень гладко работать с программно- определяемыми сетями, а разработчикам иметь возможность разрабатывать свои приложения, которые запросто могут запускаться поверх предоставляемой сетевой инфраструктуры. Соответствующие уровень управления и уровень инфраструктуры являются двумя главными компонентами для определения некой программно- определяемой сети:

Программно- определяемые сетевые среды могут преобразовываться в код при помощи Terraform. Этот написанный в Terraform код конфигурации может автоматически устанавливать и изменять настройки через взаимодействие на уровне управления. Это позволяет соответствующей конфигурации автоматически снабжаться версиями и изменениями. Например, Azure Virtual Network это одна из наиболее широко применяемых реализаций SDN и она способна настраиваться Terraform.

 

Планировщики ресурсов

В инфраструктурах крупного масштаба статичное выделение приложений машинам создаёт множество проблем. В терминах Terraform доступными является большое число планировщиков, такие как Borg, Mesos, YARN и Kubernetes, которые могут применяться для решения такой задачи. Они могут применяться для динамичного планирования контейнерами Docker, Hadoop, Spark и многими прочими инструментами программного обеспечения:

Terraform не ограничивается лишь поставщиками облачных решений, таких как Azure, GCP и AWS. Планировщики ресурсов также способны выступать поставщиками , позволяя Terraform запрашивать у них ресурсы. Это позволяет Terraform применяться на уровнях для настройки необходимой физической инфраструктуры, запущенной соответствующими планировщиками, а также предоставления их в соответствующей сетке планирования. Имеется поставщик Terraform, который способен конфигурироваться при помощи Terraform для планирования любого развёртывания Pod. Вы можете прочесть о Kubernetes с Terraform в https://learn.hashicorp.com/collections/terraform/kubernetes.

 

Развёртывание во множестве облачных решений

В наши дни все организации движутся в сторону множественных облачных решений и одной из вызывающих задач является развёртывание всей инфраструктуры целиком в неком ином облачном решении. Всякий поставщик облачного решения обладает своим собственным манером развёртывания, к примеру шаблоны ARM для Azure или AWS CloudFormation. Следовательно, для администратора очень сложно обучиться всем им и в то же самое время поддерживать всю сложность развёртывания своей среды:

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

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

В нашем предыдущем разделе вы получили сведения относительно Terraform и, аналогично Terraform, имеется множество прочих вариантов IaC, которые более специфичны для индивидуальных поставщиков облачных решений, таких как шаблоны ARM для облачных решений Azur, CloudFormation для AWS и Cloud Deployment Manager для GCP. Точно так же каждый поставщик дошёл до своего собственного IaC, который применяется для предоставления их инфраструктуры. Теперь задачей каждого администратора или разработчика состоит в изучении и запоминании огромного числа различных синтаксисов шаблонов. Для преодоления этой проблемы Terraform разработала решение, вовлекающее общие рабочие процессы и синтаксис, которое позволяет операторам управлять сложной инфраструктурой. Давайте попытаемся разобраться чем Terraform отличается с точки зрения кроссплатформенности, а также модульности, языка кодирования, валидации, надёжности, сопровождаемости, рабочего процесса, управления ошибками, управления состоянием и тому подобного для основных поставщиков облачных решений, включая AWS, Azure и GCP.

В этом разделе мы рассмотрим чем Terraform отличается от CloudFormation на основе различных параметров:

Давайте приступим.

 

Переносимость между платформами

Основное преимущество Terraform состоит в том, что вы можете применять его с различными поставщиками облачных решений, в том числе AWS, GCP и Azure. Шаблоны CloudFormation более сосредоточены на AWS. Поэтому Terraform более предпочтителен нежели AWS CloudFormation.

 

Язык программирования

Terraform пишется на HashiCorp Confguration Language (HCL). Синтаксис HCL очень мощный и позволяет вам ссылаться на переменные, атрибуты и тому подобное, в то время как CloudFormation применяет JSON или YAML, которые являются простыми языками обозначений и не столь мощны как HCL. При помощи CloudFormation вы также можете ссылаться на параметры, например, прочие стеки, но в целом мы полагаем что HCL превращает Terraform в более производительный.

С другой стороны CloudFormation обладает хорошей поддержкой для различных функциональностей условий. Terraform обладает циклами count, for_each и for, что делает некие вещи более простыми (такие как создание N идентичных ресурсов), а определённые моменты более тяжёлыми (например, структуру if-else условного типа, допустим, count = var.create_eip == true ? 1: 0). CloudFormation также обладает условием ожидания и политикой создания, которые могут быть важными в определённых ситуациях развёртывания, при которых вам может требоваться подождать пока не удовлетворится некое определённое условие.

С точки зрения языка программирования, Terraform прост и удобен для наброска, что побудит разработчиков и администраторов начать применять Terraform, но на практике это зависит от ситуации применения, который в некоторых случаях требует от вас применять CloudFormation для развёртывания и управления ресурсами AWS.

 

Модульность

Модульность обычно определяется как степень упрощения для вас кода инфраструктуры при помощи Terraform или CloudFormation. Модули Terraform легко могут быть написаны и применяться повторно в качестве кода инфраструктуры во множестве проектов большим числом команд. Следовательно, достаточно просто разбивать код Terraform на модули. У вас имеется вариант разбиения кода CloudFormation на модули применяя вложенные стеки. Вы не можете разбивать на модули сам по себе стек CloudFormation также как вы можете готовить стеки стеков в Terraform. В CloudFormation вы можете применять ссылки между стеками в Terraform применяя источник данных terraform_remote_state, что применяется для Terraform извлечения вывода корневого модуля из иной конфигурации Terraform.

Сопоставляя AWS CloudFormation и Terraform с точки зрения модульности, мы можем видеть что Terraform выглядит более дружественным и более простым в использовании.

 

Подтверждение

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

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

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

С точки зрения валидации, и Terraform, и AWS CloudFormation обладают определёнными вариантами для её осуществления. Единственное основное отличие, которое стоит отметить, заключается в том, что в AWS CloudFormation вам потребуется применять множество служб AWS, в то время как в Terraform мы легко способны выполнять подтверждение при помощи всего лишь его рабочего процесса.

 

Читаемость

Нет никаких сомнений в том, что когда вы пишете файл конфигурации Terraform, вы находите его более простым по сравнению с AWS CloudFormation. Файлы конфигурации Terraform пишутся на HCL,что означает что они более представительны если вы понимаете его синтаксис. Когда вы представляете CloudFormation, который обычно пишется на JSON или YAML, они достаточно сложны с точки зрения читаемости, в особенности JSON; YAML это нечто доступное для чтения и понимания, однако основана проблема состоит в YAML относится к пробельным символам и контроле стиля. В Terraform также имеются стороны контроля синтаксиса, однако Terraform обладает умным способом выполнения контроля за синтаксисом путём простого выполнения terraform fmt -recursive, что выполнит контроль стиля (линтинг) для всех представленных в данном каталоге файлов конфигураций Terraform, в то время как в YAML вам приходится выполнять нечто вручную или пользоваться каким- то инструментом валидации YAML в помощь вашего подтверждения.

Итак, в своей сердцевине, Terraform оказался более предпочтительным нежели AWS CloudFormation.

 

Лицензии и сопровождение

AWS CloudFormation это служба управления от AWS предлагаемая бесплатно, в то время как Terraform это инструмент автоматизации инфраструктуры с открытым исходным кодом, предоставляемый HashiCorp. Существует также продукт HashiCorp Terraform Cloud Enterprise, который является лицензируемой версией и корпоративным пользователям приходится покупать её у HashiCorp.

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

 

Поддержка консоли AWS

Поскольку AWS CloudFormation это родной инструмент IaC AWS, он естественно предоставляет исключительную поддержку в консоли AWS. В такой консоли AWS вы можете отслеживать весь процесс развёртывания, видеть все события развёртывания, проверять различные ошибки, выполнять интеграцию CloudFormation с CloudWatch и тому подобное. В CLI Terraform у нас нет варианта консоли, однако в версии Terraform Cloud Enterprise существует консоль, в которой вы можете видеть весь процесс развёртывания всех ресурсов.

 

Рабочий процесс

Вы можете представлять себе AWS CloudFormation что будет более зрелым с операционной точки зрения, и это правда до определённой степени, однако тут вам требуется понимать саму болевую область. Давайте возьмём в качестве примера случай, когда у вас имеется сложная инфраструктура из примерно 50 ресурсов и вы создаёте её применяя AWS CloudFormation. После работы примерно на протяжении 20- 30 минут ваш стек AWS CloudFormation получает некую ошибку в одном из ресурсов и по этой причине этот стек завершается отказом. В подобной ситуации это может выполнить откат обратно и разрушить всё что было создано в AWS, или, порой, это способно развернуть некоторые из таких ресурсов даже когда они отказали в предоставлении, когда вы отключили в AWS CloudFormation rollback on failure. Для дополнительного знакомства с вариантом отката при отказе в AWS CloudFormation, вы можете обратиться к https://aws.amazon.com/premiumsupport/knowledge-center/cloudformation-prevent-rollback-failure/. Но, честно говоря, если был выполнен откат и уничтожено то что создано, тогда вы, как оператор, вряд ли будете искать нечто подобное, поскольку это добавит ещё временных затрат и усилий. Теперь, когда вы предоставляете свою инфраструктуру AWS применяя рабочий процесс Terraform, это обеспечит в AWS всю необходимую инфраструктуру. Даже если, представим себе, рабочий процесс Terraform завершился отказом, тогда он продолжит сопровождение уже созданного ранее до сбоя. Вы можете повторно выполнить эту конфигурацию Terraform и это просто обеспечит необходимые остающиеся ресурсы вместо того чтобы создавать все такие ресурсы с чистого листа, причём это сбережёт порядочное количество времени и усилий с точки зрения повторной работы.

Итак, основываясь на нашем предыдущем параграфе, кажется, что могут применяться и AWS CloudFormation, и рабочие процессы Terraform. Это зависит от самого пользователя и того что он предпочитает.

 

Понятность сообщений об ошибках

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

Итак, сопоставляя понятность и распознавание сообщений об ошибках между Terraform и AWS CloudFormation, порой вы можете находить, что AWS CloudFormation прост, поскольку вы обладаете опытом работы с последним, а далее, осваивая Terraform, вы станете способным проще выявлять бо́льшую часть всех ошибок.

 

Управление состоянием инфраструктуры

И AWS CloudFormation, и Terraform поддерживают значение состояния вашей инфраструктуры своим собственным способом. В Terraform файлы состояния хранятся на локальном диске или вы можете предоставлять некое удалённое место на сервере, например, AWS S3, где бы вы желали хранить свой файл состояния Terraform. Этот файл состояния записывался бы в JSON и содержал бы сведения о той инфраструктуре, которая определена в соответствующем файле конфигурации Terraform. Итак, для Terraform достаточно просто подтверждать и проверять любой вид подвижек конфигурации.

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

В данном разделе мы рассмотрим чем отличается Terraform от ARM на основе различных параметров:

Давайте начнём.

 

Переносимость между платформами

Основное преимущество Terraform состоит в том, что вы можете применять его со множеством поставщиков облачных решений, включая AWS, GCP и Azure. Шаблоны ARM более близки Azure, в то время как для Terraform вам всего лишь требуется изучить синтаксис языка программирования HCL и рабочий процесс Terraform и начать применять какого- то поставщика облачного решения, такого как GCP, Azure или AWS. Таким образом, мы можем понять, что Terraform не зависит от облачного решения и для пользователя было бы проще при помощи Terraform реализовать инфраструктуру для любой из подобных платформ.

 

Язык программирования

Terraform написан на HCL. Синтаксис HCL очень мощный и позволяет вам ссылаться на переменные, атрибуты и тому подобное, в то время как шаблоны ARM применяют JSON и слега более сложны, но очень мощны, потому как вы можете применять условные предложения, встраиваемые шаблоны и тому подобное.

Имея всё это в виду, здесь также мы бы поощряли конечных пользователей и разработчиков пользоваться Terraform.

 

Модульность

Модульность обычно означает как для вас намного проще реализовывать ваш код инфраструктуры с применением Terraform и шаблонов ARM. Модули Terraform могут быстрее писаться и повторно применяться в качестве кода инфраструктуры во множестве проектов большим числом команд. Следовательно, достаточно просто разбивать на модули код Terraform.

У вас имеется вариант разбиения на модули шаблонов ARM при помощи встраиваемого шаблона ARM, хотя у вас также имеется вариант формирования некого встраиваемого шаблона, причём первый внутри самого вашего главного шаблона, а второй применяет отдельные файлы JSON, вызываемые из вашего главного шаблона.

Здесь, сопоставляя шаблоны ARM и Terraform, Terraform набирает больше очков чем шаблоны ARM, хотя в данном случае шаблоны ARM всё ещё допустимый вариант для конечных пользователей когда они планируют создавать ресурсы в Azure.

 

Подтверждение

Оба инструмента позволяют вам обладать валидацией инфраструктуры, однако существует разница. Применяя Azure CLI или PowerShell, вы можете подтверждать некий шаблон исполняя az group deployment validate, что означает, что будет выполнена лишь проверка самого синтаксиса вашего шаблона. Для подтверждения того, что все необходимые ресурсы обеспечены, вам придётся развернуть весь шаблон ARM целиком.

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

С точки зрения подтверждения, если вы сопоставили их оба, то здесь также Terraform выигрывает над шаблонами ARM.

 

Читаемость

Нет никаких сомнений в том, что когда вы пишете файл конфигурации Terraform, вы находите его более простым по сравнению с шаблонами ARM. Файлы конфигурации Terraform пишутся на HCL,что означает что они более представительны если вы понимаете его синтаксис, а самая лучшая часть состоит в том, что когда вы изучили его синтаксис, вы будете способны писать и применять его где угодно у любого поставщика облачного решения, включая Azure, GCP и AWS. Когда вы рассматриваете шаблоны AWS, которые обычно пишутся на JSON, они более сложны в плане своей читаемости.

 

Лицензия и сопровождение

Шаблоны ARM применяют встроенный IaC Azureи доступны бесплатно, в то время как Terraform это доступный от HashiCorp инструмент с открытым исходным кодом. Имеется также версия Terraform - Terraform Cloud Enterprise, которую могут приобретать корпоративные потребители. В отношении сопровождения, и шаблоны Azure, и Terraform обладают своими собственными планами поддержки, которые могут применяться их пользователями.

 

Поддержка портала Azure

Поскольку шаблоны ARM это встроенный инструмент IaC Azure, они естественно обеспечивают исключительную поддержку в самом портале Azure. В таком портале Azure вы можете отслеживать развитие развёртывания.

Для Terraform нет поддержки портала Azure, однако если пользователь пожелает применять продукт Terraform Cloud Enterprise, тогда он сможет воспользоваться неким порталом, который показывает достаточно сведений относительно той инфраструктуры, которой он планирует управлять через Terraform.

 

Рабочий процесс

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

Имеется одно менее существенное отличие, тем не менее. Прежде чем выполнять необходимый код шаблона ARM, развёртывание шаблона ARM нуждается в том чтобы на своём месте присутствовала группа ресурсов Azure, в то время как код конфигурации Terraform способен создавать группу ресурсов Azure сам по себе в процессе времени выполнения, просто как если бы вам потребовалось определить кодовый блок группы ресурсов в своём файле конфигурации. Следовательно, выглядит так, что и шаблоны ARM, и Terraform, достаточно удовлетворительны в плане рабочего процесса.

 

Понятность сообщений об ошибках

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

Итак, в плане сопоставления понятности сообщений об ошибках между Terraform и шаблонами ARM, данный процесс может оказаться более простым в шаблонах ARM.

 

Управление состоянием инфраструктуры

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

В этом разделе мы рассмотрим в чём отличия между Terraform и Google Cloud Deployment Manager на основе различных параметров:

Вперёд.

 

Переносимость между платформами

Поскольку вы уже видели сопоставление с AWS и Azure, вы теперь должны осознавать, что Terraform может применяться в любых платформах, включая также и GCP. Вам просто надлежит знать, что вы можете писать файлы конфигурации Terraform применяя HCL и его рабочий процесс.

Cloud Deployment Manager это некая служба развёртывания инфраструктуры, которая автоматизирует необходимые создание и управление ресурсами облачного решения Google. Итак и тут, Terraform одерживает победу над Cloud Deployment Manager.

 

Язык программирования

Terraform пишется на HCL. Синтаксис HCL очень простой и мощный, а также позволяет вам ссылаться на переменные, атрибуты и тому подобное, в то время как Cloud Deployment Manager для создания файла конфигурации пользуется YAML и вы можете в таком фале конфигурации определять множество шаблонов, которые пишутся на Jinja или Python.

Держа всё это на уме, в данном случае мы также поощряли бы конечных пользователей и разработчиков применять Terraform, поскольку для применения развёртывания облачных решений вам бы потребовались команды Python или Jinja и YAML.

 

Модульность

Модульность означает насколько просто для вас определять ваш файл конфигурации и повторно применять его для обеспечения инфраструктурой при помощи Terraform и Cloud Deployment Manager. Модули Terraform могут быстрее писаться и публиковаться, к тому же эти модули могут проще потребляться командами прочих продуктов в их проектах. Поэтому модульный код Terraform достаточно прост.

У вас имеется вариант разбивать Cloud Deployment Manager на модули применяя встраиваемые шаблоны внутри файла конфигурации. Эти шаблоны могут писаться либо на Python, либо на Jinja. Одна конфигурация способна импортировать шаблоны и Python, и Jinja. Эти файлы шаблонов должны представляться локально или помещаться в стороннем URL с тем, чтобы Cloud Deployment Manager был способен иметь к нему доступ.

В данном случае, при сопоставлении Cloud Deployment Manager и Terraform, Terraform набирает больше очков чем Google Cloud Deployment Manager, хотя Google Cloud Deployment Manager остаётся здесь также достойным вариантом для конечных пользователей, когда они планируют создавать ресурсы в Google.

 

Подтверждение

Оба инструмента позволяют вам подтверждать инфраструктуру, однако имеется некое отличие. Для обнаружения любых синтаксических ошибок в имеющемся файле конфигурации вам потребуется запускать его из Google Cloud Deployment Manager. Это снабдит вас всеми возможными ошибками, а также подтвердит какие ресурсы обеспечиваются. В таком случае вам придётся развернуть полный файл конфигурации Google Cloud Deployment Manager в облачном решении Google.

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

В плане подтверждения, когда вы сравнили оба, то в данном случае также Terraform побеждает Google Cloud Deployment Manager.

 

Читаемость

Если вы намерены писать файл конфигурации Terraform, вы обнаружите его более читаемым по сравнению с файлом конфигурации Google Cloud Deployment Manager. Написанные на HCL файлы конфигурации Terraform более представительны, а самая лучшая их сторона состоит в том, что изучив синтаксисы Terraform, вы окажетесь способным писать и применять их где угодно, в любом облачном решении, включая Google, GCP и AWS, или даже на своей площадке.

Когда вы задумываетесь о Cloud Deployment Manager, который в целом пишется на YAML, с ним также легко разобраться, однако когда вам требуется вводить некий шаблон в своём файле конфигурации, который пишется на Jinja или Python, тогда его становится сложнее читать и понимать.

Таким образом, я определённо придерживаюсь варианта, что Terraform проще применять по сравнению с Cloud Deployment Manager.

 

Доступность сопровождения

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

Файл конфигурации Cloud Deployment Manager, который пишется на YAML и чей шаблон пишется на Python или Jinja не так просто читать, что подразумевает, что вашему потребителю требуется изучать множество языков программирования кода. Его встраиваемые шаблоны получаются сложными и вам приходится хранить такой файл шаблона в локальном хосте или стороннем URL. Определение его кода шаблона локально в локальном файле конфигурации и потребление его соответствующим файлом конфигурации не возможно.

Cloud Deployment Manager не обладает никаким видом файла состояния, в то время как Terraform имеет файл состояния, который хранится в своём удалённом сервере.

Код конфигурации Terraform может храниться в любом инструменте управления версиями, таком как Git, Azure Repos или Bitbucket, когда мы планируем применять конвейеры DevOps CI/CD.

Сопровождение и кода Terraform, и шаблонов Google Cloud Deployment Manager было бы слегка более сложным, поскольку их оба потребовалось бы хранить либо локально, либо в инструментах контроля исходного кода.

 

Поддержка консоли Google

Поскольку Google Cloud Deployment Manager является встроенным инструментом IaC Google для обеспечения и сопровождения инфраструктуры, он предоставляет исключительную поддержку в консоли Облачного решения Google. В такой консоли Облачного решения Google вы можете видеть развитие процесса в плане развёртывания.

Для Terraform нет поддержки консоли Облачного решения Google, однако имеется некий отдельный портал когда вы применяете версию Terraform Cloud Enterprise.

 

Рабочий процесс

С точки зрения рабочего процесса, и Cloud Deployment Manager, и Terraform обладают очень хорошими функциональными возможностями. Если развёртывание ресурсов прерывается на полпути, и Terraform, и Cloud Deployment Manager обладают возможностью развёртывания остающихся ресурсов на протяжении повторного прогона, игнорируя уже имеющиеся ресурсы.

Однако, существует одно менее значимое отличие. Развёртывания Cloud Deployment Manager требуют помещения некого проекта перед исполнением своего файла конфигурации при помощи Cloud Deployment Manager, в то время как код конфигурации Terraform способен создавать некий проект Google самостоятельно на протяжении времени выполнения, в точности как если бы вам потребовалось определить некий блок кода ресурса проекта Google в самом файле конфигурации. Таким образом, мне представляется, что они оба достаточно удовлетворительны когда речь идёт о рабочем процессе.

 

Понятность сообщений об ошибках

В предыдущих сопоставлениях AWS и Azure мы упоминали, что ошибки применяют для испускания API соответствующего поставщика, а обучение тому как обрабатывать эти ошибки приходит с опытом. Если вы уже вооружены таким знанием, тогда вам будет проще иметь возможность к выделению таких проблем. И снова, по сравнению с Google Cloud Deployment Manager, код Terraform выставляет некое число трудных ошибок, с которыми вам будет не просто разобраться когда вы новичок в Terraform. Это вовсе не означает, что вам будет проще разобраться с ошибками Google Cloud Deployment Manager, ибо они вовлекают большое число языков программирования кода, таких как YAML, JSON или Jinja.

Итак, с точки зрения сопоставления и понятности сообщений об ошибках Terraform и Google Cloud Deployment Manager, когда вы обладаете опытом работы в Облачных решениях Google, тогда они инстинктивно будут ближе для вас и это поспособствует более простому пониманию всех ошибок. Относительно обработки ошибок в Terraform, вам может потребоваться некоторое время чтобы определять какие API ресурсов Облачного решения Google выпускают специфичные для этого ошибки.

 

Управление состоянием инфраструктуры

И Cloud Deployment Manager, и Terraform предоставляют достойное управление состоянием. Terraform предоставляет управление файлом состояния с применением серверного механизма состояния, а также файлов состояния, которые могут храниться в Облачном хранилище Google. Cloud Deployment Manager обладает способностью обратного отката к предыдущему успешному развёртыванию, так как развёртывания по умолчанию происходят последовательно увеличивающимися и достаточно просто реализовать все изменения, которые вы бы желали выполнить в отношении ресурсов Google при помощи Cloud Deployment Manager.

Мы рассмотрели чем Terraform отличается от прочих вариантов IaC, в основном, в плане наличия переносимости между платформами, а также модульности, читаемости, управления состоянием инфраструктуры, языка программирования, сопровождаемости, рабочего процесса, поддержки облачной консоли и тому подобного, а также как он может применяться основными поставщиками облачных решений, таких как AWS, Azure и GCP. Все эти сопоставления помогут вам понять что Terraform является более мощным IaC и что вы действенно можете остановиться на IaC Terraform для обеспечения собственной инфраструктуры вместо того чтобы выбирать какую- то конкретную IaC. Двинемся далее, давайте попробуем получить представление об архитектуре Terraform.

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

Как вы можете видеть из предыдущей архитектуры Terraform, имеются два ключевых компонента, от которых зависит работа Terraform: Ядро и подключаемые модули Terraform. Ядро Terraform пользуется Remote Procedure Calls (RPC) для взаимодействия с подключаемыми модулями Terraform и предлагает множество способов обнаружения и загрузки подключаемых модулей для применения. Подключаемые модули Terraform выставляют некоторую реализацию для определённой службы, например, AWS, или оснастки (provisioner) и тому подобное.

Ядро Terraform это статически скомпилированный исполняемый файл, написанный на программном языке Go. Он применяет RPC для взаимодействия с подключаемыми модулями Terraform и предлагает множество способов обнаружения и загрузки подключаемых модулей для применения. Такой компилированный исполняемый файл это CLI Terraform. Если вы хотите больше ознакомиться с ним, вам следует начать своё путешествие с CLI Terraform, который является всего лишь точкой входа. Этот код является открытым и размещается в http://github.com/hashicorp/Terraform.

Ядро Terraform отвечает за следующее:

Подключаемые модули Terraform написаны на программном языке Go и являются исполняемыми файлами, которые активируются Ядром Terraform через RPC. Каждый подключаемый модуль выставляет некую реализацию для конкретной службы, такой как AWS, или оснастки (provisioner), например, Bash. Все поставщики и оснастки это подключаемые модули, которые определяются в файле конфигурации Terraform. Оба исполняются как отдельные процессы и взаимодействуют со своим главным Terraform через интерфейс RPC. Terraform обладает большим числом встроенных оснасток, в то время как поставщики добавляются динамически по мере необходимости. Ядро Terraform предоставляет каркас верхнего уровня, который абстрагируется от подробностей обнаружения подключаемого модуля и взаимодействия RPC, поэтому таким разработчикам не приходится управлять ничем из этого.

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

Вот ответственности поставщиков подключаемых модулей:

Подключаемые модули оснасток отвечают за:

 

Местоположения подключаемых модулей

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

Таблица 1-1. Местоположения подключаемых модулей

Каталог	Назначение
.	Для удобства в процессе разработки
Местоположение самого исполняемого файла Terraform (например, /usr/local/bin)	Для установок с воздушным зазором {без выхода в сеть}; ссылка на пакет Terraform
terraform.d/plugins/>OS<_>ARCH<	Для проверки индивидуальных поставщиков в репозитории VCR (Version Control Systems); обычно не желательно, но порой требуется в Terraform Enterprise
.terraform/plugins/>OS<_>ARCH<	Автоматически выгружаемые поставщики
~/terraform.d/plugins/ или %APPDATA%\terraform.d\plugins	Каталог подключаемых модулей пользователя
~/terraform.d/plugins/>OS<_>ARCH< или %APPDATA%\terraform.d\plugins\>OS<_>ARCH<	Каталог подключаемых модулей пользователя с ОС и архитектурой в явном виде

Для получения дополнительных сведений относительно местоположений подключаемых модулей вы можете посетить следующую ссылку.

Когда вы запускаете terraform init в варианте с -plugin-dir=>PATH< (при не пустом >PATH<), это перекроет местоположения подключаемых модулей по умолчанию и поиск будет выполнен только в предписанном вами пути.

Подключаемые модули поставщика и оснастки могут устанавливаться в те же самые каталоги. Исполняемые файлы поставщика именуются согласно схеме terraform-provider->NAME<_vX.Y.Z, в то время как подключаемые модули оснастки применяют схему terraform-provisioner->NAME<_vX.Y.Z. Terraform при определении типов, имён и версий подключаемого модуля полагается на названия файлов.

 

Выбор подключаемых модулей

После нахождения какого бы то ни было установленного подключаемого модуля, terraform init сопоставляет его с определёнными ограничениями версии конфигурации и выбирает версию для каждого подключаемого модуля согласно:

 

Обновление подключаемых модулей

Когда вы запускаете terraform init в варианте -upgrade, выполняется проверка releases.hashicorp.com на наличие самых новых версий поставщиков и выгружается самая последняя из доступных версий.

Это работает только в случае поставщиков, чьи исключительно приемлемые версии пребывают в .terraform/plugins/>OS<_>ARCH< (каталоге автоматической выгрузки); если любые приемлемые версии данного поставщика установлены где- то ещё, terraform init -upgrade не выгрузит более новую версию необходимого подключаемого модуля.

Теперь мы рассмотрели архитектуру Terraform и изучили её центральные компоненты, иными словами , Ядро Terraform и подключаемые модули Terraform, а также то, как Ядро Terraform взаимодействует с подключаемыми модулями Terraform (оснастками и поставщиками) при помощи RPC. Совместно со всем этим, мы теперь обладаем пониманием различных источников, из которых Terraform будет пытаться выгружать подключаемые модули, поскольку без подключаемых модулей у вас не будет возможности применять Terraform.

При помощи данной главы вы теперь обладаете достаточным пониманием того что собой представляет Terraform. Terraform это инструмент оркестрации IaC, представленный HashiCorp, который в основном применяется для обеспечения инфраструктуры для вашего приложения в формате кода. Он пишется на HCL, который просто читается и понимается, к тому же мы изучили ряд различных вариантов применения, включая приложения со множеством уровней, SDN, развёртывание во множестве облачных решений и планировщики ресурсов, а также примеры того, где вы можете пользоваться Terraform.

Продвигаясь вперёд, вы получили понимание чем Terraform отличается от прочих IaC, таких как шаблоны ARM и CloudFormation в плане языка программирования, надёжности, модульности, обработки ошибок и всякого прочего. Затем мы изучили архитектуру Terraform и здесь вы получили знания о том как Ядро Terraform взаимодействует с подключаемыми модулями Terraform при помощи RPC, а также что применяя Ядро Terraform мы будем иметь возможность запускать различные команды CLI Terraform, включая init, plan и apply.

В своей следующей главе мы намерены обсудить то, как вы можете устанавливать terraform.exe в различных машинах, таких как Windows, macOS и Linux, что поможет вам приступить к работе с Terraform.

Ответы на данные вопросы можно обнаружить в разделе Аттестация в самом конце этой книги:

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