Мультирегиональная инфраструктура на AWS

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

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

Введение в Terraform

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

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

Чтобы создать состояние, вам необходимо инициализировать новый проект Terraform в том же каталоге, где вы создали файл .tf, вызвав команду terraform init.

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

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

Конечно! Вам нужно будет создать нового пользователя через консоль IAM с программным доступом, а также загрузить и установить AWS CLI на том же компьютере, что и установка Terraform. Затем вам необходимо настроить учетные данные AWS с помощью aws configure — profile terraform и ввести соответствующие данные о только что созданных вами ключах доступа. И вы можете указать Terraform использовать эти учетные данные, указав профиль учетных данных в провайдере.

Следующим шагом будет подготовка инфраструктуры. Для начала мы определим инфраструктуру снизу вверх, выполнив следующие шаги:

  • Создать собственный VPC
  • Создать собственную подсеть
  • Создайте интернет-шлюз и подключитесь к VPC
  • Создайте таблицу маршрутов, свяжите IGW и настраиваемую подсеть
  • Создайте настраиваемую группу безопасности с правилами HTTP и SSH
  • Создайте пару ключей для безопасного входа в экземпляр EC2
  • Создать экземпляр EC2

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

A. Создайте собственный VPC

В качестве первого шага мы создадим настраиваемый VPC, указав cidr_block и другие параметры для включения разрешения DNS в этом VPC. Мы делаем это, создавая ресурс Terraform, который определяется следующим образом: RESOURCE_FROM_PROVIDER RESOURCE_NAME RESOURCE_CONFIG

Поскольку мы имеем дело только с ресурсами AWS, RESOURCE_FROM_PROVIDER будет начинаться с префикса «aws». Следующий код демонстрирует определение VPC.

resource "aws_vpc" "custom-vpc-1" {

  cidr_block = "10.0.0.0/16"

  enable_dns_support = true

  enable_dns_hostnames = true

}

Б. Создайте собственную подсеть

Указав эти сведения о VPC, Terraform не может вывести свой уникальный случайный идентификатор до фактической инициализации ресурса, поэтому, чтобы указать зависимые ресурсы, мы будем ссылаться на идентификатор VPC, как показано во фрагменте ниже, для определения настраиваемой подсети. . Говоря это vpc_id = aws_vpc.vpc-1.id, мы определяем неявную зависимость, утверждающую, что VPC должен быть создан до подсети.

resource "aws_subnet" "custom-subnet-1" {

  cidr_block = "10.0.1.0/24"

  vpc_id = aws_vpc.vpc-1.id

  map_public_ip_on_launch = true

}

C. Создать интернет-шлюз

В приведенном ниже фрагменте показано определение интернет-шлюза и его подключение к ранее определенному VPC.

resource "aws_internet_gateway" "custom-igw-1" {

  vpc_id = aws_vpc.custom-vpc-1.id

}

D. Создание и привязка настраиваемой таблицы маршрутов

Как вы знаете, при создании VPC создается таблица маршрутов по умолчанию, но мы не будем ее изменять. Вместо этого мы создадим новую настраиваемую таблицу маршрутов и свяжем ее с интернет-шлюзом и настраиваемой подсетью. Мы можем добиться этого, изначально создав таблицу маршрутов и добавив настраиваемый маршрут 0.0.0.0/0, который будет указывать на шлюз, а затем создав ассоциацию маршрута, чтобы связать с ним настраиваемую подсеть.

E. Создайте настраиваемую группу безопасности с правилами HTTP и SSH.

Следующим шагом является создание экземпляра EC2, и мы можем легко сделать это с минимальной настройкой - он создаст группу безопасности по умолчанию. Но мы хотим определить настраиваемую группу безопасности, которая будет разрешать трафик HTTP и SSH любому экземпляру, к которому он подключен. Мы делаем это с помощью следующего фрагмента:

Прежде всего, мы связываем группу безопасности с настраиваемым VPC и определяем правила входа, чтобы разрешить трафик отовсюду на порт 22 (не разрешать трафик из любого места на порт 22 для ваших систем, поскольку это согласование безопасности) и порт 80. Нам также необходимо предоставить правила выхода, чтобы позволить экземпляру EC2 общаться с Интернетом.

F. Создайте пару ключей для безопасного входа в экземпляр EC2

В качестве последнего шага для определения экземпляра EC2 нам нужно определить пару ключей с использованием архитектуры RSA, чтобы мы могли подключиться к экземпляру по SSH. Мы можем сделать это, изначально сгенерировав открытый и закрытый ключи локально (с помощью ssh-keygen) и определив пару ключей с помощью следующего фрагмента.

resource "aws_key_pair" "custom -kp1" {

  key_name = "terraform-key"

  public_key = "PASTE_PUBLIC_KEY_HERE"

}

G. Создайте экземпляр EC2

Теперь мы готовы создать наш экземпляр EC2 в настраиваемой подсети внутри настраиваемого VPC. Здесь следует помнить о нескольких вещах:

  • ami — Для каждого экземпляра необходимо указать идентификатор AMI, который вы будете использовать. Вы можете получить это в консоли AWS, но обратите внимание, что вы можете использовать тот же AMI в определенном регионе.
  • instance type - это тип экземпляра, который будет использоваться для запуска EC2. В этом примере мы выбираем t2.micro, что соответствует требованиям бесплатного уровня.

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

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

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

Убедившись, что в плане Terraform все в порядке, вы можете развернуть инфраструктуру с помощью команды terraform apply. Это должно занять несколько секунд или минут, и вы сможете заметить все вновь созданные компоненты в учетной записи AWS.

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

Определение многорегиональной инфраструктуры

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

Как вы отметили, мы определили поставщика AWS в начале Terraform, указав регион us-east-1. Теперь мы хотим также развернуть ресурсы еще в двух регионах, eu-central-1 и ap-northeast-1, и нам нужно будет определить поставщиков для каждого региона.

Обратите внимание, что у вас может быть только один провайдер с той же комбинацией имени и псевдонима. Мы можем определить больше провайдеров с разными псевдонимами для каждого региона. А при определении ресурсов мы можем ссылаться на конкретный профиль, используя схему PROFILE_NAME.ALIAS (например, aws.eu). Следуя этой логике, мы можем просто скопировать и вставить ресурсы и указать соответствующий профиль для каждого ресурса.

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

Поскольку группы безопасности могут находиться в определенном регионе и VPC, нам необходимо создать группы безопасности для каждого региона. И эти группы безопасности будут иметь одинаковые правила входа и выхода, поэтому нам нужно повторно использовать этот код.

В Terraform мы можем определять переменные и ссылаться на эти переменные во всем коде. Вот почему мы определим правила входа и выхода в переменных, как показано ниже. Определение переменной довольно простое: данные указываются в блоке default, а тип данных - в блоке type.

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

Вы можете найти полный код в приведенном ниже описании:

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

Разрушьте инфраструктуру

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

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

Заботиться.