Инфраструктура как код — методология, которая уже стала стандартом де-факто, а через несколько лет, будет просто идти по умолчанию при развертывании любой системы. Она предполагает, что с конечной системой (кластером, сервером) работает не администратор напрямую, как раньше, а код, который администратор создал. Ещё одна из отличительных черт этой методологии — декларативность написанного кода.
Администратор системы сегодня описывает не то, как нужно организовать систему (императивный подход, явный пример: Bash), а конечное состояние системы, которое он ожидает увидеть. Такую декларативность сегодня организует ряд утилит и инструментов, одним из которых является Terraform. Ниже я представляю вам мой небольшой хэндбук, демонстрирующий подход infrastructure as a code.
Общие обозначения
Terraform — это инструмент для управления и конфигурации облачной инфраструктуры на облачных сервисах таких как DigitalOcean, Heroku, AWS и многих других. Если вы хотите подробнее ознакомиться с Terraform, советую прочитать официальную документацию, она очень понятно и подробно написана и снабжена большим количеством рабочих примеров.
Для нашей задачи мы будем использовать услуги облачного провайдера Hetzner. Посредством данного инструмента легко применять практику “Инфраструктура как код” (Infrastructure as Code).
Для дальнейшей работы необходимо установить terraform и иметь доступ к облачным ресурсам.
Цель
Развернуть инстанс на Hetzner через терраформ и держать конфигурации инфраструктуры в репозитории, что очень удобно при работе в команде и в случае модернизации как всей инфраструктуры, так и какой либо части. То есть применить Infrastructure as Code.
Решение
Для начала будут расписаны основные конфигурации подключения к API хостинга, хранилище стейтов, и конфигурации для одного инстанса, и описание юзердаты (скриптов при старте инстанса)
Чтобы не хардкодить данные которые могут меняться будем хранить в файлах переменных:
- variables.tf — файл с переменными, которые не являются секретными и могут храниться в репозитории.
- terraform.tfvars — файл с переменными, которые не рекомендуется хранить в репозитории (ключи доступа, токены и прочее). Такие данные нужно хранить очень аккуратно. Кстати, мой коллега Олег рассказал, как правильно хранить сикреты в своей статье.
Реализация
- Создаем репозиторий для хранения конфигураций в нем (надежность, удобство).
2. Создаем .gitignore для нашего кейса конфигурации.
3. Чтобы начать использовать API, сначала нужно получить токен API.
Войдите в Hetzner Cloud Console https://console.hetzner.cloud, выберите проект, перейдите к Access→ Tokens и создайте новый токен. Обязательно скопируйте токен, потому что он вам больше не будет показан. Токен привязан к проекту, для взаимодействия с API другого проекта необходимо создать новый токен внутри проекта
4. Создаем файлы конфигураций (в формате json):
- state.tf — конфигурация для бекенда где будет храниться состояние инфраструктуры. В нашем случае выбор пал на S3 bucket, так как не требует особых усилий в использовании, заранее создаем bucket на S3 и прописываем к нему доступы в файле
- main.tf — файл, в котором будут определены основные конфигурации
variables.tf — файл с основными переменными
- instance.tf — файл конфигурации инстанса
Файл юзер-даты user-data/instance.tpl — по сути является bash скриптом, в который можно записать действия в зависимости от задачи, в нашем случае идет:
- Установка docker;
- Docker-Compose;
- и прочие настройки.
Дополнения
Так как файл terraform.tfvars в .gitignore небольшой пример
Запуск
Для старта выполняем команды в папке с конфигами
Заключение
Теперь у нас есть:
- Рабочий инстанс с установленным ПО готовый к работе (в зависимости от задач).
- Конфигурации, которые хранятся в репозитории и не забудутся, не потеряются.
- Практика “Инфраструктура как код”.
- Воспроизводимость, без необходимости вручную настраивать сервер с нуля, и экономия времени в будущем.
Ранее статья была опубликована тут.
