СОЗДАНИЕ ИНФРАСТРУКТУРЫ КОМПАНИИ В AWS С ПОМОЩЬЮ TERRAFORM – часть 1

Эта статья является частью серии статей, посвященных созданию инфраструктуры компании на AWS с помощью Terraform. Указанной компании необходимо решение WordPress для разработчиков и инструментальное решение для инженеров DevOps. Все это будет находиться в частной сети. Часть 1 посвящена базовой вводной информации, созданию VPC и подсетей. Я проведу вас через все процессы, связанные с этим, если вы захотите создать такую же или подобную инфраструктуру, одновременно изучая и совершенствуя Terraform. Вы будете писать код в Terraform и создавать инфраструктуру, как показано ниже.

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

ШАГ 1 – Настройка

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

  2. Настройте программный доступ со своего рабочего места. Я бы рекомендовал использовать AWSCLI для этого с помощью команды aws configure.

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

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

ШАГ 2 – Создание VPC

  1. Создайте структуру каталогов, которая должна содержать:
  • папка (назовите ее как угодно)

  • main.tf файл, который является нашим основным конфигурационным файлом, где мы собираемся определить наши определения ресурсов.

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

  • terraform.tfvars файл, который будет содержать значения для ваших переменных. Этот проект очень скоро станет сложным, и я думаю, что лучше понять, что такое переменные и как ими эффективно управлять. Я наткнулся на эту замечательную статью от Spacelift, которая как нельзя лучше подходит для этого.

2.
Настройте Terraform CLI

3.
Добавьте блок провайдера (провайдером является AWS)

provider "aws" {
  region = var.region
}
Войдите в полноэкранный режим Выйдите из полноэкранного режима

4.
Добавьте ресурс, который создаст VPC для инфры.

# Create VPC
resource "aws_vpc" "main" {
  cidr_block                     = var.vpc_cidr
  enable_dns_support             = var.enable_dns_support 
  enable_dns_hostnames           = var.enable_dns_support
  enable_classiclink             = var.enable_classiclink
  enable_classiclink_dns_support = var.enable_classiclink
Войдите в полноэкранный режим Выйдите из полноэкранного режима

5.
Запустите terraform init. Terraform полагается на плагины, называемые “провайдерами”, для взаимодействия с облачными провайдерами, провайдерами SaaS и другими API. Конфигурации Terraform должны объявить, какие провайдеры им требуются, чтобы Terraform мог установить и использовать их. terraform init находит и загружает этих провайдеров либо из публичного реестра Terraform Registry, либо из реестра провайдеров сторонних производителей. Именно эта часть генерирует .terraform.lock.hcl, который вы заметите, когда запустите terraform init.

Обратите внимание, что был создан новый каталог: .terraform.... Это место, где Terraform хранит плагины. Как правило, удалять эту папку не опасно. Это просто означает, что вам придется снова выполнить terraform init, чтобы загрузить их.

6.
Запустите terraform plan, чтобы посмотреть, что будет создано, когда вы решите создать ваш ресурс aws_vpc.

7.
Запустите terraform apply, если только вы принимаете изменения, которые произойдут.

Создается новый файл terraform.tfstate Так Terraform поддерживает себя в курсе точного состояния инфраструктуры. Он читает этот файл, чтобы знать, что уже существует, что должно быть добавлено или уничтожено на основе всего разрабатываемого кода Terraform.

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

ШАГ 3 – Создание подсети

Согласно проекту инфраструктуры, вам потребуется 6 подсетей:

  • 2 публичные
  • 2 частные для веб-серверов
  • 2 частные для уровня данных

Создайте первые 2 публичные подсети.

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

# Create public subnets
resource "aws_subnet" "public" {
  count  = var.preferred_number_of_public_subnets == null ? length(data.aws_availability_zones.available.names) : var.preferred_number_of_public_subnets   
  vpc_id = aws_vpc.main.id
  cidr_block              = cidrsubnet(var.vpc_cidr, 4 , count.index)
  map_public_ip_on_launch = true
  availability_zone       = data.aws_availability_zones.available.names[count.index]
}
Вход в полноэкранный режим Выход из полноэкранного режима

Окончательный файл main.tf будет выглядеть следующим образом:

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

Оцените статью
Procodings.ru
Добавить комментарий