과거에는 어떤 오픈소스 소프트웨어의 예제코드를 돌리기까지 환경을 구축하는 문서들이 제공되었다. 인터넷에는 설치 명령어가 나열된 문서나 셸 스크립트를 심심찮게 찾을 수 있었다. 이 글에서 소개할 도커라는 방법이 제안되기 전에는 별다른 뾰족한 수가 없었던 것이다.
“우선 apt-get xxx 를 실행하세요. 그 다음에는 이제 ssh 포트를 열어주세요. 그리고 이걸 실행해 주세요…. 그 다음은…. 잘 안되면 처음부터 다시 하세요!”
예제코드를 비롯해 모종의 어플리케이션을 작동시키기 위해 선행되는 과정 전반을 프로비저닝이라고 한다(참고1). 도커파일 Dockerfile은 쉽게 말해 프로비저닝까지 필요한 과정들을 적어 두는 파일이다. 예를 들어 FROM 키워드로 운영체제를 정의하고, RUN키워드로 설치해야 하는 패키지들을 정의해둘 수 있다. 이렇게 잘 작성된 도커파일과 docker build 명령어를 이용하면 이미지를 생성해낼 수 있다. Github 에서 다운로드받은 도커파일을 이용해서 이미지를 만드는 경우 apt, pip 따위의 명령어들을 잔뜩 실행하는 모습을 볼 수 있다. 이미지를 격리된 환경에서 실행하면 컨테이너가 된다(참고4).
도커파일은 이미지를 만들 수 있는 스크립트의 나열이다(참고3). 음식으로 비유하자면, 만두를 만들기 위한 재료들이 얼려져 있는 상태가 아니라 apt나 pip 패키지 레지스트리(sup1) 등에서 그때그때 재료를 수급해 만두를 빚게 되는 셈이다. 이러한 공개 저장소의 패키지들도 시간이 변하면서 끊임없이 변화하기 때문에 언제나 완벽히 똑같이 동작하는 것을 담보하기 어렵다. 물론 ‘일단 이거 입력하시고~ 저거 입력하시고~’ 와 같은 주먹구구식 배포보다 훨씬 나아진 것은 분명하다. 하지만 앞에 언급한 문제들도 분명히 가지고 있어 도커파일을 이용한 소프트웨어 배포도 완벽하다고만은 할 수 없다(참고2).
도커파일을 이용한 소프트웨어 배포의 단점에 ‘그때그때 명령어를 통해 다운로드받는 패키지가 다르다’는 문제만 존재하는 것은 아니다. 하지만 이 글에서는 도커파일이 어떤 일을 하는 것인지를 이해하기 위한 목적으로 작성되었기 때문에 이와 거리가 먼 내용은 다루지 않는다.
supplementary
참고