컨테이너 & 이미지 % 레지스트리
컨테이너(Container)
애플리케이션이 의존성, 네트워크 환경, 파일 시스템에 구애받지 않고, 도커라는 기술 위에 실행될 수 있도록 만든 애플리케이션 상자이다.
- 물자를 싣고 내릴때에, 선박이 입항해 있는 시간을 획기적으로 단축시켜준다.
- 물자를 싣고 내릴때에, 필요한 인력(분류하는 사람, 짐 옮기는 사람, 감독하는 사람)을 대폭 감소시킨다,
이러한 컨테이너 기술을 "소프트웨어 수송, 즉 배포에 사용할 수 없을까? 라는 고민에서 시작
그 결과 리눅스 컨테이너 기술(lxc)를 만들어냄 그 자체로 훌륭하고 완성된 기술이었지만, 애플리케이션을 쉽게 컨테이너화할 수 있는 생태계 혹은 커뮤니티가 없었다.
여기서 도커(Docker) 등장
도커는 바로 Docker Hub라는 소프트웨어 저장소와 함께 빠르게 성장했고, 그 결과
개발자들은 쉽게 애플리케이션을 포장하고, 컨테이너 방식으로 실행할 수 있게 되었다.
실행 환경에 구애받지 않고 애플리케이션을 실행할 수 있다.
장점 1. 의존성 충돌 문제를 해결해준다.
어떤 애플리케이션은, 해당 애플리케이션을 실행하기 위해 반드시 어떤 환경이 구축되어 있어야 한다. 쉽게는 윈도우용 프로그램을 실행하려면 윈도우 운영체제가 필요하듯 말이다.
이와 같이 어떤 프로그램(A) 실행에 다른 프로그램(B)이 반드시 필요한 경우,
"프로그램 A는 프로그램 B에 의존 관계를 가지고 있다"고 말합니다.
하지만 이러한 의조선이 서로 충돌하는 경우가 있다.
컨테이너 기술은 바로 이 문제를 해결한다.
애플리케이션을 컨테이너 내에 구성한다. 즉, 컨테이너에서 실행 중인 애플리케이션은 어떠한 의존성도 공유하지 않고, 각자 고유의 의존성을 포함하고 있다는 이야기이다.
무엇을 격리하나??
- 프로세스
- 특정 컨테이너에서 작동하는 프로세스는 기본적으로 그 컨테이너 안에서만 액세스할 수 있다.
- 컨테이너 안에서 실행되는 프로세스는 다른 컨테이너의 프로세스에게 영향을 줄 수 없다.
- 네트워크
- 기본으로 컨테이너 하나에 하나의 IP 주소가 할당되어 있다.
- 파일 시스템
- 컨테이너 안에서 사용되는 파일 시스템은 구획화되어 있다. 그래서 해당 컨테이너에서의 명령이나 파일 등의 액세스를 제한할 수 있다
장점 2. 개발과 배포 환경을 일치시킨다.
개발을 진행하다보면 개발 환경을 일치시키는 과정은 생각보다 간단치 않다.
런타임 환경 버전을 얼추 비슷하게 맞춰야 되기도 하고, 시스템 환경 변수를 애플리케이션에 맞게 구성해야 제대로 작동하는 경우도 종종 볼 수 있다.
이러한 과정 중에 발생하는 사소한 실수나 사전 설치 항목의 부재는 문제 해결에 많은 시간을 소모하게 된다.(ㄹㅇ로)
애플리케이션 구성 자체가 컨테이너화되면 (이때 보통 Docker Compose라는 툴을 이용)
YAML 파일 하나 + 명령어 하나로
모든 애플리케이션 실행 환경 구성이 완료되는 기적을 볼 수 있다.
따라서
- OS에 상관없이 즉시 애플리케이션 실행 환경을 만들 수 있다.
- 개발을 컨테이너 위에서 진행할 경우, 모든 개발팀이 동일한 환경 하에 개발을 진행할 수 있다.
배포도 마찬가지다.
웹 서비스의 배포란
"어떤 애플리케이션이 특정 런타임 환경 위에서 실행되고, 사용자에게 이를 제공한다"라는 것인데,
이는 앞서 말한 실행 환경 구성과 본질적으로 다를 것이 없기 때문.
그저 서비스를 인터넷상에 공개적으로 노출하느냐,
내 컴퓨터 상에서 프라이빗하게 작동하느냐의 차이일 뿐이다.
장점 3. 수평 확장을 쉽게 해주며 즉, 서버에 새로운 내용을 배포하기 쉽게 만들어준다.
우리가 매일같이 사용하는 글로벌 웹 서비스는 전 세계인들이 사용하므로 그 트래픽이 어마어마하다.
예를 들어, 지금 이 시간에도 전 세계의 수많은 사람들이 google.com 에 접속할 텐데,
과연 수많은 사람들이 검색 서버라는 단 하나의 컴퓨터에 접속하고 있는 걸까?
그렇지 않다. 서비스 제공자들은 이러한 트래픽 분산을 위해 프록시 서버를 운영하며,
여러 대의 동일한 검색 서버 중 한 군데를 이용할 수 있도록 돕는다.
(이러한 서버를 리버스 프록시의 한 종류인 '로드 밸런서'라고 부른다)
더 많은 트래픽으로 인한 서버 증설에 컨테이너 기술은 아주 활발하게 이용되고 있다.
동일한 애플리케이션 구성(이미지)을 바탕으로 새로운 서버에
해당 애플리케이션을 컨테이너로 실행하고, 로드 밸런서에 이 서버를 추가하기만 하면 된다.
이미지
실행되는 모든 컨테이너는 이미지로부터 생성된다.
이미지는 애플리케이션 및 애플리케이션 구성을 함께 담아놓은 템플릿으로,
이를 이용해 즉시 컨테이너를 만들 수 있다.
이미지를 이용해 여러 개의 컨테이너를 생성할 수 있다. 이를 이용해 앞서 설명한 애플리케이션의 수평 확장이 가능하다.
이미지는 기본 이미지(base image)로부터 (마치 git을 사용하는 것처럼) 변경 사항을 추가/커밋해서 또 다른 이미지를 만들 수도 있다. 예를 들어 node.js로 작성된 애플리케이션을 이미지로 만들고 싶은 경우, nodejs 이미지를 기본 이미지로 삼고 내가 만든 애플리케이션을 추가해 넣고, 이미지화할 수 있다.
레지스트리
이미지는 레지스트리에 저장된다.
대표적인 이미지 레지스트리로는 Docker Hub, Amazon ECR이 있다.
도커 CLI에서 이미지를 이용해 컨테이너를 생성할 때, 호스트 컴퓨터에 이미지가 존재하지 않는다면, 기본 레지스트리로부터 다운로드 받게 된다.
