도커 레지스트리는 도커 이미지들을 모아 놓고 필요할 때 사용할 수 있도록 구축한 저장소 입니다. 도커 이미지를 빌드하거나 컨테이너를 실행할 수 있었던 것도 레지스트리의 이미지를 사용했기 때문이죠.
도커를 처음으로 소개할 때, 제가 도커라는 플랫폼을 정의했던 문장이 다음과 같습니다.
<aside> 💡 도커는 어플리케이션 및 실행 환경을 정의한 이미지를 생성/공유함과 동시에, 이를 이용하여 컨테이너를 작동할 수 있도록 하는 플랫폼이다.
</aside>
컨테이너 실행, 이미지 빌드를 앞 부분에서 다루었다면 이번 시간에는 레지스트리를 통하여 이미지를 공유하는 여러 가지 방법과 이용 가능한 플랫폼 등을 확인해보겠습니다.
도커의 기능을 한 눈에 정리할 수 있도록 그림으로 나타내 보았습니다. Dockerfile을 통해 빌드된 이미지가 컨테이너를 실행하는 데에 이용되기도 하고, 혹은 레지스트리에 저장되어 여러 사람이 사용할 수 있도록 공개되기도 하죠. 이를 각각 Building, Running, Shipping(Sharing) 이라는 단어로 표현합니다.
도커 이미지가 공유되는 레지스트리를 크게 3가지로 구분해보면, 디폴트로 이미지를 받아오는 도커 社의 도커 허브, 사용자가 직접 컨테이너에 구축한 로컬 레지스트리, 클라우드 사업자에서 제공하는 컨테이너 레지스트리가 있습니다. 뒤에 이어지는 내용에서 이 3가지를 모두 다룰 예정입니다.
본격적으로 레지스트리 구축을 실습하기 전에 레지스트리를 사용하는 목적에 대해 짚고 넘어가도록 하겠습니다. 이미지를 파일 형식으로도 저장 가능한데 왜 굳이 비용을 지불하면서 레지스트리를 사용하는 걸까요? 여기에는 여러 이유가 있습니다.
첫 번째는 보안 문제입니다. 이미지 내부에 보안상 중요한 파일이나 내용이 필요한 경우에는 더욱 엄격히 관리할 필요가 있습니다. 이미지 자체도 암호화 되어야 하고 레지스트리에 접근할 수 있는 권한도 통제해야 하죠. 이런 일련의 것들을 클라우드 사업자에서는 IAM(Identity and Access Management) 라는 형태로 제공하고 있습니다.
두 번째는 배포 파이프라인 효율화입니다. 위 그림에서 보다시피 레지스트리에 저장된 이미지는 단순히 저장에서 끝나는 것이 아니라 CI/CD 라는 과정까지 연속적으로 활용됩니다. CI/CD 용어에 대해서는 하단에 부연하였습니다.
<aside> 💡 CI(Continuous Integration) : 지속적 통합 빌드/테스트가 자동으로 수행된 이후 개발자의 수정 사항이 중앙 저장소에 머지되는 것 까지의 과정 일련의 자동화 과정 및 개발 문화가 포괄
</aside>
<aside> 💡 CD(Continuous Delivery) : 지속적 전달 운영 환경에 배포할 소스코드가 자동으로 세팅 빌드 이후의 변경 사항을 테스트 및 운영 서버에 자동으로 배포 필요에 따라 테스트 서버를 동적으로 생성할 수 있음
</aside>
도커 허브는 도커에서 디폴트로 참조하는 레지스트리로서, 각종 공식 이미지를 손쉽게 사용할 수 있도록 구성되어 있습니다. 또한 무료 계정을 생성하여 개인이 빌드한 이미지도 공개할 수 있죠. 실습을 진행하기 전에 계정 생성을 먼저 진행해야 합니다.
1) 저장소 만들기
계정 생성이 완료되면 'Create Repository' 버튼을 눌러 저장소를 만들어 줍니다.