[Kubernetes Foundation] Container

VM(Virtual Machines)과 컨테이너 비교

  VM을 시작할 때마다 운영 체제를 부팅하는 데 시간이 걸린다. 단일 VM 내에서 여러 애플리케이션을 실행하면, 또 다른 까다로운 문제가 발생한다. 종속 자원을 공유하는 애플리케이션은 서로 격리되지 않고, 한 애플리케이션의 자원 요구사항은 필요한 리소스의 다른 애플리케이션을 고갈시킬 수 있다. 또한 한 애플리케이션의 종속성 업그레이드로 인해 다른 애플리케이션의 작동이 중지될 수 있다. 이 문제를 해결하는 방법은 각 애플리케이션을 위한 전용 VM을 실행하는 것이다. 하지만 여기에서도 문제가 발생할 수 있다. 이 접근 방식을 수십만 개의 애플리케이션으로 확장하면 한계를 빠르게 확인할 수 있다. 간단한 커널 업데이트를 시도한다고 상상해보자. 대규모 시스템의 경우 전용 VM은 자원의 중복이고, 낭비다. 하지만, 한 가지 장점으로, 운영체제 수준으로 분리되어 있기 때문에 보안에 강하다.

 

 종속 문제를 해결하는 더 효율적인 방법은 애플리케이션 및 종속 수준에서 추상화 하는 것이다. 전체 운영체제를 가상화할 필요가 없고, 사용자 공간만 가상화하면 된다. 사용자 공간은 커널 위에 있는 모든 코드이며 애플리케이션과 종속 항목의 포함이다. 이것은 컨테이너를 생성한다는 의미다. 컨테이너는 전체 운영체제를 포함하지 않기 때문에 가볍다. 애플리케이션을 구성하는 프로세스를 시작 및 중지하고 전체 VM을 부팅하고, 각 애플리케이션의 운영체제를 초기화하지 않기 때문에 매우 빠르게 생성 및 종료할 수 있다. 컨테이너화는 코드 관리 진화의 다음 단계다.  컨테이너는 확장 가능한 고성능 애플리케이션을 제공하는 애플리케이션 중심 방식이기 때문에 개발자에게 매력적이다.

 

컨테이너와 컨테이너 이미지

 단순하게, 컨테이너 이미지가 실행 중인 인스턴스가 되는 것을 컨테이너라 한다. 소프트웨어를 컨테이너 이미지로 빌드함으로써, 개발자는 애플리케이션이 실행될 시스템에 대해 걱정할 필요 없이 애플리케이션을 쉽게 패키징하고 배송(ship)할 수 있다. 도커(Docker)는 애플리케이션과 컨테이너를 만들고 실행할 수 있는 오픈소스 기술이다. 컨테이너는 Linux 네임스페이스 를 사용하여 애플리케이션에서 볼 수 있는 항목(프로세스 ID 번호, 디렉토리 트리, IP 주소 등)을 제어하고, Linux cgroup을 사용하여 애플리케이션에서 사용할 수 있는 항목(CPU 시간, 메모리, IO 대역폭 및 기타 리소스)의 최대 낭비를 제어한다. (Linux 네임스페이스는 Kubernetes 네임스페이스와 다른 용어) 마지막으로 컨테이너는 통합 파일 시스템을 사용하여 애플리케이션과 종속성(dependencies)을 효율적인 최소 계층(minimal layers)으로 캡슐화한다.

 

 

컨테이너 이미지 레이어

 

 컨테이너 이미지는 레이어로 구성된다. 이미지를 빌드하는 데 사용하는 도구는 컨테이너 매니페스트라는 파일에서 지침을 읽는다.

도커(Docker)는 애플리케이션과 컨테이너를 만들고 실행할 수 있는 오픈소스 기술이다. Docker 형식의 컨테이너 이미지는 매니페스트(Manifest) 파일을 Dockerfile이라고 한다. Dockerfile의 4가지 명령어(FROM, COPY, RUN, CMD)는 컨테이너 이미지 내부의 레이어를 지정한다. 각 레이어는 읽기 전용이다. 컨테이너가 이미지에서 실행되면, 쓰기 가능한 임시 최상위 레이어도 있다. 이 레이어를 컨테이너 레이어라고 한다. 컨테이너 레이어의 콘텐츠 컨테이너가 삭제되면 내용이 손실된다. 새 파일 쓰기, 기존 파일 수정, 파일 삭제와 같이 실행 중인 컨테이너에 대한 모든 변경 사항은 쓰기 가능한 컨테이너 레이어에 기록된다. 컨테이너에 대한 이러한 특징은 애플리케이션 설계에 영향을 미친다. 즉, 데이터를 영구적으로 저장하려면 실행 중인 컨테이너 이미지가 아닌 다른 위치에 저장해야 한다.

 

• FROM 문은 공개 저장소에서 가져온 기본 레이어를 만드는 것으로 시작한다.
• COPY 명령어는 빌드 도구의 현재 디렉터리에서 복사한 일부 파일이 포함된 새 레이어를 추가한다.
• RUN 명령어는 make 명령어를 사용하여 애플리케이션을 빌드하고 빌드 결과를 세 번째 레이어에 넣는다.
• CMD 명령어는 마지막 레이어로 컨테이너가 시작될 때 컨테이너 내에서 실행할 COMMAND를 지정한다. 

 

 각 레이어는 이전 레이어와의 차이점 집합일 뿐이다. 그렇기 때문에 업데이트할 때 차이점만 복사하면 되고, 새 가상 머신을 실행하는 것보다 훨씬 빠르다. Dockerfile을 작성할 때 변경 가능성이 가장 낮은 계층부터 변경 가능성이 가장 높은 계층까지 구성해야 한다.

 

요즘에는 실행하는 컨테이너와 동일한 컨테이너에 애플리케이션을 빌드하지 않는 것이 좋다.

 

 빌드 도구들은 배포된 컨테이너를 어수선하게 만들고, 최악의 경우 추가 공격 영역이 된다. 애플리케이션 패키징은 하나의 컨테이너가 최종 실행 가능한 이미지를 빌드하고, 또 다른 별도의 컨테이너가 애플리케이션을 실제로 실행하는 데 필요한 것만 받는 다단계 빌드 프로세스에 의존한다.

 

GCP Cloud Build

오픈소스 Docker 명령어는 자체 컨테이너 이미지를 빌드하는 인기 있는 방법이다. 널리 알려져 있고 널리 사용 가능합니다. 그러나 Docker 명령어로 컨테이너를 빌드할 때의 한 가지 단점은 빌드를 수행하는 컴퓨터를 신뢰해야 한다는 것이다.

 

 GCP 에서는 통합되는 컨테이너 빌드를 위한 관리형 서비스를 제공하는데 이 서비스를 Cloud Build라고 한다. Google의 Cloud Build를 사용하여 Docker 형식의 컨테이너 이미지를 만든다. Cloud Build는 다양한 저장 위치에서 빌드의 소스 코드를 검색할 수 있다. 

 

참고:

- https://www.44bits.io/ko/keyword/linux-namespace#%EB%A6%AC%EB%88%85%EC%8A%A4-%EB%84%A4%EC%9E%84%EC%8A%A4%ED%8E%98%EC%9D%B4%EC%8A%A4%EB%9E%80

- https://dobby-the-house-elf.tistory.com/109