Docker 를 사용한 이유 (Why Docker?)

• Docker Architecture

docs.docker.com

 

• Docker
  • Docker Client
    • Docker API request 를 Docker Daemon 에 전달
      • docker build
      • docker pull
      • docker run
  • DOCKER_HOST
    • Docker daemon
      • Docker API request and manages Docker objects (images, containers, networks, volumes)
    • Images
      • read-only template with instructions for creating a Docker container
      • Dockerfile 을 이용한 Image build
      • 기존 Image 를 활용하여 기능을 추가할 수 있다. (Each instruction in a Dockerfile creates a layer in the image)
        • 기능을 추가한 뒤 rebuild 하여 이미지 관리가능
    • Containers
      • 이미지의 실행 가능한 인스턴스 (A container is a runnable instance of an image)
      • Docker API or CLI 를 이용해 create, start, stop, move, delete 가능
      • 기본적으로 Container 는 network, storage 등 시스템이 다른 Container 나 Host 와 분리된다
      • 컨테이너를 제거하면 저장되지 않은 상태는 삭제된다. (volume 을 활용해서 host 에 저장하기)
    • Registry
      • Docker Image 를 저장하는 공간
      • Docker Hub 를 이용해 public registry 에 올릴수도 있음
      • docker pull or run command 실행 시 registry 에서 Image 를 가져오며 Docker Hub 를 Default 로 사용한다  (https://hub.docker.com/)

 

Docker 도입 이유 (Why Docker?)

 

Case. Docker 가 없을 때
 - OS 별 패키지 설치 방식의 차이가 있다. (Debian & CentOS)
 - 개발환경 준비 - 개발 - 배포준비 (사용된 라이브러리, 운영환경 세팅 등) - 운영환경에서 테스트 - 오류수정 - 배포완료
 - 배포준비가 운영환경에 영향을 받는다. (운영환경 개수 == 배포준비 개수)
 - 서비스 확장 시 모든 배포환경에 업데이트 필요
 - 확장에 따른 별도의 버전관리가 필요함
 - 업무 인계 시 개발 및 운영환경에 대한 파악이 필요함

Case. Docker 가 있을 때
 - 패키지 설치 시 Docker Hub 를 이용하여 Image 를 내려받고 바로 사용할 수 있다.
 - 개발환경이 준비된 Container 에서 개발 - Image 로 빌드 - 운영환경으로 이관 - 테스트 - 배포완료
 - Container 가 별도의 환경을 가지기 때문에 배포가 운영환경에 영향을 받지 않는다.
 - 서비스 확장 시 Docker Image 를 업데이트하면 된다.
 - 업데이트 히스토리를 이용해 버전관리가 자연스럽게 된다.
 - 업무 인계 시 Image 환경에 대한 파악이 필요없음

 

 

Docker 로 배포를 한다는 것은
하나의 모듈을 만드는 것이 아니라
하나의 기능을 담당하는 마이크로 서비스를 만든다고 생각한다.
이에 대한 확장성은 사용하지 않을 때와 비교하지 못할정도가 아닐까..

 

 

새로운 기술을 도입한다는 것에 대해 부정적 견해가 있을 수 있다.

그 중 크게 '배포', '수정', '관리' 에 대한 질문이 돌아왔다.

 

이에 대한 해결방안은 Dockerize 과정을 정리하며 풀어나가겠다.