# Ресурсы-модификаторы: аллокация IP на орге + SNAT на шлюзе

Пример показывает два ресурса, которые выполняют операции `modify` над **уже существующими**
услугами (создаются один раз вручную в ЛК):

| Ресурс | Что делает | Параметр операции |
|---|---|---|
| `nubes_vc_org_ip_allocation` | выделяет внешние IP на организации Cloud Director | `vIPConfigure` (replace массива) |
| `nubes_vc_nsxt_snat` | включает/выключает SNAT на сетевом шлюзе периметра | `ipSpaceName` (`no-needed` = выключено) |

## Зачем они нужны

В схеме ресурсов-инстансов (`nubes_vc_org`, `nubes_vc_nsxt`) эти параметры есть только в операции
`modify`, а `create` их не отправляет. Поэтому «одним ресурсом» цепочку не собрать: отдельные
ресурсы нужны, чтобы всё поднималось **в одном `apply`** и в правильном порядке.

## Что нужно заполнить

| Переменная | Где брать |
|---|---|
| `api_token` | ЛК → Профиль → Токены → «Технический» |
| `org_uid` | UUID услуги «Организация в Cloud Director» (из URL карточки услуги в ЛК) |
| `nsxt_uid` | UUID услуги «Сетевой шлюз периметра (Edge)» |
| `ip_space_name` | Имя ipSpace, доступное организации (например `internet-ipv4-v1`) |
| `ip_count` | Сколько внешних IP выделить (например `3`) |

## Порядок и зависимости

`nubes_vc_nsxt_snat` **обязан** зависеть от `nubes_vc_org_ip_allocation`: имя ipSpace берётся из
аллокации организации. В примере это явный `depends_on`.

## Удаление (destroy)

- `nubes_vc_org_ip_allocation` — отправляет обратный `modify` с `count=0` (квота обнуляется);
- `nubes_vc_nsxt_snat` — отправляет `ipSpaceName = "no-needed"` (SNAT выключается).

Если снимать не нужно — поставь `keep_on_destroy = true`.

## Запуск

```bash
terraform init
terraform plan
terraform apply
```