컨테이너/도커

Docker 특징 및 구조

비니화이팅 2022. 10. 19. 22:02

도커

- 애플리케이션 실행 환경을 작성 및 관리하기 위한 오픈 플랫폼

- Build(이미지 생성), Ship(이미지 공유), Run(컨테이너 실행) 기능을 제공

 

 

도커 에디션

CE(Community Edition)

- 로컬 환경 및 상용 지원이 불필요한 환경에 적합

 

EE(Enterprise Edition)

- Basic : 도커사의 지원, 도커 스토어에서 이증이 끝난 컨테이너, 플러그인 제공

- Standard : Basic 기능, LDAP나 AD와 통합 가능한 도커 Datacenter 이용 가능

- Advanced : Standard 기능, 보안 기능 제공

 

 

도커 특징

확장성

- 서비스 이전이나 신규 서버에 서비스 추가 시 docker run 명령어로 처리

- 개발 서버나 테스트 서버 운용 간편

 

표준성

- 도커를 사용하지 않는 경우 ruby, node.js, go, php로 만든 서비스들의 배포 방식은 제각각

- 컨테이너라는 표준으로 서버를 배포하므로 모든 서비스들의 배포 과정이 동일

 

설정

- MYSQL_PASS=password와 같이 컨테이너를 띄울 때 환경변수를 같이 지정

- 하나의 이미지가 환경변수에 따라 동적으로 설정 파일을 생성하도록 만들어야 함

 

공유자원

- 컨테이너는 삭제 후 새로 만들면 모든 데이터가 초기화

- 업로드 파일을 외부 스토리지와 링크하여 사용하거나 S3같은 별도 저장소 필요

- 세션이나 캐시를 파일로 사용 시 memcached나 redis와 같은 외부로 분리

- 도커 컨테이너는 영구 데이터를 저장하는 데 적합하지 않음

- 데이터 전용 컨테이너에서 데이터를 관리

- 로컬 호스트를 마운트 하여 영구 데이터를 저장

 

 

도커 컨테이너

도커를 이용해 애플리케이션을 패키징하면 전개와 런타임 문제를 애플리케이션 외부에서 제어 가능

- 애플리케이션을 네트워크에 노출하는 방식, 애플리케이션의 스토리지, 메모리, I/O 이용을 관리하는 방식, 접근 권한을 통제하는 방식

 

컨테이너는 기저의 운영체계로부터, 다른 컨테이너로부터 단일 애플리케이션과 의존성 다시말해 앱 실행에 필수적인 외부 소프트웨어 라이브러리 전체를 격리

- 컨테이너화된 앱은 하나의 공통 운영 체계를 공유

 

시스템 자원을 좀 더 효율적으로 이용 가능

- 컨테이너에 담긴 앱은 가상 머신보다 훨씬 더 적은 메모리를 사용하며, 더 신속하게 시작하고 중지하며, 호스트 하드웨어에서 훨씬 더 밀도 있게 배치 가능

- 컨테이너는 훨씬 가볍고 운영체제 커널을 공유하며 시동이 훨씬 빠르고 운영체제 전체 부팅보다 메모리를 훨씬 적게 차지

 

소프트웨어 전달 주기를 가속화

- 수요에 맞춰 스케일링을 간단히 할 수 있고 비즈니스가 요구하는 신기능을 추가하는 업데이트를 간단히 할 수 있음

 

애플리케이션 이동을 가능하게 함

- 도커 컨테이너는 애플리케이션이 실행해야 하는 모든 것을 캡슐화하기 때문에 애플리케이션이 환경들 사이에서 손쉽게 이동할 수 있음

- 애플리케이션을 호스트 운영체제와 연결할 필요 없이 컨테이너 런타임 환경을 지원하는 모든 장치에서 실행 가능

 

컨테이너에 의해 좀더 용이해지는 마이크로서비스

- 애플리케이션은 다수의 느슨히 결합된 컴포넌트로부터 구성

- 전통적인 ‘모놀리틱’ 애플리케이션을 부분적 서비스들로 해체함으로써 마이크로서비스는 비즈니스 요구에 따라 별개의 팀에 의해 별개의 스케줄 상에서 LOB 앱(a Line-Of Business App)의 부분들이 개별적으로 확장, 수정, 서비스되도록 할 수 있음

 

결합성을 제공

- 대부분의 비즈니스 애플리케이션은 웹 서버, 데이터베이스, 인-메모리 캐시 등 하나의 스택으로 구성되는 별개의 여러 구성요소로 구성됨

- 여러 컨테이너가 각 조각들을 제공하며 독립적으로 유지, 업데이트, 교체, 수정 가능

 

오케스트레이션과 스케일링이 쉬움

- 여러 시스템에서의 애플리케이션 스케일링, 수요 증가와 리소스 보존을 위한 서비스 증가 및 다운에도 컨테이너를 사용 가능

 

게스트 OS를 설치하지 않음

- 단지 이미지에 서버 운영을 위한 프로그램과 라이브러리만 격리해서 설치하기 때문에 이미지 용량이 크게 줄어듬

- OS를 설치하지 않기 때문에 호스트와 OS자원을 직접 사용

 

가상화라기보다는 리눅스 컨테이너 격리기술을 사용

- 도커는 하드웨어 가상화 계층이 존재하지 않기 때문에 메모리 접근, 파일 접근 등 관련한 기능에서 직접 접근하기 때문에 가상화보다 빠른 성능

 

볼륨을 만들어 저장공간을 container끼리 연결할 수 있으며 실행한 호스트의 저장공간에도 접근 가능

 

하나의 리눅스 커널을 여러 개의 컨테이너에서 공유

- 컨테이너 안에서 작동하는 프로세스를 하나의 그룹으로 관리하고 그룹마다 각각 파일 시스템이나 호스트명, 네트워크 등을 할당

- 그룹이 다르면 프로세스나 파일에 대한 액세스를 할 수 없음

- 이러한 구조를 사용하여 컨테이너를 독립된 공간으로 관리 ← 이를 실행하기 위해 리눅스 커널기능(namespace, cgroups 등) 기술이 사용

 

도커 작동 구조

- 도커는 리눅스 커널의 기술이 베이스로 되어 있음

 

selinux : 고도의 보안 기능을 제공(리눅스 커널에 강제 액세스 제어 기능을 추가한 기능

- 보안 대상에 따라 HTTP/FTP 프로세스마다 액세스 제한을 거는 Type Enforcement와 root도 포함한 모든 사용자에 관해 제어를 거는 RBAC 등으로 리눅스를 제어)

 

namespace : 컨테이너를 구획화

- 글로벌 리소스에 대한 프로세스 수준의 격리 제공

- 도커 컨테이너 간 독립된 프로세스 공간과 독립된 네트워크 스택 등을 제공

- 6가지 네임스페이스를 지원

- Linux 커널의 namepsace는 Linux의 오브젝트에 이름을 붙여 6개의 독립된 환경을 구축

도커는 namespace 장치를 사용하여 호스트 상에서 컨테이너를 가상으로 격리

 

cgroups : 릴리스 장치 관리

- 각종 시스템 리소스(호스트 OS의 CPU나 메모리 등의 자원)에 대한 접근제어와 리소스 제약 담당

- 각 리소스는 subsytem이라고 부름

- /sys/fs/cgroup 디렉터리에서 각 subsystem 확인 가능

 

chroot

- 프로세스의 root 디렉터리 변경

 

 

도커 컴포넌트

- 도커는 컴포넌트로 구성되어 Docker Engine을 중심으로 컴포넌트를 조합하여 애플리케이션 실행 환경을 구축

 

Docker Engine : 도커의 핵심 기능

- 도커 명령 실행 및 도커파일에 의한 이미지 생성

 

Docker Registry : 이미지 공개 및 공유

- 이미지를 공개 및 공유하기 위한 레지스트리 기능

 

Docker Compose : 컨테이너 일원 관리

- 여러 개의 컨테이너 구성 정보를 코드로 정의하고 명령을 실행하여 애플리케이션의 실행 환경을 구성하는 컨테이너들을 일원 관리하기 위한 툴

 

Docker Swarm : 클러스터 관리

- 도커 호스트를 클러스터화하기 위한 툴

- Manager : 클러스터를 관리하거나 API를 제공

- Node : 도커 컨테이너를 실행하는 역할

 

 

도커 볼륨과 데이터 관리

- 도커는 데이터를 안전하게 존속시킬 수 있는 방식으로 volume, bind mouts,. tmpfs의 3가지 방식을 제공

- 3가지 유형의 가장 큰 차이점은 데이터가 도커 Host 내 어디에 존재하는지의 차이

- 어떤 유형의 마운트를 사용하든 데이터는 컨테이너 내에서 동일하게 보이며 파일시스템의 폴더나 개별적인 파일들로 표시

 

Volume

- 도커(리눅스에서는 /var/lib/docker/volume/)가 관리하는 Host File System의 일부에 데이터가 저장

- 마운트할 때 이름을 명시적으로 지정하거나 익명으로 사용 가능하며 이름이 지정된 방식과는 상관없이 볼륨은 동일한 방식으로 작동

- 원격 호스트와 클라우드 프로바이더가 데이터를 저장할 수 있는 볼륨 드라이버 사용을 지원

 

Bind mount에 비한 장점

- 백업 및 마이그레이션이 더 쉬움

- 도커 CLI 명령이나 도커 API를 사용 가능

- 리눅스 컨테이너와 윈도우 컨테이너 모두에서 작동

- 여러 컨테이너 사이에서 더 안전하게 공유

- 원격 호스트나 클라우드 프로바이더에게 볼륨을 저장하거나 볼륨의 내용을 암호화, 다른 기능을 추가 가능

- 컨테이너에 의해 그 내용물을 미리 채울 수 있음

 

Bind mount

- 데이터가 Host System의 어디에든지 저장 가능

- 호스트 시스템의 파일 또는 디렉터리가 컨테이너에 마운트(경로가 호스트에 존재하지 않는다면 자동 생성됨)

- 볼륨에 비해 기능이 제한

- 호스트 시스템의 파일 시스템 디렉터리 구조에 의존적

- 도커 CLI 명령어로 관리할 수 없음

 

tmpfs mount

- Host System의 메모리에만 데이터가 저장

- 도커 호스트 또는 컨테이너 내의 디스크에서 데이터가 유지되지 않음

- 비영구적인 상태 정보나 민감정보와 같이 컨테이너의 생명주기와 맞춰서 데이터를 보존하고자 할 때 사용 가능 Ex) Swarm Service는 내부적으로 tmpfs mount를 사용하여 Secret 정보를 Service의 컨테이너에 마운트하여 사용