용찬호. ｢ 시작하세요! 도커/쿠버네티스｣. 위키북스 를 읽으며, 학습한 내용을 정리하는 글입니다.
→ 본문의 내용은 모두 책의 내용에 대한 직/간접적 인용임을 밝힙니다.

01장. 도커란?

1.1 가상 머신과 도커 컨테이너

[ 기존의 가상화 기술 ]

• 하이퍼바이저를 이용해 여러 운영체제를 하나의 호스트에서 생성해 사용하는 방식
• 여러 운영체제는 가상 머신이라는 단위로 구별되고, 각 가상머신에는 우분투, CentOs 등의 운영체제가 설치되어 사용됨
• 하이퍼바이저에 의해 생성되고 관리되는 운영체제는 게스트 운영체제라고 하며, 각 게스트 운영체제는 다른 게스트 운영체제와 완전히 독립적 공간, 시스템 자원을 할당받아 사용함

[ 기존 기술의 한계 ]

• 하이퍼바이저를 거쳐야 하기에 일반 호스트에 비해 성능 손실
• 가상 머신은 게스트 운영체제를 사용하기 위한 라이브러리, 커널 등을 전부 포함하기에
  배포하기 위한 이미지로 만들었을 때 이미지 크기가 커진다

→ 가상 머신은 완벽한 운영체제를 생성할 수 있지만 일반 호스트에 비해 성능 손실
→ 기가바이트 단위인 가상 머신 이미지를 애플리케이션으로 배포하기는 부담

[ 도커 ]

• 도커 컨테이너는 가상화된 공간을 생성하기 위해 리눅스의 자체 기능인 chroot, namespace, cgroup을 사용하여 프로세스 단위의 격리 환경을 만들기에, 성능 손실이 거의 없다.
• 컨테이너에 필요한 커널은 호스트의 커널을 공유해서 사용, 컨테이너 안에는 애플리케이션 구동에 필요한 라이브러리, 실행 파일만 존재!
  → 이미지 용량이 가상 머신에 비해 작다!

1.3.4 Docker Toolbox와 Docker for Windows/Mac의 차이점

• 가상 머신을 생성하기 위해 리눅스킷 툴을 사용

02장. 도커 엔진

2.1 도커 이미지와 컨테이너

2.1.1 도커 이미지

• 컨테이너를 생성할 때 필요한 요소로, 여러 개의 계층으로 된 바이너리 파일로 존재
• 컨테이너 생성 및 실행시 읽기 전용으로 사용

2.1.2 도커 컨테이너

• 이미지로 컨테이너를 생성하면, 해당 이미지의 목적에 맞는 파일이 들어있는 파일시스템과, 격리된 시스템 자원 및 네트워크를 사용할 수 있는 독립된 공간이 생성된다.
  → 이것이 도커 컨테이너!
• 컨테이너는 이미지를 읽기 전용으로 사용, 이미지에서 변경된 사항만 컨테이너에 저장
  → 컨테이너에서 뭘 하든, 이미지는 영향이 없다!
• 각 컨테이너는 독립된 파일시스템을 제공받으며, 호스트와 분리되기에
  특정 컨테이너에서 애플리케이션을 설치/삭제해도 다른 컨테이너 및 호스트는 변화가 없다.

2.2 도커 컨테이너 다루기

2.2.1 컨테이너 생성

• 컨테이너에서 기본 사용자는 root
• 호스트 이름은 무작위 16진수 해시값
• attach : 컨테이너 내부로 들어가는 명령어

2.2.4 컨테이너를 외부에 노출

• 컨테이너는 가상 머신과 마찬가지로 가상 IP 주소를 할당받습니다.
• 기본적으로 도커는 컨테이너에 172.17.0.x IP를 순차적으로 할당함
  cf. docker run -i(상호 입출력) -t(tty)
  -> ifconfig 명령어로 네트워크 인터페이스 확인 가능.
• 아무런 설정을 하지 않았다면, 컨테이너는 외부에서 접근이 불가능하다

→ 외부에 컨테이너 애플리케이션을 노출하기 위해, eth0의 IP와 포트를 호스트의 IP와 포트에 바인딩해야 함!

cf. eth0 은 무엇일까?
https://seosh817.tistory.com/373#google_vignette

2.2.5 컨테이너 애플리케이션 구축

** 한 컨테이너에 프로세스 하나만 실행하는 게 도커의 철학이다 p.35

2.2.6 도커 볼륨

• 이미 생성된 이미지는 어떠한 경우든 변경되지 않는다.
• 컨테이너 계층에 원래 이미지에서 변경된 파일시스템이 저장된다.
• 컨테이너를 삭제하면 컨테이너 계층에 저장되어 있던 데이터베이스 정보가 삭제되는 단점!
• 볼륨은, 컨테이너의 데이터를 영속적 데이터로 활용할 수 있는 방법이다.

[ #1. 2.2.6.1 호스트와 볼륨 공유하기 ]
/home/workdpress_db:/var/lib/mysql
-> 호스트의 디렉토리와 컨테이너의 디렉토리를 공유한다는 뜻!
-> "동기화"되는 것이 아니라 완전히 같은 디렉터리이다.

< cf. 호스트에 이미 디렉터리, 파일 존재하고 컨테이너에도 존재하면 ? >

• 이미지에 원래 존재하던 디렉터리에 호스트의 볼륨을 공유하면 컨테이너의 디렉터리 자체가 덮어씌워진다.
  → -v 옵션을 통한 호스트 볼륨 공유는 호스트의 디렉터리를 컨테이너의 디렉터리에 마운트한다!
  

[ #2. 2.2.6.2 볼륨 컨테이너 ]

• 컨테이너를 생성할 때 --volumes-from 옵션을 설정하면 -v, --volume 옵션을 적용한 컨테이너의 볼륨 디렉터리를 공유할 수 있다.
• 직접 볼륨을 공유하는 것이 아니라, -v 옵션을 적용한 컨테이너를 통한 공유

docker run -i -t \
--name volumes_from_container \
--volumes-from volume_override \ 
ubuntu:14.04

[ #3. 2.2.6.3 도커 볼륨 ]

• docker volume 명령어를 사용하는 방식

1. docker volume create --name myvolume
2. docker volume ls
   → 이 볼륨은 로컬 호스트에 저장되고, 도커 엔진에 의해 생성/삭제된다.

[볼륨의 이름]:[컨테이너의 공유 디렉터리]

docker run -i -t --name myvolume_1 \
-v myvolume:/root/ \ 
ubuntu:14.04

볼륨을 컨테이너의 /root/ 디렉터리에 마운트하므로, /root 디렉토리에 파일을 쓰면 해당 파일이 볼륨에 저장된다.

• 볼륨은 디렉토리 하나에 상응하는 단위로, 도커 엔진에서 관리한다.
• 도커 볼륨도, 호스트 볼륨 공유와 마찬가지로 호스트에 저장함으로써 데이터를 보존하지만, 파일이 실제로 어디에 저장되는지 사용자는 알 필요가 없다.

cf. docker inspect --type volume myvolume 등으로 정보를 확인할 수 있음!

2.2.7 도커 네트워크

컨테이너의 네트워크 인터페이스에는 eth0과 lo 네트워크 인터페이스가 있다.

• 도커는 컨테이너에 내부 IP를 순차적으로 할당하며, 이는 컨테이너 재시작 때마다 변경될 수 있다.
• 이 내부 IP는 도커가 설치된 호스트, 즉 내부 망에서만 쓰일 수 있으므로 외부와 연결되어야 한다!
  • 컨테이너 시작 시마다 호스트에 veth...라는 네트워크 인터페이스를 생성함으로써 이뤄지는 과정임
  • 도커는 각 컨테이너에 외부와의 네트워크 제공을 위해 컨테이너마다 가상 네트워크 인터페이스를 호스트에 생성하고, 이인터페이스의 이름은 veth...이다.
  • 이는 도커 엔진이 자동으로 생성하는 것!

ifconfig

• eth0 : 공인 IP 또는 내부 IP가 할당되어, 실제로 외부와 통신 가능한 호스트의 네트워크 이인터페이스
• veth... : 컨테이너 시작 시 생성되어, 각 컨테이너의 eth0과 연결된다.

cf. docker0 브릿지 : 각 veth 인터페이스와 바인딩되어, 호스트의 eth0 인터페이스와 이어주는 역할을 한다~!

[ 2.2.7.2 도커 네트워크의 기능 ]
도커가 자체적으로 지원하는 네트워크 드라이버
→ bridge, host, none, container, overlay

• bridge
  • 컨테이너를 생성할 때 자동 연결되는 docker0 브릿지를 활용하도록 설정됨
  • 172.17.0.x IP 대역을 컨테이너에 순차 할당
• host
  • 호스트의 네트워크 환경을 그대로 쓸 수 있다.
  • 호스트 머신에서 설정한 호스트 이름도, 컨테이너가 물려받게 된다.
  • 컨테이너 내부의 애플리케이션을 별도의 포트 포워딩 없이 바로 서비스 가능!
• none
  • 아무런 네트워크를 쓰지 않는 것, 외부와 연결이 단절된다.
• container
  • 다른 컨테이너의 네트워크 네임스페이스 환경 공유
  • 내부 IP를 새로 할당받지 않고, 호스트에 veth 가상 네트워크 인터페이스도 만들어지지 않는다.

2.2.8 컨테이너 로깅

cf. docker logs 옵션

• --tail : 마지막 로그부터 출력할 줄 수를 지정
• --since : 특정 유닉스 시간 이후의 로그 출력
• -t : 타임스탬프 표시 가능
• -f : 로그를 스트림으로 확인 가능

docker run --log-opt 옵션을 통한 로그 파일 옵션

• max-size : 로그 파일의 최대 크기
• max-file : 로그 파일의 개수

cf. [ AWS Cloudwatch Logs ]
1. 클라우드워치에 해당하는 IAM 권한 생성하기
2. 로그 그룹 생성하기
3. 로그 그룹에 로그 스트림 생성
4. IAM 권한을 사용할 수 있는 EC2 인스턴스 생성과 로그 전송

2.2.9 컨테이너 자원 할당 제한

• --memory : 컨테이너의 메모리 제한 (최소 4MB)
• --cpu-shares : 컨테이너에 가중치 설정하여 CPU를 상대적으로 얼마나 쓸 수 있는지 명시

2.3 도커 이미지

cf. docker search
→ 도커 허브에서 이미지를 검색한다.

• 도커 이미지는 이미지에 대한 정보를 저장하는 매니페스트와, 실제로 이미지에 레이어 파일을 저장하는 바이너리 파일로 나뉩니다.

2.4 Dockerfile

2.4.1 이미지를 생성하는 방법

• 완성된 이미지를 생성하기 위해 컨테이너에 설치해야 하는 패키지, 추가해야 하는 소스 코드, 실행할 명령어와 셸 스크립트 등을 기록해 둔 파일

2.4.2 Dockerfile 작성

[ 주요 명령어 ]

• FROM : 생성할 이미지의 베이스가 될 이미지
• MAINTAINER : 이미지를 생성한 개발자의 정보. 도커 1.13.0 버전 이후로 사용되지 않는다.
• LABEL : 이미지에 추가하는 메타데이터
  • LABEL maintainer "alicek106 <alicek@naver.com> 같이 사용
• RUN : 이미지를 만들기 위해 컨테이너 내부에서 명령어를 실행.
  • RUN ["실행 가능한 파일", "명령줄 인자1", "명령줄 인자2"]
  • 환경변수 사용하기 → ["sh", "-c", "echo $MY_ENV"]
• ADD : 파일을 이미지에 추가. 추가하는 파일은 Dockerfile이 위치한 디렉터리인 컨텍스트(Context)에서 가져온다.
• WORKDIR : 명령어를 실행할 디렉터리. 배시 셸의 cd 명령어와 같다!
  • 즉, WORKDIR을 여러 번 실행하는 것은 cd를 여러 번 실행함과 같다.
• EXPOSE : Dockerfile의 빌드로 생성된 이미지에서 노출할 포트 설정
  • EXPOSE한 포트가 호스트의 포트와 바인딩되는 것은 아니며, 단지 컨테이너의 포트를 사용함을 나타낼 뿐!
• CMD : 컨테이너가 시작될 때마다 실행할 명령어를 설정하며, Dockerfile에서 한 번만 사용 가능하다.

[ 예시 Dockerfile ]

FROM ubuntu:14.04 // 베이스 이미지 설정
MAINTAINER alicek106 // maintainer의 이름 설정 
LABEL "purpose"="practice" // 이미지의 라벨을 설정

RUN apt-get update
RUN apt-get install apache2 -y // 명령어 실행하여 apache 웹서버 설치 
ADD test.html /var/www/html // Dockerfile이 위치한 디렉터리에서 text.html 파일을, 이미지의 /var/www/html 디렉터리에 추가

WORKDIR /var/www/html // 작업 디렉터리 설정
RUN ["/bin/bash", "-c", "echo hello >> test2.html"] // 옮긴 작업 디렉터리에 파일 생성

EXPOSE 80 // 컨테이너가 사용할 포트 지정
CMD apachectl -DFOREGROUND 

2.4.3 Dockerfile의 빌드

docker build -t mybuild:0.0 ./

mybuild:0.0 이라는 이름으로, 현재 위치(./)의 Dockerfile을 빌드!

docker run -d -P --name myserver mybuild:0.0

• -P : 이미지에 설정된 EXPOSE의 모든 포트를 호스트에 연결하도록 설정

docker port myserver

→ 컨테이너와 연결된 호스트의 포트를 확인한다.

docker images --filter ="label=purpose=practice"

→ 라벨로 필터링된 이미지만을 출력!

[ 2.4.3.2 빌드 과정 살펴보기 ]

• 이미지 빌드를 시작하면 도커는 가장 먼저, 빌드 컨텍스트를 읽어 들인다.
  • 빌드 컨텍스트는 이미지를 생성하는 데 필요한 파일, 소스코드, 메타데이터 등을 포함하는 디렉터리
    → Dockerfile이 위치한 디렉터리!
  • 빌드 컨텍스트는 build 명령어의 마지막 위치의 파일을 모두 포함하므로,
    dockerignore 파일을 사용하여 특정 파일을 컨텍스트에서 제외하자!

cf. .dockerignore 예시

test2.html
*.html // 현재_디렉터리/*.html 제외
*/*.html // 현재_디렉터리/*/*.html // 한 디렉터리 레벨 거침
test.htm? // ?자리에 임의의 한 문자 

!test.html // test.html은 제외하지 않는다!

[ Dockerfile을 이용한 생성과 커밋 ]

• 빌드될 때의 각 Step은 Dockerfile에 기록된 하나의 명령어이다.
• ADD, RUN 등 명령어가 실행될 때마다, 새로운 컨테이너가 하나씩 생성되며 이를 이미지로 커밋한다.
  • 즉, Dockerfile에서 명령어 한 줄이 실행될 때마다 이전 Step에서 생성한 이미지에 의해 새로운 컨테이너가 생성되고, Dockerfile에 적힌 명령어를 수행하고 다시 새로운 이미지 레이어로 저장!
  • 따라서, 이미지 빌드가 완료되면 Dockerfile의 명령어 줄 수만큼 레이어가 존재하고, 중간에 컨테이너가 같은 수만큼 생성 및 삭제된다.

[ 2.4.3.3 멀티 스테이지를 이용한 Dockerfile 빌드 ]

하나의 Dockerfile 안에 여러 개의 FROM 이미지를 정의하여,
빌드 완료 시 최종적으로 생성될 이미지의 크기를 줄이는 역할을 하는 것

[ 예시 ]

FROM golang
ADD main.go /root
WORKDIR /root
RUN go build -o /root/mainApp /root/main.go

FROM alpine:latest
WORKDIR /root
COPY --from=0 /root/mainApp . 
CMD ["./mainApp"]

• 두 번째 FROM 아래에서 사용된 COPY 명령어는, 첫 번째 FROM에서 사용된 이미지의 최종 상태에 존재하는 /root/mainApp 파일을 두 번째 이미지인 alpine:latest에 복사한다.
• 이때, --from=0은 첫 번째 FROM에서 빌드된 이미지의 최종 상태를 의미한다!
  • 즉, 첫 번째 FROM 이미지에서 빌드한 /root/mainApp 파일을 두 번째의 FROM에 명시된 이미지인 alpine:latest에 복사한다.

2.4.4 기타 Dockerfile 명령어

• ENV : Dockerfile에서 사용될 환경변수를 지정한다.
  • ${ENV_NAME} 또는 $ENV_NAME의 형태로 사용 가능
• VOLUME : 빌드된 이미지로 컨테이너를 생성했을 때 호스트와 공유할 컨테이너 내부의 디렉터리를 설정합니다.
• ARG : build 명령어를 실행할 때, 추가로 입력을 받아 Dockerfile 내에서 사용될 변수의 값을 설정합니다.
  [ ARG 사용 예시 ]

FROM ubuntu:14.04
ARG my_arg
ARG my_arg_2=value2
RUN touch ${my_arg}/mytouch

→ docker build --build-arg my_arg=/html -t myarg:0.0 ./
→ build 시점에 ARG를 지정!

• USER : 컨테이너 내에서 사용될 사용자 꼐정의 이름이나 UID를 설정하면, 그 아래의 명령어는 해당 사용자 권한으로 실행된다.
  • 기본적으로 컨테이너 내부에서는 root 사용자를 사용한다.
  • 이는 곧 컨테이너가 호스트의 루트 권한을 가질 수 있다는 뜻으로, 보안 측면에서 위험!
  • 가능하다면, 컨테이너 내부에서 새로운 사용자를 생성해 사용하자.

[ USER 사용 예시 ]

RUN groupadd -r author && useradd -r -g author alicek106
USER alicek106

• ONBUILD : 빌드된 이미지를 기반으로 하는 다른 이미지가 Dockerfile로 생성될 때, 실행할 명령어를 추가합니다.
• STOPSIGNAL : 컨테이너가 정지될 때 사용될 시스템 콜의 종류를 지정합니다.
• HEALTHCHECK : HEALTHCHECK는 이미지로부터 생성된 컨테이너에서 동작하는 애플리케이션의 상태를 체크하도록 설정합니다.
• SHELL : 사용하려는 셸을 따로 지정
  • ex. SHELL ["/usr/local/bin/node"]
• COPY : 로컬 디렉터리에서 읽어들인 컨텍스트로부터 이미지에 파일을 복사하는 역할
  • ADD는 외부 URL 및 tar 파일에서도 파일 추가가 가능하다는 차이!
  • 로컬 컨텍스트로부터 직접 추가한다는 면에서, 빌드 시점에서 어떤 파일이 추가될지 명확하기에 COPY 가 권장된다!

[ 2.4.4.4 ENTRYPOINT, CMD ]
< ENTRYPOINT와 CMD의 차이점 >

• ENTRYPOINT는 커맨드와 동일하게, 컨테이너가 시작될 때 수행할 명령을 지정
• 그러나, entrypoint는 커멘드를 인자로 받아 사용할 수 있는 스크립트의 역할을 할 수 있다.

docker run -i -t --name no_entrypoint ubuntu:14.04 /bin/bash

→ entrypoint 없음
→ cmd : /bin/bash

docker run -i -t --entrypoint="echo" --name yes_entrypoint ubuntu:14.04 /bin/bash
/bin/bash

→ entrypoint : echo
→ cmd : /bin/bash

=> entrypoint가 설정되면, run 명령어의 마지막에 입력된 cmd를 인자로 삼아 명령어를 출력한다.
=> echo /bin/bash가 된 것!

[ JSON 배열 형태와 일반 형식의 차이점 ]

• CMD 또는 ENTRYPOINT에 설정하려는 명령어를 /bin/sh 로 사용할 수 없다면 JSON 배열의 형태로 명령어를 설정해야 한다.
  • JSON 배열 형태가 아니도록 사용하면 실제 실행시 /bin/sh -c 가 추가되기 때문!

2.4.5 Dockerfile로 빌드할 때 주의할 점

[ 잘못된 사용 방식 ]

FROM ubuntu:14.04
RUN mkdir /test
RUN fallocate -l 100m /test/dummy
RUN rm /test/dummy

• 위 이미지의 크기는 ubuntu14:04 이미지에 100m를 더한 약 290m
• 파일을 삭제했지만, 용량이 큰 것.
• 이는 컨테이너를 이미지로 생성할 때 컨테이너에서 변경된 사항만 새로운 이미지 레이어로 생성하는 방식의 단점 중 하나이다.
  → RUN rm /test/dummy 로 파일 삭제해도, 이는 "파일을 삭제했다"라는 변경사항으로서의 레이어로 새로 저장될 뿐, 실제 100m 크기의 파일은 이전 레이어에 남음!
  → 실제로 컨테이너에서 사용하지 못하는 파일이 이미지 레이어로 존재하기에, 의미가 없는 저장 공간일 수 있다.

→→ Dockerfile 작성 시에 &→으로 각 RUN 명령을 하나로 묶자.
→→ RUN 하나가 하나의 이미지 레이어이므로!

2.5 도커 데몬

2.5.1 도커의 구조

도커는 실제로 어디에 있을까?

which docker 
// /usr/bin/docker

실행 중인 도커 프로세스 확인

ps aux | grep docker
..... /usr/bin/dockerd -H fd://

→ 컨테이너나 이미지를 다루는 명렁어는 /usr/bin/docker에서 실행되지만, 도커 엔진의 프로세스는 /usr/bin/dockerd 파일로 실행된다.
→ 이는 docker 명령어가 실제 도커 엔진이 아닌, 클라이언트로서의 도커이기 때문!

[ 도커 서버 ]

• 도커 서버는 실제로 컨테이너를 생성하고, 실행하며 이미지를 관리하는 주체
• dockerd 프로세스로서 동작한다.
• 도커 엔진은 외부에서 API 입력을 받아, 도커 엔진의 기능을 수행하는데,
  도커 프로세스가 실행되어 서버로서 입력을 받을 준비가 된 상태를 도커 데몬이라고 한다.

[ 도커 클라이언트 ]

• 도커 데몬은 API 입력을 받아 도커 엔진의 기능을 수행하는데, 이 API를 사용할 수 있도록 CLI를 제공하는 것이 도커 클라이언트!
• 사용자가 docker로 시작하는 명령어를 입력하면, 도커 클라이언트를 사용하는 셈!
• 도커 클라이언트는 입력된 명령어를 로컬에 존재하는 도커 데몬에게 API로서 전달한다.
• 이때 도커 클라이언트는 /var/run/docker.sock에 위치한 유닉스 소켓을 통해 도커 데몬의 API를 호출한다.
• 도커 클라이언트가 사용하는 유닉스 소켓은 같은 호스트 내에 있는 도커 데몬에게 명령을 전달할 때 사용!

[ docker 명령어 입력할 때의 과정 ]
1. 사용자가 docker ps 같은 명령어를 입력
2. /usr/bin/docker 는 /var/run/docker.sock 유닉스 소켓을 사용해 도커 데몬에게 명령어를 전달
3. 도커 데몬은 이 명령어를 파싱하고, 해당하는 작업을 수행
4. 수행 결과를 도커 클라이언트에게 반환하고, 사용자에게 결과를 출력.

2.5.2 도커 데몬 실행

우분투에서는 도커가 설치되면 자동으로 서비스로 등록된다!

service docker start
service docker stop 

service docker stop // 도커 서비스를 정지한 뒤
dockerd // 명령어로 직접 도커를 실행하는 방식
...
...
// API listen on /var/run/docker.sock

2.5.3. 도커 데몬 설정

dockerd --help

[ 2.5.3.1 도커 데몬 제어: -H ]

• 도커 데몬의 API를 사용할 수 있는 방법을 추가
  cf. 아래 두 명령어는 동일하다.

dockerd
dockerd -H unix:///var/run/docker.sock  // 도커 클라이언트 /usr/bin/docker를 위한 유닉스 소켓 /var/run/docker.sock

• -H 옵션에 IP 주소, 포트 번호를 입력하면 원격 API인 Docker Remote API로 도커 제어가 가능하다.

dockerd -H tcp://0.0.0.0:2375

→ remote API를 위한 바인딩 주소를 입력하면 유닉스 소켓은 비활성화
→ 도커 클라이언트를 사용할 수는 없어진다 (docker ~ 명령어 사용 불가)
→ 일반적으로, 아래와 같이 도커 클라이언트를 위한 유닉스 소켓과 Remote API를 위한 바인딩 주소를 동시 설정

dockerd -H unix:///var/run/docker.sock -H tcp://0.0.0.0:2375

[ 2.5.3.3 도커 스토리지 드라이버 변경 : --storage-driver ]

< cf. 스토리지 드라이버의 원리 >

• 이미지는 읽기 전용 파일로 생성되고, 컨테이너는 이미지 위에 얇은 컨테이너 레이어를 생성하며 컨테이너의 고유한 공간을 생성한다 (기본 개념!)
• 실제로 컨테이너 내부의 읽기와 새로운 파일 쓰기, 기존의 파일 쓰기 작업이 일어날 때는 Copy-On-Write(CoW), Redirect-on-Write(RoW) 개념을 사용.

cf. 스냅숏(snapshot)은 "원본 파일은 읽기 전용으로 사용하되 이 파일이 변경되면 새로운 공간을 할당한다"는 개념!
→ 애플리케이션이 스냅숏의 A 파일에 쓰기 작업을 수행해야 한다면,
원본 파일을 유지하면서도 변경사항을 저장할 수 있어야 한다.
→ 이를 해결하는 방식에 따라 CoW, RoW로 나뉨!

< CoW >

• 스냅숏의 파일에 쓰기 작업을 숭해라 때 스냅숏 공간에 원본 파일을 복사한 뒤 쓰기 요청을 반영함
• 이 과정에서, 복사하기 위해 파일을 읽는 작업, 파일을 스냅숏 공간에 쓰고 변경사항을 쓰는 작업, 총 2번의 쓰기 작업이 발생 → 오버헤드가 발생!

< RoW >

• 한 번의 쓰기 작업만 발생
• 스냅숏에 기록된 원본 파일은 스냅숏 파일로 묶은(Freeze)한 뒤 변경사항을 새 장소에 할당받아 저장

2.5.4 도커 데몬 모니터링

[ 2.5.4.2 events, stats, system df 명령어 ]

docker events
docker system events

→ 도커 데몬이 수행한 명령어의 결과를 실시간으로 보여줌!

docker stats

→ 실행 중인 모든 컨테이너의 자원 사용량을 스트림으로 출력!

docker system df

→ 도커에서 사용하고 있는 이미지, 컨테이너, 로컬 볼륨의 총 개수 및 사용 중인 개수, 크기, 삭제함으로써 확보 가능한 공간을 출력.