Anthos-Cluster auf Bare Metal sind jetzt Google Distributed Cloud (nur Software) für Bare Metal. Weitere Informationen finden Sie in der Produktübersicht.

Google Distributed Cloud-Cluster am Edge bereitstellen

In dieser Anleitung wird eine einsatzbereite Lösung vorgestellt, die Google Distributed Cloud und Config Sync verwendet, um Kubernetes-Cluster am Netzwerkrand bereitzustellen. Diese Anleitung richtet sich an Plattformbetreiber und Entwickler. Bevor Sie dieses Dokument lesen, sollten Sie mit den folgenden Technologien und Konzepten vertraut sein:

Ansible-Playbooks.
Edge-Bereitstellungen und ihre Herausforderungen
Mit einem Google Cloud-Projekt arbeiten
Container-Webanwendung bereitstellen
gcloud- und kubectl-Befehlszeilenschnittstellen.

In dieser Anleitung verwenden Sie Compute Engine-VMs, um Knoten zu emulieren, die am Edge bereitgestellt werden, und eine Beispielanwendung für die Kasse als Edge-Arbeitslast. Google Distributed Cloud und Config Sync bieten eine zentralisierte Verwaltung und Steuerung für Ihren Edge-Cluster. Config Sync ruft neue Konfigurationen dynamisch aus GitHub ab und wendet diese Richtlinien und Konfigurationen auf Ihre Cluster an.

Edge-Bereitstellungsarchitektur

Eine Edge-Bereitstellung für den Einzelhandel ist eine gute Möglichkeit, die Architektur zu veranschaulichen, die bei einer typischen Bereitstellung in der Google Distributed Cloud verwendet wird.

Ein Ladengeschäft ist der direkteste Kontaktpunkt zwischen einer Unternehmenseinheit und den Verbrauchern. Softwaresysteme in Geschäften müssen ihre Arbeitslasten ausführen, zeitnahe Updates erhalten und wichtige Messwerte unabhängig vom zentralen Verwaltungssystem des Unternehmens melden. Außerdem müssen diese Softwaresysteme so konzipiert sein, dass sie in Zukunft auf weitere Standorte ausgeweitet werden können. Die Google Distributed Cloud erfüllt zwar alle diese Anforderungen für Ladensoftwaresysteme, das Edge-Profil ermöglicht jedoch einen wichtigen Anwendungsfall: Bereitstellungen in Umgebungen mit begrenzten Hardwareressourcen, z. B. in einer Ladengeschäfts-Website.

Das folgende Diagramm zeigt eine Bereitstellung der verteilten Cloud von Google, bei der das Edge-Profil in einem Einzelhandelsgeschäft verwendet wird:

Google Distributed Cloud-Bereitstellung, bei der das Edge-Profil in einem Einzelhandelsgeschäft verwendet wird

Das obige Diagramm zeigt ein typisches Ladengeschäft. Im Geschäft gibt es intelligente Geräte wie Kartenlesegeräte, Kassensysteme, Kameras und Drucker. Der Shop verfügt außerdem über drei physische Computing-Hardwaregeräte (beschriftet mit Node 1, Node 2 und Node 3). Alle diese Geräte sind mit einem zentralen Netzwerk-Switch verbunden. Die drei Computing-Geräte sind also über ein Layer-2-Netzwerk miteinander verbunden. Die miteinander vernetzten Computing-Geräte bilden die Bare-Metal-Infrastruktur. Die Google Distributed Cloud wird auf jedem der drei Rechengeräte ausgeführt. Diese Geräte haben auch eigenen Laufwerkspeicher und sind für die Datenreplizierung zwischen ihnen konfiguriert, um eine hohe Verfügbarkeit zu gewährleisten.

Das Diagramm zeigt auch die folgenden Hauptkomponenten, die Teil einer Google Distributed Cloud-Bereitstellung sind:

Die Komponente, die als MetalLB gekennzeichnet ist, ist der gebündelte Load Balancer, der mit Google Distributed Cloud bereitgestellt wird.
Mit der Config Sync-Komponente können Sie den Status des Clusters mit Quell-Repositories synchronisieren. Dieses optionale Add-on wird dringend empfohlen und muss separat installiert und konfiguriert werden. Weitere Informationen zum Einrichten von Config Sync und zur Nomenklatur finden Sie in der Config Sync-Dokumentation.
Das Stamm-Repository und das Namespace-Repository, die oben im Diagramm außerhalb des Geschäftsstandorts zu sehen sind, stellen zwei Quell-Repositories dar.

Änderungen am Cluster werden in diese zentralen Quell-Repositories übertragen. Google Distributed Cloud-Bereitstellungen an verschiedenen Edge-Standorten ziehen Updates aus den Quell-Repositories ab. Dieses Verhalten wird durch die Pfeile dargestellt, die die beiden Repositories im Diagramm mit den Config Sync-Komponenten im Google Distributed Cloud-Cluster verbinden, der auf den Geräten ausgeführt wird.
Eine weitere wichtige Komponente, die als Teil des Clusters dargestellt wird, ist die VM-Laufzeit auf GDC. Mit VM Runtime on GDC können Sie vorhandene VM-basierte Arbeitslasten im Cluster ausführen, ohne sie containerisieren zu müssen. In der Dokumentation zu VM Runtime auf GDC wird beschrieben, wie Sie sie aktivieren und Ihre VM-Arbeitslasten im Cluster bereitstellen.
Die Komponente, die als Anwendung gekennzeichnet ist, steht für Software, die vom Einzelhändler im Cluster bereitgestellt wird. Die Point-of-Sale-Anwendung an den Kiosken eines Einzelhandelsgeschäfts könnte ein Beispiel für eine solche Anwendung sein.

Die Kästchen unten im Diagramm stehen für die vielen Geräte (z. B. Kioske, Tablets oder Kameras) in einem Einzelhandelsgeschäft, die alle mit einem zentralen Netzwerk-Switch verbunden sind. Über das lokale Netzwerk im Geschäft können die Anwendungen, die in der Google Distributed Cloud-Bereitstellung ausgeführt werden, diese Geräte erreichen.

Im nächsten Abschnitt sehen Sie die Emulierung dieser Einzelhandels-Bereitstellung in Google Cloud mit Compute Engine-VMs. Diese Emulation verwenden Sie in der folgenden Anleitung, um mit Google Distributed Cloud zu experimentieren.

Bereitstellung eines emulierten Edge in Google Cloud

Das folgende Diagramm zeigt alle Elemente, die Sie in dieser Anleitung in Google Cloud eingerichtet haben. Dieses Diagramm entspricht dem Diagramm für den Einzelhandel aus dem vorherigen Abschnitt. Diese Bereitstellung stellt einen emulierten Edge-Standort dar, an dem die Point-of-Sale-Anwendung bereitgestellt wird. Die Architektur zeigt auch eine einfache Point-of-Sale-Beispielanwendungsarbeitslast, die Sie in dieser Anleitung verwenden. Sie greifen über einen Webbrowser im Kioskmodus auf die Point-of-Sale-Anwendung im Cluster zu.

Architektur der Point-of-Sale-Anwendung und ihre Bereitstellung in einem Google Distributed Cloud-Cluster, der auf Compute Engine-VMs ausgeführt wird

Die drei Compute Engine-VMs (virtuelle Maschinen) im vorherigen Diagramm stehen für die physische Hardware (oder Knoten) an einem typischen Edge-Standort. Diese Hardware wird mit Netzwerk-Switches verbunden, um die Bare-Metal-Infrastruktur zu bilden. In unserer emulierten Umgebung in Google Cloud sind diese VMs über das standardmäßige VPC-Netzwerk (Virtual Private Cloud) im Google Cloud-Projekt miteinander verbunden.

Bei einer typischen Google Distributed Cloud-Installation können Sie eigene Load Balancer konfigurieren. In dieser Anleitung richten Sie jedoch keinen externen Load Balancer ein. Stattdessen verwenden Sie den gebündelten MetalLB-Load Balancer, der mit Google Distributed Cloud installiert ist. Der gebündelte MetalLB-Load Balancer erfordert eine Layer-2-Netzwerkverbindung zwischen den Knoten. So wird die Layer 2-Verbindung zwischen den Compute Engine-VMs durch das Erstellen eines VxLAN-Overlay-Netzwerks über dem standardmäßigen Virtual Private Cloud-Netzwerk (VPC) aktiviert.

Im Rechteck mit der Beschriftung L2-Overlay-Netzwerk (VxLAN) sind die Softwarekomponenten zu sehen, die in den drei Compute Engine-VMs ausgeführt werden. Dieses Rechteck enthält den Google Distributed Cloud-Cluster und einen Reverse-Proxy. Der Cluster wird durch das Rechteck Google Distributed Cloud dargestellt. Dieses Rechteck, das den Cluster darstellt, enthält ein weiteres Rechteck, das als „Kubernetes-Namespace (pos)“ gekennzeichnet ist. Dies stellt einen Kubernetes-Namespace innerhalb des Clusters dar. Alle Komponenten in diesem Kubernetes-Namespace bilden die Point-of-Sale-Anwendung, die im Google Distributed Cloud-Cluster bereitgestellt wird. Die Point-of-Sale-Anwendung hat drei Mikrodienste: API-Server, Inventar und Zahlungen. Alle diese Komponenten zusammen bilden eine "application", die im vorherigen Architekturdiagramm für das Edge-Roll-out dargestellt ist.

Der mitgelieferte MetalLB-Load Balancer des Google Distributed Cloud-Clusters kann nicht direkt von außerhalb der VMs erreicht werden. Das Diagramm zeigt einen NGINX-Reverse-Proxy, der so konfiguriert ist, dass er innerhalb der VMs ausgeführt wird, um Traffic, der bei den Compute Engine-VMs ankommt, an den Load Balancer weiterzuleiten. Dies ist nur eine Lösung für diese Anleitung, bei der die Edge-Knoten mit Google Cloud Compute Engine-VMs emuliert werden. In einem echten Edge-Standort kann dies mit einer geeigneten Netzwerkkonfiguration erfolgen.

Ziele

Mit Compute Engine-VMs eine Bare-Metal-Infrastruktur emulieren, die an einem Edge-Standort ausgeführt wird
Erstellen Sie einen Google Distributed Cloud-Cluster in der emulierten Edge-Infrastruktur.
Verbinden und registrieren Sie den Cluster mit Google Cloud.
Beispiel-Point-of-Sale-Anwendungsarbeitslast auf dem Google Distributed Cloud-Cluster bereitstellen.
Überprüfen und überwachen Sie in der Google Cloud Console die POS-Anwendung, die an Edge-Standorten ausgeführt wird.
Verwenden Sie Config Sync, um die Point-of-Sale-Anwendung zu aktualisieren, die auf dem Google Distributed Cloud-Cluster ausgeführt wird.

Hinweise

Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.

Hinweis: Wenn Sie die Ressourcen, die Sie in diesem Verfahren erstellen, nicht behalten möchten, erstellen Sie ein Projekt, anstatt ein vorhandenes Projekt auszuwählen. Wenn Sie fertig sind, können Sie das Projekt löschen und dadurch alle mit ihm verknüpften Ressourcen entfernen.

Zur Projektauswahl
Die Abrechnung für das Cloud-Projekt muss aktiviert sein. So prüfen Sie, ob die Abrechnung für ein Projekt aktiviert ist.
Installieren und initialisieren Sie die Google Cloud CLI.

Repository „anthos-samples“ verzweigen und klonen

Alle in dieser Anleitung verwendeten Scripts sind im Repository anthos-samples gespeichert. Die Ordnerstruktur unter /anthos-bm-edge-deployment/acm-config-sink entspricht den Anforderungen von Config Sync. Klonen Sie dieses Repository in Ihr eigenes GitHub-Konto, bevor Sie mit den folgenden Schritten fortfahren.

Erstellen Sie ein Konto auf GitHub, falls Sie noch keines haben.
Erstellen Sie ein persönliches Zugriffstoken, das in der Config Sync-Konfiguration verwendet werden soll. Dies ist erforderlich, damit sich die Config Sync-Komponenten im Cluster bei Ihrem GitHub-Konto authentifizieren können, wenn versucht wird, neue Änderungen zu synchronisieren.
1. Wählen Sie nur den Bereich public_repo aus.
2. Speichern Sie das von Ihnen erstellte Zugriffstoken an einem sicheren Ort, um es später zu verwenden.
Erstellen Sie einen Fork des Repositorys anthos-samples in Ihrem eigenen GitHub-Konto:
1. Rufen Sie das Repository „anthos-samples“ auf.
2. Klicken Sie in der oberen rechten Ecke der Seite auf das Symbol Fork.
3. Klicken Sie auf das GitHub-Nutzerkonto, das den Fork des Repositorys enthalten soll. Sie werden automatisch zur Seite mit der Fork-Version des Repositorys anthos-samples weitergeleitet.
Öffnen Sie ein Terminal in der lokalen Umgebung.
Klonen Sie den Fork des Repositorys durch Ausführen des folgenden Befehls, wobei GITHUB_USERNAME der Nutzername für Ihr GitHub-Konto ist:
```
git clone https://github.com/GITHUB_USERNAME/anthos-samples
cd anthos-samples/anthos-bm-edge-deployment
```
Hinweis: Sowohl das Quell-Repository dieser Lösung als auch die Verzweigung dieses Repositorys sind öffentliche Repositories. In diesem Dokument wird die Verwendung eines Zugriffstokens gezeigt, um einen tatsächlichen Anwendungsfall mit einem privaten Repository nachzuahmen.

Workstation-Umgebung einrichten

Für die in diesem Dokument beschriebene Edge-Bereitstellung benötigen Sie eine Workstation mit Zugriff auf das Internet und die folgenden installierten Tools:

Docker
envsubst-Befehlszeilentool (normalerweise unter Linux und anderen Unix-ähnlichen Betriebssystemen vorinstalliert)

Führen Sie alle Befehle in der Anleitung auf der Workstation aus, die Sie in diesem Abschnitt konfigurieren.

Initialisieren Sie die Umgebungsvariablen auf Ihrer Workstation in einer neuen Shell-Instanz:

export PROJECT_ID="PROJECT_ID"
export REGION="us-central1"
export ZONE="us-central1-a"

# port on the admin Compute Engine instance you use to set up an nginx proxy
# this allows to reach the workloads inside the cluster via the VM IP
export PROXY_PORT="8082"

# should be a multiple of 3 since N/3 clusters are created with each having 3 nodes
export GCE_COUNT="3"

# url to the fork of: https://github.com/GoogleCloudPlatform/anthos-samples
export ROOT_REPO_URL="https://github.com/GITHUB_USERNAME/anthos-samples"

# this is the username used to authenticate to your fork of this repository
export SCM_TOKEN_USER="GITHUB_USERNAME"

# access token created in the earlier step
export SCM_TOKEN_TOKEN="ACCESS_TOKEN"

Ersetzen Sie die folgenden Werte:

PROJECT_ID ist Ihre Google Cloud-Projekt-ID.
GITHUB_USERNAME ist Ihr GitHub-Nutzername
ACCESS_TOKEN: das persönliche Zugriffstoken, das Sie für das GitHub-Repository erstellt haben.

Behalten Sie für die anderen Umgebungsvariablen die Standardwerte bei. Sie werden in den folgenden Abschnitten erläutert.

Initialisieren Sie die Google Cloud CLI auf Ihrer Workstation:

gcloud config set project "${PROJECT_ID}"
gcloud services enable compute.googleapis.com

gcloud config set compute/region "${REGION}"
gcloud config set compute/zone "${ZONE}"

Erstellen Sie auf Ihrer Workstation das Google Cloud-Dienstkonto für die Compute Engine-Instanzen. Dieses Script erstellt die JSON-Schlüsseldatei für das neue Dienstkonto unter <REPO_ROOT>/anthos-bm-edge-deployment/build-artifacts/consumer-edge-gsa.json. Außerdem werden der Schlüsselring und der Schlüssel für die Verschlüsselung des SSH-Private-Keys im Cloud Key Management Service eingerichtet.

./scripts/create-primary-gsa.sh

Das folgende Beispiel ist nur ein Teil des Scripts. Wenn Sie das vollständige Script sehen möchten, klicken Sie auf Auf GitHub ansehen.

# ...
EXISTS=$(gcloud iam service-accounts list \
  --filter="email=${GSA_EMAIL}" \
  --format="value(name, disabled)" \
  --project="${PROJECT_ID}")

if [[ -z "${EXISTS}" ]]; then
  echo "GSA [${GSA_EMAIL}]does not exist, creating it"

  # GSA does NOT exist, create
  gcloud iam service-accounts create ${GSA_NAME} \
    --description="GSA used on each Target machine to make gcloud commands" \
    --display-name="target-machine-gsa" \
    --project "${PROJECT_ID}"
else
  if [[ "${EXISTS}" =~ .*"disabled".* ]]; then
    # Found GSA is disabled, enable
    gcloud iam service-accounts enable "${GSA_EMAIL}" --project "${PROJECT_ID}"
  fi
  # otherwise, no need to do anything
fi
# ...

Compute Engine-Instanzen bereitstellen

In diesem Abschnitt erstellen Sie die Compute Engine-VMs, auf denen Google Distributed Cloud installiert wird. Prüfen Sie auch die Verbindung zu diesen VMs, bevor Sie mit dem Installationsabschnitt fortfahren.

Erstellen Sie auf Ihrer Workstation SSH-Schlüssel, die für die Kommunikation zwischen den Compute Engine-Instanzen verwendet werden.
```
ssh-keygen -f ./build-artifacts/consumer-edge-machine
```

Verschlüsseln Sie den privaten SSH-Schlüssel mit dem Cloud Key Management Service.

gcloud kms encrypt \
    --key gdc-ssh-key \
    --keyring gdc-ce-keyring \
    --location global \
    --plaintext-file build-artifacts/consumer-edge-machine \
    --ciphertext-file build-artifacts/consumer-edge-machine.encrypted

Erstellen Sie die Umgebungskonfigurationsdatei .envrc und rufen Sie sie auf. Prüfen Sie nach dem Erstellen der Datei .envrc, ob die Umgebungsvariablen durch die richtigen Werte ersetzt wurden.

envsubst < templates/envrc-template.sh > .envrc
source .envrc

Im Folgenden sehen Sie ein Beispiel für eine .envrc-Datei, die durch Ersetzen der Umgebungsvariablen in der templates/envrc-template.sh-Datei generiert wurde. Die aktualisierten Zeilen sind hervorgehoben:

# GSA Key used for provisioning (result of running ./scripts/create-primary-gsa.sh)
LOCAL_GSA_FILE=$(pwd)/build-artifacts/consumer-edge-gsa.json
export LOCAL_GSA_FILE
# GCP Project ID
export PROJECT_ID="abm-edge-project"
# Bucket to store cluster snapshot information
export SNAPSHOT_GCS="abm-edge-project-cluster-snapshots"

# GCP Project Region (Adjust as desired)
export REGION="us-central1"
# GCP Project Zone (Adjust as desired)
export ZONE="us-central1-a"

# Gitlab Personal Access Token credentials (generated in Quick Start step 2)
export SCM_TOKEN_USER="LarryPage"
export SCM_TOKEN_TOKEN="oo901Sp-FHuzmz__dgl0393atkf69c8L"

# Default Root Repo setup for multiple locations
export ROOT_REPO_URL="https://github.com/LarryPage/anthos-samples"
export ROOT_REPO_BRANCH="main"
export ROOT_REPO_DIR="/anthos-bm-edge-deployment/acm-config-sink"

# OIDC Configuration (off by default)
export OIDC_CLIENT_ID="" # Optional, requires GCP API setup work
export OIDC_CLIENT_SECRET="" # Optional
export OIDC_USER="" # Optional
export OIDC_ENABLED="false" # Flip to true IF implementing OIDC on cluster

Erstellen Sie Compute Engine-Instanzen, auf denen Google Distributed Cloud installiert ist.

./scripts/cloud/create-cloud-gce-baseline.sh -c "$GCE_COUNT" | \
    tee ./build-artifacts/gce-info

Google Distributed Cloud mit Ansible installieren

Das in dieser Anleitung verwendete Skript erstellt Google Distributed Cloud-Cluster in Gruppen von drei Compute Engine-Instanzen. Die Anzahl der erstellten Cluster wird durch die Umgebungsvariable GCE_COUNT gesteuert. Sie legen beispielsweise die Umgebungsvariable GCE_COUNT auf 6 fest, um zwei Google Distributed Cloud-Cluster mit jeweils 3 VM-Instanzen zu erstellen. Standardmäßig ist die Umgebungsvariable GCE_COUNT auf 3 festgelegt. In dieser Anleitung wird daher ein Cluster mit 3 Compute Engine-Instanzen erstellt. Die VM-Instanzen haben das Präfix cnuc-, gefolgt von einer Zahl. Die erste VM-Instanz jedes Clusters fungiert als Administratorworkstation, von der die Installation ausgelöst wird. Der Cluster erhält denselben Namen wie die VM der Administrator-Workstation (z. B. cnuc-1, cnuc-4, cnuc-7).

Das Ansible-Playbook tut Folgendes:

Konfiguriert die Compute Engine-Instanzen mit den erforderlichen Tools, z. B. docker, bmctl, gcloud und nomos.
Installiert die Google Distributed Cloud in den konfigurierten Compute Engine-Instanzen.
Erstellt einen eigenständigen Google Distributed Cloud-Cluster mit dem Namen cnuc-1.
Registriert den Cluster cnuc-1 bei Google Cloud.
Installiert Config Sync im Cluster cnuc-1.
Konfiguriert Config Sync, sodass mit den Clusterkonfigurationen unter anthos-bm-edge-deployment/acm-config-sink in Ihrem verzweigten Repository synchronisiert wird.
Generiert die Login token für den Cluster.

Führen Sie die folgenden Schritte aus, um den Installationsvorgang einzurichten und zu starten:

Erstellen Sie auf Ihrer Workstation das für die Installation verwendete Docker-Image. Dieses Image enthält alle für die Installation erforderlichen Tools, z. B. Ansible, Python und die Google Cloud CLI.

gcloud builds submit --config docker-build/cloudbuild.yaml docker-build/

Wenn der Build erfolgreich ausgeführt wird, wird eine Ausgabe wie die folgende ausgegeben:

...
latest: digest: sha256:99ded20d221a0b2bcd8edf3372c8b1f85d6c1737988b240dd28ea1291f8b151a size: 4498
DONE
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ID                                    CREATE_TIME                DURATION  SOURCE                                                                                         IMAGES                                                  STATUS
2238baa2-1f41-440e-a157-c65900b7666b  2022-08-17T19:28:57+00:00  6M53S     gs://my_project_cloudbuild/source/1660764535.808019-69238d8c870044f0b4b2bde77a16111d.tgz  gcr.io/my_project/consumer-edge-install (+1 more)  SUCCESS

Generieren Sie die Ansible-Inventardatei aus einer Vorlage.

envsubst < templates/inventory-cloud-example.yaml > inventory/gcp.yaml

Führen Sie das Installationsskript aus, das einen Docker-Container aus dem zuvor erstellten Image startet. Das Script verwendet intern Docker, um den Container mit einem Volume-Mount zum aktuellen Arbeitsverzeichnis zu erstellen. Nach erfolgreichem Abschluss dieses Scripts müssen Sie sich im erstellten Docker-Container befinden. Sie starten die Ansible-Installation von diesem Container aus.

./install.sh

Wenn das Script erfolgreich ausgeführt wird, wird eine Ausgabe wie die folgende ausgegeben:

...
Check the values above and if correct, do you want to proceed? (y/N): y
Starting the installation
Pulling docker install image...

==============================
Starting the docker container. You will need to run the following 2 commands (cut-copy-paste)
==============================
1: ./scripts/health-check.sh
2: ansible-playbook all-full-install.yaml -i inventory
3: Type 'exit' to exit the Docker shell after installation
==============================
Thank you for using the quick helper script!
(you are now inside the Docker shell)

Prüfen Sie im Docker-Container den Zugriff auf die Compute Engine-Instanzen.

./scripts/health-check.sh

Wenn das Script erfolgreich ausgeführt wird, sieht die Ausgabe in etwa so aus:

...
cnuc-2 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}
cnuc-3 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}
cnuc-1 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}

Führen Sie im Docker-Container das Ansible-Playbook zur Installation von Google Distributed Cloud auf Compute Engine-Instanzen aus. Nach Abschluss wird die Login Token für den Cluster auf dem Bildschirm angezeigt.

ansible-playbook all-full-install.yaml -i inventory | tee ./build-artifacts/ansible-run.log

Wenn die Installation erfolgreich war, wird eine Ausgabe wie die folgende ausgegeben:

...
TASK [abm-login-token : Display login token] **************************************************************************
ok: [cnuc-1] => {
    "msg": "eyJhbGciOiJSUzI1NiIsImtpZCI6Imk2X3duZ3BzckQyWmszb09sZHFMN0FoWU9mV1kzOWNGZzMyb0x2WlMyalkifQ.eymljZS1hY2NvdW
iZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImVkZ2Etc2EtdG9rZW4tc2R4MmQiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2Nvd
4CwanGlof6s-fbu8"
}
skipping: [cnuc-2]
skipping: [cnuc-3]

PLAY RECAP ***********************************************************************************************************
cnuc-1                     : ok=205  changed=156  unreachable=0    failed=0    skipped=48   rescued=0    ignored=12
cnuc-2                     : ok=128  changed=99   unreachable=0    failed=0    skipped=108  rescued=0    ignored=2
cnuc-3                     : ok=128  changed=99   unreachable=0    failed=0    skipped=108  rescued=0    ignored=2

In der Google Cloud Console beim Google Distributed Cloud-Cluster anmelden

Nachdem das Ansible-Playbook vollständig ausgeführt wurde, wird ein eigenständiger Google Distributed Cloud-Cluster in den Compute Engine-VMs installiert. Dieser Cluster ist auch über den Connect-Agent bei Google Cloud registriert. Wenn Sie jedoch Details zu diesem Cluster sehen möchten, müssen Sie sich über die Google Cloud Console im Cluster anmelden. Führen Sie die folgenden Schritte aus, um sich im GKE-Cluster anzumelden.

Kopieren Sie das Token aus der Ausgabe des Ansible-Playbooks im vorherigen Abschnitt.

Hinweis: Wenn Sie keinen Zugriff mehr auf die Konsolenausgabe haben, sehen Sie in der Protokolldatei unter ./build-artifacts/ansible-run.log nach, um Ihr Token zu erhalten. Sie können auch das folgende Ansible-Playbook ausführen, um das Token noch einmal abzurufen: ansible-playbook all-get-login-tokens.yaml -i inventory
Rufen Sie in der Google Cloud Console die Seite Kubernetes-Cluster auf und verwenden Sie das kopierte Token, um sich im Cluster cnuc-1 anzumelden.

Zur Seite "Kubernetes-Cluster"
1. Klicken Sie in der Liste der Cluster neben dem Cluster cnuc-1 auf Aktionen und dann auf Anmelden.
2. Wählen Sie Token aus und fügen Sie das kopierte Token ein.
3. Klicken Sie auf Login (Anmelden).
Rufen Sie in der Google Cloud Console im Abschnitt Features die Seite Konfiguration auf.

Zu „Config“

Sehen Sie sich auf dem Tab Pakete in der Clustertabelle die Spalte Synchronisierungsstatus an. Prüfen Sie, ob der Status Synchronisiert lautet. Der Status Synchronisiert gibt an, dass Config Sync Ihre GitHub-Konfigurationen erfolgreich mit Ihrem bereitgestellten Cluster cnuc-1 synchronisiert hat.

Proxy für externen Traffic konfigurieren

Der in den vorherigen Schritten installierte Google Distributed Cloud-Cluster verwendet einen gebündelten Load Balancer namens MetalLB. Auf diesen Load-Balancer-Dienst kann nur über eine VPC-IP-Adresse (Virtual Private Cloud) zugegriffen werden. Richten Sie einen Reverse-Proxy-Dienst im Admin-Host (cnuc-1) ein, um den Traffic, der über seine externe IP-Adresse eingeht, an den gebündelten Load Balancer weiterzuleiten. Mit diesem Reverse-Proxy-Dienst können Sie den API-Server der Point-of-Sale-Anwendung über die externe IP-Adresse des Admin-Hosts (cnuc-1) erreichen.

Mit den Installationsscripts in den vorherigen Schritten wurde NGINX zusammen mit einer Beispielkonfigurationsdatei auf den Administratorhosts installiert. Aktualisieren Sie diese Datei, um die IP-Adresse des Load-Balancer-Dienstes zu verwenden, und starten nginx neu.

Melden Sie sich auf Ihrer Workstation über SSH an der Administrator-Workstation an:
```
ssh -F ./build-artifacts/ssh-config abm-admin@cnuc-1
```
Richten Sie auf dem Admin-Arbeitsplatz einen NGINX-Reverse-Proxy ein, um Traffic an den API-Server-Load-Balancer-Dienst weiterzuleiten. Rufen Sie die IP-Adresse des Kubernetes-Dienstes vom Typ „Load Balancer“ ab:
```
ABM_INTERNAL_IP=$(kubectl get services api-server-lb -n pos | awk '{print $4}' | tail -n 1)
```

Aktualisieren Sie die Konfigurationsdatei der Vorlage mit der abgerufenen IP-Adresse:

sudo sh -c "sed 's/<K8_LB_IP>/${ABM_INTERNAL_IP}/g' \
    /etc/nginx/nginx.conf.template > /etc/nginx/nginx.conf"

Starte NGINX neu, damit die neue Konfiguration angewendet wird:
```
sudo systemctl restart nginx
```

Prüfen Sie den Status des NGINX-Servers und achten Sie darauf, dass er „aktiv (in Ausführung)“ meldet:

sudo systemctl status nginx

Wenn NGINX erfolgreich ausgeführt wird, wird eine Ausgabe wie im folgenden Beispiel ausgegeben:

● nginx.service - A high performance web server and a reverse proxy server
    Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
    Active: active (running) since Fri 2021-09-17 02:41:01 UTC; 2s ago
    Docs: man:nginx(8)
    Process: 92571 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
    Process: 92572 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
Main PID: 92573 (nginx)
    Tasks: 17 (limit: 72331)
    Memory: 13.2M
    CGroup: /system.slice/nginx.service
            ├─92573 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
            ├─92574 nginx: worker process
            ├─92575 nginx: worker process
            ├─92577 nginx: ....
            ...
            ...

Beenden Sie die SSH-Sitzung auf der Admin-Workstation.
```
exit
```
Beenden Sie die Shell-Sitzung und kehren Sie zum Docker-Container zurück. Wenn Sie die Admin-Instanz beenden, befinden Sie sich noch im für die Installation verwendeten Docker-Container:
```
exit
```

Auf die Kassenanwendung zugreifen

Mit der externen Proxy-Einrichtung können Sie auf die Anwendung zugreifen, die im GKE-Cluster ausgeführt wird. Führen Sie die folgenden Schritte aus, um auf die Beispiel-POS-Anwendung zuzugreifen.

Rufen Sie auf Ihrer Workstation die externe IP-Adresse der Compute Engine-Admin-Instanz auf und greifen Sie auf die Benutzeroberfläche der Point-of-Sale-Anwendung zu:

EXTERNAL_IP=$(gcloud compute instances list \
    --project ${PROJECT_ID} \
    --filter="name:cnuc-1" \
    --format="get(networkInterfaces[0].accessConfigs[0].natIP)")
echo "Point the browser to: ${EXTERNAL_IP}:${PROXY_PORT}"

Wenn die Skripts erfolgreich ausgeführt werden, produzieren sie in etwa folgende Ausgabe:

Point the browser to: 34.134.194.84:8082

Öffnen Sie Ihren Webbrowser und rufen Sie die IP-Adresse auf, die in der Ausgabe des vorherigen Befehls angezeigt wurde. Sie können auf die Beispiel-Kassenanwendung zugreifen und sie testen, wie im folgenden Beispielscreenshot gezeigt:

API-Server mit Config Sync aktualisieren

Die Beispielanwendung kann auf eine neuere Version aktualisiert werden, indem die Konfigurationsdateien im Stammverzeichnis aktualisiert werden. Config Sync erkennt die Updates und nimmt die Änderungen automatisch an Ihrem Cluster vor. In diesem Beispiel ist das Stamm-Repository das anthos-samples-Repository, das Sie zu Beginn dieses Leitfadens geklont haben. Führen Sie die folgenden Schritte aus, um zu sehen, wie die Beispiel-POS-Anwendung auf eine neuere Version umgestellt werden kann.

Aktualisieren Sie auf Ihrer Workstation das Feld image, um die API-Serverversion von v1 in v2 zu ändern. Die YAML-Konfiguration für das Deployment befindet sich in der Datei unter anthos-bm-edge-deployment/acm-config-sink/namespaces/pos/api-server.yaml.
```
containers:
- name: api-server
  image: us-docker.pkg.dev/anthos-dpe-abm-edge-pos/abm-edge-pos-images/api-server:v1
```

Fügen Sie die Änderungen hinzu, übernehmen Sie sie und übertragen Sie sie per Push in Ihr verzweigtes Repository:

git add acm-config-sink/namespaces/pos/api-server.yaml
git commit -m "chore: updated api-server version to v2"
git push

Rufen Sie in der Google Cloud Console die Seite Config Sync auf, um den Status der Konfigurationsspezifikation zu prüfen. Prüfen Sie, ob der Status Synchronisiert lautet.

Zur Seite „Config Sync“
Rufen Sie in der Google Cloud Console die Seite Kubernetes Engine-Arbeitslasten auf, um nachzusehen, ob das Deployment aktualisiert wurde.

Zur Seite „Kubernetes Engine-Arbeitslasten“
Wenn der Status der Bereitstellung OK lautet, zeigen Sie mit dem Browser die IP-Adresse aus dem vorherigen Abschnitt an, um die Kassenanwendung aufzurufen. Die Version im Titel zeigt „V2“, was darauf hinweist, dass Ihre Anwendungsänderung bereitgestellt wurde, wie im folgenden Beispielscreenshot zu sehen:

Möglicherweise müssen Sie den Browsertab vollständig aktualisieren, damit die Änderungen angezeigt werden.

Bereinigen

Löschen Sie die für diese Anleitung verwendeten Ressourcen, um unnötige Google Cloud-Gebühren zu vermeiden. Sie können diese Ressourcen entweder manuell löschen oder Ihr Google Cloud-Projekt löschen, wodurch auch alle Ressourcen entfernt werden. Darüber hinaus können Sie auch die Änderungen bereinigen, die Sie auf Ihrer lokalen Workstation vorgenommen haben:

Lokale Workstation

Die folgenden Dateien müssen aktualisiert werden, um Änderungen zu löschen, die von den Installationsskripts vorgenommen wurden.

Entfernen Sie die Compute Engine-VM-IP-Adressen, die der Datei /etc/hosts hinzugefügt wurden.
Entfernen Sie die SSH-Konfiguration für cnuc-* in der Datei ~/.ssh/config.
Entfernen Sie die Fingerabdrücke der Compute Engine-VM aus der Datei ~/.ssh/known_hosts.

Projekt löschen

Wenn Sie für dieses Verfahren ein dediziertes Projekt erstellt haben, löschen Sie das Google Cloud-Projekt aus der Google Cloud Console.

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.

Manuell

Wenn Sie für dieses Verfahren ein vorhandenes Projekt verwendet haben, gehen Sie so vor:

Heben Sie die Registrierung aller Kubernetes-Cluster mit einem Namen auf, dem cnuc- vorangestellt ist.
Löschen Sie alle Compute Engine-VMs mit einem Namen, dem das Präfix cnuc- vorangestellt ist.
Löschen Sie den Cloud Storage-Bucket mit einem Namen, dem abm-edge-boot vorangestellt ist.
Löschen Sie die Firewallregeln allow-pod-ingress und allow-pod-egress.
Löschen Sie das Secret Manager-Secret install-pub-key.

Nächste Schritte

Sie können diese Anleitung erweitern, indem Sie einen weiteren Edge-Standort hinzufügen. Wenn Sie die Umgebungsvariable GCE_COUNT auf 6 setzen und dieselben Schritte aus den vorherigen Abschnitten noch einmal ausführen, werden drei neue Compute Engine-Instanzen erstellt (cnuc-4, cnuc-5, cnuc-6) und ein neuer eigenständiger Google Distributed Cloud-Cluster namens cnuc-4.

Sie können auch die Clusterkonfigurationen in Ihrem verzweigten Repository aktualisieren, um selektiv verschiedene Versionen der Point-of-Sale-Anwendung auf die beiden Cluster cnuc-1 und cnuc-4 mit ClusterSelectors anzuwenden.

Weitere Informationen zu den einzelnen Schritten in dieser Anleitung und den betroffenen Skripts finden Sie im Repository anthos-samples.