feat: add minimal PROD VM example
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This commit is contained in:
Repinoid
@@ -0,0 +1,127 @@
|
||||
# Минимальная цепочка для одной ВМ (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 |
|
||||
Reference in New Issue
Block a user