Nasazení minimální hub-spoke topologie v Azure

Slovník

Obsah

• Úvod
• Příprava lokálního prostředí
• Deployment
  • Vygenerování SSH klíče
  • Připojení do Azure z CLI
  • Nasazení Hubu
  • Nasazení aplikace 1
  • Nasazení aplikace 2
• Kontrola konektivity
  • Routování mezi spoke sítěmi
  • Ping a tracepath mezi aplikacemi
• Smazání a dealokace VMs
• Závěr
• Odkazy

Úvod

Hub-spoke topologie je doporučená síťová topologie v Azure, kterou si nasadíme pomocí Bicep kódu (s AVM moduly) tak, abychom měli centrální hub síť a dvě spoke sítě, které budou s hubem propojeny přes VNet peering. Pro směrování provozu mezi spoke sítěmi využijeme Linux VM, který bude fungovat jako router.

Adresní prostory jsou nastaveny jako příklad, nesmí se překrývat a je nutné si je zvolit podle potřeby a reálného use-case. Azure si v každé podsíti rezervuje pět IP adres, které nelze přiřadit. Patří mezi ně první čtyři adresy a poslední adresa v rozsahu dané podsítě. Praktické tipy, jak správně zvolit rozsahy lze najít zde:

• Plan for IP addressing
• Prevent IPv4 exhaustion in Azure

Příprava lokálního prostředí

winget install --exact --id Microsoft.AzureCLI 
az bicep upgrade

git clone https://github.com/Ninjanaut/azure-hub-spoke-bicep-template-01.git
cd azure-hub-spoke-bicep-template-0

platform/
├── hub.bicep 
└── connectivity/
    ├── params/
    │   └── shared.bicepparam
    ├── main.bicep
    └── router-cloud.init.yaml
landing-zones/
├── app1/
│   └── dev.bicepparam
├── app2/
│   └── dev.bicepparam
└── main.bicep

• Connectivity (hub) subskripce má vlastní platform/connectivity/main.bicep soubor a načítá si parametry z shared.bicepparam. Zároveň si načítá router-cloud.init.yaml pro inicializaci Linux VM a nastavení síťového forwardingu.
• Po nasazení hubu je potřeba vyplnit platform/hub.bicep, který je vstupem do landing-zones deploymentu kvůli nastavení oboustranného peeringu, abychom při přidávání dalších systémů nemuseli hub redeployovat.
• App1 a app2 mají sdílený landing-zones/main.bicep soubor, ale každá aplikace má své vlastní parametry uložené v dev.bicepparam souboru.
• landing-zones/main.bicep si importuje platform/hub.bicep pro nastavení oboustranného peeringu.
• Shared a dev jsou názvy prostředí, byť v tomto případě to nehraje roli.

Před nasazením je potřeba nastavit parametry, jako například region nebo VM sizing. Přednastavil jsem nejlevnější dostupný sizing, ale je potřeba dostupnost před spuštěním zkontrolovat. Adresářovou strukturu, jmennou konvenci a single repository jsem zvolil pro potřeby příkladu a je vhodné si setup přizpůsobit pro enterprise potřeby, podle rozdělení zodpovědností v týmech, oprávnění a nastavení DevOps pipeliny. Předpokládá se, že uživatel má roli Owner nebo Contributor u subskripce, kterou nasazuje. U nasazování spoke (aplikace 1 a 2) je potřeba mít oprávnění nejen na spoke subskripci, ale i na nastavení hub VNet peeringu (např. Network Contributor).

Základní příkazy pro práci s Bicep soubory jsou az bicep build a az deployment.

az bicep lint
az bicep build
az deployment sub validate
az deployment sub what-if
az deployment sub create

Deployment

Vygenerování SSH klíče

• Privátní klíč se na Windows uloží do C:\Users\username\.ssh\azure-hub-spoke-template-01 a s nikým ho nesdílíme ani neukládáme do repository.
• Veřejný klíč se na Windows uloží do C:\Users\username\.ssh\azure-hub-spoke-template-01.pub a jedná se o klíč, který použijeme pro deployment.

ssh-keygen -t ed25519 -f "$HOME\.ssh\azure-hub-spoke-template-01" -C "azure-hub-spoke-template-01"

Připojení do Azure z CLI

$env:ADMIN_SSH_PUBLIC_KEY = Get-Content "$HOME\.ssh\azure-hub-spoke-template-01.pub"
$env:ADMIN_SSH_PUBLIC_KEY

az login --tenant '<tenant-id>' # Login
az account set --subscription '<hub-subscription-id>' # Přepnutí do konkrétní subskripce
az account show -o table # Kontrola, ve které subskripci se nacházíme

Nasazení Hubu

az account set --subscription '<hub-subscription-id>'
az deployment sub create -n hub-shared -l swedencentral -f platform/connectivity/main.bicep -p platform/connectivity/params/shared.bicepparam

V Azure se vytvoří následující resources:

• Resource Group
  • VNet
    • Subnet
  • Linux VM s nastaveným síťovým forwardingem
  • NIC
  • Disk

Následně upravíme parametry (primárně subscriptionId) v souboru platform/hub.bicep. Soubor je vstupem do Bicep šablony aplikace 1 a aplikace 2, z důvodu nastavení oboustranného síťového peeringu.

Nasazení aplikace 1

az account set --subscription '<app1-subscription-id>'
az deployment sub create -n spoke-app1-dev -l swedencentral -f landing-zones/main.bicep -p landing-zones/app1/dev.bicepparam

V Azure se vytvoří následující resources:

• Resource Group
  • VNet
    • Subnet
  • Route table, která směřuje traffic do hubu
  • Linux VM
  • NIC
  • Disk

Nasazení aplikace 2

az account set --subscription '<app2-subscription-id>'
az deployment sub create -n spoke-app2-dev -l swedencentral -f landing-zones/main.bicep -p landing-zones/app2/dev.bicepparam

V Azure se vytvoří následující resources:

• Resource Group
  • VNet
    • Subnet
  • Route table, která směřuje traffic do hubu
  • Linux VM
  • NIC
  • Disk

Kontrola konektivity

Routování mezi spoke sítěmi

Protože VNet peering není tranzitivní, spoke sítě na sebe přímo nevidí. Aby provoz mezi aplikací 1 a aplikací 2 fungoval, musí platit tři podmínky:

1. IP forwarding musí být u Linux VM v hub síti zapnutý na síťové kartě (NIC) a zároveň v operačním systému.
   • V souboru platform/connectivity/main.bicep nastavení enableIPForwarding: true u router modulu.
   • V souboru router-cloud.init.yaml nastavení net.ipv4.ip_forward=1.
2. Síťový peering mezi hub a spokes musí mít povolený forwarding.
   • V souboru landing-zones/main.bicep nastavení allowForwardedTraffic: true a remotePeeringAllowForwardedTraffic: true u vnet modulu.
3. Spoke musí mít nastavenou směrovací tabulku (route table) s next hop adresou Linux VM v hubu.
   • V souboru landing-zones/main.bicep nastavení modulu routeTable.

Ping a tracepath mezi aplikacemi

az vm run-command invoke -g rg-spoke-app1-dev -n vm-conntest-app1-dev-swedencentral-001 --command-id RunShellScript --scripts "ping -c 4 10.0.8.4; tracepath -n 10.0.8.4"

{
  "value": [
    {
      "code": "ProvisioningState/succeeded",
      "displayStatus": "Provisioning succeeded",
      "level": "Info",
      "message": "Enable succeeded: \n[stdout]\nPING 10.0.8.4 (10.0.8.4) 56(84) bytes of data.\n64 bytes from 10.0.8.4: icmp_seq=1 ttl=63 time=15.4 ms\n64 bytes from 10.0.8.4: icmp_seq=2 ttl=63 time=3.51 ms\n64 bytes from 10.0.8.4: icmp_seq=3 ttl=63 time=2.51 ms\n64 bytes from 10.0.8.4: icmp_seq=4 ttl=63 time=2.75 ms\n\n--- 10.0.8.4 ping statistics ---\n4 packets transmitted, 4 received, 0% packet loss, time 3005ms\nrtt min/avg/max/mdev = 2.512/6.043/15.407/5.418 ms\n 1?: [LOCALHOST]                      pmtu 1500\n 1:  10.0.0.4                                              1.640ms \n 1:  10.0.0.4                                              1.578ms \n 2:  10.0.8.4                                              1.839ms reached\n     Resume: pmtu 1500 hops 2 back 2 \n\n[stderr]\n"
    }
  ]
}

az vm run-command invoke -g rg-spoke-app2-dev -n vm-conntest-app2-dev-swedencentral-001 --command-id RunShellScript --scripts "ping -c 4 10.0.4.4; tracepath -n 10.0.4.4"

{
  "value": [
    {
      "code": "ProvisioningState/succeeded",
      "displayStatus": "Provisioning succeeded",
      "level": "Info",
      "message": "Enable succeeded: \n[stdout]\nPING 10.0.4.4 (10.0.4.4) 56(84) bytes of data.\n64 bytes from 10.0.4.4: icmp_seq=1 ttl=63 time=2.86 ms\n64 bytes from 10.0.4.4: icmp_seq=2 ttl=63 time=8.40 ms\n64 bytes from 10.0.4.4: icmp_seq=3 ttl=63 time=2.11 ms\n64 bytes from 10.0.4.4: icmp_seq=4 ttl=63 time=4.61 ms\n\n--- 10.0.4.4 ping statistics ---\n4 packets transmitted, 4 received, 0% packet loss, time 3005ms\nrtt min/avg/max/mdev = 2.113/4.497/8.404/2.430 ms\n 1?: [LOCALHOST]                      pmtu 1500\n 1:  10.0.0.4                                              1.476ms \n 1:  10.0.0.4                                              1.036ms \n 2:  10.0.4.4                                              5.966ms reached\n     Resume: pmtu 1500 hops 2 back 2 \n\n[stderr]\n"
    }
  ]
}

Smazání a dealokace VMs

az vm delete -g rg-spoke-app1-dev -n vm-conntest-app1-dev-swedencentral-001 --yes
az vm delete -g rg-spoke-app2-dev -n vm-conntest-app2-dev-swedencentral-001 --yes
az vm deallocate -g rg-hub-shared -n vm-router-shared-swedencentral-001

az group delete -n rg-spoke-app1-dev --yes
az group delete -n rg-spoke-app2-dev --yes
az group delete -n rg-hub-shared --yes

Závěr

Nasadili jsme minimální hub-spoke topologii pomocí Bicep šablon přes Azure CLI. To je základ, na kterém lze stavět 🙌. Příště si přidáme privátní DNS, službu Azure Bastion, Azure Firewall místo Linux VM routeru, nastavíme na subnetech stavové L3/L4 firewally (NSG) a přidáme i point-to-site VPN Gateway.

Odkazy

• Hub-spoke topology in Azure
• Azure landing zone architecture
• Azure naming convention
• Bicep documentation
• Bicep overview
• Bicep Azure Verified Modules
• Az deployment CLI reference
• Plan for IP addressing
• Prevent IPv4 exhaustion in Azure
• Azure Private IP addresses
• Azure Private IP restrictions - FAQ
• Azure Accelerated Networking overview
• Azure on-demand capacity reservation