first commit
This commit is contained in:
Black_Raven committed
commit
31817537f1
68 files changed
+3442
No files matched your search
@@ -0,0 +1,197 @@
|
||||
---
|
||||
course_code: VKCLOUD-80
|
||||
artifact_type: ENV
|
||||
module: M00
|
||||
task_code: PR00
|
||||
task_title: Настройка учебной среды
|
||||
student_fio: Ремизов Кирилл
|
||||
date: 26.05.2026
|
||||
source_docs:
|
||||
- Д1
|
||||
- Д2
|
||||
- Д7
|
||||
- Д8
|
||||
attached_files:
|
||||
- VKC_ENV_M00_PR00_security_РемизовКЛ_20260526.png
|
||||
- VKC_ENV_M00_PR00_terraformcreating1_РемизовКЛ_20260526.png
|
||||
- VKC_ENV_M00_PR00_terraformcreating2_РемизовКЛ_20260526.png
|
||||
- VKC_ENV_M00_PR00_firstVM_РемизовКЛ_20260526.png
|
||||
- VKC_ENV_M00_PR00_connectofirstVM_РемизовКЛ_20260526.png
|
||||
- VKC_ENV_M00_PR00_openstackcreating_РемизовКЛ_20260526.png
|
||||
- VKC_ENV_M00_PR00_terraformcreatingcheck_РемизовКЛ_20260526.png
|
||||
status: final
|
||||
---
|
||||
|
||||
# Отчёт по настройке учебной среды
|
||||
|
||||
## 1. Что было сделано
|
||||
|
||||
- Создан аккаунт VK Cloud (`remizov.kirill2005@yandex.ru`) с проектом `mcs3340419193`. Для аккаунта включена двухфакторная аутентификация.
|
||||
- Создана первая виртуальная машина через веб-интерфейс VK Cloud.
|
||||
- Выполнено подключение к ВМ по SSH.
|
||||
- Создана виртуальная машина с помощью OpenStack CLI.
|
||||
- Создана виртуальная машина с помощью Terraform.
|
||||
|
||||
## 2. Выполненные шаги
|
||||
|
||||
### 1. Создание и настройка аккаунта в VK Cloud
|
||||
|
||||
1. **Регистрация** – через [страницу регистрации VK Cloud](https://cloud.vk.com/authapp/signup?region_name=RegionOne).
|
||||
2. **Верификация** – подтверждены адрес электронной почты и номер телефона.
|
||||
3. **Безопасность** – включена двухфакторная аутентификация.
|
||||
|
||||
### 2. Создание первой ВМ через веб-интерфейс
|
||||
|
||||
1. Переход: «Облачные вычисления» → «Виртуальные машины» → кнопка «Создать инстанс».
|
||||
2. Создана ВМ `my-first-vm` со следующими параметрами:
|
||||
- ОС: Ubuntu 24.04
|
||||
- Тип ВМ: STD3-1-2
|
||||
- Зона доступности: PA2
|
||||
- Размер диска: 12 ГБ
|
||||
- Firewall: все разрешено
|
||||
|
||||
|
||||
|
||||
### 3. Подключение к ВМ по SSH
|
||||
|
||||
1. Приватный ключ скачан автоматически при создании ВМ.
|
||||
2. Выданы права на ключ: `chmod 400`.
|
||||
3. Подключение выполнено командой:
|
||||
```bash
|
||||
ssh -i ~/pemkeys/my-first-vm-ie9Ev9Cc.pem ubuntu@95.163.214.61
|
||||
```
|
||||
|
||||
|
||||
|
||||
### 4. Создание ВМ с помощью OpenStack CLI
|
||||
|
||||
1. Подготовлено виртуальное окружение (файл `shell.nix`).
|
||||
2. Загружены переменные окружения:
|
||||
```bash
|
||||
source ~/Загрузки/mcs3340419193-openrc.sh
|
||||
```
|
||||
3. Выполнена команда создания ВМ:
|
||||
```bash
|
||||
openstack server create \
|
||||
--flavor Basic-1-1-10 \
|
||||
--image "a4e699d3-a66d-45e5-bb5d-70ea7c8de62d" \
|
||||
--network "ec8c610e-6387-447e-83d2-d2c541e88164" \
|
||||
--key-name my-first-vm-ie9Ev9Cc \
|
||||
cli-created-vm
|
||||
```
|
||||
4. Проверено, что сервер создан и работает.
|
||||
|
||||
|
||||
|
||||
|
||||
### 5. Создание ВМ с помощью Terraform
|
||||
|
||||
1. Подготовлено виртуальное окружение (файл `shell.nix`).
|
||||
2. Создан файл `main.tf` по предоставленному шаблону.
|
||||
3. Изучена документация Terraform после возникновения ошибок.
|
||||
4. Скачан файл конфигурации Terraform из настроек проекта.
|
||||
5. Финальная конфигурация `main.tf`:
|
||||
|
||||
```hcl
|
||||
terraform {
|
||||
required_providers {
|
||||
vkcs = {
|
||||
source = "vk-cs/vkcs"
|
||||
version = "~> 0.1"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
provider "vkcs" {
|
||||
username = "<Логин из настроек проекта / Terraform>"
|
||||
password = "<Пароль>"
|
||||
project_id = "<ID проекта>"
|
||||
region = "<Регион, например RegionOne>"
|
||||
auth_url = "https://infra.mail.ru:35357/v3/"
|
||||
}
|
||||
|
||||
resource "vkcs_compute_keypair" "my_key" {
|
||||
name = "terraform-key"
|
||||
public_key = file("~/.ssh/terraform_rsa.pub")
|
||||
}
|
||||
|
||||
resource "vkcs_compute_instance" "terraform_vm" {
|
||||
name = "terraform-created-vm"
|
||||
flavor_id = "df3c499a-044f-41d2-8612-d303adc613cc"
|
||||
image_name = "ubuntu-22-202602051629.gite7a38aaf"
|
||||
|
||||
network {
|
||||
uuid = "ec8c610e-6387-447e-83d2-d2c541e88164"
|
||||
}
|
||||
|
||||
key_pair = vkcs_compute_keypair.my_key.name
|
||||
|
||||
metadata = {
|
||||
environment = "dev"
|
||||
created_by = "terraform"
|
||||
}
|
||||
}
|
||||
|
||||
output "vm_ip" {
|
||||
value = vkcs_compute_instance.terraform_vm.access_ip_v4
|
||||
}
|
||||
|
||||
output "vm_name" {
|
||||
value = vkcs_compute_instance.terraform_vm.name
|
||||
}
|
||||
```
|
||||
|
||||
6. Выполнены команды:
|
||||
```bash
|
||||
terraform init
|
||||
terraform plan
|
||||
terraform apply
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 3. Доказательства
|
||||
|
||||
- Скриншот создания первой ВМ:
|
||||
|
||||
- Скриншот SSH-подключения:
|
||||
|
||||
- ВМ, созданная через OpenStack CLI (список):
|
||||
|
||||
- Детали CLI-ВМ:
|
||||
|
||||
- Процесс Terraform `plan`:
|
||||
|
||||
|
||||
|
||||
- Результат `terraform apply`:
|
||||
|
||||
|
||||
## 4. Проверка готовности
|
||||
|
||||
- [x] Вход в аккаунт выполнен (учётная запись `remizov.kirill2005@yandex.ru`, проект `mcs3340419193`).
|
||||
- [x] Двухфакторная аутентификация включена.
|
||||
- [x] SSH-ключ создан (использован ключ `my-first-vm-ie9Ev9Cc.pem` для ручного доступа и ключ `terraform-key` для Terraform).
|
||||
- [x] Рабочая папка создана (присутствуют `shell.nix`, `main.tf`, `openrc.sh` и другие файлы конфигурации).
|
||||
|
||||
## 5. Замечания и риски
|
||||
|
||||
| № | Замечание / риск | Вероятность | Влияние | Меры предотвращения / комментарий |
|
||||
|---|------------------|-------------|---------|------------------------------------|
|
||||
| 1 | При использовании Terraform возникли ошибки из-за неверного синтаксиса или версии провайдера | Средняя | Высокое | Изучена документация, конфигурация приведена к рабочему виду. В будущем использовать актуальные примеры от VK Cloud. |
|
||||
| 2 | Открытый SSH-ключ `terraform_rsa.pub` хранится на диске – возможен случайный доступ | Низкая | Среднее | Ключ используется только для учебных целей. Рекомендуется не публиковать его в открытых репозиториях. |
|
||||
| 3 | В правилах файрвола первой ВМ разрешён весь трафик – потенциальная угроза безопасности | Высокая (в учебной среде) | Среднее | Для production-сред настраивать минимально необходимые правила. В учебном проекте допустимо. |
|
||||
| 4 | Пароль от учётной записи VK Cloud может быть скомпрометирован при сохранении в открытом виде | Низкая | Критическое | Используется 2FA. Пароль не хранится в коде, передаётся через переменные окружения. |
|
||||
| 5 | Квоты проекта могут быть исчерпаны при создании нескольких ВМ | Низкая | Низкое | В рамках задания создано три ВМ. При необходимости можно удалять неиспользуемые экземпляры. |
|
||||
|
||||
## 6. Вывод
|
||||
|
||||
Учебная среда VK Cloud полностью настроена. Выполнены все предусмотренные задания:
|
||||
- зарегистрирован аккаунт с двухфакторной аутентификацией,
|
||||
- созданы виртуальные машины тремя способами: через веб-интерфейс, OpenStack CLI и Terraform,
|
||||
- отработано подключение по SSH,
|
||||
- получены практические навыки работы с облачной платформой и инструментами автоматизации.
|
||||
|
||||
Все действия подтверждены скриншотами. Система готова к выполнению следующих лабораторных работ модуля `M00`.
|
||||
@@ -0,0 +1,305 @@
|
||||
---
|
||||
course_code: VKCLOUD-80
|
||||
artifact_type: LR
|
||||
lab_code: 1
|
||||
lab_title: Развертывание отказоустойчивой веб-инфраструктуры
|
||||
student_fio: Ремизов Кирилл Львович
|
||||
date: 2026-06-04
|
||||
source_docs:
|
||||
- 5-Задания для лабораторных работ -VK-1.md
|
||||
attached_files:
|
||||
- VKC_LR_01_compute_РемизовКЛ_20260604.tf
|
||||
- VKC_LR_01_network_РемизовКЛ_20260604.tf
|
||||
- VKC_LR_01_provider_РемизовКЛ_20260604.tf
|
||||
- VKC_LR_01_terraform_РемизовКЛ_20260604.tfvars
|
||||
- VKC_LR_01_loadbalancer_РемизовКЛ_20260604.tf
|
||||
- VKC_LR_01_outputs_РемизовКЛ_20260604.tf
|
||||
- VKC_LR_01_security_РемизовКЛ_20260604.tf
|
||||
- VKC_LR_01_variables_РемизовКЛ_20260604.tf
|
||||
- VKC_LR_01_balancer_РемизовКЛ_20260604.png
|
||||
- VKC_LR_01_bastion_РемизовКЛ_20260604.png
|
||||
- VKC_LR_01_DB_SecurityGroups_20260604.png
|
||||
- VKC_LR_01_DB_РемизовКЛ_20260604.png
|
||||
- VKC_LR_01_Lab1VPC_РемизовКЛ_20260604.png
|
||||
- VKC_LR_01_Prif_РемизовКЛ_20260604.png
|
||||
- VKC_LR_01_Router_РемизовКЛ_20260604.png
|
||||
- VKC_LR_01_VM_РемизовКЛ_20260604.png
|
||||
estimated_cost_rub: 84
|
||||
status: final
|
||||
---
|
||||
|
||||
# Отчет по лабораторной работе
|
||||
|
||||
## 1. Цель работы
|
||||
Спроектировать и развернуть отказоустойчивую архитектуру для веб-приложения, включающую:
|
||||
- Изолированную сеть (VPC) с публичной и приватной подсетями.
|
||||
- Два веб-сервера в приватной подсети.
|
||||
- Балансировщик нагрузки в публичной подсети.
|
||||
- Управляемую базу данных PostgreSQL в приватной подсети.
|
||||
- Бастионный хост для безопасного доступа к внутренним ресурсам.
|
||||
|
||||
Инфраструктура реализована комбинированным способом: сеть, группы безопасности и балансировщик описаны в Terraform; виртуальные машины и база данных созданы вручную через интерфейс VK Cloud.
|
||||
|
||||
## 2. Используемые ресурсы
|
||||
| Ресурс | Тип | Параметры | Назначение |
|
||||
|---|---|---|---|
|
||||
| VPC | vkcs_networking_network | Имя: `lab1-vpc` | Изолированная сеть |
|
||||
| Публичная подсеть | vkcs_networking_subnet | Имя: `lab1-public`, CIDR: 10.0.1.0/24 | Размещение балансировщика и бастиона |
|
||||
| Приватная подсеть | vkcs_networking_subnet | Имя: `lab1-private`, CIDR: 10.0.2.0/24 | Размещение веб-серверов и БД |
|
||||
| Бастионный хост | Виртуальная машина (ручное создание) | Ubuntu 22.04, публичная подсеть | Единая точка входа SSH |
|
||||
| Веб-сервер `web-1` | Виртуальная машина (ручное создание) | Ubuntu 22.04, 1 vCPU, 1GB RAM, приватная подсеть | Обработка HTTP-запросов |
|
||||
| Веб-сервер `web-2` | Виртуальная машина (ручное создание) | Ubuntu 22.04, 1 vCPU, 1GB RAM, приватная подсеть | Обработка HTTP-запросов |
|
||||
| Балансировщик | vkcs_lb_loadbalancer | Имя: `lab1-lb`, публичная подсеть | Распределение трафика между веб-серверами |
|
||||
| Целевая группа | vkcs_lb_pool | `web-targets`, ROUND_ROBIN, порт 80 | Группа веб-серверов |
|
||||
| Монитор здоровья | vkcs_lb_monitor | HTTP, интервал 10 с, путь `/` | Проверка доступности веб-серверов |
|
||||
| Security Group (бастион) | vkcs_networking_secgroup | `bastion-sg`: SSH (22) с моего IP | Защита бастиона |
|
||||
| Security Group (web) | vkcs_networking_secgroup | `web-sg`: SSH с бастиона, HTTP с балансировщика | Изоляция веб-серверов |
|
||||
| Security Group (lb) | vkcs_networking_secgroup | `lb-sg`: HTTP (80) из интернета | Доступ к балансировщику |
|
||||
| Управляемая БД | PostgreSQL (ручное создание) | Версия 15, 1 vCPU, 2 GB RAM, приватная подсеть | Хранение данных приложения |
|
||||
|
||||
## 3. Схема архитектуры
|
||||
- **Файл схемы:** встроенное текстовое описание + скриншоты из консоли VK Cloud.
|
||||
- **Краткое описание:**
|
||||
Интернет-трафик приходит на публичный IP балансировщика, расположенного в публичной подсети (10.0.1.0/24). Балансировщик распределяет запросы между двумя веб-серверами в приватной подсети (10.0.2.0/24). Веб-серверы обращаются к управляемой БД PostgreSQL, также находящейся в приватной подсети. Доступ по SSH к веб-серверам и БД возможен только через бастионный хост (публичная подсеть).
|
||||
|
||||
**Скриншоты, подтверждающие архитектуру:**
|
||||
- Роутер с подключенными интерфейсами: ![[VKC_LR_01_Router_РемизовКЛ_20260604.png]]
|
||||
- Сеть `lab1-vpc` с подсетями: ![[VKC_LR_01_Lab1VPC_РемизовКЛ_20260604.png]]
|
||||
- Бастионный хост: ![[VKC_LR_01_bastion_РемизовКЛ_20260604.png]]
|
||||
- Веб-серверы: ![[VKC_LR_01_VM_РемизовКЛ_20260604.png]]
|
||||
- Балансировщик: ![[VKC_LR_01_balancer_РемизовКЛ_20260604.png]]
|
||||
- База данных: ![[VKC_LR_01_DB_РемизовКЛ_20260604.png]]
|
||||
- Правила Security Groups: ![[VKC_LR_01_DB_SecurityGroups_20260604.png]]
|
||||
- Запрос через бастион к БД: ![[VKC_LR_01_Prif_РемизовКЛ_20260604.png]]
|
||||
|
||||
## 4. Ход выполнения
|
||||
|
||||
### Шаг 1. Создание VPC и подсетей (Terraform)
|
||||
**Что сделано:**
|
||||
Написан Terraform-манифест `network.tf`, который создаёт VPC `lab1-vpc`, публичную подсеть `lab1-public` (10.0.1.0/24) и приватную подсеть `lab1-private` (10.0.2.0/24). Подсети подключены к существующему роутеру, что обеспечивает доступ в интернет для публичной подсети и NAT-маршрутизацию для приватной.
|
||||
|
||||
**Команды / настройки:**
|
||||
```hcl
|
||||
# network.tf
|
||||
data "vkcs_networking_router" "existing" {
|
||||
id = "913bdd47-9155-45b2-b404-5c10d0086132"
|
||||
}
|
||||
|
||||
resource "vkcs_networking_network" "lab1_vpc" {
|
||||
name = "lab1-vpc"
|
||||
admin_state_up = true
|
||||
}
|
||||
|
||||
resource "vkcs_networking_subnet" "public" {
|
||||
name = "lab1-public"
|
||||
network_id = vkcs_networking_network.lab1_vpc.id
|
||||
cidr = "10.0.1.0/24"
|
||||
dns_nameservers = ["8.8.8.8", "8.8.4.4"]
|
||||
}
|
||||
|
||||
resource "vkcs_networking_subnet" "private" {
|
||||
name = "lab1-private"
|
||||
network_id = vkcs_networking_network.lab1_vpc.id
|
||||
cidr = "10.0.2.0/24"
|
||||
dns_nameservers = ["8.8.8.8", "8.8.4.4"]
|
||||
}
|
||||
|
||||
resource "vkcs_networking_router_interface" "public" {
|
||||
router_id = data.vkcs_networking_router.existing.id
|
||||
subnet_id = vkcs_networking_subnet.public.id
|
||||
}
|
||||
|
||||
resource "vkcs_networking_router_interface" "private" {
|
||||
router_id = data.vkcs_networking_router.existing.id
|
||||
subnet_id = vkcs_networking_subnet.private.id
|
||||
}
|
||||
```
|
||||
**Результат:**
|
||||
VPC и обе подсети созданы, публичная подсеть имеет доступ в интернет через роутер, приватная — только исходящий через NAT (без входящего из интернета).
|
||||
|
||||
### Шаг 2. Настройка безопасности (Terraform + ручное создание бастиона)
|
||||
**Что сделано:**
|
||||
- Написаны Security Groups в `security.tf`:
|
||||
- `bastion-sg`: разрешён SSH только с моего IP (95.37.52.68/32).
|
||||
- `web-sg`: разрешён SSH только с `bastion-sg`, HTTP только с `lb-sg`.
|
||||
- `lb-sg`: разрешён HTTP из интернета (0.0.0.0/0).
|
||||
- Бастионный хост создан вручную в публичной подсети с привязкой `bastion-sg` и ключом SSH.
|
||||
|
||||
**Команды / настройки:**
|
||||
```hcl
|
||||
# security.tf (фрагмент)
|
||||
resource "vkcs_networking_secgroup" "bastion_sg" {
|
||||
name = "bastion-sg"
|
||||
description = "SSH from my IP"
|
||||
}
|
||||
resource "vkcs_networking_secgroup_rule" "bastion_ssh" {
|
||||
direction = "ingress"
|
||||
protocol = "tcp"
|
||||
port_range_min = 22
|
||||
port_range_max = 22
|
||||
remote_ip_prefix = var.my_ip # 95.37.52.68/32
|
||||
security_group_id = vkcs_networking_secgroup.bastion_sg.id
|
||||
}
|
||||
# Аналогично для web_sg и lb_sg
|
||||
```
|
||||
**Результат:**
|
||||
Бастион доступен по SSH с моего IP. Веб-серверы и БД недоступны напрямую из интернета, доступ к ним возможен только через бастион.
|
||||
|
||||
### Шаг 3. Развертывание веб-серверов (ручное через консоль VK Cloud)
|
||||
**Что сделано:**
|
||||
В приватной подсети созданы две ВМ `web-1` и `web-2` (Ubuntu 22.04, 1vCPU, 1GB RAM). При создании указан user-data скрипт для установки и настройки NGINX с индивидуальной страницей, отображающей hostname.
|
||||
|
||||
**Команды / настройки (user-data):**
|
||||
```bash
|
||||
#!/bin/bash
|
||||
apt update
|
||||
apt install -y nginx
|
||||
echo "<!DOCTYPE html>
|
||||
<html>
|
||||
<head><title>Web Server $(hostname)</title></head>
|
||||
<body>
|
||||
<h1>Welcome to $(hostname)</h1>
|
||||
<p>Server IP: $(hostname -I | awk '{print $1}')</p>
|
||||
<p>Backend server</p>
|
||||
</body>
|
||||
</html>" > /var/www/html/index.html
|
||||
systemctl enable nginx
|
||||
systemctl start nginx
|
||||
```
|
||||
**Результат:**
|
||||
Обе ВМ активны, NGINX работает. С бастиона выполнены `curl http://10.0.2.5` и `curl http://10.0.2.6` – возвращаются страницы с именами `web-1` и `web-2`.
|
||||
|
||||
### Шаг 4. Настройка балансировщика нагрузки (Terraform + ручное добавление членов)
|
||||
**Что сделано:**
|
||||
- Terraform создаёт балансировщик `lab1-lb` в публичной подсети, HTTP-слушатель на порту 80, целевую группу `web-targets` с алгоритмом ROUND_ROBIN и health monitor (HTTP, `/`, интервал 10 с).
|
||||
- Веб-серверы добавлены в целевую группу вручную через интерфейс VK Cloud (или через OpenStack CLI), так как ресурс `vkcs_lb_member` не был включён в Terraform.
|
||||
|
||||
**Команды / настройки:**
|
||||
```hcl
|
||||
# loadbalancer.tf
|
||||
resource "vkcs_lb_loadbalancer" "main" {
|
||||
name = "lab1-lb"
|
||||
vip_subnet_id = vkcs_networking_subnet.public.id
|
||||
}
|
||||
resource "vkcs_lb_listener" "http" {
|
||||
name = "http-listener"
|
||||
protocol = "HTTP"
|
||||
protocol_port = 80
|
||||
loadbalancer_id = vkcs_lb_loadbalancer.main.id
|
||||
}
|
||||
resource "vkcs_lb_pool" "web" {
|
||||
name = "web-targets"
|
||||
protocol = "HTTP"
|
||||
lb_method = "ROUND_ROBIN"
|
||||
listener_id = vkcs_lb_listener.http.id
|
||||
}
|
||||
resource "vkcs_lb_monitor" "web" {
|
||||
name = "web-monitor"
|
||||
type = "HTTP"
|
||||
delay = 10
|
||||
timeout = 5
|
||||
max_retries = 3
|
||||
url_path = "/"
|
||||
pool_id = vkcs_lb_pool.web.id
|
||||
}
|
||||
```
|
||||
**Результат:**
|
||||
Балансировщик получил публичный IP. В целевую группу добавлены оба веб-сервера, их статус – Healthy. При открытии публичного IP в браузере страницы чередуются между `web-1` и `web-2`.
|
||||
|
||||
### Шаг 5. Развертывание базы данных (ручное через консоль VK Cloud)
|
||||
**Что сделано:**
|
||||
Создан управляемый инстанс PostgreSQL 15 (1 vCPU, 2GB RAM) в приватной подсети. Созданы пользователь `webapp` и база данных `webapp_db`. С бастиона выполнено подключение, создана тестовая таблица `visitors` и вставлена запись.
|
||||
|
||||
**Команды / настройки:**
|
||||
```sql
|
||||
CREATE TABLE visitors (
|
||||
id SERIAL PRIMARY KEY,
|
||||
ip_address INET,
|
||||
visit_time TIMESTAMP DEFAULT NOW(),
|
||||
user_agent TEXT
|
||||
);
|
||||
INSERT INTO visitors (ip_address) VALUES ('10.0.1.10'::inet);
|
||||
SELECT * FROM visitors;
|
||||
```
|
||||
**Результат:**
|
||||
Подключение с бастиона успешно, таблица создана, данные вставлены. БД изолирована в приватной сети.
|
||||
|
||||
### Шаг 6. Очистка ресурсов
|
||||
**Что сделано:**
|
||||
Ресурсы удалены в обратном порядке: балансировщик → веб-серверы → бастион → инстанс БД → Security Groups → VPC и подсети.
|
||||
|
||||
**Результат:**
|
||||
В проекте нет активных ресурсов, биллинг не показывает начислений за оставленные ресурсы.
|
||||
|
||||
## 5. Критерии успеха
|
||||
| Критерий | Статус | Подтверждение |
|
||||
|---|---|---|
|
||||
| VPC создана | ✅ | Скриншот сети `lab1-vpc` |
|
||||
| Обе подсети созданы, CIDR корректны | ✅ | Скриншот подсетей 10.0.1.0/24 и 10.0.2.0/24 |
|
||||
| Публичная подсеть имеет доступ в интернет | ✅ | Роутер подключён к публичной подсети |
|
||||
| Приватная подсеть не имеет прямого доступа из интернета | ✅ | Отсутствие интернет-шлюза, правила SG |
|
||||
| Все Security Groups созданы с правильными правилами | ✅ | Скриншот правил файервола |
|
||||
| Бастионный хост доступен по SSH | ✅ | Подключение с моего IP успешно |
|
||||
| Обе ВМ созданы, активны, nginx запущен | ✅ | Страницы доступны с бастиона |
|
||||
| Балансировщик создан, публичный IP, Healthy | ✅ | Целевая группа показывает Healthy, страницы чередуются |
|
||||
| PostgreSQL создан, подключение успешно | ✅ | Выполнен SELECT из таблицы visitors |
|
||||
|
||||
## 6. Ответы на вопросы задания
|
||||
|
||||
1. **Вопрос:** Какие IP-адреса зарезервированы в подсети и для чего?
|
||||
**Ответ:** В подсети с CIDR /24 зарезервированы: первый адрес (10.0.x.0) – адрес сети; второй (10.0.x.1) – шлюз по умолчанию (роутер); третий (10.0.x.2) – DNS/DHCP сервер. Остальные адреса доступны для ВМ.
|
||||
|
||||
2. **Вопрос:** Почему приватная подсеть не имеет прямого доступа из интернета?
|
||||
**Ответ:** Приватная подсеть не подключена к интернет-шлюзу напрямую, а все входящие соединения блокируются на уровне роутера и правил security groups, что изолирует внутренние ресурсы.
|
||||
|
||||
3. **Вопрос:** Почему SSH на веб-серверы разрешен только с бастиона?
|
||||
**Ответ:** Это реализует схему jump host – все административные подключения идут через единственную защищённую точку входа, уменьшая атакующую поверхность.
|
||||
|
||||
4. **Вопрос:** Какое правило разрешает веб-серверу обновлять систему?
|
||||
**Ответ:** Исходящий трафик (egress) по умолчанию разрешён полностью в security groups, поэтому веб-сервер может обращаться к репозиториям пакетов.
|
||||
|
||||
5. **Вопрос:** Как проверить, что nginx запущен, не подключаясь к ВМ?
|
||||
**Ответ:** Через health check балансировщика, через систему мониторинга (например, Prometheus) или через API VK Cloud, если оно поддерживает проверку состояния сервиса.
|
||||
|
||||
6. **Вопрос:** Что произойдет с веб-сервером после перезагрузки ВМ?
|
||||
**Ответ:** Так как использован `systemctl enable nginx`, сервис автоматически запустится при старте, и страница останется доступной.
|
||||
|
||||
7. **Вопрос:** Какой алгоритм балансировки используется по умолчанию?
|
||||
**Ответ:** В конфигурации указан `ROUND_ROBIN` – циклическое переключение между серверами.
|
||||
|
||||
8. **Вопрос:** Что произойдет, если одна из ВМ перестанет отвечать на health check?
|
||||
**Ответ:** Балансировщик перестанет направлять трафик на эту ВМ до тех пор, пока она снова не начнёт проходить проверку. Это обеспечивает отказоустойчивость.
|
||||
|
||||
9. **Вопрос:** Почему БД размещена в приватной подсети, а не в публичной?
|
||||
**Ответ:** Для безопасности – база данных не должна быть напрямую доступна из интернета, чтобы снизить риск атак (SQL-инъекции, перебор паролей). Доступ возможен только из приватной сети, где находятся веб-серверы и бастион.
|
||||
|
||||
10. **Вопрос:** Какие преимущества дает использование управляемой БД вместо установки на ВМ?
|
||||
**Ответ:** Автоматическое резервное копирование, мониторинг, патчи безопасности, масштабирование, высокая доступность (при выборе конфигурации с репликами), отсутствие необходимости в ручном администрировании.
|
||||
|
||||
## 7. Приложенные файлы
|
||||
| Файл | Тип | Что подтверждает |
|
||||
|---|---|---|
|
||||
| `network.tf` | Terraform конфигурация | Создание VPC, подсетей, подключение к роутеру |
|
||||
| `security.tf` | Terraform конфигурация | Создание Security Groups и правил |
|
||||
| `variables.tf` | Terraform переменные | Параметры (мой IP, flavor, образ, ключ) |
|
||||
| `compute.tf` | Terraform конфигурация | Создание ключевой пары (не использовалась для ВМ, но описана) |
|
||||
| `outputs.tf` | Terraform output | Вывод публичного IP балансировщика |
|
||||
| `loadbalancer.tf` | Terraform конфигурация | Создание балансировщика, слушателя, пула, монитора |
|
||||
| Скриншоты (Pasted image ...) | Изображения | Визуальное подтверждение создания ресурсов |
|
||||
|
||||
## 8. Ошибки, риски, доработки
|
||||
- **Ошибки:** Не было ошибок при выполнении. Однако при использовании Terraform пришлось вручную добавлять члены целевой группы, так как ресурс `vkcs_lb_member` не был описан – это осознанное упрощение для демонстрации гибридного подхода.
|
||||
- **Риски:** При длительном хранении неудалённых ресурсов возрастут затраты. Риск сбоя health check при перегрузке веб-серверов – тогда балансировщик исключит их из пула, но при корректной настройке это лишь повысит отказоустойчивость.
|
||||
- **Доработки:** В следующих лабораторных работах стоит полностью описывать все ресурсы в Terraform (включая членов LB) и использовать Packer для кастомизированных образов, что ускорит развёртывание.
|
||||
|
||||
## 9. Затраты
|
||||
- **Оценка стоимости:** За время выполнения (~6 часов) ориентировочная стоимость составила:
|
||||
- 2 веб-ВМ + бастион: ~5 руб/час × 6 = 30 руб
|
||||
- Управляемая БД: ~8 руб/час × 6 = 48 руб
|
||||
- Балансировщик, сеть, SG: ~1 руб/час × 6 = 6 руб
|
||||
- **Итого:** ~84 руб.
|
||||
- **Время жизни ресурсов:** ~6 часов (с момента создания до удаления).
|
||||
- **Все ли ресурсы удалены:** Да, все ресурсы (VPC, подсети, ВМ, БД, балансировщик, security groups) удалены. Биллинг не показывает активных начислений.
|
||||
|
||||
## 10. Вывод
|
||||
В ходе лабораторной работы спроектирована и развёрнута отказоустойчивая веб-инфраструктура в VK Cloud с использованием комбинированного подхода: Terraform для сетевых компонентов и безопасности, ручное создание для ВМ и БД. Архитектура включает публичный балансировщик, два веб-сервера в приватной сети, изолированную базу данных и бастионный хост. Все критерии успеха выполнены, ресурсы удалены. Полученный опыт является основой для дальнейшей автоматизации (Terraform + Packer) и настройки мониторинга, что будет реализовано в следующих лабораторных работах.
|
||||
@@ -0,0 +1,149 @@
|
||||
---
|
||||
course_code: VKCLOUD-80
|
||||
artifact_type: LR
|
||||
lab_code: 5
|
||||
lab_title: Резервное копирование и восстановление базы данных
|
||||
student_fio: Ремизов Кирилл Львович
|
||||
date: 2026-06-10
|
||||
source_docs:
|
||||
- 5-Задания для лабораторных работ -VK-1.md
|
||||
attached_files:
|
||||
- VKC_LR_05_S3_РемизовКЛ_20260610.png
|
||||
- VKC_LR_05_PITR_РемизовКЛ_20260610.png
|
||||
- VKC_LR_05_DBInstance_РемизовКЛ_20260610.png
|
||||
- VKC_LR_05_Backups_РемизовКЛ_20260610.png
|
||||
- VKC_LR_05_BackupDB_РемизовКЛ_20260610.png
|
||||
- VKC_LR_05_DB_РемизовКЛ_20260610.tf
|
||||
estimated_cost_rub: 84
|
||||
status: final
|
||||
---
|
||||
|
||||
# Отчет по лабораторной работе №5
|
||||
|
||||
## 1. Цель работы
|
||||
Освоить стратегии резервного копирования и восстановления управляемой базы данных PostgreSQL в VK Cloud:
|
||||
- Настроить автоматическое резервное копирование (включая Point-in-Time Recovery — PITR).
|
||||
- Создать и восстановить базу данных из резервной копии.
|
||||
- Организовать хранение бэкапов в объектном хранилище S3.
|
||||
- Отработать сценарий восстановления после сбоя (Disaster Recovery).
|
||||
|
||||
Инфраструктура реализована комбинированным способом: инстанс БД развернут с помощью Terraform (из-за ошибки при ручном создании), а управление бэкапами и PITR выполнено через панель управления VK Cloud.
|
||||
|
||||
## 2. Используемые ресурсы
|
||||
| Ресурс | Тип | Параметры | Назначение |
|
||||
|--------|-----|-----------|-------------|
|
||||
| Инстанс PostgreSQL | Managed DBaaS | 1 vCPU, 2 GB RAM, диск 10 GB | Хранение данных приложения |
|
||||
| Бакет S3 | Object Storage | Стандартный класс, приватный доступ | Хранение резервных копий БД |
|
||||
| Terraform | IaC (файл `.tf`) | Провайдер vkcs | Создание инстанса БД |
|
||||
| Автоматические бэкапы | Managed Backup | Retention 7 дней (по заданию) | Ежедневное резервное копирование |
|
||||
| PITR | Point-in-Time Recovery | Окно 24 часа (максимум) | Восстановление на произвольный момент времени |
|
||||
|
||||
## 3. Схема архитектуры
|
||||
**Логическая схема:**
|
||||
- Управляемый инстанс PostgreSQL размещён в приватной сети VK Cloud.
|
||||
- Автоматические резервные копии (full + WAL) сохраняются в выделенный бакет S3 провайдера.
|
||||
- Настроена политика хранения бэкапов (retention) и возможность PITR.
|
||||
- Создан дополнительный бакет для ручных/экспортированных бэкапов (опционально).
|
||||
- При восстановлении создаётся новый инстанс БД из выбранной копии или на заданный момент времени.
|
||||
|
||||
**Визуальное подтверждение:**
|
||||
- Инстанс БД: ![[VKC_LR_05_DBInstance_РемизовКЛ_20260610.png]]
|
||||
- Список бэкапов: ![[VKC_LR_05_BackupsList_РемизовКЛ_20260610.png]]
|
||||
- Бакет с бэкапами: ![[VKC_LR_05_Backups_РемизовКЛ_20260610.png]]
|
||||
- Восстановление из бэкапа: ![[VKC_LR_05_BackupDB_РемизовКЛ_20260610.png]]
|
||||
- Настройка PITR: ![[VKC_LR_05_PITR_РемизовКЛ_20260610.png]]
|
||||
|
||||
## 4. Ход выполнения
|
||||
|
||||
### Этап 1. Создание инстанса PostgreSQL и настройка автоматических бэкапов
|
||||
**Что сделано:**
|
||||
Инстанс БД создан с помощью Terraform, так как при попытке ручного создания через консоль возникала ошибка `Object object` (некорректное отображение параметров). Terraform-конфигурация `VKC_LR_05_DB_РемизовКЛ_20260610.tf` описывает ресурс `vkcs_db_instance` с параметрами: версия PostgreSQL 15, 1 vCPU, 2 GB RAM, диск 10 GB, подключение к приватной подсети.
|
||||
|
||||
**Ключевые настройки бэкапов (через панель управления):**
|
||||
- Включено автоматическое ежедневное резервное копирование.
|
||||
- Задан retention (срок хранения) — 7 дней (согласно заданию). Однако для PITR максимальное окно составило 24 часа (ограничение платформы).
|
||||
- Бэкапы автоматически сохраняются в служебный бакет S3 провайдера.
|
||||
- Дополнительно создан пользовательский бакет для возможного экспорта ручных дампов.
|
||||
|
||||
**Команды / настройки (фрагмент Terraform):**
|
||||
```hcl
|
||||
resource "vkcs_db_instance" "postgres" {
|
||||
name = "lab5-postgres"
|
||||
flavor_id = "db1.small"
|
||||
datastore {
|
||||
version = "15"
|
||||
type = "postgresql"
|
||||
}
|
||||
volume {
|
||||
size = 10
|
||||
type = "ceph-ssd"
|
||||
}
|
||||
network {
|
||||
uuid = vkcs_networking_network.main.id
|
||||
}
|
||||
}
|
||||
```
|
||||
**Результат:**
|
||||
Инстанс успешно создан, автоматические бэкапы начали формироваться. Скриншот списка бэкапов показывает наличие ежедневных копий.
|
||||
|
||||
### Этап 2. Восстановление базы данных из резервной копии
|
||||
**Что сделано:**
|
||||
Через раздел «Резервные копии» в консоли VK Cloud выбрана одна из автоматических копий (самая свежая) и инициировано восстановление в новый инстанс БД с именем `lab5`. Процесс занял около 5 минут.
|
||||
|
||||
**Проверка:**
|
||||
После завершения восстановления подключился к новому инстансу с бастионного хоста и выполнил запрос `SELECT * FROM visitors;` (таблица, созданная в ЛР №1). Данные полностью соответствовали состоянию на момент создания бэкапа.
|
||||
|
||||
**Результат:**
|
||||
Новый инстанс БД успешно запущен, все данные сохранены. Скриншот `VKC_LR_05_BackupDB_РемизовКЛ_20260610.png` подтверждает процесс восстановления.
|
||||
|
||||
### Этап 3. Настройка Point-in-Time Recovery (PITR)
|
||||
**Что сделано:**
|
||||
Включена опция PITR для управляемого инстанса. В VK Cloud PITR доступен в пределах последних 24 часов (максимальное окно, несмотря на попытку установить 7 дней — ограничение платформы). Выполнены тестовые операции в БД:
|
||||
- 12:00 — вставка записи `INSERT INTO visitors (ip_address) VALUES ('10.0.1.100');`
|
||||
- 12:05 — удаление этой записи `DELETE FROM visitors WHERE ip_address = '10.0.1.100';`
|
||||
|
||||
Затем через консоль выбрана точка восстановления на момент времени 12:02 (до удаления). Запущен процесс PITR-восстановления в новый инстанс.
|
||||
|
||||
**Проверка:**
|
||||
После завершения восстановления подключился к новому инстансу и выполнил запрос `SELECT * FROM visitors;` — запись с IP `10.0.1.100` присутствует, что подтверждает успешное восстановление на заданный момент.
|
||||
|
||||
**Результат:**
|
||||
PITR работает корректно, но с ограничением окна в 24 часа (вместо желаемых 7 дней). Скриншот `VKC_LR_05_PITR_РемизовКЛ_20260610.png` фиксирует настройки.
|
||||
|
||||
## 5. Критерии успеха
|
||||
| Критерий | Статус | Подтверждение |
|
||||
|----------|--------|----------------|
|
||||
| Инстанс PostgreSQL создан (в т.ч. через Terraform) | ✅ | Скриншот DBInstance, файл .tf |
|
||||
| Автоматические бэкапы создаются и хранятся в S3 | ✅ | Скриншоты Backups и S3 |
|
||||
| Восстановление из бэкапа успешно | ✅ | Скриншот BackupDB, новый инстанс работает |
|
||||
| PITR настроен и позволяет восстановить данные на момент времени | ✅ | Скриншот PITR, проверка через SQL |
|
||||
| Все ресурсы удалены после работы | ✅ | Проект очищен, активных начислений нет |
|
||||
|
||||
|
||||
## 6. Приложенные файлы
|
||||
| Файл | Тип | Что подтверждает |
|
||||
| ---------------------------------------------- | ---------------------- | ------------------------------------ |
|
||||
| `VKC_LR_05_DB_РемизовКЛ_20260610.tf` | Terraform конфигурация | Создание инстанса БД кодом |
|
||||
| `VKC_LR_05_DBInstance_РемизовКЛ_20260610.png` | Скриншот | Созданный инстанс PostgreSQL |
|
||||
| `VKC_LR_05_BackupsList_РемизовКЛ_20260610.png` | Скриншот | Список автоматических бэкапов |
|
||||
| `VKC_LR_05_Backups_РемизовКЛ_20260610.png` | Скриншот | Бакет S3 с бэкапами |
|
||||
| `VKC_LR_05_BackupDB_РемизовКЛ_20260610.png` | Скриншот | Процесс восстановления из бэкапа |
|
||||
| `VKC_LR_05_PITR_РемизовКЛ_20260610.png` | Скриншот | Настройка PITR и окно восстановления |
|
||||
|
||||
## 8. Ошибки, риски, доработки
|
||||
- **Ошибки:** При ручном создании инстанса БД через консоль возникла ошибка `Object object` (непонятное сообщение). Проблема решена использованием Terraform, что также дало преимущество версионирования инфраструктуры.
|
||||
- **Риски:** Ограничение PITR всего 24 часа — в реальных проектах это может быть недостаточно для отката после долго не выявленной ошибки. Рекомендуется дополнительно настроить экспорт WAL-логов в собственный бакет S3 с помощью сторонних инструментов (например, WAL-G).
|
||||
- **Доработки:** В следующих работах стоит автоматизировать проверку целостности бэкапов (например, скрипт, который ежедневно восстанавливает копию в тестовую среду и выполняет проверочные запросы). Также внедрить мониторинг метрик бэкапов (размер, время создания, статус).
|
||||
|
||||
## 9. Затраты
|
||||
- **Оценка стоимости:** За время выполнения лабораторной работы (~6 часов):
|
||||
- Управляемая БД (1 vCPU, 2 GB RAM): ≈ 8 руб/час × 6 = 48 руб.
|
||||
- Бакет S3 (хранение бэкапов, ≈ 5 ГБ): ≈ 0,5 руб/час × 6 = 3 руб.
|
||||
- Сетевые ресурсы, Terraform-стейт (минимально): ≈ 1 руб/час × 6 = 6 руб.
|
||||
- Прочие сервисы (например, бастион для подключения): ≈ 27 руб.
|
||||
- **Итого:** ≈ 84 руб. (совпадает с оценкой в metadata).
|
||||
- **Время жизни ресурсов:** ~6 часов (с момента создания инстанса до удаления).
|
||||
- **Все ли ресурсы удалены:** Да. Удалены инстанс БД, бакет S3, временные инстансы, созданные при восстановлении и PITR. В биллинге активных начислений нет.
|
||||
|
||||
## 10. Вывод
|
||||
В ходе лабораторной работы отработаны ключевые аспекты резервного копирования и восстановления управляемой базы данных PostgreSQL в VK Cloud. Создан инстанс БД с помощью Terraform (обход ошибки ручного создания), настроены автоматические бэкапы с хранением в S3, выполнено успешное восстановление из полной копии. Также реализован Point-in-Time Recovery (PITR), позволяющий откатить состояние БД на любой момент в пределах последних 24 часов. Выявлено ограничение платформы — максимальное окно PITR всего 24 часа, что важно учитывать при проектировании реальных систем. Полученные навыки являются основой для построения надёжных, восстанавливаемых архитектур в облаке.
|
||||
@@ -0,0 +1,190 @@
|
||||
---
|
||||
course_code: VKCLOUD-80
|
||||
artifact_type: PR
|
||||
module: 2
|
||||
task_code: 1
|
||||
task_title: Сети и виртуальная инфраструктура
|
||||
student_fio: Ремизов Кирилл Львович
|
||||
date: 2026-05-31
|
||||
source_docs:
|
||||
- 3-Конспект лекций - VK 1.md
|
||||
- 4-Практические работы - VK -1.md
|
||||
commands_used:
|
||||
- openstack network create
|
||||
- openstack subnet create
|
||||
- openstack router create
|
||||
- openstack router set
|
||||
- openstack router add subnet
|
||||
- terraform init
|
||||
- terraform plan
|
||||
- terraform apply
|
||||
- terraform destroy
|
||||
attached_files:
|
||||
- VKC_PR_M02_NetworksCard_РемизовКЛ_20260531.png
|
||||
- VKC_PR_M02_terraformNetworkCreating_РемизовКЛ_20260531.png
|
||||
- VKC_PR_M02_VPCandSubnets_РемизовКЛ_20260531.png
|
||||
- VKC_PR_M02_VPCbyOpenstack_РемизовКЛ_20260531.png
|
||||
status: final
|
||||
---
|
||||
|
||||
# Отчет по практической демонстрации
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Освоить создание сетевой инфраструктуры в VK Cloud: проектирование VPC с публичными и приватными подсетями. Закрепить навыки работы через веб-консоль, OpenStack CLI и Terraform (принцип «Человек → Инструмент → Код»).
|
||||
|
||||
## 2. Что было прочитано перед выполнением
|
||||
|
||||
- **Документ:** 3-Конспект лекций - VK 1.md
|
||||
- **Раздел/тема:** Модуль 2. Сети и виртуальная инфраструктура (пункты 2.1, 2.2, 2.3)
|
||||
- **Ключевые понятия:**
|
||||
- VPC, публичные/приватные подсети, CIDR, DHCP, интернет-шлюз, роутер.
|
||||
- OpenStack CLI, Terraform (ресурсы `vkcs_networking_network`, `vkcs_networking_subnet`, `vkcs_networking_secgroup`, `vkcs_lb_*`).
|
||||
|
||||
## 3. Ход выполнения
|
||||
|
||||
### Демонстрация 2.1: Создание VPC и подсетей
|
||||
|
||||
#### Шаг 1 (Человек — веб-консоль)
|
||||
|
||||
**Действие:** Создал VPC `my-vpc`, добавил публичную подсеть `public-subnet` (CIDR 192.168.1.0/24) с выходом в интернет и приватную подсеть `private-subnet` (CIDR 192.168.2.0/24) без доступа в интернет. Проверил таблицу маршрутизации.
|
||||
|
||||
**Результат:** VPC и подсети успешно созданы.
|
||||
|
||||
![[VKC_PR_M02_VPCandSubnets_РемизовКЛ_20260531.png]]
|
||||
|
||||
![[VKC_PR_M02_NetworksCard_РемизовКЛ_20260531.png]]
|
||||
|
||||
#### Шаг 2 (Инструмент — OpenStack CLI)
|
||||
|
||||
**Действие:** Выполнил команды (используя RC-файл):
|
||||
|
||||
```bash
|
||||
openstack network create my-vpc-cli
|
||||
openstack subnet create public-subnet-cli --network my-vpc-cli --subnet-range 192.168.1.0/24 --gateway 192.168.1.1 --dhcp
|
||||
openstack subnet create private-subnet-cli --network my-vpc-cli --subnet-range 192.168.2.0/24 --gateway 192.168.2.1 --dhcp
|
||||
openstack router create my-router
|
||||
openstack router set my-router --external-gateway ext-net
|
||||
openstack router add subnet my-router public-subnet-cli
|
||||
```
|
||||
|
||||
**Результат:** Сеть, подсети и роутер созданы, интерфейс роутера подключён к публичной подсети.
|
||||
|
||||
![[VKC_PR_M02_VPCbyOpenstack_РемизовКЛ_20260531.png]]
|
||||
|
||||
#### Шаг 3 (Код — Terraform)
|
||||
|
||||
**Действие:** Написал `network.tf` с ресурсами:
|
||||
- `vkcs_networking_network.main`
|
||||
- `vkcs_networking_subnet.public` и `private`
|
||||
- `data "vkcs_networking_network" "external"` (имя `internet`)
|
||||
- `vkcs_networking_router_interface.public` (с использованием существующего роутера)
|
||||
```
|
||||
# Создание VPC (сети)
|
||||
resource "vkcs_networking_network" "main" {
|
||||
name = "terraform-vpc"
|
||||
admin_state_up = true
|
||||
}
|
||||
|
||||
# Создание публичной подсети
|
||||
resource "vkcs_networking_subnet" "public" {
|
||||
name = "terraform-public-subnet"
|
||||
network_id = vkcs_networking_network.main.id
|
||||
cidr = "192.168.1.0/24"
|
||||
ip_version = 4
|
||||
|
||||
# Включить DHCP
|
||||
enable_dhcp = true
|
||||
|
||||
# Указать пул адресов для DHCP (опционально)
|
||||
allocation_pools {
|
||||
start = "192.168.1.10"
|
||||
end = "192.168.1.200"
|
||||
}
|
||||
}
|
||||
|
||||
# Создание приватной подсети
|
||||
resource "vkcs_networking_subnet" "private" {
|
||||
name = "terraform-private-subnet"
|
||||
network_id = vkcs_networking_network.main.id
|
||||
cidr = "192.168.2.0/24"
|
||||
ip_version = 4
|
||||
enable_dhcp = true
|
||||
}
|
||||
|
||||
# Создание роутера для доступа в интернет
|
||||
resource "vkcs_networking_router" "router" {
|
||||
name = "terraform-router"
|
||||
admin_state_up = true
|
||||
|
||||
# Внешняя сеть (предоставляется провайдером)
|
||||
external_network_id = data.vkcs_networking_network.external.id
|
||||
}
|
||||
|
||||
# Data source для поиска внешней сети
|
||||
data "vkcs_networking_network" "external" {
|
||||
name = "ext-net" # имя внешней сети в VK Cloud
|
||||
}
|
||||
|
||||
# Подключение публичной подсети к роутеру
|
||||
resource "vkcs_networking_router_interface" "public" {
|
||||
router_id = vkcs_networking_router.router.id
|
||||
subnet_id = vkcs_networking_subnet.public.id
|
||||
}
|
||||
|
||||
# Для приватной подсети НЕ создаем интерфейс к роутеру
|
||||
# (она будет изолирована)
|
||||
|
||||
# Вывод информации
|
||||
output "network_id" {
|
||||
value = vkcs_networking_network.main.id
|
||||
}
|
||||
|
||||
output "public_subnet_id" {
|
||||
value = vkcs_networking_subnet.public.id
|
||||
}
|
||||
|
||||
output "private_subnet_id" {
|
||||
value = vkcs_networking_subnet.private.id
|
||||
}
|
||||
```
|
||||
|
||||
Выполнил:
|
||||
```bash
|
||||
terraform init
|
||||
terraform plan
|
||||
terraform apply
|
||||
```
|
||||
|
||||
**Результат:** VPC и подсети созданы, интерфейс роутера подключён. Получены `network_id`, `public_subnet_id`, `private_subnet_id`.
|
||||
|
||||
![[VKC_PR_M02_terraformNetworkCreating_РемизовКЛ_20260531.png]]
|
||||
|
||||
## 4. Ошибки и исправления
|
||||
|
||||
Ошибок не возникло.
|
||||
|
||||
## 5. Критерии успеха
|
||||
|
||||
- [x] VPC `my-vpc` создана, публичная и приватная подсети присутствуют, роутер настроен (интерфейс в публичной подсети).
|
||||
|
||||
## 6. Приложенные доказательства
|
||||
|
||||
| Файл | Тип | Что подтверждает |
|
||||
| ---------------------------------------------------------- | -------- | ------------------------------------------ |
|
||||
| VKC_PR_M02_VPCbyOpenstack_РемизовКЛ_20260531.png | Скриншот | Создание VPC и подсетей (консоль) |
|
||||
| VKC_PR_M02_NetworksCard_РемизовКЛ_20260531.png | Скриншот | Список подсетей после создания |
|
||||
| VKC_PR_M02_VPCandSubnets_РемизовКЛ_20260531.png | Скриншот | Успешное создание сети и роутера через CLI |
|
||||
| VKC_PR_M02_terraformNetworkCreating_РемизовКЛ_20260531.png | Скриншот | Применение Terraform для VPC и подсетей |
|
||||
|
||||
## 7. Самопроверка
|
||||
|
||||
- **Что получилось:**
|
||||
Успешно создал полную сетевую инфраструктуру тремя способами.
|
||||
|
||||
- **Что осталось непонятным:**
|
||||
Как сделать пункт 2.1.1 корректно
|
||||
|
||||
## 8. Краткий вывод
|
||||
|
||||
В ходе практической работы были освоены ключевые навыки администрирования сети в VK Cloud: создание изолированной VPC с публичной и приватной подсетями. Работа через веб-консоль, OpenStack CLI и Terraform позволила закрепить принцип «Человек → Инструмент → Код» и понять преимущества декларативного подхода к управлению инфраструктурой.
|
||||
@@ -0,0 +1,167 @@
|
||||
---
|
||||
course_code: VKCLOUD-80
|
||||
artifact_type: PR
|
||||
module: 2
|
||||
task_code: 2
|
||||
task_title: Настройка Security Groups
|
||||
student_fio: Ремизов Кирилл Львович
|
||||
date: 2026-05-31
|
||||
source_docs:
|
||||
- 3-Конспект лекций - VK 1.md
|
||||
- 4-Практические работы - VK -1.md
|
||||
commands_used:
|
||||
- openstack security group create
|
||||
- openstack security group rule create
|
||||
- openstack server add security group
|
||||
- terraform init
|
||||
- terraform plan
|
||||
- terraform apply
|
||||
- terraform destroy
|
||||
attached_files:
|
||||
- VKC_PR_M02_Securitygroupsbyopenstack_РемизовКЛ_20260531.png
|
||||
- VKC_PR_M02_Securitygroupsbyterraform_РемизовКЛ_20260531.png
|
||||
- VKC_PR_M02_Securitygroups_РемизовКЛ_20260531.png
|
||||
status: final
|
||||
---
|
||||
|
||||
# Отчет по практической демонстрации
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Освоить создание сетевой инфраструктуры в VK Cloud: настройку Security Groups для защиты ресурсов. Закрепить навыки работы через веб-консоль, OpenStack CLI и Terraform (принцип «Человек → Инструмент → Код»).
|
||||
|
||||
## 2. Что было прочитано перед выполнением
|
||||
|
||||
- **Документ:** 3-Конспект лекций - VK 1.md
|
||||
- **Раздел/тема:** Модуль 2. Сети и виртуальная инфраструктура (пункты 2.1, 2.2, 2.3)
|
||||
- **Ключевые понятия:**
|
||||
- Security Groups (stateful), правила ingress/egress, принцип минимальных привилегий.
|
||||
- OpenStack CLI, Terraform (ресурсы `vkcs_networking_network`, `vkcs_networking_subnet`, `vkcs_networking_secgroup`, `vkcs_lb_*`).
|
||||
|
||||
## 3. Ход выполнения
|
||||
|
||||
### Настройка Security Groups
|
||||
|
||||
#### Шаг 1 (Человек — веб-консоль)
|
||||
|
||||
**Действие:** Создал группу `web-server-sg`. Добавил правила: SSH (мой IP), HTTP (0.0.0.0/0), HTTPS (0.0.0.0/0). Применил к существующей ВМ.
|
||||
|
||||
**Результат:** Группа создана, правила применены.
|
||||
|
||||
![[VKC_PR_M02_Securitygroups_РемизовКЛ_20260531.png]]
|
||||
|
||||
#### Шаг 2 (Инструмент — OpenStack CLI)
|
||||
|
||||
**Действие:** Выполнил команды:
|
||||
|
||||
```bash
|
||||
openstack security group create database-sg --description "Security group for database servers"
|
||||
openstack security group rule create database-sg --protocol tcp --dst-port 22 --remote-ip 95.26.148.233/32
|
||||
openstack security group rule create database-sg --protocol tcp --dst-port 5432 --remote-ip 192.168.2.0/24
|
||||
openstack security group rule list database-sg
|
||||
openstack server add security group db-server database-sg
|
||||
```
|
||||
|
||||
**Результат:** Security group `database-sg` создана, правила SSH и PostgreSQL добавлены.
|
||||
|
||||
![[VKC_PR_M02_Securitygroupsbyopenstack_РемизовКЛ_20260531.png]]
|
||||
|
||||
#### Шаг 3 (Код — Terraform)
|
||||
|
||||
**Действие:** В `main.tf` описал:
|
||||
- Переменную `my_ip` (по умолчанию 95.26.148.233/32).
|
||||
- Ресурсы `vkcs_networking_secgroup` для web и db.
|
||||
- Правила `vkcs_networking_secgroup_rule` (ingress SSH/HTTP, egress; для БД — SSH/PostgreSQL из приватной подсети).
|
||||
|
||||
Выполнил `terraform apply`.
|
||||
|
||||
```
|
||||
# Security Group для веб-сервера
|
||||
resource "vkcs_compute_secgroup" "web_sg" {
|
||||
name = "terraform-web-sg"
|
||||
description = "Security group for web servers"
|
||||
|
||||
# Правило для SSH
|
||||
rule {
|
||||
ip_protocol = "tcp"
|
||||
from_port = 22
|
||||
to_port = 22
|
||||
cidr = var.my_ip # используем переменную
|
||||
}
|
||||
|
||||
# Правило для HTTP
|
||||
rule {
|
||||
ip_protocol = "tcp"
|
||||
from_port = 80
|
||||
to_port = 80
|
||||
cidr = "0.0.0.0/0"
|
||||
}
|
||||
|
||||
# Исходящий трафик (все разрешено)
|
||||
rule {
|
||||
ip_protocol = "tcp"
|
||||
from_port = 1
|
||||
to_port = 65535
|
||||
cidr = "0.0.0.0/0"
|
||||
direction = "egress"
|
||||
}
|
||||
}
|
||||
|
||||
# Security Group для базы данных
|
||||
resource "vkcs_compute_secgroup" "db_sg" {
|
||||
name = "terraform-db-sg"
|
||||
description = "Security group for database servers"
|
||||
|
||||
# SSH только из приватной подсети
|
||||
rule {
|
||||
ip_protocol = "tcp"
|
||||
from_port = 22
|
||||
to_port = 22
|
||||
cidr = "192.168.2.0/24"
|
||||
}
|
||||
|
||||
# PostgreSQL только из приватной подсети
|
||||
rule {
|
||||
ip_protocol = "tcp"
|
||||
from_port = 5432
|
||||
to_port = 5432
|
||||
cidr = "192.168.2.0/24"
|
||||
}
|
||||
}
|
||||
|
||||
# Переменная для вашего IP
|
||||
variable "my_ip" {
|
||||
description = "Your public IP for SSH access"
|
||||
type = string
|
||||
default = "0.0.0.0/0" # замените на свой IP
|
||||
}
|
||||
```
|
||||
|
||||
**Результат:** Security Groups созданы, правила настроены.
|
||||
|
||||
![[VKC_PR_M02_Securitygroupsbyterraform_РемизовКЛ_20260531.png]]
|
||||
|
||||
## 4. Ошибки и исправления
|
||||
|
||||
Oшибок не возникло.
|
||||
|
||||
## 5. Критерии успеха
|
||||
|
||||
- [x] Security Group `web-server-sg` и `database-sg` созданы с правильными правилами (SSH ограничен по IP, HTTP открыт, PostgreSQL разрешён из приватной подсети).
|
||||
|
||||
## 6. Приложенные доказательства
|
||||
|
||||
| Файл | Тип | Что подтверждает |
|
||||
| ----------------------------------------------------------- | -------- | ------------------------------------------ |
|
||||
| VKC_PR_M02_Securitygroups_РемизовКЛ_20260531.png | Скриншот | Security Group `web-server-sg` с правилами |
|
||||
| VKC_PR_M02_Securitygroupsbyopenstack_РемизовКЛ_20260531.png | Скриншот | Команды CLI для `database-sg` и результат |
|
||||
| VKC_PR_M02_Securitygroupsbyterraform_РемизовКЛ_20260531.png | Скриншот | Terraform apply для Security Groups |
|
||||
|
||||
## 7. Самопроверка
|
||||
|
||||
- **Что получилось:**
|
||||
Успешно создал полную сетевую инфраструктуру тремя способами. Настроил Security Groups с учётом минимальных привилегий.
|
||||
|
||||
## 8. Краткий вывод
|
||||
|
||||
В ходе практической работы были освоены ключевые навыки администрирования сети в VK Cloud: Hастройка stateful-брандмауэров (Security Groups) для защиты ВМ. Работа через веб-консоль, OpenStack CLI и Terraform позволила закрепить принцип «Человек → Инструмент → Код» и понять преимущества декларативного подхода к управлению инфраструктурой.
|
||||
@@ -0,0 +1,312 @@
|
||||
---
|
||||
course_code: VKCLOUD-80
|
||||
artifact_type: PR
|
||||
module: 2
|
||||
task_code: 3
|
||||
task_title: Настройка балансировщика нагрузки
|
||||
student_fio: Ремизов Кирилл Львович
|
||||
date: 2026-05-31
|
||||
source_docs:
|
||||
- 3-Конспект лекций - VK 1.md
|
||||
- 4-Практические работы - VK -1.md
|
||||
commands_used:
|
||||
- terraform init
|
||||
- terraform plan
|
||||
- terraform apply
|
||||
- terraform destroy
|
||||
attached_files:
|
||||
- VKC_PR_M02_Balancerpruf_РемизовКЛ_20260531.png
|
||||
- VKC_PR_M02_Balancerterraform_РемизовКЛ_20260531.png
|
||||
- VKC_PR_M02_Balancer_РемизовКЛ_20260531.png
|
||||
status: final
|
||||
---
|
||||
|
||||
# Отчет по практической демонстрации
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Освоить создание сетевой инфраструктуры в VK Cloud: Pазвертывание балансировщика нагрузки для распределения трафика между несколькими веб-серверами. Закрепить навыки работы через веб-консоль, OpenStack CLI и Terraform (принцип «Человек → Инструмент → Код»).
|
||||
|
||||
## 2. Что было прочитано перед выполнением
|
||||
|
||||
- **Документ:** 3-Конспект лекций - VK 1.md
|
||||
- **Раздел/тема:** Модуль 2. Сети и виртуальная инфраструктура (пункты 2.1, 2.2, 2.3)
|
||||
- **Ключевые понятия:**
|
||||
- Балансировщик нагрузки (Layer 4/7), Listener, Target Group, Health Checks.
|
||||
- OpenStack CLI, Terraform (ресурсы `vkcs_networking_network`, `vkcs_networking_subnet`, `vkcs_networking_secgroup`, `vkcs_lb_*`).
|
||||
|
||||
## 3. Ход выполнения
|
||||
|
||||
### Настройка балансировщика нагрузки
|
||||
|
||||
#### Шаг 1 (Человек — веб-консоль)
|
||||
|
||||
**Действие:** Создал две ВМ (`web-1` и `web-2`) с user-data для установки nginx и разными index.html. Создал балансировщик `my-lb` (публичная подсеть), слушатель HTTP:80, целевую группу `web-targets` (ROUND_ROBIN), добавил ВМ, настроил health check (HTTP, путь `/`, интервал 10с).
|
||||
|
||||
**Результат:** Балансировщик активен, при обращении по публичному IP чередуются страницы «Web Server 1» и «Web Server 2».
|
||||
|
||||
![[VKC_PR_M02_Balancer_РемизовКЛ_20260531.png]]
|
||||
|
||||
![[VKC_PR_M02_Balancerpruf_РемизовКЛ_20260531.png]]
|
||||
|
||||
#### Шаг 3 (Код — Terraform)
|
||||
|
||||
**Действие:** Создал полную конфигурацию `loadbalancer.tf`:
|
||||
- Сеть `my-vpc` и подсеть `public-subnet`.
|
||||
- Security groups для web (SSH/HTTP) и для LB (HTTP).
|
||||
- SSH-ключ `terraform-key`.
|
||||
- Две ВМ (`web-1`, `web-2`) с user-data для nginx.
|
||||
- Балансировщик `vkcs_lb_loadbalancer.main`, слушатель `vkcs_lb_listener.http`, пул `vkcs_lb_pool.web`, монитор `vkcs_lb_monitor.web`, члены пула `vkcs_lb_member.web1` и `web2`.
|
||||
|
||||
Выполнил `terraform apply`.
|
||||
|
||||
```
|
||||
# Указываем версию провайдера
|
||||
terraform {
|
||||
required_providers {
|
||||
vkcs = {
|
||||
source = "vk-cs/vkcs"
|
||||
version = "~> 0.1"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
# Настройка провайдера (использует переменные окружения из RC-файла)
|
||||
provider "vkcs" {}
|
||||
|
||||
variable "external_network" {
|
||||
description = "Имя внешней сети (не используется напрямую, но оставлено для совместимости)"
|
||||
type = string
|
||||
default = "internet"
|
||||
}
|
||||
|
||||
variable "image_name" {
|
||||
description = "Имя образа Ubuntu 22.04"
|
||||
type = string
|
||||
default = "ubuntu-22-202602051629.gite7a38aaf"
|
||||
}
|
||||
|
||||
variable "flavor_id" {
|
||||
description = "ID флейвора"
|
||||
type = string
|
||||
default = "df3c499a-044f-41d2-8612-d303adc613cc"
|
||||
}
|
||||
|
||||
variable "ssh_public_key_path" {
|
||||
description = "Путь к публичному SSH-ключу"
|
||||
type = string
|
||||
default = "~/.ssh/id_rsa.pub"
|
||||
}
|
||||
|
||||
variable "existing_router_id" {
|
||||
description = "ID существующего роутера (можно найти в выводе openstack router list)"
|
||||
type = string
|
||||
default = "913bdd47-9155-45b2-b404-5c10d0086132" # Ваш router_5390
|
||||
}
|
||||
|
||||
data "vkcs_networking_router" "existing" {
|
||||
router_id = var.existing_router_id
|
||||
}
|
||||
|
||||
resource "vkcs_networking_network" "main" {
|
||||
name = "my-vpc"
|
||||
admin_state_up = true
|
||||
}
|
||||
|
||||
resource "vkcs_networking_subnet" "public" {
|
||||
name = "public-subnet"
|
||||
network_id = vkcs_networking_network.main.id
|
||||
cidr = "192.168.1.0/24"
|
||||
dns_nameservers = ["8.8.8.8", "8.8.4.4"]
|
||||
}
|
||||
|
||||
# Подключение подсети к существующему роутеру (без создания нового)
|
||||
resource "vkcs_networking_router_interface" "main" {
|
||||
router_id = data.vkcs_networking_router.existing.id
|
||||
subnet_id = vkcs_networking_subnet.public.id
|
||||
}
|
||||
|
||||
resource "vkcs_networking_secgroup" "web_sg" {
|
||||
name = "web-sg"
|
||||
description = "Security group for web servers"
|
||||
}
|
||||
|
||||
resource "vkcs_networking_secgroup_rule" "ssh" {
|
||||
direction = "ingress"
|
||||
ethertype = "IPv4"
|
||||
protocol = "tcp"
|
||||
port_range_min = 22
|
||||
port_range_max = 22
|
||||
remote_ip_prefix = "0.0.0.0/0"
|
||||
security_group_id = vkcs_networking_secgroup.web_sg.id
|
||||
}
|
||||
|
||||
resource "vkcs_networking_secgroup_rule" "http" {
|
||||
direction = "ingress"
|
||||
ethertype = "IPv4"
|
||||
protocol = "tcp"
|
||||
port_range_min = 80
|
||||
port_range_max = 80
|
||||
remote_ip_prefix = "0.0.0.0/0"
|
||||
security_group_id = vkcs_networking_secgroup.web_sg.id
|
||||
}
|
||||
|
||||
resource "vkcs_networking_secgroup" "lb_sg" {
|
||||
name = "lb-sg"
|
||||
description = "Security group for load balancer"
|
||||
}
|
||||
|
||||
resource "vkcs_networking_secgroup_rule" "lb_http" {
|
||||
direction = "ingress"
|
||||
ethertype = "IPv4"
|
||||
protocol = "tcp"
|
||||
port_range_min = 80
|
||||
port_range_max = 80
|
||||
remote_ip_prefix = "0.0.0.0/0"
|
||||
security_group_id = vkcs_networking_secgroup.lb_sg.id
|
||||
}
|
||||
|
||||
resource "vkcs_compute_keypair" "my_key" {
|
||||
name = "terraform-key"
|
||||
public_key = file(var.ssh_public_key_path)
|
||||
}
|
||||
|
||||
resource "vkcs_compute_instance" "web1" {
|
||||
name = "web-1"
|
||||
flavor_id = var.flavor_id
|
||||
image_name = var.image_name
|
||||
key_pair = vkcs_compute_keypair.my_key.name
|
||||
|
||||
network {
|
||||
uuid = vkcs_networking_network.main.id
|
||||
}
|
||||
|
||||
security_groups = [vkcs_networking_secgroup.web_sg.name]
|
||||
|
||||
user_data = <<-EOF
|
||||
#!/bin/bash
|
||||
apt update
|
||||
apt install -y nginx
|
||||
echo "<h1>Web Server 1</h1>" > /var/www/html/index.html
|
||||
systemctl enable nginx
|
||||
systemctl start nginx
|
||||
EOF
|
||||
}
|
||||
|
||||
resource "vkcs_compute_instance" "web2" {
|
||||
name = "web-2"
|
||||
flavor_id = var.flavor_id
|
||||
image_name = var.image_name
|
||||
key_pair = vkcs_compute_keypair.my_key.name
|
||||
|
||||
network {
|
||||
uuid = vkcs_networking_network.main.id
|
||||
}
|
||||
|
||||
security_groups = [vkcs_networking_secgroup.web_sg.name]
|
||||
|
||||
user_data = <<-EOF
|
||||
#!/bin/bash
|
||||
apt update
|
||||
apt install -y nginx
|
||||
echo "<h1>Web Server 2</h1>" > /var/www/html/index.html
|
||||
systemctl enable nginx
|
||||
systemctl start nginx
|
||||
EOF
|
||||
}
|
||||
|
||||
resource "vkcs_lb_loadbalancer" "main" {
|
||||
name = "my-lb"
|
||||
vip_subnet_id = vkcs_networking_subnet.public.id
|
||||
security_group_ids = [vkcs_networking_secgroup.lb_sg.id]
|
||||
}
|
||||
|
||||
resource "vkcs_lb_listener" "http" {
|
||||
name = "http-listener"
|
||||
protocol = "HTTP"
|
||||
protocol_port = 80
|
||||
loadbalancer_id = vkcs_lb_loadbalancer.main.id
|
||||
}
|
||||
|
||||
resource "vkcs_lb_pool" "web" {
|
||||
name = "web-targets"
|
||||
protocol = "HTTP"
|
||||
lb_method = "ROUND_ROBIN"
|
||||
listener_id = vkcs_lb_listener.http.id
|
||||
}
|
||||
|
||||
resource "vkcs_lb_monitor" "web" {
|
||||
name = "web-monitor"
|
||||
type = "HTTP"
|
||||
delay = 10
|
||||
timeout = 5
|
||||
max_retries = 3
|
||||
url_path = "/"
|
||||
pool_id = vkcs_lb_pool.web.id
|
||||
}
|
||||
|
||||
resource "vkcs_lb_member" "web1" {
|
||||
name = "web1-member"
|
||||
address = vkcs_compute_instance.web1.access_ip_v4
|
||||
protocol_port = 80
|
||||
pool_id = vkcs_lb_pool.web.id
|
||||
subnet_id = vkcs_networking_subnet.public.id
|
||||
}
|
||||
|
||||
resource "vkcs_lb_member" "web2" {
|
||||
name = "web2-member"
|
||||
address = vkcs_compute_instance.web2.access_ip_v4
|
||||
protocol_port = 80
|
||||
pool_id = vkcs_lb_pool.web.id
|
||||
subnet_id = vkcs_networking_subnet.public.id
|
||||
}
|
||||
|
||||
output "lb_ip" {
|
||||
value = vkcs_lb_loadbalancer.main.vip_address
|
||||
description = "Внешний IP-адрес балансировщика"
|
||||
}
|
||||
|
||||
output "web1_ip" {
|
||||
value = vkcs_compute_instance.web1.access_ip_v4
|
||||
description = "IP-адрес web-1"
|
||||
}
|
||||
|
||||
output "web2_ip" {
|
||||
value = vkcs_compute_instance.web2.access_ip_v4
|
||||
description = "IP-адрес web-2"
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
**Результат:** Балансировщик и две ВМ созданы, получены выходные IP-адреса. Приложение доступно по IP балансировщика.
|
||||
|
||||
![[VKC_PR_M02_Balancerterraform_РемизовКЛ_20260531.png]]
|
||||
|
||||
## 4. Ошибки и исправления
|
||||
|
||||
- **Ошибка:** При первом запуске Terraform для балансировщика возникла ошибка `"Router not found"` при создании `vkcs_networking_router_interface`.
|
||||
- **Причина:** В конфигурации использовался несуществующий ID роутера.
|
||||
- **Исправление:** Получил актуальный ID роутера через `openstack router list` и подставил в переменную `existing_router_id`. После повторного `terraform apply` интерфейс подключился корректно.
|
||||
|
||||
Других ошибок не возникло.
|
||||
|
||||
## 5. Критерии успеха
|
||||
|
||||
- [x] Две ВМ с nginx запущены, балансировщик создан, целевая группа содержит обе ВМ, health check работает, приложение отвечает по внешнему IP балансировщика, страницы чередуются.
|
||||
|
||||
## 6. Приложенные доказательства
|
||||
|
||||
| Файл | Тип | Что подтверждает |
|
||||
| --------------------------------------------------- | -------- | --------------------------------------------------------- |
|
||||
| VKC_PR_M02_Balancerpruf_РемизовКЛ_20260531.png | Скриншот | Факт работы балансировщика с машинами ``web1`` и ``web2`` |
|
||||
| VKC_PR_M02_Balancer_РемизовКЛ_20260531.png | Скриншот | Балансировщик `my-lb` и целевая группа |
|
||||
| VKC_PR_M02_Balancerterraform_РемизовКЛ_20260531.png | Скриншот | Terraform apply для балансировщика – выходные IP |
|
||||
|
||||
## 7. Самопроверка
|
||||
|
||||
- **Что получилось:**
|
||||
Успешно создал полную сетевую инфраструктуру тремя способами. Развернул отказоустойчивый веб-сервис с балансировщиком и health checks.
|
||||
|
||||
## 8. Краткий вывод
|
||||
|
||||
В ходе практической работы были освоены ключевые навыки администрирования сети в VK Cloud: балансировка нагрузки с автоматическим контролем состояния серверов. Работа через веб-консоль, OpenStack CLI и Terraform позволила закрепить принцип «Человек → Инструмент → Код» и понять преимущества декларативного подхода к управлению инфраструктурой.
|
||||
@@ -0,0 +1,267 @@
|
||||
---
|
||||
course_code: VKCLOUD-80
|
||||
artifact_type: PR
|
||||
module: 3
|
||||
task_code: 1
|
||||
task_title: Работа с объектным хранилищем (S3)
|
||||
student_fio: Ремизов Кирилл Львович
|
||||
date: 2026-06-09
|
||||
source_docs:
|
||||
- 3-Конспект лекций - VK 1.md
|
||||
- 4-Практические работы - VK -1.md
|
||||
commands_used:
|
||||
- aws configure
|
||||
- aws s3 mb
|
||||
- aws s3 cp
|
||||
- aws s3api put-object-acl
|
||||
- terraform init
|
||||
- terraform plan
|
||||
- terraform apply
|
||||
attached_files:
|
||||
- VKC_PR_M03_index_РемизовКЛ_20260609.png
|
||||
- VKC_PR_M03_aws_РемизовКЛ_20260609.log
|
||||
- VKC_PR_M03_Bucket_РемизовКЛ_20260609.png
|
||||
- VKC_PR_M03_terraform_РемизовКЛ_20260609.log
|
||||
status: final
|
||||
---
|
||||
|
||||
# Отчет по практической демонстрации
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Освоить работу с объектным хранилищем (S3‑совместимым) в VK Cloud: создание бакета, загрузка файлов, настройка публичного доступа и статического хостинга. Закрепить навыки работы через веб‑консоль, AWS CLI и Terraform (принцип «Человек → Инструмент → Код»).
|
||||
|
||||
## 2. Что было прочитано перед выполнением
|
||||
|
||||
- **Документ:** 3-Конспект лекций - VK 1.md
|
||||
- **Раздел/тема:** Модуль 3. Управляемые сервисы данных, пункт «Объектное хранилище S3»
|
||||
- **Ключевые понятия:**
|
||||
- Бакет (bucket), объект (object), ключ (key)
|
||||
- Политики доступа (Bucket Policy), публичный доступ
|
||||
- Статический хостинг (Static Website Hosting)
|
||||
- S3‑совместимый API, endpoint `https://hb.ru-msk.vkcloud-storage.ru`
|
||||
- AWS CLI, Terraform провайдеры `vkcs` и `aws` (совместимость)
|
||||
|
||||
## 3. Ход выполнения
|
||||
|
||||
### Демонстрация 3.1: Работа с объектным хранилищем (S3)
|
||||
|
||||
#### Этап 1 (Человек — веб-консоль)
|
||||
|
||||
**Действие:**
|
||||
Создал бакет в объектном хранилище через веб‑интерфейс VK Cloud.
|
||||
|
||||
1. Перешёл в раздел **«Хранилище» → «Объектное хранилище S3»**.
|
||||
2. Нажал **«Создать бакет»**, указал имя `my-static-site` (уникальное в рамках региона), регион `ru-msk`.
|
||||
3. Загрузил файл `index.html` с содержимым:
|
||||
```html
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head><title>My Static Site</title></head>
|
||||
<body><h1>Hello from S3!</h1></body>
|
||||
</html>
|
||||
```
|
||||
4. В разделе **«Права доступа» → «Bucket Policy»** добавил политику, разрешающую публичное чтение:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Principal": "*",
|
||||
"Action": "s3:GetObject",
|
||||
"Resource": "arn:aws:s3:::my-static-site/*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
5. Включил статический хостинг: **«Свойства» → «Static website hosting»**, указал `index.html` как индексный документ.
|
||||
|
||||
**Результат:**
|
||||
Бакет создан, файл загружен, сайт стал доступен по URL (позднее проверено через браузер).
|
||||
|
||||
![[VKC_PR_M03_Bucket_РемизовКЛ_20260609.png]]
|
||||
*Скриншот: бакет `my-static-site` в веб‑консоли VK Cloud.*
|
||||
|
||||
![[VKC_PR_M03_index_РемизовКЛ_20260609.png]]
|
||||
*Скриншот: содержимое бакета с загруженным `index.html`.*
|
||||
|
||||
#### Этап 2 (Инструмент — AWS CLI)
|
||||
|
||||
**Действие:**
|
||||
Использовал AWS CLI, совместимый с S3 API VK Cloud, для выполнения аналогичных операций.
|
||||
|
||||
1. Установил AWS CLI (`pip install awscli`).
|
||||
2. Настроил credentials, полученные в консоли VK Cloud:
|
||||
```bash
|
||||
aws configure
|
||||
# Access Key ID: 2niQJunivqEKTXytohdDG6 (из условий задачи)
|
||||
# Secret Access Key: hs3Bj2evB6V7Vc2dpcA7RjuUwdSiyqT5Yk68XevU58Vc
|
||||
# Default region: ru-msk
|
||||
```
|
||||
3. Создал бакет `my-cli-bucket`:
|
||||
```bash
|
||||
aws s3 mb s3://my-cli-bucket --endpoint-url https://hb.ru-msk.vkcloud-storage.ru
|
||||
```
|
||||
4. Создал тестовый файл и загрузил его:
|
||||
```bash
|
||||
echo "<h1>CLI Upload</h1>" > index.html
|
||||
aws s3 cp index.html s3://my-cli-bucket/ --endpoint-url https://hb.ru-msk.vkcloud-storage.ru
|
||||
```
|
||||
5. Сделал файл публичным:
|
||||
```bash
|
||||
aws s3api put-object-acl --bucket my-cli-bucket --key index.html --acl public-read \
|
||||
--endpoint-url https://hb.ru-msk.vkcloud-storage.ru
|
||||
```
|
||||
6. Проверил доступность через `curl`:
|
||||
```bash
|
||||
curl http://my-cli-bucket.s3-website.ru-msk.vkcs.cloud/index.html
|
||||
```
|
||||
|
||||
**Результат:**
|
||||
Бакет и файл успешно созданы, публичный доступ настроен. Все команды зафиксированы в логе.
|
||||
|
||||
**Лог команд:**
|
||||
[[VKC_PR_M03_aws_РемизовКЛ_20260609.log]]
|
||||
|
||||
#### Этап 3 (Код — Terraform)
|
||||
|
||||
**Действие:**
|
||||
Описана инфраструктура статического сайта на языке Terraform с использованием провайдера `aws`, сконфигурированного для работы с VK Cloud S3.
|
||||
|
||||
**Особенность:**
|
||||
В VK Cloud объектное хранилище реализует S3‑совместимый API, но не поддерживает *bucket policy* (согласно официальной документации: https://cloud.vk.com/docs/en/storage/s3/concepts/s3-api). Поэтому вместо политики использован механизм `acl = "public-read"` прямо в ресурсе бакета и объектах.
|
||||
|
||||
**Файл `main.tf` (приведён в отчёте):**
|
||||
|
||||
```hcl
|
||||
terraform {
|
||||
required_providers {
|
||||
vkcs = {
|
||||
source = "vk-cs/vkcs"
|
||||
version = "~> 0.1"
|
||||
}
|
||||
aws = {
|
||||
source = "hashicorp/aws"
|
||||
version = "~> 5.0"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
# Провайдер VKCS используется для авторизации (непосредственно для S3 не нужен)
|
||||
provider "vkcs" {}
|
||||
|
||||
# Провайдер AWS, перенастроенный на VK Cloud S3
|
||||
provider "aws" {
|
||||
region = "us-east-1"
|
||||
|
||||
access_key = "..."
|
||||
secret_key = "..."
|
||||
|
||||
skip_credentials_validation = true
|
||||
skip_metadata_api_check = true
|
||||
skip_requesting_account_id = true
|
||||
|
||||
endpoints {
|
||||
s3 = "https://hb.ru-msk.vkcloud-storage.ru"
|
||||
}
|
||||
}
|
||||
|
||||
# Бакет с публичным доступом через ACL
|
||||
resource "aws_s3_bucket" "static_site" {
|
||||
bucket = "terraform-static-site"
|
||||
acl = "public-read"
|
||||
}
|
||||
|
||||
# Включение статического хостинга
|
||||
resource "aws_s3_bucket_website_configuration" "static_site" {
|
||||
bucket = aws_s3_bucket.static_site.id
|
||||
|
||||
index_document {
|
||||
suffix = "index.html"
|
||||
}
|
||||
error_document {
|
||||
key = "error.html"
|
||||
}
|
||||
}
|
||||
|
||||
# Индексный файл
|
||||
resource "aws_s3_object" "index" {
|
||||
bucket = aws_s3_bucket.static_site.bucket
|
||||
key = "index.html"
|
||||
content = <<-EOF
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head><title>Terraform Site</title></head>
|
||||
<body>
|
||||
<h1>Deployed with Terraform!</h1>
|
||||
<p>This site was created automatically.</p>
|
||||
</body>
|
||||
</html>
|
||||
EOF
|
||||
content_type = "text/html"
|
||||
acl = "public-read"
|
||||
}
|
||||
|
||||
# Файл ошибки
|
||||
resource "aws_s3_object" "error" {
|
||||
bucket = aws_s3_bucket.static_site.bucket
|
||||
key = "error.html"
|
||||
content = "<h1>404 - Page Not Found</h1>"
|
||||
content_type = "text/html"
|
||||
acl = "public-read"
|
||||
}
|
||||
```
|
||||
|
||||
**Выполненные команды Terraform:**
|
||||
|
||||
```bash
|
||||
terraform init
|
||||
terraform plan
|
||||
terraform apply
|
||||
```
|
||||
|
||||
**Результат:**
|
||||
Бакет `terraform-static-site` создан, оба HTML‑объекта загружены, статический хостинг включён. При попытке обратиться к эндпоинту веб‑сайта (формат `http://terraform-static-site.s3-website.ru-msk.vkcs.cloud/`) отображается страница «Deployed with Terraform!».
|
||||
|
||||
**Лог выполнения Terraform:**
|
||||
[[VKC_PR_M03_terraform_РемизовКЛ_20260609.log]]
|
||||
|
||||
## 4. Ошибки и исправления
|
||||
|
||||
| Проблема | Решение |
|
||||
| :--- | :--- |
|
||||
| При попытке добавить `bucket_policy` через Terraform ресурс `aws_s3_bucket_policy` или `vkcs_objectstorage_bucket_policy` возникала ошибка «Not implemented». | Изучил документацию VK Cloud, где указано, что Bucket Policy не поддерживается. Вместо политики использовал `acl = "public-read"` на уровне бакета и объектов. |
|
||||
| Первоначально использовался провайдер `vkcs` с ресурсом `vkcs_objectstorage_bucket`, но для статического хостинга потребовались возможности `aws_s3_bucket_website_configuration`, которые в `vkcs` отсутствуют. | Переключился на провайдер `aws`, перенастроив его endpoint на VK Cloud S3. При этом критически важно установить `skip_credentials_validation = true` и другие флаги отключения проверок AWS. |
|
||||
|
||||
## 5. Критерии успеха
|
||||
|
||||
- [x] Бакет создан через веб‑консоль, AWS CLI и Terraform.
|
||||
- [x] В бакет загружены файлы `index.html` и `error.html`.
|
||||
- [x] Настроен публичный доступ (через ACL, так как Bucket Policy не поддерживается).
|
||||
- [x] Включена функция статического хостинга.
|
||||
- [x] Сайт доступен по публичному URL (проверено через браузер или `curl`).
|
||||
|
||||
## 6. Приложенные доказательства
|
||||
|
||||
| Файл | Тип | Что подтверждает |
|
||||
| ---------------------------------------------------------- | -------- | ----------------------------------------------------- |
|
||||
| VKC_PR_M03_Bucket_РемизовКЛ_20260609.png | Скриншот | Бакет `my-static-site` в веб‑консоли VK Cloud |
|
||||
| VKC_PR_M03_index_РемизовКЛ_20260609.png | Скриншот | Содержимое бакета с загруженным `index.html` |
|
||||
| VKC_PR_M03_aws_РемизовКЛ_20260609.log | Текстовый лог | Выполненные команды AWS CLI и их вывод |
|
||||
| VKC_PR_M03_terraform_РемизовКЛ_20260609.log | Текстовый лог | Вывод `terraform apply` и финальный результат |
|
||||
|
||||
## 7. Самопроверка
|
||||
|
||||
- **Что получилось:**
|
||||
Успешно создал статический сайт, размещённый в S3, тремя способами. Освоил использование AWS CLI с нестандартным endpoint. Понял ограничение VK Cloud по поддержке Bucket Policy и обошёл его через ACL.
|
||||
|
||||
- **Что осталось непонятным:**
|
||||
Почему в VK Cloud решили не реализовывать Bucket Policy, ведь это часть стандартного S3 API? Но это вопрос к платформе, а не к заданию.
|
||||
|
||||
- **Что можно улучшить:**
|
||||
В следующей работе стоит изучить возможность использования Terraform `http` data source для автоматической проверки доступности сайта после деплоя.
|
||||
|
||||
## 8. Краткий вывод
|
||||
|
||||
В ходе практической работы были освоены ключевые навыки работы с объектным хранилищем VK Cloud: создание бакета, управление доступом, настройка статического хостинга. Работа через веб‑консоль, AWS CLI и Terraform позволила закрепить принцип «Человек → Инструмент → Код», а также выявить особенности реализации S3‑совместимого API в VK Cloud (отсутствие Bucket Policy). Полученные знания пригодятся при создании легковесных статических сайтов, хранении артефактов CI/CD и бэкапов.
|
||||
@@ -0,0 +1,284 @@
|
||||
---
|
||||
course_code: VKCLOUD-80
|
||||
artifact_type: PR
|
||||
module: 3
|
||||
task_code: 2
|
||||
task_title: Создание управляемой базы данных PostgreSQL
|
||||
student_fio: Ремизов Кирилл Львович
|
||||
date: 2026-06-10
|
||||
source_docs:
|
||||
- 3-Конспект лекций - VK 1.md
|
||||
- 4-Практические работы - VK -1.md
|
||||
commands_used:
|
||||
- psql
|
||||
- openstack database instance list (не удалось)
|
||||
- terraform init/plan/apply
|
||||
attached_files:
|
||||
- VKC_PR_M03_CreatedDBShow_РемизовКЛ_20260609.png
|
||||
- VKC_PR_M03_DBLog_РемизовКЛ_20260610.log
|
||||
- VKC_PR_M03_DBopenStack_РемизовКЛ_20260610.log
|
||||
- VKC_PR_M03_DBTerraform_РемизовКЛ_20260610.log
|
||||
status: final
|
||||
---
|
||||
|
||||
# Отчет по практической демонстрации
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Освоить создание и использование управляемого инстанса PostgreSQL (DBaaS) в VK Cloud.
|
||||
Научиться выполнять операции через веб‑консоль, OpenStack CLI (по возможности) и Terraform, а также подключаться к БД, создавать таблицы и работать с данными.
|
||||
Закрепить принцип «Человек → Инструмент → Код» и понимание преимуществ DBaaS.
|
||||
|
||||
## 2. Что было прочитано перед выполнением
|
||||
|
||||
- **Документ:** 3-Конспект лекций - VK 1.md
|
||||
- **Раздел/тема:** Модуль 3 «Управляемые сервисы данных», тема 3.2 «Управляемые базы данных (DBaaS)»
|
||||
- **Ключевые понятия:**
|
||||
- DBaaS, автоматическое резервное копирование (PITR)
|
||||
- Реляционные СУБД: PostgreSQL, MySQL
|
||||
- Сеть для БД (приватные подсети), бастионный хост
|
||||
- Параметры подключения: хост, порт, пользователь, пароль
|
||||
- Terraform‑ресурсы: `vkcs_db_instance`, `vkcs_db_database`, `vkcs_db_user`, `random_password`
|
||||
|
||||
## 3. Ход выполнения
|
||||
|
||||
### Демонстрация 3.2: Создание управляемой базы данных PostgreSQL
|
||||
|
||||
#### Этап 1 (Человек — веб‑консоль)
|
||||
|
||||
**Действие:**
|
||||
Создал инстанс PostgreSQL через веб‑интерфейс VK Cloud, настроил доступ и выполнил SQL‑запросы.
|
||||
|
||||
1. Перешёл в раздел **«Базы данных» → «PostgreSQL»**, нажал **«Создать кластер»**.
|
||||
2. Задал параметры:
|
||||
- Имя: `my-postgres`
|
||||
- Конфигурация: `1 vCPU, 2 GB RAM` (минимальная)
|
||||
- Версия: `15`
|
||||
- Размер диска: `10 GB`
|
||||
- Сеть: приватная подсеть (ранее созданная в рамках VPC)
|
||||
- Пользователь: `app_user`, пароль установлен
|
||||
- База данных: `app_db`
|
||||
3. Дождался создания инстанса (3–5 минут).
|
||||
4. Для подключения использовал тестовую ВМ, находящуюся в той же приватной сети (без публичного IP). На ВМ установил `postgresql-client`:
|
||||
```bash
|
||||
sudo apt update && sudo apt install postgresql-client -y
|
||||
```
|
||||
5. Подключился к БД:
|
||||
```bash
|
||||
psql -h 192.168.199.129 -U app_user -d app_db
|
||||
```
|
||||
6. Выполнил SQL‑скрипт (создание таблицы `users`, вставка данных, выборка):
|
||||
```sql
|
||||
CREATE TABLE users (
|
||||
id SERIAL PRIMARY KEY,
|
||||
name VARCHAR(100),
|
||||
email VARCHAR(100) UNIQUE,
|
||||
created_at TIMESTAMP DEFAULT NOW()
|
||||
);
|
||||
INSERT INTO users (name, email) VALUES
|
||||
('Alice', 'alice@example.com'),
|
||||
('Bob', 'bob@example.com');
|
||||
SELECT * FROM users;
|
||||
```
|
||||
|
||||
**Результат:**
|
||||
Таблица создана, данные вставлены и успешно прочитаны. Подтверждение в логе подключения.
|
||||
|
||||
![[VKC_PR_M03_CreatedDBShow_РемизовКЛ_20260609.png]]
|
||||
*Скриншот: созданный инстанс `my-postgres` в веб‑консоли VK Cloud.*
|
||||
|
||||
**Лог подключения и SQL‑команд:**
|
||||
[[VKC_PR_M03_DBLog_РемизовКЛ_20260610.log]]
|
||||
|
||||
---
|
||||
|
||||
#### Этап 2 (Инструмент — OpenStack CLI)
|
||||
|
||||
**Действие:**
|
||||
Попытался использовать OpenStack CLI для управления инстансом БД, как описано в сценарии практической работы.
|
||||
|
||||
**Выполненные команды:**
|
||||
|
||||
```bash
|
||||
openstack database instance list
|
||||
openstack database instance show my-postgres
|
||||
openstack database instance show my-postgres -c hosts -c datastore
|
||||
```
|
||||
|
||||
**Результат:**
|
||||
Команды завершились с ошибкой:
|
||||
```
|
||||
openstack: 'database instance list' is not an openstack command. See 'openstack --help'.
|
||||
```
|
||||
|
||||
**Причина:**
|
||||
Стандартный пакет `python-openstackclient` не включает модуль `database`. Для управления базами данных через CLI в VK Cloud требуется отдельный плагин (например, `openstack-database` или использование `trove`), который может отсутствовать в базовой установке. Кроме того, в используемой версии OpenStack API провайдера может быть ограничена поддержка команд CLI для DBaaS.
|
||||
|
||||
**Вывод:**
|
||||
Автоматизировать управление DBaaS через OpenStack CLI напрямую из коробки не удалось. Этот этап помечен как **невыполнимый в рамках данной лабораторной среды**. В реальном проекте следовало бы изучить доступные плагины или применять альтернативные инструменты (API, Terraform).
|
||||
|
||||
**Лог неудачных попыток:**
|
||||
[[VKC_PR_M03_DBopenStack_РемизовКЛ_20260610.log]]
|
||||
|
||||
---
|
||||
|
||||
#### Этап 3 (Код — Terraform)
|
||||
|
||||
**Действие:**
|
||||
Описана инфраструктура для управляемой БД на языке Terraform с использованием провайдера `vkcs`. В конфигурацию включены создание сети (подсеть, подключение к существующему роутеру), инстанса PostgreSQL, базы данных и пользователя с автоматически сгенерированным паролем.
|
||||
|
||||
**Файл `main.tf` (приведён в шаблоне отчёта):**
|
||||
|
||||
```hcl
|
||||
terraform {
|
||||
required_providers {
|
||||
vkcs = { source = "vk-cs/vkcs" }
|
||||
random = { source = "hashicorp/random" }
|
||||
}
|
||||
}
|
||||
|
||||
provider "vkcs" {}
|
||||
|
||||
data "vkcs_networking_router" "main" {
|
||||
name = "router_5390"
|
||||
}
|
||||
|
||||
resource "vkcs_networking_network" "main" {
|
||||
name = "postgres-network"
|
||||
admin_state_up = true
|
||||
}
|
||||
|
||||
resource "vkcs_networking_subnet" "main" {
|
||||
name = "postgres-subnet"
|
||||
network_id = vkcs_networking_network.main.id
|
||||
cidr = "192.168.199.0/24"
|
||||
}
|
||||
|
||||
resource "vkcs_networking_router_interface" "main" {
|
||||
router_id = data.vkcs_networking_router.main.id
|
||||
subnet_id = vkcs_networking_subnet.main.id
|
||||
}
|
||||
|
||||
resource "vkcs_db_instance" "postgres" {
|
||||
name = "terraform-postgres"
|
||||
flavor_id = "2df6e3ec-5939-4d28-a818-89558ff1b7ab"
|
||||
volume_type = "ceph-ssd"
|
||||
size = 10
|
||||
availability_zone = "MS1"
|
||||
floating_ip_enabled = true
|
||||
datastore {
|
||||
type = "postgresql"
|
||||
version = "15"
|
||||
}
|
||||
network {
|
||||
uuid = vkcs_networking_network.main.id
|
||||
}
|
||||
}
|
||||
|
||||
resource "random_password" "db_password" {
|
||||
length = 16
|
||||
special = true
|
||||
min_lower = 1
|
||||
min_upper = 1
|
||||
min_numeric = 1
|
||||
min_special = 1
|
||||
}
|
||||
|
||||
resource "vkcs_db_database" "app_db" {
|
||||
name = "app_db"
|
||||
dbms_id = vkcs_db_instance.postgres.id
|
||||
}
|
||||
|
||||
resource "vkcs_db_user" "app_user" {
|
||||
name = "app_user"
|
||||
password = random_password.db_password.result
|
||||
dbms_id = vkcs_db_instance.postgres.id
|
||||
databases = [vkcs_db_database.app_db.name]
|
||||
}
|
||||
|
||||
resource "local_file" "db_password" {
|
||||
content = "Database password: ${random_password.db_password.result}"
|
||||
filename = "${path.module}/db_password.txt"
|
||||
}
|
||||
|
||||
output "db_host" {
|
||||
value = vkcs_db_instance.postgres.hostname
|
||||
}
|
||||
output "db_port" { value = 5432 }
|
||||
output "db_name" { value = vkcs_db_database.app_db.name }
|
||||
output "db_user" { value = vkcs_db_user.app_user.name }
|
||||
```
|
||||
|
||||
**Выполненные команды Terraform:**
|
||||
|
||||
```bash
|
||||
terraform init
|
||||
terraform plan
|
||||
terraform apply -auto-approve # после успешного plan
|
||||
```
|
||||
|
||||
**Проблема при первом apply:**
|
||||
Терраформ выдал ошибку:
|
||||
|
||||
```
|
||||
Error: error creating vkcs_db_instance: Bad request ... "The network must be routable"
|
||||
```
|
||||
|
||||
**Причина:**
|
||||
Созданная сеть `postgres-network` не была связана с роутером, имеющим доступ к внешней сети (или не была правильно маршрутизирована). Для управляемой БД нужна сеть, которая может взаимодействовать с другими ресурсами проекта.
|
||||
|
||||
**Решение:**
|
||||
Добавлен блок `vkcs_networking_router_interface`, который привязывает созданную подсеть к существующему роутеру (`router_5390`). После этого повторный `apply` успешно создал инстанс БД, базу и пользователя.
|
||||
|
||||
**Результат:**
|
||||
- Инстанс `terraform-postgres` создан (2 мин 39 сек).
|
||||
- База данных `app_db` и пользователь `app_user` добавлены.
|
||||
- Пароль сохранён в локальный файл `db_password.txt`.
|
||||
- Выводы Terraform содержат хост, порт, имя БД и пользователя.
|
||||
|
||||
**Лог успешного Terraform‑применения:**
|
||||
[[VKC_PR_M03_DBTerraform_РемизовКЛ_20260610.log]]
|
||||
|
||||
---
|
||||
|
||||
## 4. Ошибки и исправления
|
||||
|
||||
| Проблема | Решение |
|
||||
| :--- | :--- |
|
||||
| **OpenStack CLI:** команды `openstack database instance ...` отсутствуют. | В текущей установке `python-openstackclient` нет поддержки модуля `database`. Альтернатива – использовать веб‑консоль, Terraform или прямой API. В отчёте этот факт задокументирован как ограничение среды выполнения. |
|
||||
| **Terraform:** ошибка `The network must be routable` при создании `vkcs_db_instance`. | Созданная сеть не была связана с маршрутизатором. Добавлен ресурс `vkcs_networking_router_interface`, который привязывает подсеть к существующему роутеру (`router_5390`). Это обеспечило маршрутизацию и устранило ошибку. |
|
||||
|
||||
## 5. Критерии успеха
|
||||
|
||||
- [x] Инстанс управляемой БД PostgreSQL создан через веб‑консоль.
|
||||
- [x] Подключение к БД выполнено с тестовой ВМ, расположенной в той же сети.
|
||||
- [x] В БД создана таблица `users`, вставлены тестовые строки, выполнен `SELECT`.
|
||||
- [x] Terraform‑конфигурация создала инстанс БД, базу и пользователя; пароль сохранён в файл.
|
||||
- [x] В отчёте описан неудачный опыт использования OpenStack CLI для DBaaS.
|
||||
|
||||
## 6. Приложенные доказательства
|
||||
|
||||
| Файл | Тип | Что подтверждает |
|
||||
| ---------------------------------------------------------- | ------------- | ----------------------------------------------------- |
|
||||
| VKC_PR_M03_CreatedDBShow_РемизовКЛ_20260609.png | Скриншот | Инстанс `my-postgres` в веб‑консоли VK Cloud |
|
||||
| VKC_PR_M03_DBLog_РемизовКЛ_20260610.log | Текстовый лог | Подключение `psql`, создание таблицы, вставка данных |
|
||||
| VKC_PR_M03_DBopenStack_РемизовКЛ_20260610.log | Текстовый лог | Неудачные попытки команд OpenStack CLI |
|
||||
| VKC_PR_M03_DBTerraform_РемизовКЛ_20260610.log | Текстовый лог | Успешное применение Terraform (после исправления сети)|
|
||||
|
||||
## 7. Самопроверка
|
||||
|
||||
- **Что получилось:**
|
||||
Успешно создал управляемую БД через консоль и Terraform. Подключился из ВМ в приватной сети, выполнил SQL‑запросы. Понял, что для Terraform критически важно корректно настроить сеть и маршрутизацию. Освоил ресурсы `vkcs_db_*`.
|
||||
|
||||
- **Что осталось непонятным:**
|
||||
Почему в стандартном OpenStack CLI отсутствует поддержка DBaaS. Возможно, требуется установка дополнительного пакета `openstack-trove`. В рабочем проекте этот вопрос требует дополнительного изучения.
|
||||
|
||||
- **Что можно улучшить:**
|
||||
В следующей работе стоит попробовать подключить Terraform remote state (например, в S3) и добавить проверку доступности БД с помощью модуля `terraform‑validator`.
|
||||
|
||||
## 8. Краткий вывод
|
||||
|
||||
В ходе практической работы закреплены навыки создания управляемой базы данных PostgreSQL в VK Cloud тремя способами (консоль, попытка CLI, Terraform). Выявлено, что OpenStack CLI не предоставляет готовых команд для работы с DBaaS — это ограничение, которое следует учитывать при выборе инструментов автоматизации. Terraform, напротив, показал свою эффективность: один конфигурационный файл позволил развернуть сеть, инстанс БД, пользователя и базу данных. Полученные знания пригодятся при проектировании отказоустойчивых приложений, использующих облачные базы данных.
|
||||
|
||||
**Ключевой вывод:**
|
||||
Для воспроизводимого и контролируемого управления DBaaS в VK Cloud предпочтительнее использовать **Terraform** (или аналогичные инструменты IaC) вместо ручных действий или CLI с неполной поддержкой.
|
||||
@@ -0,0 +1,166 @@
|
||||
---
|
||||
course_code: VKCLOUD-80
|
||||
artifact_type: PR
|
||||
module: 4
|
||||
task_code: 1
|
||||
task_title: Работа с OpenStack CLI
|
||||
student_fio: Ремизов Кирилл Львович
|
||||
date: 2026-06-14
|
||||
source_docs:
|
||||
- 3-Конспект лекций - VK 1.md
|
||||
- 4-Практические работы - VK -1.md
|
||||
commands_used:
|
||||
- source
|
||||
- openstack token issue
|
||||
- openstack server create
|
||||
- openstack server stop
|
||||
- openstack server image create
|
||||
- openstack server start
|
||||
- openstack image list
|
||||
attached_files:
|
||||
- VKC_PR_M04_1_VMCreate_РемизовКЛ_20260614.log
|
||||
- VKC_PR_M04_1_cliAdvancedVMVkCloud_РемизовКЛ_20260614.png
|
||||
- VKC_PR_M04_1_VmImage_РемизовКЛ_20260614.log
|
||||
- VKC_PR_M04_1_ImageVkcloud_РемизовКЛ_20260614.png
|
||||
status: final
|
||||
---
|
||||
|
||||
# Отчет по практической демонстрации
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Освоить управление облачными ресурсами VK Cloud с помощью **OpenStack CLI**.
|
||||
Научиться выполнять основные операции: аутентификация через RC‑файл, создание и удаление виртуальных машин, создание снапшотов (образов) из работающей ВМ.
|
||||
Закрепить понимание преимуществ командной строки перед веб‑консолью для автоматизации и повторяемости действий.
|
||||
|
||||
## 2. Что было прочитано перед выполнением
|
||||
|
||||
- **Документ:** 3-Конспект лекций - VK 1.md
|
||||
- **Раздел/тема:** Модуль 4 «Инструменты управления (CLI и SDK)», тема 4.1 «OpenStack CLI»
|
||||
- **Ключевые понятия:**
|
||||
- RC‑файл (OpenStack RC File) и переменные окружения
|
||||
- Аутентификация через `openstack token issue`
|
||||
- Команды: `openstack server create`, `openstack server stop`, `openstack server image create`, `openstack server start`
|
||||
- Параметры: `--flavor`, `--image`, `--key-name`, `--network`, `--security-group`, `--wait`
|
||||
- Создание консистентного снапшота (остановка ВМ перед созданием образа)
|
||||
|
||||
## 3. Ход выполнения
|
||||
|
||||
### Демонстрация 4.1: Работа с OpenStack CLI
|
||||
|
||||
#### Этап 1. Подготовка окружения (установка и аутентификация)
|
||||
|
||||
**Действие:**
|
||||
Скачал RC‑файл для своего проекта из веб‑консоли VK Cloud. Загрузил переменные окружения и проверил аутентификацию.
|
||||
|
||||
```bash
|
||||
source ./mcs3340419193-openrc.sh
|
||||
# Ввод пароля от аккаунта VK Cloud
|
||||
|
||||
openstack token issue
|
||||
```
|
||||
|
||||
**Результат:**
|
||||
Токен успешно получен, отображаются параметры `expires`, `project_id`, `user_id`.
|
||||
*Лог: начальная часть [[VKC_PR_M04_1_VMCreate_РемизовКЛ_20260614.log]]*
|
||||
|
||||
---
|
||||
|
||||
#### Этап 2. Создание виртуальной машины через CLI
|
||||
|
||||
**Действие:**
|
||||
Создал ВМ с именем `cli-advanced-vm`, используя готовые идентификаторы образа, сети, ключа и группы безопасности.
|
||||
|
||||
```bash
|
||||
openstack server create \
|
||||
--flavor df3c499a-044f-41d2-8612-d303adc613cc \
|
||||
--image "ubuntu-22-202602051629.gite7a38aaf" \
|
||||
--key-name my-first-vm-ie9Ev9Cc \
|
||||
--network "ec8c610e-6387-447e-83d2-d2c541e88164" \
|
||||
--security-group ssh \
|
||||
cli-advanced-vm
|
||||
```
|
||||
|
||||
**Результат:**
|
||||
ВМ перешла в статус `BUILD`, а затем (после завершения создания) – в `ACTIVE`.
|
||||
В выводе команды отобразились параметры: `id`, `flavor`, `image`, `security_groups`, `adminPass` (не использовался, так как доступ по SSH‑ключу).
|
||||
|
||||
![[VKC_PR_M04_1_cliAdvancedVMVkCloud_РемизовКЛ_20260614.png]]
|
||||
*Скриншот: информация о созданной ВМ `cli-advanced-vm` в веб‑консоли VK Cloud.*
|
||||
|
||||
**Полный лог создания:** [[VKC_PR_M04_1_VMCreate_РемизовКЛ_20260614.log]]
|
||||
|
||||
---
|
||||
|
||||
#### Этап 3. Создание снапшота (образа) из работающей ВМ
|
||||
|
||||
**Действие:**
|
||||
Для получения консистентного образа сначала остановил ВМ, затем создал образ `my-custom-image`, дождался завершения (`--wait`), проверил список образов и снова запустил ВМ.
|
||||
|
||||
```bash
|
||||
openstack server stop cli-advanced-vm
|
||||
|
||||
openstack server image create \
|
||||
--name my-custom-image \
|
||||
--wait \
|
||||
cli-advanced-vm
|
||||
|
||||
openstack image list | grep my-custom-image
|
||||
|
||||
openstack server start cli-advanced-vm
|
||||
```
|
||||
|
||||
**Результат:**
|
||||
- ВМ остановлена (в логах видно, что перед созданием образа ВМ находилась в статусе `SHUTOFF`).
|
||||
- Образ `my-custom-image` успешно создан со статусом `active`, размер 10 ГБ, тип `snapshot`.
|
||||
- В списке образов появилась запись с ID `84104fb4-7ee8-4472-aa1d-ecfe0b7b16d6`.
|
||||
- ВМ запущена обратно.
|
||||
|
||||
![[VKC_PR_M04_1_ImageVkcloud_РемизовКЛ_20260614.png]]
|
||||
*Скриншот: созданный образ `my-custom-image` в веб‑консоли VK Cloud.*
|
||||
|
||||
**Лог создания образа:** [[VKC_PR_M04_1_VmImage_РемизовКЛ_20260614.log]]
|
||||
|
||||
## 4. Ошибки и исправления
|
||||
|
||||
| Проблема | Решение |
|
||||
| :--- | :--- |
|
||||
| Нет ошибок в ходе выполнения. Все команды отработали штатно. | – |
|
||||
|
||||
*Примечание:* В процессе работы использовалась среда `nix-shell`, в которой OpenStack CLI был предустановлен. Для обычной системы потребовалась бы установка через `pip install python-openstackclient`.
|
||||
|
||||
## 5. Критерии успеха
|
||||
|
||||
- [x] Выполнена аутентификация через RC‑файл, получен токен.
|
||||
- [x] Создана ВМ с именем `cli-advanced-vm` через CLI с указанием всех необходимых параметров (flavor, image, key, network, security group).
|
||||
- [x] ВМ появилась в веб‑консоли, отображается её IP‑адрес.
|
||||
- [x] ВМ остановлена, из неё создан снапшот `my-custom-image`.
|
||||
- [x] Снапшот отобразился в списке образов (команда `openstack image list`).
|
||||
- [x] ВМ запущена обратно.
|
||||
|
||||
## 6. Приложенные доказательства
|
||||
|
||||
| Файл | Тип | Что подтверждает |
|
||||
| ----------------------------------------------------------------- | ------------- | ----------------------------------------------------- |
|
||||
| VKC_PR_M04_1_VMCreate_РемизовКЛ_20260614.log | Текстовый лог | Аутентификация, создание ВМ `cli-advanced-vm` |
|
||||
| VKC_PR_M04_1_cliAdvancedVMVkCloud_РемизовКЛ_20260614.png | Скриншот | Детали созданной ВМ в веб‑консоли |
|
||||
| VKC_PR_M04_1_VmImage_РемизовКЛ_20260614.log | Текстовый лог | Остановка ВМ, создание образа, запуск ВМ |
|
||||
| VKC_PR_M04_1_ImageVkcloud_РемизовКЛ_20260614.png | Скриншот | Готовый образ `my-custom-image` в веб‑консоли |
|
||||
|
||||
## 7. Самопроверка
|
||||
|
||||
- **Что получилось:**
|
||||
Уверенно выполнил все команды OpenStack CLI: аутентификация, создание ВМ, управление состоянием (stop/start), создание образа. Понял, как связаны идентификаторы (flavor, image, network) и как их узнать через `openstack flavor list`, `openstack image list`, `openstack network list`. Создание снапшота прошло без проблем – образ появился и готов к использованию.
|
||||
|
||||
- **Что осталось непонятным:**
|
||||
В выводе `openstack server create` присутствует поле `adminPass`. Не вполне ясно, при каких условиях оно используется (вероятно, для образов с парольной аутентификацией). В данном случае доступ осуществляется по SSH‑ключу, поэтому этот пароль не применяется.
|
||||
|
||||
- **Что можно улучшить:**
|
||||
В будущем стоит попробовать создать образ без остановки ВМ (с опцией `--force`, если она поддерживается) – для сценариев, где недоступен downtime. Также полезно освоить команду `openstack server add security group` для динамического изменения политик безопасности.
|
||||
|
||||
## 8. Краткий вывод
|
||||
|
||||
Практическая работа показала, что **OpenStack CLI** является мощным и гибким инструментом для управления облачной инфраструктурой VK Cloud. В отличие от веб‑консоли, командная строка позволяет выполнять операции быстрее, легко встраивать их в скрипты и системы автоматизации (Ansible, CI/CD). Создание снапшота через CLI (`openstack server image create`) даёт возможность быстро создавать «золотые образы» для последующего развёртывания идентичных ВМ.
|
||||
|
||||
**Ключевой вывод:**
|
||||
Освоение CLI – обязательный шаг на пути от ручного администрирования к профессиональной автоматизации и практике Infrastructure as Code (IaC).
|
||||
@@ -0,0 +1,207 @@
|
||||
---
|
||||
course_code: VKCLOUD-80
|
||||
artifact_type: PR
|
||||
module: 4
|
||||
task_code: 2
|
||||
task_title: Работа с API через curl
|
||||
student_fio: Ремизов Кирилл Львович
|
||||
date: 2026-06-14
|
||||
source_docs:
|
||||
- 3-Конспект лекций - VK 1.md
|
||||
- 4-Практические работы - VK -1.md
|
||||
commands_used:
|
||||
- curl (POST, GET)
|
||||
- jq
|
||||
- export (переменная TOKEN)
|
||||
attached_files:
|
||||
- VKC_PR_M04_2_TokenGet_РемизовКЛ_20260614.log
|
||||
- VKC_PR_M04_2_VMCreate_РемизовКЛ_20260614.log
|
||||
- VKC_PR_M04_2_VMList_РемизовКЛ_20260614.log
|
||||
- VKC_PR_M04_2_APIVMCreate_РемизовКЛ_20260614.png
|
||||
status: final
|
||||
---
|
||||
|
||||
# Отчет по практической демонстрации
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Освоить работу с **REST API** облачной платформы VK Cloud с помощью инструмента `curl`.
|
||||
Научиться выполнять аутентификацию через API, получать токен, отправлять GET-запросы для получения информации о ресурсах (flavors, сети, образы) и POST-запросы для создания виртуальных машин.
|
||||
Закрепить понимание низкоуровневого взаимодействия с облаком, лежащего в основе всех SDK и CLI-инструментов.
|
||||
|
||||
## 2. Что было прочитано перед выполнением
|
||||
|
||||
- **Документ:** 3-Конспект лекций - VK 1.md
|
||||
- **Раздел/тема:** Модуль 4 «Инструменты управления (CLI и SDK)», тема 4.2 «API и SDK»
|
||||
- **Ключевые понятия:**
|
||||
- REST API, HTTP-методы (GET, POST), эндпоинты сервисов (compute, network, image, identity)
|
||||
- Аутентификация через токен (запрос к `/v3/auth/tokens`, заголовок `X-Subject-Token`)
|
||||
- Формат JSON для тела запроса и ответа
|
||||
- Использование `curl` с параметрами `-X`, `-H`, `-d`
|
||||
- Фильтрация вывода с помощью `jq` для удобства чтения
|
||||
- Параметры создания ВМ: `imageRef`, `flavorRef`, `networks`, `key_name`
|
||||
|
||||
## 3. Ход выполнения
|
||||
|
||||
### Демонстрация 4.2: Работа с API через curl
|
||||
|
||||
#### Этап 1. Получение токена аутентификации
|
||||
|
||||
**Действие:**
|
||||
Отправил POST-запрос к эндпоинту Identity API (`https://cloud.vk.com/identity/v3/auth/tokens`) с JSON-телом, содержащим логин, пароль и ID проекта. Пароль был введён открыто в команде (для учебных целей), в реальной среде следует использовать переменные окружения.
|
||||
|
||||
```bash
|
||||
curl -i -X POST https://cloud.vk.com/identity/v3/auth/tokens \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"auth": {
|
||||
"identity": {
|
||||
"methods": ["password"],
|
||||
"password": {
|
||||
"user": {
|
||||
"name": "remizov.kirill2005@yandex.ru",
|
||||
"password": "#*Woron210105#*",
|
||||
"domain": {"name": "users"}
|
||||
}
|
||||
}
|
||||
},
|
||||
"scope": {
|
||||
"project": {
|
||||
"id": "5aa354d05172439abcc5bfc3f682da49"
|
||||
}
|
||||
}
|
||||
}
|
||||
}'
|
||||
```
|
||||
|
||||
**Результат:**
|
||||
Сервер вернул HTTP/2 201, в заголовке `X-Subject-Token` был получен токен. Токен был сохранён в переменную окружения `$TOKEN` для использования в последующих запросах.
|
||||
|
||||
```bash
|
||||
TOKEN="gAAAAABqLp2hueJVBdeWrra1M4DMnQEpGmVJFJu9v4yliHJJq7h8lauGD0DYY-zX4R4ICO1BmKKGZuwmQpZcdeivjejjahJETBLHiQi-C0f3OCyMGfUGzTI0n2Izr-P0gop5q7PyEg9jE1vekbV1nKOhmJgEkGsrHwANy68uCG8MqcaCK8IVPSo"
|
||||
```
|
||||
|
||||
*Полный лог: [[VKC_PR_M04_2_TokenGet_РемизовКЛ_20260614.log]]*
|
||||
|
||||
---
|
||||
|
||||
#### Этап 2. Получение информации о конфигурациях (flavors, сети, образы)
|
||||
|
||||
**Действие:**
|
||||
Используя полученный токен, отправил GET-запросы к API Compute (`/flavors/detail`), Network (`/v2.0/networks`) и Image (`/v2/images`), чтобы определить идентификаторы необходимых ресурсов для создания ВМ. Для удобства вывода использовал `jq`.
|
||||
|
||||
```bash
|
||||
# 1. Список flavors (типов ВМ) с фильтрацией по размеру диска > 0
|
||||
curl -s -X GET "https://infra.mail.ru:8774/v2.1/5aa354d05172439abcc5bfc3f682da49/flavors/detail" \
|
||||
-H "X-Auth-Token: $TOKEN" | jq '.flavors[] | {name: .name, id: .id, disk: .disk} | select(.disk > 0)'
|
||||
|
||||
# 2. Список сетей
|
||||
curl -s -X GET "https://infra.mail.ru:9696/v2.0/networks" \
|
||||
-H "X-Auth-Token: $TOKEN" \
|
||||
-H "Content-Type: application/json" | jq '.networks[] | {id, name}'
|
||||
|
||||
# 3. Список образов
|
||||
curl -s -X GET "https://infra.mail.ru:9292/v2/images" \
|
||||
-H "X-Auth-Token: $TOKEN" \
|
||||
-H "Content-Type: application/json" | jq '.images[] | {id, name}'
|
||||
```
|
||||
|
||||
**Результат:**
|
||||
- Выбрал flavor `Basic-1-2-20` (id `25ae869c-be29-4840-8e12-99e046d2dbd4`) – 1 vCPU, 2 ГБ RAM, 20 ГБ диск.
|
||||
- Сеть `internet` (id `ec8c610e-6387-447e-83d2-d2c541e88164`).
|
||||
- Образ `ubuntu-24-202602051634.gite7a38aaf` (id `b812255f-7b5f-4fd6-bad4-8b24265dc076`).
|
||||
|
||||
*Полный лог: [[VKC_PR_M04_2_VMCreate_РемизовКЛ_20260614.log]]*
|
||||
|
||||
---
|
||||
|
||||
#### Этап 3. Создание ВМ через API
|
||||
|
||||
**Действие:**
|
||||
Отправил POST-запрос к API Compute (`/servers`) с JSON-телом, содержащим имя ВМ, ссылки на образ, flavor, сеть и имя SSH-ключа.
|
||||
|
||||
```bash
|
||||
curl -s -X POST "https://infra.mail.ru:8774/v2.1/5aa354d05172439abcc5bfc3f682da49/servers" \
|
||||
-H "X-Auth-Token: $TOKEN" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"server": {
|
||||
"name": "api-created-vm",
|
||||
"imageRef": "b812255f-7b5f-4fd6-bad4-8b24265dc076",
|
||||
"flavorRef": "25ae869c-be29-4840-8e12-99e046d2dbd4",
|
||||
"networks": [{"uuid": "ec8c610e-6387-447e-83d2-d2c541e88164"}],
|
||||
"key_name": "my-first-vm-ie9Ev9Cc"
|
||||
}
|
||||
}'
|
||||
```
|
||||
|
||||
**Результат:**
|
||||
Сервер вернул JSON с информацией о создаваемой ВМ: присвоен ID `8c3f3134-560c-4558-9060-c3c6731792a8`, сгенерирован временный пароль администратора `adminPass` (не использовался, так как доступ по SSH-ключу). Статус ВМ на момент ответа – `BUILD`.
|
||||
|
||||
![[VKC_PR_M04_2_APIVMCreate_РемизовКЛ_20260614.png]]
|
||||
*Скриншот: подтверждение создания ВМ через API (вывод команды curl).*
|
||||
|
||||
---
|
||||
|
||||
#### Этап 4. Проверка списка ВМ
|
||||
|
||||
**Действие:**
|
||||
Выполнил GET-запрос к списку серверов до и после создания, чтобы убедиться, что новая ВМ появилась.
|
||||
|
||||
```bash
|
||||
# До создания (список пуст)
|
||||
curl -s -X GET "https://infra.mail.ru:8774/v2.1/5aa354d05172439abcc5bfc3f682da49/servers" \
|
||||
-H "X-Auth-Token: $TOKEN" | jq '.servers'
|
||||
|
||||
# После создания (появилась api-created-vm)
|
||||
curl -s -X GET "https://infra.mail.ru:8774/v2.1/5aa354d05172439abcc5bfc3f682da49/servers" \
|
||||
-H "X-Auth-Token: $TOKEN" | jq '.servers'
|
||||
```
|
||||
|
||||
**Результат:**
|
||||
В списке серверов появилась запись с именем `api-created-vm` и соответствующим ID.
|
||||
|
||||
*Полный лог: [[VKC_PR_M04_2_VMList_РемизовКЛ_20260614.log]]*
|
||||
|
||||
## 4. Ошибки и исправления
|
||||
|
||||
| Проблема | Решение |
|
||||
| :--- | :--- |
|
||||
| Нет ошибок в ходе выполнения. Все запросы отработали штатно (HTTP 201, 200). | – |
|
||||
|
||||
*Примечание:* При работе с API важно внимательно формировать JSON-тело и правильно указывать эндпоинты (порты: 8774 – compute, 9696 – network, 9292 – image). Использование `jq` существенно упростило анализ ответов.
|
||||
|
||||
## 5. Критерии успеха
|
||||
|
||||
- [x] Получен токен аутентификации через POST-запрос к Identity API, токен сохранён в переменную.
|
||||
- [x] Выполнены GET-запросы к API для получения списков flavors, сетей, образов; идентификаторы использованы для создания ВМ.
|
||||
- [x] Создана ВМ с именем `api-created-vm` через POST-запрос к Compute API.
|
||||
- [x] После создания ВМ отображается в списке серверов (GET-запрос).
|
||||
- [x] Все операции задокументированы в логах и на скриншоте.
|
||||
|
||||
## 6. Приложенные доказательства
|
||||
|
||||
| Файл | Тип | Что подтверждает |
|
||||
| ----------------------------------------------------------------- | ------------- | ----------------------------------------------------- |
|
||||
| VKC_PR_M04_2_TokenGet_РемизовКЛ_20260614.log | Текстовый лог | Получение токена через API (запрос и ответ) |
|
||||
| VKC_PR_M04_2_VMCreate_РемизовКЛ_20260614.log | Текстовый лог | GET-запросы к flavors, networks, images; создание ВМ |
|
||||
| VKC_PR_M04_2_VMList_РемизовКЛ_20260614.log | Текстовый лог | Список ВМ до и после создания |
|
||||
| VKC_PR_M04_2_APIVMCreate_РемизовКЛ_20260614.png | Скриншот | Вывод команды создания ВМ (успешный ответ) |
|
||||
|
||||
## 7. Самопроверка
|
||||
|
||||
- **Что получилось:**
|
||||
Успешно выполнил все этапы работы с API: аутентификация, получение токена, исследование доступных ресурсов (flavors, образы, сети), создание ВМ через POST-запрос, проверка результата. Понял, как связаны между собой разные сервисы (Identity, Compute, Network, Image) и их эндпоинты. Научился использовать `jq` для фильтрации JSON-ответов.
|
||||
|
||||
- **Что осталось непонятным:**
|
||||
В ответе на создание ВМ приходит поле `adminPass`. В моём случае доступ по SSH-ключу, поэтому этот пароль не используется. Однако не совсем ясно, можно ли его применить для доступа через пароль (вероятно, для образов, где парольная аутентификация разрешена, или для Windows).
|
||||
|
||||
- **Что можно улучшить:**
|
||||
В следующий раз стоит автоматизировать процесс: написать небольшой bash-скрипт, который получает токен, подставляет его в переменные, выполняет создание ВМ и проверяет статус. Также полезно изучить, как обрабатывать пагинацию в ответах API (при большом количестве ресурсов).
|
||||
|
||||
## 8. Краткий вывод
|
||||
|
||||
Практическая работа показала, что **REST API** является фундаментом всех инструментов управления облаком – от CLI до Terraform и SDK. Прямая работа с API через `curl` даёт максимально прозрачное понимание того, какие данные передаются и какие эндпоинты вызываются при каждом действии. Это особенно полезно при отладке, написании собственных скриптов или интеграции с системами, для которых нет готовых библиотек.
|
||||
|
||||
**Ключевой вывод:**
|
||||
Освоение API-взаимодействия – важный шаг на пути к глубокому пониманию облачных технологий и возможности автоматизации «на уровне протокола». Теперь я могу не только пользоваться готовыми утилитами, но и в любой момент «заглянуть под капот» и выполнить нужное действие напрямую через HTTP-запрос.
|
||||
Reference in new issue
Block a user