Einheit 2.2: Netzwerk und Konnektivität als Code

Einführung

In Einheit 2.1 haben Sie die Compute-Ebene von TaskBoard provisioniert: einen API-Server und einen Worker, jeweils gestartet mit cloud-init. Diese Server sind nutzlos, bis sie miteinander kommunizieren, das Internet für Paketupdates erreichen und einen Hostnamen auflösen können, der auf den API-Endpunkt verweist. Das ist die Aufgabe der Netzwerkebene, und auf IONOS CLOUD ist jeder Bestandteil davon eine Terraform-Ressource.

In dieser Einheit wird der Netzwerkstack unterhalb von TaskBoard aufgebaut. Sie segmentieren den Traffic in eine öffentliche Ebene, eine Anwendungsebene und eine Datenbankebene, indem Sie separate LANs verwenden. Sie verbinden die Server mit diesen LANs über NICs, gewähren den privaten Ebenen kontrollierten ausgehenden Zugriff über ein NAT-Gateway und veröffentlichen einen DNS-Eintrag, damit Clients die API finden können. Jede Ressource ist deklarativ, jede Abhängigkeit wird durch den Graphen von Terraform aufgelöst und die gesamte Topologie ist aus einer einzelnen terraform apply reproduzierbar.

1. LANs für Netzwerksegmentierung

Die ionoscloud_lan-Ressource ist die Grundlage der Netzwerksegmentierung innerhalb eines VDC. Ein LAN ist ein Broadcast-Bereich der Ebene 2, der auf ein einzelnes Rechenzentrum beschränkt ist. Sie erstellen ein LAN pro Ebene, damit der Verkehr zwischen den Ebenen eine kontrollierte Grenze durchqueren muss, anstatt ein flaches Netzwerk zu teilen.

Das wichtigste Argument ist public. Ein öffentliches LAN ist mit dem Internet-Gateway von IONOS CLOUD verbunden, und seine NICs erhalten eine routbare öffentliche IPv4-Adresse vom Plattform-DHCP-Dienst. Ein privates LAN (public = false) hat keinen eigenen Internetpfad, was genau das ist, was Sie für die Anwendungsebene und die Datenbankebene benötigen.

1.1 Definition der drei Ebenen

TaskBoard benötigt drei LANs: ein öffentliches LAN für den Eingang, ein privates Anwendungslan für die API und den Worker sowie ein privates Datenbank-LAN. Jedes LAN gehört zum Rechenzentrum, das Sie in Modul 1 bereitgestellt haben.

resource "ionoscloud_lan" "public" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-public"
  public        = true
}

resource "ionoscloud_lan" "app" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-app"
  public        = false
}

resource "ionoscloud_lan" "db" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-db"
  public        = false
}

Terraform weist jedem LAN nach der Erstellung eine numerische ID innerhalb des Datacenters zu. Sie verweisen in NIC-Ressourcen auf diese IDs, anstatt sie hart zu codieren, was die Konfiguration über Umgebungen hinweg portabel hält.

1.2 Adressierung innerhalb eines LAN

Die Plattform weist jedem LAN ein privates Subnetz mit einer /24 Standard-Subnetzgröße zu, sodass ein einzelnes LAN bis zu 254 nutzbare Host-Adressen bereitstellt. Private LANs verwenden RFC 1918 Bereiche (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Der Standard-Ethernet-MTU beträgt 1500 Bytes, was relevant ist, wenn Sie später in dieser Einheit anwendungsebene Paketgrößen oder VPN-Payloads anpassen.

Sie konfigurieren das Subnetz nicht direkt am LAN. Adressen werden auf NIC-Ebene zugewiesen, entweder automatisch durch DHCP oder als explizite statische IPs, was der nächste Abschnitt behandelt.

2. Anbinden von Servern mit NICs

Eine ionoscloud_nic verbindet einen Server mit einem LAN. Ein Server kann mehrere NICs besitzen, und genau so nimmt ein Host an mehreren Ebenen teil. Der API-Server von TaskBoard benötigt beispielsweise eine NIC im öffentlichen LAN (zum Empfangen von eingehendem Verkehr) und eine NIC im App-LAN (um auf die Worker- und Datenbank-Ebenen zuzugreifen).

An der NIC entscheiden Sie, ob eine Schnittstelle eine per DHCP zugewiesene Adresse oder eine statische Adresse erhält und ob die Plattform-Firewall auf dieser Schnittstelle aktiv ist.

2.1 DHCP- und statische Adressierung

Setzen Sie dhcp = true, damit der DHCP-Dienst der Plattform eine Adresse zuweist. Auf einem öffentlichen LAN wird auf diese Weise automatisch auch eine routbare öffentliche IPv4-Adresse zugewiesen. Für private Ebenen, bei denen Sie vorhersehbare Adressen wünschen, geben Sie eine explizite ips-Liste aus dem RFC-1918-Bereich des LANs an.

# Public-facing NIC on the API server: DHCP-assigned public IP
resource "ionoscloud_nic" "api_public" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = ionoscloud_server.api.id
  lan           = ionoscloud_lan.public.id
  name          = "api-public"
  dhcp          = true
  firewall_active = true
}

# Private NIC on the API server: static address on the app LAN
resource "ionoscloud_nic" "api_app" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = ionoscloud_server.api.id
  lan           = ionoscloud_lan.app.id
  name          = "api-app"
  dhcp          = false
  ips           = ["10.7.1.10"]
}

Der firewall_active-Schalter aktiviert die Firewall pro NIC. Wenn aktiviert, blockiert die NIC-Firewall standardmäßig den gesamten eingehenden Verkehr und erlaubt nur Verkehr auf explizit aktivierten Ports. Die NIC-Firewall ist die Sicherheitssteuerung pro Schnittstelle; die detaillierte Regelbereitstellung und Network Security Groups werden in Einheit 2.3 behandelt.

2.2 Multi-NIC-Server und Ebenenmitgliedschaft

Der Worker muss nur auf die App- und Datenbank-Ebenen zugreifen können, daher erhält er zwei private NICs und keinerlei öffentliche Schnittstelle.

resource "ionoscloud_nic" "worker_app" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = ionoscloud_server.worker.id
  lan           = ionoscloud_lan.app.id
  name          = "worker-app"
  dhcp          = false
  ips           = ["10.7.1.20"]
}

resource "ionoscloud_nic" "worker_db" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = ionoscloud_server.worker.id
  lan           = ionoscloud_lan.db.id
  name          = "worker-db"
  dhcp          = false
  ips           = ["10.7.2.20"]
}

Da Terraform erkennt, dass jede NIC sowohl einen Server als auch ein LAN referenziert, ordnet sie die Erstellung automatisch: zuerst das Datacenter, dann die LANs und Server, anschließend die NICs. Sie schreiben für diese Kette niemals explizites depends_on. Ohne öffentliche NIC ist der Worker aus dem Internet nicht erreichbar, was die Isolation darstellt, die Sie für einen Backend-Prozess benötigen.

3. Ausgehender Zugriff über ein NAT-Gateway

Ein privates LAN verfügt über keine Internetroute. Das ist für die Sicherheit eingehender Verbindungen vorteilhaft, stellt jedoch ein Problem dar, wenn Ihr API-Server Betriebssystem-Updates abrufen, Abhängigkeiten laden oder eine externe SaaS-API aufrufen muss. Die Ressource ionoscloud_natgateway löst dieses Problem, indem sie eine kontrollierte, ausschließlich ausgehende Konnektivität bereitstellt.

Das NAT-Gateway arbeitet ausschließlich mit SNAT (Source NAT). Es überschreibt die Quelladresse des ausgehenden Traffics von privaten Hosts durch eine öffentliche IP, die dem Gateway zugeordnet ist, und blockiert automatisch alle nicht angeforderten eingehenden Datenpakete. Ein einzelnes Gateway kann bis zu 6 private Netzwerke bedienen.

3.1 Bereitstellung des Gateways

Das Gateway benötigt eine oder mehrere reservierte öffentliche IPv4-Adressen, die Sie als IP-Block zuweisen. Verknüpfen Sie das Gateway mit den LANs, deren Hosts ausgehenden Zugriff benötigen, und definieren Sie die internen IP-Adressen, die das Gateway auf jedem LAN verwendet.

resource "ionoscloud_ipblock" "nat" {
  location = ionoscloud_datacenter.taskboard.location
  size     = 1
  name     = "taskboard-nat-ip"
}

resource "ionoscloud_natgateway" "taskboard" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-nat"
  public_ips    = ionoscloud_ipblock.nat.ips

  lans {
    id           = ionoscloud_lan.app.id
    gateway_ips  = ["10.7.1.1/24"]
  }
}

Der zugrunde liegende API-Aufruf wird auf POST /datacenters/{datacenterId}/natgateways abgebildet. Wie alle Provisioning-Vorgänge in IONOS CLOUD ist dieser asynchron; der Terraform-Provider fragt die Anfrage ab, bis sie abgeschlossen ist, bevor die Ressource als erstellt gemeldet wird.

3.2 SNAT-Regeln

Das Gateway leitet keinen Verkehr, bis Sie Regeln definieren. Eine NAT-Gateway-Regel legt fest, welche privaten Quelladressen übersetzt werden und über welches Protokoll. Regeln werden auf POST /datacenters/{datacenterId}/natgateways/{natGatewayId}/rules abgebildet.

resource "ionoscloud_natgateway_rule" "app_egress" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  natgateway_id = ionoscloud_natgateway.taskboard.id
  name          = "app-tier-egress"
  type          = "SNAT"
  protocol      = "ALL"
  source_subnet = "10.7.1.0/24"
  public_ip     = ionoscloud_ipblock.nat.ips[0]
}

Das Protokoll kann bei Bedarf für eine engere Steuerung eingeschränkt werden (z. B. auf TCP oder UDP), jedoch ist ALL für eine allgemeine Ausgangsregel geeignet. Beachten Sie, dass der Standardpfad nicht automatisch injiziert wird: Hosts im privaten LAN müssen die Gateway-IP (10.7.1.1 oben) als ihr Standardgateway verwenden, die Sie in der Regel über cloud-init oder DHCP-Optionen auf der NIC festlegen.

4. Site-to-Site-Verbindung mit IPSec VPN

Wenn TaskBoard auf eine Ressource in Ihrem lokalen Rechenzentrum zugreifen muss, beispielsweise auf einen internen Identitätsanbieter, verbinden Sie die beiden Netzwerke mit der ionoscloud_vpn_ipsec_gateway-Ressource. Das VPN Gateway unterstützt IPSec und WireGuard; in diesem Abschnitt wird IPSec für einen klassischen Site-to-Site-Tunnel verwendet.

IPSec in IONOS CLOUD verwendet IKEv2 und authentifiziert Tunnel mit einem vorab geteilten Schlüssel (PSK). Die VPN API ist regional: Jedes Gateway befindet sich hinter einem regionsspezifischen Host wie https://vpn.de-fra.ionos.com, wobei IPSec-Gateways unter dem Ressourcenpfad /ipsecgateways bereitgestellt werden und deren Tunnel unter /ipsecgateways/{gatewayId}/tunnels verschachtelt sind.

4.1 Gateway und Tunnel

Das Gateway benötigt eine reservierte öffentliche IP und eine Verbindung in das LAN, das es bedient. Der Tunnel definiert den entfernten Peer und die Traffic-Selektoren.

resource "ionoscloud_ipblock" "vpn" {
  location = ionoscloud_datacenter.taskboard.location
  size     = 1
  name     = "taskboard-vpn-ip"
}

resource "ionoscloud_vpn_ipsec_gateway" "hybrid" {
  name       = "taskboard-hybrid"
  location   = "de/fra"
  gateway_ip = ionoscloud_ipblock.vpn.ips[0]

  connections {
    datacenter_id = ionoscloud_datacenter.taskboard.id
    lan_id        = ionoscloud_lan.app.id
    ipv4_cidr     = "10.7.1.5/24"  # the gateway's own host address on the app LAN, not the network address
  }
}

resource "ionoscloud_vpn_ipsec_tunnel" "onprem" {
  gateway_id    = ionoscloud_vpn_ipsec_gateway.hybrid.id
  location      = "de/fra"
  name          = "to-onprem"
  remote_host   = "203.0.113.10"

  auth {
    method = "PSK"
    psk {
      key = var.vpn_psk
    }
  }

  cloud_network_cidrs = ["10.7.1.0/24"]
  peer_network_cidrs  = ["192.168.50.0/24"]
}

Halten Sie den PSK aus der Quellcodeverwaltung heraus. Deklarieren Sie ihn als sensible Variable (variable "vpn_psk" { sensitive = true }) und stellen Sie ihn über eine Umgebungsvariable oder einen Secret Store bereit, niemals als Literal in der .tf-Datei.

4.2 Routing über den Tunnel

Die cloud_network_cidrs und peer_network_cidrs definieren, welche Subnetze über den Tunnel erreichbar sind. Verkehr von 10.7.1.0/24 mit Ziel 192.168.50.0/24 wird verschlüsselt und weitergeleitet; alles andere folgt der normalen Routing-Logik. Passen Sie diese CIDRs exakt an Ihre On-Premises-Konfiguration an, da eine Abweichung der häufigste Grund ist, warum ein Tunnel zwar aufgebaut wird, aber keinen Verkehr transportiert.

5. DNS as Code

Ein Netzwerkstack, den niemand finden kann, ist unvollständig. Die Ressourcen ionoscloud_dns_zone und ionoscloud_dns_record ermöglichen es, DNS vollständig über Terraform zu veröffentlichen, sodass der Hostname für die API von TaskBoard gemeinsam mit der Infrastruktur versioniert wird, die sie bereitstellt. IONOS Cloud DNS wird über ein Anycast-Netzwerk bereitgestellt, sodass Einträge vom nächstgelegenen Präsenzpunkt aufgelöst werden.

5.1 Zonen und Einträge

Erstellen Sie die Zone und fügen Sie anschließend Einträge hinzu, die auf die öffentliche IP zeigen, die der öffentlichen NIC des API-Servers zugewiesen wurde.

resource "ionoscloud_dns_zone" "taskboard" {
  name        = "taskboard.example.com"
  description = "TaskBoard application zone"
  enabled     = true
}

resource "ionoscloud_dns_record" "api" {
  zone_id = ionoscloud_dns_zone.taskboard.id
  name    = "api"
  type    = "A"
  content = ionoscloud_nic.api_public.ips[0]
  ttl     = 300
  enabled = true
}

TTL-Werte müssen zwischen 60 und 604800 Sekunden liegen. Cloud DNS unterstützt eine breite Palette an Record-Typen, darunter A, AAAA, CNAME, ALIAS, MX, NS, SOA, SRV, TXT, CAA und HTTPS. Um einen Apex- (Zonenwurzel-) Eintrag zu erstellen, lassen Sie das Feld für den Record-Namen leer, anstatt @ zu verwenden.

Der entsprechende API-Aufruf sendet Daten an https://dns.<region>.ionos.com/zones für Zonen und an den /records-Pfad der Zone für Einträge, beispielsweise POST https://dns.de-fra.ionos.com/zones/{zoneId}/records.

5.2 Cloud DNS-Umfang und der Ort für Failover

Cloud DNS ist ein autoritativer DNS-Dienst: Er veröffentlicht und löst Ihre Zonen und Einträge auf. Er befragt Ihre Backends nicht und führt kein Failover basierend auf Health Checks durch. Daher wird ein Eintrag unabhängig davon, ob das konfigurierte Ziel verfügbar ist, weiterhin auf dieses Ziel aufgelöst. Verlassen Sie sich nicht auf DNS, um um ein fehlgeschlagenes Backend herumzuleiten. Für automatisches Failover platzieren Sie einen verwalteten Load Balancer vor Ihren Zielen und weisen den DNS-Eintrag dem Load Balancer zu, sodass Health Checks und die Entfernung von Zielen auf der Load-Balancing-Ebene erfolgen, die in Einheit 2.3 eingeführt wurde.

API-Referenz Schnellkarte

Wichtige API-Endpunkte für die Bereitstellung von Netzwerk und Konnektivität:

Basis-URL (Cloud API): https://api.ionos.com/cloudapi/v6 Regionaler DNS-Host: https://dns.de-fra.ionos.com Regionaler VPN-Host: https://vpn.de-fra.ionos.com Authentifizierung: Authorization: Bearer <token>

Code Lab

Ziel: Erstellen Sie den dreistufigen Netzwerk-Stack von TaskBoard mit Terraform: öffentliche, App- und Datenbank-LANs, Server-NICs, ein NAT-Gateway für privaten Ausgangsverkehr und ein DNS-Eintrag für die API. Prüfen Sie anschließend die Konnektivität zwischen den Ebenen.

Voraussetzungen:

• IONOS CLOUD-Konto mit API-Token (IONOS_TOKEN exportiert)
• Terraform mit dem ionoscloud-Provider installiert
• Das TaskBoard-Rechenzentrum und die Server aus Einheit 2.1 befinden sich bereits im State

Schritt 1: Die drei LANs definieren

resource "ionoscloud_lan" "public" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-public"
  public        = true
}
resource "ionoscloud_lan" "app" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-app"
  public        = false
}
resource "ionoscloud_lan" "db" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-db"
  public        = false
}

Erwartete Ausgabe:

Plan: 3 to add, 0 to change, 0 to destroy.

Schritt 2: API-Server-NICs anbinden

resource "ionoscloud_nic" "api_public" {
  datacenter_id   = ionoscloud_datacenter.taskboard.id
  server_id       = ionoscloud_server.api.id
  lan             = ionoscloud_lan.public.id
  dhcp            = true
  firewall_active = true
}
resource "ionoscloud_nic" "api_app" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = ionoscloud_server.api.id
  lan           = ionoscloud_lan.app.id
  dhcp          = false
  ips           = ["10.7.1.10"]
}

Erwartete Ausgabe:

ionoscloud_nic.api_public: Creation complete after 1m12s

Schritt 3: IP-Block reservieren und NAT-Gateway erstellen

resource "ionoscloud_ipblock" "nat" {
  location = ionoscloud_datacenter.taskboard.location
  size     = 1
  name     = "taskboard-nat-ip"
}
resource "ionoscloud_natgateway" "taskboard" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-nat"
  public_ips    = ionoscloud_ipblock.nat.ips
  lans {
    id          = ionoscloud_lan.app.id
    gateway_ips = ["10.7.1.1/24"]
  }
}

Erwartete Ausgabe:

ionoscloud_natgateway.taskboard: Creation complete after 2m03s

Schritt 4: Die SNAT-Outbound-Regel hinzufügen

resource "ionoscloud_natgateway_rule" "app_egress" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  natgateway_id = ionoscloud_natgateway.taskboard.id
  name          = "app-tier-egress"
  type          = "SNAT"
  protocol      = "ALL"
  source_subnet = "10.7.1.0/24"
  public_ip     = ionoscloud_ipblock.nat.ips[0]
}

Erwartete Ausgabe:

ionoscloud_natgateway_rule.app_egress: Creation complete

Schritt 5: DNS-Eintrag veröffentlichen

resource "ionoscloud_dns_zone" "taskboard" {
  name    = "taskboard.example.com"
  enabled = true
}
resource "ionoscloud_dns_record" "api" {
  zone_id = ionoscloud_dns_zone.taskboard.id
  name    = "api"
  type    = "A"
  content = ionoscloud_nic.api_public.ips[0]
  ttl     = 300
  enabled = true
}

Erwartete Ausgabe:

ionoscloud_dns_record.api: Creation complete

Schritt 6: Egress von einem privaten Host anwenden und überprüfen

terraform apply -auto-approve
# SSH to the API server via its public IP, then test outbound through NAT:
ssh root@$(terraform output -raw api_public_ip)
curl -s https://ifconfig.io   # should return the NAT gateway public IP

Erwartete Ausgabe:

<the public IP from ionoscloud_ipblock.nat>

Schritt 7: Verbindung der Ebenen überprüfen

# From the API server, reach the worker on the app LAN:
ping -c 2 10.7.1.20

Erwartete Ausgabe:

2 packets transmitted, 2 received, 0% packet loss

Prüfliste:

• [ ] Drei LANs erstellt (1 öffentlich, 2 privat)
• [ ] Der API-Server verfügt über sowohl eine öffentliche als auch eine App-Tier-NIC
• [ ] Der private Host erreicht das Internet über die öffentliche IP-Adresse des NAT
• [ ] Der API-Server und der Worker kommunizieren über das App-LAN
• [ ] Der DNS-Eintrag vom Typ A wird auf die öffentliche IP-Adresse des API-Servers aufgelöst

Aufräumen:

terraform destroy -auto-approve

Häufige Fehler

Fehler von Entwicklerinnen und Entwicklern, die bei der Netzwerkbereitstellung auf IONOS CLOUD vermieden werden sollten:

1. Erwartung, dass private LAN-Hosts ohne NAT-Gateway auf das Internet zugreifen können

   • Problem: Ihr API-Server auf einem privaten LAN kann apt update oder keine externen APIs aufrufen, und Verbindungen laufen einfach auf.
   • Grund: Ein privates LAN (public = false) hat keine Internetroute. Die Standardroute wird nicht automatisch injiziert, auch nicht nach dem Anbinden eines NAT-Gateways.
   • Lösung: Stellen Sie ein ionoscloud_natgateway mit einer SNAT-Regel bereit und weisen Sie den Hosts über cloud-init oder DHCP-Optionen die Gateway-IP als Standardgateway zu:

   lans {
     id          = ionoscloud_lan.app.id
     gateway_ips = ["10.7.1.1/24"]
   }
   

2. Nicht übereinstimmende VPN-Traffic-Selektoren

   • Problem: Der IPSec-Tunnel wird als aktiv angezeigt, aber es werden keine Pakete darüber übertragen und die Hosts in der lokalen Infrastruktur bleiben unerreichbar.
   • Ursache: cloud_network_cidrs und peer_network_cidrs stimmen nicht exakt mit den auf dem entfernten Peer konfigurierten Subnetzen überein, weshalb der Traffic nicht für die Verschlüsselung ausgewählt wird.
   • Lösung: Die CIDRs auf beiden Seiten exakt abgleichen. Die IONOS CLOUD-Seite muss ihr eigenes LAN-Subnetz und das Subnetz des Peers auflisten, das der Konfiguration des entfernten Geräts entspricht:

   cloud_network_cidrs = ["10.7.1.0/24"]
   peer_network_cidrs  = ["192.168.50.0/24"]
   

3. Verwendung eines ungültigen TTL-Werts in einem DNS-Eintrag

   • Problem: Die Erstellung eines DNS-Eintrags schlägt mit einem Validierungsfehler im Feld ttl fehl.
   • Ursache: Der TTL-Wert liegt außerhalb des zulässigen Bereichs von 60 bis 604800 Sekunden (zum Beispiel ein ttl = 30, der von einem anderen Anbieter übernommen wurde).
   • Lösung: Den TTL-Wert auf den unterstützten Bereich begrenzen:

   resource "ionoscloud_dns_record" "api" {
     ttl = 300   # valid: 60..604800
   }
   

Zusammenfassung

Sie können jetzt ein vollständiges, segmentiertes Netzwerk für eine Anwendung vollständig als Code erstellen. LANs bieten Ihnen gestufte Isolation, NICs verbinden Server mit einer oder mehreren Stufen über statische oder DHCP-Adressierung, ein NAT-Gateway gewährt kontrollierten ausgehenden Zugriff auf private Hosts, ein IPSec-Gateway stellt eine Brücke zu On-Premises-Netzwerken her, und DNS-Einträge veröffentlichen den Endpunkt, wobei alles in Terraform deklariert und bei Bedarf reproduzierbar ist. TaskBoard verfügt nun über eine öffentliche Eingangsstufe, eine private Anwendungsebene und eine isolierte Datenbankstufe, mit privatem Ausgang und einem auflösbaren API-Hostnamen.

Der Netzwerk-Stack ist das Fundament, auf dem der Rest von Modul 2 aufbaut. Einheit 2.3 fügt Load Balancer und Network Security Group-Regeln auf Basis dieser LANs und NICs hinzu, und Modul 4 verbindet den Anwendungscode mit den verwalteten Datenbanken, die auf der gerade erstellten Datenbankstufe platziert werden.

Wichtige Punkte:

• Ein ionoscloud_lan pro Stufe; public = true verbindet mit dem Internet-Gateway, public = false isoliert die Stufe
• Ein Server nimmt an mehreren Stufen teil, indem er mehrere ionoscloud_nic-Ressourcen besitzt, eine pro LAN
• Private LANs benötigen ein nur für SNAT bestimmtes ionoscloud_natgateway für den ausgehenden Zugriff, und der Standard-Route wird nicht automatisch injiziert
• IPSec VPN verwendet IKEv2 mit einem PSK und erfordert exakt übereinstimmende Traffic Selectors auf beiden Enden
• DNS-Zonen und -Einträge sind Terraform-Ressourcen mit TTLs, die auf 60 bis 604800 Sekunden beschränkt sind, und werden über ein Anycast-Netzwerk bereitgestellt

Wichtige Begriffe:

• LAN: Ein Layer-2-Broadcast-Bereich, der auf ein VDC beschränkt ist, die Einheit der Netzwerksegmentierung; provisioniert mit ionoscloud_lan.
• NIC: Eine Netzwerkschnittstelle, die einen Server an ein LAN anbindet; ein Server mit NICs auf mehreren LANs nimmt an mehreren Stufen teil.
• SNAT (Source NAT): Die Übersetzung, die das NAT-Gateway durchführt, indem es ausgehende Quelladressen in eine öffentliche IP umschreibt und ungefragten eingehenden Verkehr blockiert.
• Traffic selector: Das Paar aus Cloud- und Peer-CIDR auf einem IPSec-Tunnel, das bestimmt, welcher Verkehr verschlüsselt und über das VPN geroutet wird.
• Apex record: Ein DNS-Eintrag an der Zonenwurzel, erstellt in Cloud DNS, indem das Feld für den Eintragsnamen leer gelassen wird.

Nächste Schritte

Weiter lernen: Einheit 2.3: Lastverteilung und Security as Code

Verwandte Themen:

• Einheit 2.1: Compute und Server-Automatisierung
• Einheit 1.2: Terraform Provider und Kernmuster