[Docker] 중간고사 정리(2)

 

 

 

 

 

Chap5. Docker Introduction 

- 도커는 구글이 만든 SW 아니다. ‘Solomon Hykes’ 파이콘 2013에서 발표

- 2013년, 도커가 Go 언어로 짠 순간, 쿠버네티스 등장 (Go) -> 두 sw가 출시되며 Go 언어가 인정받음

 

- 도커는 거의 대부분의 플랫폼 위에 올라간다 + 오픈소스 / 플랫폼에 독립적으로 SW를 돌릴 수 있다 
-> OS에 무관하게 도커 위에서 어플리케이션을 짜면 된다, infrastructure 과 무관하게 짜면 된다.

- 프로그래밍 하듯이 infrastructure를 관리할 수 있다, infrastructure as code (IaC)

- 실행할 프로그램의 소스 코드와, 이미지를 만들기위한 도커 파일 코드, 이렇게 코드 파일이 2개 필요하다.

 

* Immutable Infrastructure using ‘Dockerfile’

- 내가 필요한 환경을 도커 파일로 작성 (내가 필요한 개발환경 요청) -> 도커 파일을 빌드하면 도커 이미지가 만들어진다. 

- 만들어진 이미지를 필요할 때, 필요한 만큼 실행하면 도커 컨테이너 // 도커 파일이 IaC

 

* 도커를 사용하는 이유 (도커의 장점) 

* Flexible - 도커 파일로 복잡한 개발 환경을 간단하게 세팅 가능

* Lightweight - guestOS 없이 hostOS만 있어도 OK 

* Interchangeable – 즉시 업데이트, 다운그레이드 용이하다.

 

* Docker Image – executable package including everything needed to run an application 

- Infrastructure as Code - 코드, path 등 환경변수, configuration file 등 도커 이미지 안에 담아서 한번에 설치하고, 지운다.

* Docker Container – a runtime interface of an image -> 이미지를 실행하면 메모리 상의 컨테이너가 됨 (인스턴스 개념)

- 이미지 자체는 잠자는 파일 (클래스, 설계도 개념) 이걸 실행해야 함 -> 실행 시 동작하는 인스턴스가 컨테이너

- 인스턴스를 필요할 때 필요한 만큼 실행하는 것 / CPU와 메모리를 잡아먹음 

 

* Sharing Immutable Infrastructures – Docker Hub - 350만개의 도커 어플리케이션, 그 중 하나가 우분투 

- registry - 이미지 저장소 / 다른 사람들이 만들어 둔 이미지를 가져오면 됨

- 웹서버를 돌리는 환경은 NGINX - 이미 구현되어 있음 / 필요할 때 필요한 만큼 컨테이너로 띄워서 쓰고, 깔끔하게 지우면 됨

 

* docker run hello-world - 이 컴퓨터에는 hello world 최신 버전이 없다 

- 도커 데몬이 자동으로 인터넷에 접속해서 도커 허브에서 찾음 -> 도커 데몬이 컨테이너를 실행시킨다 

- 도커 클라이언트로 보내어, 터미널에 글씨를 띄움

* VM과 컨테이너의 큰 차이점 – VM은 전원을 끄기 전까지는 항상 살아있다.

- But 컨테이너는 명령을 실행하고, 명령이 종료되면 컨테이너는 죽는다. 출력이 끝나면 해당 컨테이너의 목적은 끝남

 

 

 

 

 

* docker run -it ubuntu bash / interactive terminal - 우분투 내부의 bash(셸)를 실행시켜라 

-> 매킨토시에서 리눅스로 프롬프트가 #으로 바뀐다 (id는 root로 됨)

+ 이미지 위에서 컨테이너가 도니까, 지울 때는 이미지보다 컨테이너 먼저 지워라

 

* Ubuntu - 원래는 설치가 까다로운 우분투 -> 도커로 편리하게 이미지를 가져오고, 실행할 수 있다.

docker pull ubuntu                                                                   // 백그라운드 모드, 서버처럼 돌도록 데몬으로 실행 (-d)

docker container run -it -d –-rm –-name ubuntuos ubuntu:latest   // 우분투OS 컨테이너 안의 bash 프로그램을 it로 실행

docker exec -it ubunyuos /bin/bash                                            

docker container ls

docker image ls 

 

* Alpine Linux - 우분투는 기능 거의 X, 알파인은 busy box

– 쓸 만한 명령어 많음 but 보안 이슈가 있다, 매우 가볍다

docker pull alpine

docker container run -it -d —rm –-name alpineos alpine:latest       // 이미지를 갖고 왔으니, 컨테이너를 실행시켜줘

docker exec -it alpineos /bin/ash                                               // bash 대신 ash shell

 

 

 

 

 

Chap6. Docker Overview

- Community Edition CE – 학생버전 무료, 오픈소스 / 기업이라면 EE 유료 버전 

* Docker Engine - 이미지를 만들고, 실행하고 가져오는, 도커의 가장 핵심 SW 

- 도커 파일에 정의한 인프라들을 빌드해서 이미지를 만들고 러닝해서 컨테이너를 만든다. 

- 컨테이너가 잘 돌아가는지 check 등 컨테이너의 lifecycle을 process, 전반적인 것들을 실행하고 관리한다.

 

*** Docker의 3대 요소 – 서버, CLI, 이를 연결하는 rest API

* 원격지에 있는 docker daemon (engine) / 백그라운드 서버가 도커 데몬 

- 나는 CLI로 타이핑하여 춘천에 있는 서버(데몬)에 rest API로 접속(네트워크)가능 // docker engine과 docker CLI는 독립

- 둘을 이어주는 통신 (REST API) / HTTP 통신 프로토콜을 위해 사용한 명령어 

* CRUD 기반의 DB와 HTTP(통신) get 등 4개 메소드를 연결해서, DB와 연동되는 기술이 rest // 구체적인 방식이 restful API

 

* Docker Daemon – CLI or 다른 데몬이 본인에게 어떠한 요청을 하는지 듣고 있다. 다른 컴퓨터의 데몬 간 통신도 가능

* Docker Client – Command line interface (CLI) – give instruction to the Docker Engine 

- 웹의 클라이언트 – 서버 아키텍처와 유사하다 (웹이 아니긴 함) - 도커 클라이언트는 도커 엔진에게 본인이 필요한 기능들 요청

* Docker Desktop – GUI 상 보이기만 하나이고, 사실은 다 쪼개져 있다. 

 

* Docker Registries - 도커 이미지를 저장함 – 공개된 public registry와 내부에서 사용하는 private registry로 구분

- docker pull – 이미지 가져오는 것 / docker run - 이미지 실행 / docker push - 이미지를 허브에 올리는 것

 

* Docker Ecosystem 

위에서 아래까지 손으로 타이핑할 명령 X 프로그램으로 자동화될 수 있음 

CI - 컴파일, 빌드까지 / CD - 운용팀이 하는 deployment까지 사람의 개입 최소화 

DevOps - 빠른 시간 안에 개발, 안정적으로 프로그램을 배포하기 위해

 

- 개발자 컴퓨터에서 image를 registry에 올리는 것은 docker push / Code를 올리는 건 git push

+ 이미지 안에 넣은 코드가 git push 대상이 되는 것 + Docker file (infrastructure as a code) - 컨테이너를 만드는 코드 

- 이렇게 소스코드가 둘이 나오는 것 / 둘 다 Git-hub에 올린다. 

 

* image가 debug / production level에서 만들어질 수 있음 

- 개발 or 운영팀이 release version의 이미지를 빌드할 수 있음

- 성능 or 기능 중심 (dev) vs 안정성 (ops) - 둘의 관점이 다름

 

+ 한 대의 도커 데몬 위에서, 여러 컨테이너 띄울 수 있음 

- CPU 개수와 무관하게 쌓기 O (VM은 CPU 4개라면 3개만 가능)

- 호스트가 수천 수만대가 될 것이기 때문에, 관리를 위해 후반부에 등장할 오케스트레이터 Orchestrator

 

* Underlying Technologies of Docker - 도커는 고 GO 언어로 만듦 / 리눅스/유닉스 컨셉과 유사 - 컨테이너 별 그룹 분리 

* Namespaces - 섞이지 않도록 분리하는 namespace 기술 사용 / VM에서도 사용하는 기법을 컨테이너도 동일하게 사용 

- 사용자 입장에서는 독립적인 컴퓨터인 것처럼 속는 것, 컨테이너 별 공간이 중복되지 않도록 namespace 분리 

* Control Groups – cgroups - 접근 권한 그룹 - virtual machine처럼 생겼다 / 사용자 입장에서는 둘이 비슷하다 

- container 간에는 최대한 충돌이 없도록 제한하여 resource management 

 

* Getting started – docker run -d -p 80:80 docker/getting-started 

-d 데몬 – 서버처럼 / -p 포트 - 내부와 외부 ip address가 다르다 (NAT/PAT)

- port address translation (PAT) 바깥도 안쪽도 80을 준다는 의미 - 컨테이너가 뜨면 웹 브라우저에 (localhost:80) 접속 가능 

+ ls -> 살아있는 것들만 뜸 / ls all -> 실행되었는데, 자고 있는 애들도 다 전부 다 뜬다. 

+ 웹브라우저 get / curl – 간단한 HTTP methods / 더 확장된 pip / python import requests 파이썬 모듈 

 

 

 

 

 

Chap7. Docker Hub & Dockerfile

* Docker hub – sharing immutable infrastructures - 남이 만든 다른 high quality container 이미지들을 쉽게 가져올 수 있다.

Ex) python 개발 환경이 이미 다 갖춰진 것 - 플랫폼에 무관하게, immutable하게 환경을 구축하여, 내 파이썬 SW 돌리기 가능 

 

* Dockerfile - 이미지를 만드는 파일, 고유명사 도커파일 - 아래부터 위까지 차곡차곡 필요한 개발 환경을 쌓는 것 (레이어)

- 도커 파일이 infrastructure as a code의 대명사

 

5개의 명령을 && and로 묶음 - 이게 한 줄 명령 -> RUN 명령어는 한 번 실행됨

FROM RUN ENTRYPOINT // 이런 빨간 명령어들은 쌓인다 -> 개수 제한이 있음 - 이걸 레이어라고 한다.

너무 많으면 동작이 안 됨, only 20~30개

 

가져온 우분투 안으로 들어가서 파이썬 설치

entrypoint 출입구 like cpp의 main func / 빌드해서 실행하고, 최초의 진입 지점

 

FROM python:3                                             // FROM – creates a layer from the Python3 Docker Image

COPY . /app                                                  // COPY – adds files from your Docker client’s current dir to /app

CMD [ “python”, “/app/myapp.py” ]                  // CMD – specifies what command to run within the container 

# myapp.py에는 print(“Hello, World!”) 한 줄 들어가 있음

 

* Dockerfile Execution 

docker build -t myapp .                                 // . current directory 의미하는 점

docker run -it –-rm –-name py3 myapp            // 타이틀은 py3 으로 줌, —rm은 지워버리란 의미

 

* Docker Container Lifecycle - 주로 start, stop 사용

 

 

 

- docker container ls -a -q (or -aq)    // 나중에 여러 컨테이너 중 난수로 특정 컨테이너만 멈추고 싶을 때, 맨 앞의 난수만 출력 

- docker system prune                    // 이미지, 컨테이너, 볼륨, 캐시 등 싹 다 지워버리는게 prune

* docker image rm -f $(docker image ls -aq) // 이미지 싹 다 지우고 싶을 때, 난수 뽑아서 전부 지울 수 있음

 

 

 

 

 

Chap8. Build and Push Images 

- 직접 예제로 주어진 도커 파일을 이해하고, 이미지를 만들어보자 –> nginx 예시

 

* Dockerfile

FROM ubuntu:latest 

RUN apt-get update                                      // RUN - 내가 가져온 이미지 위에서 실행

RUN apt-get install -y nginx                            // 즉, 우분투 위에서 해당 명령어 실행

RUN echo “this is a ubuntu container”

WORKDIR /etc/nginx

CMD [“nginx”, “-g”, “daemon off;”]

EXPOSE 80                                                  // port address 80 사용해서 외부와 통신

docker build –tag myubuntu:1.0 .                     // 점을 하나 찍는 것 - 내가 있는 위치 / 현재 directory 의미

                                                                   // 즉 지금 있는 곳의 도커 파일로부터 이미지를 빌드한다는 뜻

docker run --name myubuntu-nginx -d -p 4000:80 myubuntu:1.0 

docker stats                                                 // stats - 얼마나 많은 리소스를 쓰고 있는지 볼 수 있다.

 

* port address translation PAT - 컨테이너가 80번 포트를 쓰겠다 - 컨테이너 안의 이야기

- 바깥에서 접속하려면 외부 포트와의 mapping 필요 / 외부에서 4000으로 접근하면, 내부에서 80으로 받는다.

+ PAT 이유: 하나의 IP 주소를 가지고 여러 내부 호스트 사용 가능 // http://localhost:4000 -> 내부 80으로 감

 

 

 

 

 

Chap9. Docker Compose - 둘 이상의 서로 다른 컨테이너들이 통신하며 서비스를 이룸

- 복수 개의 컨테이너에 대한 파일을 만든다 => 도커 컴포즈 파일 (얌파일) / 기존 도커 파일은 1개의 이미지에 대한 파일

 

*** Docker Services 

– 최종 어플리케이션 하나 - 유튜브 / 이를 구성하는 여러 개의 부품 같은 서비스들이 모여서, 하나의 어플리케이션을 사용자에게 제공함 

ex) 비디오들 저장하는 DB 서비스 / 비디오 품질을 조정하는 서비스 / 사용자에게 스트리밍 작업을 하는 프론트엔드 서비스

ex2) 백엔드 구조 - 1) 로드밸런서 2) DB 3) Logic server + 4) 백엔드 중 프론트엔드 - 최초의 request를 받아주는 애

 

- 각각의 서비스들은 별도의 컨테이너로 구성 – 복잡한 하나의 프로그램이 아니라, 잘게 쪼개진 서비스들로 만드는 것

* 하나의 서비스는 하나의 이미지에 매핑이 된다. 이 서비스를 (같은 기능을 하는) 몇 개의 컨테이너로 띄울 것인지 결정 / 

- scaling: 서비스에 대한 컨테이너 개수를 필요한 만큼 늘이고, 줄일 수 있다. 

 

*** Docker Compose - 둘 이상의 이미지로 묶인 애들을 논리적인 한 그룹처럼 묶어서 실행하고, 관리한다. 

Dockerfile 처럼 여기서는 docker-compose.yml (얌파일) - 둘 이상의 컨테이너를 띄우는 현재 디렉토리에 해당 파일을 실행

compose up - 얌파일에 들어간 multi-container들을 싹 띄우는 명령어 / compose down – stop all services 

+ 도커 데스크탑으로 한 번에 자동으로 깔리지만, 하나씩 쪼개서 별도 설치도 가능하다. 

* 하나의 도커 컴포즈로 띄운 두 컨테이너를 논리적인 네트워크로 연결해 줌 - IP Address 사용 X / Prefix (이름) cattle mode

+ DNS - 이름을 통해 node들을 만들어 줌 - 알아서 IP Address 사용하게 바꿈, 즉 네트워크를 만들어 준다.

 

* How to create docker compose files – docker-compose.yml 얌파일 작성 

 

version: ‘3.7’                       // TAP 말고, 두 칸 씩 일일이 해라

service:

web:                              // web / database - 이 이름 중요 

  image: nginx                // 이미지는 nginx / redis

database:

    image: redis 

 

+ 1번이 2번 서비스보다 먼저 뜰꺼란 보장은 X, 간단하게는 sleep으로 재울 수 있음 

- 보통 이럴 경우, 2번이 먼저 1번에게 hello 보내고, world 받으면 (heartbeat) 서버 살아있는지 확인하는 과정이 들어간다. 

+ port address translation, 스토리지와 관련된 volumes + environment에서 system params 설정 가능

 

* Cattle mode in docker compose - Container 오리지널(working dir, 폴더) 이름 - web (서비스 이름) – 1, 2, 3 … 

-> 해당 서비스의 컨테이너가 여러 개 뜰 수 있음 – 이때 Cattle mode로 1, 2, 3 이렇게 명명된다. 

- 컨테이너 db-1가 web-1에 접속하고 싶다면, http://web-1 라고 쓰면 서버에 접속할 수 있음! 

Ex) Container lecture09-sources-web-1 / Container lecture09-sources-database-1 

 

* docker compose down 실행 시 주의할 점 – up한 위치, 즉 yml 파일이 있는 곳에서 명령어 실행해야 한다. 

Ex) ports: “8000:80” - 바깥에서 들어갈 땐 8000 / 내부 포트는 80 - curl로 localhost:8000에 붙을 수 있음

- NAT/PAT – Network and Port Address Translation - 외부에서는 NAT/PAT로 번역된 번호 사용 

 

* YAML - JSON과 유사한 key-value에 map chain, 데이터의 형태를 정의하는 언어

- Configuration files, Log files, Cross-language data sharing 등 다양한 곳에 활용되는 format

+ 우리가 지금 손으로 하는 행위는 나중에 다 프로그래밍으로 자동 작성 – 인간이 개입하지 않도록 ex) pyyaml

 

docker-compose.yml

- 바깥에서 8001로 접근하면 worker 1 컨테이너 내부의 80번 포트

- 8002는 worker2 컨테이너 내부의 80번 포트 * 서로 다른 서비스, 즉 다른 이미지

- curl http://worker1:80

- curl http://worker2:80

*** curl로 IP or domain 영역에 우리가 부여한 이름(worker1, 2)을 주면 80번 포트로 붙기 가능 (이게 제일 중요) 

+ docker compose up -d --scale manager=4     

- 스케일 옵션을 사용하여 매니저를 4개 띄워볼 수 있다. 필요할 때 필요한 만큼 컨테이너 수를 키우는 것

 

 

 

 

 

Chap10. Docker Storage – 저장 공간, 스토리지에 대한 이야기

* 컨테이너에 파일을 저장할 때의 문제 - 컨테이너는 지속적이지 않지만, 데이터는 어딘가에 저장되어야 한다.

- 컨테이너 내부 writable layer 가능하나, OS별 구현은 느리고 복잡함 -> 권장 X. volumes과 bind mounts 사용을 권장 

- 컨테이너 바깥에 & 컴퓨터 안에 있는 스토리지를 의미 

- 물론 컨테이너 안에도 스토리지가 있을 수 있다 (VM처럼) but 컨테이너는 그러려고 만든 것이 아니다. 

+ 원래 목적 - 프로그램을 원하는 만큼 실행하고, 필요 없음 지우는 건데, 이 목적과 맞지 않음

* Storing files in the host machine – volume, bind mount 둘 다 컨테이너 or 컴퓨터 전원이 죽어도 살아있긴 함

 

(1) bind mount

컨테이너 밖 / HOST 컴퓨터 파일시스템 - 태생적으로 존재하는 디스크 

사용자가 사용하던, 컨테이너와 상관없이 존재하는 파일들 

+ OS에서 저장장치를 연결하는 것을 마운트라고 함 

 

(2) volume - docker area – part of the host filesystem managed by Docker

- 도커가 돌아가기 위한 작은 리눅스 등 도커가 사용자에게 보여주지 않으며 사용하는 공간

- 여긴 사용자가 아니라, 도커가 사용하려고 만든 것 (read는 가능하지만, 사용자 접근 및 write 원치 X)

- 여러 컨테이너가 volume을 동시에 공유할 수 있다. 서로 다른 컨테이너들이 병렬로 처리 가능, 컨테이너가 죽어도 볼륨은 O

- docker volume create / docker volume prune 

* docker volume create myvol-1                      // create 대신 inspect 명령어를 통해 볼륨 내부의 세부 정보 볼 수 O

 

(3) tmpfs mounts - temporal file system - RAM, 메모리 - 컴퓨터 메모리를 마치 임시 디스크처럼 사용하는 것

- 매우 빠른 속도 but 작은 데이터만 처리 가능, 컨테이너 or 컴퓨터 죽으면 같이 사라짐, only Linux

 

* Jenkins – 젠킨스 

- CI/CD로 가장 많이 언급되는 자동화 도구 - 외부와의 통신을 위해서 포트가 두 개 열려야 함

- docker pull jenkins/jenkins:lts-jdk11

- docker run -p 8080:8080 -p 50000:50000 -v myvol-1 :/var/jenkins_home jenkins/jenkins:lts-jdk11

-> http://localhost: 8080 – 난수 키 값을 통해 젠킨스 설치 가능 

- docker container stop {jenkins container ID} - 컨테이너는 죽였지만, 볼륨은 그대로 저장됨 (myvol-1)

+ 서로 다른 두 컨테이너에서 하나의 volume을 동시에 공유할 수 있다. 

* docker-compose up을 통해 yaml 얌파일 잘 짜서 돌리면, 일련의 손으로 작성한 코드들 한방에 실행 가능 (이게 쓰는 이유)

 

 

 

 

 

Chap11. Docker Machine - 복수의 물리적인 / 논리적인 도커 실행환경을 만드는 것

- Docker machine 도커 머신 - 도커가 돌아가는 가상머신을 만들어주는 도구 - 여러 대의 컴퓨터에 동시에 뿌리는 것

- 도커가 실행되도록 Virtual hosts 운영해주는 원격 관리 툴 / 지금까지는 한 대의 컴퓨터 위에서 컨테이너 & 스토리지 

-> 이제는 여러 컴퓨터들을 묶어서, 모두 host machine에서, 원격으로 다룰 수 있도록 지원해주는 프로그램이 도커 머신

+ 도커 머신은 기본 모드가 virtual box로 VM을 띄우고, 그 위에 도커를 띄우는 것

 

* Docker Machine to Docker Engine - 우리가 CLI로 명령 실행 - 내 컴퓨터에서 띄워진 도커 데몬 서버에 REST API로 접속

- 따라서 다른 컴퓨터의 도커 서버에 HTTP 기반의 통신으로 접속하는 것은 언제나 가능하다.

- docker-machine create --driver virtualbox myvm1        // driver를 virtualbox 말고 다른 것도 OK

- 도커 머신은 VM을 만들고 - 리눅스를 설치하고, 도커를 설치하고, 필요한 환경을 설치하고, 원격 접속을 하기 위해 만들어진 것

Ex) docker-machine stop myvm1 / docker-machine start myvm1 / docker-machine rm myvm1 – 원격으로 도커 머신 control 

 

* ssh - secure shell - 원격에 있는 컴퓨터에 암호화된 통신으로 연결하기 위해, ssh 프로그램 사용

Ex) 기존: docker version      원격: docker-machine ssh default docker version 

+ docker-machine env default - 지금부터 치는 명령은 ssh default 없어도, 원격에 있는 컴퓨터로 보내줘 

- restful API를 통해 도커 CLI가 원격으로부터 결과를 가져오는 것 // -u : undo를 통해 다시 돌아올 수 있음 

- docker-machine ls -> 내가 지금 타이핑하는 명령이 대체 누구한테 가? / 여러 개 중 하나만 * (원격으로 보내지는 타겟)