terraform aws что это
Terraform: Beyond the Basics with AWS
Editor’s note: This post was updated in March 2018.
By Josh Campbell and Brandon Chavis, Partner Solutions Architects at AWS
Terraform by HashiCorp, an AWS Partner Network (APN) Advanced Technology Partner and member of the AWS DevOps Competency, is an “infrastructure as code” tool similar to AWS CloudFormation that allows you to create, update, and version your Amazon Web Services (AWS) infrastructure.
Terraform has a great set of features that make it worth adding to your tool belt, including:
New to Terraform?
This article assumes you have some familiarity with Terraform already.
We recommend that you review the HashiCorp documentation for getting started to understand the basics of Terraform. Conveniently, their documentation uses AWS as the example cloud infrastructure of choice!
Keeping Secrets
You can provide Terraform with an AWS access key directly through the provider, but we recommend that you use a credential profile already configured by one of the AWS Software Developer Kits (SDKs). This prevents you from having to maintain secrets in multiple locations or accidentally committing these secrets to version control. In either scenario, you’ll want to be sure to read our best practices for maintaining good security habits. Alternatively, you can run Terraform from one or more control servers that use an AWS Identity and Access Management (IAM) instance profile.
Each instance profile should include a policy that provides the appropriate level of permissions for each role and use case. For example, a development group may get a control server with an attached profile that enables them to run Terraform plans to create needed resources like Elastic Load Balancers and AWS Auto Scaling groups, but not resources outside the group’s scope like Amazon Redshift clusters or additional IAM roles. You’ll need to plan your control instances carefully based on your needs.
To use an instance or credential profile with Terraform, inside your AWS provider block simply remove the access_key and secret_key declarations and any other variables that reference access and secret keys. Terraform will automatically know to use the instance or credential profile for all actions.
region = “us-west-2”
keypair_name = “your_keypair_name”
corp_ip_range = “192.168.1.0/24”
some_secret = “your_secret”
Building Blocks
An advantage of using an infrastructure as code tool is that your configurations also become your documentation. Breaking down your infrastructure into components makes it easier to read and update your infrastructure as you grow. This, in turn, helps makes knowledge sharing and bringing new team members up to speed easier.
Because Terraform allows you to segment chunks of infrastructure code into multiple files (more on this below), it’s up to you to decide on a logical structure for your plans. With this in mind, one best practice could be to break up Terraform files by microservice, application, security boundary, or AWS service component. For example, you might have one group of Terraform files that build out an Amazon Elastic Container Service (ECS) cluster for your inventory API and another group that builds out the AWS Elastic Beanstalk environment for your production front-end web application.
Additionally, Terraform supports powerful constructs called modules that allow you to re-use infrastructure code. This enables you to provide infrastructure as building blocks that other teams can leverage. For example, you might create a module for creating Amazon Elastic Compute Cloud (Amazon EC2) instances that uses only the instance types your company has standardized on. A service team can then include your module and automatically be in compliance. This approach creates enablement and promotes self-service.
Organizing Complex Services with Modules
Modules are an excellent way to add structure to your project and accept a variety of different source options which allow versioning, GitHub, Bitbucket, and the Terraform Module Registry, among others. You can then execute these modules from a single configuration file (we’ll use main.tf for this example) in the parent directory where your sub-directories (modules) are located. Let’s examine this concept a bit closer.
Modules, like other Terraform resources, understand your order of dependencies. For example, a module to create a launch configuration will automatically run before a module that creates an Auto Scaling group, if the AWS Auto Scaling group depends on the newly created launch configuration.
Terraform allows you to reference output variables from one module for use in different modules. The benefit is that you can create multiple, smaller Terraform files grouped by function or service as opposed to one large file with potentially hundreds or thousands of lines of code. To use Terraform modules effectively, it is important to understand the interrelationship between output variables and input variables.
At a high level, these are the steps you would take to make an object in one module available to another module:
As an example, let’s say we’ve created a module called load_balancers that defines an Elastic Load Balancer. After declaring the resource, we add an output variable for the ELB’s name:
Sample Directory Layout Using Local Modules for Organization
There are a few things to note about this layout:
Following Along with an Example
In this section, we’ll walk you through an example project that creates an infrastructure with several components, including an Elastic Load Balancer and AWS Auto Scaling group, which will be our focus.
Main.tf
Looking at main.tf you will see that there are several modules defined. Let’s focus on the autoscaling_groups module first:
Autoscaling_groups Modules
Here we’re setting the load_balancers parameter to an array that contains a reference to the variable webapp_elb_name. If you look back at main.tf, you’ll notice that this name is also part of the configuration of the autoscaling_groups module. Looking in autoscaling_groups/variables.tf, you’ll see this variable declared with empty curly braces ( <> ). This is the magic behind using outputs from other modules as input variables.
Load_balancers Modules
To bring it together, examine load_balancers/webapp-elb.tf and find this section:
Here we’re telling Terraform to output a variable named webapp_elb_name, whose value is equal to our ELB name as determined by Terraform after the ELB is created for us.
Summary
Collaborating with Teams
Chances are, if you’re using Terraform to build production infrastructure, you’re not working alone. If you need to collaborate on your Terraform templates, the best way to sync is by using Terraform Enterprise by HashiCorp. Terraform Enterprise allows your infrastructure templates to be version controlled, audited, and automatically deployed based on workflows you configure. There’s a lot to talk about when it comes to Terraform Enterprise, so we’ll save the deep dive for our next blog post.
Wrapping Up
We hope we’ve given you a good idea of how you can leverage the flexibility of Terraform to make managing your infrastructure less difficult. By using modules that logically correlate to your actual application or infrastructure configuration, you can improve agility and increase confidence in making changes to your infrastructure.
At HashiConf 2017, HashiCorp also introduced the Terraform Module Registry, where you can find verified and tested modules from AWS and HashiCorp trusted partners.
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Создание ресурсов AWS с Terraform
В данной статье посмотрим и разберем, как создать простейшие ресурсы в облаке AWS (Amazon Web Services) с помощью замечательного инструмента IaaS, под названием Terraform. Для того, чтобы можно было повторить то, о чем пойдет речь в статье необходим действующий аккаунт AWS и рабочая машина (виртуальный сервер) с установленным Terraform, и текстовым редактором Atom + плагин для Terraform.
Интенсив по Виртуализации VMware vSphere 7
Самое важное про виртуализацию и VMware vSphere 7 в 2-х часовом онлайн-интесиве от тренера с 30 летним стажем. Для тех, кто начинает знакомство с виртуализацией и хочет быстро погрузиться в предметную область и решения на базе VMware
Первоначальная настройка данных инструментов разбиралась в предыдущих статьях. Описание в статье пойдет под операционную систему CentOS. Вы можете для тренировки использовать на свой вкус любую.
Для начала создадим папку под наш новый проект, можно непосредственно в домашней директории.
Далее схема работы следующая: пишем код в файле, сохраняем, производим управляющие команды в командной строке для выполнения или проверки данного кода, уничтожения, модификации элементов или объектов в облаке.
Как в начале статьи было сказано, нам необходим аккаунт AWS, чтобы терраформ взаимодействовал с облачной инфраструктурой, а более конкретно нам нужно создать пользователя и получить access key и secret key, для доступа к облаку. Это необходимо для аунтификации Terraform в AWS облаке.
Заходим в AWS консоль и выбираем сервис IAM. Заходим во вкладку пользователи и создаем новую учетную запись. Вводим имя пользователя в пустое поле. Нужно поставить Programmatic Фccess. Далее нажимаем Создать пользователя и попадаем на закладку назначения прав. Тут необходимо присоеденить уже созданный по умолчанию в AWS набор прав администратора. Далее переходим к страничке назначения Tag, тут по желанию вашему, если хотите то можете добавить тэги. Нажимаем кнопку создать пользователя.
Финальное окно будет выглядеть следующим образом.
Получаем те данные, которые нам необходимы для Terraform.
Теперь в принципе все готово для создания первого ресурса в AWS.
Начинаем с объявления с каким облаком мы работаем.
Тем самым мы обозначили с каким облачным провайдером мы будем работать. В данном коде в отличии от YAML, количество пробелов не важно. Далее прописываем access key и secret key. В каком регионе будут использоваться ресурсы. Регион мы укажем eu-central-1 – это ЦОД расположенный в Европе во Франфуркте. Старайтесь регион указывать, поближе к себе, чтобы до ресурсов была минимальная задержка прохождения пакетов.
При нажатии Ctrl+S, мы сохраняем и видим, что плагин аккуратно выправляет для удобства написанный код.
Теперь можно сделать первый ресурс. Например, инстанс в Амазон. Добавляем ниже:
Для поднятия ресурса необходимо указать 2 минимальные вещи. Это ami – image id и instance_type. Теперь необходимо пойти в указанный регион, открыть EC2 и посмотреть ami интересующего инстанса.
А тип возьмем t2.micro. Данный тип для новых аккаунтов на год бесплатный. Получаем код полностью готовый для развертывания первого инстанса.
В принципе все готово для запуска первого инстанса. Код Terraform будет выглядеть следующим образом:
Запускаем консоль и переходим в директорию, где находится у нас Terraform.
И можно убирать эти 2 строчки из кода.
После подтверждения видим следующую картину. Со стороны консоли.
Со стороны амазона спустя полминуты.
Как мы видим сервер создался и проходит инициализацию.
Интенсив по Виртуализации VMware vSphere 7
Самое важное про виртуализацию и VMware vSphere 7 в 2-х часовом онлайн-интесиве от тренера с 30 летним стажем. Для тех, кто начинает знакомство с виртуализацией и хочет быстро погрузиться в предметную область и решения на базе VMware
Используем Terraformer для адаптации действующей инфраструктуры в AWS для деплоев с Terraform
Рассказываем про наш опыт импорта и адаптации конфигураций инфраструктуры, ранее развернутой вручную в AWS, в формат Terraform. Зачем? Причин может быть много: и отказоустойчивость, и упрощение горизонтального и вертикального масштабирования, и многие другие. С них и начнем эту статью.
Проблематика
Без каких-либо процессов автоматизации управления инфраструктурой вы неизбежно столкнетесь с известными ограничениями:
невозможно быстро пересоздать инфраструктуру;
нет истории изменений, произведенных в инфраструктуре;
нет контроля используемых версий ПО;
И это не просто вопрос удобства. Подобные ограничения влияют на критичные для бизнеса показатели: на скорость устранения возникающих проблем в инфраструктуре, на отказоустойчивость… в конечном счете — на uptime. Это понимание привело к расцвету подхода IaC.
На уровне программных служб вопрос решается системами управления конфигураций (Ansible, Chef и т.п.), однако они не покрывают более низкий — аппаратный — слой, а ведь он тоже требует внимания.
Многие из вас уже знакомы на практике с решениями и для этого уровня, такими как Terraform. Оно выглядит уместным, когда мы создаем инфраструктуру с нуля. Но будет ли оно таким же, если перед нами production, состоящий из десятков (сотен, …) компонентов? Ведь потребуются колоссальные трудозатраты на написание сценариев развертывания для каждого элемента.
В этой статье мы подойдем к решению вопроса с другой стороны и попробуем импортировать уже существующую production-инфраструктуру, а затем — адаптировать полученные конфигурации для возможности бесшовного перехода на автоматизированный способ управления.
Планирование и подготовка
Для реализации поставленной задачи — импорта конфигураций — были рассмотрены различные инструменты (в частности, сам Terraform, CLI-утилиту AWS, Terraforming), но мы остановились на утилите Terraformer. Основные причины — полнота и корректность выходных данных, а также удобство использования. Разработчик данного решения при выполнении аналогичной задачи столкнулся с ограничениями, упомянутыми во введении. В результате и появился этот проект, реализующий функции, которых нам так не хватало.
Стоит отметить, что процедура импортирования и адаптации планировалась сразу в нескольких регионах, не связанных друг с другом. Работы при этом необходимо было провести итеративно, чтобы в один момент времени затрагивать только один регион. Решение — реализовать полностью готовое окружение, предварительно проверив его работу в тестовой среде. Поэтому будем использовать Docker-контейнер как удобный способ для быстрого разворачивания окружения с привязкой к конкретным версиям ПО.
Собирать и запускать Docker-образа будем посредством утилиты werf, воспользовавшись её синтаксисом (stapel) вместо Dockerfile. В этом нет какого-либо архитектурного ограничения (обычный docker тоже подойдет) — все дело в более удобном/привычном подходе.
Возьмем базовый образ на основе Ubuntu и выполним в него установку Terraform и плагина Terraformer. Также потребуется добавить конфигурацию и файл с учетными данными доступа в AWS. Вот что получается в случае stapel-манифеста для werf (несложно переписать и на Dockerfile при такой необходимости):
Итак, собираем образ, указав переменные с учетными данными пользователя AWS IAM. Значения можно явно указывать каждый раз при запуске команды вручную или же определить в CI-среде:
Теперь запускаем контейнер, используя собранный образ и те же самые значения переменных. Если указать иные значения, то будет ошибка несоответствия конфигураций. Поскольку мы взаимодействуем с действующей инфраструктурой через слои абстракции, необходимо запускать исключительно то, что было собрано:
Реализация
Инициализация
Этап инициализации стартовой конфигурации Terraform для установки плагина провайдера можно включить в сам образ. Конечно, это увеличит его объем, но и предоставит полностью рабочее решение в рамках конкретного образа, используемого для проведения работ, — при любой итерации запуска (что важно в рамках задачи).
Для предустановки плагина провайдера создадим файл ( providers.tf ) и поместим его в рабочую директорию в образе:
Инициализируем конфигурацию Terraform. Если вы устанавливаете плагин провайдера на этапе сборки, то команду инициализации требуется включить последним шагом, при этом запуск вручную уже не потребуется.
Импорт
Выполняем импорт ресурсов. В данном примере используем следующие ключи:
linux-notes.org
Работа с AWS VPC и Terraform в Unix/Linux
Amazon Virtual Private Cloud (Amazon VPC) – это логически изолированный раздел облака AWS, в котором можно запускать ресурсы AWS в созданной пользователем виртуальной сети. Пользователь полностью контролирует свою среду виртуальной сети, в том числе может выбирать собственный диапазон IP-адресов, создавать подсети, а также настраивать таблицы маршрутизации и сетевые шлюзы. Для обеспечения удобного и безопасного доступа к ресурсам и приложениям в VPC можно использовать как IPv4, так и IPv6.
Сетевую конфигурацию Amazon VPC можно легко настроить по своему усмотрению. Например, для веб-серверов можно создать публичную подсеть с выходом в Интернет, а внутренние системы, такие как базы данных или серверы приложений, расположить в частной подсети без доступа к Интернету. Можно использовать многоуровневую систему безопасности, состоящую из групп безопасности и сетевых списков контроля доступа (NACL), чтобы контролировать доступ к инстансам Amazon EC2 в каждой подсети.
Кроме того, можно создать подключение между корпоративным центром обработки данных и VPC с помощью аппаратной частной виртуальной сети (VPN) и использовать облако AWS для расширения возможностей корпоративного ЦОД.
Установка terraform в Unix/Linux
Установка крайне примитивная и я описал как это можно сделать тут:
Так же, в данной статье, я создал скрипт для автоматической установки данного ПО. Он был протестирован на CentOS 6/7, Debian 8 и на Mac OS X. Все работает должным образом!
Чтобы получить помощь по использованию команд, выполните:
Приступим к использованию!
Работа с AWS VPC и Terraform в Unix/Linux
AWS VPC — виртуальное частное облако, которое в основном обеспечивает способ структурирования вашей собственной сети так, как вы хотите. Прежде чем погрузиться, давайте определим некоторые базовые концепции VPC:
Terraform решает проблему взаимодействия с различными инфраструктурными сервисами (AWS, Digital Ocean, OpenStack и т. Д.) И предоставляет для нее унифицированный формат конфигурации.
Вот несколько важных моментов:
Чтобы записать все имеющиеся переменные в файл, используем:
Чтобы запустить инфраструктуру с созданными переменными, запустим:
И чтобы удалить, запустим:
Существует два способа настройки групп безопасности AWS в Terraform. Вы можете определить правила, связанные с ресурсом aws_security_group, или вы можете определить дополнительные дискретные ресурсы aws_security_group_rule.
Мой первый инстинкт заключался в том, чтобы определить «базовую» группу безопасности, используя встроенные правила, а затем расширить ее с помощью внешних правил. Плохая идея. Об этом позже.
Однако для двух действительных вариантов есть важные последствия, и я обнаружил, что они не были ясны на момент написания (около Terraform v0.9.11). После небольшого исследования и экспериментов у меня появилось гораздо больше пониманий.
Создание VPC с помощью terraform
Давайте создадим VPC, например:
И так, чтоже я тут написал:
Создание security group с помощью terraform
Вот как выглядит определение встроенной группы безопасности:
В примере что выше, есть два правила: правило для входящего (ingress) и исходящего (egress) соединения, определенное внутри блока ресурсов aws_security_group.
Расмотрим что тут написано более подробно:
Вот как одна и та же идея может быть выражена с использованием внешних правил через ресурс aws_security_group_rule:
Группа безопасности и каждое ее правило определяются как дискретный ресурс и тесно связанные друг с другом через security_group_id атрибут. Для каждого порта прописывать правила — нормально и можно, но если у вам имеется 10 портов, — это уже не прикольно! По этому, делаем следующее:
PS: Я на данном этапе, не выношу переменные в отдельный файл. В самом конце этой темы, я приведу полную конфигурацию всех файлов….
Создание private network с помощью terraform
Создадим приватную сеть:
Расмотрим что тут имеется:
Создание public network с помощью terraform
Создадим публичную сеть:
Расмотрим что тут имеется:
Создание internet gateway с помощью terraform
Так же, создам интернет гетвей:
Создание route для internet с помощью terraform
Следующим щагом будет создание роута для интернета:
Или, можно еще сделать следующее:
Создание Elastic IP (EIP) с помощью terraform
Мы создадим этот IP-адрес, чтобы назначить ему NAT-шлюз:
Создание NAT Gateway с помощью terraform
Убедитесь, что вы создали nat в подсети, подключенной к Интернету (общедоступная подсетьб — public network):
Создание private route table и the route to the internet с помощью terraform
Это позволит всем трафику из частных подсетей (privat network) ходить в интернет через NAT-шлюз (трансляция сетевых адресов, — NAT):
Создание Route Table Associations с помощью terraform
Теперь свяжем подсети с разными таблицами маршрутов:
Это я привел некоторые примеры по использованию. Я придерживаюсь того, чтобы все и всегда сортировать (стараюсь так делать), т.е придерживатся так званого стандарта (который придумываю я сам для своих нужд), по этому я расскажу как я делаю.
У меня есть папка terraform, в ней у меня будут лежать провайдеры с которыми я буду работать. Т.к в этом примере я буду использовать AWS, то создам данную папку и перейду в нее. Далее, в этой папке, стоит создать:
В папке examples, я буду хранить так званые «плейбуки» для разварачивания различных служб, например — zabbix-server, grafana, web-серверы и так далее. В modules директории, я буду хранить все необходимые модули.
Начнем писать модуль, но для этой задачи, я создам папку:
В данный файл, вставляем:
Собственно в этом файле храняться все переменные. Спасибо кэп!
Открываем последний файл:
и в него вставить нужно следующие строки:
Данный файл служит для того, чтобы выводить нужные значения на экран вашего экрана.
Переходим теперь в папку aws/examples и создадим еще одну папку для проверки написанного чуда:
Внутри созданной папки открываем файл:
И вставим в него следующий код:
В этом файле, имеется:
Нашел прикольную фишку, можно прописать:
И в своих модулях прописывать (например):
Тоже облегчает жизнь…. Идем дельше….
Все уже написано и готово к использованию. Ну что, начнем тестирование. В папке с вашим плейбуком, выполняем:
Этим действием я инициализирую проект. Затем, подтягиваю модуль:
PS: Для обновление изменений в самом модуле, можно выполнять:
Мне вывело что все у меня хорошо и можно запускать деплой:
Открываем AWS аккаунт и смотрим что вышло.
Созданная AWS VPC через terraform:
Созданные подсети через терраформ:
Чтобы визуализировать представление плана выполнения, запустите следующую команду:
Данная команда сохранит вывод в PNG файл, чтобы просто посмотреть вывод, выполните:
Чтобы удалить созданное творение, можно выполнить:
Весь материал аплоаджу в github аккаунт для удобства использования:
Вот и все на этом. Данная статья «Работа с AWS VPC и Terraform в Unix/Linux» завершена.
Добавить комментарий Отменить ответ
Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.