도커(Docker) 가볍게 입문해보기 - 1

이 스터디는 학교 선배가 작성한 강의 자료를 참고하였으며 같이 2024 ETRI 동계 연수연구생으로 재직중인 친구의 도움을 받았다. 또한 관련 책을 ETRI에서 대여하여 병행하며 읽고 있다. 아낌없는 도움을 제공하는 모두에게 무한한 감사를..

GitHub - J-hoplin1/Docker-n-K8S-Lecture-Note: Docker,Kubernetes 강의자료

도커란?

도커(Docker)는 리눅스 컨테이너에 여러 기능을 추가함으로써 애플리케이션을 컨테이너로서 좀 더 쉽게 사용할 수 있게 만들어진 오픈소스 프로젝트이다. Go 언어로 작성돼 있으며 기존에 쓰이던 가상화 방법인 가상 머신과는 달리 도커 컨테이너는 성능의 손실이 거의 없어서 차세대 클라우드 인프라 솔루션으로 많은 개발자들에게 주목받고 있다.

가상 머신과 도커 컨테이너

기존의 가상화 기술은 가상 머신이라는 단위로 구별되고 각 가상 머신에는 운영체제가 설치되어야 한다. 하지만 각종 시스템 자원을 가상화하고 독립된 공간을 생선하는 작업은 하이퍼바이저를 반드시 거치기 때문에 일반 호스트에 비해 성능의 손실이 발생한다.
이에 비해 도커 컨테이너는 가상화된 공간을 생성하기 위해 리눅스의 자체 기능인 chroot, 이름공간(namespace), cgroup을 사용하여 프로세스 단위의 격리 환경을 만들기 때문에 성능 손실이 거의 존재하지 않는다.
2022년 2학기에 들었던 컴퓨터 구조 수업에서 도커 관련 내용이 후반부에 잠깐 나왔는데 당시에 내가 느꼈던 도커와 가상머신과의 가장 큰 차이점은 바로 'Guest OS를 설치하지 않는다'라는 점이다. 운영을 위해 필요한 프로그램, 라이브러리만 격리하여 사용할 수 있으며 OS Resource, System Call은 Host OS와 공유한다. 해당 내용은 준호형의 강의 노트 1장 - What is Docker? 에서 확인할 수 있다.

https://github.com/J-hoplin1/Docker-n-K8S-Lecture-Note/blob/main/docker-1-What-is-docker%3F/imgs/6.pn

도커는 하드웨어를 가상화 하는 계층이 없다. 그렇기에 메모리 접근, 파일시스템, 네트워크 모두 가상머신에 비해 빠르다. Docker는 Dockerfile을 작성하여 이미지 생성/ 배포에 특화되어있으며, 버전관리도 가능하다. 또한 도커는 Docker Hub라는것을 제공하여 다른 사람이 만든 이미지를 사용할 수도 있다.

도커를 시작해야 하는 이유

사실 나는 부끄럽지만 지금까지 도커 관련 인터넷 강의를 2번 정도 들었다. 하지만 이번에 도커를 공부하면서 모든 것이 새로웠다.

실제로 Google Cloud의 Kubernetes 코스도 수료해서 집에 기념품 구글 마크가 그려진 모자도 있다. 비닐도 뜯지 않았다. 핑계일 뿐이지만 도커 관련 강의들을 들을 때 시험 기간이기도 했고 작년엔 학생회 활동까지 겹치게 되면서 제대로 공부할 시간이 부족했고 내용이 너무 어렵기도 해서 딱히 손이 가지 않았던 것도 사실이고.. 그래서 '수료증만 받자'라는 생각으로 대충 빠르게 듣고 넘겼다. 그렇다고 '늦었지만 남들이 다 도커를 공부하니까 나도 해야한다'와 같은 수동적인 동기부여는 내게 도움이 되지 않을 것이다. 그래서 도커를 시작해야 하는 이유는 무엇일까?

애플리케이션의 개발과 배포가 편해진다.

서버를 부팅할 때 실행되는 운영체제를 일반적으로 '호스트 OS'라고 부르며 도커 컨테이너는 호스트 OS 위에서 실행되는 격리된 공간이다. 따라서 컨테이너 자체에 특별한 권한을 주지 않는 한 컨테이너 내부에 수많은 소프트웨어를 설치하고 설정 파일을 수정해도 호스트 OS에는 영향을 끼치지 않고 독리보딘 개발 환경을 보장받을 수 있다.
또한 배포하자고 하는 컨테이너를 도커 이미지(운영체제에 비유하면 이미지는 실행 파일, 컨테이너는 프로세스이다.)라고 하는 일종의 패키지로 만들어 운영 서버에 전달하기만 하면 컨테이너에서 사용되던 패키지를 운영 서버에서 새롭게 설치할 필요도 없으며 각종 라이브러리 설치 등으로 인한 의존성을 걱정할 필요도 없다.
게다가 도커 이미지는 가상 머신의 이미지와 달리 커널을 포함하고 있지 않고 위에서 설명한 것과 같이 OS Resource, System Call은 Host OS와 공유하기 때문에 이미지 크기가 상대적으로 작다. 또한 이미지 내용을 레이어 단위로 구성하며 중복뒤는 레이어를 재사용할 수 있어서 애플리케이션의 배포 속도가 매우 빨라진다는 장점이 있다.

여러 애플리케이션의 독립성과 확장성이 높아진다.

소프트웨어의 여러 모듈이 상호 작용하는 로직을 하나의 프로그램 내에서 구동시키는 방식인 모놀리스(Monolith) 애플리케이션 방식은 서비스의 기능이 복잡해지고 거대해질수록 소프트웨어 자체의 확장성과 유연성이 줄어든다는 단점이 있다. 이러한 모놀리스 방식을 대체하기 위해 여러 모듈을 독립된 형태로 구성하여 모듈 관리가 쉬우며 여러 모듈에게 독립된 환경을 동시에 제공하고 변화에 빠르게 대응할 수 있는 마이크로서비스(Microservices) 구조가 최근 새롭게 떠올랐다.
책에서 든 예시로 웹 서비스는 데이터베이스 컨테이너와 웹 서버 컨테이너로 분리하여 웹 서비스에 부하 발생 시 마이크로서비스 구조의 웹 서버 컨테이너만을 동적으로 늘려 부하를 분산할 수 있으며 또한 웹 서버와 데이터베이스의 이미지 버전을 독립적으로 관리하기 때문에 유지 보수 또한 용이해진다.

---

결론

이 외에도 도커 컨테이너를 사용하는 이유로 프로젝트 자체의 성숙도나 확장성, 편의성 등이 있지만 이를 이해하기 위해서 도커를 직접 사용해보는 것이 좋다고 책에서 권하고 있다. 사실 강의 자료 3장까지 보면서 간단한 실습을 진행하긴 했는데 오늘 해당 내용을 다 적기에는 무리가 있어 보인다. 다음 글에서부터 강의 자료를 보면서 내가 어떻게 직접 경험해봤는지 적어보도록 하겠다.
운영체제 강의 시간에 배웠었던 모놀리스 방식, 마이크로서비스 방식과 같은 내가 쓸 일이 전혀 없을 것 같았던 개념들이 나와서 내심 반갑기도 했다.
도커의 가벼운 입문 말고 Express.js 기본적인 CURD API 만들어보기, Middleware에 대한 개념 이해하기 등등.. 과제가 많은데 열심히 해야지!