앱 버전을 App Engine에 배포

리전 ID

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

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

App Engine Admin API를 사용하여 프로그래매틱 방식으로 HTTP POST 요청을 통해 App Engine 애플리케이션에 앱 버전을 배포할 수 있습니다.

시작하기 전에

HTTP 배포 요청을 보내기 전에 HTTP 요청을 승인하고 스테이징된 앱 파일에 액세스할 수 있어야 하며 포맷된 JSON 구성 파일이 필요합니다. 이러한 사전 요건에 대한 도움말은 다음 주제를 참조하세요.

Admin API를 사용하여 App Engine에 앱 배포

App Engine의 애플리케이션에 앱 버전을 배포하려면 다음 안내를 따르세요.

  1. HTTP 요청을 승인합니다(예: 액세스 토큰 확보).

    Admin API에 대한 액세스 승인은 API 앱의 요구사항에 따라 서로 다른 OAuth 흐름을 사용하여 이루어집니다. 자세한 내용은 API 액세스를 참조하세요.

  2. 액세스 토큰 및 Admin API를 사용하여 HTTP POST 요청을 보내 App Engine 애플리케이션에 버전을 배포합니다.

    버전을 배포하려면 JSON 구성 파일을 지정하고 대상 서비스 및 App Engine 애플리케이션의 Version 리소스를 정의하는 HTTP POST 요청을 보냅니다.

    예를 들어 다음 HTTP POST 요청을 사용하여 JSON 구성 파일에 지정된 버전을 MY_PROJECT_ID 애플리케이션의 default 서비스에 배포할 수 있습니다.

    POST https://appengine.googleapis.com/v1/apps/[MY_PROJECT_ID]/services/default/versions app.json

    cURL 명령어 예시:

    curl -X POST -T "app.json" -H "Content-Type: application/json" -H "Authorization: Bearer [MY_ACCESS_TOKEN]" https://appengine.googleapis.com/v1/apps/[MY_PROJECT_ID]/services/default/versions

    각 항목의 의미는 다음과 같습니다.

    • [MY_ACCESS_TOKEN]은 HTTP 요청을 승인하기 위해 받은 액세스 토큰입니다.
    • [MY_PROJECT_ID]는 버전을 배포하려는 프로젝트의 ID입니다.

    응답 예:

    {
  "metadata": {
    "@type": "type.googleapis.com/google.appengine.v1.OperationMetadataV1",
    "insertTime": "2015-05-29T17:12:44.679Z",
    "method": "google.appengine.v1.Versions.CreateVersion",
    "target": "apps/[MY_PROJECT_ID]/services/default/versions/v1",
    "user": "me@example.com"
  }
  "name": "apps/[MY_PROJECT_ID]/operations/89729825-ef1f-4ffa-b3e3-e2c25eb66a85"
}

  3. App Engine 애플리케이션에 버전이 배포되었는지 확인합니다.

    1. 실제 배포 작업의 상태를 봅니다.

      이전 단계에서 사용한 HTTP POST 요청이 name 필드에 작업 이름을 반환했으며, 이를 apps.operations 컬렉션의 GET 메소드와 함께 사용하여 배포 작업의 상태를 확인할 수 있습니다.

      예를 들어 응답의 name 필드가 다음과 같은 경우:

      "name": "apps/[MY_PROJECT_ID]/operations/89729825-ef1f-4ffa-b3e3-e2c25eb66a85"

      다음 HTTP GET 요청을 보냅니다.

      GET https://appengine.googleapis.com/v1/apps/[MY_PROJECT_ID]/operations/89729825-ef1f-4ffa-b3e3-e2c25eb66a85

      cURL 명령어 예시:

      curl -H "Authorization: Bearer [MY_ACCESS_TOKEN]" https://appengine.googleapis.com/v1/apps/[MY_PROJECT_ID]/operations/89729825-ef1f-4ffa-b3e3-e2c25eb66a85

      여기에서 [MY_ACCESS_TOKEN]은 액세스 토큰이며 [MY_PROJECT_ID]는 버전을 배포한 프로젝트의 ID입니다.

      응답 예:

      {
  "done": true,
  "metadata": {
    "@type": "type.googleapis.com/google.appengine.v1.OperationMetadataV1",
    "endTime": "2015-05-29T17:13:20.424Z",
    "insertTime": "2015-05-29T17:12:44.679Z",
    "method": "google.appengine.v1.Versions.CreateVersion",
    "target": "apps/[MY_PROJECT_ID]/services/default/versions/v1",
    "user": "me@example.com"
  },
  "name": "apps/[MY_PROJECT_ID]/operations/89729825-ef1f-4ffa-b3e3-e2c25eb66a85",
  "response": {
    "@type": "type.googleapis.com/google.appengine.v1.Version",
    "creationTime": "2015-05-29T17:12:46.000Z",
    "deployer": "me@example.com",
    "id": "v1",
    "name": "apps/[MY_PROJECT_ID]/services/default/versions/v1",
    "runtime": "python27",
    "servingStatus": "SERVING",
    "threadsafe": true,
  }
}

      장기 실행 작업의 폴링에 대한 자세한 내용은 google.longrunning RPC 참조에서 볼 수 있습니다.

    2. App Engine 애플리케이션에서 버전이 생성되었는지 확인합니다.

      버전에 대한 세부정보를 보려면 apps.services.versions 컬렉션의 GET 메서드를 사용합니다. HTTP GET 요청에 배포한 버전을 지정해야 합니다. 예를 들면 다음과 같습니다.

      GET https://appengine.googleapis.com/v1/apps/[MY_PROJECT_ID]/services/default/versions/v1

      cURL 명령어 예시:

      curl -H "Authorization: Bearer [MY_ACCESS_TOKEN]" https://appengine.googleapis.com/v1/apps/[MY_PROJECT_ID]/services/default/versions/v1

      여기에서 [MY_ACCESS_TOKEN]은 액세스 토큰이며 [MY_PROJECT_ID]는 버전을 배포한 프로젝트의 ID입니다.

      응답 예:

      {
  "creationTime": "2015-05-29T17:12:46.000Z",
  "deployer": "me@example.com",
  "deployment": {
    "files": {
      "my-python-app.py": {
        "sha1Sum": "7cffbdaa9fcfa46e5e58269bfe336dd815de0566",
        "sourceUrl": "https://storage.googleapis.com/[YOUR_BUCKET_ID]/my-application/logo.jpg",
      },
      "logo.jpg": {
        "sha1Sum": "13f7ea1e24f7cd2de5c66660525f2b509da37c14",
        "sourceUrl": "https://storage.googleapis.com/[YOUR_BUCKET_ID]/my-application/my-python-app.py"
      }
    }
  },
  "handlers": [
    {
      "authFailAction": "AUTH_FAIL_ACTION_REDIRECT",
      "login": "LOGIN_OPTIONAL",
      "script": {
        "scriptPath": "my-python-app.application",
      },
      "securityLevel": "SECURE_OPTIONAL",
      "urlRegex": "/.*"
    }
  ]
  "id": "v1",
  "name": "apps/[MY_PROJECT_ID]/services/default/versions/v1",
  "runtime": "python27",
  "servingStatus": "SERVING",
  "threadsafe": true,
}

      GET https://appengine.googleapis.com/v1/apps/[MY_PROJECT_ID]/services/default/versions/v1?view=FULL

  4. (선택사항) https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com를 사용하여 브라우저를 시작하고 앱을 보려면 다음 명령어를 실행하면 됩니다.

    gcloud app browse -v [MY_VERSION_ID]

  5. 배포한 버전에서 수신해야 하는 트래픽의 양을 구성합니다.

    기본적으로, App Engine 애플리케이션에 배포하는 최초의 버전은 트래픽의 100%를 수신하도록 자동으로 구성됩니다. 그러나 그 이후에 동일한 App Engine 애플리케이션에 배포하는 모든 버전은 수동으로 구성해야 하며, 그렇게 하지 않으면 트래픽을 수신하지 않습니다.

    버전의 트래픽을 구성하는 방법은 트래픽 이전 및 분할을 참조하세요.

추가 버전 및 서비스 배포

추가 서비스 생성을 포함하여 앱의 후속 버전을 배포하기 위한 단계는 이 작업에서 다룬 배포 단계와 거의 동일합니다. App Engine 애플리케이션에서 실행 중인 현재 버전을 대체하거나 부가적인 서비스를 추가하려는 경우 구성 파일에서 몇 가지 부분을 수정한 다음 새 버전을 배포할 수 있습니다.

다음 예에서 App Engine 애플리케이션에 추가 버전을 배포하는 방법을 볼 수 있습니다. 버전을 배포한 후 트래픽을 구성해야 한다는 점을 유의하세요.

예: 추가 서비스 배포

App Engine에 오래된 버전 또는 결함이 있는 버전이 실행 중인 경우 App Engine 애플리케이션에 다른 버전을 배포한 다음 이 버전으로 트래픽을 라우팅하는 방법으로 버전을 대체할 수 있습니다. 예를 들어 앱의 소스 코드를 수정한 후 app.yaml 파일의 version 값을 변경하고 새 app.json 파일을 만든 다음 다른 HTTP POST 요청으로 앱의 v2 버전을 배포합니다.

업데이트된 app.yaml 파일의 예:

  service: default
  version: v2
  runtime: python27
  threadsafe: true
  handlers:
  - url: /.*
    script: my-python-app.application

버전 v2에 대한 HTTP POST 요청의 예:

  POST https://appengine.googleapis.com/v1/apps/[MY_PROJECT_ID]/services/default/versions app.json

버전이 성공적으로 배포되었는지 확인하기 위한 단계를 수행한 후 HTTP PATCH 요청을 보내 모든 트래픽을 새 버전으로 라우팅할 수 있습니다. 예를 들면 다음과 같습니다.

  PATCH https://appengine.googleapis.com/v1/apps/[MY_PROJECT_ID]/services/default/?updateMask=split {"split": { "allocations": { "v2": "1" } } }

트래픽 라우팅에 대한 자세한 내용은 트래픽 마이그레이션 및 분할을 참조하세요.

예: 여러 서비스 배포

v1 버전이 App Engine 애플리케이션에서 실행 중이고 추가 서비스를 배포하려는 경우(예: backend) 동일한 배포 단계를 수행합니다.

예를 들어 backend 서비스를 생성하는 v1 버전을 배포하려면 다음 안내를 따르세요.

  1. backend 서비스의 새 코드와 소스 파일을 만듭니다.
  2. Cloud Storage 버킷에서 backend 서비스의 애플리케이션 리소스를 스테이징합니다.
  3. backend/app.json 구성 파일을 만듭니다.

  4. HTTP 요청을 사용하여 backend 서비스의 v1 버전을 App Engine 애플리케이션에 배포합니다.

    HTTP POST 요청 예:

    POST https://appengine.googleapis.com/v1/apps/[MY_PROJECT_ID]/services/backend/versions backend/app.json

    backend 서비스에서 v1 버전이 생성되었는지 확인하는 HTTP GET 요청 예:

    GET https://appengine.googleapis.com/v1/apps/[MY_PROJECT_ID]/services

    응답 예:

    {
  "services": [
    {
      "name": "apps/[MY_PROJECT_ID]/services/default",
      "id": "default",
      "split": {
        "allocations": {
          "v2": 1
        }
      }
    },
    {
      "name": "apps/[MY_PROJECT_ID]/services/backend",
      "id": "backend",
      "split": {
        "allocations": {
          "v1": 1
        }
      }
    }
  ]
}

다음 단계