Wdrażanie klastra AlloyDB Omni o wysokiej dostępności w maszynach wirtualnych GCE za pomocą narzędzia RPM Orchestrator

1. Wprowadzenie

To ćwiczenie pokazuje, jak wdrożyć klaster AlloyDB Omni o wysokiej dostępności w maszynach wirtualnych Google Compute Engine (GCE). Na koniec tych zajęć praktycznych utworzysz architekturę referencyjną o wysokiej dostępności składającą się z 3 węzłów bazy danych i 2 węzłów HAProxy oraz węzła sterującego do operacji zarządzania.

Wymagania wstępne

  • Dostęp do projektu Google Cloud i Cloud Shell z konsoli Google Cloud.
  • Zainstalowany i skonfigurowany pakiet SDK Google Cloud (gcloud). Szczegółowe informacje o instalowaniu gcloud znajdziesz w artykule gcloud-install.
  • Zainstalowano Terraform w wersji v1.9.8.

Czego się nauczysz

  • Jak tworzyć i przygotowywać maszyny wirtualne GCE na potrzeby AlloyDB Omni.
  • Jak zainstalować i uruchomić narzędzie AlloyDB Omni RPM Orchestrator.
  • Instalowanie i konfigurowanie pakietów RPM AlloyDB Omni na potrzeby architektury referencyjnej HA.

Czego potrzebujesz

  • Uzyskaj link URL do pakietów RPM AlloyDB Omni i orkiestratora RPM. Aby to zrobić, musisz wypełnić formularz rejestracyjny AlloyDB Omni. Linki są wysyłane na adres e-mail serwera adresu URL repozytorium. Zainicjuj te zmienne środowiskowe, aby mieć pod ręką adresy URL, które będą używane podczas ćwiczeń z programowania.
    export ORCHESTRATOR_ANSIBLE_COLLECTION_PATH="..."
export ALLOYDB_OMNI_REPOSITORY_URL="..."
export ALLOYDB_OMNI_ORCHESTRATOR_REPOSITORY_URL="..."
export ALLOYDB_OMNI_COMMON_REPOSITORY_URL=....
export ETCD_REPOSITORY_URL="..."
  • Działający terminal z dostępem do stosu wdrożenia AlloyDB Omni. W tym celu możesz użyć Cloud Shell.

2. Konfiguracja i wymagania

Konfigurowanie projektu

Tworzenie projektu Google Cloud

  1. W konsoli Google Cloud na stronie wyboru projektu wybierz lub utwórz projekt w chmurze Google Cloud.
  2. Sprawdź, czy w projekcie Cloud włączone są płatności. Dowiedz się, jak sprawdzić, czy w projekcie są włączone płatności.

Uruchamianie Cloud Shell

Z Google Cloud można korzystać zdalnie na laptopie, ale w tym ćwiczeniu użyjesz Google Cloud Shell, czyli środowiska wiersza poleceń działającego w chmurze.

W konsoli Google Cloud kliknij ikonę Cloud Shell na pasku narzędzi w prawym górnym rogu:

Ikona aktywowania Cloud Shell

Możesz też nacisnąć G, a potem S. Ta sekwencja aktywuje Cloud Shell, jeśli korzystasz z konsoli Google Cloud. Możesz też użyć tego linku.

Uzyskanie dostępu do środowiska i połączenie się z nim powinno zająć tylko kilka chwil. Po zakończeniu powinno wyświetlić się coś takiego:

Terminal Google Cloud Shell z informacją o połączeniu ze środowiskiem

Ta maszyna wirtualna zawiera wszystkie potrzebne narzędzia dla programistów. Zawiera również stały katalog domowy o pojemności 5 GB i działa w Google Cloud, co znacznie zwiększa wydajność sieci i usprawnia proces uwierzytelniania. Wszystkie zadania w tym laboratorium możesz wykonać w przeglądarce. Nie musisz niczego instalować.

3. Tworzenie maszyn wirtualnych Google Cloud Compute Engine

Przygotowywanie skryptów Terraform

  1. Zdefiniuj zmienne środowiskowe dla identyfikatora projektu i wybranej nazwy klastra. Będziesz ich używać podczas naszych ćwiczeń z programowania.
    export PROJECT="your-project-id"
export CLUSTER="your-cluster-name"
    Uwaga: identyfikator projektu Google Cloud powinien mieć od 6 do 30 znaków. Więcej informacji znajdziesz na stronie https://docs.cloud.google.com/resource-manager/docs/creating-managing-projects#before_you_begin
  2. Sprawdź, czy logujesz się jako użytkownik konta Google Cloud.
    gcloud auth login
  3. Utwórz katalog roboczy na potrzeby wdrożenia i skopiuj wymagane pliki konfiguracji Terraform ze źródła repozytorium.
    mkdir -p ~/alloydb-omni/$PROJECT/$CLUSTER
cd ~/alloydb-omni/$PROJECT/$CLUSTER
gcloud storage cp gs://alloydb-omni-install/rpm-orchestrator/gce/terraform/*.tf .
  4. Utwórz plik terraform.tfvars, aby określić wymagane parametry zgodnie z architekturą referencyjną, jak pokazano poniżej:
    cat > terraform.tfvars <<EOF
# Required instance counts for reference architecture
db_instance_count      = 3
haproxy_instance_count = 2
control_instance_count = 1

# Optional: Customize if needed with the below variables
# os_image             = "rocky-linux-cloud/rocky-linux-9"
# zone                 = "us-west4-c"
# region_1             = "us-west4"
# db_instance_type     = "c4-highmem-4"
# db_disk_type         = "hyperdisk-balanced"
# db_data_size         =  "50" # GB
# data_dir             =  "/data"
EOF

Uruchamianie skryptów Terraform i weryfikowanie

  1. Możesz teraz udostępnić maszyny wirtualne.
    terraform init
  2. Zanim utworzysz maszyny wirtualne, upewnij się, że masz wymagany dostęp do tworzenia maszyn wirtualnych i innych zasobów. Podsumowując, potrzebujesz tych uprawnień:
    roles/compute.admin
roles/iam.roleAdmin
roles/compute.osAdminLogin
roles/iam.serviceAccountCreator
roles/iam.serviceAccountUser
roles/artifactregistry.repoAdmin
roles/storage.objectUser
roles/resourcemanager.projectIamAdmin
roles/serviceusage.serviceUsageAdmin
  3. Sprawdź poprawność konfiguracji i zastosuj ją, aby udostępnić zasoby.
    terraform validate
terraform apply --auto-approve
    Uwaga: upewnij się, że używasz Terraform w wersji 1.9.8 zgodnie z konfiguracją wdrożenia.
  4. Po zakończeniu działania Terraform sprawdź, czy maszyny wirtualne zostały utworzone, wyświetlając listę utworzonych instancji za pomocą polecenia gcloud.
    gcloud compute instances list --filter="name~$CLUSTER" --project=$PROJECT
    Powinny być widoczne instancje odpowiadające 3 węzłom bazy danych, 2 węzłom HAProxy oraz maszynie wirtualnej sterowania i odpowiednim strefom. Zapisz STREFĘ węzła sterującego. Będziemy go potrzebować w dalszej części tego ćwiczenia.
    export ZONE=$(gcloud compute instances list \
  --filter="name=$CLUSTER-control"          \
  --format="value(zone)" --project=$PROJECT)

4. Przygotowywanie maszyn wirtualnych do wdrożenia

Musisz utworzyć sesję SSH z węzłem sterującym i wykonać czynności, aby włączyć dostęp SSH do wszystkich maszyn wirtualnych (nazywanych też węzłami).

  1. Sprawdź, czy zmienne środowiskowe projektu i klastra są zdefiniowane.
    export PROJECT="your-project-id"
export CLUSTER="your-cluster-name"
  2. Utwórz klucz SSH i dodaj go, aby zalogować się na maszynie wirtualnej sterowania.
    # Replace values with your specific GCP project, cluster and zone details
ssh-keygen -t ed25519 -f $HOME/.ssh/google_compute_engine
gcloud compute os-login ssh-keys add --key-file=$HOME/.ssh/google_compute_engine.pub --project=$PROJECT
  3. Utwórz regułę zapory sieciowej, która zezwala na połączenia SSH i ruch VRRP.
    gcloud compute config-ssh --project=$PROJECT
gcloud compute firewall-rules create $CLUSTER-allow-ssh --network=$CLUSTER --project=$PROJECT --direction=INGRESS --action=allow --rules=tcp:22 --source-ranges="0.0.0.0/0"
gcloud compute firewall-rules create $CLUSTER-allow-vrrp --network=$CLUSTER --project=$PROJECT --allow=112 --source-ranges="0.0.0.0/0"
  4. Połącz się z maszyną wirtualną sterowania przez SSH:
    gcloud compute ssh "$CLUSTER-control" --zone=$ZONE --project=$PROJECT
  5. Utwórz grupę Linux na węźle sterującym o tej samej nazwie co nazwa użytkownika:
    sudo groupadd $(id -un)
sudo usermod -aG $(id -un) $(id -un)
  6. Konfiguracja Terraform tworzy kilka skryptów konfiguracyjnych i umieszcza je w katalogu /tmp/ na maszynie wirtualnej sterowania. Zawiera on m.in. nazwę klastra, konto usługi i nazwę projektu. Utwórz dostęp SSH bez hasła z węzłów sterowania do wszystkich węzłów klastra za pomocą skryptów konfiguracji w węźle sterowania.
    /tmp/setup-ssh-for-cluster.sh
    Ważne: zanotuj użytkownika service_account. Będziemy go używać jako SSH_USER w dalszej części tego ćwiczenia.
  7. W tym ćwiczeniu możemy wyłączyć SELinux na wszystkich węzłach. Skrypt Terraform dodaje plik „/tmp/run-all.sh”, którego można użyć w tym celu.
    /tmp/run-all.sh sudo setenforce 0
  8. Jeśli masz już zarejestrowaną usługę AlloyDB Omni i uzyskane linki, dodaj te adresy URL do zmiennych środowiskowych.
    cat >> ~/.codelab.env <<EOF
export ORCHESTRATOR_ANSIBLE_COLLECTION_PATH="..."
export ALLOYDB_OMNI_REPOSITORY_URL="..."
export ALLOYDB_OMNI_ORCHESTRATOR_REPOSITORY_URL="..."
export ALLOYDB_OMNI_COMMON_REPOSITORY_URL=....
export ETCD_REPOSITORY_URL="..."
EOF
    Wybierz wirtualny adres IP dla swojego środowiska z zmiennej wejściowej cidr_range w pliku terraform/variables.tf, tak aby nie powodował konfliktu z innymi węzłami, jak pokazano w tym przykładzie:
    cat >> ~/.codelab.env <<EOF
export VIRTUAL_IP="10.1.0.50"
EOF

5. Zainstaluj wymagane komponenty oprogramowania na wszystkich maszynach wirtualnych.

Następnym krokiem jest zainstalowanie wymaganych komponentów oprogramowania na maszynach wirtualnych. Można to skoordynować w węźle sterującym. Wszystkie poniższe polecenia muszą być wykonywane na węźle sterującym.

  1. Połącz się z maszyną wirtualną sterowania przez SSH, jeśli nie jesteś jeszcze na węźle sterowania.
    gcloud compute ssh "$CLUSTER-control" --zone=$ZONE --project=$PROJECT
    Gdy pojawi się wiersz poleceń SSH maszyny wirtualnej sterowania, uruchom plik środowiska źródłowego.
    source ~/.codelab.env
  2. W węźle sterującym zainstaluj Ansible i wymagane biblioteki Pythona.
    sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm -y
sudo dnf install -y ansible
sudo dnf install -y python3-grpcio python3-protobuf python3-googleapis-common-protos python3-grpcio-status
  3. Następnie pobierz plik tar kolekcji RPM Orchestrator Ansible i zainstaluj go.
    gcloud storage cp "gs://${ORCHESTRATOR_ANSIBLE_COLLECTION_PATH#https://storage.googleapis.com/}google-alloydbomni_orchestrator-*.tar.gz" .
ansible-galaxy collection install google-alloydbomni_orchestrator-0.1.0-6.tar.gz
ansible-galaxy collection list | grep alloydbomni_orchestrator
    Uwaga: upewnij się, że zmienna ORCHESTRATOR_ANSIBLE_COLLECTION_PATH kończy się znakiem „/”.
  4. Orkiestrator używa pliku specyfikacji wdrożenia w formacie spisu Ansible, aby poznać topologię klastra. Utwórz na węźle sterującym plik o nazwie deployment_spec.yaml zawierający szczegóły węzła.
    cat > deployment_spec.yaml <<EOF
alloydbomni:
  vars:
    cluster_manager:
      name: "$CLUSTER"
    etcd:
      setup: true
      config_forcewrite: true
    alloydbomni:
      major_version: "18"
      repo_url: $ALLOYDB_OMNI_REPOSITORY_URL
    alloydbomni_monitor:
      repo_url: $ALLOYDB_OMNI_COMMON_REPOSITORY_URL
    alloydbomni_cluster_manager:
      repo_url: $ALLOYDB_OMNI_ORCHESTRATOR_REPOSITORY_URL
    alloydbomni_node_manager:
      repo_url: $ALLOYDB_OMNI_ORCHESTRATOR_REPOSITORY_URL
    pgbouncer:
      repo_url: $ALLOYDB_OMNI_COMMON_REPOSITORY_URL
    pgbackrest:
      repo_url: $ALLOYDB_OMNI_COMMON_REPOSITORY_URL

  children:
    primary_instance_nodes:
      hosts:
        $CLUSTER-db1:
        $CLUSTER-db2:
        $CLUSTER-db3:
    load_balancer_nodes:
      hosts:
        $CLUSTER-haproxy1:
        $CLUSTER-haproxy2:
EOF
    Uwaga: sprawdź wygenerowany plik, aby upewnić się, że zawiera prawidłowe wartości.
  5. Utwórz plik playbook o nazwie install.yaml, który odwołuje się do roli instalacji z kolekcji orkiestratora.
    cat > install.yaml <<EOF
- name: Install AlloyDB Omni cluster components
  hosts: all
  vars:
    ansible_become: true
    ansible_user: $SSH_USER
    ansible_ssh_private_key_file: $HOME/ssh-key-cluster-sa
  roles:
    - role: google.alloydbomni_orchestrator.install
EOF
    Uwaga: sprawdź wygenerowany plik, aby upewnić się, że zawiera prawidłowe wartości.
  6. Uruchom playbooka, używając pliku zasobów reklamowych, aby pobrać i zainstalować pakiety RPM na wszystkich określonych węzłach.
    ansible-playbook -i deployment_spec.yaml install.yaml

6. Uruchamianie klastra AlloyDB Omni

Na tym etapie wszystkie wymagane komponenty zostały zainstalowane na wszystkich węzłach. Jesteśmy gotowi do uruchomienia klastra AlloyDB Omni.

  1. Połącz się z maszyną wirtualną sterowania przez SSH, jeśli nie jesteś jeszcze na węźle sterowania.
    gcloud compute ssh "$CLUSTER-control" --zone=$ZONE --project=$PROJECT
    Gdy pojawi się wiersz poleceń SSH maszyny wirtualnej sterowania, uruchom plik środowiska źródłowego.
    source ~/.codelab.env
  2. Wygeneruj hash hasła i zapisz go.
    encoded_password=$(echo -n "your unique password" | base64)
  3. Aby utworzyć klaster, AlloyDB Omni musi wiedzieć, jak go skonfigurować. Utwórz plik o nazwie dbcluster.yaml na potrzeby specyfikacji klastra bazy danych.
    cat > dbcluster.yaml <<EOF
Secret:
  metadata:
    name: db-pw-$CLUSTER
  spec:
    type: Opaque
    data:
      $CLUSTER: $encoded_password
---
DBCluster:
  metadata:
    name: $CLUSTER
  spec:
    databaseVersion: 18.1.0
    mode: ""
    availability:
      numberOfStandbys: 2
      enableAutoFailover: true
      enableAutoHeal: true
      autoFailoverTriggerThreshold: 2
      autoHealTriggerThreshold: 2
      healthcheckPeriodSeconds: 5
      replayReplicationSlotsOnStandbys: false
    primarySpec:
      adminUser:
        passwordRef:
          name: db-pw-$CLUSTER
      resources:
        cpu: 4
        memory: 32Gi
        disks:
        - name: DataDisk
          path: $PGDATA
      dbLoadBalancerOptions:
        gcp:
          loadBalancerIP: "$VIRTUAL_IP"
          loadBalancerType: "internal"
          loadBalancerInterface: "eth0"
EOF
  4. Utwórz plik playbook o nazwie bootstrap.yaml, który będzie odwoływać się do roli Ansible wczytywania w celu utworzenia klastra AlloyDB Omni.
    cat > bootstrap.yaml <<EOF
- name: Create DBCluster
  hosts: localhost
  vars:
    ansible_become: true
    ansible_user: $SSH_USER
    ansible_ssh_private_key_file: $HOME/ssh-key-cluster-sa
  roles:
  - role: google.alloydbomni_orchestrator.bootstrap
EOF
  5. Uruchom scenariusz, aby utworzyć klaster
    ansible-playbook bootstrap.yaml -i deployment_spec.yaml -e resource_spec=dbcluster.yaml

7. (Opcjonalnie) Skonfiguruj PgBouncer Connection Pooler

AlloyDB Omni obsługuje lekkie pule połączeń za pomocą PgBouncer. PgBouncer możesz skonfigurować i uruchomić od razu po udostępnieniu klastra.

  1. Utwórz plik specyfikacji zasobów o nazwie pgbouncer.yaml, który powiąże pulę połączeń z klastrem bazy danych:
    cat > pgbouncer.yaml <<EOF
PgBouncer:
  metadata:
    name: pgbouncer-pooler
  spec:
    dbclusterRef: $CLUSTER
    allowSuperUserAccess: true
    accessMode: "rw"
    port: 6432
EOF
  2. Uruchom pulę PgBouncer za pomocą tego samego pliku bootstrap.yaml utworzonego wcześniej, przekazując nowy plik specyfikacji:
    ansible-playbook bootstrap.yaml -i deployment_spec.yaml -e resource_spec=pgbouncer.yaml

8. Weryfikowanie klastra AlloyDB Omni

Aby sprawdzić, czy klaster działa prawidłowo i jest dostępny za pomocą modułu równoważenia obciążenia, możesz połączyć się z nim za pomocą standardowego klienta PostgreSQL z węzła sterującego.

  1. Zainstaluj repozytorium klienta PostgreSQL 18 i pakiet na węźle sterującym:
    sudo dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm
sudo dnf install -y postgresql18
  2. Połącz się z klastrem za pomocą zarezerwowanego wcześniej wirtualnego adresu IP. Pojawi się prośba o podanie hasła zakodowanego w pliku dbcluster.yaml:
    /usr/pgsql-18/bin/psql -h $VIRTUAL_IP -U postgres -W
  3. Po połączeniu możesz uruchamiać podstawowe zapytania SQL, aby sprawdzić stan klastra, np. wersję bazy danych:
    postgres=# SELECT version();
    Powinny się wyświetlić dane wyjściowe wskazujące, że PostgreSQL 18 działa z AlloyDB Omni. Aby zamknąć prompt, wpisz \q.

9. (Opcjonalnie) Tworzenie kopii zapasowej danych za pomocą pgBackRest

AlloyDB Omni integruje się z pgBackRest, aby zarządzać kopiami zapasowymi bezpośrednio w Cloud Storage. Możesz skonfigurować plan tworzenia kopii zapasowych i wywołać tworzenie kopii zapasowej na żądanie w zasobniku GCS utworzonym przez konfigurację Terraform.

  1. Utwórz plik specyfikacji planu tworzenia kopii zapasowych o nazwie backup_plan.yaml, który będzie wskazywać udostępniony zasobnik GCS:
    cat > backup_plan.yaml <<EOF
BackupPlan:
  metadata:
    name: pgb-plan
  spec:
    dbclusterRef: $CLUSTER
    backupLocation:
      type: GCS
      gcsOptions:
        bucket: $CLUSTER-gcs-backups
        key: /backups
EOF
  2. Utwórz poradnik Ansible o nazwie backup.yaml, który odwołuje się do roli zarządzania kopiami zapasowymi:
    cat > backup.yaml <<EOF
- name: Manage AlloyDB Omni Backups
  hosts: localhost
  vars:
    ansible_become: true
    ansible_user: $SSH_USER
    ansible_ssh_private_key_file: $HOME/ssh-key-cluster-sa
  roles:
    - role: google.alloydbomni_orchestrator.backup
EOF
  3. Zastosuj plan tworzenia kopii zapasowych za pomocą pliku backup.yaml:
    ansible-playbook backup.yaml -i deployment_spec.yaml -e resource_spec=backup_plan.yaml
  4. Po utworzeniu planu utwórz plik zasobu kopii zapasowej na żądanie o nazwie create_backup.yaml.
    cat > create_backup.yaml <<EOF
Backup:
  metadata:
    name: on-demand-backup
  spec:
    backupPlanRef: pgb-plan
    dbclusterRef: $CLUSTER
EOF
  5. Uruchom scenariusz, aby rozpocząć tworzenie kopii zapasowej:
    ansible-playbook backup.yaml -i deployment_spec.yaml -e resource_spec=create_backup.yaml
  6. Aby sprawdzić stan kopii zapasowej, utwórz plik status.yaml:
- name: Fetch AlloyDB Omni Resource Status
hosts: localhost
vars:
  ansible_become: true
  ansible_user: $SSH_USER
  ansible_ssh_private_key_file: $HOME/ssh-key-cluster-sa
roles:
  - role: google.alloydbomni_orchestrator.status
EOF
  1. Uruchom scenariusz, aby wyświetlić listę wszystkich kopii zapasowych:
ansible-playbook status.yaml -i deployment_spec.yaml -e resource_type=Backup
  1. Możesz też przekazać -e resource_name=on-demand-backup, aby uzyskać szczegółowe informacje o konkretnej kopii zapasowej utworzonej wcześniej:
ansible-playbook status.yaml -i deployment_spec.yaml \
  -e resource_type=Backup \
  -e resource_name=on-demand-backup

10. Czyszczenie zasobów

Po zakończeniu wdrażania możesz usunąć udostępnione zasoby, aby uniknąć opłat.

  1. Utwórz scenariusz o nazwie teardown.yaml:
    cat > teardown.yaml <<EOF
- name: Tear down AlloyDB Omni cluster
  hosts: localhost
  vars:
    ansible_become: true
    ansible_user: $SSH_USER
    ansible_ssh_private_key_file: $HOME/ssh-key-cluster-sa
  roles:
  - role: google.alloydbomni_orchestrator.delete
EOF
  2. Uruchom scenariusz za pomocą polecenia ansible-playbook. Jeśli masz skonfigurowane kopie zapasowe, najpierw usuń zasoby Backup i BackupPlan:
    ansible-playbook teardown.yaml -i deployment_spec.yaml  -e "resource_type=Backup" -e "resource_name=on-demand-backup"
ansible-playbook teardown.yaml -i deployment_spec.yaml  -e "resource_type=BackupPlan" -e "resource_name=pgb-plan"
    Jeśli masz skonfigurowany PgBouncer, usuń najpierw zasób puli połączeń:
    ansible-playbook teardown.yaml -i deployment_spec.yaml  -e "resource_type=PgBouncer" -e "resource_name=pgbouncer-pooler"
    Następnie określ DBCluster jako resource_type i usuń sam klaster bazy danych:
    ansible-playbook teardown.yaml -i deployment_spec.yaml  -e "resource_type=DBCluster" -e "resource_name=$CLUSTER"
  3. Po usunięciu klastra wyloguj się z węzła sterującego, wróć do terminala i przejdź do katalogu roboczego Terraform.
    Uwaga: jeśli dopiero co zalogowano się w Cloud Shell, pamiętaj, aby ustawić te wartości:
    export PROJECT="your-project-id"
export CLUSTER="your-cluster-name"
  4. Usuń regułę zapory sieciowej VRRP i zniszcz zasoby zarządzane przez Terraform:
    gcloud compute firewall-rules delete -q "$CLUSTER-allow-vrrp" --project="$PROJECT"
gcloud compute firewall-rules delete -q "$CLUSTER-allow-ssh" --project="$PROJECT"
terraform destroy
  5. Gdy pojawi się odpowiedni komunikat, potwierdź zniszczenie. Ponieważ pozostałe zasoby sieciowe lub trasy mogą czasami uniemożliwiać całkowite wycofanie, uruchom poniższe bezpieczne polecenia czyszczenia, aby upewnić się, że wszystkie powiązane reguły zapory sieciowej, bramy NAT, routery, trasy, podsieci i sieci zostały całkowicie usunięte. Zastąp REGION konkretnym regionem wdrożenia, np. „us-central1”:
    # Delete any remaining firewall rules associated with the cluster
gcloud compute firewall-rules list --project=$PROJECT 2> /dev/null | grep ^$CLUSTER- | cut -f1 -d' ' | \
  while read rule; do gcloud compute firewall-rules delete --project=$PROJECT --quiet $rule; done

# Delete the Cloud NAT gateway and router if they still exist
gcloud compute routers nats describe $CLUSTER-nat-gw --router=$CLUSTER-router --region=REGION --project=$PROJECT 2>/dev/null \
  && gcloud compute routers nats delete $CLUSTER-nat-gw --router=$CLUSTER-router --region=REGION --project=$PROJECT --quiet

gcloud compute routers describe $CLUSTER-router --region=REGION --project=$PROJECT 2>/dev/null \
  && gcloud compute routers delete $CLUSTER-router --region=REGION --project=$PROJECT --quiet

# Delete any remaining custom routes
gcloud compute routes list --project=$PROJECT --filter="network:$CLUSTER" --format="value(name)" 2>/dev/null | \
  while read route; do gcloud compute routes delete --project=$PROJECT --quiet $route 2>/dev/null || true; done

# Delete the subnet and network if they still exist
gcloud compute networks subnets describe $CLUSTER --region=REGION --project=$PROJECT 2>/dev/null \
  && gcloud compute networks subnets delete $CLUSTER --region=REGION --project=$PROJECT --quiet

gcloud compute networks describe $CLUSTER --project $PROJECT 2> /dev/null \
  && gcloud compute networks delete $CLUSTER --project $PROJECT --quiet

11. Gratulacje

Gratulujemy ukończenia ćwiczenia.

Omówione zagadnienia

  • Jak tworzyć i przygotowywać maszyny wirtualne GCE na potrzeby AlloyDB Omni.
  • Jak zainstalować i uruchomić narzędzie AlloyDB Omni RPM Orchestrator.
  • Instalowanie i konfigurowanie pakietów RPM AlloyDB Omni na potrzeby architektury referencyjnej HA.

Więcej informacji o AlloyDB Omni znajdziesz w dokumentacji.

12. Ankieta

Jak zamierzasz wykorzystać ten samouczek?

Tylko przeczytaj Przeczytaj i wykonaj ćwiczenia