docs(pipeline): страница переписана как инструкция для пользователя (шаги, значения из ЛК, команды)
This commit is contained in:
Repinoid
@@ -1,127 +1,72 @@
|
||||
# Пайплайн: vDC → Edge → внешние IP → SNAT
|
||||
# Как развернуть vDC, Edge, внешние IP и SNAT
|
||||
|
||||
> Проверено на dev-стенде 2026-09-24 (провайдер `2.0.20`): один `apply` собирает всю цепочку,
|
||||
> повторный `plan` не показывает изменений, `destroy` проходит в обратном порядке.
|
||||
Пошаговая инструкция. Готовые файлы — в репозитории примеров.
|
||||
|
||||
## Что делает пайплайн
|
||||
Организацию создайте заранее в ЛК: Terraform её не создаёт.
|
||||
Кластер Штурвал в эту инструкцию не входит — он разворачивается долго, отдельным шагом.
|
||||
|
||||
Собирает сетевую основу под нагрузку: виртуальный датацентр, периметровый шлюз, внешние IP
|
||||
на организации и SNAT на шлюзе — **без ручных операций в ЛК после создания организации**.
|
||||
|
||||
**Кластер Штурвал в этот пайплайн не входит** — он разворачивается очень долго, это отдельный шаг.
|
||||
|
||||
## Что вне Terraform (создаётся один раз вручную)
|
||||
|
||||
**Организация в Cloud Director** — одна на ресурсный realm, создать вторую нельзя. В конфиге она
|
||||
адресуется по UUID (`org_uid`), а её внешние IP выделяются уже Terraform-ресурсом.
|
||||
|
||||
## Порядок и почему он такой
|
||||
|
||||
| # | Ресурс | Что создаёт |
|
||||
|---|---|---|
|
||||
| 1 | `nubes_vc_vdc` | виртуальный датацентр |
|
||||
| 2 | `nubes_vc_nsxt` | сетевой шлюз периметра (Edge), ALB/AVI |
|
||||
| 3 | `nubes_vc_org_ip_allocation` | внешние IP на организации (`vIPConfigure`) |
|
||||
| 4 | `nubes_vc_nsxt_snat` | SNAT на шлюзе (`ipSpaceName`) |
|
||||
|
||||
Порядок обязателен: шаги 3 и 4 — операции `modify`, а платформа строит список доступных `ipSpace`
|
||||
из состояния `job.vcd.networkProvider` / `job.vcd.providerGateway`, то есть **требует уже созданные
|
||||
vDC и Edge**. В инструкции к операции это записано прямо: «предварительно необходимо создать
|
||||
Виртуальный датацентр (VDC), потом Сетевой шлюз периметра (Edge Gateway)». Если открыть `modify`
|
||||
на организации без vDC/Edge, список значений падает с ошибкой `Can't cast Complex Object Type
|
||||
Struct to String`.
|
||||
|
||||
## Пример конфигурации
|
||||
|
||||
```hcl
|
||||
resource "nubes_vc_vdc" "vdc" {
|
||||
resource_name = "fullpipe-vdc"
|
||||
organization_uid = var.organization # имя или UUID существующей организации
|
||||
network_provider = "snb1" # из ЛК
|
||||
provider_vdc = "Intel Broadwell 2.4"
|
||||
storage_config = jsonencode([{ name = "SATA", size = "200" }])
|
||||
suspend_on_destroy = true
|
||||
}
|
||||
|
||||
resource "nubes_vc_nsxt" "edge" {
|
||||
resource_name = "fullpipe-edge"
|
||||
vdc_type = "vdc"
|
||||
vdc_uid = nubes_vc_vdc.vdc.id # Edge создаётся только после vDC
|
||||
|
||||
need_enable_avi = true
|
||||
virtual_services_count = 3 # Штурвалу нужно ≥ 3
|
||||
routed_net_configuration = {
|
||||
ip_addr_pool = "10.10.102.0/24"
|
||||
main_dns = "81.22.46.22"
|
||||
second_dns = "185.247.187.77"
|
||||
}
|
||||
}
|
||||
|
||||
# Внешние IP на организации — только после создания Edge
|
||||
resource "nubes_vc_org_ip_allocation" "org_ip" {
|
||||
org_uid = var.org_uid # UUID организации
|
||||
|
||||
vip_configure = jsonencode([
|
||||
{ name = "internet-ipv4-v1", count = "3" }
|
||||
])
|
||||
|
||||
depends_on = [nubes_vc_nsxt.edge]
|
||||
}
|
||||
|
||||
# SNAT на шлюзе этим ipSpace
|
||||
resource "nubes_vc_nsxt_snat" "snat" {
|
||||
nsxt_uid = nubes_vc_nsxt.edge.id
|
||||
ip_space_name = "internet-ipv4-v1"
|
||||
|
||||
depends_on = [nubes_vc_org_ip_allocation.org_ip]
|
||||
}
|
||||
```
|
||||
|
||||
Порядок ключей в `vip_configure` и его форматирование значения не имеют — сравнение смысловое.
|
||||
|
||||
## Готовые файлы примеров
|
||||
|
||||
Комплект `.tf`-файлов (vDC, Edge, аллокация IP, SNAT) лежит в отдельном репозитории примеров:
|
||||
|
||||
**<https://gitea.services.ngcloud.ru/Nail/tf_examples>**
|
||||
|
||||
- каталог `modify_resources/` — ресурсы-модификаторы (аллокация IP на организации + SNAT);
|
||||
- `terraform.tfvars.example` — шаблон переменных (реальный `terraform.tfvars` с токеном нигде не публикуется).
|
||||
|
||||
Клонирование целиком:
|
||||
## 1. Скопируйте пример
|
||||
|
||||
```bash
|
||||
git clone https://gitea.services.ngcloud.ru/Nail/tf_examples.git
|
||||
cd tf_examples/fullpipe_chain
|
||||
```
|
||||
|
||||
## Значения, которые берутся из ЛК
|
||||
## 2. Возьмите значения в ЛК
|
||||
|
||||
| Параметр | Где смотреть |
|
||||
|---|---|
|
||||
| `organization_uid` / `org_uid` | карточка услуги «Организация в Cloud Director» |
|
||||
| `network_provider`, `provider_vdc` | страница vDC |
|
||||
| `storage_config` (имена политик) | дисковые политики ресурсного пула (`SATA`, `SSD`) |
|
||||
| `ip_space_name` | список ipSpace организации (доступен после создания vDC и Edge) |
|
||||
|
||||
## Удаление
|
||||
|
||||
`terraform destroy` идёт в обратном порядке и сам приводит систему в исходное состояние:
|
||||
|
||||
| # | Ресурс | Обратная операция |
|
||||
| Что | Где взять | Пример |
|
||||
|---|---|---|
|
||||
| 1 | `nubes_vc_nsxt_snat` | `modify` с `ipSpaceName = "no-needed"` (SNAT выключается) |
|
||||
| 2 | `nubes_vc_org_ip_allocation` | `modify` с `count = "0"` (квота IP обнуляется) |
|
||||
| 3 | `nubes_vc_nsxt` | удаление шлюза |
|
||||
| 4 | `nubes_vc_vdc` | удаление vDC |
|
||||
| Токен API | ЛК → Профиль → Токены → «Технический» | `eyJhbGciOi...` |
|
||||
| UUID организации | ЛК → услуга «Организация в Cloud Director» → UUID в карточке услуги | `57eeacd1-dc7f-4a52-b903-7e5f7d3c1164` |
|
||||
| Имя организации | там же — название услуги | `organ` |
|
||||
| Сетевой провайдер | ЛК → vDC → «Сетевой провайдер» | `snb1` |
|
||||
| Provider VDC | ЛК → vDC → «Provider VDC» | `Intel Broadwell 2.4` |
|
||||
| Дисковая политика | ЛК → vDC → доступные дисковые политики | `SATA` |
|
||||
| Имя ipSpace | ЛК → организация → внешние IP | `internet-ipv4-v1` |
|
||||
|
||||
Организацию удаление не затрагивает. Если снимать SNAT или квоту не нужно — у ресурсов есть
|
||||
`keep_on_destroy = true`.
|
||||
## 3. Заполните значения
|
||||
|
||||
## Что подтверждено живым прогоном (dev, 2026-09-24)
|
||||
```bash
|
||||
cp terraform.tfvars.example terraform.tfvars
|
||||
```
|
||||
|
||||
- вся цепочка поднимается **одним `apply`**;
|
||||
- повторный `plan` не требует изменений;
|
||||
- после apply в API: у организации `vIPConfigure: [{"name":"internet-ipv4-v1","count":"3"}]`,
|
||||
у шлюза `ipSpaceName: "internet-ipv4-v1"`, при этом `needEnableAVI` и `virtualServicesCount`
|
||||
не затираются (SNAT-модификация отправляет только своё поле);
|
||||
- `destroy` выключает SNAT и обнуляет квоту, орг остаётся живой.
|
||||
```hcl
|
||||
api_token = "eyJhbGciOi..." # токен из шага 2
|
||||
organization = "organ" # имя организации
|
||||
org_uid = "57eeacd1-dc7f-4a52-b903-7e5f7d3c1164" # UUID организации
|
||||
ip_space_name = "internet-ipv4-v1"
|
||||
ip_count = "3"
|
||||
```
|
||||
|
||||
## 4. Выполните команды
|
||||
|
||||
```bash
|
||||
terraform init # один раз — скачает провайдер
|
||||
terraform plan # покажет, что будет создано
|
||||
terraform apply # создаст (подтвердить: yes)
|
||||
```
|
||||
|
||||
## 5. Проверьте результат
|
||||
|
||||
- в ЛК появились виртуальный датацентр и сетевой шлюз;
|
||||
- на организации выделены внешние IP;
|
||||
- на шлюзе включён SNAT;
|
||||
- повторный `terraform plan` изменений не показывает.
|
||||
|
||||
## 6. Удаление
|
||||
|
||||
```bash
|
||||
terraform destroy
|
||||
```
|
||||
|
||||
SNAT выключается, квота IP обнуляется, затем удаляются шлюз и vDC. Организация не удаляется.
|
||||
|
||||
## Файлы примера
|
||||
|
||||
| Файл | Что делает |
|
||||
|---|---|
|
||||
| `main.tf` | провайдер и переменные |
|
||||
| `vdc.tf` | виртуальный датацентр |
|
||||
| `edge.tf` | сетевой шлюз периметра (Edge) |
|
||||
| `modifiers.tf` | внешние IP на организации + SNAT на шлюзе |
|
||||
| `terraform.tfvars.example` | шаблон значений из ЛК |
|
||||
|
||||
Reference in New Issue
Block a user