Заводить ли личный блог или сайт? Часть I. Готовим инфраструктуру c помощью Terraform

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

Однако, порефлексировав, я понял, что вся работа, которая не дает ожидаемого результата не напрасна. Как минимум — это опыт, а опыт штука полезная. Никогда не угадаешь, что тебе может пригодится в будущем. К тому же не стоит сбрасывать со счетов накопительный эффект общей массы знаний. Звучит довольно туманно, поэтому приведу пример. Разработка показала мне, как можно копить фрагментированные кусочки знаний долгое время, которые в определенный момент могут сложится в полную картину, а ты будешь удивляться, как не понимал чего-то раньше.

Так о чем это я? Я буду делать личный блог или сайт, на самом деле еще не знаю во что это выльется. Но как показал опрос в моем TG канале, у ребят, как и у меня, есть интерес к тому, как можно сделать и использовать блог, чтобы он приносил тебе пользу в каком-либо виде. Если дело пойдет, то здесь будет целая арка статей. Приступим!

С чего начать?

На самом деле в голосовании в своем канале, я обозначил более широкую тему: «Как сделать личный сайт, чтобы он в каком-то виде работал на тебя?». То есть речь шла о чем угодно, от блога до сайта студии по разработке. Но сделать что-то с таким широким выбором трудно, поэтому пообщавшись с ребятами, я решил начать с малого — личный блог.

Получается первое, что нужно сделать — определиться с форматом (блог, сайт студии и т.п.) и придерживаться его.

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

• https://wesbos.com/javascript

• https://addyosmani.com

• https://kentcdodds.com

• https://sarah.dev

• https://ericelliottjs.com

• https://davidwalsh.name

• https://rauchg.com

• https://wassim.dev

Критерии у меня были так себе — если сайт хоть как-то цеплял, то кидал в список. А когда посмотрел референсы, то начал думать о том, как реализовать нечто подобное.

То есть второй пункт — выбор инструментов.

Конечно сразу же приходит на ум такой инструмент, как Astro. На если использовать Astro и делать обычный статический блог, то с большой долей вероятности, здесь бы была только одна статья, а у меня бы появился блог, в который мне бы пришлось как-то привлекать трафик. И скорее всего — все это также бы пошло в стол. Поэтому я выбрал путь поинтереснее. А именно самостоятельно развернуть инфраструктуру, используя IaC подход, и написать динамический блог с cms на минималках, используя SSR.

Таким образом, я попробую «убить нескольких зайцев одним камнем». А именно:

1. Попрактиковаться в конфигурации облачной инфраструктуры.

2. Попробовать наконец-то SSR, а то для внутрекорпоративных продуктов он не в ходу.

3. Сделать блог.

Далее идет третий пункт — декомпозиция. На данном этапе я разделил задачу на три шага:

1. Написание конфигурации облачной инфраструктуры с помощью Terraform в облаке Selectel.

2. Настройка развернутой инфраструктуры с помощью Ansible.

3. Написание блога (Декомпозицию этого пункта проведу позже).

Немного о Terraform

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

Terraform появился на свет благодаря HashiCorp и стал довольно популярным. Он хранит свой конфиг в файлах, написанных на HCL (ямлоподобные конфиги). При изменении файлов конфига Terraform автоматически определяет, что уже развернуто, а что следует добавить или удалить.

Terraform можно использовать для работы с любым REST API, правда, для API нужен особый плагин под названием провайдер. Полный список провайдеров для любых облачных сервисов можно найти в Terraform Registry. Кроме того, из Terraform Registry можно загрузить и готовые рецепты тех или иных сервисов — модули.

Обычно все облачные сервисы пишут подробные инструкции для работы с их API через Terraform. Вот некоторые из них:

1. Selectel

2. Yandex Cloud

3. Google Cloud

К сожалению, сейчас, находясь в России, нельзя просто так взять и скачать себе Terraform. Вам потребуется VPN или зеркало. Если вы использовали зеркало, то определите в переменной PATH путь к бинарнику:

export PATH=$PATH:<path>

Установите Terraform, используя инструкцию из документации HashiCorp или эту инструкцию.

Теперь о работе с Terraform. Если кратко, то алгоритм работы следующий:

1. Определить, из каких элементов состоит инфраструктура.

2. Написать конфигурационные файлы.

3. terraform init — установить плагины Terraform, необходимые для используемых элементов.

4. terraform plan — посмотреть, какие конкретно изменения Terraform внесёт в существующую инфраструктуру.

5. terraform apply — применить эти изменения.

Из чего состоит конфигурация? 

Провайдер в Terraform — это плагин для работы с каким-либо сервисом. Для популярных сервисов (облачных и не очень) уже написаны плагины-провайдеры. Если для управления инфраструктурой при помощи Terraform этих провайдеров недостаточно, можно написать свой плагин.

Пример конфигурации провайдеры для Selectel:

# Initialize Selectel provider with service user. provider "selectel" {   username    = var.username   password    = var.password   domain_name = var.domain_name   auth_region = var.region   auth_url    = var.auth_url }

Ресурс — это описание сущности, которую можно создать в API сервиса (с ним общается провайдер). Список доступных ресурсов можно подсмотреть в документации провайдера, я буду использовать провайдеры Selectel и Openstack.

Пример конфигурации хранилища от Selectel:

resource "openstack_blockstorage_volume_v3" "volume_1" {   name              = "volume-for-${var.server_name}"   size              = var.server_root_disk_gb   image_id          = module.image_datasource.image_id   volume_type       = var.server_volume_type   availability_zone = var.server_zone   metadata          = var.server_volume_metadata    lifecycle {     ignore_changes  = [image_id]   } }

Datasource — это дополнительный, подключаемый источник данных. Например, с помощью datasource мы можем получить какой-либо набор данных и сложить их в переменную для дальнейшего использования.

Пример определения datasource и его применения в ресурсе:

data "openstack_networking_network_v2" "external_net" {   name     = var.router_external_net_name   external = true }  resource "openstack_networking_router_v2" "router_1" {   name                = var.router_name   external_network_id = data.openstack_networking_network_v2.external_net.id }

Variables — переменные в Terraform можно поделить на три вида:

1. Input переменные.

2. Output переменные.

3. Local переменные.

Если провести аналогию с языком программирования, то Input переменные — аргументы функции. Каждая входная переменная, принимаемая модулем, должна быть объявлена c помощью блока variable:

variable "server_zone" {   default         = "ru-9a"   type            = string   description     = "Instance availability zone"   validation {     condition     = contains(toset(["ru-1a", "ru-3a", "ru-9a"]), var.instance_zone)     error_message = "Select availability zone from the list: ru-1a, ru-3a, ru-9a."   }   sensitive       = true   nullable        = false }

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

output "server_id" {   value = openstack_compute_instance_v2.instance_1.id }

Local переменные напоминают локальные переменные в функциях. Они задаются с помощью блока locals:

locals {   service_name = "virtual machine"   owner        = «Selectel }

Локальные переменные полезны, когда в конфигурации есть многократное повторение одних и тех же значений.

Задавать значения переменных можно, используя дефолтные значения при их объявлении, как показано в примерах выше, а также можно использовать следующие методы:

1. В cli через -var (поштучно):

$ terraform apply -var="server_zone=ru-9a"

2. Через файл с расширением .tfvars (пачками). Создаём файл *.tfvars:

server_zone=ru-9a

По умолчанию загружаются значения из terraform.tfvars, но можно явно обозначить файл для загрузки:

$ terraform apply -var-file="testing.tfvars"

3. Через переменные окружения. Переменная должна начинаться с TF_VAR_, а дальше уже имя переменной:

# для простого типа $ export TF_VAR_server_zone=ru-9a  # для составного типа $ export TF_VAR_server_zone='["ru-9a","ru-3a"]'  $ terraform apply

Подробнее о переменных можно почитать здесь.

Модуль — набор конфигурационных файлов в одной директории. Если в каталоге лежит хотя бы один файл конфигурации Terraform .tf — это уже модуль. Структура модуля обычно выглядит так:

├── LICENSE ├── README.md ├── main.tf ├── modules/ ├── variables.tf ├── outputs.tf

Подробнее про структуру можно почитать здесь.

Модули бывают корневые (root) и дочерние (child). Корневой — наш модуль, а дочерними будут все модули, которые мы подключим в корневом. Дочерние модули можно хранить локально, положить в папку modules в рутовом модуле, или брать с удалённых registry (GitLab, HTTP URL, Terraform Registry).

Мета-аргументы — Язык Terraform определяет несколько мета-аргументов, которые можно использовать с любым типом ресурсов для изменения их поведения. К ним относятся:

1. depends_on — для указания скрытых зависимостей.

2. count — для создания нескольких экземпляров ресурсов, количество экземпляров = count. Подробности тут.

3. for_each создаёт несколько экземпляров модуля из одного блока модуля. За подробностями сюда.

4. provider — для выбора конфигурации провайдера. Дополнительно читать тут.

5. lifecycle — для настройки жизненного цикла. Сейчас не используется, но зарезервирован на будущее.

За подробностями по мета-аргументам стоит заглянуть сюда.

Приступаю к настройке

Прежде чем я начну описывать инфраструктуру, должен отметить, что основная моя специализация — это Frontend разработка, а мой уровень знаний по DevOps складывается из решения различных вопросов на работе и курса от Яндекс.Практикум, что я прошел год назад. Поэтому сразу скажу, что мои решения не претендуют на прилагательное «идеальные», скорее всего я могу чего-то не знать и рассчитываю на вашу помощь, если вы имеете компетенцию в этой сфере.

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

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

├── README.md ├── main.tf ├── modules/ ├──── flavor/ ├──── floatingip/ ├──── image_datasource/ ├──── keypair/ ├──── nat/ ├──── project/ ├──── project_with_user/ ├──── server_remote_root_disk/ ├── vars.tf ├── versions.tf ├── outputs.tf

Для начала отдельно отмечу файл versions.tf. Там указаны версии провайдеров, которые будут использоваться при инициализации Terraform:

terraform {   required_providers {     selectel = {       source  = "selectel/selectel"       version = ">= 5.1.1"     }     openstack = {       source  = "terraform-provider-openstack/openstack"       version = ">= 2.0.0"     }   }   required_version = ">= 1.9.2" }

Теперь стоит рассказать о корневом модуле, для этого рассмотрим файл main.tf:

# Initialize Selectel provider with service user. provider "selectel" {   username    = var.username   password    = var.password   domain_name = var.domain_name   auth_region = var.region   auth_url    = var.auth_url }  # Create the main project with user. # This module should be applied first: # terraform apply -target=module.project_with_user module "project_with_user" {   source = "./modules/project_with_user"    project_name      = var.project_name   project_user_name = var.project_user_name   user_password     = var.user_password }  # Initialize Openstack provider. provider "openstack" {   user_name           = var.project_user_name   tenant_name         = var.project_name   password            = var.user_password   project_domain_name = var.domain_name   user_domain_name    = var.domain_name   auth_url            = var.auth_url   region              = var.region }  # Create an OpenStack Compute instance. module "server" {   source = "./modules/server_remote_root_disk"    # OpenStack Instance parameters.   keypair_name           = var.keypair_name   server_group_id        = var.server_group_id   server_image_name      = var.server_image_name   server_license_type    = var.server_license_type   server_name            = var.server_name   server_preemptible_tag = var.server_preemptible_tag   server_ram_mb          = var.server_ram_mb   server_root_disk_gb    = var.server_root_disk_gb   server_vcpus           = var.server_vcpus   server_volume_metadata = var.server_volume_metadata   server_volume_type     = var.server_volume_type   server_zone            = var.server_zone    depends_on = [     module.project_with_user,   ] }

Здесь определяются два провайдера: Selectel и Openstack, также два модуля: project_with_user и server. Большинство переменных задано в файле vars.tf с помощью дефолтных значений, за исключением следующих четырех:

• username — имя сервисного пользователя, которого вы должны создать в админке Selectel, подробнее здесь.

• password — пароль от вышеупомянутого сервисного пользователя.

• domain_name — идентификатор аккаунта Selectel, который можно посмотреть в панели управления в правом верхнем углу.

• user_password — любой придуманный вами пароль для нового сервисного пользователя, который будет управлять созданным проектом.

Как вы могли заметить модуль server зависит от project_with_user, поэтому применять конфигурацию необходимо с помощью двух команд apply:

env \   TF_VAR_username=USER \   TF_VAR_password=PASSWORD \   TF_VAR_domain_name=ACCOUNT_ID \   TF_VAR_user_password=xxx \   terraform apply -target=module.project_with_user  env \   TF_VAR_username=USER \   TF_VAR_password=PASSWORD \   TF_VAR_domain_name=ACCOUNT_ID \   TF_VAR_user_password=xxx \   terraform apply

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

flavor

Flavor — это предустановленная конфигурация, определяющая вычислительные ресурсы, память и емкость хранилища экземпляра ВМ. В проекте я его оставил для примера, а при создании ВМ использую идентфикатор готового Flavor от Selectel, все варианты которых можно посмотреть здесь. Код ресурса:

resource "openstack_compute_flavor_v2" "flavor_1" {   name      = var.flavor_name   ram       = var.flavor_ram_mb   vcpus     = var.flavor_vcpus   disk      = var.flavor_local_disk_gb   is_public = var.flavor_is_public    lifecycle {     create_before_destroy = true   } }

floatingip

Плавающий IP-адрес — это своего рода виртуальный IP-адрес, который можно динамически перенаправлять на любой сервер в той же сети. Он используется для подключения к ВМ, как публичный IP. Код ресурса:

resource "openstack_networking_floatingip_v2" "floatingip_1" {   pool = "external-network" }

image_datasource

Источник данных, где хранится информация об образе системы, которую нужно будет развернуть на ВМ. Код:

data "openstack_images_image_v2" "image_1" {   name        = var.image_name   visibility  = "public"   most_recent = true }

keypair

Модуль, через который можно подвязать ваш публичный ssh-ключ к созданному сервизному пользователю:

module "keypair" {   count  = var.keypair_name != "" ? 1 : 0   source = "../keypair"    keypair_name       = var.keypair_name   keypair_public_key = file("~/.ssh/id_rsa.pub")   keypair_user_id    = selectel_iam_serviceuser_v1.serviceuser_1.id }

nat

Модуль, который создает объекты NAT. Network address translation (NAT) — это метод сопоставления одного пространства IP-адресов с другим путем изменения информации о сетевых адресах в IP-заголовке пакетов. Код модуля:

data "openstack_networking_network_v2" "external_net" {   name     = var.router_external_net_name   external = true }  resource "openstack_networking_router_v2" "router_1" {   name                = var.router_name   external_network_id = data.openstack_networking_network_v2.external_net.id }  resource "openstack_networking_network_v2" "network_1" {   name = var.network_name }  resource "openstack_networking_subnet_v2" "subnet_1" {   network_id      = openstack_networking_network_v2.network_1.id   dns_nameservers = var.dns_nameservers   name            = var.subnet_cidr   cidr            = var.subnet_cidr }  resource "openstack_networking_router_interface_v2" "router_interface_1" {   router_id = openstack_networking_router_v2.router_1.id   subnet_id = openstack_networking_subnet_v2.subnet_1.id }

project

Модуль для создания проекта в Selectel. Код:

resource "selectel_vpc_project_v2" "project_1" {   name        = var.project_name }

project_with_user

Модуль, который использует модуль project и создает сервисного пользователя для этого проекта с привязанным ssh-ключом. Код модуля:

module "project" {   source       = "../project"   project_name = var.project_name } resource "selectel_iam_serviceuser_v1" "serviceuser_1" {   name     = var.project_user_name   password = var.user_password   role {     role_name = "member"     scope     = "project"     project_id = module.project.project_id   } }  module "keypair" {   count  = var.keypair_name != "" ? 1 : 0   source = "../keypair"    keypair_name       = var.keypair_name   keypair_public_key = file("~/.ssh/id_rsa.pub")   keypair_user_id    = selectel_iam_serviceuser_v1.serviceuser_1.id }

server_remote_root_disk

Модуль для создания виртуальной машины с внешним хранилищем, который использует созданные объекты NAT и публичный IP. Код модуля:

resource "random_string" "random_name" {   length  = 5   special = false }  # module "flavor" { #   source        = "../flavor" #   flavor_name   = "flavor-${random_string.random_name.result}" #   flavor_vcpus  = var.server_vcpus #   flavor_ram_mb = var.server_ram_mb # }  module "nat" {   source = "../nat" }  resource "openstack_networking_port_v2" "port_1" {   name       = "${var.server_name}-eth0"   network_id = module.nat.network_id    fixed_ip {     subnet_id = module.nat.subnet_id   } }  module "image_datasource" {   source     = "../image_datasource"   image_name = var.server_image_name }  resource "openstack_blockstorage_volume_v3" "volume_1" {   name              = "volume-for-${var.server_name}"   size              = var.server_root_disk_gb   image_id          = module.image_datasource.image_id   volume_type       = var.server_volume_type   availability_zone = var.server_zone   metadata          = var.server_volume_metadata    lifecycle {     ignore_changes = [image_id]   } }  resource "openstack_compute_instance_v2" "instance_1" {   name              = var.server_name   # flavor_id          = module.flavor.flavor_id   // NOTE: [Denis Voronin] 25.12.2024 - flavor_id is shared Line fixed configurations with vCPU share of 10%;   // https://docs.selectel.ru/en/cloud/servers/create/configurations/#shared-line   flavor_id          = "9011"   key_pair          = var.keypair_name   availability_zone = var.server_zone    network {     port = openstack_networking_port_v2.port_1.id   }    dynamic "network" {     for_each = var.server_license_type != "" ? [var.server_license_type] : []      content {       name = var.server_license_type     }   }    block_device {     uuid             = openstack_blockstorage_volume_v3.volume_1.id     source_type      = "volume"     destination_type = "volume"     boot_index       = 0   }    tags = var.server_preemptible_tag    vendor_options {     ignore_resize_confirmation = true   }    dynamic "scheduler_hints" {     for_each = var.server_group_id != "" ? [var.server_group_id] : []     content {       group = var.server_group_id     }   } }  module "floatingip" {   source = "../floatingip" }  resource "openstack_networking_floatingip_associate_v2" "association_1" {   port_id     = openstack_networking_port_v2.port_1.id   floating_ip = module.floatingip.floatingip_address }

Если применить конфигурацию, то по результату мы получим публичный IP адрес, который можно использовать для подключения к ВМ с помощью SSH:

ssh remote_username@remote_host

remote_username в нашем случае будет root, а remote_host — наш публичный IP.

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

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

22 рубля с копейками в сутки или почти 670 рублей в месяц. Для статического блога было бы дорогавто)

На этом все. Спасибо всем, кто дочитал до конца!) Буду рад коммаентариям и если зайдете в мой TG канал.