42서울/Inception

도커 이미지와 컨테이너 레포지토리 [42 inception 과제 개념 2]

뜨거운 개발자 2023. 6. 24. 17:56

도커 이미지와 도커 컨테이너

많은 사람들은 이 도커 이미지도커 컨테이너 용어를 혼용해서 사용하고 있습니다.

사실 이 둘 사이에는 큰 차이점이 존재합니다. 다만, 쉬운 이해를 위해 설명할 때도 혼용을 해서 많이 사용하였습니다.

💡
쉽게 이해하면 이미지는 컨테이너를 저장한 설계도 입니다.

이미지는 컨테이너를 저장하고 이동하는데 주로 사용 됩니다.

이미지를 실행하면 컨테이너가 실행이 됩니다.

👨🏻‍💻
이미지란, 실제 어플리케이션 패키지를 의미합니다. 이 패키지 내부에는 설정과 종속성 등 모든 것들이 들어있습니다. 또한 이미지는 이동 가능한 아티팩트입니다. 한마디로 말하면 완성품 패키지라고 보면 됩니다.

로컬 컴퓨터에서 필요한 이미지를 가져오고 이미지를 실행시킵니다.

그러면 이미지 내부 어플리케이션이 컨테이너 환경을 생성하는 어플리케이션을 시작시켜서 컨테이너가 실행되는 것 입니다.

👨🏻‍💻
이미지 하나를 이용해서 여러개의 컨테이너를 생성할 수 있습니다. 따라서 쉽게 생각하면 이미지는 컨테이너를 만드는 실행중이지 않은 설계도, 이미지를 실행하면 나오는 것이 컨테이너입니다.

실제 컨테이너를 실행해보는 실습을 진행한 후에 터미널에 docker ps 명령을 입력하면 실행중인 컨테이너를 보여주게 되는데, 컨테이너 ID, image, 실행 명령 등, 다양한 정보를 볼 수 있습니다.

Container Repository란? 컨테이너 저장소이다.

컨테이너는 portable하다는 것은 이전 글에서 설명했습니다. 그렇다면 컨테이너를 어떻게 공유하고 이동할 수 있을까요? 그것이 가능하기 위해서는 컨테이너를 위한 일종의 저장소가 필요합니다.

Container Repository란, 컨테이너를 저장하고 공유하기 위해 컨테이너를 저장할 수 있는 저장소입니다. 이것은 오직 컨테이너만을 위한 특별한 유형의 저장소입니다.

Container Repository는 크게 2가지 종류로 나뉩니다.

1. Public Repository(Docker hub)

첫번째는 Public Repository입니다. Public Repository는 응용 프로그램 컨테이너를 찾아보고 원하는 컨테이너를 얻을 수 있도록 해줍니다.

public repository Docker hub(https://hub.docker.com/)에는 10만개 이상의 많은 컨테이너 이미지를 볼 수 있습니다.

여기에는 DockerOFFICIAL 이미지도 있지만, 비공식 이미지들도 있는 것을 볼 수가 있습니다.

주로 일반적으로 도커 이미지를 다운로드 받을 때 이곳을 통해서 다운로드 받게 됩니다.

2. private repository

Deploy a registry server
Explains how to deploy a registry
https://docs.docker.com/registry/deploying/

많은 회사들은 호스트 또는 모든 컨테이너를 저장하는 방식으로 자체적인 private repository를 보유하고 있습니다. 이것을 활용해서 소유한 모든 Containerpush 할 수 있습니다.

이것은 외부에 공개 되지 않고 내부의 사람들(회사사람들)끼리만 이미지를 사용하는 용도로 주로 사용이 됩니다.

컨테이너가 개발 프로세스를 훨씬 효율적으로 만드는 방법

과거에는 10개의 서비스를 사용해야 이 프로그램을 실행할 수 있다면 저희는 10개의 프로그램을 반드시 호스트 하드웨어에 설치하고 호스트 운영체제가 관리 해야만 했습니다.

컨테이너는 이러한 문제들을 해결했습니다.

👨🏻‍💻
컨테이너를 사용하면 사실 운영체제 위에 직접적으로 서비스를 설치할 필요성이 없어집니다. 왜냐하면, 컨테이너는 리눅스 기반 이미지가 있는 자체 격리된 운영체제 계층이기 때문입니다. 완전히 격리된 환경이 컨테이너의 특징입니다.

어떤 프로그램을 실행하기 위해 이미지를 설치하는 상황을 가정해보겠습니다.

일반적인 프로그램 설치를 위해서 개발자는 컴퓨터에 다운로드할 바이너리를 찾아봐야 했습니다.

하지만 컨테이너(이미지)를 다운로드 하는 경우 컨테이너 저장소(container repository)체크아웃(check out)해서 필요한 컨테이너(이미지)를 찾아 로컬 컴퓨터에 다운로드 시킵니다.

Docker run 명령은 사실 컨테이너를 가져오고 동시에 시작하는 하나의 docker command입니다.

👨🏻‍💻
컨테이너를 사용하기 위해서 사용하는 명령과 문서 파일들은 운영체제마다 다른 게 아니라 정확히 동일한 파일을 사용합니다. 이것은 아주 큰 장점입니다.

이전에는 10개의 서비스를 설치해야만 한다면 운영체제마다 또, 컴퓨터 환경마다 다르게 설치를 했어야 했지만 이제는 10개의 도커 명령만 실행하면 설치가 됩니다.

로컬 환경과 동일한 프로그램의 다른 버전의 설치도 충돌 없이 사용할 수 있는 장점도 있습니다.

images layers (컨테이너의 기술적 개념)

컨테이너는 기술적으로 이미지로 구성이 됩니다. 겹겹이 쌓이 이미지 층(images layers) 구조를 가집니다.
👨🏻‍💻
모든 컨테이너 아래 가장 아래에는 리눅스 기반 이미지가 있습니다. 그것은 특정 버전의 Alpine이거나 또는 다른 Linux 배포판일 수도 있습니다.(그림의 Core Linux)

이런 리눅스 기반 이미지를 Base 이미지라고 부릅니다.

base 이미지의 가장 중요한 것은 크기가 작아야 합니다. 왜냐면, 컨테이너의 가장 큰 장점은 이식성과 적은 자원을 사용하는 것이기 때문입니다.

👨🏻‍💻
따라서 alpine은 컨테이너의 사이즈를 작게 유지할 수 있도록 해주는 경량화된 리눅스 배포 이미지입니다.

그리고 기반 이미지로 alpine을 사용하는게 설치 구조상 apt를 사용하는 데비안 계열보다 더 작은 규모로 필요한 것들만 설치할 수 있기 때문에 alpine 사용을 선호합니다. (따라서 inception 과제에서도 alpine을 기반으로 과제를 진행할 예정입니다.)

컨테이너는 base imageapplication image 사이에 중간 이미지가 존재합니다. 그림에서 보면 App 부분이 application image OS 부분이 base image 입니다.
그리고 그 중간 이미지에는 모든 구성 데이터(configuration data)가 있습니다.

그런데 뭔가 이상하지 않나요? 컨테이너는 어플리케이션 구조만 가상화 한다고 해놓고 왜 리눅스가 있을까요?

base image alpine?

Base 이미지는 컨테이너의 기본 구성 요소로, 컨테이너화된 애플리케이션을 빌드하고 실행하는 데 필요한 기본 운영 체제 구성 요소와 라이브러리 등이 포함되어 있습니다.

알파인 베이스 이미지에는 다음과 같은 것들이 포함되어 있습니다.

  1. Alpine Linux 운영 체제 컴포넌트: Alpine Linux의 최소 설치 또는 기본 설치를 기반으로 한 운영 체제 컴포넌트가 포함됩니다. 이에는 Alpine Linux에서 사용되는 파일 시스템, 패키지 관리자인 apk 등이 포함될 수 있습니다.
  1. 필수 라이브러리 및 도구: 컨테이너 내에서 실행되는 애플리케이션이 필요로 하는 필수 라이브러리와 도구들이 포함됩니다. 이는 일반적으로 컨테이너 내에서 애플리케이션을 실행하는 데 필요한 런타임 라이브러리, 네트워크 관련 도구, 디버깅 도구 등이 포함될 수 있습니다.

그래서 실제로 컨테이너에 접속해보면 간단한 리눅스 명령은 되지만 복잡한 리눅스 명령은 안되는 것이 많다는 것을 알 수가 있습니다. 이것은 경량화된 리눅스 배포이미지 이기 때문입니다.

👨🏻‍💻
컨테이너의 생명은 작은 크기이기 때문에 리눅스의 방대한 기능들을 다 넣으면 이미지의 크기가 너무 커지기 때문입니다.

그렇다면 cgroup과 chroot는 어디에 있어요?

컨테이너를 실행하면 다음과 같은 구조를 가집니다.

이전에 이야기 했듯 컨테이너는 리눅스의 기술입니다.

리눅스 커널의 기술인 cgroupsnamespace를 사용해서, 독립적이고 격리된 공간을 부여합니다.

그래서 컨테이너의 어플리케이션은 호스트 os의 리눅스 커널을 사용하지만, 독립된 공간을 보장받을 수 있는 것 입니다.

맥과 윈도우에서 컨테이너 기술

컨테이너 기술은 리눅스의 기술입니다. 그런데 어떻게 윈도우와 맥에서도 사용이 가능할까요?

윈도우, Mac에서는 cgroups, namespace와 같은 기능이 존재하지 않습니다. 따라서 해당 OS 환경에서 도커를 설치하게 된다면 위의 그림과 달리 LinuxKit을 통한 가상화 환경에서 실행하게 된다.

Under the Hood: Demystifying Docker Desktop For Mac
Docker is a full development platform for creating containerized apps, and Docker for Mac is the most efficient way to start and run Docker on your MacBook. It runs on a LinuxKit VM and NOT on VirtualBox or VMware Fusion. It embeds a hypervisor (based on xhyve), a Linux distribution which runs on LinuxKit and […]
https://collabnix.com/how-docker-for-mac-works-under-the-hood/

컨테이너 설치해보기

한번 내 터미널에서 docker run nignx 를 입력해봅니다.

이 명령을 실행하면, 가장 최신버전의 nginx 이미지를 가져오게 됩니다. 하지만 특정 버전을 선택해주고 싶다면 docker run postgress:9.6 이렇게 선택을 해주면 이미지를 가져오게 됩니다.

실제 이 명령은 로컬을 먼저 탐색해서 해당 이름을 가진 이미지가 있는지를 탐색합니다. 있다면 다운로드를 하지 않고 로컬에 있는 이미지를 사용해서 run합니다.

없는 경우에만 Docker Hub에서 이미지를 다운로드하게 됩니다. 다운로드가 완료 되면 한줄 단위로 다운로드가 되는 것을 볼 수가 있습니다. 이는 도커 컨테이너가 layers로 구성되는 것을 볼 수 있습니다.

설치가 완료되면 docker ps 명령을 실행하면 실행 중인 모든 컨테이너를 볼 수가 있습니다.

images layer 의 장점

images layer 구조의 장점은 다운로드를 할 때 이미 있는 부분은 다운로드 하지 않고 바뀌는 부분만 새로 다운로드 한다는 장점이 있습니다.

이미지를 여러 부분으로 쪼개서 새로운 업데이트가 있을 때 이미 해당 이미지가 있다면, 그 이미지는 유지하고 변경된 부분만 새로 다운로드 합니다.

이미지 layer형태로 하면 다음과 같이 이미 있는 부분은 다운로드 하지 않습니다.

예를 들어서 만약 새로운 버전의 업데이트 같은게 생겨서 이미지가 변경되는 경우를 가정해봅시다.

새로운 버전의 경우 이전에 설치했던 버전과 동일한 부분의 layer도 가지고 있습니다. 따라서 저희는 이전과 달라진 것들만 다운로드 받으면 됩니다. 즉 특정 변경 부분만 다운로드 하기 때문에 시간적, 통신적 측면에서 훨씬 더 효율적인 방식을 사용합니다.

👨🏻‍💻
이미지 layer구조의 장점은 두가지 다른 버전의 이미지를 충돌 없이 한개의 컴퓨터에 설치하는 것 뿐 아니라 두개의 다른 버전을 동시에 실행 가능하다는 장점이 있습니다.

이미지가 layer형태이기 때문에 분리되서 합쳐지기 때문에 충돌이 발생하지 않는 것 입니다. 이것은 아주 큰 장점입니다!!


Uploaded by N2T

728x90