Cloud Run의 Wagtail

1. 소개

Cloud Run은 HTTP 요청으로 호출 가능한 스테이트리스(Stateless) 컨테이너를 실행하는 관리형 컴퓨팅 플랫폼입니다. Cloud Run은 서버리스이므로 인프라 관리가 필요 없습니다. 따라서 개발자가 본연의 업무인 애플리케이션 개발에 집중할 수 있습니다.

또한 관리형 데이터베이스를 위한 Cloud SQL, 통합 객체 스토리지를 위한 Cloud Storage, 보안 비밀을 관리하기 위한 Secret Manager를 비롯하여 Google Cloud 생태계의 다른 여러 부분과도 기본적으로 상호작용합니다.

Wagtail은 Django를 기반으로 구축된 오픈소스 콘텐츠 관리 시스템 (CMS)입니다. Django는 고급 Python 웹 프레임워크입니다.

이 튜토리얼에서는 이러한 구성요소를 사용하여 작은 Wagtail 프로젝트를 배포합니다.

참고: 이 Codelab은 Django 5를 지원하는 Wagtail 5.2.2로 마지막으로 확인되었습니다.

학습할 내용

• Cloud Shell 사용 방법
• Cloud SQL 데이터베이스를 만드는 방법
• Cloud Storage 버킷을 만드는 방법
• Secret Manager 보안 비밀을 만드는 방법
• 다른 Google Cloud 서비스의 비밀을 사용하는 방법
• Google Cloud 구성요소를 Cloud Run 서비스에 연결하는 방법
• Container Registry를 사용하여 빌드된 컨테이너를 저장하는 방법
• Cloud Run에 배포하는 방법
• Cloud Build에서 데이터베이스 스키마 마이그레이션을 실행하는 방법

2. 설정 및 요건

자습형 환경 설정

1. Google Cloud Console에 로그인하여 새 프로젝트를 만들거나 기존 프로젝트를 재사용합니다. 아직 Gmail이나 Google Workspace 계정이 없는 경우 계정을 만들어야 합니다.

• 프로젝트 이름은 이 프로젝트 참가자의 표시 이름입니다. 이는 Google API에서 사용하지 않는 문자열이며 언제든지 업데이트할 수 있습니다.
• 프로젝트 ID는 모든 Google Cloud 프로젝트에서 고유하며, 변경할 수 없습니다(설정된 후에는 변경할 수 없음). Cloud 콘솔은 고유한 문자열을 자동으로 생성합니다. 일반적으로는 신경 쓰지 않아도 됩니다. 대부분의 Codelab에서는 프로젝트 ID (일반적으로 PROJECT_ID로 식별됨)를 참조해야 합니다. 생성된 ID가 마음에 들지 않으면 다른 임의 ID를 생성할 수 있습니다. 또는 직접 시도해 보고 사용 가능한지 확인할 수도 있습니다. 이 단계 이후에는 변경할 수 없으며 프로젝트 기간 동안 유지됩니다.
• 참고로 세 번째 값은 일부 API에서 사용하는 프로젝트 번호입니다. 이 세 가지 값에 대한 자세한 내용은 문서를 참고하세요.

주의: 프로젝트 ID는 전역적으로 고유하며 선택한 후에는 다른 사람이 사용할 수 없습니다. 해당 ID의 유일한 사용자입니다. 프로젝트가 삭제되더라도 ID는 다시 사용할 수 없습니다.

참고: Gmail 계정을 사용하는 경우 기본 위치를 조직 없음으로 설정된 그대로 둘 수 있습니다. Google Workspace 계정을 사용하는 경우 조직에 적합한 위치를 선택하세요.

2. 다음으로 Cloud 리소스/API를 사용하려면 Cloud 콘솔에서 결제를 사용 설정해야 합니다. 이 Codelab 실행에는 많은 비용이 들지 않습니다. 이 튜토리얼이 끝난 후에 요금이 청구되지 않도록 리소스를 종료하려면 만든 리소스 또는 프로젝트를 삭제하면 됩니다. Google Cloud 신규 사용자는 300달러(USD) 상당의 무료 체험판 프로그램에 참여할 수 있습니다.

Google Cloud Shell

Google Cloud를 노트북에서 원격으로 실행할 수도 있지만 이 Codelab에서는 Cloud에서 실행되는 명령줄 환경인 Google Cloud Shell을 사용합니다.

Cloud Shell 활성화

1. Cloud Console에서 Cloud Shell 활성화를 클릭합니다.

Cloud Shell을 처음 시작하는 경우 Cloud Shell에 대한 설명이 포함된 중간 화면이 표시됩니다. 중간 화면이 표시되면 계속을 클릭합니다.

Cloud Shell을 프로비저닝하고 연결하는 데 몇 분 정도만 걸립니다.

이 가상 머신에는 필요한 모든 개발 도구가 로드되어 있습니다. 영구적인 5GB 홈 디렉터리를 제공하고 Google Cloud에서 실행되므로 네트워크 성능과 인증이 크게 개선됩니다. 이 Codelab에서 대부분의 작업은 브라우저만으로도 수행할 수 있습니다.

Cloud Shell에 연결되면 인증이 완료되었고 프로젝트가 자신의 프로젝트 ID로 설정된 것을 확인할 수 있습니다.

2. Cloud Shell에서 다음 명령어를 실행하여 인증되었는지 확인합니다.

gcloud auth list

명령어 결과

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

To set the active account, run:
    $ gcloud config set account `ACCOUNT`

참고: gcloud 명령줄 도구는 Google Cloud의 강력한 통합 명령줄 도구입니다. 이 도구는 Cloud Shell에 사전 설치되어 있습니다. 탭 완성 기능이 지원되는 것을 확인할 수 있습니다. 명령어를 처음 실행할 때 인증하라는 메시지가 표시될 수 있습니다. 자세한 내용은 gcloud 명령줄 도구 개요를 참조하세요.

3. Cloud Shell에서 다음 명령어를 실행하여 gcloud 명령어가 프로젝트를 알고 있는지 확인합니다.

gcloud config list project

명령어 결과

[core]
project = <PROJECT_ID>

또는 다음 명령어로 설정할 수 있습니다.

gcloud config set project <PROJECT_ID>

명령어 결과

Updated property [core/project].

참고: Cloud Shell 외부에서 이 튜토리얼을 완료하는 경우 애플리케이션 기본 사용자 인증 정보 설정을 따르세요.

3. Cloud API 사용 설정

Cloud Shell에서 사용될 구성요소의 Cloud API를 사용 설정합니다.

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

gcloud에서 API를 처음 호출하는 것이므로 이 요청을 수행하기 위해 사용자 인증 정보를 사용하여 승인하라는 메시지가 표시됩니다. 이는 Cloud Shell 세션당 한 번씩 발생합니다.

이 작업을 완료하는 데 몇 분 정도 걸릴 수 있습니다.

완료되면 다음과 유사한 성공 메시지가 표시됩니다.

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

4. 템플릿 프로젝트 만들기

기본 Wagtail 프로젝트 템플릿을 샘플 Wagtail 프로젝트로 사용합니다. 이를 위해 Wagtail을 임시로 설치하여 템플릿을 생성합니다.

이 템플릿 프로젝트를 만들려면 Cloud Shell을 사용하여 wagtail-cloudrun이라는 새 디렉터리를 만들고 해당 디렉터리로 이동합니다.

mkdir ~/wagtail-cloudrun
cd ~/wagtail-cloudrun

그런 다음 임시 가상 환경에 Wagtail을 설치합니다.

virtualenv venv
source venv/bin/activate
pip install wagtail

그런 다음 현재 폴더에 새 템플릿 프로젝트를 만듭니다.

wagtail start myproject .

이제 현재 폴더에 템플릿 Wagtail 프로젝트가 생성됩니다.

ls -F

Dockerfile  home/  manage.py*  myproject/  requirements.txt  search/ venv/

이제 임시 가상 환경을 종료하고 삭제할 수 있습니다.

deactivate
rm -rf venv

이제 컨테이너 내에서 Wagtail이 호출됩니다.

5. 지원 서비스 만들기

이제 백엔드 서비스(전용 서비스 계정, 아티팩트 저장소, Cloud SQL 데이터베이스, Cloud Storage 버킷, 여러 Secret Manager 값)를 만듭니다.

배포에 사용되는 비밀번호 값을 보호하는 것은 프로젝트 보안과 관련하여 중요하며, 아무도 실수로 비밀번호를 잘못된 위치(예: 설정 파일에 직접 입력하거나 기록에서 검색할 수 있는 터미널에 직접 입력)에 입력하지 않도록 합니다.

시작하려면 프로젝트 ID에 하나씩, 총 두 개의 기본 환경 변수를 설정합니다.

PROJECT_ID=$(gcloud config get-value core/project)

그리고 지역별로 하나씩 있습니다.

REGION=us-central1

인프라를 사용할 때는 구성요소가 서로 더 효율적으로 통신할 수 있도록 모든 구성요소를 동일한 위치에 두는 것이 좋습니다. 일부 구성요소는 전 세계에서 사용할 수 있지만 모든 구성요소가 모든 지역에서 제공되는 것은 아닙니다.

이 Codelab에서는 us-central1, europe-north1 또는 asia-northeast1를 사용하는 것이 좋습니다. Cloud Run (완전 관리형)이 지원되는 모든 리전을 지원합니다.

자세히 알아보기:

• Cloud Run (완전 관리형) 위치
• Cloud SQL 위치
• Cloud Storage 위치

서비스 계정 만들기

서비스가 Google Cloud의 다른 부분에 액세스하는 것을 제한하려면 전용 서비스 계정을 만드세요.

gcloud iam service-accounts create cloudrun-serviceaccount

이 Codelab의 향후 섹션에서 이 계정을 이메일로 참조합니다. 환경 변수에 이 값을 설정합니다.

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

Artifact Registry 만들기

빌드된 컨테이너 이미지를 저장하려면 선택한 리전에 Container Registry를 만듭니다.

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

이 Codelab의 이후 섹션에서는 이름으로 이 레지스트리를 참조합니다.

ARTIFACT_REGISTRY=${REGION}-docker.pkg.dev/${PROJECT_ID}/containers

데이터베이스 만들기

Cloud SQL 인스턴스를 만듭니다.

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

이 작업을 완료하는 데 몇 분 정도 걸릴 수 있습니다.

해당 인스턴스에서 데이터베이스를 만듭니다.

gcloud sql databases create mydatabase --instance myinstance

동일한 경우에 사용자를 만듭니다.

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

서비스 계정에 인스턴스에 연결할 수 있는 권한을 부여합니다.

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member serviceAccount:${SERVICE_ACCOUNT} \
    --role roles/cloudsql.client

스토리지 버킷 만들기

Cloud Storage 버킷을 만듭니다(이름은 전 세계적으로 고유해야 함).

GS_BUCKET_NAME=${PROJECT_ID}-media
gcloud storage buckets create gs://${GS_BUCKET_NAME} --location ${REGION} 

서비스 계정에 버킷을 관리할 수 있는 권한을 부여합니다.

gcloud storage buckets add-iam-policy-binding gs://${GS_BUCKET_NAME} \
    --member serviceAccount:${SERVICE_ACCOUNT} \
    --role roles/storage.admin

버킷에 저장된 객체의 출처가 다르므로(Cloud Run URL이 아닌 버킷 URL) 교차 출처 리소스 공유(CORS) 설정을 구성해야 합니다.

다음 콘텐츠로 cors.json라는 새 파일을 만듭니다.

touch cors.json
cloudshell edit cors.json

cors.json

[
    {
      "origin": ["*"],
      "responseHeader": ["Content-Type"],
      "method": ["GET"],
      "maxAgeSeconds": 3600
    }
]

새로 만든 스토리지 버킷에 이 CORS 구성을 적용합니다.

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

구성 저장(보안 비밀로)

백업 서비스를 설정했으므로 이제 Secret Manager를 사용하여 보호되는 파일에 이러한 값을 저장합니다.

Secret Manager를 사용하면 보안 비밀을 바이너리 blob 또는 텍스트 문자열로 저장, 관리, 액세스할 수 있습니다. Secret Manager는 런타임 시 애플리케이션에 필요한 데이터베이스 비밀번호, API 키 또는 TLS 인증서와 같은 구성 정보를 저장하는 데 적합합니다.

먼저 데이터베이스 연결 문자열 값, 미디어 버킷, Django 보안 비밀 키 (세션 및 토큰의 암호화 서명에 사용)로 파일을 만들고 디버깅을 사용 설정합니다.

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

그런 다음 이 파일을 보안 비밀로 사용하여 application_settings라는 보안 비밀을 만듭니다.

gcloud secrets create application_settings --data-file .env

서비스 계정이 이 보안 비밀에 액세스하도록 허용합니다.

gcloud secrets add-iam-policy-binding application_settings \
  --member serviceAccount:${SERVICE_ACCOUNT} --role roles/secretmanager.secretAccessor

보안 비밀을 나열하여 보안 비밀이 생성되었는지 확인합니다.

gcloud secrets versions list application_settings

보안 비밀이 생성되었는지 확인한 후 로컬 파일을 삭제합니다.

rm .env

6. 애플리케이션 구성

이전에 만든 템플릿 프로젝트를 이제 몇 가지 수정해야 합니다. 이러한 변경사항을 통해 Wagtail과 함께 제공되는 템플릿 설정 구성의 복잡성이 줄어들고 Wagtail이 이전에 만든 지원 서비스와 통합됩니다.

설정 구성

생성된 base.py 설정 파일을 찾아 기본 myproject 폴더에서 이름을 basesettings.py로 바꿉니다.

mv myproject/settings/base.py myproject/basesettings.py

Cloud Shell 웹 편집기를 사용하여 다음 코드로 새 settings.py 파일을 만듭니다.

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

시간을 내어 각 구성에 대해 추가된 설명을 읽어보세요.

이 파일에서 린팅 오류가 표시될 수 있습니다. 이는 정상적인 동작입니다. Cloud Shell에는 이 프로젝트의 요구사항 컨텍스트가 없으므로 잘못된 가져오기 및 사용되지 않은 가져오기가 보고될 수 있습니다.

그런 다음 이전 설정 폴더를 삭제합니다.

rm -rf myproject/settings/

그러면 Wagtail의 설정 파일과 방금 만든 설정 파일 2개가 생성됩니다.

ls myproject/*settings*

myproject/basesettings.py  myproject/settings.py

마지막으로 manage.py 설정 파일을 열고 Wagtail이 기본 settings.py 파일을 가리키도록 구성을 업데이트합니다.

cloudshell edit manage.py

management.py 줄 (앞)

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings.dev")

manage.py 줄 (뒤)

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings")

myproject/wsgi.py 파일에서도 동일한 구성을 변경합니다.

cloudshell edit myproject/wsgi.py

myproject/wsgi.py 줄(이전)

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings.dev")

myproject/wsgi.py 줄(이후)

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings")

자동으로 생성된 Dockerfile을 삭제합니다.

rm Dockerfile

Python 종속 항목

requirements.txt 파일을 찾아 다음 패키지를 추가합니다.

cloudshell edit requirements.txt

requirements.txt(추가)

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

애플리케이션 이미지 정의하기

Cloud Run은 Cloud Run 컨테이너 계약을 준수하는 한 모든 컨테이너를 실행합니다. 이 튜토리얼에서는 Dockerfile를 생략하고 대신 클라우드 네이티브 빌드팩을 사용합니다. 빌드팩은 Python을 비롯한 일반적인 언어의 컨테이너 빌드를 지원합니다.

이 튜토리얼에서는 웹 애플리케이션을 시작하는 데 사용되는 Procfile을 맞춤설정하도록 선택합니다.

템플릿 프로젝트를 컨테이너화하려면 먼저 프로젝트의 최상위 수준 (manage.py와 동일한 디렉터리)에 Procfile라는 새 파일을 만들고 다음 콘텐츠를 복사합니다.

touch Procfile
cloudshell edit Procfile

Procfile

web: gunicorn --bind 0.0.0.0:$PORT --workers 1 --threads 8 --timeout 0 myproject.wsgi:application

7. 이전 단계 구성, 빌드, 실행

Cloud SQL 데이터베이스에 데이터베이스 스키마를 만들고 Cloud Storage 버킷을 정적 애셋으로 채우려면 migrate 및 collectstatic를 실행해야 합니다.

이러한 기본 Django 마이그레이션 명령어는 데이터베이스에 대한 액세스 권한이 있는 빌드된 컨테이너 이미지의 컨텍스트 내에서 실행해야 합니다.

또한 createsuperuser를 실행하여 Django 관리자에 로그인하려면 관리자 계정을 만들어야 합니다.

이를 위해 Cloud Run 작업을 사용하여 이러한 작업을 실행합니다. Cloud Run 작업을 사용하면 종료가 정의된 프로세스를 실행할 수 있으므로 관리 작업에 적합합니다.

Django 수퍼유저 비밀번호 정의

슈퍼 사용자를 만들려면 대화형 버전이 아닌 createsuperuser 명령어를 사용합니다. 이 명령어를 사용하려면 비밀번호를 입력하라는 메시지 대신 사용할 특수한 이름의 환경 변수가 필요합니다.

무작위로 생성된 비밀번호를 사용하여 새 보안 비밀을 만듭니다.

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

서비스 계정이 이 보안 비밀에 액세스하도록 허용합니다.

gcloud secrets add-iam-policy-binding django_superuser_password \
  --member serviceAccount:${SERVICE_ACCOUNT} \
  --role roles/secretmanager.secretAccessor

Procfile 업데이트하기

Cloud Run 작업의 명확성을 위해 Procfile에서 바로가기를 만들고 다음 진입점을 Procfile에 추가합니다.

migrate: python manage.py migrate && python manage.py collectstatic --noinput --clear
createuser: python manage.py createsuperuser --username admin --email [e-mail] --noinput

이제 세 개의 항목이 있습니다. 기본 web 진입점, 데이터베이스 마이그레이션을 적용할 migrate 진입점, createsuperuser 명령어를 실행할 createuser 진입점입니다.

애플리케이션 이미지 빌드

Procfile을 업데이트했으면 이미지를 빌드합니다.

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

Cloud Run 작업 만들기

이제 이미지가 있으므로 이를 사용하여 Cloud Run 작업을 만들 수 있습니다.

이러한 작업은 이전에 빌드된 이미지를 사용하지만 다른 command 값을 사용합니다. 이는 Procfile의 값에 매핑됩니다.

마이그레이션을 위한 작업을 만듭니다.

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

사용자 생성을 위한 작업을 만듭니다.

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

Cloud Run 작업 실행

작업 구성이 준비되면 마이그레이션을 실행합니다.

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

명령어 출력에 실행이 '완료됨'이라고 표시되는지 확인합니다.

나중에 애플리케이션을 업데이트할 때 이 명령어를 실행합니다.

데이터베이스 설정을 통해 작업을 사용하여 사용자를 만듭니다.

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

명령어 출력에 실행이 '완료됨'이라고 표시되는지 확인합니다.

이 명령어를 다시 실행하지 않아도 됩니다.

8. Cloud Run에 배포

지원 서비스가 생성되고 채워지면 이제 Cloud Run 서비스를 만들어 이러한 서비스에 액세스할 수 있습니다.

Cloud Run에 컨테이너화된 애플리케이션의 초기 배포는 다음 명령어를 사용하여 생성됩니다.

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

그런 다음 배포가 완료될 때까지 잠시 기다립니다. 성공하면 명령줄에 다음과 같은 서비스 URL이 표시됩니다.

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

이제 웹브라우저에서 다음 URL을 열어 배포된 컨테이너로 이동할 수 있습니다.

9. Django 관리자 액세스

CSRF 설정 업데이트

Django 4.0에서 변경됨: 이제 CSRF Origin 헤더 확인이 적용됩니다. Django 문서를 참고하세요.

Django에는 교차 사이트 요청 위조 (CSRF)에 대한 보호 기능이 포함되어 있습니다. Django 관리자 로그인을 포함하여 Django 사이트에서 양식이 제출될 때마다 신뢰할 수 있는 출처 설정이 확인됩니다. 요청의 출처와 일치하지 않으면 Django에서 오류를 반환합니다.

mysite/settings.py 파일에서 CLOUDRUN_SERVICE_URL 환경 변수가 정의되면 CSRF_TRUSTED_ORIGINS 및 ALLOWED_HOSTS 설정에서 사용됩니다. ALLOWED_HOSTS는 필수는 아니지만 CSRF_TRUSTED_ORIGINS에 이미 필요하므로 추가하는 것이 좋습니다.

서비스 URL이 필요하므로 첫 번째 배포가 완료되기 전에는 이 구성을 추가할 수 없습니다.

이 환경 변수를 추가하려면 서비스를 업데이트해야 합니다. application_settings 보안 비밀에 추가하거나 환경 변수로 직접 추가할 수 있습니다.

아래 구현은 gcloud 형식 지정 및 escaping를 활용합니다.

서비스 URL을 가져옵니다.

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

이 값을 Cloud Run 서비스의 환경 변수로 설정합니다.

gcloud run services update wagtail-cloudrun \
  --region $REGION \
  --update-env-vars "^##^CLOUDRUN_SERVICE_URLS=$CLOUDRUN_SERVICE_URLS"

Django 관리자에 로그인

Django 관리 인터페이스에 액세스하려면 서비스 URL에 /admin를 추가합니다.

이제 사용자 이름 'admin'으로 로그인합니다. 로 이동하고 다음 명령어를 사용하여 비밀번호를 검색합니다.

gcloud secrets versions access latest --secret django_superuser_password && echo ""

10. 애플리케이션 개발

애플리케이션을 개발할 때는 로컬에서 테스트하는 것이 좋습니다. 이렇게 하려면 Cloud SQL('프로덕션') 데이터베이스 또는 로컬('테스트') 데이터베이스에 연결해야 합니다.

프로덕션 데이터베이스에 연결

Cloud SQL 인증 프록시를 사용하여 Cloud SQL 인스턴스에 연결할 수 있습니다. 이 애플리케이션은 로컬 머신에서 데이터베이스로 연결을 생성합니다.

Cloud SQL 인증 프록시를 설치한 후 다음 단계를 따르세요.

# 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

작업을 완료한 후에는 temp_settings 파일을 삭제해야 합니다.

로컬 SQLite 데이터베이스에 연결

또는 애플리케이션을 개발할 때 로컬 데이터베이스를 사용할 수 있습니다. Django는 PostgreSQL과 SQLite 데이터베이스를 모두 지원하며, PostgreSQL에는 SQLite에는 없는 기능이 있지만, 대부분의 경우 기능은 동일합니다.

SQLite를 설정하려면 애플리케이션 설정을 업데이트하여 로컬 데이터베이스를 가리켜야 합니다. 그런 다음 스키마 이전을 적용해야 합니다.

이 방법을 설정하려면 다음 단계를 따르세요.

# 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

작업을 완료한 후에는 temp_settings 파일을 삭제해야 합니다.

마이그레이션 만들기

데이터베이스 모델을 변경할 때 python manage.py makemigrations를 실행하여 Django의 마이그레이션 파일을 생성해야 할 수도 있습니다.

프로덕션 또는 테스트 데이터베이스 연결을 설정한 후 이 명령어를 실행할 수 있습니다. 또는 빈 설정을 지정하여 데이터베이스 없이 이전 파일을 생성할 수도 있습니다.

SECRET_KEY="" DATABASE_URL="" GS_BUCKET_NAME="" python manage.py makemigrations

애플리케이션 업데이트 적용

신청서에 변경사항을 적용하려면 다음을 수행해야 합니다.

• 변경사항을 새 이미지에 빌드하고
• 데이터베이스 또는 정적 마이그레이션을 적용한 다음
• 새 이미지를 사용하도록 Cloud Run 서비스를 업데이트합니다.

이미지를 빌드하려면 다음 안내를 따르세요.

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

적용할 이전이 있는 경우 Cloud Run 작업을 실행합니다.

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

새 이미지로 서비스를 업데이트하려면 다음 안내를 따르세요.

gcloud run services update wagtail-cloudrun \
  --region $REGION \
  --image ${ARTIFACT_REGISTRY}/myimage

11. 축하합니다.

복잡한 프로젝트를 Cloud Run에 배포했습니다.

• Cloud Run은 수신된 요청을 처리하기 위해 컨테이너 이미지를 자동 및 수평 확장한 다음 수요가 감소하면 축소합니다. 요청 처리 도중 소비한 CPU, 메모리, 네트워킹에 대해서만 비용을 지불하면 됩니다.
• Cloud SQL을 사용하면 자동으로 유지관리되고 여러 Google Cloud 시스템에 기본적으로 통합되는 관리형 PostgreSQL 인스턴스를 프로비저닝할 수 있습니다.
• Cloud Storage를 사용하면 Django에서 원활하게 액세스할 수 있는 방식으로 클라우드 스토리지를 사용할 수 있습니다.
• Secret Manager를 사용하면 보안 비밀을 저장하고 Google Cloud의 특정 부분에서만 액세스할 수 있도록 할 수 있습니다.

이 짧은 실습은 gcloud 명령줄을 사용하여 완료되었지만, Cloud Run은 Cloud 콘솔 ( console.cloud.google.com)을 통해 사용할 수 있습니다. Compute(으)로 이동하기만 하면 됩니다. Cloud Run를 클릭하면 서비스가 나열되는 것을 확인할 수 있습니다.

정리

이 튜토리얼에서 사용한 리소스 비용이 Google Cloud Platform 계정에 청구되지 않도록 하는 방법은 다음과 같습니다.

• Cloud 콘솔에서 리소스 관리 페이지로 이동합니다.
• 프로젝트 목록에서 해당 프로젝트를 선택한 후 삭제를 클릭합니다.
• 대화상자에서 프로젝트 ID를 입력한 후 종료를 클릭하여 프로젝트를 삭제합니다.

자세히 알아보기

• Cloud Run에서 사용하는 Django: https://cloud.google.com/python/django/run
• Python을 사용한 Cloud Run Hello: https://codelabs.developers.google.com/codelabs/cloud-run-hello-python3
• Google Cloud 기반 Python: https://cloud.google.com/python
• Google Cloud Python 클라이언트: https://github.com/googleapis/google-cloud-python

/