Docker, 컨테이너에 대해서

Docker와 컨테이너 기술에 대한 것

 

컨테이너 기술과 Docker를 명확하게 구분해서 설명하기

컨테이너 기술이 Docker 이전에도 존재했던 개념임을 이해하고, Docker가 컨테이너 기술을 구현한 하나의 도구라는 관점에서 설명하기. 또한 Docker외에 컨테이너 기술을 구현한 다른 도구의 예시를 들기

 

Docker이미지, 컨테이너 둘 다 애플리케이션 배포 기술임

 

Docker와 컨테이너의 차이점

내가 보고도 뭔소린지 이해를 못해서 여러번 적는다. 이게 대체 뭐야?

 

Docker는 소프트웨어를 컨테이너에 패키징하는 소프트웨어 플랫폼이고,

Docker 이미지는 컨테이너 생성 지침이 포함된 읽기 전용 템플릿임.. 컨테이너 내에서 애플리케이션을 실행하는 데 필요한 라이브러리 및 종속성의 스냅샷 또는 청사진이라고 한다.

Docker는 소프트웨어, Docker이미지는 템플릿?

 

컨테이너는 '격리된 공간에서 프로세스가 동작하게 해주는 가상화 기술'이고

Docker는 컨테이너라는 기술을 사용자가 편리하게 제공해주는 '플랫폼'이다..

 

컨테이너는 애플리케이션과 모든 종속성을 묶어 격리된 환경에서 실행되도록 하는 기술이다

Docker는 컨테이너 기반의 애플리케이션을 구축, 배포, 실행, 관리하기 위한 플랫폼이다..

 

컨테이너

출처 : https://colevelup.tistory.com/30

출처를 적극적으로 활용했습니다

 

Docker 래퍼런스 왈

컨테이너는 애플리케이션이 하나의 컴퓨터 환경에서 다른 컴퓨터 환경으로 빠르고 안정적으로 실행될 수 있도록 코드와 모든 종속성을 패키징하는 표준 소프트웨어 단위이다

Docker 컨테이너 이미지는 코드, 런타임, 시스템 도구, 시스템 라이브러리 및 설정 등 애플리케이션을 실행하는 데 필요한 모든것을 포함하는 경량의 독립 실행형 소프트웨어 패키지이다

 

컨테이너화

기본 운영체제(OS) 커널을 동일한 시스템의 다른 컨테이너와 공유하는 격리된 환경에서 애플리케이션을 실행하는 방법임

컨테이너는 종속성, 필요한 라이브러리 및 바이너리와 함께 애플리케이션을 컨테이너 이미지라고 하는 독립된 패키지로 패키지화하여 여러 컴퓨팅 환경에 쉽게 배포할 수 있다.

OS레벨에서 애플리케이션 실행 환경을 격리하여 마치 다른 OS에서 동작하는것과 같은 가상 실행 환경을 제공한다고 보면 된다.

 

컨테이너 기반 가상화는 기존의 가상화와 달리 하이퍼바이저 위에 여러개의 Guest OS를 실행하는 대신

호스트 OS 커널을 사용하여 격리된 여러개의 컨테이너를 실행한다.

 

 Docker

Docker를 이해하려면 컨테이너를 알아야함. 컨테이너를 활용하는게 Docker니까

컨테이너 기반의 가상화 오픈소스 플랫폼

리눅스의 응용프로그램들을 소프트웨어 컨테이너 안에 배치시키는 일을 자동화하는 오픈소스 프로젝트라고 함

 

VMware, Virtual Box, SandBox 등을 활용해서 내 Host OS 위에 다른 OS를 사용하는 경우가 있다. 실제로 나도 써봤음

이건 OS 전체를 가상화하는 방식으로 기존 OS와 완전히 다른, 완전하고 독립적인 OS를 생성한다

이 방식은 Host OS의 자원을 할당받아서 사용하기 때문에 속도가 느리며, 새로운 운영체제를 프로그램에 설치하기 때문에 소모되는 자원이 크고 용량도 많이 차지한다.

 

이를 보완하기 위한 개념이 컨테이너임

각 컨테이너는 하나의 격리된 프로세스 공간이라고 한다

컨테이너는 OS를 가상화하여 Host OS와 커널을 공유하면서 이를 하나의 프로세스로 간주하여 격리된 환경에서 실행하는 개념임

할당받은 하드웨어 전체를 가상화하는 가상머신과 달리 os까지 완전 독립되지 않고 서로 커널을 공유하는 방식이다.

따라서 부담이 적고 속도가 빠르며 자원 할당량도 적다.

 

이러한 컨테이너 기반의 플랫폼이 Docker임

즉 컨테이너라는 개념이 등장하고 Docker가 생긴것

컨테이너와 가상머신의 구조, 출처 Docker 홈페이지

 

 

가상머신의 경우 Hypervisor라는 하드웨어에서 시스템 OS와 리소스를 분리해 가상머신에 할당하여 구동하는 소프트웨어 위에서

각각의 독립된 OS가 실행된다. Host OS의 자원을 공유해서 사용하기 때문에 시스템 자원을 많이 잡아먹는다.

VMware같은 프로그램에서 OS를 2,3개 실행시키면 부담이 엄청 커지겠죠?

* 가상머신은 하드웨어의 리소스를 가상화하여 동작한다.

 

컨테이너의 경우 Host(Host Operating System)위에 Docker를 설치한다.

그 위에 각 서비스 환경을 컨테이너로 패키징하여 설치하고 운영하는 형태를 가진다.

OS를 프로그램에 통째로 설치하는게 아니라 이미지를 설치한다.

이 이미지 안에 필요한 설정파일 및 컨테이너를 실행하기 위한 모든 정보가 담겨있다.

만약 Docker로 리눅스 서버를 구축한다고 하면, 리눅스 이미지를 다운받아서 컨테이너를 생성한 다음 서버를 구축하면 됨

* 컨테이너 방식은 OS를 가상화하여 동작한다.

 

 

Docker외에 컨테이너 기술을 구현한 도구들

출처 : https://nangman14.tistory.com/92

출처의 글을 적극적으로 활용했습니다

 

컨테이너 기술을 구현한 대표적인 도구는 Docker임이 맞는것 같다.

Docker의 특징

 - Docker Daemon

Docker는 이미지 빌드 등의 동작을 위해 Docker daemon을 사용함.. 이는 노드가 분산되어있는 Kubernetes(쿠버네티스) 환경에서 많은 자원을 요구하기 때문에 비효율적이다

또한 Docker Daemon은 Host에 대해서 Root Privilege를 요구함, 보안에 취약하다

따라서 Kubernetes 환경에서 Docker를 빌드 도구로 사용하는건 좋지 않다!

 

그 외의 도구들

Buildpack / Kaniko / Buildah / Buildkit

 

이중 Kaniko, Buildah, Buildkit 이미지 빌드 도구들에 대해서

공통점

 - OCI Compliant

세 도구 모두 OCI(Open Container Initiative) 규격을 따르는 컨테이너 이미지 빌드 가능

 - Daemonless

세 도구 모두 Docker Daemon이나 유사한 Daemon을 필요로 하지 않는다. 이에 따른 자원의 소모량, 보안문제 해결가능

 - Multi-stage Build

세 도구 모두 이전 스테이지에서 빌드한 결과물을 다음 스테이지에서 사용할 수 있게 해주는 Multi-stage build 사용가능

이 기능을 통해 Dockerfile을 간결하게 유지할 수 있으며, 빌드의 효율성을 높일 수 있음

 

 

차이점

1. Security(보안)에서의 차이점

 - Kaniko

Kaniko는 이미지 빌드를 위해 컨테이너 내에서 Root 권한을 필요로 하지만, Privileged 컨테이너를 요구하지는 않음

Root는 컨테이너 내부에서만 루트 권한을 부여하지만, Privileged는 컨테이너 내부에서 부여된 권한을 Host에도 부여한다.

즉 Kaniko는 컨테이너 내에서 Root권한을 가질 수 있지만 이게 Host까지 미치지는 못함

 

 - Buildkit

Buildkit은 Rootless버전을 제공해서 Root권한 없이 이미지를 빌드할 수 있음

하지만 seccomp, AppArmor를 Disable해야하기 때문에 Linux Kernal(리눅스 커널)에서 보안 취약점을 노출하게 된다

GCP(?)의 GKE(?)에 있는 COS(Container Optimized OS)를 사용할 시 Rootless모드에서 volume을 마운트할 수 없는 이슈가 존재해서 COS환경에서는 Root모드로 실행해야한다..

 

 - Buildah

Buildah도 Rootless버전을 지원해서 Root권한 없이 이미지 빌드 가능

하지만 Rootless버전이 GKE COS에서 정상적으로 작동하지 않는 것으로 확인된다고 함

 

 

2. Caching(캐싱)

 - Kaniko

Kaniko는 Snapshot(스냅샷) 기능이 존재한다.

Snapshot 기능은 이미지의 Filesystem을 tarball로 압축해서 Layer로 보관하는 Kaniko의 캐싱방법임

Kaniko는 Base image의 Filesystem을 포함해서 각 Dockerfile의 Layer를 Snapshot해서 캐싱한다

이후 캐시값 비교를 통해 캐시된 Layer와 같은 Layer가 존재한다면 Kaniko는 해당 Layer를 새로 빌드하는 대신 캐시를 사용함

또한 Kaniko는 캐시를 외부 리포지토리에 저장하고 가져올 수 있는 Remote캐싱을 지원해서 CI/CD Pipeline(파이프라인) 환경에서 사용하기 유리하다는 장점이 존재함

 

 - Buildkit

Buildkit도 Layer단위로 캐싱을 수행해서 이미지를 빌드할 때 각 Layer의 해시값을 비교해서 캐시가 맞는지 판단함

또한 외부 리포지토리에 캐시를 저장하고 가져오는 Remote 캐싱을 지원해서 CI/CD Pipeline 환경에서 유리함

추가로, Buildkit은 이미지 자체에 캐시를 저장하는 Inline캐싱 방식을 지원해서 리포지토리를 간결하게 유지할 수 있다

 

 - Buildah

Buildah가 Dockerfile을 기반으로 이미지를 빌드하는 buildah bud 명령어는 Remote 캐싱 기능을 제공하지 않는다고 한다.(2023)

현재 Remote 캐싱은 스크립트 언어 기반으로 레이어를 추가하는 buildah add 명령어를 통해서만 Remote 캐싱이 가능함

Local Cache를 사용할 수 없는 CI/CD Pipeline 환경에서는 Docker파일을 이용한 빌드를 할 때 캐싱기능을 사용할 수 없다는 단점이 존재한다..