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.
Współpracuje też natywnie z wieloma innymi częściami ekosystemu Google Cloud, w tym z Cloud SQL do zarządzania bazami danych, Cloud Storage do ujednoliconego przechowywania obiektów i Secret Manager do zarządzania danymi tajnymi.
Django CMS to system zarządzania treścią (CMS) dla przedsiębiorstw, który jest oparty na Django. Django to zaawansowana platforma internetowa w języku Python.
W tym samouczku użyjesz tych komponentów do wdrożenia małego projektu Django CMS.
Uwaga: ten przewodnik został ostatnio zweryfikowany w przypadku Django CMS 4.1.2 za pomocą django-cms/cms-template w wersji 4.1.
Czego się nauczysz
- Jak korzystać z Cloud Shell
- Jak utworzyć bazę danych Cloud SQL
- Tworzenie zasobnika Cloud Storage
- Jak tworzyć obiekty tajne w usłudze Secret Manager
- Jak korzystać z sekretów w różnych usługach Google Cloud
- Łączenie komponentów Google Cloud z usługą Cloud Run
- Jak używać Container Registry do przechowywania skompilowanych kontenerów
- Jak wdrażać w Cloud Run
- Jak uruchamiać migracje schematu bazy danych w Cloud Build
2. Konfiguracja i wymagania
Samodzielne konfigurowanie środowiska
- Zaloguj się w konsoli Google Cloud i utwórz nowy projekt lub użyj istniejącego. Jeśli nie masz jeszcze konta Gmail ani Google Workspace, musisz je utworzyć.
- Nazwa projektu to wyświetlana nazwa uczestników tego projektu. Jest to ciąg znaków, który nie jest używany przez interfejsy API Google. Zawsze możesz ją zaktualizować.
- Identyfikator projektu jest unikalny we wszystkich projektach Google Cloud i nie można go zmienić po ustawieniu. Konsola Cloud automatycznie generuje unikalny ciąg znaków. Zwykle nie musisz się tym przejmować. W większości ćwiczeń z programowania musisz odwoływać się do identyfikatora projektu (zwykle oznaczanego jako
PROJECT_ID). Jeśli wygenerowany identyfikator Ci się nie podoba, możesz wygenerować inny losowy identyfikator. Możesz też spróbować utworzyć własny adres i sprawdzić, czy jest dostępny. Po tym kroku nie można go zmienić i pozostaje on taki przez cały czas trwania projektu. - Warto wiedzieć, że istnieje też trzecia wartość, numer projektu, której używają niektóre interfejsy API. Więcej informacji o tych 3 wartościach znajdziesz w dokumentacji.
- Następnie musisz włączyć płatności w konsoli Cloud, aby korzystać z zasobów i interfejsów API Google Cloud. Wykonanie tego laboratorium nie będzie kosztować dużo, a może nawet nic. Aby wyłączyć zasoby i uniknąć naliczania opłat po zakończeniu tego samouczka, możesz usunąć utworzone zasoby lub projekt. Nowi użytkownicy Google Cloud mogą skorzystać z bezpłatnego okresu próbnego, w którym mają do dyspozycji środki w wysokości 300 USD.
Google Cloud Shell
Z Google Cloud można korzystać zdalnie na laptopie, ale w tym module użyjemy Google Cloud Shell, czyli środowiska wiersza poleceń działającego w chmurze.
Aktywowanie Cloud Shell
- W konsoli Cloud kliknij Aktywuj Cloud Shell
.
Jeśli uruchamiasz Cloud Shell po raz pierwszy, zobaczysz ekran pośredni z opisem tego środowiska. Jeśli pojawił się ekran pośredni, kliknij Dalej.
Uzyskanie dostępu do środowiska Cloud Shell i połączenie się z nim powinno zająć tylko kilka chwil.
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. Większość zadań w tym module, a być może wszystkie, możesz wykonać w przeglądarce.
Po połączeniu z Cloud Shell zobaczysz, że uwierzytelnianie zostało już przeprowadzone, a projekt jest już ustawiony na Twój identyfikator projektu.
- Aby potwierdzić, że uwierzytelnianie zostało przeprowadzone, uruchom w Cloud Shell to polecenie:
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`
- Aby potwierdzić, że polecenie gcloud zna Twój projekt, uruchom w Cloud Shell to polecenie:
gcloud config list project
Wynik polecenia
[core] project = <PROJECT_ID>
Jeśli nie, możesz go ustawić za pomocą tego polecenia:
gcloud config set project <PROJECT_ID>
Wynik polecenia
Updated property [core/project].
3. Włączanie interfejsów Cloud API
W Cloud Shell włącz interfejsy Cloud API dla komponentów, które będą używane:
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żywania Twoich danych logowania do wysłania tego żądania. Będzie to miało miejsce raz na sesję Cloud Shell.
Wykonanie tej operacji może potrwać kilka chwil.
Po zakończeniu powinien pojawić się komunikat o powodzeniu podobny do tego:
Operation "operations/acf.cc11852d-40af-47ad-9d59-477a12847c9e" finished successfully.
4. Tworzenie projektu szablonu
Jako przykładowy projekt Django CMS użyjesz cms-template.
Aby utworzyć ten projekt szablonu, użyj Cloud Shell do utworzenia nowego katalogu o nazwie djangocms-cloudrun i przejdź do niego:
mkdir ~/djangocms-cloudrun cd ~/djangocms-cloudrun
Zainstaluj pakiet django-cms w tymczasowym środowisku wirtualnym:
virtualenv venv source venv/bin/activate pip install djangocms-frontend\[cms-4]
Utwórz kopię projektu cms-template:
django-admin startproject --template https://github.com/django-cms/cms-template/archive/4.1.zip myproject .
Zmień nazwę pliku requirements.in na requirements.txt. (Plik .in jest generowany przez pip-tools w celu tworzenia plików requirements.txt, ale można go używać w takiej postaci, jeśli zmieni się rozszerzenie. W dalszych krokach pip oczekuje rozszerzenia .txt).
mv requirements.in requirements.txt
W folderze o nazwie myproject znajdziesz teraz projekt szablonu Django CMS:
ls -F
manage.py* media/ myproject/ project.db requirements.txt static/ venv/
Teraz możesz zamknąć tymczasowe środowisko wirtualne i je usunąć:
deactivate rm -rf venv
Z tego miejsca w kontenerze będzie wywoływany system Django CMS.
5. Tworzenie usług pomocniczych
Teraz utworzysz usługi pomocnicze: dedykowane konto usługi, Artifact Registry, bazę danych Cloud SQL, zasobnik Cloud Storage i wiele wartości Secret Manager.
Zabezpieczenie wartości haseł używanych we wdrożeniu jest ważne dla bezpieczeństwa każdego projektu i gwarantuje, że nikt przypadkowo nie umieści haseł w nieodpowiednich miejscach (np. bezpośrednio w plikach ustawień lub nie wpisze ich bezpośrednio w terminalu, z którego można je pobrać z historii).
Na początek ustaw 2 podstawowe zmienne środowiskowe, jedną dla identyfikatora projektu:
PROJECT_ID=$(gcloud config get-value core/project)
i jeden 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 dalszych częściach tego samouczka będziesz odwoływać się do tego konta za pomocą adresu e-mail. Ustaw tę wartość w zmiennej środowiskowej:
SERVICE_ACCOUNT=$(gcloud iam service-accounts list \
--filter cloudrun-serviceaccount --format "value(email)")
Utwórz 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 dalszych sekcjach tego samouczka będziesz odwoływać się 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 tej instancji 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 łą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 (pamiętaj, że nazwa musi być globalnie unikalna):
GS_BUCKET_NAME=${PROJECT_ID}-media
gcloud storage buckets create gs://${GS_BUCKET_NAME} --location ${REGION}
Przyznaj kontu usługi uprawnienia do administrowania zasobnikiem:
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ą miały inne źródło (adres URL zasobnika zamiast adresu URL Cloud Run), dlatego musisz skonfigurować ustawienia współdzielenia zasobów mię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 pamięci:
gsutil cors set cors.json gs://$GS_BUCKET_NAME
Zapisywanie konfiguracji jako obiektu tajnego
Po skonfigurowaniu usług pomocniczych zapiszesz te wartości w pliku chronionym za pomocą usługi Secret Manager.
Usługa Secret Manager umożliwia przechowywanie obiektów tajnych w postaci binarnych obiektów blob lub ciągów tekstowych, a także zarządzanie nimi i uzyskiwanie do nich dostępu. Sprawdza się w przypadku przechowywania informacji konfiguracyjnych, takich jak hasła do baz danych, klucze interfejsu API czy certyfikaty TLS potrzebne aplikacji w czasie wykonywania.
Najpierw utwórz plik z wartościami ciągu połączenia z bazą danych, zasobnika multimediów, klucza tajnego Django (używanego do kryptograficznego podpisywania sesji i tokenów) oraz włącz debugowanie:
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
Zezwól kontu usługi na dostęp do tego obiektu tajnego:
gcloud secrets add-iam-policy-binding application_settings \
--member serviceAccount:${SERVICE_ACCOUNT} --role roles/secretmanager.secretAccessor
Aby sprawdzić, czy obiekt tajny został utworzony, wyświetl listę obiektów tajnych:
gcloud secrets versions list application_settings
Po potwierdzeniu utworzenia obiektu tajnego usuń plik lokalny:
rm .env
6. Skonfiguruj aplikację
W związku z utworzonymi właśnie usługami pomocniczymi musisz wprowadzić w projekcie szablonu pewne zmiany.
Obejmuje to wprowadzenie django-environ do używania zmiennych środowiskowych jako ustawień konfiguracji, które wypełnisz wartościami zdefiniowanymi jako obiekty tajne. Aby to zrobić, rozszerz ustawienia szablonu. Musisz też dodać dodatkowe zależności Pythona.
Konfigurowanie ustawień
Przenieś plik settings.py i zmień jego nazwę na basesettings.py:.
mv myproject/settings.py myproject/basesettings.py
W edytorze internetowym 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ęć czas na przeczytanie komentarzy dodanych do każdej konfiguracji.
Pamiętaj, że w tym pliku mogą pojawić się błędy lintingu. To normalne. Cloud Shell nie ma kontekstu wymagań tego projektu, więc może zgłaszać nieprawidłowe i nieużywane importy.
Zależności Pythona
Znajdź plik requirements.txt i dołącz te pakiety:
cloudshell edit requirements.txt
requirements.txt (append)
gunicorn psycopg2-binary django-storages[google] django-environ
Określ obraz aplikacji
Cloud Run uruchomi każdy kontener, o ile jest on zgodny z umową dotyczącą kontenerów Cloud Run. W tym samouczku pominięto Dockerfile, ale zamiast tego użyto Cloud Native Buildpacks. Buildpacki pomagają w tworzeniu kontenerów dla popularnych języków, w tym Pythona.
W tym samouczku wybieramy dostosowanie Procfile używanego do uruchamiania aplikacji internetowej.
Aby skonteneryzować projekt szablonu, najpierw utwórz nowy plik o nazwie Procfile w katalogu najwyższego poziomu 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. Konfigurowanie, tworzenie i uruchamianie kroków migracji
Aby utworzyć schemat bazy danych w bazie danych Cloud SQL i wypełnić zasobnik Cloud Storage statycznymi zasobami, musisz uruchomić polecenia migrate i collectstatic.
Te podstawowe polecenia migracji Django muszą być uruchamiane w kontekście utworzonego obrazu kontenera z dostępem do bazy danych.
Musisz też uruchomić polecenie createsuperuser, aby utworzyć konto administratora do logowania się w panelu administracyjnym Django.
Aby to zrobić, użyjesz zadań Cloud Run. Zadania Cloud Run umożliwiają uruchamianie procesów, które mają określone zakończenie, dzięki czemu idealnie nadają się do zadań administracyjnych.
Określ hasło superużytkownika Django
Aby utworzyć superużytkownika, użyj nieinteraktywnej wersji polecenia createsuperuser. To polecenie wymaga specjalnie nazwanej zmiennej środowiskowej, która zastępuje prośbę o wpisanie 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=-
Zezwó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 pliku Procfile
Aby zwiększyć przejrzystość zadań Cloud Run, utwórz skróty w pliku Procfile i dołącz te punkty wejścia do pliku 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 widoczne 3 wpisy: domyślny punkt wejścia web, punkt wejścia migrate do stosowania migracji bazy danych i punkt wejścia createuser do uruchamiania polecenia createsuperuser.
Tworzenie obrazu aplikacji
Po wprowadzeniu zmian w pliku Procfile skompiluj obraz:
gcloud builds submit --pack image=${ARTIFACT_REGISTRY}/myimage
Tworzenie zadań Cloud Run
Teraz, gdy obraz już istnieje, możesz tworzyć za jego pomocą zadania Cloud Run.
Te zadania używają wcześniej utworzonego obrazu, ale mają inne wartości command. Odpowiadają one wartościom w 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
wykonywać zadania Cloud Run,
Po skonfigurowaniu zadań uruchom migracje:
gcloud run jobs execute migrate --region $REGION --wait
Sprawdź, czy w wynikach tego polecenia jest komunikat „successfully completed” (zostało wykonane).
To polecenie uruchomisz później, gdy będziesz wprowadzać zmiany w aplikacji.
Po skonfigurowaniu bazy danych utwórz użytkownika za pomocą zadania:
gcloud run jobs execute createuser --region $REGION --wait
Sprawdź, czy w wynikach tego polecenia jest komunikat „successfully completed” (zostało wykonane).
Nie musisz ponownie uruchamiać tego polecenia.
8. Wdrożenie w Cloud Run
Po utworzeniu i wypełnieniu usług pomocniczych możesz utworzyć usługę Cloud Run, aby uzyskać do nich dostęp.
Początkowe wdrożenie skonteneryzowanej aplikacji w Cloud Run tworzy się za pomocą tego polecenia:
gcloud run deploy djangocms-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 [djangocms-cloudrun] revision [djangocms-cloudrun-00001-...] has been deployed and is serving 100 percent of traffic. Service URL: https://djangocms-cloudrun-...run.app
Możesz teraz zobaczyć wdrożony kontener, otwierając ten adres URL w przeglądarce:
Ponieważ jest to nowa instalacja, automatycznie przekierujemy Cię na stronę logowania.
9. Dostęp do panelu administracyjnego Django
Jedną z głównych funkcji Django CMS jest interaktywny panel administracyjny.
Aktualizowanie ustawień CSRF
Django zawiera zabezpieczenia przed fałszowaniem żądań z innych witryn (CSRF). Za każdym razem, gdy w witrynie Django przesyłany jest formularz, w tym podczas logowania się w panelu administracyjnym Django, sprawdzane jest ustawienie Zaufane źródła. Jeśli nie pasuje do źródła żą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. Definiowanie parametru ALLOWED_HOSTS nie jest obowiązkowe, ale warto go dodać, ponieważ jest on już wymagany w przypadku parametru CSRF_TRUSTED_ORIGINS.
Ponieważ potrzebujesz adresu URL usługi, tej konfiguracji nie można dodać przed pierwszym wdrożeniem.
Aby dodać tę zmienną środowiskową, musisz zaktualizować usługę. Można go dodać do klucza tajnego application_settings lub bezpośrednio jako zmienną środowiskową.
Poniższe wdrożenie korzysta z formatowania i sekwencji ucieczki gcloud.
Pobierz adres URL usługi:
CLOUDRUN_SERVICE_URLS=$(gcloud run services describe djangocms-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 djangocms-cloudrun \ --region $REGION \ --update-env-vars "^##^CLOUDRUN_SERVICE_URLS=$CLOUDRUN_SERVICE_URLS"
Logowanie się w panelu administracyjnym Django
Aby uzyskać dostęp do interfejsu administratora Django, dodaj /admin do adresu URL usługi.
Teraz zaloguj się przy użyciu nazwy użytkownika „admin” i odzyskaj hasło za pomocą tego polecenia:
gcloud secrets versions access latest --secret django_superuser_password && echo ""
10. Instalowanie aktualizacji aplikacji
Podczas tworzenia aplikacji warto ją testować lokalnie. Aby to zrobić, musisz połączyć się z bazą danych Cloud SQL („produkcyjną”) lub lokalną („testową”).
Łączenie z produkcyjną bazą danych
Z instancjami Cloud SQL możesz łączyć się za pomocą serwera proxy uwierzytelniania Cloud SQL. Ta aplikacja tworzy połączenie z bazą danych z 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 ${PROJECT_ID}:${REGION}:myinstance
# 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
Po zakończeniu pracy usuń plik temp_settings.
Nawiązywanie połączenia z lokalną bazą danych SQLite
Podczas tworzenia aplikacji możesz też używać lokalnej bazy danych. Django obsługuje bazy danych PostgreSQL i SQLite. Niektóre funkcje PostgreSQL nie są dostępne w SQLite, ale w wielu przypadkach funkcjonalność jest identyczna.
Aby skonfigurować SQLite, musisz zaktualizować ustawienia aplikacji, aby wskazywały lokalną bazę danych, a następnie 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
Po zakończeniu pracy usuń plik temp_settings.
Tworzę migracje
Wprowadzając zmiany w modelach bazy danych, może być konieczne wygenerowanie plików migracji Django przez uruchomienie polecenia python manage.py makemigrations.
To polecenie możesz uruchomić po skonfigurowaniu połączenia z bazą danych produkcyjną lub testową. Możesz też wygenerować pliki migracji bez bazy danych, podając puste ustawienia:
SECRET_KEY="" DATABASE_URL="" GS_BUCKET_NAME="" python manage.py makemigrations
Instalowanie aktualizacji aplikacji
Aby zastosować zmiany w aplikacji, musisz:
- wprowadzić zmiany w nowym obrazie,
- zastosować migracje statyczne lub dotyczące baz danych, a następnie
- zaktualizować usługę Cloud Run, aby używała nowego obrazu.
Aby utworzyć obraz:
gcloud builds submit --pack image=${ARTIFACT_REGISTRY}/myimage
Jeśli masz jakieś migracje do zastosowania, uruchom zadanie Cloud Run:
gcloud run jobs execute migrate --region $REGION --wait
Aby zaktualizować usługę za pomocą nowego obrazu:
gcloud run services update djangocms-cloudrun \
--platform managed \
--region $REGION \
--image gcr.io/${PROJECT_ID}/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 go w dół, gdy zapotrzebowanie maleje. Płacisz tylko za procesor, pamięć i sieć wykorzystywane w trakcie obsługiwania żądań.
- Cloud SQL umożliwia udostępnianie zarządzanej instancji PostgreSQL, która jest automatycznie obsługiwana i natywnie zintegrowana z wieloma systemami Google Cloud.
- Cloud Storage umożliwia korzystanie z pamięci w chmurze w sposób, który jest bezproblemowo dostępny w Django.
- Usługa Secret Manager umożliwia przechowywanie obiektów tajnych i udostępnianie ich tylko określonym częściom 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 projekt, a następnie kliknij Usuń.
- W oknie wpisz identyfikator projektu i kliknij Wyłącz, aby usunąć projekt.
Więcej informacji
- Django w Cloud Run: https://cloud.google.com/python/django/run
- Hello Cloud Run with Python: https://codelabs.developers.google.com/codelabs/cloud-run-hello-python3
- Python w Google Cloud: https://cloud.google.com/python
- Klient Google Cloud Python: https://github.com/googleapis/google-cloud-python