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

1. 개요

이 Codelab 시리즈 (자기 주도형 실습 튜토리얼)는 Google App Engine (표준) 개발자가 일련의 이전을 안내하여 앱을 현대화하도록 돕는 것을 목표로 합니다. 이렇게 하면 사용자는 Cloud Run, App Engine 에 대한 Google Cloud의 컨테이너 호스팅 자매 서비스, 기타 컨테이너 호스팅 서비스에 앱을 컨테이너화하여 더 쉽게 이동하도록 할 수 있습니다.

이 튜토리얼에서는 Docker의 대안인 Cloud Buildpack을 사용하여 Cloud Run 완전 관리형 서비스에 배포하기 위해 App Engine 앱을 컨테이너화하는 방법을 설명합니다. Cloud Buildpacks는 Dockerfile 파일을 관리하지 않고도 Docker에 관해 전혀 모르는 상태에서 앱을 컨테이너화합니다.

이 Codelab은 앱을 원래의 기본 제공 서비스에서 다른 곳으로 이동하여 Python 3로 포팅한 Python 2 App Engine 개발자를 대상으로 하며, 현재 컨테이너에서 앱을 실행하려는 개발자를 대상으로 합니다. 이 Codelab은 완료된 모듈 2 또는 모듈 3 Python 3 앱으로 시작합니다.

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

학습 목표

• Cloud 빌드팩을 사용한 앱 컨테이너화
• Cloud Run에 컨테이너 이미지 배포

필요한 사항

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

설문조사

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

<ph type="x-smartling-placeholder"></ph> 읽어보기만 해도 됩니다. 읽고 연습 활동을 완료하세요

2. 배경

App Engine 및 Cloud Functions와 같은 PaaS 시스템은 팀과 애플리케이션에 많은 편의성을 제공합니다. 예를 들어 이러한 서버리스 플랫폼을 통해 SysAdmin/Devops는 솔루션 빌드에 집중할 수 있습니다. 앱은 필요에 따라 자동 확장하고 종량제 결제를 통해 비용을 0으로 축소할 수 있으며 비용을 관리할 수 있으며 다양한 공통 개발 언어를 사용합니다.

하지만 컨테이너의 유연성도 매력적입니다. 어떤 언어, 어떤 라이브러리나 바이너리도 선택할 수 있습니다. 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 소유나 Google의 튜토리얼에서 이 가이드를 시작합니다. 이 Codelab에서는 이전을 단계별로 안내하며, 완료 시점까지는 대부분 모듈 5 FINISH 저장소 폴더에 있는 항목과 일치해야 합니다.

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

START 파일 디렉터리 (사용자 또는 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를 사용하는 방법을 알아보려면 이 모듈을 완료한 후 모듈 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를 만듭니다. 다음과 같은 링크를 방문하면 자동 생성된 service.yaml를 확인할 수 있지만 SVC_NAME 및 REGION 서비스의 경우 https://console.cloud.google.com/run/detail/REGION/SVC_NAME/yaml/view를 대상으로 합니다.

서드 파티 라이브러리

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

서드 파티 구성

빌드팩은 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로 거의 바로 이동할 수 있습니다. 진입점 지시문이 두 플랫폼 간에 사용되는 위치 요약: 아래와 같이 바로 변환됩니다. FYI로 상응하는 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용 Issue Tracker
  • 문제 검색
  • 새로운 문제/의견 제출

마이그레이션 리소스

모듈 2와 3 (START)과 모듈 5 (FINISH)의 저장소 폴더 링크는 아래 표에서 찾을 수 있습니다. 또한 클론 또는 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 Buildpack 출시 후
  • Cloud Buildpacks 배포 후
  • Cloud Buildpacks 저장소
  • CNCF Buildpacks 사양
  • App Engine to Cloud Run 도구 — 자체 service.yaml 생성
• 일반
  • Google Cloud Platform에서 Python 사용
  • Google Cloud Python 클라이언트 라이브러리