Django w Cloud Run

1. Wprowadzenie

894762ebb681671c.png

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 elementami ekosystemu Google Cloud, w tym z usługą Cloud SQL do obsługi zarządzanych baz danych, usługą Cloud Storage do obsługi ujednoliconego przechowywania obiektów oraz usługą Secret Manager do zarządzania sekretami.

Django to wysokiej jakości framework internetowy w Pythonie.

W tym samouczku użyjesz tych komponentów do wdrożenia małego projektu Django.

Uwaga: ta wersja Codelab została ostatnio zweryfikowana w Django 5.0. O ile w przyszłych aktualizacjach nie pojawią się zmiany, które spowodują przerwanie działania, to to ćwiczenie z programowania powinno działać. Sprawdź informacje o przyszłych wersjach Django.

Czego się nauczysz

  • Jak korzystać z 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 używać Container Registry do przechowywania utworzonych kontenerów
  • Wdrażanie w Cloud Run
  • Jak przeprowadzać migracje schematów baz danych w Cloud Build

2. Konfiguracja i wymagania

Konfiguracja środowiska w samodzielnym tempie

  1. 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ć.

fbef9caa1602edd0.png

a99b7ace416376c4.png

5e3ff691252acf41.png

  • Nazwa projektu to wyświetlana nazwa uczestników tego projektu. Jest to ciąg znaków, którego nie używają 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ć użyć własnego adresu e-mail, aby sprawdzić, czy jest on dostępny. Nie można go zmienić po wykonaniu tego kroku. Pozostanie on do końca 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.
  1. Następnie musisz włączyć rozliczenia w konsoli Cloud, aby korzystać z zasobów i interfejsów API Cloud. Przejście przez ten samouczek nie będzie kosztowne, a być może nawet bezpłatne. Aby wyłączyć zasoby i uniknąć obciążenia opłatami po zakończeniu samouczka, możesz usunąć utworzone zasoby lub usunąć 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

Google Cloud można obsługiwać zdalnie z laptopa, ale w tym przypadku użyjemy Google Cloud Shell, czyli środowiska wiersza poleceń działającego w chmurze.

Aktywowanie Cloud Shell

  1. W konsoli Google Cloud kliknij Aktywuj Cloud Shell 853e55310c205094.png.

3c1dabeca90e44e5.png

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.

9c92662c6a846a5c.png

Uproszczenie i połączenie z Cloud Shell powinno zająć tylko kilka chwil.

9f0e51b578fecce5.png

Ta maszyna wirtualna zawiera wszystkie niezbędne narzędzia programistyczne. Zawiera stały katalog domowy o pojemności 5 GB i działa w Google Cloud, co znacznie poprawia wydajność sieci i uwierzytelnianie. Większość, jeśli nie wszystkie, zadań w tym ćwiczeniu 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.

  1. Aby potwierdzić uwierzytelnianie, 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`
  1. Aby sprawdzić, czy 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 je ustawić za pomocą tego polecenia:

gcloud config set project <PROJECT_ID>

Wynik 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 potrwać kilka chwil.

Po zakończeniu procesu powinien wyświetlić się komunikat podobny do tego:

Operation "operations/acf.cc11852d-40af-47ad-9d59-477a12847c9e" finished successfully.

4. Tworzenie projektu na podstawie szablonu

Jako przykładowy projekt Django użyjesz domyślnego szablonu projektu Django.

Aby utworzyć ten projekt szablonu, utwórz w Cloud Shell nowy katalog o nazwie django-cloudrun i przejdź do niego:

mkdir ~/django-cloudrun
cd ~/django-cloudrun

Następnie zainstaluj Django w tymczasowym środowisku wirtualnym:

virtualenv venv
source venv/bin/activate
pip install Django

Zapisz listę zainstalowanych pakietów w pliku requirements.txt

pip freeze > requirements.txt

Lista powinna zawierać Django i jego zależności: sqlparseasgiref.

Następnie utwórz nowy projekt szablonu:

django-admin startproject myproject .

Utworzy się nowy plik o nazwie manage.py i nowy folder o nazwie myproject, który będzie zawierać kilka plików, w tym settings.py.

Sprawdź, czy zawartość folderu najwyższego poziomu jest zgodna z oczekiwaniami:

ls -F
manage.py myproject/ requirements.txt venv/

Sprawdź, czy zawartość folderu myproject jest zgodna z oczekiwaniami:

ls -F myproject/
__init__.py asgi.py settings.py  urls.py  wsgi.py

Możesz teraz zamknąć tymczasowe środowisko wirtualne i je usunąć:

deactivate
rm -rf venv

Od tego momentu Django będzie wywoływane w kontenerze.

5. Tworzenie usług pomocniczych

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 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 kolejnych sekcjach tego CodeLab będziesz się odwoływać do tego konta po jego adresie e-mail. Ustaw tę wartość w zmiennej środowiskowej:

SERVICE_ACCOUNT=$(gcloud iam service-accounts list \
    --filter cloudrun-serviceaccount --format "value(email)")

Tworzenie repozytorium 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

Aby utworzyć instancję Cloud SQL:

gcloud sql instances create myinstance --project $PROJECT_ID \
  --database-version POSTGRES_14 --tier db-f1-micro --region $REGION

Ta operacja 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 uprawnienia do konta usługi, aby umożliwić połączenie 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 niepowtarzalna):

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

Przechowywanie konfiguracji jako obiektu tajnego

Po skonfigurowaniu usług pomocniczych zapisz te wartości w pliku chronionym za pomocą usługi Secret Manager.

Secret Manager pozwala przechowywać obiekty tajne w postaci binarnych obiektów blob lub ciągów tekstowych, a także nimi zarządzać i uzyskiwać do nich dostęp. Jest to dobre rozwiązanie do 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, 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

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ę

Ze względu na utworzone przez Ciebie usługi pomocnicze musisz wprowadzić w projekcie szablonu odpowiednie zmiany.

W tym celu musisz użyć funkcji django-environ, która używa zmiennych środowiskowych jako ustawień konfiguracji. Te zmienne będą wypełnione 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 zmienić jego nazwę na basesettings.py:.

mv myproject/settings.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",
    },
}

Przeczytaj komentarze do poszczególnych konfiguracji.

Pamiętaj, że w tym pliku mogą wystąpić błędy lintingu. To normalne. Cloud Shell nie ma kontekstu wymagań dotyczących tego projektu, więc może zgłaszać nieprawidłowe i nieużywane importy.

Zależność Pythona

Odszukaj plik requirements.txt i dodaj te pakiety:

cloudshell edit requirements.txt

requirements.txt (dołączanie)

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 pomijamy Dockerfile, ale zamiast tego używamy pakietów kompilacji typu Cloud Native Buildpacks. Pakiety kompilacji pomagają budować kontenery 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, utwórz najpierw nowy plik o nazwie Procfile na najwyższym poziomie projektu (w tym samym katalogu, w którym znajduje się plik manage.py), a potem skopiuj ten tekst:

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, kompilowanie i uruchamianie kroków migracji

Aby utworzyć schemat bazy danych w bazie danych Cloud SQL i wypełnić zasobnik Cloud Storage zasobami statycznymi, musisz uruchomić polecenia 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, za pomocą którego zalogujesz się w panelu administracyjnym Django.

W tym celu użyjesz zadań Cloud Run. Zadania Cloud Run umożliwiają uruchamianie procesów, które mają zdefiniowany koniec, dzięki czemu są idealne do wykonywania 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 ułatwić sobie pracę z zadaniami Cloud Run, utwórz skróty w pliku Procfile, dodając do pliku Procfile te punkty wejścia:

migrate: python manage.py migrate && python manage.py collectstatic --noinput --clear
createuser: python manage.py createsuperuser --username admin --email noop@example.com --noinput

Powinny pojawić się 3 pozycje: domyślny punkt wejścia web, punkt wejścia migrate do stosowania migracji baz danych oraz punkt wejścia createuser do uruchamiania polecenia createsuperuser.

Kompilowanie obrazu aplikacji

Po wprowadzeniu aktualizacji w pliku Procfile skompiluj obraz:

gcloud builds submit --pack image=${ARTIFACT_REGISTRY}/myimage

Tworzenie zadań Cloud Run

Teraz, gdy obraz już istnieje, możesz utworzyć za jego pomocą zadania Cloud Run.

Te zadania używają obrazu skompilowanego wcześniej, ale mają różne 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ń Cloud Run

Po skonfigurowaniu zadań uruchom migracje:

gcloud run jobs execute migrate --region $REGION --wait

Sprawdź, czy w wynikach polecenia jest komunikat „successfully completed” (zostało wykonane).

To polecenie wykonasz później, gdy będziesz wprowadzać zmiany w aplikacji.

W ramach konfiguracji bazy danych utwórz użytkownika za pomocą 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 wypełnieniu usług pomocniczych możesz utworzyć usługę Cloud Run, aby uzyskać do nich dostęp.

Wdróż usługę w Cloud Run, używając utworzonego wcześniej obrazu, za pomocą tego polecenia:

gcloud run deploy django-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

Kiedy operacja zostanie wykonana, w wierszu poleceń wyświetli się URL usługi:

Service [django-cloudrun] revision [django-cloudrun-00001-...] has been deployed and is serving 100 percent of traffic.
Service URL: https://django-cloudrun-...run.app

Możesz teraz zobaczyć wdrożony kontener, otwierając ten adres URL w przeglądarce:

d2dfaf668baabfcc.png

9. Otwieranie panelu administracyjnego Django

Jedną z głównych funkcji Django jest interaktywny interfejs administracyjny.

Aktualizowanie 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 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_ORIGINSALLOWED_HOSTS. Definiowanie elementu ALLOWED_HOSTS nie jest obowiązkowe, ale warto go dodać, ponieważ jest on wymagany w przypadku elementu 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żesz go dodać do tajnego klucza application_settings lub bezpośrednio jako zmienną środowiskową.

Implementacja poniżej korzysta z formatowaniaescaping gcloud.

Pobieranie adresów URL usług:

CLOUDRUN_SERVICE_URLS=$(gcloud run services describe django-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 django-cloudrun \
  --region $REGION \
  --update-env-vars "^##^CLOUDRUN_SERVICE_URLS=$CLOUDRUN_SERVICE_URLS"

Logowanie się w panelu administracyjnym Django

Aby uzyskać dostęp do interfejsu administracyjnego 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 ""

678cd382b7039769.png

de755ef7a1779dc6.png

10. Tworzenie aplikacji

Podczas tworzenia aplikacji warto ją przetestować lokalnie. W tym celu musisz połączyć się z bazą danych Cloud SQL („produkcyjną”) lub lokalną („testową”).

Łą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 ${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

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 bazy danych PostgreSQL i SQLite. PostgreSQL ma pewne funkcje, których nie ma SQLite, ale w wielu przypadkach 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.

Możesz uruchomić to polecenie po skonfigurowaniu połączenia z bazą danych produkcyjnej lub testowej. 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, wykonaj te czynności:

  • wprowadzić zmiany w nowym obrazie,
  • zastosuj migrację bazy danych lub migrację statyczną, a następnie
  • zaktualizuj usługę Cloud Run, 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ć usługę za pomocą nowego obrazu:

gcloud run services update django-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 go w dół, gdy zapotrzebowanie maleje. Płacisz tylko za procesor, pamięć i sieć wykorzystywane w trakcie obsługiwania żądań.
  • Cloud SQL umożliwia wdrożenie zarządzanej instancji PostgreSQL, która jest automatycznie obsługiwana i natywnie integruje się z wieloma systemami Google Cloud.
  • Cloud Storage umożliwia korzystanie z chmury w sposób płynny w Django.
  • Menedżer obiektów tajnych umożliwia przechowywanie obiektów tajnych i udostępnianie ich określonym częściom Google Cloud.

Czyszczenie danych

Oto czynności, które musisz wykonać, 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 potem kliknij Usuń.
  • W oknie wpisz identyfikator projektu i kliknij Wyłącz, aby usunąć projekt.

Więcej informacji