Docker 소개

일. 목표

Bring Portability, Security, And Efficiency To Your Traditional Applications Without Changing Application Code

애플리케이션 코드를 변경하지 않고도 기존 애플리케이션에 이식성, 보안성 및 비용 효율성을 제공합니다

이. 특성

Docker 는 애플리케이션을 패키징하여 느슨하게 격리된 환경 (컨테이너라고 함) 에서 실행하는 기능과 컨테이너 수명 주기를 관리하기 위한 도구 및 플랫폼을 제공합니다

P.S.Docker 는 Go 로 작성되었습니다

하이브리드 클라우드 이식성

애플리케이션의 소스 코드와 종속성을 모두 경량의 독립적인 컨테이너로 패키징합��다. 컨테이너는works on my machine문제를 해결합니다. 그림과 같습니다：

(이미지 출처 Digging Into the "Works On My Machine" Problem)

이를 통해 환경 간 차이를 고려하지 않고도 애플리케이션을 새로운 환경에서 정상적으로 실행할 수 있습니다. 패키징 후 간단한 Docker 명령 하나로 컨테이너를 어떤 환경에나 쉽게 배포할 수 있습니다. 클라우드 마이그레이션을 신속하게 시작하고 기술 업데이트 주기를 가속화하거나 (퍼블릭) 클라우드로 급격히 마이그레이션할 수 있습니다

애플리케이션 보안 향상

기존 애플리케이션을 Docker 컨테이너로 패키징하면 소스 코드를 수정하지 않고도 Docker 내장 보안 기능을 활용할 수 있습니다. Docker 는 컨테이너 격리를 제공하고 제한적인 구성을 통해 애플리케이션의 공격 표면을 줄이며 적절한 리소스 할당을 설정하여 호스트 리소스를 절약할 수 있습니다

또한 Docker 는 컨테이너 애플리케이션의 생성, 스캔, 서명, 공유 및 배포를 위한 안전한 공급망을 제공합니다. 예를 들어 보안 스캔은 모든 종속성의 알려진 취약점 목록을 제공하고 정기적인 보고서에서 Docker 관리자에게 알려진 공개 취약점 수정을 알립니다. 컨테이너 디지털 서명도 가능하며 Docker 클러스터 검증을 활성화하여 애플리케이션의 안전한 전송을 보장합니다

CapEx(자본적 지출) 및 OpEx(운영 비용) 이점

Docker 는 리소스 프로비저닝, 배포, 업데이트 등의 작업을 간소화하며 Docker 컨테이너로 마이그레이션하면 배포 시간을 절약할 수 있습니다

구조적으로 Docker 컨테이너는 기본 운영 체제 커널을 공유하므로 리소스 소비가 가상 머신보다 적고 상대적으로 경량입니다. 컨테이너 격리를 통해 애플리케이션 충돌을 방지할 수 있으므로 IT 관리자는 기존 인프라의 부하 밀도를 향상시키고 기존 가상 머신과 서버의 활용률을 최적화할 수 있습니다

P.S.하이퍼바이저의 추가 오버헤드가 필요하지 않고 호스트 커널에서 직접 실행되므로 리소스를 더 절약하며 가상 머신보다 경량입니다. 가상 머신 환경에서 Docker 를 실행할 수도 있습니다

DevOps

DevOps (a clipped compound of "development" and "operations") is a software engineering culture and practice that aims at unifying software development (Dev) and software operation (Ops). The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management. DevOps aims at shorter development cycles, increased deployment frequency, more dependable releases, in close alignment with business objectives.

소프트웨어 개발과 운영 (테스트, 운영) 을 통합하고 제품 릴리스 주기를 더욱 단축하며 효율성을 향상시키는 것을 목표로 하는 소프트웨어 엔지니어링 문화 및 관행입니다. 동시에 자동화와 모니터링을 통해 신뢰성을 보장합니다

컨테이너 기술은 DevOps 에서 중요한一环입니다. 아래 그림과 같습니다：

(이미지 출처 Red Hat OpenShift V3 Overview and Deep Dive)

앞서 언급한 바와 같이 소스 코드와 종속성을 컨테이너로 패키징하면 리소스 프로비저닝, 배포, 업데이트 등 일련의 운영 작업을 간소화하고 You build it, you run it 를 실현하여 개발에서 릴리스까지의 불확실한 단계를 줄일 수 있습니다

P.S.DevOps 에 대한 자세한 정보는 DevOps 의前世今生 를 참조하십시오

삼. 구조 및 개념

C/S 아키텍처의 일종으로, Client 가 명령을 보내면 Server(데몬) 가 이를 받아 해당 작업을 실행하고 컨테이너와 이미지를 관리합니다. Server 는 Client 와 동일한 물리 머신에 있을 수도 있고 다른 원격 머신에 있을 수도 있으며 REST API 를 통해 통신합니다 (UNIX socket 을 통한 프로세스 간 통신 또는 네트워크를 통한 원격 통신 중 하나입니다)

Docker 데몬

데몬 (dockerd) 은 Docker API 요청을 수신 대기하고 이미지 (image), 컨테이너 (container), 네트워크, 디렉토리 (volume, 파일 시스템의 개념, 볼륨) 등의 Docker 객체를 관리합니다. 또한 데몬은 다른 데몬과 통신하여 Docker 서비스를 관리할 수도 있습니다

Docker 클라이언트

클라이언트 (docker) 는 Docker 사용자가 Docker 와 상호 작용하는 기본 방법입니다. 예를 들어 docker run 명령을 사용하면 클라이언트는 이러한 명령을 dockerd 에 보내 실행합니다. 하나의 client 는 여러 데몬과 통신할 수 있습니다

Docker 레지스트리

npm registry 와 유사하며 Docker registry 는 공개 Docker 이미지를 저장하는 데 사용되며 기본적으로 Docker Hub 에서 이미지를 찾습니다

docker pull 또는 docker run 명령을 실행하면 설정된 registry 에서 필요한 이미지를 가져옵니다. docker push 는 로컬 이미지를 설정된 registry 에 게시하는 데 사용됩니다

또한 npm package 와 달리 공개 이미지는 여전히 이미지 레벨 (블랙박스) 이며 npm package 처럼 소스 코드가 모두 공개되어 있는 것은 아닙니다. 따라서 Docker 는유료 에코시스템Docker store 를 발전시켰습니다. 신뢰할 수 있는 모듈/애플리케이션 패키지를 직접 구매할 수 있으며 업그레이드 유지보수 (이미지 업데이트) 등의 서비스도 받을 수 있습니다. 매우 흥미롭습니다

P.S.예를 들어 Foopipes 는 유료 이미지입니다

Docker 객체

이미지 (image), 컨테이너 (container), 서비스 (service), 네트워크, volume(디렉토리), 플러그인 등을 포함하며 자주 다루는 것은 이미지와 컨테이너입니다

이미지

이미지는읽기 전용템플릿으로 Docker 컨테이너를 생성하기 위한 지침이 있습니다

3 가지 특징이 있습니다：

이식성：registry 에 게시하거나 압축 파일로 저장할 수 있습니다
계층화：이미지를 생성하는 단계는 (이미지에) 레이어를 추가하는 것이며 이를 통해 마지막 몇 단계를 제외하고 대부분의 이미지는 부모 레이어를 공유하여 디스크 사용량을 줄일 수 있습니다
정적 (읽기 전용): 콘텐츠는 불변이며 새 이미지를 생성하지 않는 한 변경할 수 없습니다

일반적으로 다른 이미지를 기반으로 추가 커스터마이징을 수행하여 새 이미지를 생성합니다. 예를 들어 ubuntu 이미지를 기반으로 이미지를 구축하고 Apache 와 자신의 애플리케이션을 설치하고 필요한 Apache 설정 항목을 지정할 수 있습니다

자신의 이미지를 생성하려면 Dockerfile 을 생성하고 간단한 구문으로 생성 및 실행에 필요한 단계를 정의합니다. Dockerfile 의 각 지시는 이미지에 레이어를 생성합니다. Dockerfile 을 수정하고 이미지를 다시 빌드할 때 변경된 레이어만 빌드합니다. 다른 가상화 기술에 비해 더 가볍고 빠릅니다

컨테이너

컨테이너는 이미지의 실행 가능한 인스턴스입니다

컨테이너에도 3 가지 특징이 있습니다：

런타임 개념：프로세스가置이는 환경
가변 (쓰기 가능): 실질적으로는 단기 저장의 일종입니다
계층화：이미지는 컨테이너의 "레이어"입니다

Docker API 또는 CLI 를 통해 컨테이너를 생성, 시작, 중지, 이동, 삭제할 수 있습니다. 컨테이너를 여러 네트워크에 연결하고 스토리지를 첨부할 수 있으며 컨테이너의 현재 상태를 기반으로 새 이미지를 생성할 수도 있습니다

컨테이너는 해당 이미지와 생성 및 시작 시 지정된 구성 항목에 의해 정의됩니다. 컨테이너가 삭제되면 지속되지 않은 모든 상태 변경 사항이 손실됩니다

예：

docker run -i -t ubuntu /bin/bash

이 명령을 실행하면 6 가지 일이 발생합니다：

로컬에 ubuntu 이미지가 없으면 registry 에서 가져옵니다 (수동으로 docker pull ubuntu 실행과 동일합니다)
새 컨테이너를 생성합니다 (수동으로 docker create 실행과 동일합니다)
컨테이너에 읽기/쓰기 파일 시스템을 할당하여 최종 레이어로 만들고 실행 중인 컨테이너가 로컬 파일을 조작할 수 있도록 합니다
네트워크 인터페이스를 생성하고 컨테이너를 기본 네트워크에 연결합니다 (네트워크 옵션을 지정하지 않은 경우). 이를 통해 컨테이너에 IP 주소가 할당되며 기본적으로 컨테이너는 호스트의 네트워크 연결을 통해 외부 네트워크에 연결할 수 있습니다
컨테이너를 시작하고 /bin/bash 를 실행합니다. 컨테이너는 대화형 모드 (-i) 로 실행되고 터미널에 연결 (-t) 됩니다. 이후 키보드에서 입력하고 출력을 터미널에 기록할 수 있습니다
exit 를 입력하여 /bin/bash 명령을 종료하면 컨테이너가 중지되지만 삭제되지는 않습니다. 다시 시작하거나 삭제할 수 있습니다

서비스

서비스는 여러 Docker 데몬 간에 컨테이너를 확장할 수 있도록 합니다. 마치 여러 관리자와 작업자가 클러스터로 협력하는 것과 같습니다. 클러스터의 각 멤버는 Docker 데몬이며 모든 데몬은 Docker API 를 통해 통신합니다. 서비스는 필요한 상태를 정의할 수 있도록 합니다. 예를 들어 특정 시간에 컨테이너가 제공해야 하는 복제본 수 등. 기본적으로 서비스는 모든 작업 노드 간에 로드 밸런싱됩니다. 사용자에게 Docker 서비스는 단일 애플리케이션처럼 보입니다

기반 기술

Docker 는 구현상 몇 가지 Linux 커널 기능을 활용합니다：

Namespaces 를 통한 독립된 작업 공간 (container) 구현
Control groups 를 통한 컨테이너 사용 가능 리소스 제한
Union file systems 를 통한 레이어 (layer) 구현
Container format 를 통한 컨테이너 관리 (위 3 가지 기능을 종합적으로 활용하여 추상화한 개념)

사. 예시

환경

cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)

설치 및 활성화

# 설치
yum install docker
# 시작
sudo service docker start
# 부팅 시 자동 시작
sudo chkconfig docker on

체험

CentOS 이미지를 기반으로 새 이미지를 만듭니다：

# CentOS 이미지 가져오기
docker pull centos
# 이미지 존재 확인
docker images centos

정상이라면 다음과 같은 출력이 표시되며 로컬에 최신 CentOS 이미지가 존재함을 나타냅니다：

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
docker.io/centos    latest              3fa822599e10        3 weeks ago         203.5 MB

Docker 컨테이너 실행

docker run -i -t centos /bin/bash

새로 생성된 터미널 (centos 컨테이너 환경 내) 에서 하고 싶은 일을 합니다：

# nvm 설치
curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.8/install.sh | bash
# 환경 변수 업데이트
source ~/.bashrc
# node v4.6.2 설치
nvm install 4.6.2
# 전역 모듈 설치
npm install -g ionic @1.7.16
npm install -g cordova @6.2.0
# ... 일련의 작업 수행
# 대화형 터미널 종료
exit

P.S.여기서 node 버전과 전역 모듈 버전이 고정된 이유는 무엇일까요？옛날 장난감 이 있어서 이 환경에서만 실행할 수 있기 때문입니다. Docker 는 이러한 시나리오에 매우 적합합니다. 그렇지 않으면 다른 사람의 로컬 환경에서 실행하기 어렵습니다. 따라서환경에 특별한 요구 사항이 있는 오픈 소스 프로젝트는 Docker 이미지를 게시하거나 Dockerfile 을 동봉하는 것이 좋습니다

마지막으로 현재 상태에서 이미지를 생성합니다：

#刚才 수정한 컨테이너 ID 확인
docker ps -a -q -l
# 변경 사항 커밋 및 새 이미지 생성
docker commit 887a377fa369 ayqy/rsshelper

이를 통해 centos 이미지를 기반으로 한 ayqy/rsshelper 사용자 정의 이미지가 로컬에 생성됩니다：

# 새로 생성된 이미지 확인
docker images ayqy/rsshelper
# 한 번에 RSSHelper 실행에 필요한 환경 진입
docker run -it ayqy/rsshelper /bin/bash
# 환경 확인
node -v
# v4.6.2 맞습니다

기본적인 사용법은 이렇고 실제 애플리케이션에서는 Dockerfile 을 통해 사용자 정의 이미지를 생성하는 것이 합리적입니다

Dockerfile

먼저 하나 생성합니다：

mkdir -p ~/projs/docker/rsshelper/
vi ~/projs/docker/rsshelper/Dockerfile

내용 편집：

FROM centos:latest
MAINTAINER ayqy "nwujiajie @163.com"

ENV NODE_VERSION 4.6.2

RUN curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.8/install.sh | bash \
&& source ~/.bashrc \
&& nvm install "$NODE_VERSION" \
&& nvm alias default "$NODE_VERSION" \
&& nvm use default \
&& nvm install -g ionic @1.7.16 cordova @6.2.0

주의:

첫 번째 줄 FROM 지시는 필수이며 소스 이미지를 지정하는 데 사용되며 지정된 이미지는 로컬에 존재해야 합니다. FROM 는 docker run 에 해당합니다
RUN 지시는 기본적으로 /bin/bash 를 사용하며 각 RUN 은 새 bash 프로세스를 시작하므로 환경 변수를 공유하려면 && 로 연결해야 하며 여러 RUN 지시를 사용하지 않습니다

이미지 생성：

docker build -t="ayqy/rsshelper_image" ~/projs/docker/rsshelper/
# 생성 완료 후 새 이미지 확인
docker images ayqy/rsshelper_image

주의：어느 명령의 반환 값이 0 이 아니면 이미지는빌드 실패합니다

P.S.Dockerfile 에 대한 자세한 정보는 快速掌握 dockerfile 를 참조하십시오

자주 사용하는 명령

# registry 에서 지정 이미지 가져오기
docker pull fedora
# 로컬 이미지 확인
docker images
# Dockerfile 에서 이미지 생성, 현재 디렉토리에 Dockerfile 필요
docker build -t myimage .
# 대화형 모드로 컨테이너 실행
docker run -it myimage
# 실행 중인 컨테이너 확인
docker ps -l
# 컨테이너 실행 중지 (id 는 docker ps 출력��서 확인)
docker kill <id>
# 컨테이너 삭제
docker rm <id>

P.S.docker help 를 통해 더 많은 Docker 클라이언트 명령을 확인할 수 있습니다

오. 애플리케이션 시나리오

컨테이너 기술은 로컬 개발 환경과 실제 프로덕션 환경의 차이를 제거하여 CI/CD 워크플로우 보장을 간소화합니다：

컨테이너로 애플리케이션 개발 및 종속성 관리
컨테이너를 배포 및 테스트의 기본 단위로 사용
프로덕션 환경에 배포, 프로덕션 환경이 어떤 형태이든 (로컬 데이터센터, 클라우드 공급자 또는 이들의 하이브리드)

몇 가지 애플리케이션 시나리오 예：

데모 공유

개발 데모를 컨테이너로 패키징하여 공유하면 다른 사람이 자신의 로컬 환경에서 즉시 실행할 수 있습니다

자동화 테스트

개발 환경의 애플리케이션을 테스트 환경에 배포하여 수동 테스트/자동화 테스트를 실행합니다. 환경 차이를 고려할 필요가 없습니다

신속한 재배포/게시

개발 환경에서 버그를 수정한 후 테스트 환경에 재배포하여 테스트 검증을 실행합니다. 테스트 통과 후 최신 이미지를 프로덕션 환경에 배포합니다

리소스 활용률 최적화

각 애플리케이션의 리소스 할당을 제한하거나 Docker 컨테이너를 가상 머신 대신 사용하여 리소스 활용률을 더욱 향상시킵니다

참고 자료

Docker overview
A beginners guide to Docker: 정확하고 포괄적인 입문 가이드
Modernize Traditional Applications with Docker Enterprise Edition
What is Docker?