W12 Container & Docker

12주차에 진행되었던 컨테이너/도커의 학습 내역을 정리하였습니다

Container & Docker 예습

Docker

What is Docker?

Overview

• What is Container & What problem solve?
• Container Repository
  • A storage for containers.
• DEVELOP application
  • How D. can make dev process much easier&efficient
• DEPLOY application
  • How D. solve prbms.

What is a Containers?

• a Con;
  • a way to package apps w/ all nessary dependencies&configuration
  • Portable Artifact, easily shared&moved around btw dev<>ops team
  • Makes dev process much efficient
    • portabilty+packed in isolated envr

Where do containers live?

• Container Repository
• Private repositories
• Public repositores for D. > DockerHub

How containers improved..

App Development

• BC (Before Container)
  • 개발 및 구동에 필요한 모든 패키지를 로컬 환경에 설치
  • 각 OS 환경에 따라 설치 과정이 상이함
  • 실수할 수 있는 많은 중간단계(커맨드누락등)
• AC (After Con)
  • Image 기반 별개의 독립된 환경구축
  • 필요한 구성이 설정된 패키지
  • 1개의 Docker Command로 환경 설치 가능
  • 버전이 다른 2개의 앱을 동시 실행 가능

Again,

• BC
  • Dev;
    • Produce Artifact w/setup-guide,conf,db,etc…
  • Ops;
    • Do configuration
  • 사용에 필요한 서버에 직접 설치
  • 버전 종속성 충돌 발생
  • 텍스트 가이드에 의존; 전달부족으로인한 충돌
• AC
  • Dev&Ops
    • 모든 종속성 및 연관 구성을 한 컨테이너에 통합
    • Docker 실행을 제외한 서버의 환경구성 필요성 X

---

What is Con?

• Layers of images
• bottom; Linux Base Image, cuz small in size
• top; Application Image that u need

• btw; as u needed

• Can download from DockerHub
  • docker run {packagename}:{version}
  • Seperate images are downloaded
    • ADV; only diff. images downloaded
  • docker ps
    • 가동중인 컨테이너 조회

Image	Container
Packages	started App
artifact,\n can be moved around	container environment created
NOT RUNNING	RUNNING

---

Docker vs Virtual Machine

1. Kernel communc8s w/HW
2. Apps run on Kernel layer
   • Same Linux kernel, implemented diff apps > devian/rhel

Docker

• Virtualize on applications layer
• Do not have its own kernel; use its host OS kernel

VM

• has apps AND its own kernel
• virtualize complete OS; use own OS kernel

1. Size; Docker image much smaaller
2. Speed; Docker containers start&run much fast
3. Compatibility; VM of any OS can run on any OS host
   • D. CANNOT run linux based apps on window host w/o other tools(Docker Toolbox)

---

Docker installation 9(for Linux,32:05)

공식문서 해설이라서 필요할때 문서보고 진행하면될듯
중요한건 자체적으로 도커 실행되지않는 환경에선 Docker ToolBox 필요함 https://docs.docker.com/engine/install/ubuntu/

---

Basic Comman

Overview

• Container vs Image
• Version and Tag
• Docker Commands
  • docker pull
  • docker run
  • docker start
  • docker stop
  • docker ps
  • docker exec -it
  • docker logs

Container vs Image

• CONTAINER is a running environment for IMAGE
• docker pull redis > 특정 app image 다운
• docker images > 다운로드한 이미지 조회
• docker run redis > 특정 app 실행(컨테이너)
• docker ps > 가동중인 컨테이너 조회
• docker run -d redis > detach 상태로 실행(ps로 조회는 가능, 가동중X)
• docker stop {container ID} > 컨테이너 중지
• docker start {container ID} > 컨테이너 시작(=합쳐서 재시작)
• docker ps -a > 가동중+중지된 컨테이너 조회

만약 필요로 인해 서로다른 redis 어플리케이션을 동시에 실행해야한다면?

• docker run redis:4.0 > 이미지를 가져오고(pull), 컨테이너 시작
• docker ps > 서로다른 redis image 기반 2개의 컨테이너 작동확인
  • 동일한 port(6379/tcp)에서 작동 중

---

CONTAINER Port vs HOST Port

Num	Host	Container
1	5000	5000
2	3000	3000
3	3001	3000

• Multiple containers can run on host machine
• Your laptop has only certain ports available
• Conflict when same port on host machine
  • Case1, The port is already bound or in use
  • Case2,3, Works well
• docker run -p{Host port}:{Container port}
• docker run -p6000:6379 redis
• docker run -p6000:6479 redis:4.0 > ERROR; port already bound
• docker run -p6001:6479 redis:4.0 > Running well

---

Debugging Containers

• docker logs {Container ID}or{Container Name}
  • 컨테이너 이름은 ps시 제일오른쪽에 있음, 기본적으로 랜덤생성

• docker run -d -p6001:6379 –name redis-older redis:4.0

• docker exec
  • 특정 Con.에 문제발생, 터미널 화면으로 진입하고싶다;
  • 내부 디렉토리, 로그파일, 설정 구성, 환경변수 확인 등
• docker exec -it {Con. ID} /bin/bash
  • Interacive Terminal
  • 대부분의 컨테이너이미지는 Lightweight Linux distributuon 기반
  • 대부분의 명령어는 사용안된다고 봐야함 (curl,ifconfig, etc.)

Docker run vs start

• run
  • create new Con. from Image
  • > Create a new Con.
• start
  • not working w/images
  • working w/containers
  • > Restart a stopped Con.

---

Demo Project

Overview

• Development
• Continuous Integration/Delivery
• Deployment

Workflow w/D.

1. JavaScriptApp 개발
   • 랩탑에서 로컬, JS앱 개발 중 + 도커의 몽고DB 연계
   • 초기 개발 완료 또는 테스터팀에게 테스트 맡길 예정
   • JS앱을 Git과 같은 버전관리 시스템에 커밋
2. JS앱 구성 및 도커 이미지 생성
   • Jenkins 같은 CI 도구가 사용됨
   • Artifact 기반 JS앱 구성 및 도커이미지 생성
   • Private D. 저장소로 생성된 D. 이미지 PUSH (타인에게 노출방지)
3. Dev 서버에 배포
   • Dev 서버가 사설저장소에서 JS앱의 D. 이미지 Pull
   • Dev 서버가 DockerHub에서 MongoDB 이미지 Pull
   • 두개의 컨테이너의 상호작용으로 JS앱 가동
   • 테스터나 다른 개발자가 Dev서버에 접속해서 JS앱 테스트 가능

---

Develop w/Con.

Overview
로컬 개발과정에서의 도커 사용예시

1. JS&Nodejs application 구성
2. MongoDB 도커 컨테이너에 연결

• JS앱 부분은 깃허브에 코드공개되어있음

• 대충 작동은 하는데 DB없어서 설정변경해도 저장X

• docker pull mongo
• docker pull mongo-express
• 먼저 저 두 몽고DB 관련 앱 사이에 연결을 만들어야한다

---

Docker Network

• 도커는 격리된 도커 네트워크를 구성함
• 두개의 컨테이너를 구성할시, 같은 N/W상에 있기 때문에 컨테이너 이름으로 연결됨
• 외부의 앱은 Host의 포트번호로 D. N/W와 연결되어야함

• 배포 단계시, Nodejs도 막 뭐 HTTP등 인덱스 포함해서 이미지화

• 웹브라우저가 이에 접속

• docker network ls > 현재 네트워크 상황조회
• docker network create mongo-network

몽고 컨테이너 생성

• docker run -p 27017:27017 -d -e MONGO_INITDB_ROOT_USERNAME=admin -e MONGO_INITDB_ROOT_PASSWORD=password –name mongodb –net mongo-network mongo
  • 환경변수 설정은 참조
• 읽을수 있게 입력하려면, docker run -d \ -p ~ \ -e ~ 식으로 입력
• docker logs {Con. ID} > 생성기록확인

몽고 익스프레스 컨테이너 생성 및 연결

• 몽고익스프레스
• 어드민 계정정보는 입력안할시 덮어씌움, 설정필요
• 포트번호는 냅둠 (동일)
• 서버 네트워크 지정
• docker run -d -p 8081:8081 -e ME_CONFIG_MONGODB_ADMINUSERNAME=admin -e ME_CONFIG_MONGODB_ADMINPASSWORD=password –net mongo-network –name mongo-express -e ME_CONFIG_MONGODB_SERVER=mongodb mongo-express
• 쓰읍.. 가상머신의 0.0.0.0:8081에서만 접속되겠구나..
• 아모튼 node.js쪽에는 다 되어있으니까 작동해보면 다 잘될거임
• 이것저것 설정값 입력해보고 변경하고 docker logs로 확인해보면 조회가능

---

Docker compose

• 플레이북 같은거
• 커맨드의 내용을 입력해놔서 편하게편하게

• 네트워크는 입력하지않는다, 자체 네트워크를 생성함

• docker-compose -f mongo.yml up
  • -f = file
• docker network로 조회시 새로운 N/W가 생성되어있음

• 연결이 필요한 컨테이너의 경우 실행순서를 조정할 수 있음

• 컨테이너 재시작시 내부의 설정값 같은 데이터는 초기화됨
  • Docker Volumes for Data Persistence! (later)
• docker-compose -f mongo.yml down
  • 모든컨테이너+네트워크 종료 후 삭제

---

Dockerfile

원래는;

• Git에 Dockerfile을 커밋하면, Jenkins가 자동으로 이미지화 하여 Repo로 보냄
• 해당 과정을 수동으로 해볼것임.

To build image from an app…

• Copy the contents of app (jar,war,bundle.js)
• To do above, Need blueprint for building images(=dockerfile)

# The name MUST BE "Dockerfile"
FROM node:13-alpine

ENV MONGO_DB_USERNAME=admin \
    MONGO_DB_PWD=password

RUN mkdir -p /home/app

COPY . /home/app

CMD ["node", "server.js"]

How to make?

1. FROM; Start by basing it on another image
   • 지금 경우, linux alpine 대신 node부터 시작
2. ENV; Optionally define environmental variables
   • 가능하면 Image외부에 변수를 설정하는게 관리하기에 쉽긴함
3. RUN; execute any Linux command
   • 컨테이너 내부에서 실행됨
4. COPY; executes on the HOST machine
   • 컨테이너 외부, HOST에서 받아옴
5. CMD; 흠 기반 이미지의 명령어를 실행하고 싶을때?
   • CMD=entry point command <> can have multiple RUN commands
   • 엔트리 포인트가 머야

• 공식문서에 있는 태그들도 눌러보면 해당 Dockerfile로 연결됨

---

Image Layers

• app:1.0 > Current APP, FROM node:13-alpine
• node:13-alpine > FROM alpine:3.10
• alpine:3.10

---

build an Image using Dockerfile

• docker build -t my-app:1.0 .
  • tag&dockerfile location
• docker images
• docker run my-app:1.0
  • CMD [“node”, “server.js”]>CMD [“node”, “/home/appserver.js”]
  • When you ADJUST the Dockerfile, you MUST REBUILD THE IMAGE!
• docker rmi {Image ID from ‘docker images’}
• docker rm {Con. ID}
• 다시 build하고 run
• docker exec -it {container ID} /bin/sh
  • /bin/bash가 모든 컨테이너에서 활성화된건 아님
  • env 명령어로 내부에 설정된 환경변수 조회가능
  • 뭔가 옮겨넣을 내용이 많다면 compress해서 artifact화 한다음에 그거를 이미지로 쓰는것도 가능
    • 아티팩트는 뭐에요 노드js용어인가

---

서버 가상화 VS 컨테이너 가상화

서버 가상화

• 서버 가상화=전가상화=가상머신(VirtualBox,Vmware)
• 하드웨어 수준 가상화
• 가상화도구(Hypervisor)를 사용하여 다수의 Physical GUEST OS(Linux) 구현
  • 장점: 자체 OS를 포함한 모든 구성요소를 사용할 수 있는 완전한 머신임
  • 단점: OS위에 추가적인 독립 OS들을 구성하기 때문에 리소스의 낭비(운영간접비,Overhead) 발생 Guest 1의 resouce(CPU, RAM, 등)가 사용되지않더라도 Guest 2가 해당 리소스를 사용하지 못함

컨테이너 가상화

• 컨테이너 가상화=컨테이너(Docker, k8s?)
• OS 수준 가상화
• 컨테이너(Container S/W)를 사용하여, 다수의 격리된 Logical 어플리케이션 환경 구현
  • 장점: 단일 어플리케이션 구동을 위한 최소한의 환경만 구분 > 빠른 속도
  • 단점: VM 처럼 다양한 OS 사용 불가, 컨테이너간 격리되어있지않음

컨테이너는 어떻게?

• LXC (Linux Container)에서 부터 발전해옴
  • chroot: 특정 디렉토리를 root(최상위 디렉토리)로 인식하게 함.
  • Name Space: 리눅스 시스템자원을 묶어 프로세스에 할당함.
  • cgroup: 특정 애플리케이션이 CPU와 메모리같은 특정자원을 과다하게 사용하는것을 방지.
• 특정 root 디렉토리를 생성하고, 자원을 할당하고, 제어함.

Docker

리눅스 컨테이너를 이용하여 프로세스 단위별 가상화 실행 환경을 제공하는,
Hypervisor보다 가벼운 경량 가상화 기술

특징

• 가상 OS를 설치하지 않음 - 호스트에서 바로 컨테이너 실행
• 호스트와 컨테이너의 성능 차이가 유사 - 오차범위 안
• 이미지 생성과 배포에 특화 - 도커 허브 제공

아키텍쳐(구조)

• 도커 이미지
  • 서비스 운영에 필요한 프로그램, 코드, 실행파일을 묶은 형태
  • 저장소(도커 허브)에서 올리고 내려 받는 것이 도커 이미지
• 컨테이너
  • 이미지를 실행한 상태(이미지-컨테이너는 실행파일-프로세스 관계)
  • 이미지로 여러개의 컨테이너 생성 가능
• 도커 허브
  • 도커 이미지 레파지토리

설치 및 명령어

도커 설치 방법

• yum 관리도구 설치
  yum install -y yum-utils
• 도커 관련 레포지토리 추가
  yum-config-manager –add-repo https://download.docker.com/linux/centos/docker-ce.repo
• 도커 설치
  yum install docker-ce docker-ce-cli containerd.io
• 도커 시작 및 활성화
  systemctl enable docker –now
• 도커 설치 및 시작 확인 systemctl status docker
  docker –version

도커 명령어

• 도커허브에서 이미지 검색
  docker search 이미지명
• 이미지 다운로드
  docker pull 이미지명:태그
• 이미지 리스트 확인
  docker image ls or docker images
• 이미지 ID 리스트 확인
  docker image ls -q or docker images -q
• 이미지 삭제
  docekr image rm [-f] 이미지명
  => -f 옵션은 컨테이너가 실행되었던 이미지 삭제시
• 컨테이너가 실행되지 않았던 이미지 삭제
  docker image prune –all
• 컨테이너가 실행되었던 이미지 삭제
  docker image rm -f $(docker images -q)
• 이미지 백업
  docker save -o 백업파일명 이미지명 이미지명 ….
• 이미지 백업 파일 해제
  docker load -i 백업파일명
• 컨테이너 생성 및 실행
  docker run [option] –name 컨테이너명 이미지:태그 command
  옵션
  -it : 입력값과 출력값이 필요로 하는 컨테이너 경우에 붙임
  -d : attach를 실행하지 않고 백그라운드로 실행만 시킬 경우에 붙임
• 컨테이너 list 확인 docker ps [-a]
  -a : 종료된 컨테이너까지 확인
• 컨테이너 삭제
  docker container rm [-f] 컨테이너명
  -f : 실행되고 있는 컨테이너 삭제시 붙임
• 컨테이너 시작 및 정지
  docker container start / stop 컨테이너명
• 컨테이너 및 이미지 스펙 확인
  docker inspect 컨테이너명/이미지명
• 컨테이너 리소스 확인
  docker stats {–no-stream} : 1회성으로 띄울 때
• 컨테이너 리소스 제한
  docker run –cpus (0.0~1.0) –memory (메모리크기) [옵션] –name 컨테이너명 이미지명:태그
• 컨테이너 리소스 변경
  docker update –cpus or –memory (limit 제한) 컨테이너명
• 컨테이너 PID 확인
  docker top 컨테이너명
• 컨테이너 빠져나오기
  ctrl p q 차례대로 입력
• 컨테이너 재진입
  docker attach 컨테이너명
• 컨테이너 분리모드로 실행
  docker exec -it 컨테이너명 실행명령어
  => -it 오는 경우는 shell 명령어 실행시 second 설정으로 스냅샷

Docker 명령어

• 도커 파일 복사
  • 컨테이너 -> 호스트
    • docker container cp 컨테이너명:PATH 호스트 PATH
  • 호스트 -> 컨테이너
    • docker container cp 호스트_PATH 컨테이너명:PATH
• 컨테이너 파일 변경 현황
  • docker diff 컨테이너명
• 도커 볼륨
  • bind-mount
    • docker run [옵션] -v 호스트_PATH:컨테이너_PATH 컨테이너명
  • volume 생성
    • docker volume create 볼륨명
    • ls /var/lib/docker/volume/볼륨명/_data
  • volume 마운트
    • docker run [옵션] 볼륨명:컨테이너_PATH 컨테이너명
  • volume 리스트 확인
    • docker volume ls

Docker 기본 구조

• Docker Client
• Docker Host
  • Engine
  • Container Runtime(containerd, runC)
  • image registry
• Registry
  • Docker Hub
  • Private Registry(직접 구성, AWS, GCP…)

컨테이너 구동을 위한 리눅스 기반기술

• cgroup
• namespace : PID(Process), Network, UID(User ID), Mount, UTS(Hostname), IPC
• chroot

Docker 설치 docs.docker.com

이미지 관리 (docker image)

• 이미지 다운로드 (pull)
• 이미지 목록 확인 (ls)
• 이미지 삭제 (rm)

컨테이너 관리(docker container)

• 생성(create) - 시작(start) - 중지(stop) - 삭제(rm)
• docker container run / docker run (create+start)
• 컨테이너 생성 및 시작 시 주요 옵션 -i, –interactive : Interactive, 표준입출력(STDIN,STDOUT) 채널을 오픈
  -t, –tty : TTY, Terminal, 사용자가 터미널을 사용하여 연결할 수 있도록
  -d, –detach : 백그라운드(run) 실행
  -a, –attach : 포그라운드(start) 실행
  -n, –name : 컨테이너 이름 지정
• 컨테이너 동작중 중지, 재시작, 일시정지 등 가능 stop, restart, pause, unpause
• 실행중인 컨테이너 제어 docker attach : 현재 컨테이너의 메인 프로세스에 연결
  docker exec : 별도의 프로세스를 실행하여 연결 /bin/sh, /bin/bash
  docker logs : 컨테이너의 로그 확인
  docker top : 컨테이너 내 프로세스 확인

볼륨

• Bind Mount
• Docker Volume
• tmpfs

참고) 컨테이너 전체 삭제(실행중+중지상태) $ docker rm -f $(docker ps -aq) $ docker rm -f `docker ps -aq`

도커 네트워크

Docker에서는 기본적으로 컨테이너가 사용할 수 있는 Bridge를 제공(docker0)
docker0는 172.17.0.0/16 네트워크 주소를 사용
기본 docker0 bridge를 사용할 경우는 veth를 생성하여 사용
기본 bridge 이외에도 다양한 유형의 네트워크 사용 가능

Docker에서 사용할 수 있는 네트워크 유형 Bridge: 기본적으로 생성된 docker0 브리지를 사용하여 컨테이너의 외부 연결 제공. 사용자가 직접 생성 가능
Host: Docker Host의 네트워크 설정을 그대로 사용
Null : 네트워크 인터페이스를 사용할 필요가 없는 컨테이너에 사용
macvlan : 호스트의 네트워크와 동일한 위치에 가상 네트워크 인터페이스를 생성
macvlan 사용시 필요조건 : Promiscuous mode 활성화
overlay : 컨테이너 클러스터 환경에서 사용
container : 다른 컨테이너의 네트워크 설정을 공유

사용자에 의한 Docker Network 개체 생성 $ docker network create –driver=[TYPE] [NETWORK이름]

Bridge

예시$ docker network create --driver bridge mybridge1
예시$ docker network create --driver bridge --subnet 192.168.200.0/24 --gateway 192.168.200.1 mybridge2

옵션
–driver: 사용할 네트워크 유형 선택
–subnet: bridge 내부에서 사용할 네트워크 IP 범위
–gateway: bridge 내부에서 외부로 패킷을 보내기 위한 경로. subnet 범위 내

macvlan

$ ip link set enp0s8 promisc on // promiscuous mode 활성화 $ docker network create --driver=macvlan 예시$ docker network create --driver macvlan --gateway 192.168.56.1 --subnet 192.168.56.0/24 --ip-range 192.168.56.192/26 -o parent=enp0s8 mymacvlan

옵션
–gateway : 동일
–subnet : 동일
–ip-range : 실제 컨테이너의 NIC에 할당할 IP주소의 범위
-o parent : 호스트 시스템의 NIC중 macvlan으로 연결할 네트워크를 사용중인 NIC

네트워크 설정 변경(실행중인 컨테이너의 네트워크 변경)
docker network connect
docker network disconnet

사용자 생성 Bridge의 특징

• network-alias 기능이 제공
• 내부적인 DNS가 생성 (기본 docker0 브리지에는 없음)

컨테이너 이름을 사용한 주소 확인
–link <컨테이너명>[:별칭]

DNS를 사용한 주소 확인 (별도의 bridge 생성 시)

• 따로 설정하지 않아도 컨테이너 이름을 사용한 이름 변환 가능
• 각 bridge 내 DNS 서버 동작 (127.0.0.11)

network-alias
해당 이름을 사용하는 다수의 컨테이너를 지정

network-alias 를 지정한 컨테이너 실행

$ docker run -d --name web1 --network mybridge1 --network-alias websvc httpd
$ docker run -d --name web2 --network mybridge1 --network-alias websvc httpd
$ docker run -d --name web3 --network mybridge1 --network-alias websvc httpd

테스트용 컨테이너 생성
$ docker run -it --rm --network mybridge1 travelping/nettools

테스트

$ nslookup web1.
$ nslookup web2.
$ nslookup web3.
$ nslookup websvc.

컨테이너 이름 관련 옵션
docker run 실행 시 –hostname 옵션: 컨테이너의 hostname 지정
docker run 실행 시 –dns 옵션: 컨테이너 내부에서 사용할 DNS 지정

이미지 관리

• 이미지 생성(직접 생성, 코드에 의한 관리 IaC)
• 이미지 내보내기
• 이미지 가져오기

• 이미지 업로드

• Snowflake Server Snowflake : 눈송이
  사용자에 의해서 지속적으로 관리가 수행되는 서버

• Phoenix Server Phoenix : 불사조
  서버의 상태를 이미지화하는 서버

Docker의 이미지 Layer 구조

• Union Filesystem
  • 하나의 지점에 여러 디렉토리를 마운트 할 수 있는 파일시스템
  • 겹치는 부분이 있을 경우, 층 구조에서 상단에 위치한 층의 정보를 사용
  • 대표적인 Union Filesystem
    • UnionFS
    • AUFS(Advanced multi-layered Unification File System)
    • BTRFS
    • ZFS
    • OverlayFS(v1/v2)

OverlayFS

• Union Filesystem을 구현한 파일시스템

• lsmod

  grep overlay

• 기본구조
  • lower : 아래쪽 층들의 모임, 절대 수정되지 않음
  • upper : 겹침 구조의 최상층, 실제 수정이 반영되는 부분
  • merge : lower+upper 겹쳐서 보는 통합 View
  • work : 겹침 구조의 병합 작업등을 위하여 사용되는 임시공산

OverlayFS 테스트

1. 마운트용 디렉토리 생성
   • mkdir /overlay
   • cd /overlay/
   • mkdir lower upper merge work
2. 테스트용 파일 생성
   • echo Hello > lower/fileA
   • echo World > upper/fileB
3. OverlayFS 마운트
   • mount -t overlay overlay -o lowerdir=lower/,upperdir=upper/,workdir=work/ merge/
   • mounr -t [TYPE] -o [옵션] <원본> <마운트포인트>
4. 마운트 상태 및 파일 상태 확인
   • ls -l lower
   • ls -l upper
   • ls -l merge
5. lower에 존재하는 fileA 파일을 마운트 된 merge를 통해 접근하여 수정 및 확인
   • echo merong » merge/fileA
   • ls -l merge/
   • cat merge/fileA
   • ls -l lower/
   • cat lower/fileA
   • ls -l upper/
   • cat upper/fileA
     • 결론: lower의 파일은 수정되지 않고, upper에 수정된 파일이 생성되며, merge에서는 upper의 파일이 노출됨
6. upper에 존재하는 fileB 파일을 마운트 된 merge를 통해 접근하여 수정 및 확인
   • echo merong » merge/fileB
   • ls -l merge/
   • cat merge/fileB
   • ls -l lower/
   • ls -l upper/
   • cat upper/fileB
     • 결론: lower는 upper에만 존재하는 파일과 무관하며, upper에만 존재하는 파일은 upper에서 수정됨
7. lower에 존재하는 fileA 파일을 merge를 통해 접근하여 삭제
   • rm merge/fileA
   • ls -l merge/
   • ls -l lower/
   • cat lower/fileA
   • ls -l upper/
     • 결론: lower에 존재하는 파일을 삭제할 경우, merge에 파일이 노출되지 않도록 upper에서 masking을 위한 Character 장치파일(c)을 생성. merge에는 해당 파일이 노출되지 않음
8. upper에 존재하는 fileB 파일을 merge를 통해 접근하여 삭제
   • rm merge/fileB
   • ls -l merge/
   • ls -l lower/
   • ls -l upper/
     • 결론: upper에만 존재하는 파일을 삭제할 경우 lower는 무관하며, upper에서 직접 파일이 삭제됨

이미지 생성

태그 docker image tag : 이미지 태그 생성 (기존 이미지의 정보와 동일)

현재 사용중인 컨테이너를 이미지화 docker container commit <원본컨테이너> <생성할이미지명>[:태그] 원본 이미지의 정보를 그대로 생성할 이미지로 전달 기존 컨테이너 생성 시 사용한 이미지의 레이어 정보도 그대로 유지

옵션 -a, –author : 작성자 지정
-m, –message : 별도로 추가하고 싶은 메시지 입력
-c, –change : 이미지와 관련된 설정 변경
-p, –pause : 이미지 작성 시 컨테이너 일시 중지 후 작성

이미지 내보내기 / 가져오기

현재 Docker Host(Docker Engine)에 저장되어 있는 이미지를 파일로 내보내기
파일 형태로 저장되어 있는 이미지를 이미지로 불러오기
컨테이너 -> 파일(export), 이미지 -> 파일(save)

<export/import>

• 컨테이너를 파일로 내보내기
  • docker container export <컨테이너명> > <파일명>
  • docker container export <컨테이너명> -o <파일명>
  • 내보내기 시는 tar 아카이브 파일로 생성
• export 한 파일을 이미지로 저장하기
  • docker image import <이미지명>[:태그]
    • 옵션
    • -m, –message : 메시지 추가
    • -c, –change : 이미지 속성 정보 추가

export/import의 경우 이미지의 계층 정보 및 이미지의 속성정보 등이 모두 남아있지 않고, 현재 컨테이너의 파일시스템 내의 데이터만 파일로 저장하므로, 해당 이미지를 사용하여 컨테이너를 구동하기 위해서는 필요한 구성 설정을 직접 추가하여야 함 (-c, –change 옵션 사용)

<save/load>

• 이미지를 파일로 내보내기
  • docker image save <이미지이름>[:태그] > <파일명>
  • docker image save <이미지이름>[:태그] -o <파일명>
• 파일을 이미지로 가져오기
  • docker image load -i <파일명>

save/load의 경우 이미지의 계층(layer) 정보 및 이미지의 속성정보(manifest) 등을 모두 포함한 형태로 저장하기 때문에, 이미지를 다시 load 하였을 때 정보가 그대로 유지됨

• Dockerfile을 사용한 이미지 작성
  • 이미지 작성 시, 코드에 의해 이미지를 작성하도록 하는 방법
  • 기본 파일명 Dockerfile (필요시 변경 가능)
  • docker image build 명령어를 사용하여 Dockerfile 내용에 따른 이미지 빌드
  • docker image build -t <생성할이미지명>[:태그]
    • 옵션: -f, –file: Dockerfile 대신 사용할 이름

Dockerfile

• 기본 이미지: ubuntu, centos, busybox 등등…
• 이미지에 추가, 수정할 파일
• 실행할 명령
  • 이미지를 만드는 과정에서 실행할 명령
  • 만들어진 이미지로 컨테이너를 구동하는 과정에서 실행할 명령
  • 만들어진 이미지를 사용하여 다시 이미지를 빌드할 때 실행할 명령
• 네트워크 정보: 컨테이너에서 노출할 포트 정보
• 볼륨 정보: 컨테이너에서 사용할 볼륨
• 기본정보: 컨테이너 작성자
• 환경변수: 이미지 실행시 사용자화(Customization)를 위한 환경변수 지정
• 사용자: 컨테이너 내에서 명령을 실행할 사용자 지정
• 실행위치: working directory 지정

Dockerfile에서 사용하는 예약어

1. 베이스 이미지 (기본 이미지): FROM
   • 사용법
   • FROM <이미지명> // latest 태그를 자동 지정
   • FROM <이미지명>:<태그명>
   • FROM <이미지명>@
2. 실행할 명령어 (이미지 작성 시 실행): RUN
   • 사용법
   • RUN <실행할 명령="">
3. 실행할 명령어 (이미지로부터 컨테이너 구동 시 실행): CMD, ENTRYPOINT
   • CMD와 ENTRYPOINT의 관계
     • CMD만 있을 경우: CMD에 지정된 명령을 실행
     • ENTRYPOINT만 있을 경우: ENTRYPOINT에 지정된 명령을 실행
     • CMD와 ENTRYPOINT가 모두 있을 경우: ENTRYPOINT에 지정된 부분이 명령어, CMD에 지정된 부분이 명령어의 인자
     • ex) ENTRYPOINT touch
     • CMD /tmp/test
   • CMD의 경우 컨테이너 실행 시 변경가능
     • docker run [옵션] <이미지> [명령어]
   • ENTRYPOINT의 경우 옵션을 사용하여 변경 가능
     • docker run –entrypoint …
4. 실행할 명령어 (이미지를 사용하여 빌드할 때 실행): ONBUILD

---

Dockerfile 내에서 실행할 명령을 입력할 때 사용하는 방법

• Shell 방식 : 명령어를 그대로 입력
  • ex) RUN yum -y install httpd
• Exec 방식 : 명령어를 JSON 포맷 형태로 입력
  • ex) RUN [“yum”, “-y”, “install”, “httpd”]

Dockerfile

#나의 첫번째 Dockerfile
FROM centos:7
#이미지 빌드 시 실행할 명령 (빌드시 실행할 명령을 Shell 형식으로 지정)
RUN yum -y install httpd

#나의 첫번째 Dockerfile
FROM centos:7
#이미지 빌드 시 실행할 명령 (빌드 시 실행할 명령을 Exec 형식으로 지정)
RUN ["yum", "-y", "install", "httpd"]

#나의 첫번째 Dockerfile
FROM centos:7
#이미지 빌드 시 실행할 명령 (컨테이너 구동 시 실행할 명령을 Shell 형식으로 지정)
ENTRYPOINT touch
CMD /tmp/test

#나의 첫번째 Dockerfile
FROM centos:7
#이미지 빌드 시 실행할 명령 (컨테이너 구동 시 실행할 명령을 Exec 형식으로 지정)
ENTRYPOINT ["touch"]
CMD ["/tmp/test"]