[GCP] GCR과 GAR의 차이점

베하~! 안녕하세요 BTC금쪽상담소의 오은영석사와 금쪽이 입니다~

무더운 여름 별탈없이 지내셨나요?? 무척이나 더운 날씨에 건강 관리 유의하시고 항상 수분 섭취 잘 챙기실 바랍니다.

여러분 그거 아시나요? 강아지는 키가 작기 때문에 지면에서 부터 발생하는 복사열에 의해 사람이 35도 정도의 더위를 느낀다면 강아지는 50도의 열기를 느낀다고 해요.

여름엔 밤에 산책을 데리고 다니시는걸 추천드릴께요!

 

자 그럼 잡담은 이쯤에서 마무리하고 오늘은 GCP의 서비스인 Google Container Registry와 Google Artifact Registry에 대해 알아보도록 하겠습니다.

 

Container Registry

Container Registry는 Google Cloud에 비공개 컨테이너 이미지를 저장하기 위한 기존 서비스입니다.

많은 사람이 공개 Docker 이미지를 저장하는 중앙 레지스트리로 Docker Hub를 사용하지만, 이미지 액세스를 제어하려면 Artifact Registry 또는 Container Registry 같은 비공개 레지스트리를 사용해야 합니다.

보안 HTTPS 엔드포인트를 통해 레지스트리에 액세스하여 모든 시스템, VM 인스턴스 또는 자체 하드웨어로 이미지를 내보내고 가져오며 관리할 수 있습니다.

• 레지스트리를 Google Cloud CI/CD 서비스 또는 기존 CI/CD 도구와 통합합니다.
  • Cloud Build의 컨테이너 이미지를 저장합니다.
  • Google Kubernetes Engine, Cloud Run, Compute Engine, App Engine 가변형 환경을 포함하여 컨테이너 이미지를 Google Cloud 런타임에 배포합니다.
  • ID 및 액세스 관리는 일관된 사용자 인증 정보 및 액세스 제어를 제공합니다.
• 컨테이너 소프트웨어 공급망을 보호합니다.
  • Artifact Analysis를 사용하여 컨테이너 메타데이터를 관리하고 컨테이너 취약점을 스캔합니다.
  • Binary Authorization으로 배포 정책을 적용합니다.
• VPC 서비스 제어 보안 경계에서 레지스트리를 보호합니다.

Container Registry를 사용하여 Google Cloud 프로젝트마다 멀티 리전 호스트를 최대 4개까지 만들 수 있습니다. 별도의 액세스 정책으로 개별 저장소를 만들거나 멀티 리전 대신 리전에 이미지를 저장하려면 대신 Artifact Registry를 사용합니다.

Container Registry의 레지스트리는 호스트와 프로젝트 ID를 기준으로 명명됩니다. 이미지 작업(내보내기, 가져오기, 삭제 등)을 하려면, 다음 형식을 이용해 이미지를 식별해야 합니다.

HOSTNAME/PROJECT-ID/IMAGE:TAG

각 항목의 의미는 다음과 같습니다.

• HOSTNAME은 이미지가 저장된 위치
• PROJECT-ID는 Google Cloud 콘솔 프로젝트 ID입니다.
• IMAGE는 이미지의 이름입니다.
• :TAG 또는 @IMAGE-DIGEST를 끝에 추가하면 이미지의 특정 버전을 구별할 수 있지만 선택사항입니다.

이러한 Registry 구성과 Image 관리를 통해 GCP 환경에서의 Container Image 관리를 손쉽게 할 수 있게됩니다.

하지만, GCR (Google Container Registry) 서비스는 지원이 중단 되었기 때문에, GCP에서는 GAR 사용을 권장하고 있습니다. 따라서 이전 시간에 함께 이야기 한 이미지 마이그레이션을 통해 기존 이미지를 Artifact Registry로 이동하고 gcr.io 도메인을 사용하여 계속 액세스할 수 있습니다.

그렇다면 GAR (Google Artifact Registry)는 무엇일까요?

 

Artifact Registry

Artifact Registry는 패키지 및 Docker 컨테이너 이미지를 저장하고 관리하기 위한 단일 위치를 제공합니다. 다음과 같은 작업을 할 수 있습니다.

• Artifact Registry를 Google Cloud CI/CD 서비스 또는 기존 CI/CD 도구와 통합합니다.
  • Cloud Build의 아티팩트를 저장합니다.
  • Google Kubernetes Engine, Cloud Run, Compute Engine, App Engine 가변형 환경을 포함하여 아티팩트를 Google Cloud 런타임에 배포합니다.
  • Identity and Access Management는 일관된 사용자 인증 정보 및 액세스 제어를 제공합니다.
• 소프트웨어 공급망을 보호합니다.
  • Artifact Analysis를 사용하여 컨테이너 메타데이터를 관리하고 컨테이너 취약점을 스캔합니다.
  • Binary Authorization으로 배포 정책을 적용합니다.
• VPC 서비스 제어 보안 경계에서 저장소를 보호합니다.
• 단일 Google Cloud 프로젝트 내에 여러 리전 저장소를 만듭니다. 팀 또는 개발 단계별로 이미지를 그룹화하고 저장소 수준에서 액세스를 제어합니다.

Artifact Registry는 Cloud Build와 기타 지속적 배포 및 지속적 통합 시스템과 통합되어 빌드의 패키지를 저장합니다. 빌드 및 배포에 사용하는 신뢰할 수 있는 종속 항목을 저장할 수도 있습니다.

종속 항목 관리

소프트웨어 공급망 보호에는 특정 도구를 사용하는 것 이상의 의미가 있습니다. 소프트웨어를 개발, 빌드, 실행하기 위해 사용하는 프로세스 및 관행 역시 소프트웨어의 무결성에 영향을 미칩니다.

Software Delivery Shield

Software Delivery Shield는 완전 관리형 엔드 투 엔드 소프트웨어 공급망 보안 솔루션입니다. 이는 개발자, DevOps, 보안팀이 소프트웨어 공급망의 보안 상태를 개선하는 데 사용할 수 있는 포괄적이고 모듈화된 기능 및 도구 모음을 Google Cloud 서비스 전반에서 제공합니다.

Software Delivery Shield의 일부인 Artifact Registry는 다음을 제공합니다.

• 관리 수준을 높이고 취약점, 빌드 출처 및 기타 종속 항목 정보를 검색할 수 있도록 업스트림 공개 소스에서 종속 항목을 캐시하기 위한 원격 저장소를 제공합니다.
• 단일 엔드포인트 뒤에서 원격 및 비공개 저장소를 그룹화하기 위한 가상 저장소를 제공합니다. 아티팩트를 다운로드하거나 설치할 때 검색 순서를 제어하기 위해 각 저장소에서 우선순위를 설정합니다.

Cloud Build, Cloud Run, GKE 내에서 보안 상태, 빌드 아티팩트 및 Google Cloud 콘솔 대시보드의 종속 항목에 대해 보안 정보를 확인할 수 있습니다.

 

즉, GCR보다 훨씬 더 많은 기능을 제공하면서 Google Cloud 환경에 적합한 Registry 서비스입니다.

 

클라우드는 CSP에서 제공하는 서비스와 관리형태에 따라 동일한 기능을 하지만, 서비스의 종류를 고를 필요가 있습니다.

서비스의 지원유무, 보안성 검토등을 통해 올바른 클라우드 서비스를 사용하여 안전하고 효율적인 클라우드 환경을 구축하시길 바랍니다!

 

지금까지 BTC금쪽상담소였습니다! 감사합니다!

 

출처 :

https://cloud.google.com/container-registry/docs/overview?hl=ko 

https://cloud.google.com/artifact-registry/docs/overview?hl=ko