[DevOps] 왜 Docker는 컨테이너 빌드 도구 선택지에서 점점 배제될까?

최근 회사의 애플리케이션 배포 방식이 변경되면서 회사에서 맡고 있는 프로젝트 또한 별도의 배포 도구를 사용하지 않고, 형상 관리 시스템(Github, Gitlab)의 배포 도구를 사용하는 방식으로 마이그레이션 하게 되었습니다.

 

그런데, 마이그레이션하면서 사용하고 있는 CI/CD 도구가 Docker executor가 아닌 k8s executor를 사용하고 있었고, 여기서 애플리케이션을 컨테이너로 빌드할 때 사용하는 도구 또한 Docker가 아닌 Kaniko를 사용하고 있는 점을 알게 되었습니다.

 

 

Docker의 단점

가끔 Docker를 사용하면서 이런 생각이 종종 들었습니다.

 

• 컨테이너 이미지를 빌드하고 배포하기 위해, 굳이 Docker Engine을 설치해야 할까?
• Docker에서는 빌드만을 위한 SDK는 제공하지 않는걸까?

이런 생각을 하게 된 계기는 Github Actions, Jenkins를 이용해서 CI/CD 자동화를 하면서부터였습니다. Docker Engine 자체는 많은 권한을 요구하고, 설치 리소스가 크기 때문에 빌드만을 위한 도구라고 보기는 어려웠습니다. 따라서 늘상 인스턴스 비용이 들어가는 CI/CD 작업에는 너무 과도한 도구였죠.

 

 

Docker를 기본적으로 설치하게 되면 위와 같은 구조의 형태로 설치하게 됩니다. 기본적으로 Docker 명령을 수행하기 위한 프로그램인 Docker Client와 그 명령을 받아주는 Docker Host로 나누는데, 이 Docker Host에는 Docker Daemon이 포함되어 있으며 이는 빌드할 때 사용하는 것이 아닌 실제 컨테이너 이미지를 실행하는 역할을 합니다. 뿐만 아니라 Host OS에 대해 관리자 권한(Root Privileges)을 요구하여 실제 애플리케이션 구동을 하는 데 필요 이상의 권한을 추출하기 때문에 아무래도 빌드만을 위해 사용한다면 조금 꺼려지게 됩니다.

 

 

 

Docker 이외의 컨테이너 빌드 도구

그래서 몇 가지 조사를 해봤는데, 이미 다른 곳에서 이러한 단점을 캐치하고 다양한 컨테이너 빌드 도구를 개발해놓은 것이 여럿 있었습니다. 특히 쿠버네티스(Kubernetes)를 개발한 Google에서는 쿠버네티스의 컨테이너 환경을 Docker로 사용했을 때 추가 데몬 프로세스를 사용하고, 필요 이상의 권한을 사용하는 것에 대해 보안 취약점이 생길 것을 우려하였는지는 몰라도 쿠버네티스에서 Dockershim Container Runtime이 어느샌가 제거된 걸 알 수 있었습니다.

 

사실 컨테이너 기술이 각광받기 시작된 이후 가상머신과 동일하게 컨테이너 또한 업계 개방형 표준 기술 규약이 필요하다고 판단하여 생기게 된 것이 바로 OCI(Open Container Initiative)인데, 당시 Docker와 Redhat이 서로 다른 컨테이너 규격을 사용하게 되면서 서로가 자신들의 표준화를 주장하던 무렵 2016년 5월에 개최된 DockerCon 2015에서 이 표준이 선언되었고, 이후 2년 뒤에 OCI v1.0이 나오게 되었지요. 고로 우리는 굳이 Docker를 사용하지 않아도 컨테이너 빌드가 가능. 

(참조: https://opencontainers.org/ )

 

그렇다면 Docker 이외의 컨테이너 빌드 도구에는 어떤 것이 있을까요?

 

• Kaniko
• Buildkit
• Buildah
• Buildpack

Kaniko는 쿠버네티스 클러스터에서 내부의 Dockerfile을 이용해 컨테이너 이미지를 빌드하는 도구로 아직 구글의 정식 컨테이너 도구는 아니지만 GoogleContainerTools Github에 귀속되어 있는 빌드 도구입니다. Docker와 마찬가지로 root 권한을 필요로 하지만 Host OS가 가진 root 계정의 권한까지는 귀속하지 않아 보안 취약점 노출시 Host OS에는 영향을 받지 않는다는 것에 차이가 있습니다. (https://github.com/GoogleContainerTools/kaniko)

 

Buildkit은 mody에서 개발한 빌드 도구로 기존에는 Docker 팀에 있었다 분리되어, 컨테이너 빌드시 이미지 레이어 병렬 처리 기능을 제공하고, ARM 프로세서와 같은 이기종 하드웨어 컨테이너 이미지 빌드를 지원하는 빌드 도구입니다. 실제 Docker에서는 18.09버전에서 docker buildx 명령어로 제공하며 최근에는 Macbook M1과 같은 비 인텔 프로세서 컴퓨터에서 컨테이너 이미지를 빌드하기 위해 사용하는 빌드 도구입니다. (https://github.com/moby/buildkit)

 

Buildah는 보통 podman과 함께 사용하는 컨테이너 이미지 빌드 도구로 Rootless 버전을 지원하여 kaniko, buildkit과 마찬가지로 root 권한 없이 컨테이너 이미지를 빌드할 수 있지만 원격 캐시 저장 기능(Remote Caching)을 지원하지 않아 로컬 환경 외 CI/CD 환경에서는 사용하기 적합하지 않은 빌드 도구입니다. (https://github.com/containers/buildah)

 

Buildpack은 2011년 heroku가 처음 고안한 이후 Gitlab, Knative와 같은 PaaS에서 정식으로 채택한 빌드 도구로, 유일하게 Dockerfile과 같은 컨테이너 이미지 빌드용 파일 없이 애플리케이션 프로젝트의 설정 코드(requirements.txt, build.gradle.kts 등)만으로 이미지를 빌드할 수 있습니다. (https://github.com/buildpacks)

 

 

 

Docker가 배제되는 이유 그리고, 적합한 빌드 도구를 고르려면...

위에서 보다시피 여러 컨테이너 빌드 도구들이 있었고, 확실히 로컬에서 Docker를 설치해 컨테이너를 빌드해야 할 필요 없고, 그런 고민들이 이미 수없이 이뤄지고 그 해결책이 나온 상황입니다. 그렇다면 내가 운영하고 있는 시스템에서 배포를 위해 사용해야 할 컨테이너 빌드 도구를 선택해야 한다면 아래와 같은 조건을 따져볼 필요가 있을 것 같습니다.

 

• 배포하려는 서버의 프로세서 아키텍처가 멀티 아키텍처인가?
• 변경이 잦아 자주 빌드가 이뤄져 인스턴스 비용이 높은가?
• 배포 자동화를 위한 빌드라면, 자동화 하기 위한 서버의 OS가 무엇인가?

배포에는 여러가지 방법이 있을 것입니다. 개발자가 직접 자신의 PC에서 수동으로 컨테이너 이미지를 빌드하여 레지스트리에 푸시(push)한 다음 배포하는 방법도 있고, Github Actions 혹은 Gitlab Runner, Jenkins와 같은 외부 배포 서버를 이용하여 배포하는 방법도 있을 것입니다.

 

그러나 이런 다양한 환경에서 빌드만을 위해 컨테이너를 실행하기 위한 엔진, 데몬 프로세스 등을 설치해서 운영하는 것은 리소스상으로도 비효율적인데다 root 권한, Privileged 컨테이너를 생성하는 것은 만약 혹시라도 보안 취약점이 발생하여 시스템 전반에 피해를 발생시키는 원인이 되기 때문에 필요한 빌드 도구만 받을 수 있다면 그것이 최고의 선택일 것입니다.

 

일반적으로 로컬 PC에서 애플리케이션을 개발하고 컨테이너 이미지를 빌드하게 되면 자신의 머신에 레이어별로 캐시를 남기고 다음에 재빌드할 때 중복된 빌드 과정을 캐시에서 가져와 빌드 시간을 단축하게 됩니다. 이러한 캐시는 대부분의 빌드 도구에서 지원하지만 원격 서버에서 컨테이너 이미지를 빌드하는 경우 빌드 도구가 원격 캐시 저장 기능을 지원하는지를 검토해야 합니다.

 

형상에 소스 코드를 올린 뒤, 표준 환경에서 테스트를 마친 후 배포 이미지로 빌드하는 경우 위와 같이 별도의 서버를 사용하여 빌드할 수 있습니다. 가령 Github Actions 내지 Gitlab Runner의 경우, CI/CD용 서버가 존재하고 형상 관리 시스템에서 이벤트 발생시 컨테이너 이미지 빌드를 위한 인스턴스가 생성되는데, 이 때 인스턴스가 생성된 후에는 해당 인스턴스는 소멸되어 없어지기 때문에 메모리에 빌드 캐시를 주입하는 건 무의미하므로 별도의 원격 저장소에 빌드 캐시를 적재해야 합니다.

 

따라서 이런 경우 Buildah 빌드 도구는 적합하지 않으며 이 외에 애플리케이션이 여러 환경(다른 OS 혹은 다른 CPU 아키텍처)에서 빌드되어야 하는 경우 가장 적합한 빌드 도구는 Buildkit입니다.

 

 

 

마치며..

컨테이너 이미지를 빌드하는 데는 우리가 과거부터 보편적으로 사용해왔던 Docker가 주류라고 생각했지만 OCI 표준 규약이 생기면서 다양한 빌드 도구로도 컨테이너 이미지를 빌드하고 서버에 배포하는 것이 가능합니다.

 

특히 Github Actions와 같은 원격 서버에서 애플리케이션을 빌드하고 배포하는 경우 Docker를 사용하는 것이 불가능한 것은 아니지만 다양한 환경, 컴플라이언스 등을 고려해야 하는 경우가 있다면 위와 같은 여러 도구들을 잘 비교해서 쓰는 것이 현명할 것입니다. 만약, 이러한 케이스를 고려하고 있다면 이 글을 통해서 도움을 얻어가셨으면 합니다.