컨테이너 · 도커

컨테이너란?

컨테이너를 쓰기 시작하면 가장 먼저 바뀌는 것은 서버 세팅 문서가 코드로 바뀐다는 점입니다. 예전에는 '자바 11 설치, 환경변수는 이렇게, 라이브러리는 몇 버전' 같은 설치 안내서를 위키에 적어두고 사람이 손으로 따라 했습니다. 컨테이너에서는 그 절차를 Dockerfile이라는 파일 한 장에 적고, 그 파일이 그대로 실행됩니다. 사람의 기억과 손버릇이 끼어들 여지가 사라지는 것이 실제 변화입니다.

가상머신(VM)과 혼동하기 쉽지만 층위가 다릅니다. VM은 운영체제를 통째로 하나 더 띄워 이미지가 보통 수 GB, 기동에 분 단위가 걸립니다. 반면 컨테이너는 호스트의 커널을 공유해 수십~수백 MB에 기동은 대개 초 단위입니다. 용어도 갈라 써야 합니다. 설계도에 해당하는 것이 이미지, 그 이미지를 실제로 띄운 것이 컨테이너, 이미지를 보관하고 나눠주는 창고가 레지스트리입니다. 컨테이너가 수십 개로 늘어나 배치와 복구를 자동으로 맡길 단계가 되면 그 지휘자 역할이 쿠버네티스입니다.

모든 조직에 당장 필요한 것은 아닙니다. 서버 한 대에 서비스 하나를 올려두고 분기에 한 번 고치는 정도라면 도입 비용이 더 큽니다. 배포가 잦거나, 같은 제품을 여러 고객사 환경에 설치하거나, 개발자가 늘어 환경 맞추기가 반복될 때 효과가 분명해집니다. 판단 기준은 기술 취향이 아니라 '같은 것을 몇 군데에 똑같이 올려야 하는가'입니다.

가장 자주 깨지는 지점은 컨테이너 안에 데이터를 그냥 두는 것입니다. 컨테이너는 껐다 켜면 내부 변경분이 사라지는 구조라, 볼륨을 붙이지 않고 DB나 업로드 파일을 안에 넣어두면 재배포 한 번에 통째로 날아갑니다. 이미지 태그를 'latest'로만 쓰는 습관도 위험합니다. 어제 내려받은 latest와 오늘 내려받은 latest가 다른 것이 되어, '어디서나 똑같이'라는 장점을 스스로 버리는 셈이 됩니다. 버전을 숫자로 고정해 두지 않으면 장애가 나도 어떤 코드가 돌고 있었는지 되짚지 못합니다.