Windows Server-Images für mehrere Architekturen erstellen

Standard

In dieser Anleitung wird gezeigt, wie Sie die Komplexität der Versionsverwaltung beim Erstellen von Images verwalten, die auf mehrere Windows Server-Versionen ausgerichtet sind. Windows Server-Container enthalten Versionskompatibilitätsanforderungen, die verhindern, dass Container auf mehr als einer Windows Server-Hostversion ausgeführt werden. Allerdings unterstützt Docker auf Windows Server Container-Images für mehrere Architekturen, die über mehrere Windows Server-Versionen ausgeführt werden können.

Mit Images für mehrere Architekturen können Sie den Windows Server-Knotenpool von Google Kubernetes Engine auf Ihre bevorzugte Windows Server-Version aktualisieren, ohne das Image neu erstellen und die Pod-Spezifikationen ändern zu müssen. Beispiel:

Die GKE-Version 1.15 unterstützt Windows Server 1809
Die GKE-Version 1.16 unterstützt Windows Server 1909

Für ein automatisches Upgrade von einer GKE-Version auf eine neuere Version müssen Sie Images für mehrere Architekturen für Ihre Windows-Arbeitslasten erstellen. Zum Erstellen eines Images für mehrere Architekturen müssen Sie für jede Windows Server-Version ein Image erstellen und dann ein Manifest erstellen, das auf diese Images für jede Windows Server-Version verweist. Sie können die Images manuell erstellen, wenn Sie das Image und den Erstellungsprozess vollständig kontrollieren möchten. Alternativ können Sie Cloud Build verwenden, um die Images für mehrere Architekturen von Windows Server automatisch zu erstellen.

Ziele

In dieser Anleitung erfahren Sie, wie Sie Windows Server-Images für mehrere Architekturen manuell oder mithilfe von Cloud Build erstellen.

Images manuell erstellen:
- Erstellen Sie zwei Docker-Images mit verschiedenen Versionen oder Typen von Windows Server, z. B. Langfristiger Service-Kanal (LTSC) und Halbjährlicher Kanal (SAC).
- Erstellen Sie eine Windows Server-VM.
- Erstellen Sie ein Manifest und übertragen Sie es in die Registry.
Erstellen Sie die Images mit Cloud Build:
- Bereiten Sie Ihre Umgebung vor, indem Sie ein Projekt erstellen, APIs aktivieren und Berechtigungen gewähren.
- Erstellen Sie eine Anwendung, Dockerfiles und Build-Dateien.
- Führen Sie einen Befehl aus, um das Image zu erstellen.

Kosten

In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Nach Abschluss der in diesem Dokument beschriebenen Aufgaben können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

Vorbereitung

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

Installieren Sie das Google Cloud CLI, um gcloud-Befehle auszuführen.
Installieren Sie Docker, um Container zu erstellen.
Installieren Sie Go, um Binärdateien von Windows Server zu erstellen.
In dieser Anleitung wird Artifact Registry als Repository verwendet. Prüfen Sie, ob das Docker-Repository erstellt wurde.

Images für mehrere Architekturen manuell erstellen

Durch das manuelle Erstellen von Images für mehrere Architekturen können Sie ein Image erstellen, das alle erforderlichen Windows Server-Versionen enthält. So erstellen Sie ein Image für mehrere Architekturen:

Erstellen Sie ein LTSC 2019-Docker-Image für eine Architektur. Weitere Informationen zum Erstellen von Docker-Images finden Sie unter Windows Server-Anwendung bereitstellen. Beispiel: us-docker.pkg.dev/my-project/docker-repo/foo:1.0-2019.
Erstellen Sie ein LTSC 2022-Docker-Image für eine Architektur. Beispiel: us-docker.pkg.dev/my-project/docker-repo/foo:1.0-2022
Erstellen Sie ein SAC 20H2-Docker-Image für eine Architektur. Beispiel: us-docker.pkg.dev/my-project/docker-repo/foo:1.0-20h2.
Erstellen Sie eine Windows Server-VM, zum Beispiel Version 20H2. Kurzanleitung: Windows Server-VM verwenden
Stellen Sie eine RDP-Verbindung zur VM her.
Öffnen Sie ein PowerShell-Fenster, um die Befehle in den nächsten Schritten auszuführen.
Aktivieren Sie das experimentelle Feature docker manifest. Ein Docker-Manifest ist eine Liste von Images, die in eine Registry hochgeladen werden:
```
PS C:\> $env:DOCKER_CLI_EXPERIMENTAL = 'enabled'
```

Erstellen Sie das Manifest für mehrere Architekturen:

docker manifest create `
  REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/foo:1.0 `
  REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/foo:1.0-2019 `
  REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/foo:1.0-2022 `
  REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/foo:1.0-20h2

Übertragen Sie das neu erstellte Image-Manifest für mehrere Architekturen per Push in Ihr Artifact Registry-Repository:
```
 docker manifest push `
   REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/foo:1.0
```
Wenn Sie prüfen möchten, ob das Image für mehrere Architekturen erfolgreich erstellt und übertragen wurde, rufen Sie REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/foo auf und klicken auf dieses Image. Sie sehen die drei Images darin:
- foo:1.0-2019
- foo:1.0-2022
- foo:1.0-20h2
- foo:1.0

Verweisen Sie jetzt in den Pod-Spezifikationen auf das Multiarch-Image REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/foo:1.0. Auf diese Weise können Sie die automatische Aktualisierung für Ihre GKE-Windows-Knotenpools sicher verwenden.

Images für mehrere Architekturen mit dem gke-windows-builder von Cloud Build erstellen

Sie können den Befehl gke-windows-builder basierend auf dem OSS-gke-windows-builder nutzen, um die manuellen Build-Schritte zu vereinfachen. Sie können gke-windows-builder mit Cloud Build verwenden, um die Windows Server-Multiarch-Images automatisch zu erstellen. GKE aktualisiert den Builder so, dass er neue unterstützte Windows-SAC- und LTSC-Versionen enthält, sobald sie veröffentlicht werden. Ein weiterer Vorteil des Builders besteht darin, dass Sie keine eigene Windows-VM mit Powershell erstellen müssen, um die Images zu erstellen. Die Windows-VM wird durch einen Docker-Container ersetzt, der die Befehle für Sie in Cloud Build ausführt.

Dieses Beispiel zeigt, wie das Builder-Image „Hello World” für mehrere Architekturen erstellt wird, damit Sie wissen, wie der Builder funktioniert. Diese Schritte können auf Linux- oder Windows-Servern ausgeführt werden.

Umgebung vorbereiten

Führen Sie die folgenden Schritte aus, um die Umgebung vorzubereiten:

Erstellen Sie ein Workspace-Verzeichnis auf Ihrem Computer. Beispiel: ~/gke-windows-builder/hello-world.
Erstellen oder wählen Sie ein Projekt für diese Anleitung aus.
Achten Sie darauf, dass für Ihr Projekt die Abrechnung aktiviert ist.
Aktivieren Sie die Compute Engine API, die Cloud Build API und die Artifact Registry API für Ihr Projekt. Der gke-windows-builder wird mit Cloud Build aufgerufen und die resultierenden Container-Images für mehrere Architekturen werden in Artifact Registry übertragen. Compute Engine ist erforderlich, damit der Builder Windows Server-VMs erstellen und verwalten kann.
```
gcloud services enable compute.googleapis.com cloudbuild.googleapis.com \
  artifactregistry.googleapis.com cloudbuild.googleapis.com
```

Weisen Sie Ihrem Cloud Build-Dienstkonto die folgenden Identitäts- und Zugriffsverwaltungsrollen mithilfe der Google Cloud CLI zu:

Variabeln festlegen:

export PROJECT=$(gcloud info --format='value(config.project)')
export MEMBER=$(gcloud projects describe $PROJECT --format 'value(projectNumber)')@cloudbuild.gserviceaccount.com

Weisen Sie Rollen zu. Diese Rollen sind für den Builder erforderlich, um die Windows Server-VMs zu erstellen, den Arbeitsbereich in einen Cloud Storage-Bucket zu kopieren, die Netzwerke für die Erstellung des Docker-Image zu konfigurieren und das entstehende Image per Push in Artifact Registry zu übertragen.

gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:$MEMBER --role='roles/compute.instanceAdmin'
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:$MEMBER --role='roles/iam.serviceAccountUser'
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:$MEMBER --role='roles/compute.networkViewer'
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:$MEMBER --role='roles/storage.admin'
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:$MEMBER --role='roles/artifactregistry.writer'

Fügen Sie eine Firewallregel mit dem Namen allow-winrm-ingress hinzu, damit WinRM eine Verbindung zu Windows Server-VMs zum Ausführen eines Docker-Builds herstellen kann:

Hinweis: Der Name der Firewallregel muss allow-winrm-ingress sein, da gke-windows-builder anhand dieses Namens prüft, ob diese Firewallregel existiert.
```
gcloud compute firewall-rules create allow-winrm-ingress --allow=tcp:5986 --direction=INGRESS
```
Erstellen Sie in Artifact Registry ein Docker-Repository für Ihr Projekt. Wenn Sie bisher noch keine Docker-Repositories in Artifact Registry verwendet haben, führen Sie zuerst die Kurzanleitung für Docker aus. Führen Sie den folgenden Befehl aus, um das Repository zu erstellen:
```
gcloud artifacts repositories create REPOSITORY \
  --repository-format=docker --location=REGISTRY_REGION \
  --description="Docker repository"
```
Ersetzen Sie dabei Folgendes:
- REPOSITORY: ein Name wie windows-multi-arch-images.
- REGISTRY_REGION: ein gültiger Artifact Registry-Speicherort.

hello.exe-Binärdatei im Arbeitsbereich erstellen

Erstellen Sie für diese Anleitung eine einfache „Hello World”-Anwendung, geschrieben in Go. Der Code für die Beispielanwendung befindet sich auf GitHub.

Klonen Sie das Repository mit dem Beispielcode für diese Anleitung mithilfe der folgenden Befehle auf Ihren lokalen Computer:

 git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
 cd kubernetes-engine-samples/windows/windows-multi-arch

Die Datei hello.go gibt den Text „Hello World” aus:

package main

import "fmt"

func main() {
	fmt.Println("Hello World!")
}

Generieren Sie die Binärdatei hello.exe:
```
GOOS=windows go build hello.go
```

Die Binärdatei hello.exe wird in Ihrem Arbeitsbereich angezeigt.

Dockerfile und Dateien in Ihrem Arbeitsbereich erstellen

In diesem Abschnitt erstellen Sie mit einem Dockerfile ein Windows Server-Image für eine Architektur und verwenden dann eine Build-Datei, um Cloud Build auszulösen. Der Build kombiniert die Images für eine Architektur zu einem Image für mehrere Architekturen.

Die Dockerfile ist ein Textdokument, das Anweisungen für das Erstellen eines Images durch Docker enthält. Der gke-windows-builder ersetzt WINDOWS_VERSION durch eine bestimmte Windows Server-Version, für die das Image erstellt werden soll. Der Builder führt docker build -t multi-arch-helloworld:latest_20h2 --build-arg WINDOWS_VERSION=20H2 . beispielsweise unter Windows Server 20H2 aus.
```
ARG WINDOWS_VERSION=
FROM mcr.microsoft.com/windows/servercore:${WINDOWS_VERSION}
COPY hello.exe /hello.exe
USER ContainerUser
ENTRYPOINT ["hello.exe"]
```

Im selben Verzeichnis, das die Datei Dockerfile enthält, ist die Datei cloudbuild.yaml Ihre Build-Konfigurationsdatei. Ersetzen Sie <REPOSITORY> und <REGISTRY_REGION> durch den Namen und die Region des Artifact Registry-Repositorys, das Sie im vorherigen Schritt erstellt haben. Bei der Build-Erstellung ersetzt Cloud Build $PROJECT_ID automatisch durch Ihre Projekt-ID.

timeout: 3600s
steps:
- name: 'us-docker.pkg.dev/gke-windows-tools/docker-repo/gke-windows-builder:latest'
  args:
  - --container-image-name
  # Replace <REGISTRY_REGION> and <REPOSITORY>.
  - '<REGISTRY_REGION>-docker.pkg.dev/$PROJECT_ID/<REPOSITORY>/multiarch-helloworld:latest'
  # Specify specific variants of images to be built. Or, remove the following 2 lines to default to all available variants.
  - --versions
  - '20H2,ltsc2019'

Image erstellen

Jetzt können Sie das Image erstellen und Ihre Logs anzeigen, um einen erfolgreichen Build zu prüfen.

Um das Image zu erstellen, führen Sie den folgenden Befehl aus:
```
gcloud builds submit --config=cloudbuild.yaml .
```
Hinweis: Die Ausführung dieses Befehls kann mehrere Minuten dauern.

Sie sehen Logs wie das folgende Beispiel. Die letzte Zeile im Log zeigt, dass der Build erfolgreich war:

Creating temporary tarball archive of 2 file(s) totalling 492 bytes before compression.
Uploading tarball of [.] to [gs://PROJECT_ID_cloudbuild/source/1600082502.509759-b949721a922d462c94a75da9be9f1181.tgz]
Created [https://cloudbuild.googleapis.com/v1/projects/PROJECT_ID/builds/ec333452-1301-47e8-90e2-716aeb2f5650].
Logs are available at [https://console.cloud.google.com/cloud-build/builds/ec333452-1301-47e8-90e2-716aeb2f5650?project=840737568665].
------------------------ REMOTE BUILD OUTPUT---------------------------------------
...
...

Created manifest list REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/multiarch-helloworld:latest
sha256:3ecbbc9f5144f358f81f7c7f1a7e28f069c98423d59c40eaff72bf184af0be02
2020/09/14 11:34:25 Instance: 35.184.178.49 shut down successfully
PUSH
DONE
-----------------------------------------------------------------------------------

ID                                    CREATE_TIME                DURATION  SOURCE                                                                                      IMAGES  STATUS
ec333452-1301-47e8-90e2-716aeb2f5650  2020-09-14T11:21:43+00:00  12M43S    gs://PROJECT_ID_cloudbuild/source/1600082502.509759-b949721a922d462c94a75da9be9f1181.tgz  -                 SUCCESS

Sie haben das Image mit der Build-Konfigurationsdatei erstellt und es in Artifact Registry unter REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/multiarch-helloworld:latest verschoben.

Image bereitstellen

Unter Windows Server-Anwendung bereitstellen erfahren Sie, wie Sie das Windows-Image für mehrere Architekturen in einem Cluster bereitstellen.

Erweiterte Verwendung von gke-windows-builder

Sie können das Verhalten des gke-windows-builders anpassen, indem Sie dem Abschnitt args der Build-Konfigurationsdatei cloudbuild.yaml Flags hinzufügen. Einige Flags für häufiges Verhalten werden in diesem Abschnitt beschrieben. Diese Liste ist jedoch nicht vollständig. Um die vollständige Liste der Flags zu sehen, die gke-windows-builder unterstützt, führen Sie den folgenden Befehl auf einem Linux-Server oder in Cloud Shell aus:

docker run -it us-docker.pkg.dev/gke-windows-tools/docker-repo/gke-windows-builder:latest --help

Zur Beschleunigung Ihrer Builds können Sie einen größeren Maschinentyp für die Windows-Instanzen verwenden:

  - --machineType
  - 'n1-standard-8'

Anstatt das Image für alle von GKE unterstützten Windows-Versionen zu erstellen, können Sie mit dem Flag --versions bestimmte Windows Server-Versionen auswählen, für die Builds erstellt werden sollen:

  - --versions
  - '20H2,ltsc2019'

Wenn Ihr Arbeitsbereich viele Dateien hat, ist der Image-Build zuverlässiger, wenn Sie den Builder zum Kopieren des Arbeitsbereichs über Cloud Storage statt WinRM konfigurieren. Erstellen Sie einen Bucket in Ihrem Projekt, z. B. gs://{your project}_builder, und legen Sie dann das Flag --workspace-bucket fest:

  - --workspace-bucket
  - '{your project}_builder'

Verwenden Sie zum Ausführen der Windows-Builder-Instanzen in einem freigegebenen VPC-Dienstprojekt folgende Flags, die die Netzwerkeinrichtung der Instanz steuern:

  - --subnetwork-project
  - 'shared-vpc-host-project'
  - --subnetwork
  - 'host-project-subnet-shared-with-service-project'

Bereinigen

Nachdem Sie die Anleitung abgeschlossen haben, können Sie die erstellten Ressourcen bereinigen, damit sie keine Kontingente mehr nutzen und keine Gebühren mehr anfallen. In den folgenden Abschnitten erfahren Sie, wie Sie diese Ressourcen löschen oder deaktivieren.

Image löschen

Informationen zum Löschen der multiarch-helloworld-Images in Artifact Registry finden Sie unter Images löschen.

Projekt löschen

Am einfachsten vermeiden Sie weitere Kosten, wenn Sie das zum Ausführen der Anleitung erstellte Projekt löschen.

So löschen Sie das Projekt:

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:

Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.

Wenn Sie mehrere Architekturen, Anleitungen und Kurzanleitungen durcharbeiten möchten, können Sie die Überschreitung von Projektkontingenten verhindern, indem Sie Projekte wiederverwenden.

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

Nächste Schritte

Weitere Kubernetes-Anleitungen
Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center