1. Docker

도커(Docker)는 컨테이너형 가상화 구현을 위한 상주 애플리케이션과 이를 관리하는 명령형 도구로 구성되어 있음

도커 이미지와 도커 컨테이너의 관계

fig.1

도커 이미지
- 도커 컨테이너를 구성하는 파일 시스템과 실행할 애플리케이션 설정을 하나로 합친 것
- 컨테이너를 생성하는 탬플릿 역할
도커 컨테이너
- 도커 이미지를 기반으로 생성
- 애플리케이션과 인프라를 함께 담은 상자
- 파일 시스템과 애플리케이션이 구체화돼 실행되는 상태
도커 이미지는 파일 시스템을 실행하는 애플리케이션 파일을 담고 있음
- 컨테이너가 생성될 때 이미지로부터 파일 시스템을 구체화
- 컨테이너 안의 파일 시스템상에서 애플리케이션 실행
- 컨테이너로 애플리케이션을 실행하려면 컨테이너 형태로 구제화될 템플릿 역할을 하는 이미지를 먼저 생성해야함

도커의 특징

컨테이너에 애플리케이션 실행 환경이 함께 배포되는 방식
- 배포 간편
컨테이너 중심으로 애플리케이션 개발 및 운영
- 애플리케이션 배포에 특화
Dockerfile에 컨테이너 정보 관리
- Dockerfile의 코드를 기반으로 복제 및 배포
- 따라서, 개발 환경과 운영 환경을 거의 동등하게 재현 가능
- 이식성 뛰어남, 재현성 높음
컨테이너형 가상화 기술을 사용해 컨테이너를 쉽게 만들고 사용 및 제거 가능
- 가상화 소프트웨어보다 오버헤드 적음
- 가상화 소프트웨어보다 더 가볍게 동작

도커 사용의 예

설치가 번거로운 명령형 도구를 도커 컨테이너로 가져다 사용함으로써 호스트를 깔끔하게 유지하면서도 바로 실행할 수 있음
다양한 의존 라이브러리나 도구를 도커 컨테이너에 포함시켜 배포함으로써 실행 환경과 상관없이 스크립트의 동작 재현성 높임
도커 컨테이너를 HTTP 부하 테스트의 워커로 사용해 HTTP 요청 수 증가시킴

도커 사용의 의의

1) 환경 차이로 인한 문제 방지

애플리케이션은 항상 뭔가에 의존함
- 운영 체제는 물론이고, CPU나 메모리 같은 컴퓨터 리소스, 언어 런타임, 라이브러리, 별도 프로세스로 애플리케이션 내부적으로 실행하는 애플리케이션 등 다양한 요소에 의존성을 가질 수 있음
이 문제를 해결하기 위해 코드로 관리하는 인프라와 불변 인프라 개념 도입
- 코드로 관리하는 인프라
  - 코드 기반으로 인프라 정의 (Dockerfile)
  - 서버를 어떻게 구성할 것인지, 어떤 라이브러리와 도구를 설치할지를 코드로 정의
  - 셰프(Chef)나 앤서블(Ansible) 같은 프로비저닝 도구로 서버 구축
  - 수작업이 개입할 여지를 줄이고 코드 중심으로 바꿈으로써 쉽게 같은 구성의 서버 여러 대 복제 가능
- 불변 인프라
  - 어떤 시점의 서버 상태를 저장해 복제할 수 있도록 하는 것
  - 서버에 변경을 가하고 싶은 경우, 기존 인프라를 수정하는 대신 새로운 서버를 구축하고 그 상태를 이미지로 저장하여 복제
    (한번 설정된 서버는 수정 없이 파기되므로 멱등성 신경쓸 필요없음)
또한, 애플리케이션과 인프라를 묶어 구축
- 애플리케이션과 인프라를 함께 관리하므로 높은 이식성을 보임
- 생성해 둔 도커 이미지는 도커가 설치된 머신이라면 어디서든 실행 가능

2) 애플리케이션 구성 관리의 용이성

일정 규모를 넘는 시스템은 주로 여러 개의 애플리케이션과 미들웨어를 조합하는 형태로 구성
(도커를 사용함으로써 배포 작업은 매우 쉬워졌지만, 복잡한 시스템을 한 덩어리로 동작하긴 쉽지 않음)
- 즉, 시스템 전체에 대한 적절한 구성 관리 필요
- 필요한 컨테이너를 각각 실행하는 방법으로 시스템 구성
  (각 컨테이너의 의존 관계나 실행 순서가 어긋나면 제대로 동작하지 않는 등의 문제가 생기기 때문)
여러 컨테이너를 사용하는 애플리케이션을 쉽게 관리할 수 있도록 도커 컴포즈(Docker Compose) 도구 제공
- yaml 포맷으로 작성된 설정 파일로 컨테이너를 정의하거나 컨테이너 간의 의존 관계를 정의해 시작 순서 제어
- 도커와 도커 컴포즈를 통해 여러 애플리케이션과 미들웨어의 의존관계를 간결한 코드로 관리 가능
- 예시
```
version: "3"
services:
  web:
    image: gibyodocker/web
    ports:
      - "3000:3000"
    environment:
      REDIS_TARGET: redis
    depends_on:
      - redis
  redis:
    image: "redis:apline"
```
단일 서버를 넘어 여러 서버에 걸쳐 있는 여러 컨테이너를 관리할 수 있도록 도커 스웜(Docker Swarm) 도구 사용
- 여러 컨테이너를 관리하는 것만이 목적인 도커 컴포즈와 달리 도커 스웜은 컨테이너 증가 혹은 감소는 물론이고 노드의 리소스를 효율적으로 활용하기 위한 컨테이너 배치 및 로드 밸런싱 기능 등 더욱 실용적인 기능을 갖추고 있음
- 배포 시에도 롤링 업데이트(오래된 컨테이너와 새로운 컨테이너를 단계적으로 서비스에 교체 투입하는 것)가 가능해 운영 면에서도 장점 많음
- 이렇게 여러 서버에 걸쳐 있는 여러 컨테이너를 관리하는 기법을 컨테이너 오케스트레이션(Container Orchestration)라고 함
  ex. 쿠버네티스(Kubernetes)

2. `Dockerfile`

Dockerfile에 도커가 어떻게 이미지를 만들고 실행할지 정의

예시

[ helloworld ] 쉘 스크립트

#!/bin/sh

echo "Hello, World!"

[ Dockerfile ]

FROM ubuntu:16.04

COPY helloworld /usr/local/bin
RUN chmod +x /usr/local/bin/helloworld

CMD ["helloworld"]

FROM 인스트럭션
- 컨테이너의 원형(틀) 역할을 할 이미지(운영체제) 정의
- 도커 이미지의 바탕이 될 베이스 이미지 지정
  - 도커는 FROM에서 지정한 이미지를 기본적으로 도커 허브 레지스트리에서 참조
COPY 인스트럭션
- 도커가 동작 중인 호스트 머신의 파일이나 디렉터리를 도커 컨테이너 안으로 복사
RUN 인스트럭션
- 도커 이미지를 실행할 때 컨테이너 안에서 실행할 명령 정의
CMD 인스트럭션
- 도커 컨테이너를 실행할 때 컨테이너 안에서 실행할 프로세스 지정
- RUN 인스트럭션은 이미지를 빌드할 때 실행되고 CMD 인스트럭션은 컨테이너를 시작할 때 한번 실행됨
  - RUN은 애플리케이션 업데이트 및 배치에, CMD는 애플리케이션 자체를 실행하는 명령

3. Example

1) 애플리케이션 만들기

[ main.go ]

package main

import (
    "fmt"
    "log"
    "net/http"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r * http.Request){
        log.Println("received request")
        fmt.Fprintf(w, "Hello Docker!!")
    })

    log.Println("start server")
    server: = & http.Server {
        Addr: ":8080"
    }
    if err: = server.ListenAndServer(); err != nil {
        log.Println(err)
    }
}

2) Dokerfile 만들기

[ Dokerfile ]

FROM golang:1.9

RUN mkdir /echo
COPY main.go /echo

CMD ["go", "run", "/echo/main.go"]

3) 도커 이미지 빌드

$ docker image build -t example/echo:latest .

4) 도커 컨테이너 실행

$ docker container run example/echo:latest

1. Docker

2. Dockerfile

3. Example

2. `Dockerfile`