# Минимальная цепочка для одной ВМ (PROD)

Пример создаёт одну ВМ и только необходимые для неё услуги:

```text
организация (создана вручную в ЛК)
  -> vDC
  -> Edge с routed-сетью
  -> выделение IP организации (минимум 3)
  -> SNAT
  -> vApp
  -> одна ВМ
```

Штурвал, базы данных и приложения в примере отсутствуют. Он основан на успешно
запущенной в PROD конфигурации `VM_TF_Docs`, а не на `fullpipe_chain`.
Провайдер зафиксирован на PROD-версии `1.5.0`.

## Важное условие: организация создаётся вручную

До запуска создайте организацию **«Организация в Cloud Director»** через ЛК. Terraform
не создаёт и не удаляет организацию: `nubes_vc_vdc` получает её имя или UUID через
`organization`.

В ЛК проверьте, что организации доступны выбранные resource pool, Provider VDC,
storage policy и IP space. Значения из примера (`msk1`, `Intel Cascade Lake 3.1`,
`SSD SDS`) подтверждены для использованного PROD-пула; для другого пула их нужно
заменить на значения из ЛК.

## Почему выделяется 3 IP

Для проверенной цепочки с одной ВМ минимальное значение `org_vip_count` — **3**.
При значении 2 API сообщил, что свободных IP — 0, а для операции требуется ещё 1;
при значении 3 развёртывание ВМ запустилось. Поэтому в этом примере не уменьшайте
квоту до 2, даже если из дополнительных потребителей IP оставлена только одна ВМ.

`org_vip_count` задаёт количество IP в выбранном `ip_space_name` на организации —
это не количество адресов, которое сама ВМ получит. Точное внутреннее распределение
резервов платформой эта конфигурация не показывает. Если другие услуги используют
адреса из того же IP space или там уже есть занятые адреса, квоту нужно увеличить.
Список услуг со статусами `running`/`suspended` сам по себе не показывает, какие IP
заняты.

В конфигурации VM установлен `same_snat = true`: согласно PROD-схеме при этом для ВМ
создаётся собственный внешний IP. SNAT на Edge также задаётся отдельным ресурсом,
как в проверенной цепочке.

## Подготовка параметров

1. Скопируйте шаблоны:

   ```bash
   cp terraform.tfvars.example terraform.tfvars
   cp secrets.auto.tfvars.example secrets.auto.tfvars
   ```

2. В `secrets.auto.tfvars` замените заглушку на PROD API token из ЛК → Профиль →
   Токены → «Технический». Не присылайте и не коммитьте этот файл.
3. В `terraform.tfvars` замените:
   - `organization` на имя или UUID вручную созданной организации;
   - `ip_space_name` на точное имя IP space из ЛК;
   - `vm_user_public_key` на содержимое вашего `~/.ssh/id_ed25519.pub`;
   - `vm_access_ip_list` на доверенный публичный IP/CIDR для входящего доступа.
4. Убедитесь, что имена vDC, Edge, vApp и ВМ уникальны в организации. Не оставляйте
   значения-заглушки `REPLACE_WITH_...`.
5. Если выбранный resource pool отличается от проверенного PROD-пула, замените
   `vdc_network_provider`, `vdc_provider_vdc`, `vdc_storage_config`, DNS и routed subnet
   на значения, допустимые в ЛК. Routed subnet `/24` не должен пересекаться с другой сетью.

Все переменные и значения по умолчанию прокомментированы в `variables.tf` и
`terraform.tfvars.example`. Параметры ресурсов сверены с PROD YAML-схемами.

## Запуск

Команды выполняет владелец инфраструктуры; `apply` в этом примере не запускался:

```bash
terraform init
terraform validate
terraform plan
```

Проверьте план: ожидаются шесть услуг — vDC, Edge, выделение IP на организации,
SNAT, vApp и ВМ. Убедитесь, что в плане нет неожиданных изменений уже существующих
услуг. Только после проверки владелец запускает:

```bash
terraform apply
```

После завершения:

```bash
terraform output vm_state_flat
```

`externalConnect` — внешний адрес ВМ, `internalConnect` — адрес в routed-сети,
`fqdn` — DNS-имя, если платформа его вернула.

## Параметры ВМ и операции

- Образ `Ubuntu_22-20G` включает базовый диск 20 GB; `vm_disk = 128` задаёт
  **дополнительный** диск.
- `vm_access_port_list` разрешает только заданные порты. `vm_access_ip_list` ограничивает
  адреса-источники; не оставляйте доступ SSH открытым для `0.0.0.0/0`, если это не требуется.
- `git_revision` оставлен `null` при создании. Новое значение этого маркера запускает
  redeploy при последующем Update.
- `reconcile_trigger` также оставлен `null` при создании. Новое значение запускает
  reconcile при Update; при Create reconcile не выполняется.
- В проверке PROD от 17.10.2026 файл-маркер в `/home/ubuntu` отсутствовал после redeploy.
  Считайте локальные данные ВМ потенциально теряемыми при redeploy и храните важные данные
  вне системного диска.

## Состав файлов

| Файл | Назначение |
|---|---|
| `versions.tf` | Версия Terraform и PROD-провайдера |
| `provider.tf` | Подключение к PROD API |
| `variables.tf` | Типы, значения по умолчанию и пояснения к входным переменным |
| `vdc.tf` | Виртуальный датацентр |
| `edge.tf` | Edge и routed-сеть |
| `network.tf` | Квота IP организации и SNAT |
| `vm.tf` | vApp и одна ВМ |
| `outputs.tf` | Идентификаторы услуг и состояние ВМ |
| `terraform.tfvars.example` | Несекретные значения и параметры примера |
| `secrets.auto.tfvars.example` | Шаблон локального файла для API token |