API 백엔드 배포

OpenAPI | gRPC

이 페이지에서는 API의 백엔드 코드와 확장 가능 서비스 프록시(ESP)를 Google Kubernetes Engine 및 Compute Engine에 배포하는 방법에 대해 설명합니다.

배포 단계는 API를 호스팅하는 플랫폼에 따라 다르지만, ESP에 서비스 이름과 배포된 최신 Cloud Endpoints 서비스 구성을 사용하도록 ESP를 구성하는 옵션을 제공하는 단계는 항상 있습니다. ESP는 이 정보를 사용하여 API의 Endpoints 구성을 가져올 수 있습니다. 이 구성을 통해 Cloud Endpoints에서 API를 관리할 수 있게 ESP가 요청과 응답을 프록시할 수 있습니다.

기본 요건

이 페이지에서는 먼저 사용자가 다음 작업을 완료했다고 가정합니다.

• Google Cloud 프로젝트를 만들었습니다.
• Endpoints를 구성했습니다.
• Endpoints 구성을 배포했습니다.

배포 준비

Compute Engine

Endpoints에서 API를 관리하려면 ESP와 API의 백엔드 서버 코드를 설치하고 구성해야 합니다. Container Registry에서 무료로 사용할 수 있는 ESP Docker 이미지를 실행할 수 있도록 Compute Engine VM 인스턴스에 Docker를 설치해야 합니다.

배포하기 전에:

API 및 ESP를 Compute Engine에 배포하기 전에 다음 단계를 완료하세요.

1. VM 인스턴스를 만들고, 구성하고, 시작합니다.
2. VM 인스턴스에 Docker Enterprise Edition(EE) 또는 Docker Community Edition(CE)을 설치합니다.
3. 백엔드 서버 코드용 Docker 컨테이너를 만듭니다.
4. Container Registry 또는 다른 레지스트리로 컨테이너를 푸시합니다.

5. 다음을 수행할 수 있는지 확인합니다.

   • VM 인스턴스에 연결합니다.
   • Docker 이미지를 실행하여 VM 인스턴스에서 백엔드 서버 시작합니다. Docker 실행 참조를 참조하세요.
   • API에 요청을 보냅니다.

GKE

Google Cloud Console에서 클러스터를 만들 때 기본적으로 클러스터 서비스 계정에 부여된 OAuth 범위에는 Endpoints에서 필요한 범위가 포함됩니다.

• Service Control: 사용 설정됨
• Service Management: 읽기 전용

gcloud container clusters create 명령어나 타사 구성 파일을 사용하여 클러스터를 만들 때 다음 범위를 지정해야 합니다.

• "https://www.googleapis.com/auth/servicecontrol"
• "https://www.googleapis.com/auth/service.management.readonly"

자세한 내용은 액세스 범위란 무엇인가요?를 참조하세요.

배포하기 전에:

배포 매니페스트 파일에 작은 섹션을 추가하면 컨테이너 클러스터에서 컨테이너식 애플리케이션과 함께 ESP Docker 이미지를 실행할 수 있습니다. API를 ESP와 함께 GKE에 배포하려면 다음 단계를 완료하세요.

1. 컨테이너화된 애플리케이션을 컨테이너 클러스터에 배포합니다. GKE 문서에 설명되어 있는 일반적인 단계는 다음과 같습니다.

   1. 애플리케이션을 Docker 이미지로 패키지화합니다.
   2. 이미지를 레지스트리로 업로드합니다.
   3. 컨테이너 클러스터를 만듭니다.
   4. 애플리케이션을 클러스터에 배포합니다.
   5. 애플리케이션을 인터넷에 노출합니다.

2. 다음을 수행할 수 있는지 확인합니다.

   • API의 서버를 시작합니다.
   • API에 요청을 보냅니다.

API 및 ESP 배포

Compute Engine

Docker를 사용하는 Compute Engine에 API와 ESP를 배포하려면 다음 안내를 따르세요.

1. VM 인스턴스에 연결합니다. INSTANCE_NAME을 VM 인스턴스 이름으로 바꿉니다.

   gcloud compute ssh INSTANCE_NAME
   

2. esp_net이라는 자체 컨테이너 네트워크를 만듭니다.

   sudo docker network create --driver bridge esp_net
   

3. 백엔드 서버 코드의 이미지 인스턴스를 실행하고 esp_net 컨테이너 네트워크에 연결합니다.

   sudo docker run \
       --detach \
       --name=YOUR_API_CONTAINER_NAME \
       --net=esp_net \
       gcr.io/YOUR_PROJECT_ID/YOUR_IMAGE:1
   

   • YOUR_API_CONTAINER_NAME을 컨테이너 이름으로 바꿉니다.
   • YOUR_PROJECT_ID를 이미지를 푸시할 때 사용한 Google Cloud 프로젝트 ID로 바꿉니다.
   • YOUR_IMAGE를 이미지 이름으로 바꿉니다.

4. API의 서비스 이름을 가져옵니다. 이 이름은 서비스 구성 YAML 파일의 name 필드에서 지정한 이름입니다.

5. ESP Docker 이미지의 인스턴스를 실행합니다.

   sudo docker run \
       --detach \
       --name=esp \
       --publish=80:9000 \
       --net=esp_net \
       gcr.io/endpoints-release/endpoints-runtime:1 \
       --service=SERVICE_NAME \
       --rollout_strategy=managed \
       --http2_port=9000 \
       --backend=grpc://YOUR_API_CONTAINER_NAME:8000
   

   • SERVICE_NAME을 서비스 이름으로 바꿉니다.
   • YOUR_API_CONTAINER_NAME을 API의 컨테이너 이름으로 바꿉니다.

   --rollout_strategy=managed 옵션은 ESP가 배포된 최신 서비스 구성을 사용하도록 구성합니다. 이 옵션을 지정하면 새 서비스 구성을 배포하고 최대 5분 후 ESP가 변경사항을 감지하고 자동으로 사용하기 시작합니다. ESP에 사용할 특정 구성 ID 대신 이 옵션을 지정하는 것이 좋습니다.

특정 구성 ID를 사용하도록 ESP를 구성해야 하는 경우

1. --version 옵션을 포함하고 특정 구성 ID로 설정합니다.

2. --rollout_strategy=managed 옵션을 삭제하거나 --rollout_strategy를 fixed로 설정합니다. fixed 옵션은 ESP가 --version에 지정된 서비스 구성을 사용하도록 구성합니다.

3. docker run 명령어를 다시 실행합니다

--rollout_strategy=managed 및 --version 옵션을 모두 지정하면 ESP가 --version에서 지정된 구성으로 시작됩니다. 하지만 그 후에는 관리 모드로 실행되어 최신 구성을 가져옵니다.

업데이트된 서비스 구성을 배포하는 경우 새로운 구성을 사용하기 위해 ESP를 다시 시작해야 하므로 ESP가 장기간 특정 구성 ID를 사용하도록 구성한 상태로 두지 않는 것이 좋습니다.

특정 구성 ID 삭제:

1. docker run의 ESP 플래그에서 --version 옵션을 삭제합니다.

2. --rollout_strategy=managed 옵션을 추가합니다.

3. ESP를 다시 시작하려면 docker run 명령어를 실행합니다.

ESP를 시작할 때 지정할 수 있는 옵션의 전체 목록은 ESP 시작 옵션을 참조하세요.

GKE

GKE에 ESP를 배포하려면 다음 안내를 따르세요.

1. API의 서비스 이름을 가져옵니다.

2. 배포 매니페스트 파일(deployment.yaml이라고 함)을 열고 containers 섹션에 다음을 추가합니다.

         containers:
         - name: esp
           image: gcr.io/endpoints-release/endpoints-runtime:1
           args: [
             "--http2_port=9000",
             "--service=SERVICE_NAME",
             "--rollout_strategy=managed",
             "--backend=grpc://127.0.0.1:8000"
           ]
           ports:
             - containerPort: 9000
   

   SERVICE_NAME을 API의 서비스 이름으로 바꿉니다.

3. kubectl create 명령어를 사용하여 Kubernetes 서비스를 시작합니다.

       kubectl create -f deployment.yaml
   

특정 구성 ID를 사용하도록 ESP를 구성해야 하는 경우

1. 배포 매니페스트 파일에서 --version 옵션을 추가하고 특정 구성 ID로 설정합니다.

2. --rollout_strategy=managed를 삭제하거나 --rollout_strategy를 fixed로 설정합니다. fixed 옵션은 ESP가 --version에 지정된 서비스 구성을 사용하도록 구성합니다.

3. kubectl create -f deployment.yaml 명령어를 사용하여 Kubernetes 서비스를 시작합니다.

--rollout_strategy=managed 및 --version 옵션을 모두 지정하면 ESP가 --version에서 지정한 구성으로 시작됩니다. 하지만 그 후에는 관리 모드로 실행되어 최신 구성을 가져옵니다.

업데이트된 서비스 구성을 배포하는 경우 새로운 구성을 사용하기 위해 ESP를 다시 시작해야 하므로 ESP가 장기간 특정 구성 ID를 사용하도록 구성한 상태로 두지 않는 것이 좋습니다.

특정 구성 ID 삭제:

1. 배포 매니페스트 파일에서 --version 옵션을 삭제합니다.

2. --rollout_strategy=managed를 추가합니다.

3. kubectl create -f deployment.yaml 명령어를 사용하여 Kubernetes 서비스를 시작합니다.

ESP를 시작할 때 지정할 수 있는 옵션의 전체 목록은 ESP 시작 옵션을 참조하세요.

API 활동 추적

ESP와 API 백엔드를 배포한 후에는 curl 또는 Postman과 같은 도구를 사용하여 API에 요청을 보낼 수 있습니다. 성공적인 응답을 받지 못하면 응답 오류 문제해결을 참조하세요.

요청을 보낸 후 다음을 수행할 수 있습니다.

• API의 활동 그래프를 보기 위해 Endpoints > 서비스로 이동합니다. 요청이 그래프에 반영되는 데 잠시 시간이 걸릴 수 있습니다.

  Endpoints 서비스 페이지로 이동

• Cloud Logging 페이지에서 API의 요청 로그를 봅니다.

  로그 탐색기 페이지로 이동

다음 단계

• Compute Engine에서 Endpoints 문제해결
• GKE에서 Endpoints 문제해결