[Docker] Docker 구조와 인프라

Docker를 쓰기전에… 알아가기

Docker란, 소프트웨어를 신속하게 구축하고, 테스트, 배포를 할 수 있도록 하는 플랫폼이다. (OS라고 소개하는 곳도 있다.) 컨테이너라는 단위로 애플리케이션 실행에 필요한 라이브러리 등을 패키징하고 이를 독립적으로 실행할 수 있도록 한다. 이런 컨테이너는 애플리케이션 실행에 필요한 파일을 포함하기 때문에 호스트에 설치를 필요하지 않는다. (OS에 구애받지 않음)

또한, 이러한 컨테이너를 쉽게 공유하기 쉽고 생명 주기 관리도 가능하다는 장점이 있다. 이러한 특징을 통해 빠르게 애플리케이션을 제공하고, 배포 뿐만 아니라 확장에도 도움이 된다. 정리하면 아래와 같다.

• 빠르고 일관된 애플리케이션 제공
• 배포 및 확장 용이
• 동일 하드웨어에서 더 많은 워크로드 수행

Docker 인프라에 대해서

Docker는 Immutable Infrastructure Paradigm(불변 인프라) 이라는 개념을 기반으로 한다고 한다. 이번에 설명하면서 용어 정리를 하자면, 인프라 종류 중 Mutable Infrastructure, Immutable Infrastructure 각각 가변 인프라, 불변 인프라 라고 칭하고 설명하겠다.

가변 인프라(기존에 주로 쓰이는 방식)는 서버가 수행되는 중에 개발자나 관리자가 SSH로 접속해서 해당 어플리케이션, 또는 패키징을 수동으로 업그레이드 또는 다운그레이드 하는 방식으로 진행 되었다. 이런 경우 기존 서버 환경의 수정이 일어나는 변경 가능한 인프라인 것이다.

하지만, 불변 인프라는 이와 반대로 서버가 배포된 후 수정되지 않는 것이다. 그렇다면, 배포 후 기능 개선, 추가 등 수정 사항은 어떻게 할까?

이 경우 해당 서버에 코드를 개선하는 것이 아니라 다른 서버에 기능 개선, 수정 등을 추가한 것으로 구성해 두고, 이후에 이전 서버를 대체하기 위해 미리 준비 해둔다. 미리 준비한, 프로비저닝 된 서버는 유효성이 검증되면 이전 서버를 폐기하고 사용하게 된다.

이런 방식을 사용하는 이유는 일관성과 안정성이 있고, 배포 단계가 간단하다. 이에 대해서 더 자세히 알아보자.

Mutable Infrastructure VS Immutable Infrastructure

과정, 목적 차이

둘은 위에서 설명했듯이 과정 자체가 다르고, 이러한 과정이 가지는 목적도 다르다. 가변 인프라는 일단 배포 후에 수정하도록 하였다면, 불변 인프라는 기존의 것을 유지하고, 다음 배포에 수정사항을 두고 교체하는 방식이다.

참고한 링크에서는 각 인프라에서 서버를 처리하는 방식이 다르다고 이야기 한다.

클라우드

클라우드가 상용화되기 이전에는 서버를 교체하기 위해서 물리적인 서버 하드웨어를 주문하고 세팅하는… 이런 시간이 오래걸린다는 문제가 있었다.

가변 인프라는 해당 문제에 대해서 기존 서버를 수정 가능하게 함으로써 따로 서버를 주문하고, 교체하는 것보다 기존에 사용하던 서버의 알맹이만 바꾸어서 사용하는 방식을 제공하는 것이다. 이렇게 빈번하게 수정함으로 서버 복제가 힘들고, 각 서버가 취약한 요소가 될 수 있는 문제가 있는 것이다.

하지만, 가상 서버와 클라우드를 통해서 이러한 가변 인프라보다 불변 인프라가 장점을 가지면서 서버 아키텍쳐의 전환점이 된 것이다. 가상 서버를 통해 생성-삭제가 몇 분 내로 가능해지고, 이를 통해서 프로비저닝 등과 같이 서버를 신속하게 배포하고, 일관성있게 생성할 수 있게 된 것이다.

개념적 차이 (애완동물 VS 가축)

애완동물 과 소에 대한 비유는 렌디 비어스 를 참고하였다. 가변 인프라의 경우 애완동물과 같아서 해당 애완동물을 잃어버리면 대체하기 힘들지만, 불변 인프라의 경우 가축을 잃어버려도 같이 언제든지 대체가 가능하다.

소와 같은 가축의 경우 번호가 매겨지는 데, 특정 소(서버)가 다운되어도 다른 넘버의 소(서버)로 대체가 가능하다는 뜻이다. 또한, 가변 인프라에 비해서 그 과정이 자동화 되고, 빠르기 때문에 여러 장점을 가지고 있다.

불변 인프라의 장점

• 일관된 스테이징 환경과 손쉬운 수평적 확장
• 배포 실패 감소 및 정상 작동 서버 상태 확인
• 간단한 롤백과 복구
• 배포 과정 자동화

이러한 특징을 Docker도 가지고 있다.

도커 아키텍쳐

여기서 해당 실행 파일을 이미지를 이미지라고 부르고, 컨테이너는 이 이미지를 실행한 상태로 응용 프로그램의 종속성, 패키징과 캡슐화가 된 격리된 공간을 의미한다.

요약해서 이렇게 설명했지만, 한번 자세히 살펴보자.

클라이언트에서 도커를 빌드하고 실행시키면, 호스트의 도커 데몬에서 이미지에 따른 컨테이너들을 실행시킨다. 이때 클라이언트는 컨테이너를 실행, 빌드, 배포를 하는 도커 데몬과 UNIX 소켓이나 네트워크 인터페이스를 통해 API를 사용해 통신한다.

해당 요소들을 정리하면 다음과 같다.

• 도커 데몬 도커 데몬은 클라이언트와 통신하며 컨테이너, 이미지, 네트워크 및 볼륨과 같은 객체들을 관리한다. 단순히 클라이언트 뿐만아니라 다른 데몬과 통신하기도 한다.

• 도커 클라이언트 도커 클라이언트는 실질적으로 사용자가 docker와 상호작용하는 기본 방식이다. 몇몇 명령어를 통해 쉽게 통신하고, 2개 이상의 데몬과 통신 할 수 있다.

• 도커 데스크탑 데스크탑은 컨테이너화 된 애플리케이션과 마이크로서비스를 구축하고 공유할 수 있는 애플리케이션이다. Docker Desktop에는 Docker 데몬, Docker 클라이언트, Docker Compose, Docker Content Trust, Kubernetes 및 Credential Helpe가 포함된다.

• 도커 레지스트리 레지스트리는 해당하는 도커 이미지를 저장한다. Docker Hub는 누구나 이용할 수 있는 공용 레지스트리로 해당 서비스를 통해 쉽게 이미지를 가져올 수 있다.

• 도커 객체
  • 이미지 이미지는 컨테이너 생성 지침이 포함된 읽기 전용 템플릿이다. 컨테이너 생성 정보들을 작성하고, 이를 통해 빌드 및 컨테이너 생성이 가능하다. 만약 고유한 이미지를 생성하려면, Dockerfile을 만들어서 직접 설정 할 수 있고, 수정사항이 있어 수정하고 이미지를 다시 빌드하면, 변경된 부분만 다시 빌드되어서 가볍고 빠르게 수행합니다.
  • 컨테이너 컨테이너는 이미지에서 설정한 내용을 통한 실행가능한 인스턴스이다. 컨테이너를 하나 이상의 네트워크에 연결하거나, 컨테이너에 스토리지를 연결하거나, 현재 상태를 기반으로 새 이미지를 생성할 수 있다. 각 컨테이너는 호스트 시스템과 다른 컨테이너와 격리되어있기 때문에 제어하기에도 편하고 취약성이 별로 없다.