Docker

서버 관리

자체 적으로 서버를 운영하기 위해서는 여러가지 절차가 필요하다

서버 주문 > 서버 설치 > CPU, 메모리, 하드디스크 조립 > 네트워크 연결 > OS 설치 > 계정 설정 > 방화벽 설정 > …

만약 자신이 배포하던 서비스의 인기가 많아져서 서버를 늘리거나 더 좋은 서버로 옮겨야 할 때, 새로운 서버에서 전 서버에 쓰던 환경을 구체적으로 재현하는 것은 상당히 어렵다.

이 때 도커를 사용하게 되면 도커의 이미지만을 가져와 새로운 서버에 컨테이너를 만들어 쉽게 동일한 환경을 구축할 수 있다. 일반적으로 서버를 관리할 때 버저닝 이슈는 큰 장벽이었지만 도커를 사용하면 이를 해결할 수 있다는 것이다.

최근에는 DevOps 방법론의 등장으로 개발주기가 짧아지면서 배포가 더 빈번하게 이루어 지고 마이크로서비스 아키텍처의 유행으로 프로그램은 더 잘게 쪼개어져 관리는 더 복잡해졌다. 이러한 상황에서 도커가 등장했고, 서버관리 방식이 완전히 바뀌었다.

도커 이전의 서버 관리

1. 서버 관리를 위한 ppt 작성

   문서의 정확성, 버전관리, 이슈 트래킹의 부족

2. 상태관리 도구

   CHEF, PUPPET, ANSIBLE 등의 도구로 install 명령어를 실행하는 코드를 작성

   코드라서 읽기 쉬움, 협업 및 버전관리의 용이

   학습의 코스트, 한 서버에 다른 버전 여러개 설치가 어렵다

3. 가상머신

   Jnekins, Wordpress, Chat 을 가상머신에 각각 설치하고 실행한다.

   한 서버에 여러 가상머신을 설치하기 쉽다. 현재 상태 저장 가능.

   처음부터 다시 셋팅하기 어렵고 서버 이미지 공유가 어려움. 느림.

4. 클라우드

   AWS, Google Cloud, Azure

   하드웨어 파편화 문제 해결, 가상화된 환경만으로 아키텍처 구성 가능, 이미지 기반으로 다수의 서버 관리 가능

   아직 서버를 관리 및 운영 문제가 남아 있다.

5. PaaS

   Platform as a Service

   Heroku, Netlify, AWS Elastic Beanstalk, Google Cloud App Engine

   서버를 운영하는 것이 복잡하고 어려우니 소스 코드만으로 배포가 가능하게 만듬

   일반화된 프로비저닝 방법을 제공하지만 과정에 개입할 수 없다

도커 등장

어떠한 프로그램도 컨테이너로 만들어서 docker compose up으로 어디서든 사용할 수 있다.

도커는 자원 격리가 가능하고(예: venv), 프로세스 및 파일, 디렉토리를 가상으로 분리하고 CPU, memory도 제한할 수 있다.

도커는 어떠한 원리로 동작하는 걸까?

docker의 구조

도커는 Client와 Server 구조로 되어있다.

사용자가 docker run 등의 명령어를 입력하면 이를 Server족에 전송하고, 이를 도커 daemon이 수행한다.

도커 daemon은 docker api 요청을 수신하고 이미지, 컨테이너, 네트워크, 볼륨 같은 도커 object를 관리한다.

도커 Registry는 Docker의 이미지 저장소이다. 도커 Hub라는 공용 레지스트리에서 이미지를 찾는다.

docker run hello-world을 실행했을 때 나오는 메세지

도커 Daemon이 docker Hub에서 image를 pull 해온다.

도커는 image를 참조하여 새로운 container를 만든다.

도커 Daemon이 출력 메세지를 클라이언트로 보내고, 도커 클라이언트는 메세지를 터미널로 보낸다.

참고 블로그: https://cultivo-hy.github.io/docker/image/usage/2019/03/14/Docker정리/

블로그에 공식문서를 번역해서 글을 작성했습니다.

Docker Image

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

도커 이미지는 컨테이너의 기반이다. 이미지는 루트 파일 시스템 변경 사항과 컨테이너
런타임 내에 사용할 해당 실행 매개 변수의 순서 모음이다.
이미지에는 일반적으로 계층화된 파일 시스템 조합이 서로 스택처럼 샇여있다.
이미지에는 상태가 없으며 절대 변경되지 않는다.

Docker Layer

도커 이미지는 컨테이너를 실행하기 위한 모든 정보를 가지고 있기 때문에 보통 용량이 수백MB에 이른다. 처음 이미지를 다운받을 땐 크게 부담이 안되지만 기존 이미지에 파일 하나 추가할 경우 수백MB를 다시 다운 받는 것은 매우 비효율적이다.

이런 문제를 해결하기 위해 Layer라는 개념을 사용하고 유니온 파일 시스템을 이용하여 여러개의 레이어를 하나의 파일시스템으로 사용할 수 있게 해준다. 이미지는 여러개의 읽기 전용 read only 레이어로 구성되고 파일이 축되거나 수정되면 새로운 레이어가 생성된다. ubuntu 이미지가 A + B + C 의 집합이라면 ubuntu 이미지를 베이스로 만든 nginx 이미지는 A + B + C + nginx 가 된다. webapp 이미지를 여기에 추가하면 A + B + C + nginx + source 레이어로 구성된다. webapp 소스를 수정하면 나머지 레이어를 제외한 새로운 source(v2)레이어만 다운받으면되 기 때문에 굉장히 효율적으로 이미지를 관리할 수 있다.

이미지에서 레이어는 도커 파일의 명령으로 표시되는 이미지의 변형이다.
레이어는 완성된 이미지을 생성하기 위해 기본 이미지에 순차적으로 된다. 
이미지가 업데이트되거나 재구성되면 변경된 계층만 업데이트하면 되고 
변경되지 않은 계층은 로컬로 캐시된다. 
이것이 Docker 이미지가 매우 빠르고 가벼운 이유 중 이다. 
각 Layer 크기를 합산한 것이 최종 이미지의 크기와 같다.

참고자료 : https://velog.io/@weekbelt/도커데몬Docker-Daemon

https://subicura.com/2017/01/19/docker-guide-for-beginners-1.html