Files
CloudRouterAdvanced/docs/changes/2026-09-06-provider-auth-wiring-plan.md
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

4.9 KiB
Raw Permalink Blame History

План внедрения: подключение provider "vkcs" и безопасная передача PROD-credentials

Дата: 2026-09-06

Проблема

При подготовке к PROD-развёртыванию (только Terraform, без Ansible — см. project-память) обнаружено: в terraform/ вообще отсутствует блок provider "vkcs" {}. Переменные username/password/project_id/region были объявлены в variables.tf, но нигде не использовались (grep — 0 совпадений) — т.е. развёртывание не смогло бы аутентифицироваться независимо от способа передачи credentials.

Дополнительно: провайдер vkcs (в отличие от классического OpenStack-провайдера) не имеет задокументированной автоматической поддержки OS_* переменных окружения (проверено локально через terraform providers schema -json — только access_token/OS_AUTH_TOKEN упомянуты явно) — значит, auth_url, username, password, project_id, region, user_domain_name нужно явно передавать через сам provider-блок.

Пользователь передал openrc.sh для сервисного аккаунта (OS_AUTH_URL, OS_PROJECT_ID, OS_USERNAME/OS_PASSWORD, OS_USER_DOMAIN_NAME=service-users, OS_REGION_NAME=RegionOne) и попросил проверить схему "взять terraform.tfvars-шаблон за основу + на лету добавить нужные параметры".

Решение

  1. Добавить provider "vkcs" {} в terraform/versions.tf, подключив все 6 auth-переменных.
  2. Добавить недостающие переменные auth_url, user_domain_name; исправить некорректный дефолт region (было "ME1" — это код availability zone, а не OpenStack-регион; правильное значение — "RegionOne", ранее это не проявлялось, т.к. переменная не использовалась).
  3. Не вписывать реальные credentials в закоммиченный terraform.tfvars — вместо этого задокументировать и использовать паттерн *.auto.tfvars (Terraform подхватывает такие файлы автоматически поверх terraform.tfvars, без изменения самого шаблона): добавить *.auto.tfvars/*.auto.tfvars.json/terraform.tfvars.local в .gitignore, создать terraform/prod.auto.tfvars.example (без секретов, только маппинг полей openrc.sh → переменные).
  4. Проверить всю цепочку реальными credentials из openrc.sh: во временной директории вне репозитория (не в git) собрать overlay-файл с реальными значениями, прогнать terraform init + terraform plan (read-only, ничего не создаётся) против настоящего VK Cloud API — убедиться, что аутентификация и резолвинг data source'ов (vkcs_images_image, vkcs_networking_network.extnet, vkcs_networking_secgroup.default) работают. Временную директорию с секретами удалить сразу после проверки.
  5. Дополнить terraform/tests/test_terraform_delivery.py: provider-блок реально подключает все auth-переменные (regression guard на "orphaned variables"); terraform.tfvars не содержит auth_url/user_domain_name; *.auto.tfvars в .gitignore; prod.auto.tfvars.example не игнорируется.
  6. Обновить README.md/docs/QUICKSTART.md.
  7. Summary-документ по завершении.

Верификация

  • terraform fmt -check -recursive.
  • Реальный terraform init + terraform validate (локальный provider-mirror) — синтаксическая/схемная корректность provider-блока.
  • Реальный terraform init + terraform plan с настоящими PROD credentials (во временной, не-репозиторной директории) — подтверждена успешная аутентификация и резолвинг data sources; временная директория с секретами удалена сразу после проверки, секреты нигде не закоммичены.
  • venv/bin/pytest terraform/tests -v — весь сьют зелёный.