그림과 실습으로 배우는 도커 & 쿠버네티스 Chapter 2 - 도커의 동작원리

Chapter 2 - 도커의 동작원리

SECTION 01 도커의 구조

• 운영체제는 소프트웨어나 프로그램의 명령을 하드웨어에 전달하는 역할
• 도커를 사용하는 경우 운영체제 위에 도커 엔진이 동작하고 그 위에서 컨테이너가 동작한다.
• 도커 엔진 아래에도 리눅스 운영체제가 있는데, 컨테이너 속에 또 리눅스 운영체제(비슷한 것)가 있다.
  • 도커에서는 컨테이너가 완전히 분리돼 있으므로 리눅스 운영체제의 ‘주변 부분’이 컨테이너 속 프로그램 명령을 전달받을 수 없다.
  • 따라서, 컨테이너 속에 운영체제의 ‘주변 부분’이 들어 있어 프로그램의 명령을 전달받고 이를 커널에 전달하는 구조로 돼 있다.

책에서 표현하는 ‘주변 부분’ 이란? "주변 부분"은 운영체제에서 커널을 제외한 유틸리티, 라이브러리, 셸과 같은 요소들을 의미

• (유저 공간, user space):
  • 리눅스 운영체제는 크게 **커널 공간(kernel space)**과 **유저 공간(user space)**으로 나뉜다.
  • 유저 공간은 커널과 상호작용하기 위한 셸, 라이브러리(glibc 같은 표준 라이브러리), 명령어 도구 등을 포함하는 영역.
  • 이들은 커널에게 시스템 자원을 요청하거나 파일 작업, 네트워크 통신, 프로세스 관리 등의 작업을 요청하는 역할 수행.
  • 컨테이너 내부에는 이러한 유저 공간 도구들이 포함된다. 즉, 컨테이너 내부에 필요한 최소한의 리눅스 도구들(예: bash, ls, cat 같은 명령어)이 존재할 수 있으며, 이 도구들이 커널과 상호작용하여 작업을 수행하게 된다.
• 커널 (Kernel):
  • 커널은 운영체제의 핵심 부분으로, 하드웨어 자원을 관리하고 애플리케이션이 시스템 자원을 효율적으로 사용할 수 있도록 중재하는 역할을 한다.
  • 도커 엔진은 호스트 시스템의 커널을 공유한다.
  • 즉, 컨테이너 내부에서 실행되는 모든 프로그램은 실제로 호스트의 커널과 상호작용하게 된다.
  • 각 컨테이너는 마치 독립적인 환경에서 동작하는 것처럼 보이지만, 실제로는 호스트 커널과 상호작용하고 자원을 할당받아 실행 된다.

리눅스 전체 영역에 컨테이너를 넣으면 안되나?

• Docker의 가장 큰 특징인 ‘가벼움’ 을 잃게 된다.
• 위에서 표현하는 ‘주변 부분’ User Space 영역만 컨테이너에 넣고 커널은 OS 의 시스템을 빌려 사용함으로써 Docker 의 가장 큰 장점인 가벼움을 유지할 수 있다.

도커는 기본적으로 ‘리눅스용’이다.

• 도커는 리눅스 운영체제가 동작하는 것을 전제로 되어 있다.
• 즉, 리눅스 운영체제에서만 동작할 수 있다.

윈도우나 MacOS 는 도커 못쓰나?

• 원래는 사용할 수 없어야 한다.
• 그러나, 실제로는 사용할 수 있다.
• VirtualBox 나 VMware 와 같은 가상환경 위에 리눅스 운영체제를 설치하여 사용하면 된다.
• 그러나, 확실한건 어떤 형태로든 리눅스 운영체제를 갖춰야 한다.

SECTION 02 도커 허브와 이미지, 그리고 컨테이너

도커 이미지

• 도커 이미지는 컨테이너를 만드는데 사용한다.
• 우리가 실제 사용하는 것은 컨테이너며, 이미지를 그대로 사용하는 일은 없다.
• 도커 이미지 하나로 여러개의 컨테이너 생성가능
• 도커 컨테이너로 이미지 생성 가능

도커 허브

• 도커 허브는 공식적으로 운영되는 도커 레지스트리 이름이다.
• 공개된 컨테이너 이미지가 모여있는 곳 이다.
• 우리가 대중적으로 사용하는 소프트웨어들이 이미 많은 조합으로 존재한다.
• 잘못된 이미지들이 존재할 수 있으니, 공식 이미지를 사용하는 것이 좋다.

호스트 컴퓨터와 컨테이너에서 각각 다른 배포판을 사용해도 괜찮은가?

• 호스트 컴퓨터와 컨테이너 간의 배포판 버전 차이가 있어도 아무 문제가 없다.
• 단, 특정 DBMS를 사용할 때는 운영체제 종류에 따라 문제가 발생할 수 있으므로 고려해야 한다.

SECTION 03 도커 컨테이너의 생애주기와 데이터 저장

컨테이너의 생애주기(Container LifeCycle)

• 컨테이너의 생성, 실행, 종료, 폐기의 라이프 사이클을 의미
• 컨테이너는 ‘쓰고 버리는’ 일회용품 같은 것.
  • 여러 개의 컨테이너를 하나하나 업데이트하려면 많은 수고가 든다.
  • 유지보수 비용보다 새로운 이미지로부터 새로운 컨테이너를 만들어 갈아타는 방식이 유지보수 측면에서 좋다.

컨테이너를 폐기하면 데이터는?

• 컨테이너를 폐기하면 컨테이너 내부에 있는 데이터는 사라진다.
• 따라서, 보통 도커가 설치된 물리적 서버(호스트)의 디스크를 마운트해서 데이터를 저장한다.

마운트(Mount) 란? "마운트(Mount)"는 컴퓨팅 용어로, 특정 파일 시스템이나 저장 장치를 운영체제에서 접근할 수 있도록 연결하는 과정

• 마운트(Mount): 외부 장치나 파일 시스템을 운영체제에 연결하는 과정 mount -o [옵션] [디바이스명] [마운트할 디렉토리]
• 마운트 포인트(Mount Point): 마운트되는 파일 시스템이 연결될 디렉토리를 말합니다.
• 언마운트(Unmount): 연결된 장치를 안전하게 분리하는 과정 umount [마운트된 디렉토리]

SECTION 04 도커의 장점과 단점

도커의 장점

• 독립된 환경
  • 하나의 호스트에 여러개의 컨테이너를 띄울 수 있다.
• 서버관리 용이
  • 도커 이미지를 이용한 도커 컨테이너 구축 및 유지보수 가능.
• 가볍다
  • 도커 컨테이너에 OS의 커널을 포함시킬 필요가 없다.
  • 따라서, 가벼워지고 OS 배포판을 변경할 수 있다.

도커의 단점

• 리눅스만 지원됨
  • 리눅스 운영체제를 사용하는 기술이므로 리눅스용 소프트웨어만 지원한다.
  • 다른 운영체제에서 사용할 경우 다른 방식으로 우회해서 리눅스 소프트웨어에서 기동해야 한다.
• 호스트 서버 의존성
  • 호스트 서버가 문제가 생기면 호스트 위의 컨테이너 전부에게 문제가 생긴다.
• 단일 컨테이너만 사용할 경우 의미가 없음.
  • 도커는 컨테이너를 여러개 사용하는 것을 위한 것.
  • 컨테이너를 하나밖에 사용하지 안흔다면 도커 엔진은 단순한 오버헤드 발생 뿐.

도커의 주 용도

• 동일한 개발환경 구축
  • 개발 환경과 운영 환경 같이 동일한 환경 구축이 가능하다.
• 격리된 환경을 통한 신규 버전 테스트
  • 격리된 컨테이너 환경을 이용해 신규 버전의 테스트가 용이하다.
• 동일한 서버가 여러 대 필요한 경우
  • 동일한 서버가 여러 대 필요한 경우 컨테이너를 이용하여 구축할 수 있다.

도커의 파일은 날아가기 쉽다?

• 도커 컨테이너는 책에서 설명하길 ‘쓰고 버리는 것’ 이라고 표현한다.
• 쓰고 버릴 때 당연히 컨테이너 내부 데이터는 ‘지워지게 된다.’
• 하지만, 내부 데이터를 관리할 경우 호스트와 마운트 해서 사용하면 된다.
• ‘날아가기 쉽다’ 라는 말은 결국 도커를 잘못 사용하는 경우에 발생되는 불미스러운 사건일 뿐이지, 도커 자체가 데이터가 관리가 안된다는 것은 맞지 않다고 한다.