도커
도커는 2013년에 등장한 컨테이너 기반 가상화 도구입니다. Docker는 컨테이너를 위한 플랫폼으로서 도커 엔진을 통해 컨테이너를 관리합니다. Docker가 설치된 곳이라면 어느 곳이라도 컴퓨팅 환경에 구애받지 않고 애플리케이션을 신속하게 배포, 확장할 수 있으며 문제없이 실행되는 것을 보장합니다. 이를 위해서 도커는 애플리케이션을 표준화된 유닛으로 패키징하는데, 라이브러리, 시스템 도구, 코드, 런타임 등 소프트웨어를 실행하는 데 필요한 모든 것을 포함시킵니다.
이 실행 가능한 패키지를 이미지라고 하며, 이미지를 실행한 인스턴스를 컨테이너라고 합니다. 이것은 프로그램과 프로세스라는 개념과 비교하여 설명할 수 있습니다. 흔히 프로그램이라고 하면 실행 가능한 파일을 지칭하고, 이 프로그램이 실행된 상태를 프로세스라고 하는데, 이와 마찬가지로 이미지는 프로그램에, 컨테이너는 프로세스와 비교할 수 있습니다.
과거의 실행 환경 및 방식
애플리케이션을 개발하고 서비스를 제공하기까지 개발 환경, 테스트 환경, 운영 환경 등을 거치게 되는데 이 환경은 동일하지 않습니다. 개발 환경에서 정상적으로 작동하였다 하더라도 테스트 환경에서도 동일할 것이라고 기대할 수 없으며,
테스트 환경에서 정상적으로 작동했다고 할지라도 운영 환경에서 정상 작동을 보장할 수 없습니다. 환경의 구성도 다르고 가변적인 요소가 많기 때문입니다.
라이브러리 버전이 달라지거나 설정을 변경해 나가기 시작하면 관리가 더 어려워집니다. 상이한 하드웨어나 소프트웨어 버전을 사용하게 된 경우 설정이 조금씩 다를 수밖에 없고, 이러한 차이로 인해 서비스는 미묘한 불안정성을 가지게 됩니다. 이는 전형적인 가변 인프라의 문제로서 끊임없이 변경사항의 갱신을 관리해야 하는 어려움이 있습니다. 클라우드 컴퓨팅으로 전환되면서 서버의 대수는 급격히 증가하였는데, 기존의 방식대로 스크립트로 자동화하여 관리하는 것도 한계가 있으며 이러한 문제는 DevOps를 실천하는 데 매우 큰 장애요소가 됩니다.
도커의 실행 환경 및 방식
반면 도커는 애플리케이션 실행에 필요한 모든 파일을 이미지로 만들고 이 이미지를 바탕으로 컨테이너를 가동시킵니다. 변경사항이 생기면 변경사항을 갱신 관리하는 것이 아니라 새로운 이미지를 생성하여 대체해버립니다. 이 방식은 실행 환경이 변경되더라도 애플리케이션이 정상적으로 작동하는 것을 보장하며 가변적인 상황이 발생하더라도 쉽게 대응할 수 있습니다. 이러한 방식을 불변 인프라라고 하며, 도커는 이 방식을 통해 이식성을 극대화 하였습니다. 도커는 이러한 높은 이식성을 바탕으로 DevOps의 구체적인 실현 가능성을 높였습니다.
또한 컨테이너 오케스트레이션, 오토 스케일링, 마이크로서비스 아키텍처 등 클라우드 컴퓨팅 전반의 다양한 기술 발전에도 긍정적인 영향을 주었습니다.
도커를 사용하는 이유
Docker를 사용하면 애플리케이션 운영을 표준화시켜 운영하면서 겪는 시행착오를 쉽게 파악하고 개선할 수 있습니다. 이를 통해 지속적 배포, 안정적인 서비스 제공을 더 빠르게 할 수 있습니다. 결국 서비스 제공을 위한 노력을 감소시키고 자원 사용률을 증대 시켜 비용을 절감시킵니다.
도커의 구조
도커 엔진은 클라이언트-서버 애플리케이션으로서 도커의 핵심 기능입니다. 도커 호스트에서 백그라운드 데몬 프로세스로 작동하는 서버는 도커 이미지, 컨테이너, 네트워크, 볼륨 등의 객체를 생성하고 관리합니다. 도커 사용자는 커맨드 라인 인터페이스를 지원하는 클라이언트를 통해 동일 시스템 또는 원격지의 도커 데몬과 상호작용하며 명령을 실행시킬 수 있습니다.
도커 레지스트리는 도커 이미지를 공개하고 공유하기 위한 도커 이미지 저장소입니다. 원하는 이미지를 검색해서 가져오고 생성한 이미지를 레지스트리에 푸시할 수도 있습니다.
도커의 기반 기술
도커는 컨테이너라고 하는 격리된 실행환경을 생성합니다. 이를 위해 리눅스 커널의 네임스페이스라는 기술을 사용합니다. Pid는 Linux의 프로세스에 할당된 고유 ID를 의미합니다. Pid 네임스페이스는 프로세스를 격리합니다. 네임스페이스가 다른 프로세스는 서로 접근할 수 없습니다.
Net 네임스페이스는 네트워크 리소를 관리합니다. 네트워크 디바이스, IP주소, 포트 번호, 라우팅 테이블, 필터링 테이블 등을 네임스페이스마다 독립적으로 가질 수 있습니다. IPC 네임스페이스는 프로세스 간의 공유 통신 자원을 관리합니다. MNT 네임스페이스는 파일시스템을 사용하기 위한 마운트 포인트를 관리합니다. 네임스페이스가 다르면 접근할 수 없습니다. UTS 네임스페이스는 네임스페이스 별로 호스트명이나 도메인명을 독립적으로 가질 수 있도록 관리합니다.
도커 컨테이너는 물리 하드웨어의 자원을 여러 컨테이너가 공유합니다. 이때 리눅스 커널의 Control Groups 기능을 사용하여 자원 할당을 관리합니다. Cgroups는 프로세스와 스레드를 그룹화하여 그룹별로 CPU나 메모리 등의 자원 사용에 제한을 둘 수 있습니다. 이를 통해 하나의 컨테이너가 자원을 독점적으로 사용하는 등 다른 컨테이너에 영향을 주는 일을 막을 수 있습니다.
유니온 파일 시스템은 도커 엔진이 사용하는 파일 시스템입니다. 도커 이미지는 컨테이너를 실행하기 위한 모든 정보를 가지고 있기 때문에 보통 용량이 매우 큽니다. 만약 매번 대용량의 이미지를 새로 다운로드 받아야 한다면 비효율적입니다.도커는 이런 문제를 해결하기 위해 유니온 파일 시스템을 사용합니다. 가볍고 빠른 레이어로 구성된 파일 시스템입니다.이미지는 읽기 전용 레이어로 구성하는데 파일이 추가되면 새로운 레이어를 생성하여 추가합니다.
컨테이너를 생성할 때는 기존의 이미지 레이어 위에 쓰기전용 레이어를 추가하여 컨테이너가 실행 중에 생성하는 파일이나 변경된 내용은 별도로 관리합니다. 여러 개의 컨테이너를 생성하더라도 효율적으로 최소한의 용량만 사용합니다.
'SW > DevOps' 카테고리의 다른 글
DevOps 공정 : 프로세스 개념, 특징 (0) | 2019.11.27 |
---|---|
DevOps : Docker : 설치, 예제, 개념 (0) | 2019.11.22 |
DevOps : 가상화와 컨테이너 : 개념, 기능 (0) | 2019.11.20 |
DevOps : 프로젝트 빌드 관리 : 방법, 개념 (0) | 2019.11.19 |
DevOps : 소스코드관리 : Git 기능 개념 (0) | 2019.11.18 |