모듈 5: Cloud Buildpack을 사용하여 Google App Engine에서 Cloud Run으로 마이그레이션

1. 개요

이 Codelab 시리즈 (사용자 주도형, 실무 가이드)는 Google App Engine (표준) 개발자가 일련의 마이그레이션을 통해 자신의 앱을 현대화할 수 있도록 돕기 위한 것입니다. 이렇게 하면 사용자는 Cloud Run, App Engine 에 대한 Google Cloud의 컨테이너 호스팅 자매 서비스, 기타 컨테이너 호스팅 서비스에 앱을 컨테이너화하여 더 쉽게 이동하도록 할 수 있습니다.

이 튜토리얼에서는 Docker의 대안인 Cloud Buildpacks를 사용하여 Cloud Run 완전 관리형 서비스에 배포할 App Engine 앱을 컨테이너화하는 방법을 알아봅니다. Cloud Buildpacks는 Dockerfile 파일을 관리하거나 Docker에 대해 알지 않아도 앱을 컨테이너화합니다.

이 Codelab은 원래 내장 서비스에서 앱을 이동하고 Python 3로 포팅한 후 이제 컨테이너에서 앱을 실행하려는 Python 2 App Engine 개발자를 위한 것입니다. Codelab은 완성된 모듈 2 또는 모듈 3 Python 3 앱으로 시작합니다.

참고: Cloud Buildpacks는 Python 3.7 이상 (Go 1.10 이상, Node.js 10 이상, Java 8 및 11, .NET Core 3.1 이상 포함)만 지원하므로 Python 2 App Engine 앱은 Cloud Buildpacks를 사용하기 전에 3.x로 포팅해야 합니다. 2.x 앱을 컨테이너화하려면 Docker를 사용해야 합니다. 지금은 이 튜토리얼을 건너뛰고 모듈 4 Codelab: Docker를 사용하여 Google App Engine에서 Cloud Run으로 마이그레이션으로 이동하는 것이 좋습니다.

학습 목표

• Cloud Buildpacks를 사용하여 앱 컨테이너화
• Cloud Run에 컨테이너 이미지 배포

필요한 사항

• 다음을 포함하는 Google Cloud Platform 프로젝트
  • 활성 GCP 결제 계정
  • 사용 설정된 App Engine
• 기본 Python 기술
• 일반적인 Linux 명령어에 대한 실무 지식
• App Engine 앱 개발 및 배포에 대한 기본 지식
• 이 모듈(모듈 5)을 시작하기 전에 모듈 2 또는 모듈 3 Codelab을 완료하고 Python 3으로 포팅하는 것이 좋습니다.
• 컨테이너화할 준비가 된 Python 3 App Engine 앱
  • 모듈 2 Cloud NDB 샘플
  • 모듈 3 Cloud Datastore 샘플

설문조사

이 Codelab을 어떻게 사용할 예정인가요?

읽기만 할 계획입니다. 읽은 다음 연습 활동을 완료할 계획입니다.

2. 배경

App Engine 및 Cloud Functions와 같은 PaaS 시스템은 팀과 애플리케이션에 많은 편의를 제공합니다. 예를 들어 이러한 서버리스 플랫폼을 사용하면 시스템 관리자/DevOps가 솔루션 빌드에 집중할 수 있습니다. 앱은 필요에 따라 자동으로 확장할 수 있고, 사용량 기반 요금 청구를 통해 비용을 관리할 수 있으며, 다양한 일반적인 개발 언어를 사용합니다.

하지만 컨테이너의 유연성도 매력적입니다. 모든 언어, 모든 라이브러리, 모든 바이너리를 선택할 수 있습니다. 사용자에게 서버리스의 편리함과 컨테이너의 유연성을 모두 제공하는 것이 Google Cloud Run의 목표입니다.

Cloud Run 사용 방법을 배우는 것은 Cloud Run 문서에서 다루는 이 Codelab의 범위에 포함되지 않습니다. 여기서 목표는 Cloud Run(또는 기타 서비스)용 App Engine 앱을 컨테이너화하는 방법을 알아보는 것입니다. 계속하기 전에 알아두어야 할 몇 가지 사항이 있는데, 일단 애플리케이션 코드를 가져와 배포하지 않게 되면 사용자 환경이 약간 달라지고 수준이 좀더 낮아집니다.

대신 컨테이너를 빌드하고 배포하는 방법과 같은 컨테이너에 관한 정보를 알아야 합니다. 또한 App Engine의 웹 서버를 더 이상 사용하지 않으므로 웹 서버를 비롯해 컨테이너 이미지에 넣을 항목을 결정할 수 있습니다. 이 경로를 따르지 않으려면 App Engine에서 앱을 유지하는 것도 나쁘지 않습니다.

이 튜토리얼에서는 App Engine 구성 파일을 삭제하고 앱을 시작하는 방법을 비롯하여 웹 서버를 관리하는 등 앱을 컨테이너화하는 방법을 알아봅니다.

이 마이그레이션에는 다음과 같은 단계가 포함됩니다.

1. 설정/사전 작업
2. 애플리케이션 컨테이너화
   • 구성 파일 바꾸기
   • 애플리케이션 파일 수정

3. 설정/사전 작업

이 가이드의 주요 부분을 진행하기 전에 프로젝트를 설정하고 코드를 가져온 후 기본 앱을 배포하여 작동하는 코드로 시작할 수 있도록 준비합니다.

1. 프로젝트 설정

모듈 2 또는 모듈 3 Codelab을 완료했으면 동일 프로젝트(및 코드)를 다시 사용하는 것이 좋습니다. 또는 완전히 새로운 프로젝트를 만들거나 다른 기존 프로젝트를 다시 사용할 수도 있습니다. 프로젝트에 활성 결제 계정이 있고 App Engine(앱)이 사용 설정되어 있는지 확인합니다.

2. 기준 샘플 앱 가져오기

이 Codelab의 기본 요건 중 하나는 작동하는 모듈 2 또는 3 샘플 앱을 준비하는 것입니다. 샘플 앱이 없는 경우에는 계속하기 전에 아래 가이드 (위 링크)를 완료하세요. 가이드 내용을 잘 알고 계시다면 아래 코드 폴더 중 하나를 선택하여 시작하세요.

그 코드가 사용자의 것이든 Google의 것이든 관계없이 이 가이드에서 시작합니다. 이 Codelab에서는 이전 과정을 안내하며, 완료되면 모듈 5 완료 저장소 폴더에 있는 내용과 대부분 일치해야 합니다.

• 시작:
  • Cloud NDB: 모듈 2 코드
  • Cloud Datastore: 모듈 3 코드
• 완료: 모듈 5 코드
• 전체 저장소(클론 또는 ZIP 다운로드)

시작 파일 (사용자 또는 Google의 파일)의 디렉터리는 다음과 같습니다.

$ ls
README.md               main.py                 templates
app.yaml                requirements.txt

3. 기준 앱 (재)배포

이제 남은 사전 작업 실행 단계는 다음과 같습니다.

1. gcloud 명령줄 도구 다시 숙지
2. gcloud app deploy를 사용하여 샘플 앱을 다시 배포합니다.
3. 앱이 문제 없이 App Engine에서 실행되는지 확인합니다.

이러한 단계를 성공적으로 실행하면 컨테이너화할 준비가 된 것입니다.

4. 애플리케이션 컨테이너화

Docker는 오늘날 업계의 표준 컨테이너화 플랫폼입니다. 앞서 언급한 것처럼 이를 사용하는 데 있어 한 가지 문제는 컨테이너 이미지 빌드 방법을 결정하는 구성 파일인 효율적인 Dockerfile를 선별하는 데 노력이 필요하다는 것입니다. 반면 빌드팩은 인트로스펙션을 사용하여 앱의 종속 항목을 확인하므로 앱에 최대한 효율적인 빌드팩 컨테이너를 만들 수 있어 노력이 거의 필요하지 않습니다.

Docker에 대해 알아보는 것을 건너뛰고 Cloud Run 또는 기타 컨테이너 호스팅 플랫폼에서 실행하기 위해 App Engine 앱을 컨테이너화하려는 경우라면 제대로 오셨습니다. 앱 컨테이너화에 Docker를 사용하는 방법을 알아보려면 이 Codelab을 완료한 후 모듈 4 Codelab을 진행하세요. 이 튜토리얼과 동일하지만 Docker를 사용하여 컨테이너 이미지를 관리하는 방법을 자세히 알아봅니다.

마이그레이션 단계에는 App Engine 구성 파일을 바꾸고 앱을 시작하는 방법을 지정하는 작업이 포함됩니다. 아래 표에는 각 플랫폼 유형에 필요한 구성 파일이 요약되어 있습니다. App Engine 열을 빌드팩 열 (선택적으로 Docker)과 비교합니다.

설명	App Engine	Docker	빌드팩
일반 구성	app.yaml	Dockerfile	(service.yaml)
서드 파티 라이브러리	requirements.txt	requirements.txt	requirements.txt
서드 파티 구성	app.yaml(+ appengine_config.py 및 lib[2.x-only])	(해당 없음)	(해당 없음)
시작	(해당 없음) 또는 app.yaml(entrypoint가 사용된 경우)	Dockerfile	Procfile
파일 무시	.gcloudignore, .gitignore	.gcloudignore, .gitignore, .dockerignore	.gcloudignore, .gitignore

앱이 컨테이너화되면 Cloud Run에 배포할 수 있습니다. 기타 Google Cloud 컨테이너 플랫폼 옵션으로는 Compute Engine, GKE, Anthos가 있습니다.

일반 구성

App Engine은 자동으로 애플리케이션을 시작하지만 Cloud Run은 시작하지 않습니다. Procfile는 app.yaml entrypoint 지시어와 유사한 역할을 합니다. 샘플 앱의 경우 Procfile가 python main.py을 실행하여 Flask 개발 서버를 시작합니다. 원하는 경우 gunicorn과 같은 프로덕션 웹 서버를 사용할 수도 있으며, 이 경우 requirements.txt에 추가해야 합니다. 이 Cloud Run 문서 페이지에서 빌드팩을 사용하여 소스 코드에서 배포하는 방법을 자세히 알아보세요.

app.yaml entrypoint 명령어를 Procfile로 이동하기만 하면 됩니다. 없다면 지금은 Flask 개발 서버를 사용하세요. 이는 사용자가 이 이전 작업을 숙지할 수 있도록 하는 샘플 테스트 앱일 뿐입니다. 앱은 개발자가 가장 잘 아는 특정 시작 명령어가 됩니다. 내부적으로 Cloud Run 서비스는 app.yaml과 더 유사한 service.yaml을 만듭니다. 다음과 같은 링크를 방문하여 서비스 SVC_NAME 및 REGION에 대해 자동 생성된 service.yaml를 확인할 수 있습니다. https://console.cloud.google.com/run/detail/REGION/SVC_NAME/yaml/view

서드 파티 라이브러리

requirements.txt 파일은 변경할 필요가 없습니다. Flask가 Datastore 클라이언트 라이브러리 (Cloud Datastore 또는 Cloud NDB)와 함께 있어야 합니다. 이 문서 작성 당시의 현재 버전은 20.0.4이며 Gunicorn과 같은 여타의 WSGI 호환 HTTP 서버를 사용하려는 경우 gunicorn==20.0.4를 requirements.txt에 추가합니다.

서드 파티 구성

Buildpacks는 Python 2를 지원하지 않으므로 여기서는 다루지 않습니다. Cloud Run의 컨테이너에서 실행되는 Python 3 앱은 서드 파티 라이브러리를 requirements.txt에 지정해야 한다는 점에서 Python 3 App Engine 앱과 유사합니다.

시작하기

Python 3 사용자는 app.yaml 파일을 변환하여 handlers 섹션에서 script: auto 지시문 대신 entrypoint를 가져올 수 있습니다. Python 3 app.yaml에서 entrypoint를 사용하는 경우 다음과 같이 표시됩니다.

runtime: python38
entrypoint: python main.py

entrypoint 지시어는 App Engine에 서버를 시작하는 방법을 알려줍니다. 거의 바로 Procfile로 이동할 수 있습니다. 두 플랫폼 간에 진입점 지시어가 배치되는 위치를 요약하면 다음과 같습니다. 아래에 직접 변환되며 참고로 Docker에 상응하는 항목도 표시됩니다.

• Buildpacks: Procfile의 줄: web: python main.py
• Docker: Dockerfile의 줄: ENTRYPOINT ["python", "main.py"]

테스트 및 스테이징의 경우 위에서와 같이 Python에서 Flask의 개발 서버를 실행하기만 하면 되지만, 개발자는 gunicorn를 사용하는 Cloud Run 빠른 시작 샘플과 같은 프로덕션용으로 더 강력한 것을 선택할 수 있습니다.

애플리케이션 파일

모든 모듈 2 또는 모듈 3 앱은 Python 2~3와 완전히 호환되므로 main.py의 핵심 구성요소가 변경되지 않습니다. 다음 몇 줄의 시작 코드만 추가됩니다. Cloud Run에서 앱을 호출할 수 있으려면 포트 8080이 열려 있어야 하므로 개발 서버를 시작할 수 있도록 main.py 하단에 줄 한 쌍을 추가합니다.

if __name__ == '__main__':
    import os
    app.run(debug=True, threaded=True, host='0.0.0.0',
            port=int(os.environ.get('PORT', 8080)))

5. 빌드 및 배포

App Engine 구성이 빌드팩으로 대체되고 소스 파일 업데이트가 완료되었으므로 Cloud Run에서 실행할 준비가 되었습니다. 그 전에 서비스에 대해 간단히 살펴보겠습니다.

서비스와 앱의 차이

App Engine은 애플리케이션을 호스팅하기 위해 만들어졌지만 마이크로서비스 모음으로 구성된 웹 서비스 또는 애플리케이션을 호스팅하는 플랫폼이기도 합니다. Cloud Run에서 모든 것이 실제 서비스이든 또는 웹 인터페이스가 있는 애플리케이션이든 서비스 복제가 아니라 서비스이므로, 애플리케이션이 아니라 서비스 배포로 사용합니다.

App Engine 앱이 여러 서비스로 구성되지 않은 경우 애플리케이션을 배포할 때 이름을 지정할 필요가 없었습니다. Cloud Run에서는 서비스 이름을 지정해야 하므로 이 점이 다릅니다. App Engine의 appspot.com 도메인에는 프로젝트 ID(예: https://PROJECT_ID.appspot.com)와 리전 ID 약어(예: http://PROJECT_ID.REGION_ID.r.appspot.com)가 포함됩니다.

하지만 Cloud Run 서비스의 도메인에는 서비스 이름, 리전 ID 약어, 해시가 포함되지만 프로젝트 ID는 포함되지 않습니다(예: https://SVC_NAME-HASH-REG_ABBR.a.run.app). 결론적으로 서비스 이름을 생각해 보세요.

서비스 배포

아래 명령어를 실행하여 컨테이너 이미지를 빌드하고 Cloud Run에 배포합니다. 메시지가 표시되면 리전을 선택하고 테스트를 더 쉽게 할 수 있도록 인증되지 않은 연결을 허용하고, SVC_NAME이 배포하는 서비스의 이름인 경우 적절한 리전을 선택합니다.

$ gcloud run deploy SVC_NAME --source .
Please choose a target platform:
 [1] Cloud Run (fully managed)
 [2] Cloud Run for Anthos deployed on Google Cloud
 [3] Cloud Run for Anthos deployed on VMware
 [4] cancel
Please enter your numeric choice:  1

To specify the platform yourself, pass `--platform managed`. Or, to make this the default target platform, run `gcloud config set run/platform managed`.

Please specify a region:
 [1] asia-east1
 [2] asia-east2
 [3] asia-northeast1
 [4] asia-northeast2
 [5] asia-northeast3
 [6] asia-south1
 [7] asia-southeast1
 [8] asia-southeast2
 [9] australia-southeast1
 [10] europe-north1
 [11] europe-west1
 [12] europe-west2
 [13] europe-west3
 [14] europe-west4
 [15] europe-west6
 [16] northamerica-northeast1
 [17] southamerica-east1
 [18] us-central1
 [19] us-east1
 [20] us-east4
 [21] us-west1
 [22] us-west2
 [23] us-west3
 [24] us-west4
 [25] cancel
Please enter your numeric choice: <select your numeric region choice>

To make this the default region, run `gcloud config set run/region REGION`.

Allow unauthenticated invocations to [SVC_NAME] (y/N)?  y

Building using Buildpacks and deploying container to Cloud Run service [SVC_NAME] in project [PROJECT_ID] region [REGION]
✓ Building and deploying... Done.
  ✓ Uploading sources...
  ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/BUILD-HASH?project=PROJECT_NUM].
  ✓ Creating Revision...
  ✓ Routing traffic...
Done.
Service [SVC_NAME] revision [SVC_NAME-00014-soc] has been deployed and is serving 100 percent of traffic.
Service URL: https://SVC_NAME-HASH-REG_ABBR.a.run.app

브라우저에서 지정된 URL을 방문하여 배포가 성공적으로 완료되었는지 확인합니다.

gcloud 명령어가 나타내듯이 사용자는 위와 같이 출력과 상호작용을 줄이도록 다양한 기본 설정을 지정할 수 있습니다. 예를 들어 모든 상호작용을 방지하려면 다음 한 줄 배포 명령어를 대신 사용하면 됩니다.

$ gcloud beta run deploy SVC_NAME --source . --platform managed --region REGION --allow-unauthenticated

이 명령을 사용할 경우에는 위에서 설명한 대로 색인 생성 메뉴 선택이 아닌, 동일한 서비스 이름 SVC_NAME 및 원하는 REGION 이름을 선택해야 합니다.

6. 요약/삭제

앱이 App Engine에서와 마찬가지로 Cloud Run에서도 작동하는지 확인합니다. 앞의 Codelab을 수행하지 않고 이 시리즈를 바로 시작한 경우에는 앱 자체가 변경되지 않습니다. 모든 방문을 기본 웹페이지(/)에 등록하고 사이트를 충분히 방문한 후 다음과 같이 표시됩니다.

이제 코드는 모듈 5 저장소 폴더에 있는 것과 일치합니다. 이 모듈 5 Codelab을 완료하셨습니다.

선택사항: 삭제

다음 마이그레이션 Codelab으로 이동할 준비가 될 때까지 비용이 결제되지 않도록 하려면 삭제를 수행해야 합니다. 이제 다른 제품을 사용하므로 Cloud Run 가격 책정 가이드를 검토하세요.

선택사항: 서비스 사용 중지

다음 가이드로 이동할 준비가 되지 않았으면 추가 요금이 발생하지 않도록 서비스를 사용 중지합니다. 다음 Codelab으로 이동할 준비가 되었으면 이를 다시 사용 설정하면 됩니다. 앱이 사용 중지되면 비용을 일으키는 트래픽이 수행되지 않습니다. 하지만 무료 할당량을 초과할 경우 해당 Datastore 사용량에 대한 비용이 결제될 수 있습니다. 따라서 제한에 걸리지 않도록 충분히 삭제해야 합니다.

반면에 마이그레이션을 계속하지 않고 모든 것을 완전히 삭제하려면 서비스를 삭제하거나 프로젝트를 완전히 종료합니다.

다음 단계

축하합니다. 앱을 컨테이너화했습니다. 이 튜토리얼은 여기서 마무리됩니다. 이제 4단계 Codelab (아래 링크)에서 Docker를 사용하여 동일한 작업을 수행하는 방법을 알아보거나 다른 App Engine 마이그레이션을 진행하면 됩니다.

• 모듈 4: Docker를 사용하여 Cloud Run으로 마이그레이션합니다.
  • Docker를 사용하여 Cloud Run에서 실행하기 위해 앱을 컨테이너화합니다.
  • Python 2로 계속 유지합니다.
• 모듈 7: App Engine push 태스크 큐([push] 태스크 큐를 사용하는 경우 필요)
  • App Engine taskqueue push 태스크를 모듈 1 앱에 추가합니다.
  • 모듈 8에서 Cloud Tasks로 마이그레이션하기 위해 사용자를 준비합니다.
• 모듈 3:
  • Cloud NDB에서 Cloud Datastore로 Datastore 액세스 현대화
  • Python 3 App Engine 앱 및 비App Engine 앱에 사용되는 라이브러리입니다.
• 모듈 6: Cloud Firestore로 마이그레이션
  • Cloud Firestore로 마이그레이션하여 Firebase 기능에 액세스
  • Cloud Firestore는 Python 2를 지원하지만 이 Codelab은 Python 3에서만 사용할 수 있습니다.

7. 추가 리소스

App Engine 마이그레이션 모듈 Codelab 문제/의견

이 Codelab에 문제가 발견된 경우 문제를 기록하기 전에 먼저 비슷한 기록이 있는지 검색해보세요. 검색 및 새 문제 만들기 링크:

• App Engine 마이그레이션 Codelab 문제 추적기
  • 문제 검색
  • 새로운 문제/의견 제출

마이그레이션 리소스

모듈 2 및 3 (시작) 및 모듈 5 (완료)의 저장소 폴더 링크는 아래 표에서 찾을 수 있습니다. 또한 클론 또는 ZIP 파일로 다운로드할 수 있는 모든 App Engine Codelab 마이그레이션 저장소에서 액세스할 수도 있습니다.

Codelab	Python 2	Python 3
모듈 2	코드	(코드)
모듈 3	(코드)	코드
모듈 5	(해당 없음)	코드

App Engine 및 Cloud Run 리소스

다음은 이 특정 마이그레이션과 관련된 추가적인 리소스입니다.

• 컨테이너
  • Google Cloud Run
  • Google Cloud Build
  • Google Cloud Container Registry
  • Docker
  • Cloud 빌드팩 출시 게시물
  • Cloud 빌드팩 배포 게시물
  • Cloud 빌드팩 저장소
  • CNCF Buildpacks 사양
  • App Engine to Cloud Run 도구 — 자체 service.yaml 생성
• 일반
  • Google Cloud Platform에서 Python 사용
  • Google Cloud Python 클라이언트 라이브러리