시작
동기들과 사이드 프로젝트 중 각자 집에서도 편리하게 사용할 수 있는 개발 환경이 필요했다. 도커는 이러한 개발환경이나 운용 환경을 쉽게 구축할 수 있었다. 심지어 컴포즈를 적절히 만들어두면 일일이 CLI에 작성하지 않아도 단 몇 줄에 개발환경이 완성된다. 막상 필요해서 급하게 만들긴 했지만 이론적인 부분이 약해 공부하면서 정리하고자 한다.
왜 도커를 쓸까?
도커의 핵심적인 부분인 '컨테이너'에는 리눅스 운영체제의 일부를 가진다. 즉 컨테이너 별로 운영체제의 일부분을 통째로 격리시킨다. 즉 컨테이너 별로 파일 시스템이 존재하며 서로 다른 ip를 가진다. 대신 CPU나 메모리 관리 같은 핵심적인 커널 기능들은 호스트의 운영체제와 공유하여 사용한다. 이때 도커는 리눅스 기반이기 때문에 윈도우 환경에서는 Hyper-V(혹은 WSL 2 )와 같은 가상환경이 필요하다.
컨테이너를 만들기 위해서는 '이미지'가 필요하다. 이는 java에 객체와 비슷한데, 컨테이너를 인스턴스라고 할 수 있다. 즉 이미지만 있다면 다수의 컨테이너 생성도 가능하며 해당 이미지를 기반으로 다른 이미지를 생성할 수도 있다. 이렇게 독립된 환경은 컨테이너 간의 결합도를 낮춰준다. 이는 스프링 기반 서버 A와 B가 있을 때 서로 다른 데이터베이스 환경을 사용할 수 있으며 버전 문제에서도 자유롭고 장애에 있어서도 어느 정도 극복할 수 있다. 개발환경에서는 이 컨테이너 정보들을 공유하여 손쉽게 팀원 전원에게 배포해 동일한 개발환경을 사용할 수 있다.
도커 동작 구조
위의 그림과 같은 구조로 운영체제 위에 도커 엔진이 있으며 그 도커 엔진 위에서 컨테이너가 관리되고 컨테이너 안에는 운영체제의 일부가 들어가 있어 일종에 여러 개의 기능적 서버로 운용할 수 있다. 컨테이너 내부에 있는 운영체제의 일부를 제외한 핵심적인 '커널'은 도커 엔진 밑의 운영체제를 공유하기 때문에 일종에 가벼움을 얻을 수 있다. 즉 컨테이너에 들어있는 운영체제는 커널을 제외하고 해당 기능을 동작하기 위한 운영체제의 컴포넌트가 들어있다.
위에서 말한 것과 같이 이미지를 이용해 컨테이너가 만들어진다. 따라서 이미지만 공유된다면 어떤 물리적 서버에서도 같은 환경을 구성할 수 있다. 보통 이런 이미지들은 도커 허브에서 가져올 수 있다. 도커 허브는 공개된 이미지가 모여있는 곳이다. 따라서 이 이미지를 가져와 요구사항에 맞게 변경하여 손쉽게 컨테이너를 만들 수 있다. 또한 컨테이너 내 프로그램을 업데이트할 때에도 컨테이너 내부에서 변경하는 것보다 이미지를 업데이트한 후 기존 컨테이너를 중지 및 삭제하고, 업데이트된 이미지를 기반으로 새로운 컨테이너를 생성하여 실행함으로써 컨테이너를 가볍게 쓰고 버릴 수 있다. 이를 컨테이너 생애주기라고도 한다.
데이터 저장
컨테이너를 가볍게 쓰고 버린다면 그 안의 내용들은 유지해야 할 경우가 많다. 예를 들어 mysql 컨테이너를 업데이트하기 위해 컨테이너를 삭제했을 때 데이터도 삭제된다면 컨테이너를 삭제하기 까다로울 것이다. 때문에 도커는 호스트(물리적 서버)에 디스크를 마운트해 사용할 수 있다. 이를 바인드 마운트라고도 한다. 때문에 데이터와 분리되어 컨테이너를 쉽게 폐기할 수 있다. 이때 바인드 마운트를 제외하고도 도커 엔진이 관리하는 볼륨 마운트도 있다. 이때 볼륨 마운트는 호스트가 아닌 도커 엔진이 관리하며 호스트가 아닌 컨테이너를 통해 안정적으로 접근된다.
정리
도커의 핵심은 '환경을 격리할 수 있다'이다. 여러 개의 컨테이너를 실행할 수 있으며 하나의 프로그램을 여러 가지의 형태로 여러 개 띄울 수 있다. 또한 각 컨테이너는 커널을 제외한 운영체제 일부가 들어있기 때문에 비교적 가볍다. 또한 이미지를 통해 컨테이너를 생성하므로 이미지를 만드는 일종에 설계도만 공유되어도 쉽게 개발환경이 공유된다. 또한 여러 대의 서버에 동일한 서버를 운용할 때에도 유용하다.
'도커' 카테고리의 다른 글
| 도커 명령어 정리 (2) (0) | 2024.03.24 |
|---|