도커 엔진을 구성하는 도커 이미지와 도커 컨테이너

도커는 종합적으로 보면 하나의 큰 리눅스 컨테이너이다.

 

 

우리가 도커를 바이너리 파일로 설치하거나 다운로드를 받게 된다면 실제로는 도커 엔진을 다운받는 것과 똑같다.

 

또한, 도커를 이용해서 인프라를 구축하거나 개발을 한다는 말은 도커 엔진을 이용해서 인프라를 구축 및 개발한다는 말이다.

 

(자세한 설명)

컨테이너 기반 가상화는 도커 엔진 위에 애플리케이션 실행에 필요한 바이너리만 올라간다.

 

OS 가상화(HiperVisor)를 보면 Host OS와 완전히 분리되는 장점은 있지만 OS위에 OS를 올리기 때문에 무겁고 느리다.

 

하지만, 컨테이너 기반 가상화는 Host OS 그리고 도커 엔진위에서 바로 동작하며 Host의 커널을 공유한다. 

(커널을 공유하게 되면 I/O처리가 쉽게 되어 성능의 효율을 높일 수 있음)

 

컨테이너를 사용하는 것은 가상 머신을 생성하는 것이 아닌,

Host OS가 사용하는 자원을 분리하여 여러 환경을 만드는 것. 

 

그렇다면 도커 엔진은 대체 무엇인가?

 

도커 엔진

도커 이미지 + 도커 컨테이너 = 도커(도커 엔진)으로 생각하면 된다.

 

그렇다면 도커 이미지는 대체 무엇인가?

 

도커 이미지

 

도커 이미지는 쉽게 생각하면 우리가 Virtual Box나 VMware에서 사용하는 ISO 파일과 비슷하다.

 

해당 이미지들을 토대로 우리는 입맛에 맞는 이미지를 생성하고 구축하고 설치할 수 있는 것이다.

 

도커 이미지에는 컨테이너를 실행할 수 있는 실행파일, 설정 값 들을 가지고 있다.

그림과 같은 이미지들을 컨테이너에 담고 실행시키면 해당 프로세스가 동작한다.

 

이미지 내부 구성(참고)

Ubuntu 이미지를 만들기 위해 Layer A,B,C(파일시스템?)가 들어간다.

Nginx 이미지를 만들 땐 이미 Layer A,B,C로 만들어진 Ubuntu 이미지를 베이스 이미지로 사용하여 nginx만 더하게 된다.

그렇다면 실질적으로 Layer A, B, C, nginx 가 더해진 것이지만 과정은 Ubuntu + Nginx가 더해진 것이다.

 

따라서, web app 이미지를 만들려고 할 땐 Ubuntu 이미지에 Nginx를 올리고 web app을 올리는 것이 아닌 이미 만들어진 Nginx 베이스 이미지에 web app을 올려 이미지를 만들게 된다.

 

이미지 구성

이미지는 3개의 파트로 구성된다.

• 저장소
• 이미지 이름
• 태그

저장소

이미지가 저장된 저장소로 도커 허브의 공식 이미지를 뜻한다.

 

하지만, 생략할 수 있다고 한다.

 

이미지 이름

해당 이미지가 어떤 역할을 수행하는지 나타낸다.

 

태그

이미지의 버전 관리나 태깅을 통해 명시하는 버전을 나타낼 때 주로 사용된다. 만약 생략한다면 도커 엔진은 가장 최신의 latest로 인식한다.

 

그렇다면 좋은 도커 이미지를 만드는 방법은 무엇일까?

 

좋은 도커 이미지가 갖는 조건

• 동작해야 함(Working)
  • 안드로이드 SDK 이미지는 생성된 컨테이너에서 추가적인 업데이트 소프트웨어 설치가 없어도 안드로이드 프로젝트를 컴파일 할 수 있어야 한다.
  • MySQL 컨테이너는 DB와 사용자에게 서버를 부트스트랩 하는 방법을 제공해야 한다.
• 작아야 함(Minimal)
  • 컨테이너의 최대 장점 중 하나는 애플리케이션을 샌드박스로 만들 수 있다는 것. (보안 문제가 아니더라도, 호스트 파일 시스템이 번잡해지는 것을 막을 수 있다.
    • 샌드박스: 보호된 영역 내에서 프로그램을 동작시키는 것으로, 외부 요인에 의해 악영향이 미치는 것을 방지하는 보안 모델.
  • 개발 환경 구축시 node.js를 호스트 파일 시스템에 설치하거나 JDK를 설치하는 등의 작업으로 호스트 파일 시스템이 더럽히는 방법을 선택할 수도 있지만, 컨테이너를 이용하여 디스크 공간, 성능을 약간 포기하고 호스트 파일 시스템이 깨끗하게 유지되도록 할 수 있도록 도와줌.
  • 도커 이미지는 사용하려는 목적에 걸맞은 동작을 해야함. 해당 동작을 위해 군더더기 없이 딱 필요한 만큼의 환경만 설치되어야 함.
  • 위 원칙을 따른다면 도커 이미지는 좀 더 확장 가능해지면서 더 적은 양의 문제만을 일으키게 될 것임.
• 화이트 박스(Whitebox)
  • 도커 이미지에서 화이트 박스는 도커 파일(Dockerfile)을 의미.
    • 도커 파일을 통해 도커 이미지를 만들기 위해 어떤 환경이 필요한지 알아볼 수 있음.
    • 원한다면 도커 이미지를 만드는 도커 파일을 수정할 수도 있음.
    • 즉, 도커 파일이 만들어지는 과정을 쉽게 볼 수 있고 수정할 수 있어야 함.
  • 도커 레지스트리에서 좋은 이미지를 찾거나 특정 이미지가 얼마나 최적화된 좋은 이미지인지 판단하는 것은 어려움.
    • 예) 10MB 짜리 작은 NODE를 띄우는 이미지가 . 왜 10개나 되는 파일 시스템 레이어를 사용하고, 결과적으로 700MB짜리 이미지가 되었는지 사용하는 쪽에서는 이해하기 힘들다. 
• 필요한 경우가 아니면 빌드 환경 설치 X
  • 빌드 환경은 굉장히 많은 공간을 차지.
  • 예를 들어, Debian 호스트에 최신 node.js를 올려 돌리려고 python, gcc등을 설치할 필요가 없다.
• 커맨드 합치기
  • 관련있는 커맨드가 연속되는 경우, 1개의 RUN 명령어에 묶어두는 것이 좋다.
  • 이러한 습관은 빌드 캐시를 좀 더 의미있게 만들며 파일 시스템의 레이어 수를 줄이게 된다고 한다.

 

도커 컨테이너

도커 컨테이너란 위에서 말하는 도커 이미지를 가지고 컨테이너를 생성하면 그게 곧 도커 컨테이너이다.

OS레벨의 가상화로 프로세스를 격리시켜 동작하는 방식

 

앞서, 이야기한 도커 이미지를 이용해 도커 컨테이너를 만들면 해당 이미지에 맞는 파일이 있는 파일 시스템, 격리된 시스템 자원, 네트워크를 사용할 수 있게 된다.

• 파일 시스템: 컨테이너 안에서 사용되는 파일 시스템은 구획화되어 있음. 그래서, 해당 컨테이너에서의 명령이나 파일 등의 액세스를 제한할 수 있다.
• 격리된 시스템 자원: 특정 컨테이너에서 작동하는 프로세스는 기본적으로 해당 컨테이너만 액세스할 수 있다. 즉, 컨테이너 안에서 실행되는 프로세스는 다른 컨테이너의 프로세스에 영향을 줄 수 없다.
• 네트워크: 기본적으로 컨테이너 하나에 하나의 IP 주소가 할당된다.

도커 컨테이너는 각각의 컨테이너가 독립적으로 움직이기 때문에 동일한 이미지를 사용한다고 해도,

서로 다른 컨테이너는 영향을 받지 않는다.(호스트 PC 포함)

 

참고

예를 들어 다음과 같이 하나의 Nginx 이미지로 3대의 도커 컨테이너가 생성되었다고 가정하자.

그런데 만약 Container1번에서 예상치 못한 장애가 발생

 

이 상황에서 Docker Container 1번에만 영향이 있고 나머지 2, 3번에는 문제 없이 컨테이너가 돌아간다.

 

 

참고 블로그

https://wonit.tistory.com/328

[Docker] 배포의 관점에서 도커가 필요한 이유

https://velog.io/@youngs508/%EC%BB%A8%ED%85%8C%EC%9D%B4%EB%84%88%EC%9D%98-%EC%9E%A5%EC%A0%90

컨테이너의 장점

https://blog.naver.com/PostView.nhn?blogId=complusblog&logNo=220980868534&proxyReferer=https:%2F%2Fwww.google.com%2F

[의역] 좋은 도커 이미지 (Docker Image) 만들기