App Engine app.yaml 참조

리전 ID

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

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

확인

app.yaml 파일에서 App Engine 앱의 설정을 구성할 수 있습니다. 이 파일은 URL 경로가 요청 핸들러와 정적 파일에 대응하는 방식을 지정합니다. app.yaml 파일에는 런타임 및 최신 버전 식별자와 같은 앱 코드에 대한 정보도 포함되어 있습니다.

앱의 각 서비스에는 서비스 배포에 필요한 설명어 역할을 하는 고유 app.yaml 파일이 있습니다. 앱 내의 추가 서비스를 위해 app.yaml 파일을 만들고 배포하려면 먼저 default 서비스의 app.yaml 파일을 만들어야 합니다.

디렉터리 구조

앱에서 여러 서비스 구조화에 대한 자세한 내용은 App Engine의 웹 서비스 구조화를 참조하세요.

예

다음은 Python 2 애플리케이션용 app.yaml 파일의 예시입니다.

runtime: python27
api_version: 1
threadsafe: true

handlers:
- url: /
  script: home.app

- url: /index\.html
  script: home.app

- url: /stylesheets
  static_dir: stylesheets

- url: /(.*\.(gif|png|jpg))$
  static_files: static/\1
  upload: static/.*\.(gif|png|jpg)$

- url: /admin/.*
  script: admin.app
  login: admin

- url: /.*
  script: not_found.app

script: 지시문이 .py로 끝나는 파일 경로를 포함하는 경우 스크립트가 CGI를 사용한다는 의미이며, 점으로 구분된 패키지 이름이 있는 Python 모듈 경로를 포함하는 경우 스크립트가 WSGI를 사용한다는 의미입니다.

구문

app.yaml 구문은 YAML 형식입니다.

YAML 형식은 주석을 지원합니다. 우물 정자(#)로 시작하는 줄은 무시됩니다.

# This is a comment.

URL 및 파일 경로 패턴은 콜레이션 요소와 콜레이션 클래스를 제외한 POSIX 확장 정규 표현식 구문을 사용합니다. 그룹화된 일치로의 역참조(예: \1)가 지원되며 Perl 확장명(\w \W \s \S \d \D)도 지원됩니다.

런타임 및 앱 요소

요소	설명
application	경고: appcfg 도구 사용 외에 application 요소는 종료되었습니다. gcloud 명령줄과 같은 Google Cloud CLI 도구를 사용하여 애플리케이션을 지정하려면 다음 안내를 참조하세요. app.yaml 파일에서 application 요소를 삭제하고 대신 명령줄 플래그를 사용하여 애플리케이션 ID를 지정하는 것이 좋습니다. gcloud app deploy 명령어를 사용하려면 --project 플래그를 지정해야 합니다. gcloud app deploy --project [YOUR_PROJECT_ID] 이러한 명령어 사용에 관한 자세한 내용은 앱 배포를 참조하세요. 애플리케이션 ID는 Google Cloud 콘솔에서 애플리케이션을 만들 때 지정한 Google Cloud 콘솔 프로젝트 ID입니다.
api_version	필수. 앱에서 사용하는 특정 런타임 환경의 API 버전입니다. 이 필드는 최신 App Engine 런타임에서 지원 중단되었습니다. Google에서 새로운 버전의 런타임 환경 API 지원이 발표되더라도, 이전에 배포된 앱에는 해당 앱을 작성하는 데 사용된 API 버전이 계속 사용됩니다. 앱을 새로운 API 버전으로 업그레이드하려면 이 값을 변경한 후 앱을 App Engine에 다시 배포해야 합니다. 1 값을 지정하면 앱을 배포할 때마다 지원되는 최신 런타임 환경이 사용됩니다(현재는 ). 현재까지 App Engine의 python27 런타임 환경 버전은 1 하나만 있습니다.
auto_id_policy	선택사항. 항목 식별자를 자동으로 설정하는 경우, 자동 ID 정책을 설정하여 사용되는 방법을 변경할 수 있습니다. 유효한 옵션은 다음과 같습니다. default 기본값. 64비트 부동 소수점으로 표시될 수 있을 만큼 작고 적절하게 분포된 큰 정수인 분산형 자동 ID를 사용합니다. legacy 이전 옵션은 이후 출시 버전에서 지원 중단되고 결국 삭제될 예정입니다. 자세한 내용은 이 변경 사항을 알리는 블로그 게시물을 참조하세요.
builtins	선택사항. Python 2 SDK에는 일반적인 애플리케이션 기능을 위한 여러 핸들러가 내장되어 있습니다. builtins 지시문을 사용하면 app.yaml에 특정 핸들러를 포함할 수 있습니다. 이 필드는 Python 3 런타임에서 지원 중단되었습니다. 사용할 수 있는 내장 핸들러는 다음과 같습니다. appstats /_ah/stats/에서 앱 통계를 사용 설정하며 이를 통해 애플리케이션 성능을 측정할 수 있습니다. 앱 통계를 사용하려면 이벤트 레코더를 설치해야 합니다. deferred /_ah/queue/deferred에서 지연 핸들러를 사용 설정합니다. 이 내장 기능을 통해 개발자는 deferred.defer()를 사용하여 태스크 큐 작업을 간단하게 만들 수 있습니다. remote_api /_ah/remote_api/에서 remote_api 내장 기능을 사용 설정합니다. 이 내장 기능을 사용하면 올바른 사용자 인증 정보가 있는 원격 애플리케이션이 Datastore에 원격으로 액세스할 수 있습니다. 예를 들면 다음과 같습니다. builtins: - deferred: on - appstats: on builtins 지시문은 includes 지시문의 특별 인스턴스입니다. Python에서 각 builtin 지시문은 확장된 경로가 있는 includes 지시문과 같습니다. 예를 들면 다음과 같습니다. builtins: - name: on 위 항목은 다음과 동일합니다. includes: - $PYTHON_LIB/google/appengine/ext/builtins/name/ app.yaml 파일에 builtins를 사용하는 경우 내장된 include.yaml 파일에 정의된 모든 핸들러는 app.yaml 파일에 정의된 핸들러를 대체합니다. 그러나 builtins 또는 includes를 사용하는 파일을 포함하면 핸들러는 include 계층 구조의 순서대로 추가됩니다. 즉, '상위' include의 핸들러는 '하위' include의 내장 기능 이전에 추가되는 식으로 작업이 수행됩니다. 다음과 같이 appstats 내장 핸들러를 사용하는 app.yaml을 예로 들어 보겠습니다. handlers: - url: /.* script: main.app builtins: - appstats: on 핸들러의 결과 목록은 다음과 같습니다. [/_ah/stats, /.*] app.yaml이 includes 지시문을 사용하는 경우: includes: - included.yaml included.yaml 파일이 builtins를 사용하는 경우: handlers: - url: /.* script: main.app builtins: - appstats: on 핸들러의 결과 목록은 다음과 같습니다. [/.*, /_ah/stats] .yaml 파일에서 builtins 절의 배치 순서는 동작과 상관없습니다.
default_expiration	선택사항. 애플리케이션의 모든 정적 파일 핸들러에 대한 전역 기본 캐시 기간을 설정합니다. 또한 특정 정적 파일 핸들러의 캐시 기간을 구성할 수 있습니다. 값은 공백으로 구분된 숫자와 단위 문자열입니다. 단위는 d(일), h(시간), m(분), s(초)일 수 있습니다. 예를 들어 "4d 5h"는 파일이 처음 요청된 후 4일 5시간으로 캐시 만료 시간을 설정합니다. 생략하면 프로덕션 서버가 만료 시간을 10분으로 설정합니다. 예시: runtime: python27 api_version: 1 threadsafe: true default_expiration: "4d 5h" handlers: # ... 자세한 내용은 캐시 만료를 참조하세요.
env_variables	선택사항. app.yaml 파일에서 앱에 제공되도록 환경 변수를 정의할 수 있습니다. 환경 변수의 키가 '[a-zA-Z_][a-zA-Z0-9_]*' 표현식과 일치하는지 확인합니다(알파벳 또는 영숫자 또는 '_'로 이어지는 '_'로 시작). GAE로 시작하는 환경 변수는 시스템용으로 예약되어 있으며 app.yaml 파일에서 허용되지 않습니다. 이러한 변수는 os.environ 사전에서 확인할 수 있습니다. env_variables: DJANGO_SETTINGS_MODULE: "myapp.settings"
error_handlers	선택사항. 다양한 오류 유형에 따라 반환되는 커스텀 오류 페이지를 구성하기 위해 사용됩니다. 이 요소는 다음 요소를 포함할 수 있습니다. error_code 선택사항. error_code는 다음 중 하나일 수 있습니다. over_quota 앱이 리소스 할당량을 초과했음을 나타냅니다. timeout 앱에서 응답하기 전 기한에 도달한 경우에 사용됩니다. error_code는 선택사항입니다. 지정하지 않으면 제공된 파일이 앱의 기본 오류 응답이 됩니다. file 각 파일 항목은 일반 오류 응답을 대신하여 제공해야 하는 정적 파일을 나타냅니다. 해당하는 error_code 요소 없이 file 요소를 지정한 경우, 정적 파일이 앱의 기본 오류 페이지가 됩니다. 경고: 오류 응답 파일의 경로가 정적 파일 핸들러 경로와 겹치지 않는지 확인하세요. 커스텀 오류 데이터는 10KB 미만이어야 합니다. 예시 error_handlers: - file: default_error.html - error_code: over_quota file: over_quota.html
handlers	필수. URL 패턴 목록과 URL 패턴 처리 방법에 대한 설명입니다. App Engine은 애플리케이션 코드를 실행하거나 이미지, CSS 또는 자바스크립트와 같이 코드와 함께 업로드된 정적 파일을 제공하여 URL을 처리할 수 있습니다. 핸들러 및 하위 요소 구문 참조
includes	선택사항. includes 지시문을 사용하면 애플리케이션 전반에서 모든 라이브러리 또는 서비스용 구성 파일을 포함할 수 있습니다. 예를 들어 다음과 같이 사용자 관리 라이브러리를 포함할 수 있습니다. includes: - lib/user_admin.yaml App Engine은 포함된 경로를 다음 순서로 확인합니다. 작업 디렉토리의 절대 경로 또는 상대 경로. 지정된 경로는 파일을 확인합니다. basepath라고도 하는 애플리케이션 디렉터리에 상대되는 경로. 기본 경로와 경로는 파일을 확인합니다. 현재 파일을 포함한 파일에 상대되는 경로. 참조 파일의 위치와 포함 경로는 포함된 파일을 확인합니다. include 지시문이 디렉터리를 지정하면 App Engine이 해당 디렉터리에서 include.yaml이라는 파일을 찾습니다. include 지시문이 파일인 경우, 해당 특정 파일이 포함됩니다. includes를 사용하면 대상 파일(존재할 경우)에서 다음과 같은 지시문 유형만 검색됩니다. builtins includes handlers skip_files skip_files 패턴을 포함하면 포함된 app.yaml의 패턴에 추가되거나 app.yaml에 목록이 명시되어 있지 않은 경우 기본 목록에 추가됩니다. skip_files는 절대 경로를 비교한다는 점에 유의하세요.
inbound_services	선택사항. 인바운드 요청을 수신하려면 먼저 애플리케이션에서 서비스를 사용 설정해야 합니다. app.yaml 파일에 inbound_services 섹션을 포함하여 Python 2 앱에 대한 서비스를 사용 설정합니다. 다음과 같은 인바운드 서비스를 사용할 수 있습니다. mail 애플리케이션이 메일을 수신하도록 허용합니다. warmup 준비 요청을 사용 설정합니다. 준비 요청 구성을 참조하세요. 예시: inbound_services: - mail - warmup
instance_class	선택사항. 이 서비스의 인스턴스 클래스입니다. 서비스의 확장에 따라 다음과 같은 값을 사용할 수 있습니다. 자동 확장 F1, F2, F4, F4_1G 기본값: F1 원하는 경우 automatic_scaling 요소를 사용하여 인스턴스의 최소 및 최대 수, 지연 시간, 동시 연결 수 등 자동 확장의 기본 설정을 변경할 수 있습니다. 참고: instance_class가 F2 이상으로 설정된 경우 max_concurrent_requests를 기본값인 10보다 높게 설정하여 인스턴스를 최적화할 수 있습니다. 최적의 값을 찾으려면 값을 점차적으로 늘리면서 애플리케이션 성능을 모니터링하세요. 기본 및 수동 확장 B1, B2, B4, B4_1G, B8 기본값: B2 기본 및 수동 인스턴스 클래스를 사용하려면 basic_scaling 요소 또는 manual_scaling 요소를 지정해야 합니다.
libraries	선택사항. Python 2.7 런타임에는 서드 파티 라이브러리가 포함되어 있습니다. 이 중 일부는 기본적으로 사용할 수 있으며 그 외에는 구성된 경우에만 사용할 수 있습니다. name 및 version 값을 지정하여 사용할 버전을 지정할 수 있습니다. 이 필드는 Python 3 런타임에서 지원 중단되었습니다. libraries: - name: PIL version: "1.1.7" - name: webob version: "latest" latest를 지정하면 SDK는 배포 시 최신 라이브러리 버전을 결정합니다. 일단 배포되면 라이브러리 버전은 변경되지 않습니다. 다른 버전의 라이브러리를 사용하는 유일한 방법은 다시 배포하는 것입니다. 아직 사용자가 없는 애플리케이션을 개발 중인 경우 새로운 버전을 추적할 필요가 없습니다. 그러나 애플리케이션이 활발히 사용되는 경우 애플리케이션이 이전 버전과 호환되지 않는 새로운 라이브러리 버전을 사용할 수 있으므로 주의하시기 바랍니다. 포함된 서드 파티 라이브러리 목록은 서드 파티 라이브러리를 참조하세요. 로컬 디렉터리에 설치하여 순수 Python 서드 파티 라이브러리를 추가로 사용할 수 있습니다. 가변형 환경을 사용하는 경우 가변형 환경에서 Python 라이브러리 사용하기를 참조하세요.
module	참고: 이제는 모듈을 서비스라고 합니다. gcloud CLI로 앱을 관리하려면 서비스 요소를 대신 사용하세요.
runtime	필수. 앱에서 사용되는 런타임 환경 이름입니다. 예를 들어 Python 2.7을 지정하려면 다음을 사용하세요. runtime: python27
service	서비스의 이전 명칭은 모듈입니다. gcloud CLI 또는 gcloud CLI 기반 플러그인(예: gcloud app deploy)에서만 지원됩니다. 서비스를 만들 경우 필수입니다. default 서비스의 경우에는 선택사항입니다. 각 서비스와 버전에는 이름이 있어야 합니다. 이름에는 숫자, 문자, 하이픈이 포함될 수 있습니다. VERSION-dot-SERVICE-dot-PROJECT_ID의 결합된 길이(VERSION는 버전 이름, SERVICE은 서비스 이름, PROJECT_ID는 프로젝트 ID)는 63자(영문)를 초과할 수 없으며 하이픈으로 시작하거나 끝날 수 없습니다. 각 서비스와 버전에 고유한 이름을 선택합니다. 서비스와 버전 간에 이름을 재사용하지 마세요. 예시: service: service-name 참고: gcloud app deploy 명령어는 이전 버전과 호환되며 모듈로 선언된 서비스가 포함된 기존 app.yaml 파일을 지원합니다. 예를 들면 다음과 같습니다. module: service-name
service_account	선택사항. service_account 요소를 사용하면 사용자 관리 서비스 계정을 버전의 ID로 지정할 수 있습니다. 지정된 서비스 계정은 다른 Google Cloud 서비스에 액세스하고 작업을 실행할 때 사용됩니다. 예시: service_account: [SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com
skip_files	선택사항. skip_files 요소는 애플리케이션 디렉터리에서 App Engine에 업로드하지 않아야 하는 파일을 지정합니다. 이 값은 정규 표현식이거나 정규 표현식의 목록입니다. 정규 표현식과 일치하는 모든 파일 이름은 애플리케이션을 업로드할 때 업로드할 파일의 목록에서 생략됩니다. 파일 이름은 프로젝트 디렉터리를 기준으로 합니다. skip_files의 기본값은 다음과 같습니다. skip_files: - ^(.*/)?#.*#$ - ^(.*/)?.*~$ - ^(.*/)?.*\.py[co]$ - ^(.*/)?.*/RCS/.*$ - ^(.*/)?\..*$ 양식 이름이 #...# 및 ...~인 Emacs 백업 파일, .pyc 및 .pyo 파일, RCS 버전 제어 디렉터리에 있는 파일, 이름이 점(.)으로 시작되는 Unix 숨김 파일은 기본 패턴에서 제외됩니다. 위 정규 표현식 목록을 확장하려면 위 목록을 복사하여 app.yaml에 붙여넣고 사용자 고유의 정규 표현식을 추가합니다. 예를 들어 기본 패턴 외에 이름이 .bak로 끝나는 파일을 건너뛰려면 skip_files에 다음과 같은 항목을 추가합니다. skip_files: - ^(.*/)?#.*#$ - ^(.*/)?.*~$ - ^(.*/)?.*\.py[co]$ - ^(.*/)?.*/RCS/.*$ - ^(.*/)?\..*$ - ^(.*/)?.*\.bak$ 전체 디렉터리를 건너뛰려면 목록에 디렉터리 이름을 추가합니다. 예를 들어 logs라는 이름의 디렉터리를 건너뛰려면 앞에서 설명한 코드에 다음 줄을 추가합니다. skip_files: - logs/
threadsafe	필수. 동시 요청을 사용하도록 애플리케이션을 구성합니다. Python의 스레딩 라이브러리를 사용하는 경우 threading.local()에 의해 반환된 스레드 로컬 데이터는 각 요청 이후 삭제됩니다. 이 필드는 Python 3 런타임에서 지원 중단되었습니다. threadsafe: [true | false] 참고: threadsafe 지시문은 Python 2.7 애플리케이션에 필요합니다. threadsafe: true가 되려면 모든 스크립트 핸들러가 WSGI 핸들러여야 합니다. 즉, 각 스크립트는 점으로 구분된 패키지 이름과 Python 모듈 경로를 사용하여 script: 지시문에 지정되어야 합니다. Python 모듈 경로를 사용하는 script: 지시문의 마지막 구성요소는 service:의 전역 변수 이름으로, 해당 변수는 WSGI 앱이어야 하며 보통 규칙에 따라 app으로 불립니다.
version	app.yaml 파일에서 version 요소를 삭제하고 대신 명령줄 플래그를 사용하여 버전 ID를 지정하는 것이 좋습니다. gcloud app deploy 명령어를 사용하려면 -v 플래그를 지정합니다. gcloud app deploy -v [YOUR_VERSION_ID] 이 명령어 사용에 대한 자세한 내용은 앱 배포를 참조하세요. App Engine에 배포하는 애플리케이션 코드의 버전 식별자입니다. 버전 ID는 소문자, 숫자, 하이픈을 포함할 수 있습니다. 프리픽스 ah-로 시작될 수 없으며 default와 latest라는 이름은 예약되어 있어서 사용할 수 없습니다. 참고: 항상 숫자로 지정되는 숫자 인스턴스와 구분하기 위해, 버전 이름은 문자로 시작되어야 합니다. 이렇게 하면 123-dot-my-service.uc.r.appspot.com과 같이 2가지로 해석될 수 있는 URL의 모호성을 방지할 수 있습니다. 즉, URL에 버전 '123'이 있으면 대상은 제공된 서비스의 버전 '123'이 됩니다. 그리고 버전이 존재하지 않으면 대상은 기본 서비스 버전의 123번 인스턴스가 됩니다. 애플리케이션의 각 버전에는 app.yaml의 고유 복사본이 포함됩니다. 애플리케이션이 업로드될 때는 업로드되는 app.yaml 파일에 언급된 버전이 해당 업로드 작업으로 생성 또는 교체됩니다. 관리자는 Google Cloud 콘솔을 사용하여 트래픽을 처리하는 데 사용되는 애플리케이션 버전을 변경할 수 있으며, 이러한 버전이 트래픽을 수신하도록 구성하기 전에 다른 버전을 테스트할 수도 있습니다.
vpc_access_connector	선택사항. 서버리스 VPC 액세스 커넥터를 사용하도록 애플리케이션을 구성하여 애플리케이션이 VPC 네트워크의 내부 리소스에 요청을 보낼 수 있게 합니다. 자세한 내용은 VPC 네트워크에 연결을 참조하세요. name 문자열 리터럴. 서버리스 VPC 액세스 커넥터의 정규화된 이름을 따옴표로 묶어 지정합니다. "projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME" egress_setting 선택사항입니다. 기본값은 private-ranges-only입니다. egress_setting은 다음 중 하나일 수 있습니다. private-ranges-only 기본값. 내부 IP 주소에 대한 요청은 서버리스 VPC 액세스 커넥터를 거쳐 연결된 VPC 네트워크로 전송됩니다. 외부 IP 주소에 대한 요청은 공개 인터넷으로 전송됩니다. all-traffic 모든 요청은 서버리스 VPC 액세스 커넥터를 거쳐 연결된 VPC 네트워크로 전송됩니다. 예시 vpc_access_connector: name: "projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME" egress_setting: all-traffic

핸들러 요소

handlers 요소는 app.yaml 구성 파일에서 필수 요소입니다. 이 요소는 URL 패턴의 목록과 해당 목록 처리 방법에 대한 설명을 제공합니다. App Engine은 애플리케이션 코드를 실행하거나 이미지, CSS 또는 자바스크립트와 같은 코드와 함께 업로드된 정적 파일을 제공하여 URL을 처리할 수 있습니다.

패턴은 app.yaml 파일에 표시된 순서에 따라 위에서 아래로 평가됩니다. 패턴이 URL과 일치하는 첫 번째 매핑이 요청 처리를 위해 사용됩니다.

다음 표에는 스크립트, 정적 파일, 정적 디렉터리, 기타 설정의 동작을 제어하는 handlers 요소의 하위 요소가 나와 있습니다.

요소	설명
application_readable	선택사항. 부울. 기본적으로 정적 파일 핸들러에 선언된 파일은 정적 데이터로 업로드되며, 최종 사용자에게만 제공됩니다. 애플리케이션은 이러한 파일을 읽을 수 없습니다. 이 필드를 true로 설정할 경우, 애플리케이션이 파일을 읽을 수 있도록 해당 파일이 코드 데이터로도 업로드됩니다. 두 가지 업로드 모두 사용자 코드와 정적 데이터 스토리지 리소스 할당량에 따라 청구됩니다. 이 필드는 최신 App Engine 런타임에서 지원 중단되었습니다.
expiration	선택사항. 이 핸들러에서 제공된 정적 파일을 웹 프록시와 브라우저가 캐시해야 하는 기간입니다. 값은 공백으로 구분된 숫자와 단위 문자열입니다. 단위는 d(일), h(시간), m(분), s(초)일 수 있습니다. 예를 들어 "4d 5h"는 파일이 처음 요청된 후 4일 5시간으로 캐시 만료 시간을 설정합니다. 생략하면 애플리케이션의 default_expiration이 사용됩니다. 자세한 내용은 캐시 만료를 참조하세요.
http_headers	선택사항. 정적 파일 또는 디렉터리 핸들러의 응답에 HTTP 헤더를 설정할 수 있습니다. script 핸들러에서 HTTP 헤더를 설정해야 할 경우, 앱의 코드에서 대신 설정해야 합니다. 캐싱에 영향을 미치는 응답 헤더에 대한 자세한 내용은 정적 콘텐츠 캐싱을 참조하세요. 예시 handlers: - url: /images static_dir: static/images http_headers: X-Foo-Header: foo X-Bar-Header: bar value vary: Accept-Encoding # ... CORS 지원 이 기능의 중요한 용도 하나는 다른 App Engine 앱에서 호스팅되는 파일 액세스와 같이 CORS(원본 간 리소스 공유) 지원입니다. 예를 들어 myassets.uc.r.appspot.com에서 호스팅되는 애셋에 액세스하는 게임 앱 mygame.uc.r.appspot.com이 있다고 가정합니다. 하지만 mygame이 myassets에 JavaScript XMLHttpRequest를 시도하는 경우, myassets 핸들러가 http://mygame.uc.r.appspot.com 값을 포함하는 Access-Control-Allow-Origin: 응답 헤더를 반환하지 않으면 작업이 성공하지 않습니다. 정적 파일 핸들러가 필요한 응답 헤더 값을 반환하도록 만드는 방법은 다음과 같습니다. handlers: - url: /images static_dir: static/images http_headers: Access-Control-Allow-Origin: https://mygame.uc.r.appspot.com # ... 참고: 모든 사람이 애셋에 액세스하도록 허용하려면 https://mygame.uc.r.appspot.com 대신 와일드 카드 '*'를 사용할 수 있습니다.
mime_type	선택사항. 이 값을 지정하면 이 핸들러로 제공되는 모든 파일은 지정된 MIME 유형을 사용하여 제공됩니다. 지정하지 않으면 파일의 MIME 유형이 파일의 파일 이름 확장명에서 파생됩니다. 같은 파일이 여러 확장명으로 업로드되면 확장명은 업로드 수행 순서에 따라 달라질 수 있습니다. 사용 가능한 MIME 미디어 유형에 대한 자세한 내용은 IANA MIME 미디어 유형 웹사이트를 참조하세요.
redirect_http_response_code	선택사항. redirect_http_response_code는 secure 설정과 함께 secure 설정이 구성된 방식에 따라 필요한 리디렉션 수행 시 반환되는 HTTP 응답 코드를 설정하는 데 사용됩니다. redirect_http_response_code 요소에 사용 가능한 값은 다음과 같습니다. 301 응답 코드를 영구적으로 이동했습니다. 302 응답 코드를 찾았습니다. 303 다른 응답 코드를 참조합니다. 307 임시 리디렉션 응답 코드입니다. 예시 handlers: - url: /youraccount/.* script: accounts.app login: required secure: always redirect_http_response_code: 301 사용자 요청이 리디렉션되면 HTTP 상태 코드는 redirect_http_response_code 매개변수 값으로 설정됩니다. 매개변수가 없으면 302가 반환됩니다.
script	선택사항. 애플리케이션 루트 디렉터리에서 스크립트로의 경로를 지정합니다. handlers: # The root URL (/) is handled by the WSGI application named # "app" in home.py. No other URLs match this pattern. - url: / script: home.app # The URL /index.html is also handled by the home.py script. - url: /index\.html script: home.app # A regular expression can map parts of the URL to the # path of the script. - url: /browse/(books|videos|tools) script: \1.catalog.app # All other URLs use the WSGI application named in "app" # in not_found.py. - url: /.* script: not_found.app script: 지시문은 Python 가져오기 경로여야 합니다(예: WSGI 애플리케이션을 가리키는 package.module.app). Python 모듈 경로를 사용하는 script: 지시문의 마지막 구성요소는 모듈의 전역 변수 이름으로, 해당 변수는 WSGI 앱이어야 하며 보통 규칙에 따라 app으로 불립니다. 참고: Python import 문과 마찬가지로 패키지인 각 하위 디렉터리에는 이름이 __init__.py인 파일이 있어야 합니다. 최신 App Engine 런타임에서는 이 필드의 동작이 변경되었습니다.
secure	선택사항. 스크립트 핸들러와 정적 파일 핸들러를 포함한 모든 URL 핸들러는 secure 설정을 사용할 수 있습니다. secure 요소에서 사용할 수 있는 값은 다음과 같습니다. optional URL이 핸들러와 일치하는 HTTP와 HTTPS 요청 모두 리디렉션 없이 성공합니다. 애플리케이션은 요청을 조사하여 사용된 프로토콜을 확인하고 그에 따라 응답할 수 있습니다. 핸들러에 secure가 제공되지 않는 경우, 기본값이 됩니다. never HTTPS를 사용하며 이 핸들러와 일치하는 URL 요청은 HTTP에 해당하는 URL로 자동 리디렉션됩니다. 사용자의 HTTPS 요청이 HTTP 요청으로 리디렉션되는 경우, 요청에서 쿼리 매개변수가 삭제됩니다. 따라서 사용자가 보안 연결용으로 의도된 쿼리 데이터를 잘못해서 비보안 연결을 통해 제출하지 못하도록 방지합니다. always HTTPS를 사용하지 않으며 이 핸들러와 일치하는 URL 요청은 동일한 경로의 HTTPS URL로 자동 리디렉션됩니다. 쿼리 매개변수는 리디렉션을 위해 보존됩니다. 예시 handlers: - url: /youraccount/.* script: accounts.app login: required secure: always 개발용 웹 서버는 HTTPS 연결을 지원하지 않습니다. secure 매개변수가 무시되기 때문에 HTTPS에 사용하도록 의도된 경로를 개발용 웹 서버에 대한 정규 HTTP 연결을 사용하여 테스트할 수 있습니다. REGION_ID.r.appspot.com 도메인을 사용하여 앱의 특정 버전을 타겟팅하려면 일반적으로 URL의 하위 도메인 구성요소를 구분하는 마침표를 '-dot-' 문자열로 바꿉니다. 예를 들면 다음과 같습니다. https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com HTTPS가 있는 커스텀 도메인을 사용하려면 먼저 해당 도메인에 SSL 인증서를 활성화하고 구성해야 합니다. Google 계정 로그인과 로그아웃은 애플리케이션의 URL 구성 방식과 관계없이 항상 보안 연결을 사용하여 수행됩니다.
static_dir	선택사항. 애플리케이션 루트 디렉터리의 정적 파일을 포함하는 디렉터리의 경로입니다. 일치하는 url 패턴 끝 다음에 오는 모든 항목이 static_dir에 추가되어 요청된 파일에 대한 전체 경로를 구성합니다. 디렉터리의 mime_type 설정으로 재정의되지 않는 한 정적 디렉터리의 각 파일은 파일 이름 확장자에 해당하는 MIME 유형을 사용하여 제공됩니다. 제공된 디렉터리의 모든 파일은 정적 파일로 업로드되며 스크립트로 실행될 수 없습니다. 이 디렉터리의 모든 파일은 앱과 함께 정적 파일로 업로드됩니다. App Engine은 앱의 파일과 별도로 정적 파일을 저장하고 제공합니다. 기본적으로 정적 파일은 앱의 파일 시스템에 제공되지 않습니다. 이를 변경하려면 application_readable 옵션을 true로 설정합니다. 예시: handlers: # All URLs beginning with /stylesheets are treated as paths to # static files in the stylesheets/ directory. - url: /stylesheets static_dir: stylesheets # ...
static_files	선택사항. 정적 파일 패턴 핸들러가 URL 패턴을 애플리케이션을 통해 업로드된 정적 파일의 경로와 연결합니다. URL 패턴 정규 표현식은 파일 경로 생성 시 사용할 정규 표현식 그룹을 정의할 수 있습니다. static_dir 대신 이 요소를 사용하면 전체 디렉터리를 매핑하지 않고도 디렉터리 구조의 특정 파일로 매핑할 수 있습니다. 예: handlers: # All URLs ending in .gif .png or .jpg are treated as paths to # static files in the static/ directory. The URL pattern is a # regular expression, with a grouping that is inserted into the # path to the file. - url: /(.*\.(gif|png|jpg))$ static_files: static/\1 upload: static/.*\.(gif|png|jpg)$ # ... App Engine은 애플리케이션 파일과 별도로 정적 파일을 저장하고 제공합니다. 기본적으로 정적 파일은 애플리케이션의 파일 시스템에 제공되지 않습니다. 이를 변경하려면 application_readable 옵션을 true로 설정합니다. 정적 파일은 애플리케이션 코드 파일과 동일할 수 없습니다. 정적 파일 경로가 동적 핸들러에 사용된 스크립트의 경로와 일치할 경우, 해당 스크립트는 해당 동적 핸들러에 제공되지 않습니다.
upload	선택사항. 이 핸들러에서 참조되는 모든 파일의 파일 경로와 일치하는 정규 표현식입니다. 이 정규 표현식이 필요한 이유는 핸들러가 제공된 url과 static_files 패턴에 해당하는 애플리케이션 디렉터리 파일을 확인할 수 없기 때문입니다. 정적 파일은 애플리케이션 파일과 별개로 업로드되고 처리됩니다. 위 예시에 다음 upload 패턴을 사용할 수 있습니다. archives/(.*)/items/(.*)
url	handlers의 경우에는 필수 요소입니다. 정규 표현식으로 표현되는 URL 패턴입니다. 이 표현식은 스크립트의 파일 경로에서 정규 표현식 역참조를 통해 참조할 수 있는 그룹을 포함할 수 있습니다. 예를 들어 /profile/(.*)/(.*)는 URL /profile/edit/manager와 일치하고 edit와 manager를 첫 번째 및 두 번째 그룹으로 사용합니다. 다음 요소와 함께 사용되면 URL 패턴 동작이 일부 달라집니다. static_dir URL 프리픽스를 사용합니다. 정규 표현식 패턴이 static_dir 요소와 함께 사용되면 정규 표현식 패턴에 그룹이 포함될 수 없습니다. 이 프리픽스로 시작하는 모든 URL은 프리픽스 다음의 URL 부분을 파일 경로의 일부로 사용하여 이 핸들러에서 처리됩니다. static_files 정적 파일 패턴 핸들러가 URL 패턴을 애플리케이션을 통해 업로드된 정적 파일 경로와 연결합니다. URL 패턴 정규 표현식은 파일 경로 생성 시 사용할 정규 표현식 그룹을 정의할 수 있습니다. static_dir 대신 이 요소를 사용하면 전체 디렉터리를 매핑하지 않고도 디렉터리 구조의 특정 파일로 매핑할 수 있습니다.

요소 확장

다음 표의 요소는 애플리케이션의 확장 방식을 구성합니다. App Engine 앱 확장 방식에 대한 자세한 내용은 확장 유형을 참조하세요.

요소	설명
automatic_scaling	선택사항. F1 이상의 인스턴스 클래스를 사용하는 애플리케이션에만 적용됩니다. 이 요소를 지정하면 인스턴스 수의 최소 및 최대 수준, 지연 시간, 서비스의 동시 연결 수 설정 등 자동 확장의 기본 설정을 변경할 수 있습니다. 이 요소는 다음 요소를 포함할 수 있습니다. max_instances 선택사항. 0에서 2147483647 사이의 값을 지정합니다. 여기서 0을 지정하면 설정이 중지됩니다. 이 매개변수는 이 모듈 버전에 만들 수 있는 App Engine의 최대 인스턴스 수를 지정합니다. 이는 모듈 비용을 제한하는 데 유용합니다. min_instances 경고: 이 기능이 올바르게 작동하기 위해서는 준비 요청이 사용 설정되었고 애플리케이션이 준비 요청을 처리할 수 있는지 확인해야 합니다. 참고: 이 설정은 이 app.yaml 파일에서 정의한 앱의 버전이 트래픽을 수신하도록 구성된 경우에만 적용됩니다. 트래픽을 다른 앱 버전으로 라우팅하는 방법에 대한 자세한 내용은 트래픽 분할을 참조하세요. (선택 사항) 이 모듈 버전에 대해 만들 수 있는 App Engine의 최소 인스턴스 수입니다. 이러한 인스턴스는 요청이 도착했을 때 트래픽을 처리하고 트래픽 처리를 위해 추가 인스턴스가 시작되었을 때도 계속 트래픽을 처리합니다. 0에서 1,000 사이의 값을 지정합니다. 매개변수를 값 0으로 설정하면 요청이 처리되지 않을 때 비용 절감을 위해 인스턴스를 0개로 조정할 수 있습니다. 트래픽 수신 여부에 관계없이 지정된 인스턴스 수에 따라 비용이 청구됩니다. max_idle_instances 선택사항. 이 버전에 App Engine이 유지해야 하는 최대 유휴 인스턴스 수입니다. 1~1,000 사이의 값을 지정합니다. 지정되지 않은 경우 기본값은 automatic입니다. 즉, App Engine에서 유휴 인스턴스 수를 관리합니다. 다음 사항에 유의하세요. 최댓값이 높으면 부하 수준이 급상승 이후 정상으로 돌아갈 때 유휴 인스턴스 수가 보다 점진적으로 줄어듭니다. 이렇게 하면 요청 부하가 변동되더라도 애플리케이션이 성능을 안정적으로 유지할 수 있지만 높은 부하 기간 중에 유휴 인스턴스 수가 증가하므로 비용도 늘어납니다. 최댓값이 낮으면 실행 비용이 낮아지지만 부하 수준의 변동 폭이 클 때 성능이 저하될 수 있습니다. 참고: 부하 급증 후 정상 수준으로 다시 조정될 때는 유휴 인스턴스 수가 사용자가 지정한 최댓값을 일시적으로 초과할 수 있습니다. 하지만 사용자가 지정한 최대 개수를 초과하는 인스턴스에 대해서는 비용이 청구되지 않습니다. min_idle_instances 경고: 이 기능이 올바르게 작동하기 위해서는 준비 요청이 사용 설정되었고 애플리케이션이 준비 요청을 처리할 수 있는지 확인해야 합니다. 참고: 이 설정은 이 app.yaml 파일에서 정의한 앱의 버전이 트래픽을 수신하도록 구성된 경우에만 적용됩니다. 트래픽을 다른 앱 버전으로 라우팅하는 방법에 대한 자세한 내용은 트래픽 분할을 참조하세요. 선택사항: 이 버전에 대해 실행 상태로 유지되고 트래픽을 처리할 수 있는 추가 인스턴스 수입니다. App Engine은 target_cpu_utilization 및 target_throughput_utilization와 같은 확장 설정을 기반으로 현재 애플리케이션 트래픽을 처리하는 데 필요한 인스턴스 수를 계산합니다. min_idle_instances을 설정하면 이 계산된 숫자 외에 실행할 인스턴스 수가 지정됩니다. 예를 들어 App Engine에서 트래픽 처리를 위해 5개의 인스턴스가 필요하다고 계산하고 min_idle_instances가 2로 설정된 경우 App Engine은 7개의 인스턴스를 실행합니다(트래픽을 기준으로 계산된 5개와 min_idle_instances당 추가 2개를 합산). 트래픽 수신 여부에 관계없이 지정된 인스턴스 수에 따라 비용이 청구됩니다. 다음 사항에 유의하세요. 최솟값이 낮으면 유휴 기간 중에 실행 비용을 낮출 수 있지만 갑작스러운 부하 증가에 대응하기 위해 즉시 사용할 수 있는 인스턴스 수가 부족할 수 있습니다. 최솟값이 높으면 요청 부하가 급증하더라도 애플리케이션을 우선적으로 처리할 수 있습니다. App Engine은 들어오는 요청을 처리하도록 최소한의 인스턴스를 계속 실행합니다. 요청을 처리 중인지 여부에 관계없이 지정된 인스턴스 수에 따라 비용이 청구됩니다. 유휴 인스턴스의 최소 개수를 설정하면, 대기 지연 시간이 애플리케이션 성능에 영향을 덜 줍니다. target_cpu_utilization 선택사항. 0.5에서 0.95 사이의 값을 지정합니다. 기본값은 0.6입니다. 이 매개변수는 트래픽 처리를 위해 새 인스턴스가 시작되는 CPU 사용량 기준점을 지정합니다. 이렇게 하면 성능과 비용 간의 균형을 유지할 수 있습니다. 값을 낮추면 성능과 비용이 높아지고, 값을 높이면 성능이 낮아지지만 비용도 낮아집니다. 예를 들어 값이 0.7이면 CPU 사용량이 70%에 도달한 후 새 인스턴스가 시작됩니다. target_throughput_utilization 선택사항. 0.5에서 0.95 사이의 값을 지정합니다. 기본값은 0.6입니다. 동시 요청으로 인해 새 인스턴스가 시작되는 경우를 지정하기 위해 max_concurrent_requests과 함께 사용됩니다. 동시 요청 수가 max_concurrent_requests와 target_throughput_utilization을 곱한 값에 도달하면 스케줄러는 새 인스턴스를 시작하려고 합니다. max_concurrent_requests 선택사항. 스케줄러가 새 인스턴스를 만들기 전에 자동 확장 인스턴스가 허용할 수 있는 동시 요청 수입니다(기본값: 10, 최댓값: 1000). 동시 요청으로 인해 새 인스턴스가 시작되는 경우를 지정하기 위해 target_throughput_utilization과 함께 사용됩니다. 동시 요청 수가 max_concurrent_requests와 target_throughput_utilization을 곱한 값에 도달하면 스케줄러는 새 인스턴스를 시작하려고 합니다. 단일 스레딩이 필요하지 않으면 max_concurrent_requests를 10보다 작은 값으로 설정하지 않는 것이 좋습니다. 값이 10보다 작으면 threadsafe 앱에 필요한 것보다 더 많은 인스턴스가 생성될 수 있어 불필요한 비용이 발생할 수 있습니다. 이 설정이 너무 높으면 API 지연 시간이 늘어날 수 있습니다. 스케줄러는 실제 최대 요청 수에 도달하기 전에 새 인스턴스를 생성할 수 있습니다. max_pending_latency 대기 지연 시간이 감소되도록 요청 처리를 위해 추가 인스턴스를 시작하기 전에 App Engine이 대기 큐에서 요청에 허용해야 하는 최대 대기 시간입니다. 이 기준점에 도달하면 확장해야 하며, 그 결과 인스턴스 수가 증가합니다. 지정되지 않은 경우 기본값은 automatic입니다. 즉, 새 인스턴스 시작이 트리거되기 전에 요청이 최대 대기 요청 시간 제한인 10초 동안 대기 중인 큐에 남아 있을 수 있습니다. 최댓값이 낮으면 App Engine이 대기 중인 요청에 새 인스턴스를 더 빠르게 시작하므로 성능이 향상되지만 실행 비용도 높아집니다. 최댓값이 높으면 (대기 중인 요청이 있지만 이를 처리하기 위한 유휴 인스턴스가 없는 경우) 요청이 처리될 때까지 사용자가 더 오래 기다려야 할 수 있지만 애플리케이션 실행 비용이 낮아집니다. min_pending_latency App Engine이 요청을 처리할 수 있도록 새로운 인스턴스를 시작하기 전에 대기 큐에서 대기해야 하는 최소 시간을 지정하기 위해 설정할 수 있는 선택적 요소입니다. 값을 지정하면 실행 비용이 낮아지지만 요청 처리를 위해 사용자가 기다려야 하는 시간이 늘어납니다. 무료 앱의 기본값은 500ms이고, 유료 앱의 기본값은 0입니다. 이 요소는 max_pending_latency 요소와 함께 사용되어 App Engine이 새 인스턴스를 생성하는 시점을 결정합니다. 큐에서 대기 중인 요청이 다음과 같으면 다음이 수행됩니다. 지정된 min_pending_latency보다 짧으면 App Engine은 새 인스턴스를 만들지 않습니다. max_pending_latency보다 길면 App Engine은 새 인스턴스 만들기를 시도합니다. min_pending_latency와 max_pending_latency로 지정된 시간 사이이면 App Engine은 기존 인스턴스를 재사용하려고 시도합니다. max_pending_latency 이전에 요청을 처리할 수 있는 인스턴스가 없으면 App Engine은 새 인스턴스를 만듭니다. 예시 automatic_scaling: target_cpu_utilization: 0.65 min_instances: 5 max_instances: 100 min_pending_latency: 30ms max_pending_latency: automatic max_concurrent_requests: 50
basic_scaling	B1 이상의 인스턴스 클래스를 사용하는 애플리케이션은 이 요소 또는 manual_scaling을 지정해야 합니다. 이 요소는 인스턴스 클래스 B1 이상의 기본 확장을 사용 설정하며 다음 요소를 포함할 수 있습니다. max_instances 필수. 이 서비스 버전에 대해 App Engine이 만들 수 있는 최대 인스턴스 수입니다. 이는 서비스 비용을 제한하는 데 유용합니다. idle_timeout 선택사항. 마지막 요청을 받은 후 이 시간이 경과되면 인스턴스가 종료됩니다. 기본값은 5분입니다(5m). 예시 basic_scaling: max_instances: 11 idle_timeout: 10m
manual_scaling	B1 이상의 인스턴스 클래스를 사용하는 애플리케이션은 이 요소 또는 basic_scaling을 지정해야 합니다. 이 요소는 인스턴스 클래스 B1 이상의 수동 확장을 사용 설정하며 다음 요소를 포함할 수 있습니다. instances 시작 시 서비스에 할당할 인스턴스 수입니다. 예를 들면 다음과 같습니다. manual_scaling: instances: 5