GKE 기반으로 운영 환경이 바뀌면서 로컬 도커 환경 테스트에 한계가 생겨 개인 GCP 프로젝트에 클라우드 테스트 환경을 구축해 보았다.

나한테 필요한 옵션은

• Github과 클라우드 환경을 연동할 것
• 테스트 목적에 따라 배포 환경을 유지하거나 초기화할수 있어야 함
• 비용 효율적일 것 : build, deploy, run 리소스 및 실행시간 최적화
• 확장이 자유로울 것 : 향후 Airflow 외의 툴이 추가될 수 있음

대략적인 작업 순서는 아래와 같다.

1. 컨테이너 이미지 빌드 - 작업에 사용할 패키지를 매번 설치하지 않도록 이미지 생성
   1.1 빌드 트리거
   1.2 빌드 최적화
2. Artifact Registry에 저장된 image를 Helm 패키지를 이용해 GKE에 배포
   2.1 helm 차트 설정
   2.2 로드밸런스 설정: airflow 웹서버
3. 필요에 따라 컨테이너, 패키지 커스텀

** 사전준비 - quota 신청

GCP 콘솔 메뉴에서 IAM 및 관리자 > 할당량 메뉴에서 내가 사용할 SaaS에 할당된 quota 개수를 확인할 수 있다.
나같은 경우 프로젝트를 미국 리전에 생성해서 일부 서비스의 asia-northeast 리전 할당량이 0인 상태였다.
우측 상단의 할당량 수정 메뉴에서 수정요청을 보낼 수 있다.

• 실제로 반영되는데 2~5일정도가 소요된다
• 웹 콘솔에서 수정요청을 보낸 후 GCP project admin 계정으로 확인 메일이 오기 때문에 승인해줘야 한다.
• 이후 구글 운영팀에서 정보 확인을 위한 추가 메일이 올 수 있다.

위 단계에서 답변이 지연될수록 소요시간도 늘어나니 최대한 빠르게 답변하자.

---

트리거를 이용한 컨테이너 이미지 자동 빌드

먼저 cloud build와 깃헙 레포지토리를 연동시키자.
위 링크 내용대로 진행하면 트리거를 설정할 수 있다.

1. Cloud Build API 활성화
   API 활성화 링크 (이미 활성화가 되어있다면 skip)

2. Cloud build > trigger 생성
   트리거를 생성할 때 Cloud build 저장소 유형(1세대, 2세대 중 택일)을 골라야 한다.
   2세대가 1세대의 상위호환이 아니며, 지원하는 VCS 종류가 상이하므로 자신에게 필요한 유형을 선택하자.(Cloud build 저장소 1세대, 2세대)

   

   소스로 github을 사용하므로 2세대를 기준으로 환경을 설정해보자.
   (Secret Manager API 활성화 필요)

   이름 : airflow-gke-dev
   리전 : asia-northeast3
   이벤트 : 브랜치로 푸시
   소스 : 2세대
   저장소 : bamiar-airflow-gke
   유형 : Cloud Build 구성 파일(YAML)
   위치 : 저장소 bamiar-airflow-gke (GitHub)
   cloud 
   

트리거를 등록한 후 깃헙 마스터 브랜치에 푸쉬하면 Artifact Registry에 airflow-gke컨테이너 이미지가 생성된다.

---

수동 빌드

위의 이미지 2개중 base 태그가 붙은 이미지는 깃 push-트리거로 자동생성된 이미지이고, base 태그가 없는 것은 터미널에서 아래 커맨드로 생성한 이미지이다

PROJECT_ID=inspiring-rite-199401
REGISTRY=asia-northeast3-docker.pkg.dev
REPO=container-registry
APP=airflow-gke
build: base

base:
	gcloud builds submit --config=base.yaml --region=asia-northeast3 --substitutions=_PROJECT_ID="$(PROJECT_ID)",_REGISTRY="$(REGISTRY)",_REPO="$(REPO)",_APP="$(APP)" --gcs-log-dir=gs://inspiring-rite-199401_cloudbuild/airflow-gke_cloudbuild_log/

클라우드 빌드로 배포하지 않고 따로 테스트해야할 경우, 이런식으로 Makefile을 작성해 터미널에서 실행해주면 배포 파이프라인에 영향 주지 않고 빌드만 테스트할 수 있다.

로그 확인

Cloud build > 기록 메뉴에서 빌드 기록을 확인할 수 있다.