archived-project
(GCP) Container Registry to Artifact Registry Migration
Index
- Introduction
- Problem
- Artifact Registry
- Hands-On
- Conclusion
Introduction
안녕하세요 Yureutae입니다. 오늘은 GCP에서 Artifact Registry 활성화 및 기존 Container Registry 서비스 Migration 등에 대해서 설명하고 해결과정을 보여드리려 합니다.
전 현재 GCP에서 Serverless 서비스인
Cloud Run 의 Tasks를 사용 중이며, Cloud Scheduler를 통해 매 15분마다 Cloud Run 에 Trigger를 날려 Container Registry에 사전 생성해둔 Docker Image를 가져와 Application을 실행하게 만들었습니다. 해당 Application은 학과 공지 페이지를 읽어 Cloud Storage에 저장하고 Slack으로 과동아리원에게 메시지를 날려주는 서비스이며 2년 가까이 안정적으로 운영 중입니다.yureutaejin/Serverless-notification-Slackbot


그런데 약 한달 전부터 linked-in에서 여러 엔지니어 분들이 gcr.io Artifact Registry 이관 이슈를 업데이트하기 시작했던 것 같습니다. 구글에서도 이메일이 날라왔는데, 굳이 업데이트할 필요가 없는 서비스고 귀찮아서 냅뒀었습니다.
Problem
갑자기 이런 이메일이 날라오더니
Action Required 라고 제목을 붙여놓더군요. 대부분의 GCP 이메일은 Action이 필요없다고 하는데, 오늘은 달라서 좀 읽어보니까 대충 5월까지는 Registry 이슈를 처리해야했습니다.
요약하자면 “
Container Registry 서비스가 Deprecated 될 예정이니까 Artifact Registry 서비스로 Migration해라” 입니다.Vertex AI 때도 그렇고, 고객입장에서 좀 이런건 자동으로 해주면 좋겠습니다;;;

Artifact Registry

Artifact Registry는
- Container Image 뿐만 아니라, Maven, npm, Python, apt, yum, Go 등 General한 언어와 연관된 Package를 포함한 여러 ‘Artifact’ 형식을 저장할 수 있습니다.
gcr.io단일 호스트 방식에서 →LOCATION-docker.pkg.dev/PROJECT-ID/REPOSITORY방식으로 전환함으로써, 멀티 리전 호스트로 대응이 가능해졌습니다. (리전 별로 세분화된 권한, 버전 관리 등등이 가능)
- Repository 단에서 별도 권한 구분이 불가능했던 Container Registry와 달리, Reader, Writer, Administrator 등의 권한 구분이 가능해졌습니다.
- Cloud Storage 사용량이 아닌, 자체가격 책정이 됩니다.
등에서 Container Registry와 차이가 생깁니다.
Hands-On
여튼, Docker Image 저장소인 Container Registry 서비스를 Artifact Registry로 Migration 해보겠습니다. 그냥 명령어만 몇번 쳐주면 되긴한데, 로컬 gcloud console에서 context switching에서 뭔가 문제가 있는지 잘 안 되서 전 웹상 console에서 해결해줬습니다.
- Artifact Registry 활성화
- Artifact Registry API를 본인의 GCP 내 프로젝트에서 활성화시켜주면 됩니다.
- Create Repository
- 옵션을 지정해서 Repository를 생성해주면 됩니다. 전 직접 이름 할당해서 생성했는데, 아마 기존 Container Registry가 있다면 원클릭으로 Multi Region gcr.io를 생성해줍니다.

- 아래처럼 생성되었다면, Console을 통해 작업을 시작합니다.
go installgithub.com/google/go-containerregistry/cmd/gcrane@latest- IAM 권한 부여 (프로젝트 리소스 관리 페이지에서 Project ID, Project Number 확인 가능합니다.)
gcloud projects add-iam-policy-bindingProject-Id \
--member='serviceAccount:service-Project-Number@gcp-sa-artifactregistry.iam.gserviceaccount.com' \
--role='roles/storage.objectViewer'
- gcrane을 통해서 Container Registry에서 이미지를 추출하고 Artifact화하여 생성한 Repository 들에 저장합니다. (Repository 생성 수만큼 아래 명령어를 변경해서 실행합니다.)
gcrane cp -r gcr.io/Project-Id us-docker.pkg.dev/Project-Id/{Repository Name}
- 여기까지 했다면, 이제 Artifact Registry는 준비가 끝났습니다…만 아직 Container Registry의 gcr.io로 트래픽이 가고 있기 때문에 리디렉션을 해줘야합니다.
- Artifact Registry 및 Storage Administrator 권한 부여
gcloud projects add-iam-policy-bindingProject-Id \
--member='user:{gcp user email}' \
--role='roles/artifactregistry.admin'
gcloud projects add-iam-policy-bindingProject-Id \
--member='user:{gcp user email}' \
--role='roles/storage.admin'- 아래 링크로 들어가면 Artifact Registry 라우팅을 허용할 수 있게 됩니다.
모든 과정을 완료하면 각 Repository 내 프로젝트에 이미지 복사가 된 것을 확인할 수 있고, 아래 이미지처럼
*.gcr.io 트래픽이 모두 Artifact Registry로 향하는 것을 확인할 수 있습니다.
Conclusion

다시 아래 이미지처럼 정상적으로 Cloud Run Tasks가 동작함을 확인했습니다. Artifact Registry로 정상적으로 Migration 된 것 같네요.
기존 Container Registry에 비해 IAM 및 Region 등에 대해서 세분화가 강해졌다는 것을 작업 중에도 강하게 느꼈습니다. 규모가 작은 곳에서는 귀찮을 수도 있지만 큰 곳에서는 유용하게 쓰일 것 같습니다. (DevOps는 Task가 또 추가된 것 같은…)


