2020. 10. 3. 21:03ㆍTutorial & Training/Docker-Compose
본문은 시리즈로 작성되는 내용입니다.
#0. 개요
목차
- 왜 도커 컴포즈 시리즈를 작성하나요?
- 도커란 무엇인가?
- 도커의 등장 배경
- 도커를 사용하는 이유?
- 도커를 도와주는 도구들
왜 도커 컴포즈 시리즈를 작성하나요?
인터넷 게시물이나, 블로그 게시글, 유튜브 영상, 책 등을 살펴보면 Docker(도커)와 Kubernetes(쿠버 네티스)에 대한 기술이나 내용은 많이 작성되어 있지만, 도커 컴포즈는 일부만 작성돼있거나, 전체 기술을 다룬다기보다는 진행하는 내용에 있어 이 환경을 설치하기 위해 컴포즈를 설명하는 간단한 내용만을 기술하여 많은 아쉬움을 자아냅니다.
정말 좋은 기술이지만 yaml을 사용할 줄 모르거나, 컴포즈의 지원 문법을 잘 알지 못한다면 깊이 있는 컴포즈를 사용하려 할 때 꽤나 많은 러닝 커브 비용이 발생됩니다. 생각보다 그리 어렵지 않기에 많은 사람들이 작성법에 익히며 이를 통해 서로의 컴포즈로 구성한 서버 설정 정보 등을 공유하며, 초기 서버 설정이나, 서버 이식, 추가, 신입사원 온보딩 등으로 활용하면 굉장히 시간적으로 인력적으로나 엄청난 이점을 가져다줄 수 있습니다.
도커 컴포즈는 현재는 Docker Swarm(도커 스웜)을 설치하면 자동으로 포함되어 설치되며, 컴포즈는 별도의 프로젝트로 작성되어 기존 Docker프로젝트들과는 다르게 Go가 아닌 Python으로 구현되었으며, 추후에 도커 프로젝트에 흡수되면서 공식문서가 통합되어 Docker에서 공식적으로 제공해주는 기능으로 변화되었습니다.
하지만 사실 Python으로 작성되었을 뿐 Python 코드를 작성하지는 않습니다.
도커의 등장 배경
많은 사람들이 Docker를 나온 지 5년도 안된 서버 기술로 바라보는 시각이 없잖아 있지만, Docker는 사실 2013년 3월 오픈소스로 처음 등장한 나름 연혁이 조금 알찬 기술입니다.
이는 Javascript의 라이브러리인 React의 첫 등장이 2013년 5월이라는 점을 감안해도 2개월이나 앞서 나온 기술이죠.
관련 유튜브 영상 https://youtu.be/wW9 CAH9 nSLs
Docker가 없던 시절 서비스 운영은 보통 크게 2가지 전략이었습니다.
Real Server로 직접 호스팅 하여 서비스를 운영하거나, 등장한 지 오래되지 않은 클라우드 기술을 사용하거나
위 2 기술에서도 또 가상화라는 기술을 사용하여 더욱 나누어 썼지만, 이 두 방식에는 공통적으로 크나큰 문제가 있었습니다.
- 신입사원이나 업무를 인수인계해야 하는 상황에서 서버 구성만 며칠 몇 주...
- 분산 서비스를 구현하려 할 때 똑같은 서버 설정을 구성하는데 힘든 상황(문서 보고 따라 했는데 왜 안되지?)...
- 클라우드 방식과 MSA(Micro Service Architecture) 방식의 등장과 발전
이러한 문제 말고도 많은 문제가 있었지만, 도커 등장 전에는 가상화를 사용하여 주로 Guest OS를 통해 해결을 하였는데
Docker가 등장하면서 Guest OS를 구성하는 가상 리소스가 제거되고, Host와 자원을 공유하며 Container를 이용하여 격리된 공간을 제공한 것이죠!
Container는 도커에서 등장한 신기술이 아닌 오래전부터 존재해왔던 기술이며, Docker 이외의 제품군에서는 보안에서 악성코드를 동적 분석할 때 많이 이용하는 제품 중 하나인 SandBoxie가 대표적입니다.
그렇게 한국에는 소문이 퍼지기 시작했습니다.
웹 개발자가 Docker를 접하면 두 번 다시 VMware를 사용하지 않는다고 말이죠!
마치 PHP 개발자가 PHPStorm을 접하면 두 번 다시 다른 걸 쓰지 않는다는 말처럼요!
그 파급력은 생각보다 강력했고, Docker는 2016년 이후부터 계속 상승세를 타고 대한민국에도 엄청난 사용률과 지지율을 얻기 시작하여 현재에 이르렀습니다.
도커를 사용하는 이유
도커를 사용하는 이유는 앞선 내용들에서 언급했듯이 서버 구성 설정 리소스 절감 모두 엄청난 이점을 가져왔습니다.
사실 그럼에도 불구하고 아직까지도 사용하는 이유를 킹리적 갓심으로 믿어 의심치 않아 많은 사람들은 도커를 왜 해야 하는지 필요성을 배척하고 거부감을 느끼는 유저들이 존재하죠.
단일 서버만 구성한다 하여도 도커를 사용하면 서버가 죽어서 혹은 나중에 옮길 때도 매우 편합니다.
현재 도커 컨테이너가 정상적으로 돌고 있어도 해당 컨테이너를 tar파일로 만들어버려서 들고 다닐 수도(?) 있습니다.
또한 Dockerfile을 이용하여 빌드된 이미지를 마찬가지로 tar 파일로 만들어버려서 들고 다니실 수(?) 있습니다.
리소스의 절감으로 저사양 컴퓨터에서도 무리 없이 동작할 수 있습니다. 심지어는 라즈베리파이에서도 정상 동작합니다!
이 처럼 도커만 사용하는 유저들을 위해 아예 CoreOS와 Photon OS 등 Docker에만 특화된 운영체제도 나타났습니다.
마치 블리치라는 만화에서 1번대 총대장 야마모토 겐류사이만을 죽이기 위해 나온 레스 렉시온 원더 와이즈처럼 말이죠
도커를 도와주는 도구들
Compose는 도커에서 공식적으로 제공하는 도구로는 컴포즈와 스웜이 있습니다. 컴포즈는 앞으로 우리가 헤쳐나갈 관문이지만 주로 서버 설정을 도커로만 구성해도 좋지만, 서버를 설정할 때 주요 설정값이나 포트 환경변수 컨테이너 이름 마운트 위치 등 많은걸 매번 기억할 수 없습니다. 이 때문에 dockerfile을 이용하여 작성할 수 도 있지만, compose를 통해 반동적 조정을 할 수 있게 만들 수 있습니다. 그래서 이 시리즈의 제목은 컴포즈로 문서화하기입니다!
Swarm은 분산 클러스터링과 로드밸런싱을 도와주며 배포를 도와주는 오케스트레이션 도구입니다. 쉽게 생각하여 옛날 DDOS 공격처럼 중앙 봇넷이라는 매니저 노드가 있고 이 매니저 노드에서 명령을 하달하면 자식 노드(좀비 PC)가 이를 수신하여 명령을 이행하는 것 과 비슷한 매개체로 구성된 기술입니다. 이를 통해 분산 서버를 구성하고 많은 수 의 동시접속자를 분배하여 서비스가 죽지 않고 버텨나갈 수 있도록 해주는 기술입니다.
Kubernets는 Swarm과 Compose의 합쳐진 느낌으로 작성하게 되는데 Google이 내부 프로젝트로 자사에서 사용하다가 오픈소스로 2014년에 공개한 프로젝트이며, 요즘에는 이를 활용한 AWS의 EKS, Google의 Cloud Run 등의 제품군이 있습니다. 쿠버 네티스를 활용하면 Swarm과 마찬가지로 같은 기능을 수행하지만 쿠버 네티스의 경우 상당한 러닝 커브를 소모하고, 호스팅 서비스나 클라우드 호스팅에 직접 설치하여 사용할 경우 많은 리소스를 필요로 하여 요금폭탄도 맞을 수 있습니다. 하지만 대시보드가 매우 눈에 띄게 보기 좋고 근래에 오케스트레이션 중에 가장 많이 사용하는 도구입니다.
Portainer는 Docker container로 서버를 구성하여 동작하고, 이를 통해 해당 Host서버에서 동작하고 있는 Docker container의 설정이나 이미지 등을 볼 수 있으며, 웹에서 조작할 수 있게 해 줍니다. 일반적인 컨테이너와 마찬가지로 포트 포워딩 설정을 통해 외부에서 접근할 수 있습니다. 웹 상에서 컨테이너의 shell에 접근할 수 있지만 vim과 같은 에디터 편집기 사용에는 조금 무리가 있습니다.
'Tutorial & Training > Docker-Compose' 카테고리의 다른 글
| #1. 준비하기 - 도커 컴포즈로 서버 문서화하기 (0) | 2020.11.26 |
|---|