CMS dla Django w Cloud Run

CMS dla Django w Cloud Run

Informacje o tym ćwiczeniu (w Codelabs)

subjectOstatnia aktualizacja: sty 31, 2024
account_circleAutorzy: Katie McLaughlin

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.

Natywnie współpracuje też z wieloma innymi częściami ekosystemu Google Cloud, takimi jak Cloud SQL w przypadku zarządzanych baz danych, Cloud Storage do ujednoliconej pamięci obiektów i Secret Manager do zarządzania obiektami tajnymi.

Django CMS to system zarządzania treścią (CMS) dla firm stworzony na bazie Django. Django to ogólna platforma internetowa w języku Python.

W tym samouczku będziesz używać tych komponentów do wdrożenia małego projektu CMS dla Django.

Uwaga: to ćwiczenie z programowania zostało ostatnio zweryfikowane w systemie Django CMS 3.11.4 przez django-cms/cms-template v3.11.

Czego się nauczysz

  • Jak używać Cloud Shell
  • Jak utworzyć bazę danych Cloud SQL
  • Jak utworzyć zasobnik Cloud Storage
  • Jak tworzyć obiekty tajne usługi Secret Manager
  • Jak używać obiektów tajnych 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
  • Jak wdrażać w Cloud Run
  • Jak przeprowadzać migracje schematu bazy danych w Cloud Build

2. Konfiguracja i wymagania

Samodzielne konfigurowanie środowiska

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

fbef9caa1602edd0.png

a99b7ace416376c4.png

5e3ff691252acf41.png

  • Nazwa projektu jest wyświetlaną nazwą uczestników tego projektu. To ciąg znaków, który nie jest używany przez interfejsy API Google. W każdej chwili możesz ją zaktualizować.
  • Identyfikator projektu jest unikalny we wszystkich projektach Google Cloud i nie można go zmienić (po jego ustawieniu nie można go zmienić). Cloud Console automatycznie wygeneruje unikalny ciąg znaków. zwykle nieważne, co ona jest. W większości ćwiczeń w Codelabs musisz podać swój identyfikator projektu (zwykle identyfikowany jako PROJECT_ID). Jeśli nie podoba Ci się wygenerowany identyfikator, możesz wygenerować kolejny 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.
  • Jest jeszcze trzecia wartość, numer projektu, z którego korzystają niektóre interfejsy API. Więcej informacji o wszystkich 3 wartościach znajdziesz w dokumentacji.
  1. Następnie musisz włączyć płatności w Cloud Console, aby korzystać z zasobów Cloud/interfejsów API. Ukończenie tego ćwiczenia z programowania nic nie kosztuje. 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

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

3c1dabeca90e44e5.png

Jeśli uruchamiasz Cloud Shell po raz pierwszy, zobaczysz ekran pośredni z opisem tej usługi. Jeśli wyświetlił się ekran pośredni, kliknij Dalej.

9c92662c6a846a5c.png

Uzyskanie dostępu do Cloud Shell i połączenie się z nim powinno zająć tylko kilka chwil.

9f0e51b578fecce5.png

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 nawiązaniu połączenia z Cloud Shell powinno pojawić się potwierdzenie, że użytkownik jest uwierzytelniony, a projekt jest ustawiony na identyfikator Twojego projektu.

  1. Uruchom to polecenie w Cloud Shell, aby potwierdzić, że jesteś uwierzytelniony:
gcloud auth list

Dane wyjściowe polecenia

 Credentialed Accounts
ACTIVE  ACCOUNT
*       <my_account>@<my_domain.com>

To set the active account, run:
    $ gcloud config set account `ACCOUNT`
  1. 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 tak nie jest, możesz go ustawić za pomocą tego polecenia:

gcloud config set project <PROJECT_ID>

Dane wyjściowe polecenia

Updated property [core/project].

3. Włączanie Cloud APIs

W Cloud Shell włącz interfejsy Cloud APIs 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 w gcloud, pojawi się prośba o autoryzację za pomocą danych logowania w celu utworzenia tego żądania. Odbywa się to 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 szablonu

Jako przykładowego projektu systemu CMS Django użyjesz elementu cms-template systemu CMS Django.

Aby utworzyć ten projekt szablonu, w Cloud Shell utwórz nowy katalog 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-3]

Utwórz kopię projektu cms-template:

django-admin startproject --template https://github.com/django-cms/cms-template/archive/3.11.zip myproject .

Będziesz teraz mieć szablon projektu Django CMS w folderze o nazwie myproject:

ls -F
manage.py*  media/  myproject/  project.db  requirements.in requirements.txt  static/ venv/

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

deactivate
rm -rf venv

Z tego miejsca system Django CMS zostanie wywołany w kontenerze.

Możesz też usunąć automatycznie skopiowany plik requirements.in (używany przez pip-tools do generowania plików requirements.txt). Nie zostanie ono użyte w tym ćwiczeniu z programowania:

rm requirements.in

5. Tworzenie usług bazowych

Utworzysz teraz usługi tworzenia kopii zapasowych: dedykowane konto usługi, Artifact Registry, bazę danych Cloud SQL, zasobnik Cloud Storage i pewną liczbę wartości w usłudze Secret Manager.

Ochrona wartości haseł używanych podczas wdrażania jest ważna dla bezpieczeństwa każdego projektu i zapewnia ochronę, aby nikt przypadkowo nie podał haseł tam, gdzie nie należą (na przykład bezpośrednio w plikach ustawień lub wpisywanych bezpośrednio w terminalu, skąd 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 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 przechowywać obraz skompilowanego kontenera, utwórz rejestr kontenerów w wybranym regionie:

gcloud artifacts repositories create containers --repository-format docker --location $REGION

W kolejnych sekcjach tego ćwiczenia z programowania będziesz się odwoływać do tego rejestru:

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 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 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 w Cloud Run), więc 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 na dane:

gsutil cors set cors.json gs://$GS_BUCKET_NAME

Zapisywanie 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 znaków połączenia z bazą danych, zasobnikiem multimediów, tajnym kluczem Django (używanym do kryptograficznego podpisywania sesji i tokenów) i 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

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ę

Ze względu na właśnie utworzone usługi bazowe musisz wprowadzić odpowiednie zmiany w projekcie szablonu.

Obejmie to wprowadzenie w usłudze django-environ używania zmiennych środowiskowych jako ustawień konfiguracji. W jego wyniku zobaczysz wartości zdefiniowane jako obiekty tajne. Aby to zrobić, rozszerz ustawienia szablonu. Musisz też dodać dodatkowe zależności Pythona.

Konfigurowanie ustawień

Przenieś plik settings.py, zmieniając 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 URL to Django security settings
CLOUDRUN_SERVICE_URL
= env("CLOUDRUN_SERVICE_URL", default=None)
if CLOUDRUN_SERVICE_URL:
    ALLOWED_HOSTS
= [urlparse(CLOUDRUN_SERVICE_URL).netloc]
    CSRF_TRUSTED_ORIGINS
= [CLOUDRUN_SERVICE_URL]
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
= []
DEFAULT_FILE_STORAGE
= "storages.backends.gcloud.GoogleCloudStorage"
STATICFILES_STORAGE
= "storages.backends.gcloud.GoogleCloudStorage"
GS_DEFAULT_ACL
= "publicRead"

Poświęć trochę czasu na zapoznanie się z komentarzami na temat poszczególnych konfiguracji.

Zwróć uwagę, że w tym pliku mogą wystąpić błędy lintowania. To normalne. Cloud Shell nie ma kontekstu wymagań dla tego projektu, więc może zgłaszać nieprawidłowe importy i nieużywane importy.

Zależności Pythona

Znajdź plik requirements.txt i dołącz następujące pakiety:

cloudshell edit requirements.txt

requirements.txt (dodatek)

gunicorn
psycopg2-binary
django-storages[google]
django-environ

Definiowanie obrazu aplikacji

Cloud Run będzie uruchamiać dowolny kontener, o ile będzie 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.

Ten samouczek dotyczy dostosowania pliku Procfile używanego 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

Plik protokołu

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 zapełnić zasobnik Cloud Storage zasobami statycznymi, musisz uruchomić migrate i collectstatic.

Te podstawowe polecenia migracji Django należy uruchamiać w kontekście skompilowanego 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 do wykonania tych zadań 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ć superużytkownika, użyj nieinteraktywnej wersji polecenia createsuperuser. To polecenie wymaga użycia zmiennej środowiskowej o specjalnej nazwie zamiast prośby 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, 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 wpisy: domyślny internetowy punkt wejścia, punkt wejścia migrate do stosowania migracji bazy danych i punkt wejścia 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. Są one mapowane na wartości w tabeli 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).

Uruchomisz to polecenie później podczas aktualizowania 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 complete” (ukończono wykonanie).

Nie będzie trzeba uruchamiać tego polecenia ponownie.

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 djangocms-cloudrun \
  --platform managed \
  --region $REGION \
  --image gcr.io/${PROJECT_ID}/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-...-uc.a.run.app

Możesz teraz wyświetlić wdrożony kontener, otwierając ten URL w przeglądarce:

e54d1a1486427431.png

Ponieważ jest to nowa instalacja, nastąpi automatyczne przekierowanie na stronę logowania.

9. Uzyskiwanie dostępu do administratora Django

Jedną z głównych funkcji systemu Django CMS jest jego interaktywny administrator.

Aktualizacja ustawień CSRF

Django zawiera zabezpieczenia przed fałszywymi żądaniami między witrynami (CSRF). Za każdym razem, gdy w Twojej witrynie Django jest przesyłany formularz, w tym podczas logowania się na konto administratora Django, sprawdzane jest ustawienie Zaufane źródła. Jeśli nie pasuje ono do pochodzenia żądania, Django zwraca błąd.

Jeśli w pliku mysite/settings.py jest zdefiniowana 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.

Potrzebujesz adresu URL usługi, więc tę konfigurację możesz dodać dopiero po pierwszym wdrożeniu.

Aby dodać tę zmienną środowiskową, musisz zaktualizować usługę. Można go dodać do obiektu tajnego application_settings lub bezpośrednio jako zmienną środowiskową.

Pobierz adres URL usługi:

CLOUDRUN_SERVICE_URL=$(gcloud run services describe djangocms-cloudrun \
  --platform managed \
  --region $REGION  \
  --format "value(status.url)")
echo $CLOUDRUN_SERVICE_URL

Ustaw tę wartość jako zmienną środowiskową w usłudze Cloud Run:

gcloud run services update djangocms-cloudrun \
  --region $REGION \
  --update-env-vars CLOUDRUN_SERVICE_URL=$CLOUDRUN_SERVICE_URL

Logowanie do konsoli administracyjnej Django

Aby uzyskać dostęp do interfejsu administratora Django, do adresu URL usługi dodaj ciąg /admin.

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 ""

13d77046e2e7427.png

10. Instaluję aktualizacje 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 między komputerem lokalnym a bazą danych.

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

Ewentualnie podczas tworzenia aplikacji możesz użyć lokalnej bazy danych. 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 wskazać 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

Podczas wprowadzania zmian w modelach baz danych może być konieczne wygenerowanie plików migracji Django przez uruchomienie 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:

  • przekształcenie zmian w nowy obraz,
  • zastosuj dowolną migrację baz danych lub migracji statycznej, 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ć migracje, 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 djangocms-cloudrun \
  --platform managed \
  --region $REGION \
  --image gcr.io/${PROJECT_ID}/myimage

11. Gratulacje!

Właśnie udało Ci się wdrożyć złożony projekt w Cloud Run.

  • 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 podczas obsługi żą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 konsoli Cloud 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