Инфраструктура

Удаленная разработка #3: автоматизация инфраструктуры с Terraform в OVHcloud

Поделиться:
Remote development #3 – Industrialisation and Automation

После самостоятельной настройки вашего сервера шаг за шагом наступает время автоматизировать весь процесс.

Идея проста: описать инфраструктуру в конфигурационных файлах и позволить Terraform управлять ресурсами в OVHcloud.

Вот вводное руководство по Terraform с множеством полезной информации: https://support.us.ovhcloud.com/hc/en-us/articles/22648864003219-Using-Terraform-with-OVHcloud.
А также ссылка на официальный провайдер Terraform от OVHcloud: https://registry.terraform.io/providers/ovh/ovh/latest

Автоматизация развёртывания состоит из двух этапов:

  • Развёртывание экземпляра Public Cloud
  • Развёртывание прикладной части (vscode-server) и её настройка

1. Сердце автоматизации: Cloud-init-скрипт

Прежде чем перейти к Terraform, нужно понять, как сервер самостоятельно настраивается во время инициализации.
Для этого используется cloud-init — стандарт, позволяющий выполнять скрипты при первой загрузке экземпляра.

Что вы автоматизируете с помощью этого скрипта:

  • Обновление системы (apt update/upgrade)
  • Установку code-server через официальный скрипт
  • Установку и настройку Caddy (для автоматического SSL)
  • Настройку брандмауэра (UFW)

Подобные файлы имеют особый синтаксис; cloud-config.yaml будет представлен ниже.

Но важный момент, который стоит запомнить: зачем использовать этот формат?

  • Идемпотентность: cloud-init гарантирует, что всё будет готово с первой загрузки.
  • Безопасность с самого начала: UFW активируется немедленно, сокращая окно уязвимости.
  • Интеграция с Terraform: достаточно одной строки: user_data = file("cloud-config.yaml")

2. Использование Terraform для развёртывания

Terraform позволяет запускать экземпляры гораздо проще и быстрее.
Его настройка также даёт несколько преимуществ:

  • Постоянство данных: при terraform destroy экземпляра том данных может быть сохранён (цель описана в главе 2).
  • Масштабируемость: при росте проекта можно изменить размер тома и/или flavour.
  • Переносимость: том данных можно отмонтировать и подключить к другой машине.

Чтобы не загромождать пост, мы не будем копировать код сюда, но по этой ссылке на репозиторий GitHub есть всё необходимое для развёртывания за несколько минут:
https://github.com/RemyAtOVH/blogpost-dev-server

Его использование:

uubuntu@vscode-server:~$ source openrc.production.sh
ubuntu@vscode-server:~$ terraform init
ubuntu@vscode-server:~$ terraform plan
ubuntu@vscode-server:~$ terraform apply
[...]
Apply complete! Resources: 4 added, 0 changed, 0 destroyed.

Перед применением cloud-init (или без него) существует дополнительный том /dev/sdb, размер которого задан в спецификациях Terraform:

ubuntu@vscode-server-automated:~$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
[…]
sda       8:0    0   25G  0 disk 
[…]
sdb       8:16   0   10G  0 disk 

Именно это обеспечит сохранность данных.

Вы могли бы вручную удалить экземпляр и другие компоненты, не удаляя его.
Чтобы предотвратить удаление при terraform destroy, был добавлен параметр:

lifecycle { prevent_destroy = true }

Во время первого запуска скрипты установки могут выполняться долго. Вы можете отследить их шаги с помощью простого tail:

ubuntu@vscode-server-automated:~$ tail -f /var/log/cloud-init-output.log

После автоматического выполнения cloud-init всё, что в предыдущих главах настраивалось вручную, теперь сделано автоматически и воспроизводимо!

Таким образом, при необходимости можно развернуть эту настроенную удалённую среду разработки (за несколько минут выполнения) и, возможно, удалить её через несколько часов или дней использования.

В этой серии глав мы превратили простую идею — иметь доступ к VS Code откуда угодно — в профессиональную, автоматизированную и отказоустойчивую инфраструктуру.
Ниже перечислены шаги и достигнутый прогресс.

  • Глава 1: первые шаги по ручной установке для понимания механики code-server.
  • Глава 2: обеспечение безопасности с помощью обратного прокси (Caddy) и брандмауэра (UFW) для комфортной работы по HTTPS.
  • Глава 3: данная статья, в которой мы используем Terraform и OpenStack для лучшей воспроизводимости.

Автоматизация, реализованная с помощью развёртывания OVHcloud на базе Public Cloud на основе OpenStack, обеспечивает надёжную основу.

Отсюда можно пойти ещё дальше: добавить автоматическое резервное копирование томов (создание снимков), объединить это с CI/CD-пайплайном или даже развернуть эту среду с помощью docker-compose или Kubernetes.

Remote development #3 – Industrialisation and Automation