Einheit 2.2: Netzwerk und Konnektivität als Code

Einführung

In Einheit 2.1 haben Sie die Compute-Ebene von TaskBoard bereitgestellt: einen API-Server und einen Worker, der jeweils mit cloud-init gestartet wurde. Diese Server sind nutzlos, bis sie miteinander kommunizieren, das Internet für Paket-Updates 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 Teil davon eine Terraform-Ressource.

Diese Einheit baut den Netzwerk-Stack unter TaskBoard auf. Sie werden den Datenverkehr in eine öffentliche Ebene, eine Anwendungsebene und eine Datenbankebene unterteilen, indem Sie separate LANs verwenden, Server mit NICs in diese LANs einbinden, den privaten Ebenen kontrollierten Ausgangs-Zugriff über ein NAT-Gateway gewähren und einen DNS-Eintrag veröffentlichen, damit Clients den API finden können. Jede Ressource ist deklarativ, jede Abhängigkeit wird von Terraform-Graph aufgelöst, und die gesamte Topologie ist reproduzierbar aus einem einzigen terraform apply.

1. LANs für Netzwerksegmentierung

Die ionoscloud_lan-Ressource ist die Grundlage der Netzwerksegmentierung innerhalb eines virtuellen Rechenzentrums. Ein LAN ist ein Layer-2-Broadcast-Domäne, der auf ein Rechenzentrum beschränkt ist. Sie erstellen ein LAN pro Tier, damit der Datenverkehr zwischen den Tiers eine kontrollierte Grenze durchqueren muss, anstatt ein flaches Netzwerk zu teilen.

Das wichtigste Argument ist public. Ein öffentliches LAN ist mit dem IONOS-Internet-Gateway verbunden und seine Netzwerk-Schnittstellen (NICs) erhalten eine routbare öffentliche IPv4-Adresse vom Plattform-DHCP-Service. Ein privates LAN (public = false) hat keinen eigenen Internetpfad, was genau das ist, was Sie für Anwendungs- und Datenbank-Tiers wollen.

1.1 Definition der drei Tiers

TaskBoard benötigt drei LANs: ein öffentliches LAN für den Eingang, ein privates Anwendungs-LAN für den API und den Worker und 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 eine numerische ID innerhalb des Rechenzentrums zu, sobald es erstellt wurde. Sie verwenden diese IDs von NIC-Ressourcen anstelle von Hardcodings, was die Konfiguration über verschiedene 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 Ihnen bis zu 254 nutzbare Host-Adressen bietet. Private LANs verwenden RFC-1918-Bereiche (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Die Standard-Ethernet-MTU beträgt 1500 Byte, was wichtig ist, wenn Sie später in dieser Einheit Anwendungs-Levels-Paketgrößen oder VPN-Payloads anpassen.

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

2. Anbindung von Servern mit NICs

Ein ionoscloud_nic verbindet einen Server mit einem Netzwerk. Ein Server kann mehrere NICs haben, und genau so kann ein Host an mehreren Ebenen teilnehmen. TaskBoards API-Server benötigt beispielsweise eine NIC im öffentlichen Netzwerk (um eingehenden Datenverkehr zu empfangen) und eine NIC im App-Netzwerk (um die Worker- und Datenbankebenen zu erreichen).

Die NIC ist der Ort, an dem Sie entscheiden, ob eine Schnittstelle eine DHCP-zugewiesene Adresse oder eine statische Adresse erhält, und ob die Plattform Firewall auf dieser Schnittstelle aktiviert ist.

2.1 DHCP und statische Adressierung

Setzen Sie dhcp = true, um die Plattform-DHCP-Dienst eine Adresse zuweisen zu lassen. In einem öffentlichen Netzwerk wird auch automatisch eine routbare öffentliche IPv4-Adresse zugewiesen. Für private Ebenen, in denen Sie vorhersehbare Adressen wünschen, müssen Sie eine explizite ips-Liste aus dem RFC-1918-Bereich des Netzwerks bereitstellen.

# 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"]
}

Die firewall_active-Flagge aktiviert die pro-NIC-Firewall. Wenn aktiviert, blockiert die NIC-Firewall standardmäßig alle eingehenden Datenverkehre und erlaubt nur Datenverkehr auf explizit aktivierten Ports. Die NIC-Firewall ist die pro-Schnittstelle-Sicherheitssteuerung; detaillierte Regelausführung und Network Security Groups werden in Einheit 2.3 behandelt.

2.2 Multi-NIC-Server und Ebenenmitgliedschaft

Der Worker muss nur die App- und Datenbankebenen erreichen, daher erhält er zwei private NICs und keine ö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 Netzwerk referenziert, ordnet es die Erstellung automatisch: Rechenzentrum zuerst, dann LANs und Server, dann NICs. Sie müssen nie explizite depends_on für diese Kette schreiben. Ohne öffentliche NIC ist der Worker nicht von dem Internet aus erreichbar, was die Isolation ist, die Sie für einen Backend-Prozess wünschen.

3. Outbound-Zugriff mit einem NAT-Gateway

Ein privates LAN hat keine Internet-Route. Das ist gut für die eingehende Sicherheit, aber ein Problem, wenn Ihr API-Server Betriebssystem-Updates abrufen, Abhängigkeiten abrufen oder einen externen SaaS-API-Dienst aufrufen muss. Die ionoscloud_natgateway-Ressource löst dieses Problem, indem sie eine kontrollierte, nur ausgehende Konnektivität bereitstellt.

Das NAT-Gateway ist SNAT-only (Quell-NAT). Es überschreibt die Quelladresse des ausgehenden Datenverkehrs von privaten Hosts auf eine öffentliche IP, die das Gateway besitzt, und blockiert automatisch alle unerwünschten eingehenden Datenverkehre. Ein einzelnes Gateway kann bis zu 6 private Netzwerke bedienen.

3.1 Bereitstellung des Gateways

Das Gateway erfordert eine oder mehrere reservierte öffentliche IPv4-Adressen, die Sie als IP-Block zuweisen. Binden Sie das Gateway an die LANs, deren Hosts Ausgang benötigen, und definieren Sie die internen IP des Gateways, die auf jedem LAN verwendet werden.

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 entspricht POST /datacenters/{datacenterId}/natgateways. Wie bei allen IONOS-Bereitstellungsoperationen ist dies asynchron; der Terraform-Anbieter pollt die Anfrage, bis sie abgeschlossen ist, bevor er die Ressource als erstellt meldet.

3.2 SNAT-Regeln

Das Gateway leitet den Datenverkehr nicht weiter, bis Sie Regeln definieren. Eine NAT-Gateway-Regel gibt an, welche privaten Quelladressen übersetzt und über welches Protokoll werden. Regeln entsprechen POST /datacenters/{datacenterId}/natgateways/{natGatewayId}/rules.

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 eingeschränkt werden (z. B. auf TCP oder UDP), wenn Sie eine engere Kontrolle wünschen, aber ALL ist für eine allgemeine Ausgangsregel geeignet. Beachten Sie, dass die Standard-Route nicht automatisch injiziert wird: Hosts im privaten LAN müssen das Gateway-IP (10.7.1.1 oben) als ihre Standard-Route verwenden, die Sie normalerweise über cloud-init oder DHCP-Optionen auf der NIC einstellen.

4. Standort-übergreifende Konnektivität mit IPSec VPN

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

IPSec bei IONOS verwendet IKEv2 und authentifiziert Tunnel mit einem vorab vereinbarten Schlüssel (PSK). Der VPN API ist regional: Jedes Gateway befindet sich hinter einem regionspezifischen Host wie https://vpn.de-fra.ionos.com, wobei IPSec-Gateways unter dem /ipsecgateways-Ressourcenpfad verfügbar sind und ihre Tunnel unter /ipsecgateways/{gatewayId}/tunnels verschachtelt sind.

4.1 Gateway und Tunnel

Das Gateway benötigt eine reservierte öffentliche IP und eine Verbindung zum LAN, den es bedient. Der Tunnel definiert den Remote-Peer und die Traffikauswahlfelder.

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 das PSK aus der Quellcodeverwaltung heraus. Deklarieren Sie es als sensibles Variable (variable "vpn_psk" { sensitive = true }) und übergeben Sie es durch eine Umgebungsvariable oder einen Geheimnis-Speicher, 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. Der Datenverkehr von 10.7.1.0/24, der für 192.168.50.0/24 bestimmt ist, wird verschlüsselt und weitergeleitet; alles andere folgt der normalen Routing. Passen Sie diese CIDRs genau an Ihre lokale Konfiguration an, da eine Ungleichheit der häufigste Grund dafür ist, dass ein Tunnel aktiviert wird, aber keinen Datenverkehr transportiert.

5. DNS als Code

Ein Netzwerkstack, den niemand finden kann, ist unvollständig. Die ionoscloud_dns_zone- und ionoscloud_dns_record-Ressourcen ermöglichen es Ihnen, DNS vollständig aus Terraform zu veröffentlichen, sodass der Hostname für TaskBoards API zusammen mit der Infrastruktur, die es bereitstellt, versioniert wird. IONOS Cloud DNS wird von einem Anycast-Netzwerk aus geliefert, sodass die Aufzeichnungen vom nächstgelegenen Punkt der Präsenz aufgelöst werden.

5.1 Zonen und Aufzeichnungen

Erstellen Sie die Zone und fügen Sie dann Aufzeichnungen hinzu, die auf die öffentliche IP verweisen, die der öffentlichen Netzwerkkarte (NIC) des API-Servers zugewiesen ist.

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 von Datensatztypen, einschließlich A, AAAA, CNAME, ALIAS, MX, NS, SOA, SRV, TXT, CAA und HTTPS. Um einen Apex-(Zonenwurzel-)Datensatz zu erstellen, lassen Sie das Feld "Datensatzname" leer, anstatt @ zu verwenden.

Der entsprechende API-Aufruf wird an https://dns.<region>.ionos.com/zones für Zonen und an den /records-Pfad für Datensätze gesendet, beispielsweise POST https://dns.de-fra.ionos.com/zones/{zoneId}/records.

5.2 Cloud DNS-Umfang und wo Failover hingehört

Cloud DNS ist ein autorisierter DNS-Dienst: Er veröffentlicht und löst Ihre Zonen und Datensätze auf. Er überwacht Ihre Backends nicht oder führt gesundheitsbasierte Failover durch, sodass ein Datensatz weiterhin auf sein konfiguriertes Ziel verweist, unabhängig davon, ob dieses Ziel verfügbar ist. Verlassen Sie sich nicht auf DNS, um um ein fehlgeschlagenes Backend herumzuleiten. Für automatisches Failover platzieren Sie einen gemanagten Load Balancer vor Ihren Zielen und zeigen den DNS-Datensatz auf den Load Balancer, sodass Gesundheitsprüfungen und Zielentfernung auf der in Einheit 2.3 eingeführten Lastverteilungsebene erfolgen.

API Referenz-Quick-Card

Wichtige API-Endpunkte für die Netzwerk- und Konnektivitätsbereitstellung:

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

Code-Labor

Ziel: Bau von TaskBoards dreistufigem Netzwerk-Stack mit Terraform: öffentliche, App- und Datenbank-LANs, Server-NICs, ein NAT-Gateway für privaten Egress und ein DNS-Eintrag für den API. Dann die Konnektivität zwischen den Ebenen überprüfen.

Voraussetzungen:

• IONOS Cloud-Konto mit API-Token (IONOS_TOKEN exportiert)
• Terraform mit dem ionoscloud-Anbieter installiert
• Das TaskBoard-Rechenzentrum und die Server aus Einheit 2.1 bereits im Zustand

Schritt 1: Definieren der drei LANs

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: Anfügen der API-Server-NICs

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: Reservieren eines IP-Blocks und Erstellen des NAT-Gateways

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: Hinzufügen der SNAT-Egress-Regel

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: Veröffentlichen des DNS-Eintrags

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: Anwenden und Überprüfen des Egress von einem privaten Host

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: Überprüfen der Konnektivität zwischen den Ebenen

# 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

Validierungs-Checkliste:

• [ ] Drei LANs erstellt (1 öffentlich, 2 privat)
• [ ] API-Server hat sowohl eine öffentliche als auch eine App-Ebene-NIC
• [ ] Privater Host erreicht das Internet über das NAT-öffentliche IP
• [ ] API-Server und Worker kommunizieren auf der App-LAN
• [ ] DNS-A-Eintrag wird auf die API-öffentliche IP aufgelöst

Aufräumen:

terraform destroy -auto-approve

Häufige Fehlerquellen

Entwicklerfehler, die bei der Netzwerkinfrastruktur auf IONOS Cloud vermieden werden sollten:

1. Erwartung, dass private LAN-Hosts ohne ein NAT-Gateway das Internet erreichen

   • Problem: Ihr API-Server in einem privaten LAN kann nicht apt update oder externe APIs aufrufen, und Verbindungen verfallen einfach.
   • Warum es passiert: Ein privates LAN (public = false) hat keine Internet-Route. Die Standard-Route wird auch nach dem Anfügen eines NAT-Gateways nicht automatisch injiziert.
   • Lösung: Bereitstellen Sie ein ionoscloud_natgateway mit einer SNAT-Regel, dann zeigen Sie den Standard-Gateway der Hosts auf das Gateway IP via cloud-init oder DHCP-Optionen:

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

2. Nicht übereinstimmende VPN-Verkehrsauswahlfelder

   • Problem: Der IPSec-Tunnel zeigt als aktiv, aber keine Pakete überqueren ihn und lokale Hosts bleiben unerreichbar.
   • Warum es passiert: cloud_network_cidrs und peer_network_cidrs stimmen nicht genau mit den Subnetzen überein, die auf dem Remote-Peer konfiguriert sind, sodass der Verkehr nicht für die Verschlüsselung ausgewählt wird.
   • Lösung: Stimmen Sie die CIDRs auf beiden Seiten genau ab. Die IONOS-Seite muss ihr eigenes LAN-Subnetz und das Subnetz des Peers auflisten, das die Konfiguration des Remote-Geräts widerspiegelt:

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

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

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

   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 eine gestufte Isolation, NICs verbinden Server mit einem oder mehreren Ebenen mit statischer oder DHCP-Adressierung, ein NAT-Gateway gewährt kontrollierten Ausgangszugriff auf private Hosts, ein IPSec-Gateway verbindet sich mit lokalen Netzwerken und DNS-Einträge veröffentlichen den Endpunkt, alles in Terraform deklariert und reproduzierbar auf Abruf. TaskBoard verfügt jetzt über eine öffentliche Eingangs-Ebene, eine private Anwendungs-Ebene und eine isolierte Datenbank-Ebene, mit privatem Ausgang und einem auflösbaren API-Hostname.

Der Netzwerk-Stack ist die Grundlage, auf der die REST des Moduls 2 aufbaut. Einheit 2.3 fügt Lastverteilungs- und Netzwerksicherheitsgruppen-Regeln auf diese LANs und NICs hinzu, und Modul 4 verbindet Anwendungscode mit den gemanagten Datenbanken, die auf der Datenbank-Ebene leben, die Sie gerade erstellt haben.

Wichtige Punkte:

• Eine ionoscloud_lan pro Ebene; public = true verbindet sich mit dem Internet-Gateway, public = false isoliert die Ebene
• Ein Server kann mehrere Ebenen beitreten, indem er mehrere ionoscloud_nic-Ressourcen hat, eine pro LAN
• Private LANs benötigen ein SNAT-nur ionoscloud_natgateway für den Ausgangszugriff, und die Standard-Route wird nicht automatisch injiziert
• IPSec-VPN verwendet IKEv2 mit einem PSK und erfordert genau übereinstimmende Datenverkehr-Selektoren 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 einen VDC beschränkt ist, die Einheit der Netzwerk-Segmentierung; bereitgestellt mit ionoscloud_lan.
• NIC: Ein Netzwerk-Interface, das einen Server an ein LAN anhängt; ein Server mit NICs auf mehreren LANs nimmt an mehreren Ebenen teil.
• SNAT (Quell-NAT): Die Übersetzung, die das NAT-Gateway durchführt, indem es ausgehende Quell-Adressen in eine öffentliche IP umschreibt und unerwünschten eingehenden Datenverkehr blockiert.
• Datenverkehr-Selektor: Das Cloud- und Peer-CIDR-Paar auf einem IPSec-Tunnel, das bestimmt, welcher Datenverkehr verschlüsselt und über das VPN geroutet wird.
• Apex-Eintrag: Ein DNS-Eintrag am Zonen-Wurzel, der in Cloud DNS erstellt wird, indem das Eintrags-Namens-Feld leer gelassen wird.

Nächste Schritte

Weiterlernen: Einheit 2.3: Lastverteilung und Sicherheit als Code

Verwandte Themen:

• Einheit 2.1: Rechenressourcen und Serverautomatisierung
• Einheit 1.2: Terraform Anbieter und Kernmuster