1. Wprowadzenie
Cloud Run to zarządzana platforma obliczeniowa, która umożliwia uruchamianie bezstanowych kontenerów wywoływanych przez żądania HTTP. Cloud Run jest rozwiązaniem bezserwerowym, które nie wymaga zarządzania infrastrukturą, dzięki czemu możesz skupić się na tym, co najważniejsze, czyli tworzeniu świetnych aplikacji.
Jest ona też natywnie połączona z wieloma innymi częściami ekosystemu Google Cloud, w tym z usługą Cloud SQL do obsługi zarządzanych baz danych, Cloud Storage do obsługi ujednoliconego przechowywania obiektów oraz Secret Manager do zarządzania sekretami.
Wagtail to system zarządzania treścią (CMS) typu open source stworzony na bazie Django. Django to ogólna platforma internetowa w języku Python.
W tym samouczku użyjesz tych komponentów do wdrożenia małego projektu Wagtail.
Uwaga: ta wersja Codelab była ostatnio sprawdzana w Wagtail 5.2.2, która obsługuje Django 5.
Czego się nauczysz
- Jak używać Cloud Shell
- Jak utworzyć bazę danych Cloud SQL
- Tworzenie zasobnika Cloud Storage
- Tworzenie obiektów tajnych w usłudze Secret Manager
- Jak używać tajemnic z różnych usług Google Cloud
- Jak połączyć komponenty Google Cloud z usługą Cloud Run
- Jak przechowywać utworzone kontenery w Container Registry
- Wdrażanie w Cloud Run
- Jak przeprowadzać migracje schematu bazy danych w Cloud Build
2. Konfiguracja i wymagania
Konfiguracja środowiska w samodzielnym tempie
- Zaloguj się w konsoli Google Cloud i utwórz nowy projekt lub wykorzystaj już istniejący. Jeśli nie masz jeszcze konta Gmail ani Google Workspace, musisz je utworzyć.
- Nazwa projektu to wyświetlana nazwa uczestników tego projektu. To ciąg znaków, który nie jest używany przez interfejsy API Google. Zawsze możesz ją zaktualizować.
- Identyfikator projektu jest niepowtarzalny w ramach wszystkich projektów Google Cloud i nie można go zmienić (po ustawieniu). Konsola Cloud automatycznie generuje unikalny ciąg znaków. Zwykle nie ma znaczenia, jaki to ciąg. W większości laboratoriów z kodem musisz podać identyfikator projektu (zwykle oznaczony jako
PROJECT_ID). Jeśli nie podoba Ci się wygenerowany identyfikator, możesz wygenerować inny losowy. Możesz też spróbować własnych sił i sprawdzić, czy jest dostępna. Po wykonaniu tej czynności nie można jej już zmienić. Pozostanie ona przez cały czas trwania projektu. - Informacyjnie: istnieje jeszcze 3 wartość, numer projektu, której używają niektóre interfejsy API. Więcej informacji o wszystkich 3 wartościach znajdziesz w dokumentacji.
- Następnie musisz włączyć płatności w Cloud Console, aby korzystać z zasobów Cloud/interfejsów API. Przejście przez ten samouczek nie będzie kosztowne. Aby wyłączyć zasoby w celu uniknięcia naliczania opłat po zakończeniu tego samouczka, możesz usunąć utworzone zasoby lub projekt. Nowi użytkownicy Google Cloud mogą skorzystać z programu bezpłatnego okresu próbnego o wartości 300 USD.
Google Cloud Shell,
Google Cloud można obsługiwać zdalnie z Twojego laptopa, ale w ramach tego ćwiczenia z programowania wykorzystamy Google Cloud Shell – środowisko wiersza poleceń działające w chmurze.
Aktywowanie Cloud Shell
- W konsoli Cloud kliknij Aktywuj Cloud Shell
.
Jeśli uruchamiasz Cloud Shell po raz pierwszy, zobaczysz ekran pośredni, na którym opisano, czym jest to środowisko. Jeśli taki ekran się wyświetlił, kliknij Dalej.
Uproszczenie i połączenie z Cloud Shell powinno zająć tylko kilka chwil.
Ta maszyna wirtualna ma wszystkie potrzebne narzędzia dla programistów. Zawiera stały katalog domowy o pojemności 5 GB i działa w Google Cloud, co znacznie zwiększa wydajność sieci i uwierzytelnianie. Większość zadań w ramach tego ćwiczenia z programowania można wykonać w przeglądarce.
Po połączeniu z Cloud Shell powinieneś zobaczyć, że jesteś uwierzytelniony i że projekt jest ustawiony na identyfikator Twojego projektu.
- Uruchom to polecenie w Cloud Shell, aby potwierdzić, że jesteś uwierzytelniony:
gcloud auth list
Wynik polecenia
Credentialed Accounts
ACTIVE ACCOUNT
* <my_account>@<my_domain.com>
To set the active account, run:
$ gcloud config set account `ACCOUNT`
- Uruchom to polecenie w Cloud Shell, aby sprawdzić, czy polecenie gcloud zna Twój projekt:
gcloud config list project
Dane wyjściowe polecenia
[core] project = <PROJECT_ID>
Jeśli nie, możesz ustawić je za pomocą tego polecenia:
gcloud config set project <PROJECT_ID>
Dane wyjściowe polecenia
Updated property [core/project].
3. Włącz interfejsy Cloud API
W Cloud Shell włącz interfejsy Cloud API dla komponentów, których będziesz używać:
gcloud services enable \ run.googleapis.com \ sql-component.googleapis.com \ sqladmin.googleapis.com \ compute.googleapis.com \ cloudbuild.googleapis.com \ secretmanager.googleapis.com \ artifactregistry.googleapis.com
Ponieważ po raz pierwszy wywołujesz interfejsy API z gcloud, pojawi się prośba o autoryzację użycia danych logowania do wysłania tego żądania. Spowoduje to uruchomienie serwera raz na sesję Cloud Shell.
Wykonanie tej operacji może chwilę potrwać.
Po zakończeniu powinien wyświetlić się komunikat o powodzeniu podobny do tego:
Operation "operations/acf.cc11852d-40af-47ad-9d59-477a12847c9e" finished successfully.
4. Tworzenie projektu na podstawie szablonu
Jako przykładowego projektu w Wagtail użyjesz domyślnego szablonu projektu Wagtail. Aby to zrobić, tymczasowo zainstaluj Wagtail, aby wygenerować szablon.
Aby utworzyć ten projekt szablonu, w Cloud Shell utwórz nowy katalog o nazwie wagtail-cloudrun i przejdź do niego:
mkdir ~/wagtail-cloudrun cd ~/wagtail-cloudrun
Następnie zainstaluj Wagtail w tymczasowym środowisku wirtualnym:
virtualenv venv source venv/bin/activate pip install wagtail
Następnie utwórz nowy projekt szablonu w bieżącym folderze:
wagtail start myproject .
W bieżącym folderze znajdziesz teraz szablon projektu Wagtail:
ls -F
Dockerfile home/ manage.py* myproject/ requirements.txt search/ venv/
Możesz teraz zamknąć i usunąć tymczasowe środowisko wirtualne:
deactivate rm -rf venv
Od tego momentu Wagtail będzie wywoływany w kontenerze.
5. Tworzenie usług bazowych
Teraz utwórz usługi pomocnicze: dedykowane konto usługi, rejestr artefaktów, bazę danych Cloud SQL, katalog Cloud Storage i kilka wartości w usłudze Secret Manager.
Zabezpieczenie wartości haseł używanych w wdrożeniu jest ważne dla bezpieczeństwa każdego projektu i zapewnia, że nikt przypadkowo nie wprowadzi haseł w niewłaściwym miejscu (np. bezpośrednio w plikach ustawień lub wpisanych bezpośrednio w terminalu, gdzie można je odzyskać z historii).
Na początek ustaw 2 podstawowe zmienne środowiskowe, z których jedna będzie odpowiadać identyfikatorowi projektu:
PROJECT_ID=$(gcloud config get-value core/project)
I jedno dla regionu:
REGION=us-central1
utworzyć konto usługi,
Aby ograniczyć dostęp usługi do innych części Google Cloud, utwórz dedykowane konto usługi:
gcloud iam service-accounts create cloudrun-serviceaccount
W kolejnych sekcjach tego ćwiczenia z programowania będziesz odwoływać się do tego konta, podając jego adres e-mail. Ustaw tę wartość w zmiennej środowiskowej:
SERVICE_ACCOUNT=$(gcloud iam service-accounts list \
--filter cloudrun-serviceaccount --format "value(email)")
Tworzenie Artifact Registry
Aby zapisać skompilowany obraz kontenera, utwórz rejestr kontenerów w wybranym regionie:
gcloud artifacts repositories create containers --repository-format docker --location $REGION
W kolejnych sekcjach tego Codelab będziesz się odwoływać do tego rejestru po nazwie:
ARTIFACT_REGISTRY=${REGION}-docker.pkg.dev/${PROJECT_ID}/containers
Tworzenie bazy danych
Utwórz instancję Cloud SQL:
gcloud sql instances create myinstance --project $PROJECT_ID \ --database-version POSTGRES_14 --tier db-f1-micro --region $REGION
Wykonanie tej operacji może potrwać kilka minut.
W takim przypadku utwórz bazę danych:
gcloud sql databases create mydatabase --instance myinstance
W tej samej instancji utwórz użytkownika:
DJPASS="$(cat /dev/urandom | LC_ALL=C tr -dc 'a-zA-Z0-9' | fold -w 30 | head -n 1)" gcloud sql users create djuser --instance myinstance --password $DJPASS
Przyznaj kontu usługi uprawnienia do połączenia się z instancją:
gcloud projects add-iam-policy-binding $PROJECT_ID \
--member serviceAccount:${SERVICE_ACCOUNT} \
--role roles/cloudsql.client
Tworzenie zasobnika na dane
Utwórz zasobnik Cloud Storage (nazwa musi być globalnie unikalna):
GS_BUCKET_NAME=${PROJECT_ID}-media
gcloud storage buckets create gs://${GS_BUCKET_NAME} --location ${REGION}
Przyznaj uprawnienia do administrowania zasobnikiem kontu usługi:
gcloud storage buckets add-iam-policy-binding gs://${GS_BUCKET_NAME} \
--member serviceAccount:${SERVICE_ACCOUNT} \
--role roles/storage.admin
Obiekty przechowywane w zasobniku będą pochodzić z innej domeny (adres URL zasobnika, a nie Cloud Run), dlatego musisz skonfigurować ustawienia współdzielenia zasobów pomiędzy serwerami z różnych domen (CORS).
Utwórz nowy plik o nazwie cors.json z tą zawartością:
touch cors.json cloudshell edit cors.json
cors.json
[
{
"origin": ["*"],
"responseHeader": ["Content-Type"],
"method": ["GET"],
"maxAgeSeconds": 3600
}
]
Zastosuj tę konfigurację CORS do nowo utworzonego zasobnika na dane:
gsutil cors set cors.json gs://$GS_BUCKET_NAME
Przechowywanie konfiguracji jako obiektu tajnego
Po skonfigurowaniu usług tworzenia kopii zapasowych będziesz teraz przechowywać te wartości w pliku chronionym przez usługę Secret Manager.
Usługa Secret Manager umożliwia przechowywanie obiektów tajnych, zarządzanie nimi i dostęp do nich w postaci binarnych obiektów blob lub ciągów tekstowych. Można w nim również przechowywać informacje konfiguracyjne, takie jak hasła do bazy danych, klucze interfejsu API czy certyfikaty TLS wymagane przez aplikację w czasie działania.
Najpierw utwórz plik z wartościami ciągu połączenia z bazą danych, zasobem multimediów, klucza tajnego dla Django (używanego do podpisywania sesji i tokenów) oraz do włączenia debugowania:
echo DATABASE_URL=\"postgres://djuser:${DJPASS}@//cloudsql/${PROJECT_ID}:${REGION}:myinstance/mydatabase\" > .env
echo GS_BUCKET_NAME=\"${GS_BUCKET_NAME}\" >> .env
echo SECRET_KEY=\"$(cat /dev/urandom | LC_ALL=C tr -dc 'a-zA-Z0-9' | fold -w 50 | head -n 1)\" >> .env
echo DEBUG=True >> .env
Następnie utwórz obiekt tajny o nazwie application_settings, używając tego pliku jako obiektu tajnego:
gcloud secrets create application_settings --data-file .env
Przyznaj temu kontu usługi dostęp do tego obiektu tajnego:
gcloud secrets add-iam-policy-binding application_settings \
--member serviceAccount:${SERVICE_ACCOUNT} --role roles/secretmanager.secretAccessor
Sprawdź, czy obiekt tajny został utworzony, wyświetlając listę obiektów tajnych:
gcloud secrets versions list application_settings
Po potwierdzeniu utworzenia obiektu tajnego usuń plik lokalny:
rm .env
6. Skonfiguruj aplikację
Utworzony wcześniej projekt szablonu wymaga teraz wprowadzenia pewnych zmian. Te zmiany uproszczą złożoność konfiguracji ustawień szablonów dostępnych w Wagtail, a także zintegrują Wagtail z wcześniej utworzonymi usługami tworzenia kopii zapasowych.
Konfiguracja
Znajdź wygenerowany plik ustawień base.py i zmień jego nazwę na basesettings.py w głównym folderze myproject:
mv myproject/settings/base.py myproject/basesettings.py
Za pomocą edytora internetowego Cloud Shell utwórz nowy plik settings.py z tym kodem:
touch myproject/settings.py cloudshell edit myproject/settings.py
myproject/settings.py
import io
import os
from urllib.parse import urlparse
import environ
# Import the original settings from each template
from .basesettings import *
# Load the settings from the environment variable
env = environ.Env()
env.read_env(io.StringIO(os.environ.get("APPLICATION_SETTINGS", None)))
# Setting this value from django-environ
SECRET_KEY = env("SECRET_KEY")
# Ensure myproject is added to the installed applications
if "myproject" not in INSTALLED_APPS:
INSTALLED_APPS.append("myproject")
# If defined, add service URLs to Django security settings
CLOUDRUN_SERVICE_URLS = env("CLOUDRUN_SERVICE_URLS", default=None)
if CLOUDRUN_SERVICE_URLS:
CSRF_TRUSTED_ORIGINS = env("CLOUDRUN_SERVICE_URLS").split(",")
# Remove the scheme from URLs for ALLOWED_HOSTS
ALLOWED_HOSTS = [urlparse(url).netloc for url in CSRF_TRUSTED_ORIGINS]
else:
ALLOWED_HOSTS = ["*"]
# Default false. True allows default landing pages to be visible
DEBUG = env("DEBUG", default=False)
# Set this value from django-environ
DATABASES = {"default": env.db()}
# Change database settings if using the Cloud SQL Auth Proxy
if os.getenv("USE_CLOUD_SQL_AUTH_PROXY", None):
DATABASES["default"]["HOST"] = "127.0.0.1"
DATABASES["default"]["PORT"] = 5432
# Define static storage via django-storages[google]
GS_BUCKET_NAME = env("GS_BUCKET_NAME")
STATICFILES_DIRS = []
GS_DEFAULT_ACL = "publicRead"
STORAGES = {
"default": {
"BACKEND": "storages.backends.gcloud.GoogleCloudStorage",
},
"staticfiles": {
"BACKEND": "storages.backends.gcloud.GoogleCloudStorage",
},
}
Poświęć trochę czasu na zapoznanie się z komentarzami na temat poszczególnych konfiguracji.
Pamiętaj, że w tym pliku mogą wystąpić błędy lintingu. To normalne. Cloud Shell nie ma kontekstu wymagań dla tego projektu, więc może zgłaszać nieprawidłowe importy i nieużywane importy.
Następnie usuń stary folder ustawień.
rm -rf myproject/settings/
Będziesz mieć wtedy 2 pliki ustawień: jeden z Wagtail i jeden utworzony przed chwilą, który zawiera te ustawienia:
ls myproject/*settings*
myproject/basesettings.py myproject/settings.py
Na koniec otwórz plik ustawień manage.py i zaktualizuj konfigurację, aby wskazać Wagtail plik główny settings.py.
cloudshell edit manage.py
Wiersz management.py (przed)
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings.dev")
wiersz manage.py (po)
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings")
Wprowadź te same zmiany w pliku myproject/wsgi.py:
cloudshell edit myproject/wsgi.py
wiersz myproject/wsgi.py (przed)
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings.dev")
wiersz myproject/wsgi.py (po)
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings")
Usuń automatycznie utworzony plik Dockerfile:
rm Dockerfile
Zależności Pythona
Odszukaj plik requirements.txt i dodaj te pakiety:
cloudshell edit requirements.txt
requirements.txt (dodawanie)
gunicorn psycopg2-binary django-storages[google] django-environ
Definiowanie obrazu aplikacji
Cloud Run uruchomi dowolny kontener, o ile jest on zgodny z umową dotyczącą kontenerów Cloud Run. W tym samouczku postanowiono pominąć Dockerfile i zamiast tego użyć pakietów kompilacji natywnych w chmurze. Pakiety kompilacji ułatwiają tworzenie kontenerów dla popularnych języków, w tym Pythona.
W tym samouczku dostosowujemy Procfile, który służy do uruchamiania aplikacji internetowej.
Aby skonteneryzować projekt szablonu, najpierw utwórz nowy plik o nazwie Procfile na najwyższym poziomie projektu (w tym samym katalogu co manage.py) i skopiuj tę treść:
touch Procfile cloudshell edit Procfile
Procfile
web: gunicorn --bind 0.0.0.0:$PORT --workers 1 --threads 8 --timeout 0 myproject.wsgi:application
7. Skonfiguruj, skompiluj i przeprowadź migrację
Aby utworzyć schemat bazy danych w bazie danych Cloud SQL i zapełnić zasobnik Cloud Storage zasobami statycznymi, musisz uruchomić migrate i collectstatic.
Te podstawowe polecenia migracji Django należy wykonać w kontekście utworzonego obrazu kontenera z dostępem do bazy danych.
Musisz też uruchomić createsuperuser, aby utworzyć konto administratora i zalogować się do administratora Django.
W tym celu użyjesz zadań Cloud Run. Zadania Cloud Run umożliwiają uruchamianie procesów o określonym zakończeniu, dzięki czemu idealnie nadają się do zadań administracyjnych.
Definiowanie hasła superużytkownika Django
Aby utworzyć konto superużytkownika, użyj nieinteraktywnej wersji polecenia createsuperuser. To polecenie wymaga użycia zmiennej środowiskowej o specjalnej nazwie zamiast prompta z prośbą o podanie hasła.
Utwórz nowy obiekt tajny, używając losowo wygenerowanego hasła:
echo -n $(cat /dev/urandom | LC_ALL=C tr -dc 'a-zA-Z0-9' | fold -w 30 | head -n 1) | gcloud secrets create django_superuser_password --data-file=-
Pozwól kontu usługi na dostęp do tego obiektu tajnego:
gcloud secrets add-iam-policy-binding django_superuser_password \
--member serviceAccount:${SERVICE_ACCOUNT} \
--role roles/secretmanager.secretAccessor
Aktualizowanie profilu Procfile
Aby zwiększyć przejrzystość zadań Cloud Run, utwórz skróty w pliku Procfile, dołącz te punkty wejścia do Procfile:
migrate: python manage.py migrate && python manage.py collectstatic --noinput --clear createuser: python manage.py createsuperuser --username admin --email noop@example.com --noinput
Powinny być teraz 3 pozycje: domyślny punkt wejścia web, punkt wejścia migrate do stosowania migracji bazy danych i punkt początkowy createuser uruchamiający polecenie createsuperuser.
Tworzenie obrazu aplikacji
Po zaktualizowaniu Procfile utwórz obraz:
gcloud builds submit --pack image=${ARTIFACT_REGISTRY}/myimage
Tworzenie zadań Cloud Run
Gdy obraz istnieje, możesz utworzyć zadania Cloud Run za jego pomocą.
Te zadania korzystają z wcześniej utworzonego obrazu, ale używają innych wartości command. Te wartości są mapowane na wartości w pliku Procfile.
Utwórz zadanie migracji:
gcloud run jobs create migrate \
--region $REGION \
--image ${ARTIFACT_REGISTRY}/myimage \
--set-cloudsql-instances ${PROJECT_ID}:${REGION}:myinstance \
--set-secrets APPLICATION_SETTINGS=application_settings:latest \
--service-account $SERVICE_ACCOUNT \
--command migrate
Utwórz zadanie tworzenia użytkownika:
gcloud run jobs create createuser \
--region $REGION \
--image ${ARTIFACT_REGISTRY}/myimage \
--set-cloudsql-instances ${PROJECT_ID}:${REGION}:myinstance \
--set-secrets APPLICATION_SETTINGS=application_settings:latest \
--set-secrets DJANGO_SUPERUSER_PASSWORD=django_superuser_password:latest \
--service-account $SERVICE_ACCOUNT \
--command createuser
Wykonywanie zadań w Cloud Run
Po skonfigurowaniu zadań uruchom migracje:
gcloud run jobs execute migrate --region $REGION --wait
Sprawdź, czy w wynikach polecenia jest komunikat „successfully complete” (ukończono wykonanie).
To polecenie wykonasz później, gdy wprowadzisz zmiany w aplikacji.
Po skonfigurowaniu bazy danych utwórz użytkownika za pomocą tego zadania:
gcloud run jobs execute createuser --region $REGION --wait
Sprawdź, czy w wynikach polecenia jest komunikat „successfully completed” (zostało wykonane).
Nie trzeba będzie ponownie wykonywać tego polecenia.
8. Wdrożenie w Cloud Run
Po utworzeniu i zapełnieniu usług bazowych możesz utworzyć usługę Cloud Run, aby uzyskać do nich dostęp.
Początkowe wdrożenie skonteneryzowanej aplikacji w Cloud Run zostanie utworzone za pomocą tego polecenia:
gcloud run deploy wagtail-cloudrun \
--region $REGION \
--image ${ARTIFACT_REGISTRY}/myimage \
--set-cloudsql-instances ${PROJECT_ID}:${REGION}:myinstance \
--set-secrets APPLICATION_SETTINGS=application_settings:latest \
--service-account $SERVICE_ACCOUNT \
--allow-unauthenticated
Poczekaj chwilę na zakończenie wdrażania. Kiedy operacja zostanie wykonana, w wierszu poleceń wyświetli się URL usługi:
Service [wagtail-cloudrun] revision [wagtail-cloudrun-00001-...] has been deployed and is serving 100 percent of traffic. Service URL: https://wagtail-cloudrun-...run.app
Możesz teraz wyświetlić wdrożony kontener, otwierając ten URL w przeglądarce:
9. Otwieranie panelu administracyjnego Django
Aktualizacja ustawień CSRF
Django zawiera zabezpieczenia przed fałszowaniem żądań z innych witryn (CSRF). Za każdym razem, gdy w Twojej witrynie Django przesyłany jest formularz, w tym podczas logowania się w panelu administracyjnym Django, sprawdzane jest ustawienie zaufanych źródeł. Jeśli nie pasuje ono do pochodzenia żądania, Django zwraca błąd.
Jeśli w pliku mysite/settings.py zdefiniowana jest zmienna środowiskowa CLOUDRUN_SERVICE_URL, jest ona używana w ustawieniach CSRF_TRUSTED_ORIGINS i ALLOWED_HOSTS. Chociaż określenie atrybutu ALLOWED_HOSTS nie jest obowiązkowe, warto go dodać, ponieważ jest już wymagane w przypadku CSRF_TRUSTED_ORIGINS.
Ponieważ potrzebujesz adresu URL usługi, ta konfiguracja może zostać dodana dopiero po pierwszym wdrożeniu.
Aby dodać tę zmienną środowiskową, musisz zaktualizować usługę. Można go dodać do obiektu tajnego application_settings lub dodać bezpośrednio jako zmienną środowiskową.
Implementacja poniżej korzysta z formatowania i ucieczki gcloud.
Pobierz adres URL usługi:
CLOUDRUN_SERVICE_URLS=$(gcloud run services describe wagtail-cloudrun \ --region $REGION \ --format "value(metadata.annotations[\"run.googleapis.com/urls\"])" | tr -d '"[]') echo $CLOUDRUN_SERVICE_URLS
Ustaw tę wartość jako zmienną środowiskową w usłudze Cloud Run:
gcloud run services update wagtail-cloudrun \ --region $REGION \ --update-env-vars "^##^CLOUDRUN_SERVICE_URLS=$CLOUDRUN_SERVICE_URLS"
Logowanie do konsoli administracyjnej Django
Aby uzyskać dostęp do interfejsu administratora Django, dołącz /admin do adresu URL swojej usługi.
Zaloguj się, korzystając z nazwy użytkownika „admin”. i odzyskaj hasło, korzystając z następującego polecenia:
gcloud secrets versions access latest --secret django_superuser_password && echo ""
10. Tworzenie aplikacji
Podczas tworzenia aplikacji warto ją przetestować lokalnie. Aby to zrobić, musisz połączyć się z produkcyjną bazą danych Cloud SQL lub lokalną („testową”) bazą danych.
Łączenie z produkcyjną bazą danych
Z instancjami Cloud SQL możesz się łączyć za pomocą serwera proxy uwierzytelniania Cloud SQL. Ta aplikacja tworzy połączenie z bazą danych z Twojego komputera lokalnego.
Po zainstalowaniu serwera proxy uwierzytelniania Cloud SQL wykonaj te czynności:
# Create a virtualenv
virtualenv venv
source venv/bin/activate
pip install -r requirements.txt
# Copy the application settings to your local machine
gcloud secrets versions access latest --secret application_settings > temp_settings
# Run the Cloud SQL Auth Proxy
./cloud-sql-proxy --instances=${PROJECT_ID}:${REGION}:myinstance=tcp:5432
# In a new tab, start the local web server using these new settings
USE_CLOUD_SQL_AUTH_PROXY=true APPLICATION_SETTINGS=$(cat temp_settings) python manage.py runserver
Pamiętaj, aby po zakończeniu pracy usunąć plik temp_settings.
Łączenie z lokalną bazą danych SQLite
Możesz też użyć lokalnej bazy danych podczas tworzenia aplikacji. Django obsługuje zarówno bazy danych PostgreSQL, jak i SQLite. Są też pewne funkcje, których nie ma SQLite, ale w wielu przypadkach ich funkcje są identyczne.
Aby skonfigurować SQLite, musisz zaktualizować ustawienia aplikacji, aby wskazywały na lokalną bazę danych, a potem zastosować migracje schematu.
Aby skonfigurować tę metodę:
# Create a virtualenv virtualenv venv source venv/bin/activate pip install -r requirements.txt # Copy the application settings to your local machine gcloud secrets versions access latest --secret application_settings > temp_settings # Edit the DATABASE_URL setting to use a local sqlite file. For example: DATABASE_URL=sqlite:////tmp/my-tmp-sqlite.db # Set the updated settings as an environment variable APPLICATION_SETTINGS=$(cat temp_settings) # Apply migrations to the local database python manage.py migrate # Start the local web server python manage.py runserver
Pamiętaj, aby po zakończeniu pracy usunąć plik temp_settings.
Tworzę migracje
Gdy wprowadzasz zmiany w modelach bazy danych, może być konieczne wygenerowanie plików migracji Django za pomocą polecenia python manage.py makemigrations.
To polecenie możesz uruchomić po skonfigurowaniu produkcyjnego lub testowego połączenia z bazą danych. Pliki migracji możesz też wygenerować bez bazy danych, podając puste ustawienia:
SECRET_KEY="" DATABASE_URL="" GS_BUCKET_NAME="" python manage.py makemigrations
Instaluję aktualizacje aplikacji
Aby zastosować zmiany w aplikacji, musisz:
- wprowadzić zmiany w nowym obrazie,
- zastosuj migrację bazy danych lub migrację statyczną, a następnie
- zaktualizuj swoją usługę Cloud Run, tak aby używała nowego obrazu.
Aby utworzyć obraz:
gcloud builds submit --pack image=${ARTIFACT_REGISTRY}/myimage
Jeśli chcesz zastosować migrację, uruchom zadanie Cloud Run:
gcloud run jobs execute migrate --region $REGION --wait
Aby zaktualizować obraz w usłudze za pomocą nowego obrazu:
gcloud run services update wagtail-cloudrun \
--region $REGION \
--image ${ARTIFACT_REGISTRY}/myimage
11. Gratulacje!
Właśnie wdrożyliśmy w Cloud Run złożony projekt.
- Cloud Run automatycznie skaluje obraz kontenera w poziomie, aby obsługiwać otrzymane żądania, a następnie skaluje w dół, gdy zapotrzebowanie maleje. Płacisz tylko za procesor, pamięć i sieć wykorzystywane w trakcie obsługiwania żądań.
- Cloud SQL umożliwia obsługę administracyjną instancji PostgreSQL, która jest obsługiwana automatycznie i integruje się natywnie z wieloma systemami Google Cloud.
- Cloud Storage zapewnia łatwy dostęp do miejsca w chmurze w Django.
- Usługa Secret Manager umożliwia przechowywanie obiektów tajnych oraz zapewnianie do nich dostępu tylko w niektórych częściach Google Cloud.
Czyszczenie danych
Aby uniknąć obciążenia konta Google Cloud Platform opłatami za zasoby zużyte w tym samouczku:
- W Cloud Console otwórz stronę Zarządzanie zasobami.
- Na liście projektów wybierz swój projekt i kliknij Usuń.
- W oknie wpisz identyfikator projektu i kliknij Wyłącz, aby usunąć projekt.
Więcej informacji
- Django na Cloud Run: https://cloud.google.com/python/django/run
- Witamy w Cloud Run z językiem Python: https://codelabs.developers.google.com/codelabs/cloud-run-hello-python3.
- Python w Google Cloud: https://cloud.google.com/python
- Klient Pythona Google Cloud: https://github.com/googleapis/google-cloud-python
/