Wie aus dem Titel hervorgeht, geht es in diesem Beitrag darum, Ihnen bei der Bereitstellung einer Container-Instanz in Azure zu helfen.
Wir werden jedoch das typische Szenario erweitern und die Netzwerkfunktionen etwas umfassender nutzen, indem wir die Containergruppe in einem privaten Subnetz unterbringen.
Hinweis: In diesem Beispiel verwenden wir der Einfachheit halber NGINX als Container unserer Wahl. Natürlich können Sie es auch mit jedem anderen Image versuchen.
Machen wir uns an die Arbeit!
Allgemeines Layout
Das Wichtigste zuerst: Lassen Sie uns mit einer klaren Vorstellung davon beginnen, was wir bauen werden
Das Diagramm stellt alle Bausteine dar. Einige dieser Konzepte - wenn nicht sogar alle - könnten Ihnen jedoch unbekannt sein und bedürfen daher einer Erläuterung. Ich werde sie der Reihe nach durchgehen:
Lassen Sie uns ein Szenario aus dem wirklichen Leben als Analogie verwenden: Stellen Sie sich vor, Sie sind eingeladen, in einer Villa zu wohnen...
-
VNet: Die Struktur, die das Ganze zusammenhält. Ohne ein Netzwerk haben wir nichts.
Wir können es uns als die Villa selbst vorstellen. - Subnetze: Sie sind Unterabteilungen des vnet. Es ist im Grunde die Art und Weise, wie Komponenten innerhalb des Netzwerks gruppiert werden. Stellen Sie sich die Subnetze wie verschiedene Zimmer in einem Haus vor.
-
Container-Instanz: Im Wesentlichen unser Docker-Container. Der nginx-Server selbst.
Das sind Sie, einer der (potenziell vielen) Bewohner dieses Ortes. -
Öffentliche IP: Stellt unserem Netzwerk einen weltweiten öffentlichen Endpunkt zur Verfügung.
Dies wäre die Haustür, damit die Postboten die Briefe zustellen können. -
Anwendungs-Gateway: Leitet den Datenverkehr von unserem öffentlichen Frontend zu unserem Container.
Jede Villa braucht einen Butler, der (die Tür hört und öffnet), Pakete von bestimmten Postboten entgegennimmt und sie dem entsprechenden Gast zustellt. -
Netzwerk-Profil: Ermöglicht es einer Container-Instanz (ohne öffentliche IP), mit dem Subnetz zu kommunizieren, in dem sie sich befindet (so funktioniert Azure).
Aber dies ist ein großes Haus mit vielen Zimmern (Subnetzen). So beanspruchen Sie Ihr eigenes. -
Netzwerksicherheitsgruppe (nsg): Sie fungiert als eine Art Firewall, indem sie den Datenverkehr in/aus Subnetzen zulässt/verweigert. Sie stellt eine zusätzliche Sicherheitsebene für unseren Container dar.
Stellen Sie sich einen speziellen Laserzaun um Ihr Zimmer vor, der nur bestimmten Personen (wie dem Butler) den Zutritt erlaubt.
Zusammenfassend lässt sich das Verhalten wie folgt beschreiben:
Wir haben zwei Subnetze: ein öffentliches und ein privates.
Der Container (nginx) befindet sich im privaten Subnetz, wo niemand außerhalb des vnet darauf zugreifen kann (die Netzwerksicherheitsgruppe kümmert sich darum).
Im öffentlichen Subnetz platzieren wir das Anwendungsgateway, das den Datenverkehr an unseren Container weiterleitet und ihn so erreichbar macht, aber dennoch vor direktem Zugriff von außen schützt.
Ein externer Computer stellt eine Anfrage an die öffentliche IP-Adresse auf Port 80. Das Anwendungs-Gateway nimmt die Anfrage entgegen, leitet sie an die nginx-Instanz weiter, holt die Antwort ab und sendet sie an den Anfragenden zurück.
Einsatz von Komponenten
Die Einsätze werden mit Hilfe von Arm-Templates spezifiziert und über das Tool der Befehlszeilenschnittstelle als eingesetzt:
$ az group deployment create --resource-group--template-file
Ein schöner Vorteil von Vorlagendateien ist die Möglichkeit, mehr als eine Ressource in einem einzigen Durchgang einzusetzen. Wir könnten sogar das gesamte Projekt in einer einzigen Vorlagendatei angeben, wenn wir das möchten.
Der Einfachheit halber verwenden wir in diesem Beispiel jedoch getrennte Dateien.
Jeder Einsatzabschnitt enthält Vorlagenschnipsel (die Ressourcen). Ob Sie sie alle in einer einzigen Vorlagendatei zusammenfassen oder getrennt verwalten, bleibt ganz dem Leser überlassen.
Hinweis: Alle Werte in den Schnipseln sind fest codiert, um sie besser lesbar zu machen. Einige Werte können (und sollten) als Parameter in einer Parameterdatei angegeben werden. Insbesondere, wenn es sich um gesicherte Zeichenketten wie Kennwörter/Schlüssel handelt. Aber das werden wir in einem anderen Beitrag behandeln. Konzentrieren wir uns erst einmal auf das große Ganze.
Um Abhängigkeitsprobleme zu vermeiden, werden wir die obige Liste ein wenig umstellen. Wir könnten zum Beispiel den Zaun vor der Villa bekommen, aber das spielt keine Rolle. Am Ende wird sich das ganze Bild zusammenfügen.
VNet
Lassen Sie uns nun mit dem vnet, den Subnetzen und der Netzwerksicherheitsgruppe beginnen:
{ "Typ": "Microsoft.Network/networkSecurityGroups", "apiVersion": "2019-07-01", "Name": "mein-privat-nsg", "Standort": "[resourceGroup().location]", "Eigenschaften": null }, { "Typ": "Microsoft.Network/virtualNetworks", "apiVersion": "2019-07-01", "Name": "my-vnet", "Standort": "[resourceGroup().location]", "Eigenschaften": { "addressSpace": { "addressPrefixes": "10.0.0.0/21" }, "Teilnetze": [ { "Name": "öffentlich", "Eigenschaften": { "addressPrefix": "10.0.1.0/24", "privateEndpointNetworkPolicies": "Aktiviert", "privateLinkServiceNetworkPolicies": "Aktiviert" } }, { "Name": "privat", "Eigenschaften": { "addressPrefix": "10.0.2.0/24", "networkSecurityGroup": { "id": "[resourceId('Microsoft.Network/networkSecurityGroups', 'my-private-nsg')]" }, "Delegationen": [ { "Name": "private-subnet-delegation", "Eigenschaften": { "Dienstname": "Microsoft.ContainerInstance/containerGroups" } } ], "privateEndpointNetworkPolicies": "Aktiviert", "privateLinkServiceNetworkPolicies": "Aktiviert" } } ], "enableDdosProtection": false, "enableVmProtection": false }, "hängt ab von": [ "mein-privat-nsg" ] }
Hier haben wir ein vnet im Raum (10.0.0.0/21) und die beiden Subnetze in CIDR-Notation definiert:
- Öffentliches Teilnetz in 10.0.1.0/24
- Privates Teilnetz in 10.0.2.0/24
(wir verwenden drei Bits für das Subnetting. Für dieses Beispiel hätte jedoch auch ein einziges Bit ausgereicht).
Beachten Sie, dass das private Subnetz an Microsoft.ContainerInstance/containerGroups delegiert. Dies wird von Azure benötigt, um Container-Instanzen in dem Subnetz bereitstellen zu können. Die Delegierung impliziert auch, dass nur Containergruppen in diesem Subnetz eingesetzt werden können(von Azure erzwungen).
Wir haben die my-private-nsg dem privaten Subnetz zugewiesen (der Zaun ist installiert). Wir haben jedoch keine Regeln für das Netz festgelegt. Und warum? Denn wir verlassen uns darauf, dass dieser nsg einfach allen Datenverkehr verweigert, der nicht aus dem vnet stammt. Da diese Regeln standardmäßig in Azure enthalten sind, ist nichts weiter erforderlich.
Öffentliche IP-Adresse
Wir kündigen uns der Welt an:
{ "Typ": "Microsoft.Network/publicIPAddresses", "apiVersion": "2019-07-01", "Name": "mein-ip", "Standort": "[resourceGroup().location]", "sku": { "Name": "Standard", "Stufe": "Regional" }, "Eigenschaften": { "publicIPAddressVersion": "IPv4", "publicIPAllocationMethod": "Statisch", "LeerlaufZeitlimitInMinuten": 4, "dnsSettings": { "domainNameLabel": "nginx-demo" } } }
In diesem Beispiel geben wir dieser öffentlichen IP ein Domain-Namen-Label, d.h. wir können darauf zugreifen - sobald sie eingerichtet ist - über einen richtigen Domain-Namen anstelle der IP-Adresse selbst.
Anwendungs-Gateway
Wir müssen nun den Datenverkehr vom öffentlichen Teilnetz zum privaten Teilnetz leiten:
{ "Typ": "Microsoft.Network/applicationGateways", "apiVersion": "2019-08-01", "Name": "my-ag", "Standort": "[resourceGroup().location]", "Eigenschaften": { "sku": { "Name": "Standard_v2", "Stufe": "Standard_v2" }, "gatewayIPKonfigurationen": [ { "Name": "mein-gateway-ip-konfig", "Eigenschaften": { "Teilnetz": { "id": "[resourceId('Microsoft.Network/virtualNetworks/subnets', 'my-vnet', 'public')]" } } } ], "frontendIPKonfigurationen": [ { "Name": "my-gateway-frontend-ip-config", "Eigenschaften": { "privateIPAllocationMethod": "Dynamisch", "publicIPAddress": { "id": "[resourceId('Microsoft.Network/publicIPAddresses', 'my-ip')]", } } } ], "frontendPorts": [ { "Name": "port-80", "Eigenschaften": { "Hafen": 80 } } ], "backendAddressPools": [ { "Name": "nginx-backend-pool", "Eigenschaften": { "backendAddresses": [ { "ipAdresse": "10.0.2.4" } ] } } ], "backendHttpSettingsCollection": [ { "Name": "nginx-http", "Eigenschaften": { "Hafen": 80, "Protokoll": "Http", "cookieBasedAffinity": "Deaktiviert", "pickHostNameFromBackendAddress": false, "requestTimeout": 20 } } ], "httpListener": [ { "Name": "port-80-listener", "Eigenschaften": { "frontendIPKonfiguration": { "id": "[resourceId('Microsoft.Network/applicationGateways/frontendIPConfigurations', 'my-ag', 'my-gateway-frontend-ip-config')]" }, "frontendPort": { "id": "[resourceId('Microsoft.Network/applicationGateways/frontendPorts', 'nginx-ag', 'port-80')]" }, "Protokoll": "Http", "requireServerNameIndication": false } } ], "requestRoutingRules": [ { "Name": "umleiten-zu-nginx-webserver", "Eigenschaften": { "ruleType": "Einfach", "httpListener": { "id": "[resourceId('Microsoft.Network/applicationGateways/httpListeners', 'my-ag', 'port-80-listener')]" }, "backendAddressPool": { "id": "[resourceId('Microsoft.Network/applicationGateways/backendAddressPools', 'my-ag', 'nginx-backend-pool')]" }, "backendHttpSettings": { "id": "[resourceId('Microsoft.Network/applicationGateways/backendHttpSettingsCollection', 'my-ag', 'nginx-http')]" } } } ], "enableHttp2": false, "autoscaleConfiguration": { "minCapacity": 0, "maxKapazität": 10 } } }
Wir haben nur einen Backend-Pool, der auf die IP-Adresse 10.0.2.4 zeigt. Dies ist die IP-Adresse, die später der Container-Instanz zugewiesen wird. Sie können jede beliebige IP-Adresse wählen, solange sie sich im richtigen Subnetz (in diesem Fall dem privaten) befindet und nicht von Azure reserviert wurde.
Netzwerk-Profil
Noch eine und wir sind fertig mit dem Netzwerk. Diese Komponente ist sehr wichtig.
Denken Sie daran, dass wir damit die Containergruppe im privaten Subnetz platzieren werden.
{ "Typ": "Microsoft.Netzwerk/Netzwerkdateien", "apiVersion": "2018-07-01", "Name": "Mein-Netz-Profil", "Standort": "[resourceGroup().location]", "Eigenschaften": { "containerNetworkInterfaceConfigurations": [ { "Name": "my-cnic", "Eigenschaften": { "ipKonfigurationen": [ { "Name": "mein-ip-konfigurationsprofil", "Eigenschaften": { "Teilnetz": { "id": "[resourceId('Microsoft.Network/virtualNetworks/subnets', 'nginx-vnet', 'private')]" } } } ] } } ] } }
Hervorragend. Das Netzwerk ist jetzt bereit!
Container
Nun gut. Die Netzwerkinfrastruktur ist fertig und funktioniert. Jetzt ist es an der Zeit, den Container einzusetzen.
{ "Name": "nginx", "Typ": "Microsoft.ContainerInstance/containerGroups", "apiVersion": "2018-10-01", "Standort": "[resourceGroup().location]", "Eigenschaften": { "Container": [ { "Name": "nginx", "Eigenschaften": { "Bild": "nginx", "Häfen": [{ "Hafen": 80 }], "Ressourcen": { "Anfragen": { "memoryInGB": 1, "cpu": 2 } } } } ], "osType": "Linux", "ipAdresse": { "Häfen": [{ "Protokoll": "tcp", "Hafen": 80 }], "Typ": "privat", "ip": "10.0.2.4" }, "NetzwerkProfil": { "id": "[resourceId('Microsoft.Network/networkProfiles', 'my-net-profile')]" } } }
Bei der Erstellung des Anwendungs-Gateways haben wir den Backend-Pool auf 10.0.2.4 festgelegt, erinnern Sie sich? Daher muss die private IP der Instanz mit dieser Konfiguration übereinstimmen (andernfalls würde nginx keinen Datenverkehr empfangen). Dies wird eine statische Adresse für die Containergruppe sein.
Da es sich um eine interne Adresse handelt, ist das völlig in Ordnung (es ist egal, in welchem Bett Sie schlafen, solange es in Ihrem Zimmer steht).
Testen der Lösung
Alles bereit! Es ist Zeit, die ganze Maschinerie zu testen!
Öffnen Sie einen Browser und gehen Sie zu nginx-demo.westeurope.cloudapp.azure.com.
Wir sollten die nginx-Indexseite sehen:
Bumm! Herzlichen Glückwunsch: Sie haben jetzt ein lauffähiges nginx in einer Container-Instanz in Azure.
Schlussfolgerungen
Wir haben erfolgreich einen nginx-Webserver als Container-Instanzen innerhalb eines privaten Subnetzes eingesetzt. Gut gemacht!
Unsere Ideen
Weitere Blogs
Contact



