[도커] 도커 1: 도커의 3가지 컨셉

지난 시간을 통해 도커가 무엇인지 가볍게 알아볼 수 있었다.

이번 시간에는 도커의 3가지 컨셉을 알아보자!

---

🙋‍♀️ 들어가기 전에 .. 도커의 구성에 대해 살펴보자

도커의 간단한 구성

- (1) docker 명령어를 이용해 이미지로 특정한 이름(aaa)을 가진 컨테이너 생성 요청

- (2) 서버는 요청 수신 후 특정한 이름(aaa)인 컨테이너 이미지(=운영환경 설정 파일)를 이미지 저장소에서 조회

- (3) 이미지를 서버로 가져오고, 가져온 이미지를 기반으로 컨테이너 생성

---

도커 컨셉 1️⃣ 도커 API

🙋‍♀️API? 

API = Application Program Interface

- 다른 SW를 제어하기 위해 약속한 인터페이스를 말한다

- 웹, 운영체제 등에서 제공하는 광범위한 용어

 

ex) 개발자는 운영체제 API를 이용해 운영체제의 기능을 호출하여 시스템 프로그램을 작성할 수 있다

 

 

🙋‍♀️도커의 API: 도커 Deamon

그렇다면 도커에서 API가 무엇일까?

도커 간단한 구성 사진을 보면 server 쪽에 도커 Daemon이 있다.

 

docker를 쓸 때는, 

이 도커 Daemon으로 명령어를 보내 사용할 것임을 간단하게 알아두자!

 

 

🙋‍♀️ 도커 Daemon (서버) 위치는 어디에 있죠..?

맞다.

도커 Daemon으로 명령어를 보낸다고 했다.

client + server가 한 컴퓨터 안에 !

 

이때 

🖥️ client = 도커 명령어를 사용하는 부분 (개발자가 docker 명령어를 실행하는 부분)

🖥️ server(=docker daemon) = 도커 명령어를 처리하는 서버

 

client, server 모두 한 컴퓨터에 존재함을 기억하자.

 

여러분이 도커를 설치하게 되면

도커를 설치한 그 컴퓨터에 client, server가 모두 구동된다.

---

도커 컨셉 2️⃣ 도커 컨테이너

🙋‍♀️컨테이너가 뭐죠?

 

- 2014년 리눅스 컨테이너 (LXC) 기술로 처음 소개된 개념

 

- 리눅스 자원이 격리된 환경 그 자체를 말함

 

- 라이브러리, 코드, 런타임 등 시스템을 실행하는 데에 필요한 모든 것을 포함하는 개념

 

- 프로세스를 격리시키고, 독자적인 리눅스 시스템 환경을 구축

   (포토샵같은 윈도우즈/맥 전용 프로그램 가동 불가다!)

 

- 호스트 컴퓨터 입장에서, 컨테이너는 프로세스이다

  (호스트 컴퓨터 =도커를 실행하는 전체 컴퓨터, 즉 여러분의 컴퓨터를 말한다!)

 

 

🙋‍♀️도커는 리눅스 위에서 실행된다!

 

도커 엔진은 리눅스 위에서 실행되는 것이 기본이다! 

  (단, macos/윈도우 os에서도 하이퍼바이저와 도커 데스크톱을 이용해 구동 가능하다)

 

 

도커 컨셉 3️⃣ 도커 컨테이너 이미지

🙋‍♀️컨테이너 이미지?

- 운영환경 (의존성, 사용한 프로그램의 버전, 관련 의존성 라이브러리)을 하나로 모아 패키징한 파일

- 컨테이너 생성을 위해 필수적

- 여러 계층(layer)으로 이루어진 바이너리 파일 형태

- [저장소 이름]/[이미지이름]:[태그] 꼴로 사용

- 도커 컨테이너 이미지는, 공유한 이후에는 어떠한 (다른 컴퓨터의) 도커 엔진에서도 구동 가능하다

 

 

🙋‍♀️컨테이너 저장소? (image registry)

- 컨테이너 이미지를 모아놓아, 자유롭게 다운로드하며 업로드할 수 있도록 하는 저장소

    (github - 로컬 환경의 코드 관계를 생각해보라!)

 

- 이 저장소로 컨테이너 이미지를 공유하고(push),

   반대로 저장소로부터 컨테이너 이미지를 가져올 수 있다 (pull)

 

- 컨테이너 이미지 저장소

ex) 도커 허브 Explore Docker's Container Image Repository | Docker Hub

ex) quay.io https://quay.io

 

 

🙋‍♀️도커 이미지의 layer?? 그렇다면 실행시킨 다음의 데이터는 어디에?

도커 이미지는 여러 계층(layer)으로 이루어져 있다고 했다.

도커 이미지로부터 컨테이너를 생성한 경우, 기존 image layer 위에 container layer 가 생성된다.

(참고로, Linux의 UnionFS개념을 통해 여러 snapshot을 하나의 파일 시스템처럼 동작하도록 한다)

기존 image layer는 수정 불가(read only), container layer는 변경 가능(readable/writeable)하다.

 

수정 사항이 생긴다면 위에 layer가 추가되어 쌓이는 형태이다.

 

 

단, 이러한 layer 구조에서는

컨테이너를 이미지로 생성할 때 컨테이너에서 변경된 사항만 새로운 이미지 레이어로 생성된다.

즉, 큰 용량의 파일을 삭제해도, 해당 파일을 위해 할당된 저장 공간은 존재한다는 단점이 있다. (낭비)

 

---

⭐️ 정리: 도커 컨셉 정리!

- 컨테이너

    - 서로 다른 서버 환경을 격리시키며 실행 (리눅스 기술(namespace,cgroups)을 이용해 격리)

 

- 이미지

    - 운영환경(사용한 프로그램의 버전, 관련 의존성 라이브러리 등 서버를 가동하기 위해 필요한 모든 환경)을 패키징한 파일

 

- 컨테이너 이미지

    - 컨테이너를 실행시키기 위해, 기본으로 구동시킬 운영 환경 파일 

 

- 도커 장점

    - A의 컴퓨터에서 개발했을 때 구동되었다면, B 컴퓨터에 구동되지 않는다는 상황 해결

    - open된 도커 이미지를 사용하거나, 도커를 이용해 컨테이너 이미지 제작 가능

---

참고

- 도커 레지스트리 종류 설명 https://smoh.tistory.com/290

- 도커 이미지 layer 구조의 단점 - 책 '그림과 실습으로 배우는 도커 & 쿠버네티스'