[Docker] Docker 요약 (1)

Docker

[Docker] Docker 요약 (1)

ozofweird 2020. 12. 7. 14:46

1. Docker

1) Docker 란?

도커는 컨테이너 기반의 오픈소스 가상화 플랫폼이다. 컨테이너는 다양한 프로그램, 실행환경을 컨테이너로 추상화하고 동일한 인터페이스를 제공하여 프로그램의 배포 및 관리를 단순하게 해준다. 백엔드 프로그램, 데이터베이스 서버, 메시지 큐 등 어떤 프로그램도 컨테이너로 추상화할 수 있고 어디에서든 실행 할 수 있다. 간단하게 말하자면, 도커는 서버 인프라를 손쉽게 구성해주는 역할이라고 이해하면 쉽다.

도커는 크게 3가지 기능으로 나눌 수 있다.

이미지를 만드는 기능 (Build)
이미지를 공유하는 기능 (Ship)
컨테이너를 작동시키는 기능 (Run)

2) 도커의 주요 개념

컨테이너
이미지
레이어 저장 방식

"컨테이너"

컨테이너는 쉽게 배 위에 올라와 있는 화물이라고 생각하면된다. 도커의 개념으로 옮겨본다면, 다양한 OS에 여러 애플리케이션이 올려져 있는 것을 의미하는 것이고, 그런 컨테이너를 고래 위에 올린다고 생각하면 된다.

컨테이너

"가상 머신과의 차이"

Virtual Machine은 호스트 OS위에 게스트 OS 전체를 가상화하여 사용하는 방식이다. Virtual Machine은 Hypervisor을 통해 가상화 기능을 제공하며 각 독립된 커널 공간을 가진 OS를 생성하는 식의 환경 구성을 해준다. 따라서 사용법이 간단하지만, 무겁고 느리기에 운영에는 힘들다. 반면, 도커의 경우 커널 공간을 공유하며 같은 가상화 기능을 제공하기에 Virtual Machine 보다 더 가볍다.

"이미지"

이미지는 컨테이너 실행에 필요한 파일과 설정값 등을 포함하고 있는 것으로 상태값을 가지지 않고 변하지 않는다. 컨테이너는 이미지를 실행한 상태라고 볼 수 있고 추가되거나 변하는 값은 컨테이너에 저장된다. 같은 이미지에서 여러 개의 컨테이너를 생성할 수 있고 컨테이너의 상태가 변경되거나 컨테이너가 삭제되어도 이미지는 변하지 않고 그대로 남아있다.

"레이어 저장 방식"

도커 이미지는 컨테이너를 실행하기 위한 모든 정보를 가지고 있기 때문에 용량이 무겁다. 따라서 처음 도커 이미지를 다운받고, 기존 이미지에 파일 하나 추가했을 때 다시 처음부터 다운받는다면 비효율적이게 된다. 따라서 도커는 이 문제점을 개선하기 위해 레이어와 유니온 파일 시스템을 이용하여 여러 개의 레이어를 하나의 파일 시스템으로 사용할 수 있게 해준다.

3) 도커의 동작 구조

도커가 동일한 커널 공간을 공유하여 가상화 기능을 할 수 있는 이유는 Linux상에서 동작하는 프로세스에 할당하는 자원을 분리하는 기능인 namespace와 자원에 대한 제어를 가능하게 해주는 Linux 커널의 기능인 cgroups 덕분이다.

"namespace"

도커는 컨테이너라는 독립된 환경을 만들고, 그 컨테이너를 구획화하여 애플리케이션의 실행 환경을 만든다. 이 컨테이너 구획 기술은 Linux 커널의 namespace 기능을 사용한다. namespace는 한 덩어리의 데이터에 이름을 붙여 분할하여 충돌 가능성을 줄이고 쉽게 참조할 수 있게 해주는 개념이다.

"cgroups"

도커에서는 물리 머신 상의 자원을 여러 컨테이너가 공유하여 동작한다. Linux 커널의 기능인 'control groups' 기능을 이용하여 자원의 할당 등을 관리한다. cgroups는 프로세스와 스레드를 그룹화하여 그 그룹에 존재하는 프로세스와 스레드에 대한 관리를 수행하기 위한 기능이다. 대표적으로 호스트 OS의 CPU나 메모리와 같은 자원에 대해 그룹별로 제한을 둘 수 있다. cgroups로 컨테이너 안의 프로세스에 대해 자원을 제한함으로 동일한 호스트 OS상에서 동작하는 다른 컨테이너에 영향을 주는 일을 막을 수 있다. (cgroups는 대표적으로 메모리, CPU, I/O, 네트워크, device 노드 등과 같은 자원을 제어할 수 있다.)

" 네트워크 구성"

Linux는 도커를 설치하면 서버의 물리 NIC가 도커라는 가상 브리지 네트워크로 연결된다. docker0은 도커를 실행시킨 후에 기본으로 만들어진다. 도커 컨테이너가 실행되면 컨테이너에 172.16.0.0/16이라는 서브넷 마스크를 가진 프라이빗 IP 주소가 eth0으로 자동할당된다. 이 가상 NIC는 OSI 참조 모델에서 2계층인 가상 네트워크 인터페이스로 페어인 NIC와 터널링 통신을 한다.

도커에서는 NAPT(IP 마스커레이드)기능을 이용하여 외부 네트워크 통신을 사용한다. NAPT는 하나의 IP 주소를 여러 컴퓨터가 공유하는 기술로 IP 주소와 포트 번호를 변환하는 기능을 가지고 있다. 도커에서는 NAPT에 Linux iptables를 사용하고 있다. 즉, 도커에서는 이 기능을 사용할 때 컨테이너 시작 시에 컨테이너 안에서 사용하고 있는 포트를 가상 브리지인 docker0에 대해 개방한다.

2. Dockerfile

1) Dockerfile 이란?

Dockerfile은 베이스가 될 도커 이미지, 도커 컨테이너에서 수행한 명령, 환경 변수 등의 설정, 도커 컨테이너 안에서 작동시켜둘 데몬을 도커상에서 작동시킬 컨테이너 구성 정보를 기술한 파일이다. 도커 빌드 명령은 Dockerfile에 기술된 정보를 바탕으로 도커 이미지를 생성한다.

2) Dockerfile을 이용한 이미지 생성

Dockerfile로 이미지 생성 시 도커 리포지토리에서 베이스 이미지를 다운로드할 경우 시간이 걸리지만 한번 다운 받은 베이스가 될 이미지는 다시 받지 않으므로 시간 제한 없이 사용할 수 있다. (베이스 이미지와 새로 작성한 이미지의 IMAGE ID가 동일)

작성된 이미지는 공통의 베이스 이미지를 바탕으로 여러 개의 이미지를 작성한 경우에는 베이스 이미지의 레이어가 공유되어 디스크의 용량을 효율적으로 사용한다.

3. 개발 환경과 제품 환경

애플리케이션 개발 환경에서 사용한 라이브러리나 개발 지원 툴이 제품 환경에서 반드시 사용되지는 않는다. 따라서 제품 환경에는 애플리케이션을 실행하기 위한 최소한의 실행 모듈만 배치하는 것이 보안 관점이나 리소스 활용점에서 좋다. 예를 들자면, 개발 환경용 도커 이미지를 'Go 1.8.4' 베이스로 만드는 경우와 최소한의 Linux 쉘 환경을 제공하는 'busybox'로 이미지를 빌드한 경우을 따져보면 쉽게 이해할 수 있다. ('Go 1.8.4'로 빌드한 경우 803MB, 'busybox'로 빌드한 경우 1.23MB로 애플리케이션의 실행에 필요한 모듈만을 추가한 정도의 결과를 확인할 수 있다.)

4. 도커 컴포넌트

1) 도커 컴포넌트 종류

컴포넌트	설명
Docker Engine	도커의 핵심 기능으로 이미지를 생성하고 컨테이너를 가동시키기 위한 기능이다. 도커 명령의 실행이나 Dockfile에 의한 이미지도 생성한다.
Docker Registry	컨테이너의 바탕이 되는 도커 이미지를 공개 및 공유하기 위한 레지스트리 기능이다.
Docker Compose	여러 개의 컨테이너 구성 정보를 코드로 정의하고 명령을 실행함으로서 애플리케이션의 실행 환경을 구성하는 컨테이너들을 일원 관리하기 위한 툴이다.
Docker Machine	로컬 호스트용은 VirtualBox를 비롤하여 AWS EC2, Microsoft Azure와 같은 클라우드 환경에 도커의 실행 환경을 명령으로 자동 생성하기 위한 툴이다.
Docker Swarm	여러 도커 호스트를 클러스터화하기 위한 툴이다. Docker Swarm에서는 클러스터를 관리하거나 API를 제공하는 역할은 Manager가, 도커 컨테이너를 실행하는 역할은 노드가 담당한다. (Kubernetes 사용 가능)

2) Docker Registry

도커의 공식 레지스트리인 Docker Hub에는 Ubuntu, CentOS와 같은 Linux 배포판의 기본 기능을 제공하는 공식 베이스 이미지나 여러 뜻있는 사람들이 작성한 다양한 용도의 이미지가 많이 배포되어 있다. 하지만 이미지를 인터넷상에 공개하고 싶지 않은 정보가 포함되는 경우도 있다. 이를 위해 Docker Store에는 'registry' 이미지를 제공하여, 도커 이미지를 일원 관리하기 위한 레지스트리를 별도로 프라이빗 네트워크에서 구축할 수 있도록 도와준다.

공개하고 싶지 않은 이미지를 프라이빗 네트워크에 구축할 수 있지만, 다양한 인프라 구성 요소가 담긴 이미지는 용량이 크다는 단점이 있다. 이러한 이미지는 관리하기에 어렵기 때문에 퍼블릭 클라우드에서 제공하는 서비스(도커 이미지를 프라이빗으로 관리)를 이용하는 것이 좋다. 대표적으로는 Google Cloud Platform(GCP)이 제공하는 Google Container Registry가 있다.

3) Docker Compose

"웹 3계층 아키텍처"

인프라 아키텍처는 애플리케이션을 기동시키기 위해 여러 개의 서버에 기능화 역할을 분리한 인프라 전체 구성을 뜻한다. 여기서 웹 3계층 아키텍처는 웹 시스템의 서버들을 역할에 따라 3개로 나누는 설계를 뜻한다.

프론트 서버는 클라이언트의 HTTP 요청을 받아 응답을 반환하는 서버 기능이다. 미들웨어로 구축하는 경우도 있고 대표적으로 Nginx, Microsoft의 IIS 등이 있다. 요청 처리가 메인 업무이기에 부하가 높은 경우 처리 대수를 늘리거나 로드벨런서 같은 기기를 사용하여 부하분산을 한다.

애플리케이션 서버는 업무 처리를 실행하는 서버로, 주로 결제 처리, 수주 처리 등 애플리케이션의 처리를 실행하는 프로그램의 실행 환경이다. 프론트 서버와 동일하게 미들웨어로 구축하는 경우도 있다.

데이터베이스 서버는 영구 데이터를 관리하기 위한 서버이다. 영구 데이터는 높은 가용성이 요구되기 때문에 클러스터링 같은 기술로 다중화하는 경우가 많다. 또한 장애에 대비하여 백업이나 원격지 보관, 로그 수집 등과 같은 대책이 필요하다. 도커 컨테이너는 웹 프론트 서버와 같이 트래픽의 증감 등에 맞춰 필요할 때 실행하고 필요 없어지면 파기시키는 일회성 운용에 적합하다. 즉, 컨테이너에는 영구 데이터를 저장하는데 적합하지 않다. 따라서 데이터 전용 컨테이너에 데이터를 관리하는 방법이나 로컬 호스트를 마운트하여 영구 데이터를 저장해두는 방법이 있다.

"Docker Compose"

결국 웹 3계층 아키텍처처럼 여러 개의 도커 컨테이너는 협력하며 동작한다. 그리고 Docker Compose는 여러 컨테이너를 모아 관리하기 위한 툴로 사용된다. 'docker-compose.yml' 파일에 컨테이너의 구성 정보를 정의하여 동일 호스트상의 여러 컨테이너를 일괄적으로 관리한다. Compose 정의 파일은 웹 애플리케이션의 의존관계를 모아서 설정할 수 있고 YAML 형식으로 관리하기에 지속적 디플로이나 지속적 인티그레이션 프로세스에 잇어서 자동 테스트를 할 때의 환경 구축에서 이용할 수 있다.

4) Docker Machine

"클러스터링"

이미지의 작성이나 컨테이너의 시작 등은 호스트 머신에 설치된 도커가 수행하고 여러 개의 도커를 일괄 관리할 때는 Docker Compose를 이용하여 애플리케이션 실행 환경을 구축한다. 하지만 호스트에서 장애가 발생할 경우 서비스가 중지된다. 따라서 시스템의 일부에 장애가 발생해도 서비스가 정지되지 않도록 장치가 필요하다. 클러스터링은 이 문제를 해결하는 기술 중 하나로, 여러 대의 서버나 하드웨어를 모아서 한 대처럼 보이게 한다.

"Docker Machine"

Docker Machine은 호스트 머신, 클라우드, 가상 환경 등에 도커의 실행 환경을 만들 수 있는 커맨드 라인 툴이다. 대표적으로 AWS, Azure, Digital Ocean, Exoscale, Google Compute Engine, Microsoft Hyper-V, OpenStack, Rackspace, IBM SoftLayer, VirtualBox, VMware 등이 있다.

즉, Docker Machine은 사용자의 로컬 컴퓨터, 클라우드 서비스가 제공하는 인스턴스, 원격 서버에 도커 호스트를 구성해 준다. Docker Machine을 이용하면 자동으로 도커를 설치하고 도커 호스트를 만들수 있고, 도커 클라이언트를 사용해서 설정한 서버의 도커 호스트에 도커 명령을 실행할 수 있다.

5. Container Orchestration

1) Container Orchestration 이란?

코드를 작성하고 컨테이너화하도록 구축한 후 서버에 컨테이너를 배포하여 신규 서비스를 만들어 오픈했을 때, 사용자의 접속이 많은 경우를 생각하면 쉽다. 사용자가 접속을 할 경우 클라우드 환경에서 서버를 확장하면 되지만, 컨테이너 환경에서 컨테이너를 옮기는 과정과 배치하는 문제가 발생한다. 이러한 문제점을 해결하기 위해 다수의 컨테이너를 관리해주는 Container Orchestration이 등장했다. 대표적으로는 Kubernetes, Docker Swarm, Apache Mesos 등이 있다.

그 중 Kubernetes는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고 확장가능한 오픈소스 플랫폼이다. 선언적 구성과 자동화를 모두 용이하게 해주며 제공하는 기능도 풍부하고 개발 속도도 빨라 Container Orchestration 툴의 실질적인 스탠다드라고 불린다.

Container Orchestration의 목적은 여러 컨테이너의 배포 프로세스를 최적화 하는데 있으며, 컨테이너와 호스트의 수가 증가함에 따라 많이 사용한다. Container Orchestration은 배포 뿐만 아닌 여러 기능을 가지고 있다.

컨테이너 자동 배치 및 복제
컨테이너 그룹에 대한 로드 밸런싱
컨테이너 장애 복구
클러스터 외부에 서비스 노출
컨테이너 추가 또는 제거로 확장 및 축소
컨테이너 서비스간의 인터페이스를 통한 연결 및 네트워크 포트 노출 제어

2) Amazon EC2 Container Service (ECS)

ECS는 가상 머신을 제공하는 EC2를 사용한 컨테이너 관리 서비스이다. ECS에서는 테스크 정의라는 JSON 템플릿을 이용하여 환경을 정의한다. 테스크 정의에는 도커의 리포지토리, 이미지, 메모리, CPU 등과 같은 하드웨어 요구사항, 데이터 볼륨의 스토리지, 컨테이너 간 연결을 정의한다. CPU와 메모리 같은 리소스와 가용성 요구사항을 바탕으로 클러스터 전체에 컨테이너르 ㄹ배치하는 스케줄러를 가지고 있다.

ECS는 컨테이너에 장애가 발생할 경우에도 자동으로 복구가 되기에 애플리케이션을 실행하는데 필요한 수 만큼의 컨테이너를 항상 확보할 수 있다. 또한 ELB를 이용하여 트래픽을 컨테이너 전체로 분산시킬 수 있다. 애플리케이션의 전개는 테스크 정의를 새로운 버전으로 갱신하여 업로드하면 갱신된 이미지를 사용하여 컨테이너가 자동으로 시작된다. 또한 가장 오래된 버전을 실행하고 있는 컨테이너는 자동으로 정지된다.

ECS는 CloudWatch와도 연계하여 CPU나 메모리 사용의 평균값과 합계량을 감시할 수 있으며, 컨테이너나 클러스터의 스케일을 확장 혹은 축소할 때 CloudWatch 알림을 설정하여 경고할 수 있다. 그 외에도 Amazon Elastic Container Service for Kubernetes (EKS) 서비스도 있다.

3) Google Cloud Platform (GCP)

"Google Container Builder"

Dockerfile을 바탕으로 도커 이미지를 GCP상에서 작성하기 위한 커맨드 툴이다. 이미지를 빌드한 뒤에는 Container Registry에 자동 업로드한다.

"Google Kubernetes Engine (GKE)"

도커 컨테이너를 관리하는 서비스로 사용자가 정의한 CPU나 메모리와 같은 인프라 요구사항을 바탕으로 컨테이너를 클러스터에 스케줄링하여 자동으로 관리한다. GKE는 오픈소스 컨테이너 오케스트레이션 툴인 Kubernetes를 이용하고 있고 클러스터 환경으로 자비로 마련하지 않아도 컨테이너 오케스트레이션을 할 수 있다. 애플리케이션의 요구 변화에 따라 컨테이너에 할당되는 클러스터 리소스나 컨테이너 클러스터의 크기를 조정할 수 있다.

"Google Container Registry"

도커 이미지를 GCP의 제품 안에서 관리할 수 있는 프라이빗 레지스트리 서비스이다.

6. Kubernetes

1) Kubernetes 기능

Kubernetes는 여러 개의 호스트를 하나로 묶어 도커를 이용하기 위한 오케스트레이션 툴로 분산 환경에서 한 대의 컴퓨터처럼 투과적으로 컨테이너에 액세스할 수 있다. 더욱이 시스템 이용자로부터 오는 부하의급증에 대해서도 유연하게 스케일하는 장치나 여러 개의 컨테이너를 효율적으로 통합 관리하는 장치도 있다.

여러 서버들에서의 컨테이너 관리
컨테이너 간 네트워크 관리
컨테이너의 부하분산
컨테이너의 감시
무정지로 업데이트

2) Kubernetes Master 서버

Kubernetes 클러스터 안의 컨테이너를 조작하기 위한 서버이다. kubectl 명령을 사용하여 클러스터를 구성한다. 리소스를 조작할 때는 마서터 서버가 커맨드로부터 요청을 받아 처리를 한다. 여러 대로 구성된 Kubernetes 클러스터 안에 있는 노드의 리소스 사용 상황을 확인하고 컨테이너를 시작할 노드를 자동으로 선택한다.

3) 백엔드 데이터베이스 (etcd)

etcd라 부르는 분산 키-값 스토어를 사용하여 클러스터의 구성 정보를 관리한다. 클러스터를 구축하기 위한 설정 정보가 들어 있다. 시스템 구성에 따라서는 백엔드 데이터베이스를 마스터 서버 상에 구축하는 경우도 있다.

4) 노드

실제로 도커 컨테이너를 동작시키는 서버이다. 노드를 여러 개 마련하여 클러스터를 구성한다. 노드의 관리는 Master 서버가 하며 노드를 몇대 마련할지는 시스템의 규모나 부하에 따라 달라진다. 클라우드에서는 가상 머신의 인스턴스가 노드가 된다.

5) Pod

Pod는 Kubernetes에서 최소 배포 단위로 하나 이상의 컨테이너를 포함한다. Docker에서는 최소의 배포 단위가 컨테이너이지만 Kubernetes는 하나의 컨테이너가 아닌 컨테이너 및 네트워크, 스토리지가 포함된 Pod로 배포한다. 기본적으로 하나의 Pod에는 1개의 컨테이너를 올리지만 두 개의 컨테이너가 밀접한 관계를 가지고 있을 때에는 하나의 Pod에 하나 이상의 컨테이너를 배포하기도 한다.

6) ReplicaSet

ReplicaSet는 Kubernetes 클러스터 상에서 미리 지정된 Pod를 작성하여 실행시켜 두는 장치이다. 즉, 필요한 Pod 수 만큼 실행시킨 상태를 클라우드 안에 항상 만들어 두는 역할을 한다. 실행중인 Pod를 감시하여 장애가 발생했을 경우 해당 Pod를 삭제하고 새로운 Pod를 실행시킨다. 클라우드 안에 Pod를 얼마나 실행시켜 둘지를 리플리카 수라고 한다.

7) Deployment

Deployment는 Pod와 ReplicaSet를 모은 것으로 ReplicaSet의 이력을 관리한다. 이력을 관리할 수 있기 때문에 컨테이너의 버전업을 하고 싶을 때 시스템을 정지시키지 않고 업데이트를 할 수 있거나 이력을 바탕으로 이전 세대로 롤백할 수 있다. 즉, ReplicaSet는 리플리카 수를 유지하는 역할을 하며, ReplicaSet의 작성이나 갱신을 정의하는 것이 Deployment다.

8) 네트워크 관리 (Service)

Kubernetes 클러스터 안에서 실행되는 Pod에 대해 외부로부터 액세스를 할 때는 서비스를 정의한다. 클러스터 IP는 클러스터 안의 Pod끼리 통신하기 위한 프라이빗 IP 주소이며 외부 IP는 외부 클라이언트가 연결하기 위한 퍼블릭 IP 주소이다.

9) Label

Kubernetes에서는 리소스를 식별하기 위해 내부에서 자동으로 랜덤한 이름이 부여된다. 하지만 이것으로는 리소스를 적절히 관리하기 힘들기 때문에 알기 쉬운 Label을 붙여 관리한다. 키-값 형태로된 임의의 문자열을 식별자로 하여 리소스를 일괄적으로 처리할 수 있다. Label은 하나의 리소스에 대해 여러 개 설정할 수 있기 때문에 Pod의 역할별로 임의의 이름을 붙이거나 관련 있는 Pod 별로 모아서 유연하게 관리하고 싶을 때 임의의 Label을 설정한다.

10) Manifest

Kubernetes에서는 클러스터의 구성 정보를 YAML 또는 JSON 형식으로 관리할 수 있다. 이 정의 파일은 매니페스트 파일이라고 지칭하며 선언 기반으로 구성을 관리한다. 매니패스트 파일은 텍스트 파일로 Jenkins와 같은 소프트웨어의 버전 관리 시스템과 연계할 수 있다.

11) Kubernetes 구조 및 컴포넌트

Master Node
Kubectl	마스터 노드와 통신하는 명령어로, Kubernetes API를 사용하여 마스터 노드와 상호작용한다.
API Server	REST API 요청을 처리하고 Kubernetes 클러스터를 구성하는 각 컴포넌트들과 통신을 담당한다.
Scheduler	노드들의 리소스 상태를 파악하여 Pod가 배치될 적절한 노드를 선택해 주는 역할을 수행한다.
Controller Manager	Kubernetes 클러스터 상태 감시, 설정한 상태로 유지하는 역할을 수행한다.
etcd	오픈소스 키-값 저장소로 Kubernetes에서는 Master Node의 API Server가 HTTP/JSON API를 이용하여 접근할 수 있는 구성 데이터를 저장하는 용도로 사용된다.

Worker Node
Kubelet	Kubernetes Master Node간의 통신을 담당하는 에이전트로 노드에서 동작하는 Pod를 관리한다.
Kube-proxy	각 노드별로 탑재되며 네트워크 프록시 및 로드밸런서 역할을 수행한다.
Pod	컨테이너의 그룹으로 한 개 또는 여러 개의 컨테이너를 포함하는 Kubernetes 작업단위이다.