Wdrażanie zadania Poufnej przestrzeni w zarządzanych grupach instancji z użyciem autoskalowania, automatycznej naprawy i aktualizacji obrazów

1. Przegląd

Poufna przestrzeń (CS) to bezpieczne, potwierdzone i zaszyfrowane środowisko do przetwarzania danych wrażliwych. Korzystanie z samodzielnych instancji maszyn wirtualnych wiąże się z dodatkowymi kosztami operacyjnymi, ponieważ ręczne zarządzanie nie zapewnia skalowalności wymaganej w przypadku usług o krytycznym znaczeniu. Bez automatycznej orkiestracji przeprowadzanie zsynchronizowanych aktualizacji stopniowych lub wdrażanie nowych obrazów systemu operacyjnego na całej flocie staje się trudne technicznie i podatne na przestoje.

Z tego ćwiczenia dowiesz się, jak wdrożyć obciążenie Poufnej przestrzeni w zarządzanej grupie instancji. Dowiesz się też, jak włączyć automatyczną naprawę za pomocą kontroli stanu, autoskalowanie na podstawie wykorzystania procesora i aktualizacje stopniowe obrazów systemu operacyjnego oraz zadań.

Procesy przedstawione w tym ćwiczeniu pomogą Ci skonfigurować własną, przygotowaną do zastosowań produkcyjnych i bezpieczną Poufną przestrzeń na potrzeby długotrwałych wdrożeń o krytycznym znaczeniu.

Czego się nauczysz

  • Jak utworzyć specjalistyczny szablon instancji dla Poufnej przestrzeni.
  • Jak korzystać z Google Compute Engine i konfigurować zarządzane grupy instancji oraz grupy instancji
  • Jak utworzyć regułę zapory sieciowej i kontrolę stanu na potrzeby automatycznej naprawy.
  • Jak skonfigurować strefową zarządzaną grupę instancji za pomocą szablonu i kontroli stanu.
  • Jak skonfigurować autoskalowanie zarządzanej grupy instancji.
  • Jak skonfigurować aktualizacje obrazów systemu operacyjnego jednym kliknięciem za pomocą skryptów w przypadku grup instancji zarówno w przypadku obrazów zbiorów zadań, jak i nowych wersji obrazów systemu operacyjnego dla zaufanej przestrzeni

Czego potrzebujesz

  • Projekt Google Cloud z włączonymi płatnościami.
  • Znajomość edytorów tekstu, wdrożeń Dockera i skryptów Bash.
  • Narzędzie wiersza poleceń gcloud jest zainstalowane i uwierzytelnione.
  • Podstawowa znajomość Compute Engine, Poufnej przestrzeni, IAM, poufnych maszyn wirtualnych, technologii kontenerów, repozytoriów zdalnych, kont usług, Cloud Run i Cloud Scheduler.
  • Obraz kontenera zadania w Poufnej przestrzeni, który został już utworzony i przesłany do Artifact Registry.

2. Jak działa Poufna przestrzeń z MIG

Użycie zarządzanej grupy instancji (MIG) do wdrożenia obciążenia w Poufnej przestrzeni sprawia, że bezpieczna aplikacja jest bardziej niezawodna, skalowalna i łatwiejsza w obsłudze.

Wymagania dotyczące bezpieczeństwa i działania usługi produkcyjnej są logicznie podzielone między te 2 komponenty. Poufna przestrzeń zapewnia niezbędne zabezpieczenia, uruchamiając zadanie w wysoce odizolowanym, zaszyfrowanym i atestowanym środowisku zwanym zaufanym środowiskiem wykonawczym (TEE). Grupy MIG zapewniają natomiast podstawowe możliwości operacyjne wymagane do uruchamiania bezpiecznej aplikacji na dużą skalę, podobnie jak Kubernetes. Zarządzane grupy instancji eliminują ryzyko związane z uruchamianiem zadań o kluczowym znaczeniu na jednej maszynie wirtualnej, która może działać wolno lub być podatna na awarie. Takie połączenie zapewnia zarówno ochronę danych, jak i niezawodność systemu. To rozwiązanie zapewnia wysoką dostępność i automatyczną naprawę, ponieważ zadanie jest uruchamiane na wielu maszynach wirtualnych w puli. Jeśli jedna z maszyn wirtualnych ulegnie awarii, usługa pozostanie w pełni funkcjonalna dzięki równoważeniu obciążenia i obecności pozostałych instancji.

Ponadto zarządzane grupy instancji korzystają z konfigurowalnych kontroli stanu, aby stale monitorować stan operacyjny maszyn wirtualnych. Jeśli instancja zostanie uznana za niesprawną, zarządzana grupa instancji automatycznie zastąpi ją nową, sprawną maszyną wirtualną, co gwarantuje ciągłość działania.

Zarządzane grupy instancji zapewniają też użytkownikom efektywną skalowalność dzięki funkcji autoskalowania. Ta funkcja zapewnia automatyczny sposób zarządzania pojemnością bez konieczności ręcznej interwencji, co pozwala elastycznie dodawać lub usuwać pojemność w zależności od wykorzystania.

Na koniec MIG umożliwiają aktualizacje bez przestojów dzięki aktualizacjom kroczącym. Kluczową korzyścią jest możliwość „uaktualnienia jednym kliknięciem” bazowego obrazu systemu operacyjnego Poufnej przestrzeni lub obrazu kontenera aplikacji (lub obu tych elementów) bez powodowania przestojów w usłudze. Tą zmianą zarządza grupa instancji, stopniowo zastępując starsze instancje nowszymi, na których działa zaktualizowany obraz. Zapewnia to stałą dostępność podczas całego wdrożenia. Pamiętaj, że aby obsługiwać ten typ stopniowej aktualizacji, aplikacja może wymagać zgodności wstecznej.

3. Konfigurowanie zasobów w chmurze

Zanim zaczniesz

  1. skonfigurować projekt Google Cloud, Więcej informacji o tworzeniu projektu w chmurze Google Cloud znajdziesz w samouczku „Konfiguracja pierwszego projektu Google i poruszanie się po nim”. Więcej informacji o tym, jak uzyskać identyfikator projektu i czym różni się on od nazwy i numeru projektu, znajdziesz w artykule tworzenie projektów i zarządzanie nimi.
  2. Włącz płatności w swoich projektach.
  3. W Cloud Shell projektu Google skonfiguruj wymagane zmienne środowiskowe projektu, jak pokazano poniżej.
export  CURRENT_PROJECT_ID=<Google Cloud project id of current project>
  1. Włącz interfejs Confidential Computing API i te interfejsy API w projekcie.
gcloud config set project $CURRENT_PROJECT_ID
gcloud services enable \
cloudapis.googleapis.com \
container.googleapis.com \
artifactregistry.googleapis.com \
confidentialcomputing.googleapis.com \
compute.googleapis.com \
logging.googleapis.com \
run.googleapis.com \
cloudscheduler.googleapis.com
  1. W Cloud Shell w projekcie Google Cloud sklonuj repozytorium GitHub z ćwiczeniami Poufna przestrzeń i użyj poniższego polecenia, aby pobrać odpowiednie skrypty potrzebne do ukończenia tych ćwiczeń.
git clone https://github.com/GoogleCloudPlatform/confidential-space.git
  1. Przejdź do katalogu skryptów w ćwiczeniach z programowania dotyczących grupy instancji.
cd confidential-space/codelabs/mig_cs_codelab/scripts
  1. Zaktualizuj wiersz identyfikatora projektu w pliku config_env.sh, aby odzwierciedlał wybrany projekt.
  2. Ustaw wszelkie istniejące wcześniej zmienne. Zastępowanie nazw zasobów za pomocą tych zmiennych
  • Możesz ustawić te zmienne za pomocą nazw istniejących zasobów w chmurze. Jeśli zmienna jest ustawiona, zostaną użyte odpowiednie istniejące zasoby w chmurze z projektu. Jeśli nie jest ustawiona, nazwa zasobu w chmurze będzie pochodzić ze skryptu config_env.sh.
  1. Uruchom skrypt config_env.sh, aby ustawić pozostałe nazwy zmiennych dla tego projektu na wartości oparte na identyfikatorze projektu dla nazw zasobów.
source config_env.sh
  1. Dodaj uprawnienia do projektu. Uprawnienia można dodać, postępując zgodnie z instrukcjami na stronie przyznawania ról uprawnień.

Aby wykonać to działanie, musisz mieć te uprawnienia:

  • Zapisujący w Artifact Registry
  • Administrator Cloud Scheduler
  • Agent usługi Compute
  • Użytkownik zadań Confidential Computing
  • Zapisujący logi
  • Programista Cloud Run
  • Wywołujący Cloud Run
gcloud config set project $CURRENT_PROJECT_ID

# Add Artifact Registry Writer role
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/artifactregistry.writer'

# Add Confidential Space Workload Userd
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/confidentialcomputing.workloadUser'

# Add Logging Log Writer
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/logging.logWriter'

# Add Cloud Run Developer
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/run.developer'

# Add Cloud Run Invoker
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/run.invoker'


# Add Cloud Scheduler Admin
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/cloudscheduler.admin'
  1. Sprawdź plik test_workload.py
  • Sprawdź wynik zadania, przeglądając kod źródłowy. Powinien on po prostu wyświetlać bieżącą wersję zadania.
  • Gdy po raz pierwszy przeniesiemy nasz zasób do CS i sprawdzimy dane wyjściowe, powinniśmy zobaczyć wydrukowaną „wersję A”.

4. Konfigurowanie zadania

Najpierw musisz utworzyć obraz Dockera dla obciążenia używanego w tych ćwiczeniach z programowania. Zadanie to prosty skrypt, który wyświetla wersję zadania, z której obecnie korzystasz. Wyświetli informację o rozpoczęciu zadania, a następnie jego wersję. Potem poczeka 5 sekund i wyświetli informację o zakończeniu zadania.

Etapy tworzenia zadania

  1. Aby utworzyć zadanie, uruchom skrypt create_workload.sh. Ten skrypt:
  • Tworzy repozytorium Artifact Registry należące do projektu, w którym będzie publikowane obciążenie.
  • kompiluje kod i pakuje go w obrazie Dockera, Więcej informacji znajdziesz w powiązanej konfiguracji pliku Dockerfile.
  • publikuje obraz Dockera w Artifact Registry należącym do projektu,
  • Przyznaje kontu usługi <your service account name> uprawnienia do odczytu rejestru artefaktów <artifact registry repo name>.

5. Konfigurowanie szablonu instancji i zarządzanej grupy instancji

Kroki tworzenia szablonu instancji

Najpierw musisz utworzyć szablon instancji. Ten szablon to wymagany plan, którego zarządzana grupa instancji (MIG) będzie używać do udostępniania i uruchamiania zbiorów zadań w Poufnej przestrzeni.

Szablon instancji jest niezbędny, ponieważ definiuje wszystkie specjalistyczne parametry:

  • Typ maszyny: w tym przykładzie używamy typu maszyny poufna maszyna wirtualna (np. n2d-standard-2), który obsługuje technologię poufnych obliczeń AMD SEV (--confidential-compute-type=SEV).
  • Obraz systemu operacyjnego maszyny wirtualnej: używamy projektu confidential-space-images i rodziny obrazów confidential-space-debug, aby pobrać najnowszy obraz systemu operacyjnego Poufnej przestrzeni.
  • Uwaga: w tym przewodniku używamy obrazu debug, aby ułatwić rozwiązywanie problemów. W przeciwieństwie do obrazu produkcyjnego wersja debugowania utrzymuje maszynę wirtualną w stanie działania po zakończeniu zadania i umożliwia dostęp SSH na potrzeby testowania. W przypadku wdrożeń produkcyjnych wykorzystujących rzeczywiste dane wrażliwe musisz przejść na rodzinę obrazów produkcyjnych.
  • Odwołanie do obciążenia: wymaganytee-image-reference wiersz w metadanych zawiera konkretny obraz kontenera (obciążenie aplikacji), który zostanie uruchomiony na maszynie wirtualnej Poufnej przestrzeni.

Dzięki tej konfiguracji każda maszyna wirtualna utworzona przez zarządzaną grupę instancji będzie prawidłowo skonfigurowaną Poufną przestrzenią gotową do wykonania Twojego zadania.

Etapy tworzenia zarządzanej grupy instancji

Następnym krokiem jest utworzenie zarządzanej grupy instancji za pomocą zdefiniowanego właśnie szablonu. Zarządzana grupa instancji jest niezbędna, ponieważ automatyzuje wdrażanie, zarządzanie i skalowanie wielu identycznych maszyn wirtualnych.

Skrypt create_launch_mig.sh realizuje 3 główne cele:

1. Tworzenie zarządzanej grupy instancji

  • Polecenie: gcloud compute instance-groups managed create ${CURRENT_MIG_NAME}
  • Cel: to polecenie tworzy grupę, która będzie zarządzać Twoimi maszynami wirtualnymi.
  • --size 3: określa, że grupa MIG powinna początkowo utworzyć i utrzymywać 3 instancje zbioru zadań.
  • --template ${TEMPLATE_NAME}: Co ważne, odwołuje się do utworzonego wcześniej szablonu instancji, dzięki czemu wszystkie 3 instancje są skonfigurowane jako maszyny wirtualne Poufnej przestrzeni z określonym kontenerem zadania tee-image-reference.
  • --zone ${CURRENT_PROJECT_ZONE}: określa lokalizację wdrożenia instancji.

2. Pobierz numer projektu

  • Polecenie: PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
  • Cel: skrypt pobiera numeryczny identyfikator projektu. Ten numer jest często wymagany do tworzenia ról i uprawnień kont usługi, zwłaszcza w przypadku agentów usługi zarządzanych przez Google.

3. Przyznawanie uprawnień

  • Polecenie: gcloud projects add-iam-policy-binding --role="roles/compute.serviceAgent"
  • Cel: ten krok przyznaje rolę agenta usługi Compute Engine kontu usługi Twojego obciążenia (${SERVICE_ACCOUNT}). To uprawnienie jest ważne, ponieważ umożliwia kontu usługi działanie w imieniu usługi Compute Engine projektu, co jest często niezbędne w przypadku zautomatyzowanych funkcji MIG, takich jak zarządzanie instancjami, konfigurowanie sieci i interakcje z innymi usługami Google Cloud.

Uruchom polecenie create_launch_mig.sh, aby utworzyć zarządzaną grupę instancji.

6. Instrukcje włączania automatycznego naprawiania i autoskalowania

Konfigurowanie automatycznej naprawy

Aby zapewnić wysoką dostępność, sprawdzamy, czy zbiór zadań odpowiada na żądania. Jeśli aplikacja przestanie odpowiadać, zarządzana grupa instancji powinna zastąpić maszynę wirtualną. Reguły zapory sieciowej dotyczące zakresów źródłowych adresów IP są zdefiniowane w tym dokumencie.

# 1. Create Health Check (TCP Port 22)
gcloud compute health-checks create tcp ${HEALTH_CHECK_NAME} \
  --port 22 \
  --check-interval 30s \
  --healthy-threshold 1 \
  --timeout 10s \
  --unhealthy-threshold 3 \
  --global

# 2. Allow Health Check Traffic (Firewall)
gcloud compute firewall-rules create allow-health-check \
    --allow tcp:22 \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 \
    --network default \
    --project="${CURRENT_PROJECT_ID}" \ 

# 3. Apply to MIG
gcloud compute instance-groups managed update ${CURRENT_MIG_NAME} \
    --health-check ${HEALTH_CHECK_NAME} \
    --initial-delay 60 \
    --zone ${CURRENT_PROJECT_ZONE}

Konfigurowanie autoskalowania

Skonfigurujemy grupę tak, aby automatycznie skalowała się w zakresie od 1 do 5 instancji w celu obsługi nagłych wzrostów ruchu.

gcloud compute instance-groups managed set-autoscaling ${CURRENT_MIG_NAME} \
    --max-num-replicas 5 \
    --target-cpu-utilization 0.80 \
    --cool-down-period 90 \
    --zone ${CURRENT_PROJECT_ZONE}

7. Weryfikowanie obciążenia i konfigurowanie aktualizacji obrazu

Weryfikacja zadania

Gdy zarządzana grupa instancji (MIG) uruchomi maszyny wirtualne, musimy sprawdzić, czy obciążenie Poufnej przestrzeni działa prawidłowo.

Możesz to zrobić w konsoli Google Cloud lub wierszu poleceń.

gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME} \
    --zone ${CURRENT_PROJECT_ZONE}

Możesz też sprawdzić dane wyjściowe portu szeregowego konkretnej instancji, aby zobaczyć logi związane z Twoim zbiorem zadań.

# Replace <INSTANCE_NAME> with one of the names from the previous command
gcloud compute instances get-serial-port-output <INSTANCE_NAME> \
    --zone ${CURRENT_PROJECT_ZONE} \
    --port 1

Konfigurowanie aktualizacji obrazów

W środowisku produkcyjnym zarządzana grupa instancji (MIG) musi być regularnie aktualizowana w 2 różnych scenariuszach:

  1. Aktualizacje zadań: publikowanie nowej wersji kodu aplikacji (np. aktualizacja pliku test_workload.py z wersji 1 do wersji 2).
  2. Aktualizacje infrastruktury: Google udostępnia poprawkę zabezpieczeń lub aktualizację bazowego systemu operacyjnego Poufnej przestrzeni. Pamiętaj, że sprawdzoną metodą jest pobieranie najnowszych zdjęć CS co najmniej raz w miesiącu.

Ponieważ skonfigurowaliśmy szablon instancji za pomocą dynamicznego linku do obrazu (.../images/family/...) i dynamicznego tagu kontenera (:latest), możemy obsłużyć oba te scenariusze za pomocą jednej operacji „Rolling Replace”. Dzięki temu Twoja flota maszyn wirtualnych zawsze będzie korzystać z najnowszej wersji stosu bez przestojów i bez konieczności tworzenia nowego szablonu instancji przy każdej drobnej zmianie.

Skrypt wymiany stopniowej

W katalogu update_images przejdź do pliku update_images_script.sh. Ten skrypt wywołuje zastępowanie stopniowe, które stopniowo niszczy i odtwarza każdą maszynę wirtualną w grupie.

#!/bin/bash

# Initialize the template
gcloud compute instance-groups managed set-instance-template "${CURRENT_MIG_NAME}" \
--template=projects/"${PROJECT_ID}"/global/instanceTemplates/"${TEMPLATE_NAME}" \
--zone="${CURRENT_PROJECT_ZONE}" \
--project="${PROJECT_ID}"

# Trigger the rolling replace
gcloud compute instance-groups managed rolling-action replace "${CURRENT_MIG_NAME}" \
    --version=template="${TEMPLATE_NAME}" \
    --project="${PROJECT_ID}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --max-surge=1 \
    --max-unavailable=0

# Wait for the update to complete
gcloud compute instance-groups managed wait-until --version-target-reached "${CURRENT_MIG_NAME}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --project="${PROJECT_ID}"

W przypadku tego skryptu możemy użyć opcji zastąpienia zamiast ponownego uruchomienia.

  • Ponowne uruchomienie po prostu restartuje urządzenie. Zachowuje istniejący dysk systemu operacyjnego, co oznacza, że nie będzie pobierać nowych poprawek systemu operacyjnego.
  • Zastąp usuwa maszynę wirtualną i tworzy nową na podstawie szablonu. Wymusza to wyszukanie przez system najnowszego obrazu systemu operacyjnego Poufnej przestrzeni z rodziny, a także pobranie z rejestru obrazu kontenera „Latest”.

–max-surge=1: umożliwia tymczasowe utworzenie w MIG 1 dodatkowej maszyny wirtualnej ponad docelowy rozmiar. Uruchamia nową (zaktualizowaną) maszynę wirtualną i czeka, aż będzie w dobrym stanie, zanim usunie starą (nieaktualną) maszynę wirtualną.

–max-unavailable=0: zapewnia brak przestojów. Informuje on MIG, że nie może wyłączyć żadnej maszyny, dopóki nie zostanie ona zastąpiona przez inną.

Skrypt ponownego uruchamiania z przesunięciem

W katalogu update_images znajduje się też inny skrypt update_workload_image_script.sh. Ten skrypt wywołuje ponowne uruchomienie z przesunięciem w czasie, które jest szybszą metodą służącą wyłącznie do odświeżania zadań. Ponieważ poufna przestrzeń pobiera obraz kontenera z rejestru przy każdym uruchomieniu, ponowne uruchomienie wystarczy, aby zaktualizować aplikację do wersji :latest bez zmiany bazowego hosta.

#!/bin/bash
# Reboots the existing VMs to refresh the container
gcloud compute instance-groups managed rolling-action restart "${CURRENT_MIG_NAME}" \
    --project="${PROJECT_ID}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --max-surge=1 \
    --max-unavailable=0

# Wait for the update to complete
gcloud compute instance-groups managed wait-until --stable "${CURRENT_MIG_NAME}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --project="${CURRENT_PROJECT_ID}"

Sprawdź zaktualizowane zadanie

Możemy przetestować „Uaktualnianie jednym kliknięciem”, symulując wydanie aplikacji w rzeczywistym świecie. Zmodyfikujemy kod zadania, prześlemy go do Artifact Registry, zaktualizujemy MIG i sprawdzimy, czy nowa wersja działa bez przestojów.

Krok 1. Wdróż nową wersję obciążenia

Najpierw musimy utworzyć „nową” wersję aplikacji.

  1. Otwórz lokalny plik test_workload.py.
  2. Zmień instrukcję drukowania wersji z print("Workload Version A") na print("Workload Version B").
  3. Ponownie skompiluj obraz kontenera i przenieś go do Artifact Registry, uruchamiając skrypt create_workload.sh. Pamiętaj, że wysyłamy zmiany do tego samego tagu (:latest).

Krok 2. Przeprowadź aktualizację stopniową

Uruchom skrypt aktualizacji utworzony w poprzedniej sekcji. Spowoduje to wymuszenie zastąpienia każdej maszyny wirtualnej w zarządzanej grupie instancji przez pobranie nowego skrótu kontenera powiązanego z :latest.

# Run your update script
./update_images/update_images_script.sh

Poczekaj na zakończenie działania skryptu

Krok 3. Sprawdź aktualizację przez port szeregowy

Po zakończeniu aktualizacji sprawdzamy, czy nowe maszyny wirtualne działają z zaktualizowanym kodem.

# Replace <INSTANCE_NAME> with one of the names from the previous command
gcloud compute instances get-serial-port-output <INSTANCE_NAME> \
    --zone ${CURRENT_PROJECT_ZONE} \
    --port 1

Pobierz nazwę nowej instancji:

gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME} --zone ${CURRENT_PROJECT_ZONE}

Sprawdź dzienniki:

# Replace <NEW_INSTANCE_NAME> with one of the names of the running VMs
gcloud compute instances get-serial-port-output <NEW_INSTANCE_NAME> \
    --zone ${CURRENT_PROJECT_ZONE} \
    --port 1

Gdy instancje będą działać, wybierz dowolną nazwę instancji z poprzedniego polecenia gcloud, aby wyświetlić jej port szeregowy.

Oczekiwane dane wyjściowe: powinien pojawić się zaktualizowany komunikat logu potwierdzający, że wdrożenie się powiodło:

... Workload Version B ...

Krok 4. Sprawdź konfigurację infrastruktury (opcjonalnie)

Możesz też sprawdzić, czy szablon instancji jest prawidłowo skonfigurowany do pobierania dynamicznych aktualizacji zarówno systemu operacyjnego, jak i zadań, sprawdzając jego metadane.

Aby wyświetlić dynamiczne odwołanie do kontenera, uruchom to polecenie:

gcloud compute instance-templates describe ${TEMPLATE_NAME} \
    | grep -A 1 tee-image-reference

Wynik: powinien być widoczny obraz kontenera kończący się ciągiem :latest.

  • Wniosek: ponieważ szablon wskazuje tag, a nie konkretny hash, każde zastąpienie kroczące pobiera najnowszy kod przesłany w kroku 1.

(Opcjonalnie) Automatyczne aktualizacje

Ręczne aktualizacje są przydatne w przypadku głównych wersji, ale często chcesz, aby Twoja flota automatycznie pobierała najnowsze poprawki zabezpieczeń lub regularne kompilacje wdrożeniowe bez interwencji człowieka.

Możemy zautomatyzować proces „Rolling Replace”, pakując skrypt aktualizacji w zadanie Cloud Run. W tym ćwiczeniu będziemy go wywoływać co 15 minut. W środowisku produkcyjnym powinien być uruchamiany znacznie rzadziej. W zależności od potrzeb użytkownik może skonfigurować je w cyklu tygodniowym lub miesięcznym.

Krok 1. Utwórz kontener dla skryptu aktualizującego

Najpierw musimy spakować skrypt update_images_script.sh (który zawiera logikę gcloud ... rolling-action replace) do kontenera Dockera, aby można go było uruchomić w chmurze.

Przygotowaliśmy skrypt pomocniczy, który tworzy ten kontener i przenosi go do Artifact Registry.

Uruchom to polecenie:

# Build and Push the "Updater" Container
# This packages your update logic into a docker image
./update_images/deploy_docker_script_image.sh

Co to robi:

  • Pobiera skrypt update_images_script.sh z katalogu update_images/.
  • Tworzy obraz Dockera zawierający pakiet SDK Google Cloud i skrypt.
  • Wypycha obraz do ${CURRENT_PROJECT_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY}/update-script:latest.

Krok 2. Wdróż i zaplanuj zadanie

Teraz musimy poinformować Google Cloud, aby okresowo uruchamiało ten kontener. Do wykonania kontenera używamy zadań Cloud Run, a do jego aktywowania – Cloud Schedulera.

Uruchom skrypt konfiguracji harmonogramu:

# Create the Cloud Run Job and the Scheduler Trigger
./create_configs/create_schedule_job.sh

W skrypcie: ten skrypt wykonuje 2 kluczowe działania:

  1. Tworzy zadanie Cloud Run: definiuje zadanie o nazwie mig-updater-job, które wykonuje właśnie przesłany kontener.
  2. Tworzy regułę harmonogramu: konfiguruje zadanie Cloud Scheduler, które co 15 minut wywołuje interfejs Cloud Run Job API.
# (Snippet from create_schedule_job.sh for reference)
# The schedule is set to run every 15 minutes for testing purposes
gcloud scheduler jobs create http ${SCHEDULER_NAME} \
    --schedule "*/15 * * * *" \
    --uri "https://${CURRENT_PROJECT_REGION}-run.googleapis.com/apis/run.googleapis.com/v1/namespaces/${PROJECT_ID}/jobs/${JOB_NAME}:run" \
    --http-method POST \
    --oauth-service-account-email ${SERVICE_ACCOUNT}

Krok 3. Sprawdź automatyzację

Nie musisz czekać 15 minut, aby go przetestować. Aby sprawdzić potok, możesz wymusić natychmiastowe uruchomienie harmonogramu.

  1. Wymuś uruchomienie zadania:
gcloud scheduler jobs run ${SCHEDULER_NAME} --location ${CURRENT_PROJECT_REGION}
  1. Sprawdź wykonanie: otwórz konsolę Cloud Run > Zadania. Powinno się rozpocząć nowe wykonanie.
  2. Sprawdź MIG: uruchom gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME}. Gdy zadanie wywoła aktualizację kroczącą, zobaczysz, że instancje przechodzą w stan RECREATING.

Dlaczego 15 minut? W tym samouczku ustawiliśmy harmonogram na */15 * * * *, aby można było szybko zobaczyć wyniki. W prawdziwym środowisku produkcyjnym prawdopodobnie zmienisz to ustawienie, aby uruchamiać skrypt codziennie (np. 0 3 * * * o godzinie 3:00) lub co tydzień.

8. Czyszczenie

Skrypt czyszczący cleanup.sh może służyć do usuwania zasobów utworzonych w ramach tych ćwiczeń z programowania. W ramach tego czyszczenia zostaną usunięte te zasoby:

  • Zarządzana grupa instancji (${CURRENT_MIG_NAME}) i jej bazowe maszyny wirtualne.
  • Szablon instancji (${TEMPLATE_NAME}).
  • Kontrola stanu i reguły zapory sieciowej (${HEALTH_CHECK_NAME}).
  • Repozytorium Artifact Registry (${REPOSITORY}).
  • Konto usługi (jeśli zostało utworzone specjalnie na potrzeby tego laboratorium).

Jeśli nie chcesz już korzystać z projektu, możesz go usunąć, postępując zgodnie z tymi instrukcjami: Wyłączanie (usuwanie) projektów.

Gratulacje

Gratulacje! Codelab został ukończony.

Dowiedziałeś(-aś) się, jak bezpiecznie skalować zadania w Poufnej przestrzeni za pomocą zarządzanych grup instancji (MIG). Skonfigurowano automatyczne naprawianie, aby przywracać system po awariach, autoskalowanie, aby radzić sobie ze skokami ruchu, oraz przeprowadzono aktualizacje bez przestoju zarówno obrazu systemu operacyjnego zaufanej przestrzeni, jak i kontenera zbioru zadań.

Co dalej?

Zapoznaj się z dodatkowymi ćwiczeniami dotyczącymi Poufnej przestrzeni:

Więcej informacji