프로젝트를 진행하면서, 초기단계 수정과 반복이 계속되고 있습니다.
팀원 모두가 클라우드에 접근하면 물론 베스트이겠지만, 팀원이 클라우드 환경에 익숙하지 않아, 이를 제가 담당하고 있습니다.
계속해서 수정사항 및 업그레이드 된 버전을 팀원들은 제공해주었고,
저는 이럴때 마다 업데이트 버전 배포가 귀찮아진 나머지, 이를 자동화 해보자고 생각했습니다.
GCP CLI를 사용하는 이유
GCP에 익숙하신 분들은, GCP Cloud Shell 을 사용해 봤을 겁니다.
저도 이를 통해서 클라우드를 자주 사용했었는데요, 이를 통해 crontab을 시도하다가 한가지를 알게 되었습니다.
GCP Cloud Shell에 설명을 읽어보면 대략 20분 정도면 연결이 끊긴다고 하더라구요.
즉, GCP Cloud Shell 에서 crontab을 구현해봤자, 20분뒤 터미널이 종료된다는 말입니다.
이는, 제가 구현하고자 하는, 자동화 배포라인을 사용할 수 없는 환경이고, 찾다보니 GCP CLI를 사용하면 되겠다고 생각했습니다.
GCP CLI 설치하기
GCP CLI는 간단하게 말하면, 이전에 Cloud shell 을 통해 했던 작업을 Local PC에서 할 수 있게 해주는 툴입니다.
GCP SDK 설치하는 방법은 Google Cloud 에서 제공해주는 Google Cloud CLI 설치 를 통해 설치하였습니다.
각자 본인 플랫폼에 맞는 패키지를 설치하고 압축을 풀어줍니다.
이후 docs에 나와있는 대로, sh파일을 실행해주고 init을 진행해 줍니다.
./google-cloud-sdk/install.sh
gcloud init
init 진행 시, 몇가지 입력해줘야 하는 것들이 있더라구요. 본인이 사용하는 GCP 아이디 및, 컨트롤할 리전 등 안내에 따라 진행해 주시면 간단하게 사용 가능합니다.
GCP CLI를 통해 GKE 작동하기
제가 사용하는 환경은 GCP Kubernetes Engine 입니다. 구축해둔 노드를 제 로컬 pc를 통해서 제어하기 위해서는 다음 명령어가 필요합니다.
gcloud container clusters get-credentials [클러스터 이름] --zone [지역] --project [프로젝트 이름]
많은 분들이 아시겠지만, 이는 GCP에서 Cloud Shell을 통해 노드를 연결하는 코드와 동일 합니다.
해당 코드를 복사 붙여넣기로 본인 Local PC 터미널에서 실행해 줍니다.
☁ ~ kubectl get nodes
NAME STATUS ROLES AGE VERSION
노드이름1 Ready <none> 8d v1.21.6-gke.1503
노드이름2 Ready <none> 8d v1.21.6-gke.1503
노드이름3 Ready <none> 8d v1.21.6-gke.1503
그 뒤로 본인의 환경에서 노드가 잘 세팅됬는지 확인해봅니다.
제가 사용중인 노드가 잘 세팅되어 있음을 알 수 있습니다.
이제 제 로컬환경에서 GCP GKE를 컨트롤할 수 있는 환경이 구축된겁니다.
bash 코드 작성하기
이제 제가 하고자하는 내용의 bash를 정의해 줍니다.
저같은 경우는, java spring boot를 통해서 프로젝트를 진행 중인데, 이를 깃헙 코드로 부터, pull 해오고, build 및 이미지화 하는 과정을 bash 코드로 정의했습니다.
아래의 코드를 통해, 이미지를 도커허브에 까지 push 할 수 있습니다.
# 사용한 bash 코드
rm -rf Semogong
git clone https://github.com/Sejong-Talk-With/Semogong
git pull
cd Semogong
rm -rf src/test
gradle build
cp build/libs/semogong-0.0.1-SNAPSHOT.jar target/
docker build --tag wjdqlsdlsp/semogong:latest .
# 백업관리를위해 도커허브로 전송 (생략가능)
images_id=$(docker images -qa wjdqlsdlsp/semogong:latest)
docker tag $images_id wjdqlsdlsp/semogong:latest
docker push wjdqlsdlsp/semogong:latest
애플 M1칩 노트북 사용자
docker build --platform amd64 --build-arg DEPENDENCY=build/dependency -t wjdqlsdlsp/semogong:$1 .
이것 때매 한참 고생했네요, 분명 로컬환경에서는 잘작동하는데, 클라우드에서 작동하려니 작동이 안되서 많이 찾았습니다.
그러던 중 로그를 보니, 운영체제 문제가 있더라구요.
M1칩에서 생성한 이미지가 Ubuntu에서 pull해서 사용하려니 작동안하는 오류가 발생했습니다.
이를 해결하기위해서, –platform amd64를 추가해줬습니다.
rolling update
쿠버네티스는 무중단 배포라는 엄청난 기능이 있는 오케스트레이션 툴입니다.
이전에 deployment로 배포한 내용에 업데이트된 이미지로 바꾸는 과정입니다.
명령어는 아래와 같습니다.
# rolling update
kubectl set image deployment.v1.apps/[deployment 이름] [컨테이너 이름]=[이미지]:[버전]
# 사용한 infra 명령어
kubectl set image deployment.v1.apps/semogong semogong-container=wjdqlsdlsp/semogong:latest
해당 명령어를 입력하면 쿠버네티스가 새로운 이미지로 배포를 합니다.
crontab
위의 과정으로도 충분하지만, 제가 하고 싶은건 자동으로 배포를 해주는 환경을 구축하는 것입니다.
스케줄러는 다양하게 있지만, 저는 가장 간단한 crontab방식을 사용하고자 합니다.
위에서 사용한 rolling update과정도 bash코드로 묶어서 한번에 실행되게 변경합니다.
crontab -e
위의 명령어를 통해 crontab을 정의해줍니다.
저같은 경우는 0 * * * * bash [bash파일] 를 정의해서 1시간에 한번씩 해당 과정이 진행되게 하면 되겠네요.
crontab -l
를 통해서 crontab에 잘 저장이됬는지 확인해줍니다.
이제 일정시간마다, build및 이미지화, push, rolling update과정 까지 진행됨을 알 수 있습니다.
끄적끄적
실제로 구현해보니 나름 재미있고 배우는 과정이 의미는 있지만, 실사용성은 떨어지는 것 같습니다.
문제점
- (저같은) 노트북 사용자는 배터리가 아쉽다. ( 도커를 계속 켜놔서 그런가.. ? )
- 오류 대처가 안된다. ( 이래서 배포할때, 사람들이 기도하나봐요 )
CI/CD
이제 다음단계는 CI/CD 파이프라인을 통해 위의 진행했던 과정들을 진행하는 것입니다.