왜 도커를 써야 하죠?
컨테이너는 어플리케이션을 환경에 구애 받지 않고 실행하는 기술입니다.
깃랩이라는 도구를 보면 우분투에서 설치할 때 명령어를 안내하고 있습니다. 그러나 CentOS를 사용하면 명령어가 달라집니다.
이때 컨테이너 도구인 Docker가 설치되어 있다면 어느 환경이든 상관 없이 하나의 명령어로 깃랩을 실행할 수 있습니다!
도커 없이도 배포/운영이 잘 되는데 왜 써야 하죠?
그래서 저도 이점을 정리해보려고 합니다.
서버를 코드로 구성하고 관리하는 방법으로써 도커가 지닌 장점을 이야기하겠습니다.
운영하면서 만들어지는 Snowflake Servers
각 서버별 운영 기록이 다르기 때문에 똑같은 일을 하는 두 서버도 OS부터 컴파일러, 설치된 패키지까지 완벽히 같기 쉽지 않습니다.
이는 장애로 이어집니다. 이 같이 모양이 다른 서버를 Snowflake Server라 합니다.
이때 문제가 발생하면 이전 서버의 모든 운영 과정을 돌아보면서 새로운 서버와의 차이점을 알아내야 해결할 수 있습니다.
하지만 차이점은 점점 늘어갈 것입니다.
서버를 코드로 구성하고 관리하는 다양한 방법
•
사내 문서 도구에 기록
•
tmux-xpanes
•
운영 기록 코드화 - Vagrant, Chef,,,
⇒ Dockerfile
// Nginx 서버를 구성하는 도커 파일
FROM debian:stretch-slim
RUN apt-get update \
&& apt-get install -y \
imagemagick
JavaScript
복사
이 도커 파일로 도커 이미지를 만들 수 있습니다. 도커 파일이 서버 운영 기록이라면, 도커 이미지는 운영 기록을 실행할 시점이라고 할 수 있습니다.
도커 파일 = 서버 운영 기록 코드화
도커 이미지 = 도커 파일 + 실행 시점
도커에서는 앞서 살펴본 도커 파일로 이미지를 만들어 두면, 서버가 구성되는 시점이 이미지를 만든 시점으로 고정됩니다.
이 이미지를 사용해 1년 전에 A 서버에 컨테이너를 배포하고, 오늘 B 서버에 컨테이너를 배포한다고 해도, 두 컨테이너 모두 이미지매직이 설치된 시점은 같습니다.
다른 도구들은 모두 도구를 실행하는 시점에 서버의 상태가 결정되는 데 비해, 도커는 작업자가 그 시점을 미리 정해둘 수 있습니다. 덕분에 서버를 항상 똑같은 상태로 만들 수 있는 것이죠.
불편하게 여기는 부분 중 하나가 바로 도커 파일인데요. 명령어가 어려워서라기보다는 한 번 작성해서 이미지 빌드까지 성공하는 경우가 드물다보니, 수정해서 다시 빌드하는 과정을 반복해야 하기 때문입니다. 게다가 빌드하는 시간이 점점 길어지는데 그러다보면 마치 코드 작성 후 컴파일하는 시간처럼 느껴지기도 하죠(그 때는 틀리고 지금은 맞다?).
그런데 이 불편함을 다르게 바라보면 오히려 도커만의 장점이 될 수도 있습니다. (TDD, 미리 겪은 실패는 약간의 기다림과 귀찮음이지만 지금 겪지 않은 실패는 훗날 서비스 장애로 이어진다. = 먼저 맞는 매가 낫다.)
서버 배포와 운영에 도커를 꼭 써야만 하는 건 아닙니다. 하지만 지금 상황에 너무 익숙해져서 문제라고 느끼지 않는 문제는 없을까요? 수평적 확장이 자유롭나요? 서버의 견고함을 보장하면서도 동적으로 바꿀 수 있는 유연함이 존재하나요? 퇴사를 하거나 부서를 옮겨야 해서 다른 이에게 서버 운영 기록을 인계하려면 시간이 얼마나 걸릴까요?
