애플리케이션 테스트 및 배포

리전 ID

REGION_ID는 앱을 만들 때 선택한 리전을 기준으로 Google에서 할당하는 축약된 코드입니다. 일부 리전 ID는 일반적으로 사용되는 국가 및 주/도 코드와 비슷하게 표시될 수 있지만 코드는 국가 또는 주/도와 일치하지 않습니다. 2020년 2월 이후에 생성된 앱의 경우 REGION_ID.r이 App Engine URL에 포함됩니다. 이 날짜 이전에 만든 기존 앱의 경우 URL에서 리전 ID는 선택사항입니다.

리전 ID에 대해 자세히 알아보세요.

애플리케이션을 로컬에서 실행 및 배포하고 App Engine에서 테스트하는 방법을 알아봅니다.

로컬에서 실행

배포 전에 애플리케이션을 테스트하려면 일반적으로 사용하는 개발 도구를 사용하여 로컬 환경에서 애플리케이션을 실행합니다. Google Cloud SDK와 함께 제공되는 로컬 개발 서버인 dev_appserver에 의지하기보다 단위 테스트와 통합 테스트를 실행하는 pytest, 격리된 환경을 만들기 위한 virtualenv 등 표준 Python 도구를 사용하는 것이 좋습니다.

예를 들어 일반적으로 다음 명령어를 사용하여 Flask 개발 서버로 Flask 애플리케이션을 실행할 수 있습니다.

python main.py

다음 명령어를 사용하여 Django 애플리케이션을 시작합니다.

python manage.py runserver

프로덕션 App Engine 환경을 시뮬레이션하려면 완전한 웹 서버 게이트웨이 인터페이스(WSGI) 서버를 로컬에서 실행합니다. app.yaml 파일에서 진입점으로 지정된 것과 동일한 명령어를 사용합니다. 예를 들면 다음과 같습니다.

gunicorn -b :$PORT main:app

애플리케이션을 배포하기 전에

애플리케이션을 배포하기 전에 다음을 확인하세요.

Google Cloud 프로젝트의 소유자가 App Engine용 Google Cloud 프로젝트를 설정해야 합니다.
사용자 계정에 필요한 권한이 있는지 확인합니다.

애플리케이션 배포

gcloud app deploy 명령어를 사용하여 애플리케이션을 App Engine에 배포합니다. 배포 중에 Cloud Build 서비스가 표준 환경에서 실행할 애플리케이션의 컨테이너 이미지를 빌드합니다. 각 빌드는 Google Cloud 프로젝트와 동일한 리전에서 실행됩니다. 자세한 내용은 빌드 이미지 관리를 참조하세요.

앱을 프로그래매틱 방식으로 배포하려면 Admin API를 사용합니다.

서비스 배포

애플리케이션의 서비스 버전과 각 구성 파일을 배포하여 App Engine에 애플리케이션을 배포합니다.

애플리케이션의 서비스 버전을 배포하려면 서비스의 app.yaml 파일이 있는 디렉터리에서 다음 명령어를 실행합니다.

gcloud app deploy

명령어로 파일을 지정하지 않으면 현재 디렉터리의 app.yaml 파일만 배포됩니다. 기본적으로 deploy 명령어는 개발자가 배포하는 버전에 대해 고유 ID를 생성하고 개발자가 사용하도록 Google Cloud CL를 구성한 Google Cloud 프로젝트에 버전을 배포하고, 모든 트래픽을 새 버전으로 라우팅합니다.

특정 파일을 타겟팅하거나 추가 매개변수를 포함하여 명령어의 기본 동작을 변경할 수 있습니다.

서비스의 다른 구성 파일을 배포하려면 각 파일을 별도로 대상을 지정하고 배포해야 합니다. 예를 들면 다음과 같습니다.
```
gcloud app deploy cron.yaml
gcloud app deploy dispatch.yaml
gcloud app deploy index.yaml
```
커스텀 버전 ID를 지정하려면 --version 플래그를 사용합니다.
트래픽이 자동으로 새 버전으로 라우팅되지 않게 하려면 --no-promote 플래그를 사용합니다.
특정 Google Cloud 프로젝트에 배포하려면 --project 플래그를 사용합니다.

예를 들어 app.yaml 파일에서 정의된 서비스를 특정 Google Cloud 프로젝트에 배포하려면 커스텀 버전 ID를 할당하고 트래픽이 새 버전으로 라우팅되지 않도록 합니다.

gcloud app deploy --project PROJECT_ID --version VERSION_ID --no-promote

이 명령어에 대한 자세한 내용은 gcloud app deploy 참조를 확인하세요.

여러 서비스 배포

동일한 배포 명령어를 사용하여 애플리케이션을 구성하는 여러 서비스를 배포 또는 업데이트할 수 있습니다.

시작하기 전에 다음 사항을 확인하세요.

후속 서비스를 만들고 배포하려면 먼저 애플리케이션 버전을 default 서비스에 배포해야 합니다.
각 서비스의 ID를 해당 app.yaml 구성 파일에 지정해야 합니다. 서비스 ID를 지정하려면 각 구성 파일에 service 요소 정의를 포함합니다. 기본적으로 구성 파일에서 이 요소 정의를 제외하면 해당 버전이 default 서비스에 배포됩니다.

여러 서비스를 배포하려면 각 서비스의 app.yaml 파일을 별도로 배포합니다. 단일 gcloud app deploy 명령어로 여러 파일을 지정할 수 있습니다.

gcloud app deploy service1/app.yaml service2/app.yaml

빌드 로그 보기

Cloud Build는 Google Cloud 콘솔의 Cloud Build 기록 섹션에서 볼 수 있는 빌드 로그와 배포 로그를 스트리밍합니다. 앱 리전의 빌드를 보려면 리전 메뉴를 사용하여 리전별로 필터링합니다.

빌드 이미지 관리

새 버전을 배포할 때마다 다음이 수행됩니다.

App Engine은 Cloud Build 서비스를 사용하여 컨테이너 이미지를 만듭니다.
Cloud Build는 앱의 리전에 컨테이너 이미지를 빌드하고 App Engine 표준 환경에서 실행됩니다.
App Engine은 빌드된 컨테이너 이미지를 Artifact Registry에 저장합니다. 이러한 이미지를 다운로드하여 다른 위치에서 실행하거나 보관할 수 있습니다.

배포가 완료된 후에는 App Engine에서 더 이상 컨테이너 이미지가 필요하지 않습니다. 컨테이너 이미지는 자동으로 삭제되지 않습니다. 저장용량 할당량에 도달하지 않도록 하려면 필요 없는 이미지를 삭제하면 됩니다. 나중에 이미지가 필요할 수 있거나 이미지 사본을 보관하려는 경우에는 삭제하기 전에 사본을 내보내야 합니다. Artifact Registry에서 이미지를 관리하는 방법에 대한 자세한 내용은 이미지 관리를 참조하세요.

파일 무시

서비스를 배포할 때 .gcloudignore 파일을 사용하여 App Engine에 업로드되지 않는 파일과 디렉터리를 지정할 수 있습니다. 이 작업은 배포를 통해 업로드하지 않아도 되는 빌드 아티팩트와 기타 파일을 무시하는 경우에 유용합니다.

애플리케이션 보기

애플리케이션을 App Engine에 배포한 후 다음 명령어를 실행하면 브라우저를 시작하고 https://PROJECT_ID.REGION_ID.r.appspot.com에서 애플리케이션을 볼 수 있습니다.

gcloud app browse

트래픽 이동 전에 App Engine에서 테스트

새 버전에서 트래픽을 수신하도록 구성하기 전에 App Engine에서 버전을 테스트할 수 있습니다. 예를 들어 default 서비스의 새 버전을 테스트하려면 다음 안내를 따르세요.

새 버전을 배포하되 트래픽이 새 버전으로 자동 라우팅되지 않도록 합니다.
```
gcloud app deploy --no-promote
```
다음 URL로 이동하여 새 버전에 액세스합니다.

https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com

참고: Google Cloud 콘솔에서 버전 ID를 찾거나 --version flag 플래그를 사용하여 배포할 때 ID를 지정할 수 있습니다. Google Cloud CLI는 배포할 때 버전 ID도 출력합니다.

이제 App Engine 런타임 환경에서 새 버전을 테스트할 수 있습니다. 로그를 확인하여 애플리케이션을 디버깅할 수 있습니다. 자세한 내용은 애플리케이션 로그 작성을 참조하세요.

App Engine은 https://PROJECT_ID.REGION_ID.r.appspot.com으로 전송된 요청을 이전에 트래픽을 수신하도록 구성된 버전으로 라우팅합니다.
트래픽을 새 버전으로 전송하려면 Google Cloud 콘솔을 사용하여 트래픽을 마이그레이션합니다.

버전 관리하기

방금 배포한 버전을 선택하고 트래픽 마이그레이션을 클릭합니다.

URL의 default를 서비스 이름으로 바꾸면 동일한 프로세스를 사용하여 다른 서비스의 새 버전을 테스트할 수 있습니다.

https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com

특정 서비스와 버전 타겟팅에 대한 자세한 내용은 요청이 라우팅되는 방식을 참조하세요.

빌드 환경 변수 사용

빌드팩을 지원하는 런타임용 빌드 환경 변수를 설정할 수 있습니다.

빌드 환경 변수는 앱 배포를 위해 사용하는 빌드팩을 구성하기 위해 지정할 수 있는 키-값 쌍입니다. 예를 들어 컴플라이어 옵션을 지정해야 할 수 있습니다.

시작하기 전에 다음 사항을 확인하세요.

키는 대문자 ASCII 문자로 시작해야 하며 대문자 ASCII 문자, 숫자, 밑줄만 포함할 수 있습니다.
GOOGLE_* 키 프리픽스를 사용하여 변수를 만들지 않아야 합니다.
Google에서 사용하도록 예약된 키는 다음과 같습니다.
- GOOGLE_RUNTIME
- GOOGLE_RUNTIME_VERSION
- GOOGLE_ENTRYPOINT
- GOOGLE_DEVMODE
빌드팩에서 지원되는 모든 키를 사용할 수 있습니다.

빌드팩에 환경 변수를 사용하려면 app.yaml 파일에서 build_env_variables 필드를 지정합니다.

빌드팩에 대해 여기서 자세히 알아보세요.

로컬 개발 서버 사용

Google Cloud CLI에는 프로덕션 App Engine에서 실행되는 애플리케이션을 시뮬레이션하도록 로컬에서 실행할 수 있는 dev_appserver라는 로컬 개발 서버가 포함되어 있습니다. 이 개발 서버는 애플리케이션을 실행하는 환경을 부분적으로 시뮬레이션하므로 표준 환경 런타임용으로 작성된 앱을 테스트할 수 있습니다.

로컬 개발 서버 실행

앱의 app.yaml 구성 파일을 만든 후 dev_appserver.py 명령어로 로컬 개발 서버를 시작하여 앱을 로컬에서 실행할 수 있습니다.

사용자 계정의 액세스 사용자 인증 정보를 얻으려면 다음을 실행합니다.
```
gcloud auth login
```
API 액세스를 위해 로컬 애플리케이션이 사용자 인증 정보를 일시적으로 사용하도록 허용합니다.
```
gcloud auth application-default login
```
로컬 개발 서버를 시작하려면 다음 안내를 따르세요.

app.yaml 구성 파일이 포함된 디렉터리에서 dev_appserver.py 명령어를 실행하고 프로젝트 ID와 app.yaml 파일의 경로를 지정합니다.
```
python3 CLOUD_SDK_ROOT/bin/dev_appserver.py --application=PROJECT_ID app.yaml
```
포트를 변경하려면 --port 옵션을 포함합니다.
```
python3 CLOUD_SDK_ROOT/bin/dev_appserver.py --application=PROJECT_ID app.yaml --port=9999
```
Python 3 앱을 테스트하고 Python 3 인터프리터를 사용하여 dev_appserver.py를 실행하려면 --runtime_python_path 플래그에 Python 3 바이너리를 지정해야 합니다. 예를 들면 다음과 같습니다.
```
python3 CLOUD_SDK_ROOT/bin/dev_appserver.py --runtime_python_path=/usr/bin/python3 --application=PROJECT_ID app.yaml --port=9999
```
dev_appserver.py 명령어 옵션에 대한 자세한 내용은 로컬 개발 서버 옵션을 참조하세요.
로컬 개발 서버가 시작되면 requirements.txt 파일에서 발견한 종속 항목을 미리 설치하는 개발 환경을 설정합니다.
이제 로컬 개발 서버가 실행되고 요청을 리스닝합니다. 웹브라우저에서 http://localhost:8080/에 방문하여 앱 동작을 확인합니다.

--port 옵션으로 커스텀 포트를 지정한 경우 이 포트로 브라우저를 열어야 합니다.
명령줄에서 로컬 서버를 중지하려면 키보드에서 Control-C를 누릅니다.

애플리케이션 런타임 환경 감지

코드가 프로덕션과 로컬 개발 서버 중 어디에서 실행 중인지 확인하려면 GAE_ENV 환경 변수를 확인합니다.

if os.getenv('GAE_ENV', '').startswith('standard'):
  # Production in the standard environment
else:
  # Local execution.

Google Cloud 서비스에서 로컬 개발 서버 사용

dev_appserver를 다른 Google Cloud 구성 요소와 통합할 수 있습니다.

Cloud 클라이언트 라이브러리

많은 Google Cloud 클라이언트 라이브러리에는 GOOGLE_CLOUD_PROJECT 환경 변수가 필요하며 이 환경 변수는 Google Cloud 프로젝트 ID여야 합니다. gcloud config list project 명령어를 실행하거나 Google Cloud 콘솔의 프로젝트 페이지에서 값을 확인할 수 있습니다.

로컬 개발 도중 이 환경 변수가 올바르게 설정되었는지 확인하려면 위 예시처럼 --application=PROJECT_ID 매개변수를 사용하여 dev_appserver를 초기화합니다.

Cloud 에뮬레이터

Cloud Datastore, Cloud Bigtable, Cloud Pub/Sub용 에뮬레이터로 애플리케이션을 테스트할 수 있습니다.

`requirements.txt` 및 `app.yaml` 변경사항 자동 새로고침

로컬 개발 서버는 requirements.txt 파일에 있는 종속 항목을 자동으로 설치합니다. dev_appserver 또한 app.yaml을 통해 구성된 기능을 테스트 할 수 있습니다. 예를 들어 앱의 정적 파일 제공 기능을 테스트할 수 있습니다. dev_appserver가 실행 중일 때 requirements.txt 및 app.yaml에 변경사항이 발생하면 이러한 변경사항이 적용되도록 앱이 자동으로 다시 시작됩니다. 이 경우 종속 항목 다운로드 및 설치로 인해 일시적으로 지연이 발생할 수 있습니다.

개발 서버의 인스턴스 관리 및 라우팅

인스턴스 주소 검색

로컬 개발 서버는 시작 시 모든 수동 확장 인스턴스를 만듭니다. 자동 및 기본 확장 서비스의 인스턴스는 동적으로 관리됩니다. 서버는 포트를 각 서비스에 할당하고, 클라이언트는 서버에 따라 부하 분산을 수행하고 인스턴스를 자동으로 선택할 수 있습니다. 각 서비스 주소를 지정하는 포트 할당은 서버의 로그 메시지 스트림에 나타납니다.

다음은 세 가지 서비스를 정의하는 앱용 포트입니다.

INFO Starting module "default" running at: http://localhost:8084
INFO Starting module "service1" running at: http://localhost:8082
INFO Starting module "service2" running at: http://localhost:8083

예를 들어 서비스 주소 http://localhost:8082/를 사용하는 경우 서버는 서비스의 인스턴스를 만들거나 선택하고 해당 인스턴스에 요청을 보냅니다.

서버는 서비스의 각 인스턴스에 고유한 포트를 할당합니다. 관리 서버를 사용하여 이러한 포트를 검색할 수 있습니다. 관리 서버에는 고유한 포트가 있으며 메시지 로그에 나타납니다.

INFO Starting admin server at: http://localhost:8000

이 주소를 통해 관리 서버 콘솔로 이동합니다. 인스턴스를 클릭하여 앱 인스턴스의 동적 상태를 확인합니다.

각 수동 인스턴스와 기본 인스턴스에 대해 별도의 항목이 나타납니다. 인스턴스 번호는 각 인스턴스에 고유한 포트 주소가 있는 링크입니다. 해당 인스턴스로 직접 요청을 보내려면 링크를 클릭하세요.

디스패치 파일

앱에 dispatch.yaml 파일이 포함되어 있으면 로그 메시지 스트림에 디스패처 포트가 포함됩니다.

INFO Starting dispatcher running at: http://localhost:8080

이 포트에 대한 요청은 디스패치 파일의 규칙에 따라 라우팅됩니다. 서버는 호스트 이름이 포함된 dispatch.yaml 파일(예: url: "customer1.myapp.com/*")을 지원하지 않습니다. 상대 경로 패턴이 있는 규칙(url: "*/fun")은 작동합니다. 따라서 http://localhost/fun/mobile과 같은 URL을 사용하여 인스턴스에 연결할 수 있습니다. 호스트 기반 규칙이 포함된 dispatch.yaml 파일로 애플리케이션을 실행하려고 시도하면 서버가 로그 스트림에 오류를 보고합니다.

Cloud Trace 사용

Cloud Trace는 요청이 애플리케이션을 통해 전파되는 방식을 이해하는 데 유용합니다. 단일 요청의 상세 지연 시간 정보를 조사하거나 애플리케이션 전반의 지연 시간 합계를 확인할 수 있습니다.

Cloud Trace에서 trace 세부정보를 보려면 trace 찾기 및 탐색을 따르면 됩니다. Trace 탐색기에서 필터를 사용하여 특정 App Engine 서비스 및 버전을 기준으로 필터링할 수 있습니다.