Инфраструктура для бизнеса: создание модульной инфраструктуры
Cloud Server, Development | Комментировать запись
В предыдущем мануале этой серии мы рассказали, как использовать Terraform и Ansible для оркестровки ресурсов и развертывания приложения WordPress.
Terraform создает эти ресурсы с помощью файла main.tf. В настоящее время все ресурсы в этом файле у нас перечислены в индивидуальном порядке. Но чем сложнее становится ваша среда, тем больше вам нужно ресурсов и тем больше усилий и времени уйдет на их создание. В долгосрочной перспективе это усложнит управление конфигурацией.
В этом мануале мы обсудим некоторые способы упрощения этой конфигурации с помощью модулей Terraform и отдельных сред инфраструктуры. Эти понятия и идеи пригодятся вам при создании реальной установки.
Модули Terraform
Модули Terraform – это автономные пакеты конфигураций Terraform, которыми вы можете управлять как единой группой. Модули нужны для создания повторно используемых компонентов Terraform, а также для базовой организации кода.
Модули создают блоки многократно используемой инфраструктуры, которая может принимать входные и предоставлять выходные данные (как функция в высокоуровневых языках программирования). Модули могут принимать дополнительные входные аргументы для схожих элементов инфраструктуры, а также устанавливать значения по умолчанию для этих входных параметров. Это помогает организовать и упростить конфигурацию. Узнать больше о модулях можно в документации Terraform.
Взгляните на файл main.tf. Последний его раздел уже фактически использует модуль Terraform:
module "sippin_db" {
source = "github.com/cmndrsp0ck/galera-tf-mod.git?ref=v1.0.6"
...
}
Вы можете сравнить этот раздел с блоком ресурсов wp_node в верхней части файла, который содержит гораздо больше строк кода – разобрать его значительно сложнее. Как видите, модуль вызывается с помощью удаленного репозитория git. Вы можете использовать локальные пути к файлам – это подойдет для быстрой разработки и тестирования, но использование удаленного репозитория git повышет изоляцию вашей среды. Это особенно полезно при работе с несколькими инфраструктурными средами (например, если у вас есть промежуточная и производственная среда). Используя локальные пути к файлам в нескольких инфраструктурных средах, вы в конечном итоге сможете вносить изменения только для промежуточной среды; если же вы запустите приложение в производство, а путь к файлу модуля будет использоваться совместно, в приложении могут случиться сбои. Если у вас есть выделенные каталоги для каждой среды, вам придется поддерживать две или более копии ваших скриптов, и вернуться к предыдущему состоянию будет не так просто.
Использование удаленного репозитория git и указание номера версии для модуля позволяет избежать этой проблемы. Как упоминалось ранее, это также значительно упрощает возврат к известной рабочей версии, если что-то идет не так, что улучшает вашу способность управлять инцидентами и сбоями (о чем мы подробнее расскажем в главе 9).
Модуль может создать не только виртуальный сервер – он также создает теги, ноды кластера Galera, балансировщики нагрузки и плавающий IP. По сути, модули terraform – это хороший способ упаковки компонентов сервиса (или даже всего сервиса). Вы можете добавлять в модуль больше ресурсов или создавать выходные данные модуля, которые, в свою очередь, могут использоваться в качестве входных данных для других модулей, разработанных вами. Когда вам нужно создать новый модуль (например, чтобы добавить новый сервис или отделить некоторые вспомогательные функции), вы можете собрать выходные данные в ваших модулях, и они сохранятся как часть вашего состояния. Выходные данные модуля могут быть очень полезны, если вы хотите разделить доступную только для чтения информацию между разными компонентами вашей инфраструктуры или предоставить внешнему сервису возможность извлечь данные, которые ему пригодятся.
Проще говоря, если сравнить блоки ресурсов Terraform с кубиками Lego, то модули – это предварительно собранные блоки. В более сложной инфраструктуре модули могут предоставить данные о конфигурации других модулей.
Настройка инфраструктурных сред
В большинстве профессиональных проектов используется три среды: среда разработка, промежуточная среда и среда производства.
Среда разработки часто находится на локальной машине. Она дает вам возможность самостоятельно переделывать и тестировать работу. Промежуточная среда и среда производства обычно находятся в общедоступном пространстве и оркеструются с помощью автоматизированного процесса, такого как Terraform.
Тщательно продумав и спланировав рабочий процесс развертывания, вы сможете избежать головной боли на дальнейших этапах. Отчасти этот процесс связан с изоляцией сред друг от друга. Функция рабочего пространства Terraform сохраняет файлы terraform.tfstate отдельно для каждой среды, но изменения, внесенные в файлы terraform, описывающие ваши ресурсы, к ним не относятся. То есть эта функция – отличный способ внесения незначительных изменений, быстрого тестирования и развертывания, однако на нее не следует полагаться при масштабном развертывании, которое может потребовать изоляции сервисов друг от друга.
Вот пример дерева каталогов, который показывает, как вы можете настроить изоляцию среды с помощью каталогов:
.
├── ansible.cfg
├── bin/
├── environments/
│ ├── config/
│ │ └── cloud-config.yaml
│ │
│ ├── dev/
│ ├── prod/
│ │ ├── config -> ../config
│ │ ├── group_vars
│ │ ├── host_vars
│ │ ├── main.tf
│ │ ├── terraform.tfvars
│ │ ├── terraform-inventory -> ../terraform-inventory
│ │ └── variables.tf
│ │
│ ├── staging/
│ │ ├── config -> ../config
│ │ ├── group_vars
│ │ ├── host_vars
│ │ ├── main.tf
│ │ ├── terraform.tfvars
│ │ ├── terraform-inventory -> ../terraform-inventory
│ │ └── variables.tf
│ │
│ └── terraform-inventory
│
├── site.yml
├── wordpress.yml
│
└── roles/
Ключевая логика такого макета заключается в том, что файлы, относящиеся к аналогичным компонентам, находятся в разных средах, отдельно друг от друга.
Например, в каталоге environments есть подкаталог для каждой из трех сред, которые нам нужны: dev, staging и prod. Эта изоляция помогает предотвратить случайный запуск сценария Ansible или Terraform в неправильной среде. Вы можете сделать еще один уровень подкаталогов для хранения файлов различных частей инфраструктуры каждой среды.
Управление версиями модулей
Модули Terraform также могут вносить изменения в одну среду, не затрагивая при этом другие. Для примера взгляните на эти два модуля.
Это модуль для промежуточной среды (допустим, staging/main.tf):
module "sippin_db" {
source = "github.com/cmndrsp0ck/galera-tf-mod.git?ref=v1.0.8"
project = "${var.project}"
region = "${var.region}"
keys = "${var.keys}"
private_key_path = "${var.private_key_path}"
ssh_fingerprint = "${var.ssh_fingerprint}"
public_key = "${var.public_key}"
ansible_user = "${var.ansible_user}"
}
А это – модуль для среды производства (для примера prod/main.tf):
module "sippin_db" {
source = "github.com/cmndrsp0ck/galera-tf-mod.git?ref=v1.0.6"
project = "${var.project}"
region = "${var.region}"
keys = "${var.keys}"
private_key_path = "${var.private_key_path}"
ssh_fingerprint = "${var.ssh_fingerprint}"
public_key = "${var.public_key}"
ansible_user = "${var.ansible_user}"
}
Единственная разница между ними – значение ключа ref в конце строки source, который указывает версию для развертывания. В промежуточной среде это v1.0.8, а в производстве – v1.0.6. Контроль версий позволяет вносить и тестировать изменения в промежуточной среде, а уже затем развертывать их в производство. Подобные параметры упрощают конфигурацию.
Заключение
Подумайте, как упростить код своей инфраструктуры, сделав его модульным, и как изолировать среды для более безопасной разработки и развертывания. После этого можно посмотреть, как повысить скорость развертывания путем создания шаблонов. Также вы могли бы автоматизировать рабочий процесс развертывания с помощью инструментов непрерывной разработки, которые помогут вам безопасно и быстро внедрить новый код.
Читайте также: Введение в непрерывную интеграцию, доставку и развертывание
Tags: Terraform