[GCP] Docker와 Artifact Registry

개요

GCP 환경에서 CI/CD를 구축하기 위해 도커 컨테이너 이미지가 저장될 저장소가 필요하다.

처음에는 Docker Hub를 통해 이 저장소를 구축할 생각이었으나, private/public 저장 공간을 생각 못 했다.

Docker Hub의 private version을 이용하려면 요금을 지불..해야한다..!

 

그런데 어차피 유료라면 Google의 Artifact Registry라는 저장소를 사용하는 게 낫다고 판단했다.

Google Cloud에 종속성이 높지만, 보안적인 측면에서 더 강한 장점이 있는 Google Artifact Registry를 사용하기 위해 해당 문서를 작성한다.

 

---

 1. Artifact Registry

Artifact Registry란?

컨테이너 이미지(docker)나 언어 패키지(Maven, npm 등)를 관리하는 저장소다. Google Cloud의 도구 및 런타임과 통합되어 있고 따라서 CI/CD 도구 (Google Cloud Build, Google Cloud Run 등) 간단하게 통합하여 자동화된 파이프라인을 구축할 수 있다. 

 

• 비공개 빌드 아티팩트 스토리지를 Google Cloud에 설정할 수 있다. IAM 역할 및 권한을 사용하여 사용자 접근을 제어할 수 있는 장점이 있다.
• Github, Bitbucket 등에 Trigger가 발생하면 이를 Google Cloud Build가 감지하고 Artifact Registry에 Docker Image를 빌드한다. 이를 통해 CI 과정을 자동화할 수 있다.
• 이런식으로 들어오고 나가는 컨테이너 이미지 취약점에 대해 감지하여 취약점 스캔 통계를 제공한다.

 

 

더 자세한 정보는 여기에서 볼 수 있다.

 

 

Artifact Registry  |  Google Cloud

 

 

---

 

1-1. Artifact Registry 설정

 

Google Cloud에서 Artifact Registry를 찾아 + 새 저장소 만들기를 하면 아래와 같은 내용을 작성하게 된다. 

(하단 이미지의 여기에 나온 것처럼 Project가 이미 생성되었음을 가정한다! 프로젝트가 없는 사람은 프로젝트부터 생성을 하고, 인스턴스 등 Artifact Registry 관련 세팅 전 해야할 일들이 있으니 기본적인 GCP 세팅이 완료되었음을 가정한다.)

 

형식: Docker
모드: 표준
위치유형: 리전
리전: us-west1(오리건)

 

• 나는 테스트용이라 vm 인스턴스를 생성할 때 무료로 제공되는 us-west1으로 설정했기에, 리전을 us-west1으로 설정하였다.
• 그런데 이렇게 하면 Artifact Registry같은 경우 가격 정책에 네트워크 이그레스까지 포함되므로.. 그냥 서울로 하는게 나은 것같다ㅠㅠ

 

 

• 고객 관리 암호화키(CMEK)는 Cloud KMS를 사용하여 관리하는 암호화키이다. 이를 사용하면 Cloud KMS와 관련한 추가 비용이 발생하지만 여러 장점이 있다.  자세한 정보는 여기서 확인 가능하다.
• 삭제 정책은 더 이상 필요하지 않은 아티팩트 버전을 자동으로 삭제하거나, 무기한 저장하는 아키팩트를 유지하기 위한 기준을 정의하는 것이다. 아티팩트 삭제에 대한 커밋을 남기기 전에 테스트 실행을 통해 새 정책에 대해 테스트를 진행할 수 있으므로, 안정성을 위해 테스트 실행을 선택하도록 한다.

 

 

1-2  Artifact Registry 저장소 인증

 

🚨 이 과정을 진행하기 전에 Google Cloud SDK 관련 설정이 되어있어야 한다. SDK 세팅 관련 자료 : Google Cloud SDK

[GCP] Google Cloud SDK 설치 및 세팅

 

 

 

Google Cloud의 Artifact Registry에서 설정 안내를 찾아보면 Docker를 구성하기 위한 명령어가 나온다. 해당 명령어를 VM 인스턴스 터미널에 입력하여 Registry 저장소를 연결하자.

 

 

 

 

 

root 권한으로 설정해야 하므로, 앞에 sudo를 붙여주었다. 

 

 

빨간 밑줄의 /home/{username}/.docker/config.json 파일에 저장소가 등록된다.

 

 

 

---

 

2-1. Docker Image Tag 

Artifact Registry의 저장소에 도커 이미지를 푸시하기 위한 도커 이미지 태깅 작업을 한다.

 

* Docker Image Tag?

말 그대로 도커 이미지에 Tag를 다는 것이다. 도커 이미지의 레이어 구조 때문에 이러한 Tag를 활용하여 관리하는 것인데, 여기서 설명은 생략한다. 일단 단순히 관리를 위해 Tag를 붙인다고 생각해두자. 형식은 docker tag (이미지:태그) (새로 명명할 이름:태그)이다.

 

😱 vm 인스턴스에 저장된 image가 없어서 docker hub에 저장된 미니 프로젝트를 가져와서 수행했다. 이 세팅을 다시 로컬환경에 해준 다음, 애플리케이션 코드를 도커 이미지화하고, 이걸 태그를 달아서 서버에 push해야할 것같은데.... 이부분은 다시 점검을 해봐야한다..

 

 

docker tag 1:2 us-west1-docker.pkg.dev/3/4

 

• 1: docker images 명령어를 통해 확인 가능한 REPOSITORY명
• 2: docker images 명령어를 통해 확인 가능한 TAG명
• 3: GCP Project ID
• 4: Artifact Registry에서 확인가능한 이미지명 

 

2-2. Docker Image Push

docker push LOCATION-docker.pkg.dev/PROJECT-ID/REPOSITORY/IMAGE:TAG

 

 

푸시를 할 때는 꼭 위와 같은 코드 규칙을 지켜줘야한다. GCP에서 이를 잘확인하고, push하도록 하자..!

 

 

이렇게 푸시한 이미지를 docker 명령어를 통해 VM 인스턴스에서 컨테이너화하고, 실행하면 서버에 배포가 잘 되는 걸 확인할 수 있다. 

또 cloud build와 함께 세팅하여 CI도 구축할 수 있다. Google의 Artifact Registry는 다양한 파일 종류를 보관하여 활용하기에 좋다.