Im vorigen Beitrag wurde gezeigt, wie Sie einen unsicheren Service Fabric-Testcluster in Azure erstellen und einen Windows-Container darauf ausführen können. In diesem Folgebeitrag zeige ich Ihnen, was innerhalb des Clusters vor sich geht, indem ich die Docker-Befehlszeile verwende. Das Wissen darüber kann bei der Fehlersuche sehr nützlich sein.
Überprüfen Sie, ob Ihr Container läuft
Dadurch wird eine Umgebungsvariable gesetzt, die festlegt, von wo aus der Docker-Dienst erreicht werden kann.
Prüfen Sie nun, ob Docker gestartet ist und läuft, indem Sie eingeben:
Docker-Version
Dieser Befehl zeigt die aktuelle Version von Docker an, die zur Zeit 1.12 ist.
Nächste Eingabe:
docker ps -no-trunc
Dieser Befehl listet alle laufenden Container auf, wobei die Informationen für die Anzeige nicht gekürzt werden.
Das Ergebnis sollte in etwa so aussehen:
Es zeigt Informationen über Ihre laufenden Container an. Einige wichtige Elemente hier sind:
- Container-ID - die Sie verwenden können, um Operationen mit einem bestimmten Container durchzuführen
- Ports - Gibt an, dass Port 80 innerhalb des Containers offengelegt und veröffentlicht ist (beachten Sie, dass dieser Wert fehlt, wenn Ihr Image nicht explizit einen Port offenlegt).
- Befehl - der anzeigt, was beim Start des Containers ausgeführt wurde. In diesem Fall der w3svc-Dienst und PowerShell.(Beachten Sie, dass PowerShell in der Datei ServiceManifest.xml in Teil 1 konfiguriert wurde).
Überprüfen Sie, ob der IIS läuft
Wenn Sie überprüfen wollen, ob der IIS läuft, können Sie nicht einfach die Seite https://xebia.com/blog in Ihrem Browser öffnen (zur Zeit), da es ein Problem mit WinNAT gibt. Sie können die IP-Adresse des Windows-Containers verwenden. Um diese zu finden, geben Sie ein:
docker inspect -f "{{ .NetworkSettings.Networks.nat.IPAddress }}" c8e5
Beachten Sie, dass 'c8e5' der Anfang der Container-ID meines laufenden Containers ist, so dass sie in Ihrer Situation anders sein wird.
Das Ergebnis sollte in etwa so aussehen:
Es zeigt die IP-Adresse Ihres laufenden Containers an. In meiner Umgebung lautet sie
Öffnen Sie den Internet Explorer und navigieren Sie zu dieser IP-Adresse, und Sie sollten die bekannte IIS-Startseite sehen. Das funktioniert, weil Port 80 in meinem Bild loekd/iis als offen definiert wurde.
Aktivieren Sie Remote Desktop für Cluster-Knoten
Wenn Sie den RDP-Zugriff auf jeden Knoten im Cluster aktivieren möchten (auch wenn dieser nach oben und unten skaliert), können Sie dies in Ihrer ARM-Vorlage angeben. (In meiner Beispielvorlage ist dies bereits konfiguriert.)
Beachten Sie, dass dies den RDP-Zugang über das Internet offenlegt, was Auswirkungen auf die Sicherheit hat. Verwenden Sie sichere Kennwörter für das Anmeldekonto. Erwägen Sie die Verwendung einer Netzwerksicherheitsgruppe oder einer nicht öffentlichen IP-Adresse, um den Zugriff zu beschränken.
Der relevante Teil der ARM-Vorlage lautet wie folgt:
"inboundNatPools": [
{
"Name": "LoadBalancerBEAddressNatPool",
"Eigenschaften": {
"backendPort": "3389",
"frontendIPKonfiguration": {
"id": "[variables('lbIPConfig0')]"
},
"frontendPortRangeEnd": "4500",
"frontendPortRangeStart": "3389",
"Protokoll": "tcp"
}
}]
Mit dieser Tempatendefinition wird der Azure Load Balancer so konfiguriert, dass er die Internet-Ports 3389 und höher an bestimmte VMSS-Knoten weiterleitet. Der erste Knoten erhält den Port 3389, der zweite den Port 3390 und so weiter.
Load Balancer-Regeln, die Internet-Ports auf verschiedene Backend-Knoten-Ports abbilden, werden 'Inbound NAT Rules' genannt.
Im Azure-Portal sollte das Ergebnis der Vorlagenbereitstellung wie folgt aussehen:
In meiner Umgebung habe ich einen Cluster mit drei Knoten, und jeder Knoten ist jetzt über die öffentliche IP-Adresse über seinen eigenen Port erreichbar.
Lesen Sie hier weitere Informationen über Service Fabric und Scale Sets.
In diesem Beitrag habe ich einige Möglichkeiten aufgezeigt, wie Sie überprüfen können, ob Ihre Windows-Container auf Azure Service Fabric korrekt ausgeführt werden.
Verfasst von
Loek Duys
Cloud software architecture
Contact