Docker

도커 기본 정리

dm.kim 2020. 9. 21. 08:56

가상환경 제공을 거의 Native급으로 한다. 그러기에 도커를 쓴다.

컨테이너 기술을 지원하는 다양한 프로젝트 중에 하나

컨테이너 기술은 이전에도 있었으나 도커로 인해 알려짐

컨테이너 기술의 사실상 표준

2014 가장 인기있는 클라우드 오픈소스 2위(리눅스 재단 발표)

다양한 운영체제에서 사용 가능(리눅스, 윈도우, MacOS) 하지만 윈도우는 하이퍼바이저(WSL)를 사용해야되서 부하가 있음

애플리케이션에 국한 되지 않고 의존성 및 파일 시스템까지 패키징하여 빌드, 배포, 실행을 단순화함

리눅스의 네임스페이스와 cgroups와 같은 커널 기능을 사용하여 가상화

리눅스 네임스페이스 : 각 프로세스가 파일 시스템 마운트, 네트워크, 유저(uid), 호스트 네임(uts)등에 대해 시스템에 독립 뷰를 제공

리눅스 컨트롤그룹 : 프로세스를 소비할 수 있는 리소스양(CPU, 메모리, I/O, 네트어크 대역대, device 노드 등)을 제한

도커는 다양한 클라우드 서비스 모델과 같이 사용 가능

이미지 : 필요한 프로그램과 라이브러리, 소스를 설치한 뒤 만든 하나의 파일, 이미지 자체는 실행 불가능한 상태

컨테이너 : 이미지를 격리하여 독립된 공간에서 실행한 가상 환경, 이미지를 CREATE 명령어를 사용하여 컨테이너로 만든다. 컨테이너를 실행(메모리에 띄워서 애플리케이션이 동작하게 만드는 작업)을 하기 위해서는 START 명령어를 통해 메모리에 올린다. 컨테이너 생성되면 IP주소 할당. 하지만 유동적으로 변함. 이름으로 컨테이너 찾기

네트워크 : 컨테이너 그룹화

latest : 버전 안 적어주면 최신 버전

도커 레지스트리 -> 이미지 다운로드 -> 컨테이너화

도커 허브에서 이미지 검색

도커 레지스트리도 서비스로 올라가 있다.

RUN 명령어 : PULL, CREATE, START 한번에 다함 PULL되있으면 CREATE, START만 함

RUN 할때마다 동일한 이미지라도 컨테이너가 계속 생성됨
RM : 컨테이너 지우기
RMI : 이미지 지우기

도커의 라이프사이클

도커의 한계 : 서비스가 커지면 커질수록 관리해야 하는 컨테이너의 양이 급격히 증가. 도커를 사용하여 관리를 한다 하더라도 쉽지 않은 형태, 배포 및 컨테이너 배치 전략, 스케일-인, 스케일-아웃이 어려움 -> 오케스트레이션 도구와 이어짐(쿠버네티스)

 

이미지의 비밀 : 레이어. 이미지는 하나여도 레이어는 여러개가 될 수 있다. 레지스트리에 저장을 할 때 이미지 전체를 저장하는게 아니라 레이어로 나누어서 저장을 한다. 레이어를 최소단위 이미지라고 생각? 이미지 A에 레이어 A, B, C가 있고 이미지 B도 레이어 A, B, C가 있고 추가로 D가 있는 경우 이미지 A를 지우면 레이어 A, B, C가 집합으로 있는 모양은 사라지지만 레이어 A, B, C가 사라지지는 않는다.

overlay2 디렉토리 : 레이어들을 저장하고 있는 디렉토리, 이미지의 구성은 이미지 폴더에 저장되고 이미지의 실질적인 정보는 overlay2에 저장이 된다.

 

DevOps : Development + Operations

개발팀 : 개발팀 : 새로운 것 개발, 창작에 중점
운영팀 : 개발, 창작보다는 안정적인 인프라에 중점

 

하이퍼바이저 : 없는 CPU, RAM, 하드디스크 등을 만들어 준다. 이 위에 Guest OS들을 탑재

하이퍼바이저 대신 도커 엔진이 들어간다.

리눅스의 핵심 기술(리눅스 컨트롤 그룹)을 사용하는데 논리적으로 나눌 수 있는 기술을 사용한다.

하지만 윈도우에 돌아갈 때는 하이퍼바이저(WSL)를 사용한다.

따라서 도커 실습을 위해서는 리눅스 사용을 추천(하이퍼바이저를 사용하지 않기 위해 도커를 사용하니까).

가상화를 통해 도커 엔진을 구현한다.

 

가상환경을 사용하면 오버헤드가 적게든다. 다양한 종속성을 해결할 수 있다. -> 컨테이너를 사용하면 서비스가 커질 수록 성능이 가상환경 없이 실행하는 서비스보다 좋다.

Monolith : 기존 방식, 한 번에 묶어서 개발

Microservices : 개발팀 개별적으로 어플리케이션의 부분을 맡아서 개발, 각각 분리되어 작업 가능(=서비스별 컨테이너화) 많은 서비스들이 Dependency없이 하나의 서비스로 어떻게 돌아갈까? -> 마이크로서비스를 하기 위해서 컨테이너화시켰기 때문에 가능하다.(대표적 아마존, 넷플릭스)

각 서버에 기능별로 세분화 시킴, API로 서로 통신.

Kubernetes : 도커를 관리하는 프로그램, 구글이 Golang으로 만듬. 도커(2012)보다 늦게 나옴(2014). 도커의 컨테이너들을 관리할 수 있는 프로그램.

Nginx : Load Balancing 기능도 있다.

볼륨 마운트를 이용하여 로컬 머신과 도커가 서로 서비스를 공유할 수 있다.