Cloud Run의 Django CMS

Cloud Run의 Django CMS

이 Codelab 정보

subject최종 업데이트: 1월 31, 2024
account_circle작성자: Katie McLaughlin

1. 소개

894762ebb681671c.png

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

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

Django CMS는 Django를 기반으로 구축된 엔터프라이즈 콘텐츠 관리 시스템 (CMS)입니다. Django는 고급 Python 웹 프레임워크입니다.

이 가이드에서는 이러한 구성요소를 사용하여 작은 Django CMS 프로젝트를 배포합니다.

참고: 이 Codelab은 Django CMS 3.11.4에서 django-cms/cms-template v3.11을 통해 마지막으로 확인되었습니다.

학습할 내용

  • 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 계정이 없는 경우 계정을 만들어야 합니다.

fbef9caa1602edd0.png

a99b7ace416376c4.png

5e3ff691252acf41.png

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

3c1dabeca90e44e5.png

Cloud Shell을 처음 시작하는 경우 어떤 작업을 수행하는지 설명하는 중간 화면이 표시됩니다. 중간 화면이 표시되면 계속을 클릭합니다.

92662c6a846a5c.png

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

9f0e51b578fecce5.png

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

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

  1. 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`
  1. Cloud Shell에서 다음 명령어를 실행하여 gcloud 명령어가 프로젝트를 알고 있는지 확인합니다.
gcloud config list project

명령어 결과

[core]
project = <PROJECT_ID>

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

gcloud config set project <PROJECT_ID>

명령어 결과

Updated property [core/project].

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. 템플릿 프로젝트 만들기

Django CMS cms-template을 샘플 Django CMS 프로젝트로 사용합니다.

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

mkdir ~/djangocms-cloudrun
cd ~/djangocms-cloudrun

django-cms 패키지를 임시 가상 환경에 설치합니다.

virtualenv venv
source venv/bin/activate
pip install djangocms-frontend\[cms-3]

cms-template 프로젝트의 사본을 만듭니다.

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

이제 myproject 폴더에 템플릿 Django CMS 프로젝트가 있습니다.

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

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

deactivate
rm -rf venv

이제 Django CMS가 컨테이너 내에서 호출됩니다.

자동으로 복사된 requirements.in 파일 (pip-tools에서 requirements.txt 파일을 생성하는 데 사용하는 파일)을 삭제할 수도 있습니다. 이 Codelab에서는 사용되지 않습니다.

rm requirements.in

5. 지원 서비스 만들기

이제 전용 서비스 계정, Artifact Registry, Cloud SQL 데이터베이스, Cloud Storage 버킷, 여러 Secret Manager 값으로 지원 서비스를 만듭니다.

배포 시 사용되는 비밀번호의 값을 보호하는 것은 모든 프로젝트의 보안에 중요하며, 아무도 실수로 비밀번호가 속하지 않은 곳에 비밀번호를 저장하지 않도록 합니다 (예: 설정 파일에 직접 입력하거나 기록에서 검색할 수 있는 터미널에 직접 입력).

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

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

리전당 하나:

REGION=us-central1

서비스 계정 만들기

서비스가 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 또는 텍스트 문자열로 저장, 관리, 액세스할 수 있습니다. 런타임 시 애플리케이션에 필요한 데이터베이스 비밀번호, 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. 애플리케이션 구성

방금 만든 지원 서비스를 고려할 때 이에 맞게 템플릿 프로젝트를 일부 변경해야 합니다.

여기에는 구성 설정으로 환경 변수를 사용하는 django-environ를 도입하는 것이 포함되며, 이 구성에는 보안 비밀로 정의된 값이 시드됩니다. 이를 구현하려면 템플릿 설정을 확장합니다. Python 종속 항목도 추가해야 합니다.

설정 구성하기

settings.py 파일을 이동하고 이름을 basesettings.py:로 바꿉니다.

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

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

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

Python 종속 항목

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

cloudshell edit requirements.txt

requirements.txt (추가)

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

애플리케이션 이미지 정의

Cloud Run은 Cloud Run 컨테이너 계약을 준수하는 한 모든 컨테이너를 실행합니다. 이 튜토리얼에서는 Dockerfile를 생략하는 대신 Cloud Native Buildpack을 사용합니다. 빌드팩은 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 버킷을 정적 애셋으로 채우려면 migratecollectstatic를 실행해야 합니다.

이러한 기본 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 noop@example.com --noinput

이제 세 가지 항목이 표시됩니다. 기본 웹 진입점, 데이터베이스 마이그레이션을 적용할 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 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

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

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

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

e54d1a1486427431.png

신규 설치이므로 로그인 페이지로 자동 리디렉션됩니다.

9. Django Admin 액세스

Django CMS의 주요 기능 중 하나는 대화형 관리입니다.

CSRF 설정 업데이트 중

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

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

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

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

서비스 URL을 가져옵니다.

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

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

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

Django 관리자에 로그인

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

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

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

13d77046e2e7427.png

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

11. 축하합니다.

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

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

정리

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

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

자세히 알아보기