도커를 공부해보고자 실습 시나리오를 구상해봤습니다.
실습 시나리오는 과거 대학교 졸업작품을 만들 때
Docker 없이 웹 서비스를 배포했던 기억을 토대로 구상했습니다.
당시 저희 팀은 첫 배포로 마이크로소프트의 클라우드 컴퓨팅 플랫폼인 Azure 를 사용했었는데요.
처음 얼마간 무료로 쓸 수 있는 것을 활용했습니다.
서버 구조는 대충 아래와 같았습니다.
(서버 한대에 DB 까지 때려박은 것을 보실 수 있습니다. 그냥 졸업작품 프로젝트였어서...)
그런데 Azure 의 무료 기간이 생각보다 너무 짧았습니다.
마침 저는 어디선가 라즈베리파이를 하나 얻어서 가지고있었기 때문에, 라즈베리파이로 서버를 옮기기로 했습니다.
문제는 번거로운 서버 셋팅을 처음부터 다시 해야한다는 것이었습니다.
SSH 설정, JDK 설치 및 환경변수 설정, MySQL 설치 및 계정 설정, Nginx 설치, NodeJS 설치 등..
또한 라즈베리파이 OS 에는 MySQL을 설치할 수 없었기 때문에 MariaDB를 설치해야 했습니다. (물론 MySQL과 MariaDB는 거의 차이가 없었던 것 같긴 합니다.)
그런데 만약 Azure 서버를 셋팅했을 당시
Nginx, WAS, MySQL 이 셋팅된 OS를 통째로 Docker 이미지화 해두었다면?
그랬다면 라즈베리 파이 서버를 셋팅하는 과정은
Docker 설치, 이미지 다운받아서 실행
이것으로 끝났을 것입니다.
만약 어떤 회사에서 한 직원이 서버를 셋팅하고나서 퇴사했다고 해보겠습니다.
또한 서버는 저희 프로젝트에서 처럼 한 대에 프론트, 백엔드, reverse proxy 등을 전부 때려박아둔 상태라고 해볼게요.
(DB는.. DB는 빼고 ㅎㅎ ㅜ)
이후 새로운 직원이 입사했고, 회사는 저희 프로젝트에서 처럼 서버 비용 문제로 인해 서버를 이관하기로 결정했습니다.
이 때 퇴사한 직원이 서버 셋팅 기록을 엄청나게 신경써서 꼼꼼하고 정확하게 남겨두지 않았다면, B는높은 확률로 삽질을 해야할 것입니다.
그런데 서버가 Docker image 로 관리되고 있었다면?
새로운 직원은 새 서버에 Docker 를 설치하고 이미지를 실행하기만 하면 되는것이죠.
이것이 제가 지금까지 이해한, 서버 구축에서 Docker 의 장점입니다.
깃허브로 프로젝트 코드를 관리하는 것처럼, 서버 셋팅 자체를 이미지로 관리함으로써 이식성을 개선해주는 것이죠.
물론 장점이 이것 뿐만은 아니겠지만, 현재로서 저에게는 이게 가장 와닿는 것 같네요.
혹시 잘못 알고있는 부분이 있다면 알려주세요 ㅜ
그래서 아무튼 구상한 1차 실습 시나리오는 아래 그림과 같습니다.
일단은 도커를 써보면서 익숙해지는 것을 목적으로 아주 많이 단순화해봤습니다.
도커의 사용에 익숙해지는 것 이상으로
도커가 어떤 문제를 해결해주기 때문에 필요한지를 이해하는 것은 중요할 것입니다.
(이해한 대로 써보긴 했지만 확실하게 검증된 이해는 아님. 다른 개발자들 통해 검증 필요)