46 lines
2.5 KiB
Markdown
46 lines
2.5 KiB
Markdown
# Ресурсы-модификаторы: аллокация 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
|
||
```
|