Если мы используем дизайн глобальной транзитной сети для своих облачных ресурсов Azure. Это требует создания виртуальной глобальной сети, виртуального концентратора и многочисленных виртуальных сетей (виртуальных сетей). Соединение этих компонентов позволяет трафику проходить между ними при условии правильного контроля безопасности.
Все облачные ресурсы создаются и поддерживаются с использованием Terraform в сочетании с GitLab CI для непрерывной интеграции (CI). Я настоятельно рекомендую прочитать основы непрерывной интеграции, если вы новичок в этой концепции.
Итерации по коду Terraform требуют тестирования с использованием изолированного, эфемерного региона Azure, который часто исключает шлюз VPN для экономии времени и затрат; Создание VPN-шлюза занимает 30 и более минут! Каждый модуль VNet, выполняемый Terraform, комплектуется ресурсом подключения к Virtual Hub, как показано ниже:
|
1 2 3 4 5 6 |
resource "azurerm_virtual_hub_connection" "vhub" { name = "cn-to-${var.azure_name_suffix}" virtual_hub_id = var.parent_azurerm_virtual_hub_id remote_virtual_network_id = azurerm_virtual_network.vnet.id hub_to_vitual_network_traffic_allowed = true vitual_network_to_hub_gateways_traffic_allowed = true |
Примечание: Да, слово «vitual» (виртуальный) написано с ошибкой. Такой момент имеет место быть, если копать документацию глубже.
Загадочная внутренняя ошибка сервера
Выполнение кода, когда в виртуальном концентраторе нет VPN-шлюза, привело к загадочной ошибке.
|
1 2 3 4 5 |
Error: Error waiting for addition of Connection "connection_name" to Virtual Hub "virtual_hub_name" (Resource Group "resource_group_name"): Code="InternalServerError" Message="An error occurred." Details=[] on vnet\main.tf line 33, in resource "azurerm_virtual_hub_connection" "vhub": 33: resource "azurerm_virtual_hub_connection" "vhub" { virtual_hub_id = var.parent_azurerm_virtual_hub_id remote_virtual_network_id = azurerm_virtual_network.vnet.id |
Сообщения об ошибках дают несколько подсказок:
- Большинство кодов «Внутренняя ошибка сервера» означают ошибку на стороне сервера. Это исключает большинство компонентов устранения неполадок на стороне клиента, которые я обычно подозреваю.
- Пустые данные (ноль) заставляют меня поверить, что я передаю значения конфигурации, которые не поддерживаются, но не обрабатываются изящно фреймворком ошибок сервера.
Виновник есть vitual_network_to_hub_gateways_traffic_allowed. Этот параметр должен быть falseили исключен при подключении виртуальной сети к виртуальному концентратору, в котором отсутствует шлюз VPN. Я столкнулся с ошибкой, прежде чем читать глубже в документации поставщика. Другие облачные провайдеры, как правило, выдают более полезное сообщение об ошибке или переворачивают значение параметра на стороне сервера.
Комментирование параметра — это немедленное решение, которое сработало. Позже я переключился на использование условного оператора, основанного на существовании a, azurerm_vpn_gatewayдля определения логического значения vitual_network_to_hub_gateways_traffic_allowedпараметра.