Files
CloudRouterAdvanced/docs/QUICKSTART.md
T
ayurishchevandClaude Sonnet 5 8886c1baad Fix real-deployment blockers and scope down to router-only VMs
Confirmed working against a real VK Cloud PROD deployment (3 routers,
19 resources, apply succeeded end to end). Fixes found along the way:

- provider "vkcs" was never configured (versions.tf) - username/password/
  project_id/region were declared but wired to nothing; added auth_url and
  user_domain_name to complete it.
- Nova keypairs are per-user, not per-project - added an optional
  vkcs_compute_keypair resource (var.ssh_public_key) so Terraform can
  register a keypair under the deploying service account itself.
- router_priv_port used a hand-computed fixed_ip offset that collided with
  VKCS's own auto-created service ports on each network (observed: a
  "network:dns" port) - now left unset so Neutron's IPAM auto-assigns,
  which is collision-free by construction.
- vkcs_compute_instance set image_id at the top level while also booting
  from a volume via block_device - the provider docs say not to do this;
  Nova echoes back a sentinel string for image_id on a volume-booted
  server, which Terraform read as drift on a ForceNew attribute and
  wanted to destroy+recreate every already-created instance on every
  subsequent plan.
- private_network_cidrs bumped from /29 to /28 - too tight once the
  platform's own reserved ports are accounted for.

Also removed the priv_srv_01/02/03 demo instances and the LAN network/
security group only they used - this deployment provisions router VMs
only, confirmed with the user.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011hXR2ftXZZhJ4Y3XuSoR8r
2026-09-07 08:55:15 +03:00

6.0 KiB
Raw Blame History

Quick Start (самостоятельное развёртывание)

Пошаговая инструкция для самостоятельного развёртывания сценария из этого репозитория на VK Cloud.

1. Подготовка

  • Аккаунт VK Cloud с включённым API/CLI-доступом, project_id.
  • SSH-ключ загружен в VK Cloud (имя ключа понадобится в terraform.tfvars).
  • Установлены terraform (≥1.13) и ansible.

2. Клонировать репозиторий и задать credentials

terraform/terraform.tfvars — это закоммиченный обезличенный шаблон, реальные credentials в него вписывать не нужно. Вместо этого скопируйте terraform/prod.auto.tfvars.example в terraform/prod.auto.tfvars (этот файл в .gitignore, никогда не попадёт в git) и впишите туда реальные значения:

auth_url         = "https://infra.mail.ru:35357/v3/"
username         = "<ваш VK Cloud логин или сервисный аккаунт>"
password         = "<пароль>"
project_id       = "<ваш project_id>"
region           = "RegionOne"
user_domain_name = "users"   # или "service-users" для сервисного аккаунта svc-*

Terraform подхватывает *.auto.tfvars автоматически, в дополнение к terraform.tfvars — ничего больше настраивать не нужно. Если у вас есть openrc.sh для сервисного аккаунта — соответствие полей: OS_AUTH_URL→auth_url, OS_USERNAME→username, OS_PASSWORD→password, OS_PROJECT_ID→project_id, OS_REGION_NAME→region, OS_USER_DOMAIN_NAME→user_domain_name.

В самом terraform.tfvars дополнительно отредактируйте:

ssh_key_name = "<имя загруженного SSH-ключа>"

private_network_cidrs = [
  "10.90.0.0/28",
  "10.90.0.16/28",
]

private_network_cidrs — обязательная переменная без значения по умолчанию: один CIDR-префикс на каждую приватную сеть, к которой будут подключены интерфейсы роутеров (один префикс = одна общая сеть = один приватный интерфейс на роутер). Автоматической нарезки нет — префиксы не должны пересекаться. Берите /28, а не /29: VKCS сам создаёт служебные порты на каждой сети (замечен network:dns), которые тоже расходуют адреса из пула — /29 (5 адресов) на практике оказался слишком тесным.

UUID системной Security Group default (уникален для каждого проекта VK Cloud) вычисляется автоматически через data.vkcs_networking_secgroup, вручную задавать не нужно. Переменная default_security_group_id — override только на крайний случай (нестандартное имя/SDN группы в проекте), не для обычного использования.

3. (Опционально) масштабирование

Число роутеров и приватных сетей меняется правкой router_count/private_network_cidrs прямо в terraform.tfvars (сейчас там уже реальные значения этого PROD-деплоя — 3 роутера). Значение из terraform.tfvars всегда перекрывает TF_VAR_* (у tfvars-файла более высокий приоритет), так что TF_VAR_router_count сработает, только если убрать router_count из terraform.tfvars. Разовый override без правки файла — через -var в командной строке (он перекрывает даже tfvars):

terraform apply -var="router_count=4" -var='private_network_cidrs=["10.90.0.0/28","10.90.0.16/28","10.90.0.32/28"]'

4. Развернуть

cd terraform
terraform init
terraform plan
terraform apply

Каждая ВМ сама донастроит сеть при первой загрузке (network-init.sh.tpl) и перезагрузится.

5. Настроить Ansible

⚠️ Важно: ansible/inventory.ini и роли (base/frr_router/keepalived) пока жёстко рассчитаны на 2 роутера с интерфейсами eth0/eth1 (VRRP-схема) — под новую N-роутерную/N-NIC архитектуру ещё не адаптированы. Для дефолтных значений (router_count=2, 2 записи в private_network_cidrs) впишите реальные wan_ip/lan_ip/GRE/BGP-параметры роутеров в inventory.ini вручную. При масштабировании выше 2 роутеров или интерфейсов Ansible-слой нужно дорабатывать отдельно.

cd ansible
ansible-playbook -i inventory.ini site.yml

6. Проверить

  • SSH на публичные IP роутеров, cat /var/log/network-config.log — лог настройки интерфейсов.
  • ip a, networkctl — убедиться, что eth0 (WAN) и eth1..ethN (приватные) подняты корректно.
  • FRR/strongSwan/keepalived статусы — см. раздел "Under the Hood" в README.md.

Локальная офлайн-проверка поставки (без облака)

terraform/tests/setup-local-terraform.sh
venv/bin/pytest terraform/tests -v