docs(curated): страницы примеров приведены к реальным файлам (versions/provider/variables/outputs), организация по имени, снята пометка «не проверено»
This commit is contained in:
Nail
@@ -1,75 +1,74 @@
|
||||
# Ресурсы-модификаторы: внешние IP организации и SNAT на шлюзе
|
||||
|
||||
> ⚠️ Живым прогоном пока **не проверено**. Описаны ресурсы и порядок применения; выводы о поведении
|
||||
> сделаны по коду провайдера и HAR-записям ЛК.
|
||||
Два ресурса работают с **уже существующими** услугами:
|
||||
|
||||
Два ресурса выполняют операции `modify` над **уже существующими** услугами. Организация Cloud Director
|
||||
и сетевой шлюз периметра создаются один раз **вручную в ЛК** и адресуются по UUID.
|
||||
- `nubes_vc_org_ip_allocation` — выделяет внешние IP на организации;
|
||||
- `nubes_vc_nsxt_snat` — включает SNAT на сетевом шлюзе периметра.
|
||||
|
||||
## `nubes_vc_org_ip_allocation`
|
||||
Эти параметры нельзя задать при создании услуги обычным ресурсом, поэтому они вынесены в отдельные
|
||||
ресурсы: так вся цепочка поднимается одним `apply` и в правильном порядке.
|
||||
|
||||
Выделяет внешние IP на организации (операция `modify`, параметр `vIPConfigure`).
|
||||
Оба ресурса проверены живым прогоном: создание, проверка состояния в ЛК и удаление.
|
||||
|
||||
Полный рабочий пример (vDC + Edge + IP + SNAT) — на странице
|
||||
[«Как развернуть vDC, Edge, внешние IP и SNAT»](../pipeline/vdc_edge_ip_snat.md),
|
||||
файлы — в репозитории `tf_examples`, папка `fullpipe_chain`.
|
||||
|
||||
## `nubes_vc_org_ip_allocation` — внешние IP на организации
|
||||
|
||||
| Атрибут | Тип | Описание |
|
||||
|---|---|---|
|
||||
| `organization` | string, обязательный | Организация: имя из ЛК или её UUID |
|
||||
| `vip_configure` | string (JSON), обязательный | Массив аллокаций: `[{"name":"internet-ipv4-v1","count":"3"}]`. `count` — строка |
|
||||
| `keep_on_destroy` | bool, по умолчанию `false` | Не снимать квоту при `destroy` |
|
||||
|
||||
Порядок ключей и форматирование не важны — сравнение смысловое (важно потому, что `jsonencode` сортирует
|
||||
ключи по алфавиту).
|
||||
|
||||
Снять аллокацию через `vip_configure` **нельзя** (пустой массив отклоняется): для этого удали ресурс —
|
||||
тогда отправится обратный `modify` с `count = "0"`.
|
||||
| `organization` | string, обязательный | Организация: название услуги из ЛК или её UUID |
|
||||
| `vip_configure` | string (JSON), обязательный | Сколько IP выделить: `[{"name":"internet-ipv4-v1","count":"3"}]`. `count` — строкой |
|
||||
| `keep_on_destroy` | bool, по умолчанию `false` | `false` — при удалении квота обнуляется; `true` — остаётся как есть |
|
||||
|
||||
```hcl
|
||||
resource "nubes_vc_org_ip_allocation" "this" {
|
||||
organization = var.organization
|
||||
organization = "organ" # название услуги из ЛК
|
||||
|
||||
vip_configure = jsonencode([
|
||||
{ name = "internet-ipv4-v1", count = "3" }
|
||||
])
|
||||
|
||||
keep_on_destroy = false
|
||||
}
|
||||
```
|
||||
|
||||
Операция имеет **replace-семантику**: массив перезаписывается целиком, поэтому ресурс владеет всей
|
||||
аллокацией организации, а не отдельным элементом.
|
||||
Как это работает:
|
||||
|
||||
При `destroy` по умолчанию отправляется обратный `modify` с `count = "0"` — квота обнуляется.
|
||||
- массив `vip_configure` записывается **целиком**, поэтому ресурс владеет всей аллокацией организации:
|
||||
если нужно поменять количество — меняйте значение и делайте `apply`;
|
||||
- снять аллокацию через пустой массив нельзя — для этого удалите ресурс
|
||||
(`terraform destroy -target=nubes_vc_org_ip_allocation.this`), тогда отправится запрос с `count = "0"`.
|
||||
|
||||
## `nubes_vc_nsxt_snat`
|
||||
|
||||
Включает или выключает SNAT на сетевом шлюзе периметра (операция `modify`, параметр `ipSpaceName`).
|
||||
## `nubes_vc_nsxt_snat` — SNAT на шлюзе
|
||||
|
||||
| Атрибут | Тип | Описание |
|
||||
|---|---|---|
|
||||
| `nsxt_uid` | string, обязательный | UUID услуги «Сетевой шлюз периметра (Edge)» |
|
||||
| `ip_space_name` | string, обязательный | Имя ipSpace для внешнего IP; `no-needed` выключает SNAT |
|
||||
| `keep_on_destroy` | bool, по умолчанию `false` | Не выключать SNAT при `destroy` |
|
||||
| `ip_space_name` | string, обязательный | Имя ipSpace для внешнего IP; значение `no-needed` выключает SNAT |
|
||||
| `keep_on_destroy` | bool, по умолчанию `false` | `false` — при удалении SNAT выключается; `true` — остаётся как есть |
|
||||
|
||||
```hcl
|
||||
resource "nubes_vc_nsxt_snat" "this" {
|
||||
nsxt_uid = var.nsxt_uid
|
||||
nsxt_uid = nubes_vc_nsxt.edge.id # UUID шлюза из этого же конфига
|
||||
ip_space_name = "internet-ipv4-v1"
|
||||
|
||||
depends_on = [nubes_vc_org_ip_allocation.this]
|
||||
}
|
||||
```
|
||||
|
||||
Имя ipSpace должно быть предварительно выделено на организации, поэтому SNAT-ресурс **должен зависеть**
|
||||
от `nubes_vc_org_ip_allocation`. При `destroy` отправляется `ipSpaceName = "no-needed"`.
|
||||
Если шлюз создаётся в этом же конфиге, UUID искать вручную не нужно — используйте
|
||||
`nubes_vc_nsxt.edge.id`. Если шлюз уже существует, UUID виден в карточке услуги в ЛК.
|
||||
|
||||
## Зачем отдельные ресурсы
|
||||
|
||||
В схемах ресурсов-инстансов (`nubes_vc_org`, `nubes_vc_nsxt`) эти параметры присутствуют только в
|
||||
операции `modify` — `create` их не отправляет. Отдельные ресурсы позволяют собрать цепочку
|
||||
**в одном `apply`** и выстроить корректный порядок зависимостей.
|
||||
Имя ipSpace должно быть сначала выделено на организации, поэтому у ресурса есть `depends_on`
|
||||
на аллокацию IP.
|
||||
|
||||
## Импорт
|
||||
|
||||
Оба ресурса импортируются по UUID родительской услуги:
|
||||
Если услуга уже настроена (например, в ЛК вручную), ресурс можно подключить к Terraform:
|
||||
|
||||
```bash
|
||||
terraform import nubes_vc_org_ip_allocation.this organ
|
||||
terraform import nubes_vc_nsxt_snat.this <nsxt_uid>
|
||||
terraform import nubes_vc_org_ip_allocation.this organ # организация: имя или UUID
|
||||
terraform import nubes_vc_nsxt_snat.this <uuid услуги шлюза> # UUID из карточки услуги в ЛК
|
||||
```
|
||||
|
||||
@@ -1,55 +1,96 @@
|
||||
# Как развернуть vDC, Edge, внешние IP и SNAT
|
||||
|
||||
Пошаговая инструкция. Готовые файлы — в репозитории примеров.
|
||||
Пошаговая инструкция. Готовые файлы примера — в репозитории `tf_examples`, папка `fullpipe_chain`.
|
||||
|
||||
Что получится в итоге:
|
||||
|
||||
- виртуальный датацентр (vDC);
|
||||
- сетевой шлюз периметра (Edge);
|
||||
- внешние IP на организации;
|
||||
- SNAT на шлюзе.
|
||||
|
||||
Организацию создайте заранее в ЛК: Terraform её не создаёт.
|
||||
Кластер Штурвал в эту инструкцию не входит — он разворачивается долго, отдельным шагом.
|
||||
|
||||
## 1. Скопируйте пример
|
||||
**Организацию создайте заранее в ЛК** — Terraform её не создаёт и не удаляет.
|
||||
|
||||
## 1. Скачайте пример
|
||||
|
||||
```bash
|
||||
git clone https://gitea.services.ngcloud.ru/Nail/tf_examples.git
|
||||
cd tf_examples/fullpipe_chain
|
||||
```
|
||||
|
||||
Понадобится Terraform 1.5 или новее. Провайдер скачается сам при `terraform init`.
|
||||
|
||||
## 2. Возьмите значения в ЛК
|
||||
|
||||
| Что | Где взять | Пример |
|
||||
| Значение | Где взять | Пример |
|
||||
|---|---|---|
|
||||
| Токен API | ЛК → Профиль → Токены → «Технический» | `eyJhbGciOi...` |
|
||||
| Имя организации | ЛК → услуга «Организация в Cloud Director» → название услуги | `organ` |
|
||||
| Сетевой провайдер | ЛК → vDC → «Сетевой провайдер» | `snb1` |
|
||||
| Provider VDC | ЛК → vDC → «Provider VDC» | `Intel Broadwell 2.4` |
|
||||
| Дисковая политика | ЛК → vDC → доступные дисковые политики | `SATA` |
|
||||
| Имя ipSpace | ЛК → организация → внешние IP | `internet-ipv4-v1` |
|
||||
| `api_token` | ЛК → Профиль → Токены → «Технический» | `eyJhbGciOi...` |
|
||||
| `organization` | ЛК → услуга «Организация в Cloud Director» → название услуги | `organ` |
|
||||
| `vdc_network_provider` | ЛК → создание vDC → «Сетевой провайдер» | `snb1` |
|
||||
| `vdc_provider_vdc` | ЛК → создание vDC → «Provider VDC» | `Intel Broadwell 2.4` |
|
||||
| `vdc_storage_config` | ЛК → создание vDC → доступные дисковые политики | `SATA` |
|
||||
| `ip_space_name` | ЛК → карточка организации → внешние IP | `internet-ipv4-v1` |
|
||||
|
||||
## 3. Заполните значения
|
||||
|
||||
```bash
|
||||
cp terraform.tfvars.example terraform.tfvars
|
||||
nano terraform.tfvars
|
||||
```
|
||||
|
||||
Файл `terraform.tfvars` выглядит так:
|
||||
|
||||
```hcl
|
||||
api_token = "eyJhbGciOi..." # токен из шага 2
|
||||
organization = "organ" # имя организации
|
||||
# Токен из ЛК
|
||||
api_token = "eyJhbGciOi..."
|
||||
|
||||
# Организация из ЛК (создана заранее)
|
||||
organization = "organ"
|
||||
|
||||
# Внешние IP
|
||||
ip_space_name = "internet-ipv4-v1"
|
||||
ip_count = "3"
|
||||
|
||||
# vDC
|
||||
vdc_resource_name = "fullpipe-vdc" # имя услуги в ЛК, любое
|
||||
vdc_network_provider = "snb1" # ЛК → создание vDC → «Сетевой провайдер»
|
||||
vdc_provider_vdc = "Intel Broadwell 2.4" # ЛК → создание vDC → «Provider VDC»
|
||||
vdc_cpu_allocated = 8 # vCPU, шт.
|
||||
vdc_cpu_guaranteed = 0 # резервирование vCPU, %: 0, 50 или 80
|
||||
vdc_mem_allocated = 32 # RAM, ГБ
|
||||
vdc_storage_config = "[{\"name\":\"SATA\",\"size\":\"200\"}]" # политика и размер, ГБ
|
||||
|
||||
# Edge (сетевой шлюз периметра)
|
||||
nsxt_resource_name = "fullpipe-edge" # имя услуги в ЛК, любое
|
||||
nsxt_vdc_type = "vdc" # родитель: vdc или vdcGroup
|
||||
nsxt_need_enable_avi = true # балансировщик AVI (ALB)
|
||||
nsxt_virtual_services_count = 3 # виртуальных сервисов AVI: 1..4 (Штурвал: не меньше 3)
|
||||
nsxt_ip_addr_pool = "10.10.102.0/24" # пул адресов routed-сети, маска /24
|
||||
nsxt_main_dns = "81.22.46.22" # основной DNS
|
||||
nsxt_second_dns = "185.247.187.77" # второй DNS
|
||||
```
|
||||
|
||||
Описание всех параметров — в `variables.tf`. `terraform.tfvars` с токеном никому не передавайте
|
||||
и не коммитьте в git.
|
||||
|
||||
## 4. Выполните команды
|
||||
|
||||
```bash
|
||||
terraform init # один раз — скачает провайдер
|
||||
terraform plan # покажет, что будет создано
|
||||
terraform plan # покажет, что будет создано: 4 ресурса
|
||||
terraform apply # создаст (подтвердить: yes)
|
||||
```
|
||||
|
||||
## 5. Проверьте результат
|
||||
|
||||
- в ЛК появились виртуальный датацентр и сетевой шлюз;
|
||||
- на организации выделены внешние IP;
|
||||
- на шлюзе включён SNAT;
|
||||
- повторный `terraform plan` изменений не показывает.
|
||||
```bash
|
||||
terraform output # UUID и имена созданных услуг
|
||||
```
|
||||
|
||||
И в ЛК: появились vDC и Edge, на организации выделены внешние IP, на шлюзе включён SNAT.
|
||||
Повторный `terraform plan` должен показать `No changes`.
|
||||
|
||||
## 6. Удаление
|
||||
|
||||
@@ -57,14 +98,21 @@ terraform apply # создаст (подтвердить: yes)
|
||||
terraform destroy
|
||||
```
|
||||
|
||||
SNAT выключается, квота IP обнуляется, затем удаляются шлюз и vDC. Организация не удаляется.
|
||||
Порядок обратный: SNAT выключается, квота внешних IP обнуляется, затем удаляется шлюз,
|
||||
а vDC приостанавливается (данные сохраняются). **Организация не удаляется.**
|
||||
|
||||
## Файлы примера
|
||||
|
||||
| Файл | Что делает |
|
||||
|---|---|
|
||||
| `main.tf` | провайдер и переменные |
|
||||
| `versions.tf` | версия Terraform и провайдера Nubes |
|
||||
| `provider.tf` | подключение к API (токен, адрес) |
|
||||
| `variables.tf` | все параметры с описанием |
|
||||
| `vdc.tf` | виртуальный датацентр |
|
||||
| `edge.tf` | сетевой шлюз периметра (Edge) |
|
||||
| `modifiers.tf` | внешние IP на организации + SNAT на шлюзе |
|
||||
| `terraform.tfvars.example` | шаблон значений из ЛК |
|
||||
| `outputs.tf` | UUID и имена созданных услуг |
|
||||
| `terraform.tfvars.example` | шаблон значений (копируется в `terraform.tfvars`) |
|
||||
|
||||
Подробнее про два последних ресурса — на странице
|
||||
[«Ресурсы-модификаторы (IP организации, SNAT)»](../modifiers/org_ip_and_snat.md).
|
||||
|
||||
Reference in New Issue
Block a user