컨테이너 이미지와 레지스트리
컨테이너 이미지는 애플리케이션 자신 뿐만 아니라 실행에 필요한 모든 것들을 담고 있습니다. OS, DBMS, 웹서버 등 시스템 상에서 이용되는 대부분의 리소스를 이미지로 생성할 수 있으며, 컨테이너를 구동하는 데에 핵심적인 역할을 수행합니다. 과거 우리가 CD라고 하는 표준화된 물리 저장장치를 통해 프로그램을 배포하고 사용했었던 것 기억 나시나요? 이미지 역시 물리적으로 존재하지는 않지만 표준화된 방식에 따라 전 세계의 서비스에서 활용되고 있습니다.
이 그림 전체를 컴퓨터라고 생각해봅시다. CPU, 저장장치, LAN 카드, 그래픽 카드 등의 하드웨어가 컴퓨터를 물리적으로 구성하고 있습니다. 여기에 OS를 기반으로 하여 컨테이너 런타임이 구동되고, 컨테이너는 바로 이 런타임의 통제에 의해 움직입니다.
언뜻 보면 VM을 구동하는 것과 비슷해보이지만 컨테이너에는 기본적으로 OS가 없습니다. 어플리케이션을 구동하기 위해 필요한 라이브러리만을 개별적으로 가지고 있을 뿐입니다. OS를 실행할 필요가 없기 때문에 부하가 적고 구동되는 속도 역시 빠릅니다. 또한, 어플리케이션은 각자 독립된 영역을 보장받기 때문에 런타임에서 발생하는 충돌을 피할 수 있습니다.
컨테이너 레지스트리는 컨테이너 이미지들을 모아 놓고 필요할 때 사용할 수 있도록 구축한 저장소 입니다. 이미지를 빌드하거나 컨테이너를 실행할 수 있었던 것은 이를 실행할 수 있는 이미지를 레지스트리에서 가져와 사용했기 때문이죠.
레지스트리의 역할과 구성을 파악하기 전에 대표적인 컨테이너 플랫폼인 도커를 정의하는 문장을 살펴보겠습니다.
💡 도커는 어플리케이션 및 실행 환경을 정의한 이미지를 생성/공유함과 동시에, 이를 이용하여 컨테이너를 작동할 수 있도록 하는 플랫폼이다.
즉, 컨테이너 실행, 이미지 빌드와 더불어 레지스트리라는 저장소를 통해 이미지를 공유하는 도커는 어플리케이션이 작성, 빌드되고 배포되는 전 과정에 관여한다는 것을 알 수 있습니다.
도커의 기능을 한 눈에 정리할 수 있도록 그림으로 나타내 보았습니다. Dockerfile을 통해 빌드된 이미지가 컨테이너를 실행하는 데에 이용되기도 하고, 혹은 레지스트리에 저장되어 여러 사람이 사용할 수 있도록 공개되기도 하죠. 이를 각각 Building, Running, Shipping(Sharing) 이라는 단어로 표현합니다.
컨테이너 이미지가 공유되는 레지스트리를 크게 3가지로 구분해보면, 일반적으로 이미지를 받아오는 도커 社의 도커 허브, 사용자가 직접 컨테이너에 구축한 로컬 레지스트리, 클라우드 사업자에게 비용을 지불하고 사용하는 컨테이너 레지스트리가 있습니다.
이미지를 파일 형식으로도 저장 가능한데 비용을 지불하면서 레지스트리를 사용하는 걸까요? 여기에는 여러 이유가 있습니다.
첫 번째는 보안 문제입니다. 이미지 내부에 보안상 중요한 파일이나 내용이 필요한 경우에는 더욱 엄격히 관리할 필요가 있습니다. 이미지 자체도 암호화 되어야 하고 레지스트리에 접근할 수 있는 권한도 통제해야 하죠. 이런 일련의 것들을 클라우드 사업자에서는 IAM(Identity and Access Management) 라는 형태로 제공하고 있습니다. 더불어 이미지에 대하여 고도화된 암호화를 적용함으로써 보안 사고를 예방하기도 합니다.
두 번째는 배포 파이프라인 효율화입니다. 위 그림에서 보다시피 레지스트리에 저장된 이미지는 단순히 저장에서 끝나는 것이 아니라 CI/CD 라는 과정까지 연속적으로 활용됩니다. CI/CD 용어에 대해서는 하단에 부연하였습니다. 일반적으로 컨테이너를 기반으로 하는 CI/CD 파이프라인을 구축하는 데에는 적지 않은 공수가 들지만, 클라우드타입은 자체적으로 Github Actions 연동 기능을 제공하여 이미지 빌드/배포까지의 파이프라인을 손쉽게 구축할 수 있습니다.
💡 CI(Continuous Integration) : 지속적 통합
빌드/테스트가 자동으로 수행된 이후 개발자의 수정 사항이 중앙 저장소에 머지되는 것 까지의 과정 일련의 자동화 과정 및 개발 문화가 포괄
💡 CD(Continuous Delivery) : 지속적 전달
운영 환경에 배포할 소스코드가 자동으로 세팅 빌드 이후의 변경 사항을 테스트 및 운영 서버에 자동으로 배포 필요에 따라 테스트 서버를 동적으로 생성할 수 있음
다음 이어지는 글에서 CI/CD 개념을 좀 더 살펴보고 Cloudtype과 Github Actions를 활용한 CI/CD 파이프라인 구축 실습을 위한 과정을 다루도록 하겠습니다 😀
