1. 도커 설치 환경에 대한 이해
도커를 사용하려면 docker engine
를 직접 받거나 docker-destop
을 설치를 해야 한다.
하지만 설치 방법에 대한 내용은 따로 정리하지 않으려 한다.
그 대신 사용목적이나 OS 환경에 따른 차이에 대한 내용을 정리하려 한다.
1.1. 사용목적에 따른 설치
참고: docker 공식 | docker-desktop
도커를 사용하는 목적을 크게 2개로 나눌 수 있다.
- 운영환경에서 컨테이너 환경 사용
- 개발환경에서 컨테이너 환경 사용
운영환경을 위해서는 docker image
를 빌드하고 이미지를 사용하여 컨테이너를 실행하고 관리해야 한다.
즉, docker engine
의 컨테이너 라이브사이클을 관리하는 기능을 중점으로 사용한다.
개발환경에서는 편리한 개발환경 셋팅과 팀원 간 동일한 개발환경을 가지는 것이 더 중요하다고 볼 수 있다.
때문에 개발환경에서는 docker-destop
를 설치하여 GUI 기반에서 사용한다.
(아래서 설명 하겠지만 Linux가 아닌 OS에서는 docker-destop
을 설치하는 것만 공식적으로 지원한다.)
두 가지 모두 크게 보면 컨테이너 기반의 일관된 사용성을 목적으로 하는 점은 같다.
하지만 설치된 두 환경에는 크게 다른 점이 존재한다.
1.2. OS 환경에 따른 차이점
참고
- docker docs | Desktop | Mac에 대한 FAQ
- docker docs | Desktop | Window에 대한 FAQ
- docker docs | Desktop | Linux용 FAQ
docker는 Linux 자체 기능인 chroot
, namespace
, cgroup
을 사용하여 구현된다.
하지만 Window와 Mac의 경우는 Linux 기반이 아니기 때문에 결국 하이퍼바이저 기능을 사용하여 실행된다.
mac의 경우 macOS의 Hypervisor.framework를 기반의
HyperKit
을 사용하여 구현되었다.- 'Intel mac'과 'Apple 실리콘 mac' 간의 차이도 존재한다.
- mac용 Docker Desktop의 경우 x86 기반으로 개발되었다.
- 때문에
v4.3.0
이전까지 'Apple 실리콘 mac'에서는 Rosetta 2가 필수로 필요했다. v4.3.0
이후 버전에서도 최상의 성능을 내려면 Rosetta를 설치하는 것을 권장한다.- 참고: docker docs | Mac 시스템 요구사항 & Apple support | Mac에 Rosetta …
window의
Hyper-V
을 사용하여 구현된다.- 정확히는 WSL 2를 사용하여 구현되며 WSL 2가
Hyper-V
를 사용하여 구현된다. - 참고: Microsoft learn | wsl-2
- 정확히는 WSL 2를 사용하여 구현되며 WSL 2가
2. 도커 아키텍처
참고: docker docs | overview | #docker-architecture
위의 그림처럼 도커는 '클라이언트-서버 아키텍처'를 사용한다.
도커의 클라이언트는 서버의 도커 데몬에게 명령을 전달하는 일을 수행한다.
클라이언트 서버라고 하지만 일반적으로 둘은 같은 호스트(시스템)에 설치되어 사용되며,
원격지에 설치된 서버와 REST API를 사용하여 통신할 수 있다.
2.1. Docker Client
도커 클라이언트는 기본적으로 docker cli를 통해 도커 데몬에게 명령을 전달한다.
또 다른 클라이언트로는 Docker Compose가 존재한다.
docker cli 명령은 기본적으로 컨테이너의 라이브 사이클에 대한 명령이다.
- 이미지 내려받기:
$ docker pull ...
- 컨테이너 생성:
$ docker create ...
- 컨테이너 실행:
$ docker start ...
- 컨테이너 생성+실행:
$ docker run ...
- 컨테이너 삭제:
$ docker rm ...
2.2. Docker Daemon(dockerd
)
도커 데몬( dockerd
)은 cli나 REST API(docker api) 요청을 받아서 컨테이너를 관리한다.
또한 데몬은 구성에 따라 다른 데몬과 통신하는 방법으로 사용할 수 있다.
도커 데몬은 클라이언트의 요청에 따른 컨테이너를 관리뿐만 아니라 다양한 일을 수행한다.
- 이미지 생성 및 관리
- 컨테이너 생성, 실행, 삭제 및 관리
- 도커 네트워크 구축 및 관리
- 볼륨 구성 및 마운트
- 실행 중인 컨테이너 로그를 외부 쉘로 출력하거나 내부 쉘 실행 등
3. 도커 라이브사이클
도커의 라이프사이클은 결국 컨테이너의 [생성 -> 실행 -> 종료 -> 삭제] 이다.
하지만 라이브사이클에 컨테이너 생명주기 외의 한 가지가 더 포함된다.
그것은 컨테이너 생성의 토대가 되는 이미지에 관련된 내용이다.
3.1. Docker Image
이미지(?) 도커를 사용하기 전에 알던 이미지는 jpg, png 같은 확장자를 가진 미디어 파일 뿐이었다.
물론 도커를 조금 써보면 이미지에 대한 정의 없이도 이해할 수 있다.
하지만 정의는 필요했기에 나름의 이해와 정의를 해보았다.
이미지는 Docker 컨테이너를 생성하기 위한 지침이 포함된 읽기 전용 템플릿입니다.
- 공식문서에 정의된 도커 이미지 정의
먼저 도커 이미지의 이미지는 소프트웨어에서 많이 사용하는 용어이다.
그리고 이미지는 스냅샷과 비슷한 개념을 가진다.
(이미지 보단 스냅샷 개념이 조금 더 이해하기 쉽다고 생각되어 개념을 빌려서 정의한다.)
이미지는 도커 컨테이너가 생성되기 위한 모든 환경을 스냅샷한 파일이다.
- 개인적인 정의
도커 이미지의 특징
- 도커 이미지에는 도커 컨테이너를 생성하기 위한 모든 환경이 포함된다.
- 모든 환경에는 OS 환경, 앱을 실행 시키기 실행환경 등이 포함된다.
- 이미지는 사용자가 정의해서 사용 할 수 있으며, 다른 이미지를 베이스로 사용하여 생성할 수 있다.
- 사용자 정의 이미지는
Dockerfile
을 통해서 정의한다.
- 사용자 정의 이미지는
- 한번 생성된 이미지는 수정이 불가능하며, 변경사항이 있다면 새로 만들어야 한다.
- 이미지는 Github 처럼 퍼블릿 저장소가 존재하며 대표적으로 Docker Hub이 존재한다.
- 이미지는 효율성을 위해 레이어로 관리된다.
이미지 레이어의 개념
- 왼쪽: 이미지 A를 지운다 하더라도 이미지 B에서 레이어 A, B, C를 사용하고 있기 때문에 지워지지 않다.
- 오른쪽: 이미 존재하는 레이어 A, B는 새로 다운로드 받을 필요가 없다.
- 때문에 이미지 설치시 호스트에 이미 레이어가 존재하는 경우 해당 레이어의 설치는 생략된다.
node 이미지 18.19.0 버전과 latast 버전 설치 예시
- 둘이 동일한 레이어를 사용하고 있기 때문에 같은 id를 사용하는 레이어는 설치가 생략된 것을 볼 수 있다.
3.2. Docker Registries
Docker Hub 처럼 이미지가 저장된 곳을 'Docker 레지스트리'라고 한다.
Docker Hub의 경우는 비공개도 가능하지만 기본적으로 공개 레지스트리로 사용된다.
또한 Docker은 기본적으로 Docker Hub에서 이미지를 찾아 사용한다.
대부분의 클라우드 벤더사는 자신들의 레지스트리를 가지고 있다.
- AWS - Amazon Elastic Container Registry (ECR)
- GCP - Google Container Registry (GCR)
- Azure - Azure Container Registry (ACR)
3.3. Docker Containers
컨테이너는 실행 가능한 이미지의 인스턴스이다.
쉽게 이해하려면 이미지가 '클래스' 컨테이너는 '인스턴스'라고 생각해도 좋다.
docker cli 명령(또는 API)으로 이미지를 통해 컨테이너를 생성할 수 있다.
생성된 컨테이너는 '실행', '이동', '삭제' 할 수 있다.
여기서 이해하기 어렵지만 아래와 같은 동작도 가능하다.
- 컨테이너를 하나 이상의 Docker Network나 Host Network 연결 할 수 있다.
- 컨테이너의 스토리지를 Host 스토리지에 연결 할 수 있다. (이를 마운트 한다고 한다.)
- 현재 상태를 기반으로 새 이미지를 생성할 수 있다.
- 외부와 격리하여 컨테이너 간에 통신도 가능하다.
참고
'{시리즈} > Docker' 카테고리의 다른 글
4. Docker 명령어 알아보기 (2) | 2023.12.04 |
---|---|
2. Docker란 (1) | 2023.11.28 |
1. Docker의 등장 배경 (1) | 2023.11.28 |