Terraform/Go/Cloud를 사용하여 실행되는 GCP API 게이트웨이 데모

나는 처음에 Medium에 이 글을 발표했다
만약 GCP 클라우드 기능이나 클라우드 운행에 있어 웹 서비스를 구축해 왔다면, 구글 클라우드에 중요한 인프라 시설인 API 게이트웨이가 부족하다는 것을 알아차렸을 것이다.
AWS가 생긴 지 몇 년이 되었지만 GCP는 동등한 서비스가 없습니다Amazon API Gateway. 하지만 범위가 좀 다르다고 생각합니다. 개발자에게 맞춤형 솔루션을 구축하게 합니다...하지만 더 이상은 아닙니다!GCPCloud Endpoints가 새로운 구글 클라우드 API 스위치를 발표했기 때문에 제가 한번 해 보겠습니다.그것은 아직 테스트 단계에 있기 때문에 당신의 생산 시스템에서 그것을 사용하기 전에 반드시 이 점을 고려해야 합니다.

얼마 전 API 게이트웨이가 필요한 이유

RedHat 살펴보기 :

An API gateway is an API management tool that sits between a client and a collection of backend services.

더욱 구체적이고 이해하기 쉽도록 본고가 구축할 예시로 빠르게 넘어가자.

해석하다 마이크로서비스 이야기 2개

본고에서 우리는 2개의 백엔드 구성 요소로 구성된 허구적인 응용 프로그램을 구축할 것이다.

사용자 서비스: 간단한 마이크로 서비스로 http API를 가지고 JSON 형식으로 사용자 목록을 되돌려주고 에 위탁 관리한다.

위치 서비스: 간단한 마이크로 서비스로 http API를 가지고 JSON 형식으로 위치 목록을 되돌려주고 GCP Cloud Run에도 위탁 관리할 수 있다.

우리는 API 게이트웨이를 통해 이 두 서비스에 대한 통일된 접근을 제공하기를 희망한다.그러면 모든 프런트엔드 구성 요소가 API 게이트웨이에 연결되고 게이트웨이는 적절한 백엔드 서비스로 라우팅을 요청합니다.다음은 두 가지 모델로 우리의 목표를 설명한다.
GCP Cloud Run 사용자 요청
GCP Cloud Function 위치 요청

인코딩해 달래요.

너는 내가 준비한 이것

을 사용할 수 있다.이것은 프로젝트를 실행하는 데 필요한 모든 코드와 명령을 포함합니다.
본 문서 에서 이 프로젝트의 대부분의 셸 명령을 포장했습니다. 명령에 대한 상세한 정보는 다음을 참조하십시오.

github 저장소 GCP 설정

이 프로젝트에 GCP 환경을 설정하는 데 필요한 초보적인 절차를 상세히 소개했습니다.이것은 주로 새로운 GCP 프로젝트를 검증하고 생성하며 올바른 권한을 가진 서비스 계정과 클라우드 API를 활성화합니다

파일 생성 백엔드 서비스

마이크로서비스 자체는 기반의 매우 간단한 Goapi 서버입니다.이것은 사용자 서비스의 처리 프로그램 부분으로 단독 루트가 있고 정적 사용자 목록을 JSON 형식으로 되돌려줍니다.

위치 서비스는 매우 비슷합니다:

이 두 서비스는 모두 컨테이너화됩니다. 우리는 단지 here(CI/CD)를 사용하여 구축하고 로 전송하면 GCP Cloud Run에 배치할 수 있습니다

사용자 서비스 용기 생성/전송:

$ # PROJECT\_ID holds the GCP project id
$ PROJECT\_ID=$PROJECT\_ID make gcr-push-users

생성/푸시 위치 서비스 용기:

$ PROJECT\_ID=$PROJECT\_ID make gcr-push-locations

chi router A bit of Terraform magic

우리는 GCP Container Registry 클라우드 운행 서비스를 배치하는 것을 사용하고 있습니다.만약 당신이 아직 그것을 사용하지 않았다면, 당신은 그것을 보아야 합니다. 왜냐하면 그것은 아주 좋은 인프라 시설이기 때문입니다. 코드 도구로서, 이것은 당신의 DevOps 업무 흐름을 더욱 깨끗하게 할 수 있기 때문입니다

terraform 설정의 가장 중요한 부분은 이 섹션입니다. 앞에서 전송한 서비스 용기를 사용하여 클라우드 운행 서비스를 설명합니다.

프로젝트를 배치하려고 하지만 지형에서 사용해야 할 지형 변수 값에 대해 곤혹스러워합니다.ffvars 파일 (repo에 제출되지 않음), 다음은 나의 특정 설정/gcp 프로젝트의 값입니다.

배포 서비스를 시작하기 위해 먼저 GCP Cloud Build를 만듭니다. 그 중에서 Terraform은 인프라 시설에 대한 변경이 필요합니다.

$ make tf-plan

그리고 우리 변경:

$ make tf-apply

출력은 다음과 같습니다.

Outputs:

locations-svc-url = [https://locations-svc-qqx6qmklha-ew.a.run.app](https://locations-svc-qqx6qmklha-ew.a.run.app)
users-svc-url = [https://users-svc-qqx6qmklha-ew.a.run.app](https://users-svc-qqx6qmklha-ew.a.run.app)

백엔드 서비스 배포 및 준비 완료

Terraform The API Gateway

드디어 API 게이트웨이로 넘어갈 수 있게 되었습니다.불행하게도 이 글을 작성할 때 Terraform의 Google Cloud provider는 GCP API 스위치를 지원하지 않는 것 같아서 Terraform 설정에 포함할 수 없습니다.그러나 나는 이 글Terraform plan이 그 실현 가능성을 논의했기 때문에 장래에 지원을 추가할 수 있다는 것을 확실히 발견했다.따라서, 이 단계에서, 우리는 명령 gcloud 셸 명령으로 돌아갑니다

우리의 API 게이트웨이의 가장 중요한 구성 요소는 OpenAPI 규범이다:

는 우리의 API를 설명하고 API 게이트웨이가 특정한 HTTP 요청 경로를 우리의 백엔드 서비스로 라우팅하도록 지시합니다

우리는 지금 스위치를 배치할 수 있다:

$ # PROJECT\_ID and REGION hold the GCP project id and region
$ PROJECT\_ID=$PROJECT\_ID REGION=$REGION make deploy-api-gateway

그리고 우리 프린터 인터페이스 URL:

$ PROJECT\_ID=$PROJECT\_ID REGION=$REGION make get-gateway-url

출력은 다음과 같습니다.

[https://gateway-demo-4s0vqu9q.ew.gateway.dev](https://gateway-demo-4s0vqu9q.ew.gateway.dev)

API 게이트웨이/사용자 라우팅 테스트하기:

$ curl -s [https://gateway-demo-4s0vqu9q.ew.gateway.dev/users|jq](https://gateway-demo-4s0vqu9q.ew.gateway.dev/users%7Cjq)
[
  {
    "id": 1,
    "name": "Mike"
  },
  {
    "id": 2,
    "name": "John"
  }
]

현재/위치 노선:

$ curl -s [https://gateway-demo-4s0vqu9q.ew.gateway.dev/locations|jq](https://gateway-demo-4s0vqu9q.ew.gateway.dev/users%7Cjq)
[
  {
    "id": 1,
    "name": "London",
    "country": "UK"
  },
  {
    "id": 2,
    "name": "Paris",
    "country": "FR"
  }
]

그것이 작용했어, 우리는 완성했어.🎉🎊.

apply Conclusion

분명히 이 간단한 예시에서 우리는 이런 서비스가 제공할 수 있는 기능의 표면만 건드렸다.예를 들어 우리는 신분 검증이나 속도 제한 같은 더 높은 기능에 대해 토론하지 않았다.당신의 첫인상이 무엇인지 알게 해 보세요.전체 문서를 볼 수 있습니다