feat: Add demonstration 5.1
This commit is contained in:
Black_Raven committed
1 parent
d481fc05ff
commit
401ae1dd51
5 files changed
+668
No files matched your search
@@ -0,0 +1,187 @@
|
||||
---
|
||||
course_code: VKCLOUD-80
|
||||
artifact_type: PR
|
||||
module: 5
|
||||
task_code: 1
|
||||
task_title: Infrastructure as Code с Terraform
|
||||
student_fio: Ремизов Кирилл Львович
|
||||
date: 2026-06-15
|
||||
source_docs:
|
||||
- 3-Конспект лекций - VK 1.md
|
||||
- 4-Практические работы - VK -1.md
|
||||
commands_used:
|
||||
- terraform init
|
||||
- terraform plan -var="my_ip=95.37.52.68/32"
|
||||
- terraform apply -var="my_ip=95.37.52.68/32"
|
||||
- terraform destroy
|
||||
attached_files:
|
||||
- VKC_PR_M05_01_complete-infra_РемизовКЛ_20260615.tf
|
||||
- VKC_PR_M05_01_terraformLog_РемизовКЛ_20260615.log
|
||||
- VKC_PR_M05_01_network_РемизовКЛ_20260615.png
|
||||
status: final
|
||||
---
|
||||
|
||||
# Отчет по практической демонстрации
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Освоить **Infrastructure as Code (IaC)** с помощью инструмента Terraform для управления ресурсами VK Cloud. Научиться декларативно описывать полную инфраструктуру (сеть, группы безопасности, виртуальные машины, балансировщик нагрузки), применять изменения с помощью `terraform apply` и проверять работоспособность созданной среды. Закрепить понимание жизненного цикла Terraform (init, plan, apply, destroy) и управления состоянием.
|
||||
|
||||
## 2. Что было прочитано перед выполнением
|
||||
|
||||
- **Документ:** 3-Конспект лекций - VK 1.md
|
||||
- **Раздел/тема:** Модуль 5 «Контейнеризация и автоматизация», тема 5.1 «Infrastructure as Code (IaC) с Terraform»
|
||||
- **Ключевые понятия:**
|
||||
- Декларативный подход против императивного
|
||||
- Язык HCL (блоки `terraform`, `provider`, `resource`, `variable`, `output`)
|
||||
- Провайдер `vkcs` (source = "vk-cs/vkcs")
|
||||
- Ресурсы: `vkcs_networking_network`, `vkcs_networking_subnet`, `vkcs_networking_secgroup` и `secgroup_rule`, `vkcs_compute_keypair`, `vkcs_compute_instance`, `vkcs_lb_loadbalancer`, `vkcs_lb_listener`, `vkcs_lb_pool`, `vkcs_lb_monitor`, `vkcs_lb_member`
|
||||
- `user_data` для инициализации ВМ (установка nginx)
|
||||
- Переменные (`variable "my_ip"`) и выходные данные (`output`)
|
||||
- Жизненный цикл: `terraform init`, `plan`, `apply`, `destroy`
|
||||
|
||||
- **Дополнительно:** Документ 4-Практические работы - VK -1.md, демонстрация 5.1 «Infrastructure as Code с Terraform» (полная конфигурация `complete-infra.tf` и пояснения).
|
||||
|
||||
## 3. Ход выполнения
|
||||
|
||||
### Демонстрация 5.1: Полная инфраструктура через Terraform
|
||||
|
||||
#### Этап 1. Подготовка конфигурационного файла
|
||||
|
||||
**Действие:**
|
||||
Создал файл `VKC_PR_M05_01_complete-infra_РемизовКЛ_20260615.tf`, взяв за основу пример из документации, но с учётом актуальных ресурсов VK Cloud. В отличие от устаревшего примера (использовавшего `vkcs_compute_secgroup`), применил современные ресурсы:
|
||||
- `vkcs_networking_secgroup` для группы безопасности
|
||||
- `vkcs_networking_secgroup_rule` для правил (входящий SSH с моего IP, входящий HTTP отовсюду)
|
||||
|
||||
**Содержимое конфигурации (основные блоки):**
|
||||
- Провайдер `vkcs` (переменные окружения из RC-файла)
|
||||
- Переменная `my_ip` для ограничения доступа по SSH
|
||||
- Сеть `vkcs_networking_network.main` и подсеть `vkcs_networking_subnet.public` (CIDR 192.168.1.0/24)
|
||||
- Группа безопасности `vkcs_networking_secgroup.web` с двумя правилами (SSH, HTTP)
|
||||
- SSH-ключ `vkcs_compute_keypair.main` (публичный ключ из `~/.ssh/id_rsa.pub`)
|
||||
- Две ВМ `vkcs_compute_instance.web[0]` и `[1]` с `user_data` для автоматической установки nginx и создания индексной страницы с номером сервера
|
||||
- Балансировщик `vkcs_lb_loadbalancer.main`, слушатель `listener.http`, пул `pool.web`, монитор `monitor.web` и два члена пула (привязка к ВМ)
|
||||
- Выходные данные: `load_balancer_ip` и `web_servers_ips`
|
||||
|
||||
**Ключевые отличия от шаблонного примера:**
|
||||
- Явно указаны `flavor_id` и `image_id` (взяты из предварительных запросов через OpenStack CLI, соответствующие `Basic-1-2-20` и актуальному образу Ubuntu 24.04)
|
||||
- Добавлен блок `random` (не использован, но провайдер указан в `required_providers` для будущих задач)
|
||||
|
||||
#### Этап 2. Инициализация и проверка плана
|
||||
|
||||
```bash
|
||||
# Загрузка переменных окружения из RC-файла (скачан в консоли)
|
||||
source project-openrc.sh
|
||||
|
||||
# Инициализация Terraform (загрузка провайдера vkcs)
|
||||
terraform init
|
||||
|
||||
# Просмотр плана изменений с подстановкой моего IP
|
||||
terraform plan -var="my_ip=95.37.52.68"
|
||||
```
|
||||
|
||||
**Результат:**
|
||||
План показал создание 14 ресурсов (сеть, подсеть, группа безопасности, два правила, ключ, две ВМ, балансировщик, слушатель, пул, монитор, два члена пула). Все изменения – только добавление, никаких обновлений или удалений.
|
||||
|
||||
*Фрагмент лога (план) сохранён в [[VKC_PR_M05_01_terraformLog_РемизовКЛ_20260615.log]]*
|
||||
|
||||
#### Этап 3. Применение конфигурации
|
||||
|
||||
```bash
|
||||
terraform apply -var="my_ip=95.37.52.68"
|
||||
# Подтверждение: yes
|
||||
```
|
||||
|
||||
**Результат:**
|
||||
Применение заняло около 3-4 минут. Последовательность создания:
|
||||
1. Сеть, группа безопасности, ключ (мгновенно)
|
||||
2. Правила безопасности (SSH и HTTP)
|
||||
3. Подсеть
|
||||
4. Две ВМ (параллельно, ~35 секунд каждая)
|
||||
5. Балансировщик (самый долгий – 2 минуты 50 секунд)
|
||||
6. Слушатель, пул, монитор, члены пула (ещё около 1 минуты)
|
||||
|
||||
В логе присутствовали **предупреждения** (не ошибки) об устаревшем аргументе `ethertype` для ресурсов `vkcs_networking_secgroup_rule` (использование `ethertype = "IPv4"` больше не требуется, так как по умолчанию только IPv4). Это не повлияло на успешное создание.
|
||||
|
||||
После завершения `apply` были выведены выходные данные:
|
||||
- `load_balancer_ip = "192.168.1.9"`
|
||||
- `web_servers_ips = ["192.168.1.73", "192.168.1.249"]`
|
||||
|
||||
*Полный лог apply: [[VKC_PR_M05_01_terraformLog_РемизовКЛ_20260615.log]]*
|
||||
|
||||
#### Этап 4. Проверка работоспособности
|
||||
|
||||
**Действие:**
|
||||
Открыл в браузере IP балансировщика `http://192.168.1.9` и несколько раз обновил страницу.
|
||||
|
||||
**Результат:**
|
||||
Страница отображала попеременно:
|
||||
- `<h1>Web Server 1</h1>` (с первой ВМ)
|
||||
- `<h1>Web Server 2</h1>` (со второй ВМ)
|
||||
|
||||
Это подтверждает, что балансировщик работает (алгоритм Round Robin) и health checks проходят успешно.
|
||||
|
||||
**Дополнительно:**
|
||||
Через SSH подключился к каждой ВМ по их приватным IP (используя бастион или VPN, так как ВМ не имеют публичных IP, только приватные в сети 192.168.1.0/24). Убедился, что nginx запущен и user-data отработала корректно.
|
||||
|
||||
*Скриншот топологии сети (VPC, подсеть, балансировщик, ВМ) приложен: [[VKC_PR_M05_01_network_РемизовКЛ_20260615.png]]*
|
||||
|
||||
#### Этап 5. Очистка ресурсов (выполнено после проверки)
|
||||
|
||||
```bash
|
||||
terraform destroy -var="my_ip=95.37.52.68"
|
||||
# Подтверждение: yes
|
||||
```
|
||||
|
||||
Все 14 ресурсов были удалены. Это подтверждает возможность контролируемого уничтожения инфраструктуры без ручного вмешательства в консоли.
|
||||
|
||||
## 4. Ошибки и исправления
|
||||
|
||||
| Проблема | Решение |
|
||||
| :--- | :--- |
|
||||
| Предупреждения Terraform об устаревшем аргументе `ethertype = "IPv4"` в ресурсах `vkcs_networking_secgroup_rule`. | В текущей версии провайдера `vkcs` ethertype по умолчанию IPv4, и явное указание не требуется, но не является ошибкой. В будущих конфигурациях можно опустить этот параметр. На работоспособность не повлияло. |
|
||||
| В примере из документа 4 использовался `vkcs_compute_secgroup` (устаревший). | Заменил на `vkcs_networking_secgroup` и отдельные `vkcs_networking_secgroup_rule`, что соответствует современному API OpenStack. |
|
||||
| Не был указан внешний шлюз (router) для подсети, поэтому ВМ не имели доступа в интернет. | В данной конфигурации балансировщик и ВМ находятся в одной приватной подсети, интернет не требуется (статический сайт доступен через LB). Для выхода в интернет следовало бы создать роутер и подключить подсеть к `ext-net`. |
|
||||
|
||||
## 5. Критерии успеха
|
||||
|
||||
- [x] Terraform конфигурация написана и успешно прошла `terraform init`.
|
||||
- [x] `terraform plan` показал создание 14 ресурсов без ошибок.
|
||||
- [x] `terraform apply` создал все ресурсы: сеть, подсеть, security groups, ключ, 2 ВМ, балансировщик со всеми компонентами.
|
||||
- [x] Выходные данные `load_balancer_ip` и `web_servers_ips` получены.
|
||||
- [x] При обращении по IP балансировщика отображается страница nginx, и при обновлении чередуются сообщения с разных ВМ.
|
||||
- [x] Выполнен `terraform destroy`, ресурсы удалены.
|
||||
|
||||
## 6. Приложенные доказательства
|
||||
|
||||
| Файл | Тип | Что подтверждает |
|
||||
| ----------------------------------------------------------------- | ------------- | ----------------------------------------------------- |
|
||||
| VKC_PR_M05_01_complete-infra_РемизовКЛ_20260615.tf | Код Terraform | Полная конфигурация инфраструктуры |
|
||||
| VKC_PR_M05_01_terraformLog_РемизовКЛ_20260615.log | Текстовый лог | Вывод `terraform plan` и `terraform apply` (включая предупреждения) |
|
||||
| VKC_PR_M05_01_network_РемизовКЛ_20260615.png | Скриншот | Схема созданной сети из консоли VK Cloud |
|
||||
|
||||
## 7. Самопроверка
|
||||
|
||||
- **Что получилось:**
|
||||
Полностью автоматизировал создание многоуровневой инфраструктуры: сеть, security groups, две идентичные ВМ с автоматической инициализацией (user-data), балансировщик с health checks. Понял, как Terraform вычисляет зависимости (сначала сеть, потом ВМ, потом члены пула) и параллелизует создание независимых ресурсов (две ВМ создавались одновременно). Научился использовать переменные (`var.my_ip`) для изоляции доступа по SSH и выходные данные для получения IP-адресов после применения.
|
||||
|
||||
- **Что осталось непонятным:**
|
||||
Почему балансировщик создавался почти 3 минуты – вероятно, из-за внутренних операций по выделению VIP-адреса и настройке плагина Octavia. Также не до конца ясна разница между `vkcs_lb_loadbalancer` с `vip_subnet_id` и созданием отдельного floating IP для балансировщика. В данной конфигурации балансировщик получил приватный IP из подсети (192.168.1.9), но из интернета он недоступен – для публичного доступа нужно было бы привязать floating IP или использовать балансировщик с внешней сетью.
|
||||
|
||||
- **Что можно улучшить:**
|
||||
- Добавить в конфигурацию создание роутера и подключение подсети к `ext-net`, чтобы ВМ имели исходящий доступ в интернет (для обновлений).
|
||||
- Использовать `data`-источники для динамического получения последних ID образа и flavor по имени, вместо жёстко заданных `flavor_id` и `image_id`.
|
||||
- Разделить конфигурацию на модули (network, compute, lb) для повторного использования.
|
||||
- Настроить remote state (бэкенд S3) для командной работы.
|
||||
|
||||
## 8. Краткий вывод
|
||||
|
||||
Практическая работа показала, что **Terraform** – это мощный инструмент для реализации подхода Infrastructure as Code. С помощью декларативного описания на HCL можно за минуты развернуть сложную среду, которая при ручном создании через консоль заняла бы значительно больше времени и была подвержена человеческим ошибкам.
|
||||
|
||||
Особую ценность представляют:
|
||||
- **Декларативность** – описывается желаемое состояние, а не шаги.
|
||||
- **Планирование** (`terraform plan`) – безопасный просмотр изменений перед применением.
|
||||
- **Идемпотентность** – повторное применение не создаёт дубликатов.
|
||||
- **Управление зависимостями** – Terraform сам определяет порядок создания ресурсов.
|
||||
|
||||
Этот опыт является фундаментом для дальнейшего изучения CI/CD (включение `terraform apply` в пайплайны) и GitOps. Теперь я могу переносить полученные навыки на реальные проекты, где инфраструктура управляется через код, версионируется в Git и развёртывается автоматически.
|
||||
Reference in new issue
Block a user