app.yaml 구성 파일

app.yaml 파일은 일반적인 앱, 네트워크, 기타 리소스 설정뿐만 아니라 자바 런타임의 구성 설정을 정의합니다. 자세한 내용과 예제는 런타임 설정 정의를 참조하세요.

구문

app.yaml 파일의 구문은 YAML 형식입니다. YAML 형식은 해시태그(#) 문자로 시작하는 모든 줄이 무시되는 주석을 지원합니다. 예를 들면 다음과 같습니다.

# This is a comment.

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

일반 설정

app.yaml 파일에는 이러한 일반 설정이 포함될 수 있습니다. 일부 설정은 필수입니다.

이름설명
runtime: java 이 설정은 필수입니다. 이 애플리케이션에서 사용하는 App Engine 언어 런타임의 이름입니다. 자바를 지정하려면 java를 사용하세요.

다른 런타임도 사용할 수 있습니다. 자세한 내용은 각 언어의 문서를 참조하세요.

env: flex 가변형 환경을 선택합니다.
service: service_name 서비스를 만들 경우 필수 항목입니다. 기본 서비스의 경우 선택 항목입니다. 각 서비스와 버전에는 이름이 있어야 합니다. 이름에는 숫자, 문자, 하이픈이 포함될 수 있습니다. 이름이 63자보다 더 길면 안 되고 하이픈으로 시작하거나 끝나면 안 됩니다. 각 서비스와 버전에 고유한 이름을 선택합니다. 서비스와 버전 간에 이름을 재사용하지 마세요.

참고: 이전에는 서비스를 '모듈'이라고 했습니다.

skip_files

선택사항입니다. skip_files 요소는 애플리케이션 디렉토리 내의 어떤 파일이 App Engine에 업로드되지 않을지 지정합니다. 이 값은 정규 표현식이거나 정규 표현식의 목록입니다. 정규 표현식과 일치하는 파일 이름은 애플리케이션이 업로드될 때 업로드할 파일 목록에서 생략됩니다.

예를 들어 이름이 .bak로 끝나는 파일을 건너뛰려면 다음과 같이 skip_files 섹션을 추가합니다.


skip_files:
- ^(.*/)?\.bak$
App Engine 가변형 환경은 자바 8 기반의 여러 자바 런타임을 지원합니다.

  • Eclipse Jetty 9 런타임은 자바 8 기반이며 서블릿 3.1을 사용하는 Jetty 9을 실행합니다.
  • 자바 8 런타임을 사용하면 포트 8080에서 수신하는 자체 서버 코드를 애플리케이션의 일부로 제공할 수 있습니다. 이 기능을 사용하면 Spark 자바Spring Boot 등의 마이크로 서비스 프레임워크를 사용할 수 있습니다.

Jetty 9을 선택하려면 다음을 입력하세요(기본값/선택사항).

runtime_config:
   jdk: openjdk8
   server: jetty9

자바 8을 선택하려면 다음을 입력하세요.

runtime_config:
   jdk: openjdk8

네트워크 설정

app.yaml 구성 파일에 네트워크 설정을 지정할 수 있습니다. 예를 들면 다음과 같습니다.

network:
  instance_tag: TAG_NAME
  name: NETWORK_NAME
  subnetwork_name: SUBNETWORK_NAME
  forwarded_ports:
    - PORT
    - HOST_PORT:CONTAINER_PORT
    - PORT/tcp
    - HOST_PORT:CONTAINER_PORT/udp

네트워크 설정을 구성할 때 다음 옵션을 사용할 수 있습니다.

옵션 설명
instance_tag 인스턴스가 만들어질 때 서비스의 각 인스턴스에 해당 이름이 할당되는 태그입니다. 태그는 인스턴스 그룹에 작업을 타겟팅하는 gcloud 명령어에서 유용합니다. compute firewalls-create 명령어에 --source-tags--target-tags 플래그를 사용하는 경우를 예로 들 수 있습니다.
name 가변형 환경의 모든 VM 인스턴스는 인스턴스가 만들어질 때 Google Compute Engine 네트워크에 할당됩니다. 네트워크 이름을 지정할 때 이 설정을 사용합니다. 리소스 경로가 아닌 짧은 이름을 지정합니다(예: https://www.googleapis.com/compute/v1/projects/my-project/global/networks/default 대신 default). 네트워크 이름을 지정하지 않으면 인스턴스가 프로젝트의 기본 네트워크(이름 default)에 할당됩니다. 하위 네트워크 이름을 지정하려면 네트워크 이름을 지정해야 합니다.
subnetwork_name 선택사항입니다. 네트워크를 분류하고 커스텀 하위 네트워크를 사용할 수 있습니다. 네트워크 name을 지정해야 합니다. 리소스 경로가 아닌 짧은 이름을 지정합니다(예: https://www.googleapis.com/compute/v1/projects/my-project/global/networks/default/subnetworks/default 대신 default). 하위 네트워크는 애플리케이션과 동일한 지역에 있어야 합니다.
forwarded_ports 선택사항입니다. 포트를 인스턴스(HOST_PORT)에서 Docker 컨테이너(CONTAINER_PORT)로 전달할 수 있습니다. PORT만 지정할 경우, App Engine은 해당 포트가 호스트와 컨테이너에 있는 포트와 동일하다고 가정합니다. 기본적으로 TCP 트래픽과 UDP 트래픽이 모두 전달됩니다. 트래픽은 appspot.com 도메인이나 커스텀 도메인을 통해서가 아니라 대상 인스턴스의 IP 주소로 직접 전송되어야 합니다.

고급 네트워크 구성

Compute Engine 네트워크를 여러 개의 하위 네트워크로 분류할 수 있습니다. 이렇게 하면 기업 네트워크 내의 데이터베이스에 액세스하는 등의 VPN 시나리오를 사용 설정할 수 있습니다.

App Engine 애플리케이션에 하위 네트워크를 사용 설정하려면 다음 안내를 따르세요.

  1. 커스텀 서브넷 네트워크를 만듭니다.

  2. 에서 지정한 대로 app.yaml 파일에 네트워크 이름과 하위 네트워크 이름을 추가합니다.

  3. 정적 라우팅 기반의 간단한 VPN을 설정하려면 커스텀 서브넷 네트워크를 위한 게이트웨이와 터널을 생성합니다. 그렇지 않으면 [사용 안내 문서]를 참조하여 다른 유형의 VPN을 만듭니다.

포트 전달

포트 전달을 이용하면 인스턴스의 Docker 컨테이너에 직접 연결할 수 있습니다. 이 트래픽은 모든 프로토콜을 통해 이동할 수 있습니다. 포트 전달은 디버거 또는 프로파일러를 연결해야 하는 상황에 도움을 주기 위한 것입니다. 트래픽은 appspot.com 도메인이나 커스텀 도메인을 통해서가 아니라 대상 인스턴스의 IP 주소로 직접 전송되어야 합니다.

기본적으로, 네트워크 외부에서 들어오는 트래픽은 Google Cloud Platform 방화벽을 통해 허용되지 않습니다. app.yaml 파일에 포트 전달을 지정한 후에는 열어 놓을 포트로부터 트래픽을 허용하는 방화벽 규칙을 추가해야 합니다.

Google Cloud Platform 콘솔의 네트워크 방화벽 규칙 페이지에서 방화벽 규칙을 지정하거나 gcloud 명령어를 사용하여 방화벽 규칙을 지정합니다.

예를 들어 포트 2222에서 들어오는 TCP 트래픽을 전달하려면 다음 안내를 따르세요.

  1. app.yaml의 네트워크 설정에 다음을 포함시킵니다.

    network:
      forwarded_ports:
        - 2222/tcp
    
  2. GCP 콘솔 또는 gcloud compute firewall-rules create를 사용해 방화벽 규칙을 지정하여 모든 소스(0.0.0.0/0)와 tcp:2222에서 들어오는 트래픽을 허용합니다.

리소스 설정

이 설정은 컴퓨팅 리소스를 제어합니다. App Engine은 사용자가 지정한 CPU와 메모리의 크기에 따라 머신 유형을 할당합니다. 머신에는 최소한 사용자가 지정한 수준 이상의 리소스가 보장되며 그 이상의 리소스가 제공될 수도 있습니다.

리소스 설정에서 최대 8개의 tmpfs 볼륨을 지정할 수 있습니다. 그런 다음 tmpfs를 통해 공유된 메모리를 필요로 하는 작업 부하를 사용 설정하고 파일 시스템 I/O를 개선할 수 있습니다.

예:

resources:
  cpu: 2
  memory_gb: 2.3
  disk_size_gb: 10
  volumes:
  - name: ramdisk1
    volume_type: tmpfs
    size_gb: 0.5

리소스 설정을 구성할 때 다음 옵션을 사용할 수 있습니다.

옵션 설명 기본
cpu 코어 개수. 1개이거나, 2개에서 32개 사이의 짝수여야 합니다. 1개의 코어
memory_gb

RAM(GB). 애플리케이션에 요청된 메모리이며, 일부 프로세스의 오버헤드에 필요한 0.4GB 이하의 메모리는 여기에 포함되지 않습니다. 각 CPU 코어에 0.9~6.5GB 사이의 총 메모리가 필요합니다.

요청된 메모리를 계산하려면 다음을 사용하세요.

memory_gb = cpu * [0.9 - 6.5] - 0.4

2개의 코어를 지정한 위의 예에서는 1.4~12.6GB를 요청할 수 있습니다. 애플리케이션에 제공되는 총 메모리는 런타임 환경에서 환경 변수 GAE_MEMORY_MB로 설정합니다.

0.6GB
disk_size_gb 크기(GB). 최소값은 10GB이고 최대값은 10,240GB입니다. 10GB
name 볼륨을 사용할 경우 필수 항목이며, 볼륨의 이름입니다. 이름은 고유해야 하며 1~63자여야 합니다. 소문자, 숫자, 대시로 구성될 수 있습니다. 첫 번째 글자는 문자여야 하고, 마지막 글자는 대시가 아니어야 합니다. 볼륨은 앱 컨테이너에 /mnt/NAME으로 마운트됩니다.
volume_type 볼륨을 사용할 경우 필수 항목이며, tmpfs여야 합니다.
size_gb 볼륨을 사용할 경우 필수 항목이며, 볼륨의 크기(GB)입니다. 최소값은 0.001GB이고 최대값은 애플리케이션 컨테이너와 기본 장치에 제공되는 메모리 양입니다. Google은 디스크 요구사항을 충족하기 위해 시스템에 추가 RAM을 추가하지 않습니다. tmpfs 볼륨에 할당되는 RAM은 앱 컨테이너에 제공되는 메모리에서 차감됩니다. 정밀도는 시스템에 따라 다릅니다.

상태 확인

정기적인 상태 확인 요청을 통해 VM 인스턴스가 성공적으로 배포되었는지 확인하고 실행 중인 인스턴스가 정상 상태로 유지되는지 확인할 수 있습니다. 각 상태 확인에 대한 응답은 지정된 시간 간격 내에 이루어져야 합니다.

지정된 횟수만큼 연속으로 상태 확인 요청에 응답하지 못하는 인스턴스는 비정상 상태로 간주됩니다. 인스턴스가 활성 상태가 아니면 다시 시작됩니다. 인스턴스가 준비된 상태가 아니면 어떤 클라이언트 요청도 수신하지 못합니다.

다음과 같은 두 가지 유형의 상태 확인을 사용할 수 있습니다.

  • 업데이트된 상태 확인은 보다 세밀하며, 별도의 확인을 사용하여 App Engine 인스턴스가 실행되고 있으며(활성) 콘텐츠를 제공할 수 있는지(준비) 확인할 수 있습니다. 이 상태 확인은 기본적으로 사용하도록 설정되어 있습니다.

  • 이전 상태 확인은 App Engine 인스턴스가 실행 중이고 정상인지 확인합니다. 새 GCP 프로젝트에 이전 상태 확인을 사용하려면 기본 설정인 업데이트된 상태 확인을 사용 중지해야 합니다.

하나의 프로젝트에서 한 가지 유형의 상태 확인만 사용할 수 있습니다. app.yaml 파일의 커스텀 로직으로 두 가지 상태 확인 유형을 모두 수정할 수 있습니다.

애플리케이션에서 사용 중인 상태 확인의 유형을 확인하려면 다음 명령어를 실행합니다.

gcloud app describe

애플리케이션이 업데이트된 상태 확인을 사용하는 경우에는 설명에 다음 정보가 포함되어야 합니다.

featureSettings:
    splitHealthChecks: true

업데이트된 상태 확인

업데이트된 상태 확인에는 두 가지 유형이 있습니다. 즉 활성 확인을 통해 App Engine 인스턴스가 실행 중인지 확인하고, 준비 확인을 통해 인스턴스가 콘텐츠를 제공할 준비가 되어 있는지 확인할 수 있습니다.

기본적으로, 업데이트된 상태 확인의 HTTP 요청은 애플리케이션 컨테이너로 전달되지 않습니다. 상태 확인을 애플리케이션으로 확장하려면 활성 확인 또는 준비 확인을 위한 경로를 지정해야 합니다. 200 OK 응답 코드를 반환할 경우 애플리케이션의 커스텀 상태 확인에 성공한 것으로 간주됩니다.

업데이트된 상태 확인 사용 설정

기본적으로 업데이트된 상태 확인은 사용하도록 설정됩니다. 이전 상태 확인을 사용하는 Google Cloud Platform 프로젝트에 업데이트된 상태 확인을 사용 설정하려면 다음 단계를 완료하세요.

  1. 다음 명령어를 실행합니다.

    gcloud app update --split-health-checks --project [YOUR_PROJECT_ID]

    또는 app.yaml 파일에 liveness_check 또는 readiness_check 섹션을 지정하여 업데이트된 상태 확인을 사용 설정할 수 있습니다. 예를 보려면 활성 확인준비 확인을 참조하세요.

  2. 이전 상태 확인에 커스텀 설정을 사용한 경우, app.yaml 파일에서 health_check 섹션을 삭제해야 합니다.

  3. 활성 상태 확인과 준비 상태 확인을 시작하기 위해 앱의 대폭 달라진 새 버전을 배포합니다.

활성 확인

활성 확인은 VM 및 Docker 컨테이너가 실행 중인지 확인합니다. 비정상으로 간주되는 인스턴스는 다시 시작됩니다.

app.yaml 파일에 선택 사항인 liveness_check 섹션을 추가하여 활성 확인 요청을 맞춤설정할 수 있습니다. 예를 들면 다음과 같습니다.

liveness_check:
  path: "/liveness_check"
  check_interval_sec: 30
  timeout_sec: 4
  failure_threshold: 2
  success_threshold: 2

활성 확인에 다음 설정을 사용할 수 있습니다.

필드 기본 범위(최소-최대) 설명
path 없음 활성 확인이 애플리케이션 컨테이너로 전달되도록 하려면 "/liveness_check"와 같은 URL 경로를 지정합니다.
timeout_sec 4초 1-300 각 요청의 시간 제한 간격(초)입니다.
check_interval_sec 30초 1-300 각 확인 사이의 시간 간격(초)입니다.
failure_threshold 4회 확인 1-10 이 횟수만큼 연속으로 확인에 실패하면 인스턴스가 비정상입니다.
success_threshold 2회 확인 1-10 비정상 인스턴스가 이 횟수만큼 연속으로 확인에 응답하는 데 성공하면 정상이 됩니다.
initial_delay_sec 300초 0-3600 인스턴스가 시작된 후에 상태 확인 응답이 무시되는 지연 시간(초)입니다. 이 설정은 새로 생성된 각 인스턴스에 적용되며 새 인스턴스의 준비 및 실행 시간을 늘릴 수 있습니다. 이 설정은 인스턴스를 시작하는 중에 인스턴스를 점검하고 조기에 다시 만들지 않도록 자동 복구를 지연합니다. 인스턴스가 RUNNING 모드이면 초기 지연 타이머가 시작됩니다. 예를 들어 애플리케이션이 초기화 작업 때문에 트래픽 처리 준비까지 시간이 오래 걸린다면 지연을 늘릴 수 있습니다.

준비 확인

준비 확인은 인스턴스가 수신되는 요청을 수락할 수 있는지 확인합니다. 준비 확인을 통과하지 못한 인스턴스는 사용 가능한 인스턴스의 풀에 추가되지 않습니다.

app.yaml 파일에 선택 사항인 readiness_check 섹션을 추가하여 상태 확인 요청을 맞춤설정할 수 있습니다. 예를 들면 다음과 같습니다.

readiness_check:
  path: "/readiness_check"
  check_interval_sec: 5
  timeout_sec: 4
  failure_threshold: 2
  success_threshold: 2
  app_start_timeout_sec: 300

준비 확인에 다음 설정을 사용할 수 있습니다.

필드 기본 범위(최소-최대) 설명
path 없음 준비 확인이 애플리케이션 컨테이너로 전달되도록 하려면 "/readiness_check"와 같은 URL 경로를 지정합니다.
timeout_sec 4초 1-300 각 요청의 시간 제한 간격(초)입니다.
check_interval_sec 5초 1-300 각 확인 사이의 시간 간격(초)입니다.
failure_threshold 2회 확인 1-10 이 횟수만큼 연속으로 확인에 실패하면 인스턴스가 비정상입니다.
success_threshold 2회 확인 1-10 비정상 인스턴스가 이 횟수만큼 연속으로 확인에 응답하는 데 성공하면 정상이 됩니다.
app_start_timeout_sec 300초 1-1800 이 설정은 개별 VM이 아닌 새 배포에 적용됩니다. 배포에서 충분한 수의 인스턴스가 상태 확인을 통과하는 데 필요한 최대 시간(초)을 지정합니다. 이 시간이 지나면 배포가 실패하여 롤백됩니다. 이 타이머는 Compute Engine 인스턴스가 프로비저닝되고 Load Balancer 백엔드 서비스가 생성되면 작동하기 시작합니다. 예를 들어 배포 중에 충분한 수의 인스턴스가 양호한 상태를 유지하도록 제한 시간을 늘리고 싶다면 제한 시간을 늘리면 됩니다.

이전 상태 확인

이전 상태 확인 요청을 사용하려면 먼저 다음 명령어로 기본 설정인 업데이트된 상태 확인 요청을 사용 중지해야 합니다.

gcloud app update --no-split-health-checks

선택사항인 상태 확인 섹션을 구성 파일에 추가하여 이전 상태 확인을 맞춤설정할 수 있습니다.

health_check:
  enable_health_check: True
  check_interval_sec: 5
  timeout_sec: 4
  unhealthy_threshold: 2
  healthy_threshold: 2

이전 상태 확인에 다음 옵션을 사용할 수 있습니다.

옵션 설명 기본
enable_health_check 상태 확인을 사용 설정/사용 중지합니다. 상태 확인은 기본적으로 사용 설정되어 있습니다.
상태 확인을 사용 중지하려면 False로 설정합니다.
True
check_interval_sec 각 확인 간 시간 간격입니다. 1초
timeout_sec 상태 확인 시간 제한 간격입니다. 1초
unhealthy_threshold 이 횟수만큼 연속으로 확인에 실패하면 인스턴스가 비정상입니다. 1회 확인
healthy_threshold 비정상 인스턴스가 이 횟수만큼 연속으로 확인에
성공적으로 응답하면 다시 정상이 됩니다.
1회 확인
restart_threshold 연속으로 실패한 상태 확인 횟수가 이 기준을 초과하면 인스턴스가 다시 시작됩니다. 300회 확인

상태 확인 빈도

가용성을 높이기 위해 App Engine에서는 각 상태 검사기의 중복 사본을 만듭니다. 상태 검사기가 실패하면 지연 시간 없이 중복 검사기가 그 역할을 대신합니다.

애플리케이션의 nginx.health_check 로그를 확인하면 사용자 설정까지 따르는 중복 상태 검사기 때문에 상태 확인 폴링이 사용자가 구성한 빈도보다 더 자주 일어나는 경우가 있습니다. 이 중복 상태 검사기는 자동으로 생성되며 사용자가 구성할 수 없습니다.

서블릿 3.1 주석 처리

Jetty 9 빠른 시작은 고급 서블릿 주석과 호환되어 시작 성능을 향상시킵니다. 서블릿 3.1 사양을 사용하고 있고 서블릿 3.1 주석을 처리하려면 app.yaml 파일에 이 베타 설정을 포함하세요.

beta_settings:
  java_quickstart: true

서비스 확장 설정

서비스의 확장을 제어하는 데 사용되는 키는 서비스에 할당하는 확장의 유형에 따라 다릅니다.

자동 확장 또는 수동 확장을 사용할 수 있습니다. 기본값은 자동 확장입니다.

자동 확장

app.yaml 파일에 automatic_scaling 섹션을 추가하여 자동 확장을 구성할 수 있습니다. 예를 들면 다음과 같습니다.

automatic_scaling:
  min_num_instances: 1
  max_num_instances: 15
  cool_down_period_sec: 180
  cpu_utilization:
    target_utilization: 0.6

다음 표에는 자동 확장에 사용할 수 있는 설정이 나와 있습니다.

이름 설명
automatic_scaling 기본적으로 자동 확장이 적용됩니다. 자동 확장 설정을 지정하려면 이 줄을 포함시킵니다.
min_num_instances 서비스에 제공되는 인스턴스의 최소 개수입니다. 서비스가 배포되면 트래픽에 따라 이 개수만큼 인스턴스와 확장이 제공됩니다. 1 이상이어야 하며, 지연 시간을 줄이기 위한 기본값은 2입니다.
max_num_instances 서비스가 확장될 수 있는 인스턴스의 최대 개수입니다. 프로젝트 내 최대 인스턴스 수는 프로젝트의 리소스 할당량에 따라 제한됩니다. 기본값은 20입니다.
cool_down_period_sec 자동 확장 처리가 새로운 인스턴스에서 정보를 수집하기 전에 대기하는 시간(초)입니다. 이 설정은 인스턴스가 초기화될 때 자동 확장 처리가 정보를 수집하지 못하게 합니다. 초기화하는 동안 수집된 사용량은 정확하지 않기 때문입니다. 대기 시간은 60초 이상이어야 합니다. 기본값은 120입니다.
cpu_utilization 대상 CPU 사용률을 지정하려면 이 헤더를 사용하세요.
target_utilization 대상 CPU 사용률입니다. CPU 사용률은 실행 중인 모든 인스턴스의 평균으로 계산되며 인스턴스의 개수를 줄이거나 늘릴 시기를 결정하는 데 사용됩니다. 인스턴스가 종료 신호를 수신한 후 25초가 지나면 처리 중인 요청과 관계없이 인스턴스가 축소됩니다. 기본값은 0.5입니다.

수동 확장

app.yaml 파일에 manual_scaling 섹션을 추가하여 수동 확장을 구성할 수 있습니다. 예를 들면 다음과 같습니다.

manual_scaling:
  instances: 5

다음 표에는 수동 확장과 함께 사용할 수 있는 설정이 나와 있습니다.

이름설명
manual_scaling 서비스에 수동 확장을 사용 설정하는 데 필요합니다.
instances 서비스에 할당할 인스턴스의 개수입니다.

환경 변수 정의

app.yaml에서 환경 변수를 정의하여 앱에서 사용하도록 할 수 있습니다. 예를 들면 다음과 같습니다.

env_variables:
  MY_VAR: "my value"

여기서 MY_VARmy value는 정의하려는 환경 변수의 이름과 값이며, 모든 환경 변수 항목은 env_variables 요소 아래에 2개의 공백을 사용하여 들여쓰기됩니다.

환경 변수 사용

환경 변수를 검색하고 사용하려면 System.getenv()를 사용합니다.

덮어쓸 수 없는 자바 8/Jetty 9 또는 자바 8 런타임 환경 변수 목록 또한 참조하세요. 예를 들어 GAE로 시작하는 모든 환경 변수는 시스템 용도로 예약되어 있습니다.

프로젝트의 프로젝트 ID(앱 ID) 설정

일부 App Engine 표준 환경 런타임에서는 프로젝트의 app.yaml 또는 appengine-web.xml 파일에 Cloud Platform 프로젝트 ID('앱 ID'라고도 함)를 지정했을 수 있습니다.

하지만 가변형 환경에서는 프로젝트 ID(앱 ID)가 다음과 같은 방법으로 지정됩니다.

  • Google Cloud SDK를 설치할 때 gcloud init를 사용하여 지정합니다. gcloud 도구의 기본 프로젝트 ID를 보려면 gcloud config list를 실행합니다.
  • gcloud config set project [YOUR_PROJECT_ID] 명령어를 사용하여 gcloud 도구의 기본 프로젝트 ID를 설정합니다.
  • 앱을 배포할 때 --project 플래그를 사용합니다. 예: gcloud app deploy --project [YOUR_PROJECT_ID]
  • Intellij용 Google Cloud 플러그인 또는 Eclipse용 Google Cloud 플러그인을 사용하여 배포 중에 프로젝트 ID를 지정합니다.