LXC는 Linux 컨테이너를 대중이 쉽게 이용할 수있게했습니다. Docker의 첫 번째 구현도 LXC 를 그대로 사용했습니다.

다만 아쉬운 점은 LXC는 Solaris Zones와 BSD Jails와 마찬가지로 시스템 관리자에게 경량의 VM 경험을 제공하려는 시도에 머물러 있다는 것입니다.

반면 Docker의 초점은 처음부터 랩톱 및 Linux 배포판 전반에 걸쳐 개발자 커뮤니티에 컨테이너 혜택을 제공하는 데있었습니다.

이 목표를 실현하기 위해 0.9 버전을 시작한 Docker는 LXC에 대한 지원을 기본 실행 환경으로 지정하지 않고 libcontainer라는 자체 구현으로 대체했으며 결국 OCI 사양을 준수하는 runC로 대체했습니다.

rkt, OpenVZ, Cloud Foundry Garden과 같은 다른 컨테이너 대안이 있지만 그 사용은 다소 제한적입니다.

Docker는 거대한 설치 기반과 생태계 파트너뿐 아니라이 솔루션을 위해 구축 된 고급 도구 및 시설을 갖춘 컨테이너 화를 시장에 선 보이기위한 경쟁에서 중요한 선두를 확립했습니다.

Architecture

코어에서 Docker, LXC 및 기타 컨테이너 기술은 cgroup 및 namespace의 주요 Linux 커널 기능에 의존합니다.

이러한 커널 기능에 대한 자세한 정보를 얻으려면 Jérôme Petazzoni 를 보는 것이 좋습니다.

Docker 아키텍처는 libxc 대신 libcontainer라는 자체 라이브러리를 구현하여 여러 Linux 배포에 실행 환경을 제공하는 LXC와 매우 비슷하게 보입니다.

시간이 지남에 따라 더 큰 오픈 소스 생태계에 더 잘 부합하고 산업 표준을 준수하기 위해 여러 추상화 레이어를 추가했습니다.

현재 두 가지 주요 Docker 엔진 구성 요소는 containerd 및 runC입니다.

Docker는 이미지 Format 및 Daemon, 그리고 관련된 추가기능을 의미합니다.

Docker 아키텍처는 다음과 같은 구성 요소로 이루어져 있습니다.

• Docker daemon: runs on a host
• Client:  daemon에 연결하고 기본 사용자 인터페이스
• Images: read-only template used to create containers
• Containers: runnable instance of a Docker image
• Registry: Docker image의 개인 또는 공개 레지스트리
• Services: 다중 호스트, 다중 컨테이너 배포를 가능하게하는 Swarm이라는 scheduling 서비스. Swarm은 버전 1.12에서 소개되었습니다.

For more details, refer to the Docker documentation.

Storage Management LXC vs Docker

LXC 스토리지 관리는 다소 단순합니다. 그것은 btrfs, lvm, overlayfs 및 zfs와 같은 다양한 저장소 백엔드를 지원합니다.

그러나 기본적으로 (저장소 백엔드가 정의되지 않은 경우) LXC는 / var / lib / lxc / [container-name] / rootfs 아래에 루트 파일 시스템을 저장합니다.

데이터베이스 및 기타 데이터가 많은 응용 프로그램의 경우 rootfs에 직접 데이터를로드하거나 데이터 및 rootfs에 대해 별도의 외부 공유 저장 장치 볼륨을 마운트 할 수 있습니다.

이를 통해 SAN 또는 NAS 스토리지 배열의 기능을 활용할 수 있습니다.

LXC 컨테이너에서 이미지를 생성하면 rootfs 디렉토리를 tar'ing하면됩니다.

반면 Docker는 컨테이너 저장 및 이미지 관리를위한 보다 정교한 솔루션을 제공합니다.

우선 이미지 저장부터 예기를 하면,

Docker 이미지는 파일 시스템의 차이점을 나타내는 읽기 전용 레이어 목록을 참조합니다.

이 이미지들은 위의 그림에서 볼 수 있듯이 서로 겹쳐져있어 컨테이너 루트 파일 시스템의 기초를 형성합니다.

Docker 저장소 드라이버는 여러 계층을 스택하고 유지 관리합니다. 스토리지 드라이버는 또한 이미지의 레이어 공유를 관리합니다.

따라서 이미지를 빠르게 만들고, 당기고, 밀어 넣고, 복사하는 작업이 빨라지고 저장 공간이 절약됩니다.

컨테이너를 만들고 각각의 컨테이너에 쓰기 가능한 컨테이너 Layer를 가져오고 모든 변경 사항을 이 컨테이너 Layer에 저장하면 여러 컨테이너가 동일한 기본 이미지에 대한 액세스를 공유 할 수 있지만 자체 데이터 상태를 가질 수 있습니다.

Docker는 기본적으로 이미지와 컨테이너 모두에서 CoW (Copy-On-Write) 기술을 사용합니다.

이 CoW 전략은 이미지 디스크 공간 사용량과 컨테이너 시작 시간 성능을 모두 최적화합니다.

컨테이너를 삭제하면 저장된 모든 데이터가 손실됩니다.

영구 저장 장치가 필요한 데이터베이스 및 데이터 중심 응용 프로그램의 경우 Docker는 호스트의 파일 시스템을 컨테이너에 직접 마운트 할 수 있습니다.

이렇게하면 컨테이너가 삭제 된 후에도 데이터가 유지되고 여러 컨테이너에서 데이터를 공유 할 수 있습니다.

Docker를 사용하면 Docker Volume Plug-ins을 통해 AWS EBS와 같은 외부 스토리지 어레이 및 스토리지 서비스에서 데이터 볼륨을 마운팅 할 수 있습니다.

Docker 스토리지에 대한 자세한 내용은 해당 문서를 참조하십시오. refer to their documentation.

Client Tools and Onboarding

앞서 설립 한 BSD jails와 LXC는 경량 가상화 솔루션을 제공한다는 목표하에 IT 운영자에 중점을 두었습니다.

즉, 시스템 관리자가 하이퍼 바이저 기반 가상화에서 LXC로 전환하는 것은 쉽지 않습니다.

컨테이너 템플리트 작성에서부터 컨테이너 배치, OS 구성, 네트워킹, 스토리지 마운트, 응용 프로그램 배치 등 모든 작업이 동일하게 유지됩니다.

실제로 LXC는 직접 SSH 액세스를 제공합니다. 즉, VM 및 물리적 서버용으로 작성된 모든 스크립트 및 자동화 워크 플로가 LXC 컨테이너에도 적용됩니다.

또한 LXC는 필수 패키지를 설치하고 필수 구성 파일을 만드는 쉘 스크립트 인 템플릿 개념을 지원합니다.

Docker는 주로 개발자 커뮤니티에 집중했습니다.

그 결과, 이미지를 빌드, 버전 및 배포하고, 컨테이너를 배포 및 관리하고, 응용 프로그램과 모든 종속성을 이미지에 패키지화하는 사용자 지정 솔루션과 도구를 제공합니다.

주요 Docker 클라이언트 도구

• Dockerfile - 이미지를 어셈블하기 위해 사용자가 명령 줄에서 호출 할 수있는 모든 명령을 포함하는 텍스트 파일입니다.

• Docker CLI - 모든 Docker 기능을 사용하기위한 기본 인터페이스입니다.

• Docker Compose - 간단한 YAML 파일을 사용하여 다중 컨테이너 Docker 응용 프로그램을 정의하고 실행하기위한 도구입니다.

Docker는 수많은 맞춤형 툴을 통해 사용하기 쉽지만, 더 커진 학습 곡선을 희생해야한다는 점에 유의해야합니다.

개발자 인 경우 VirtualBox, VMware 워크 스테이션 / 플레이어 및 유모차 등을 사용하여 신속한 개발 환경을 만드는 데 익숙합니다.

한편, 관리자는 테스트 및 프로덕션 환경을 관리하기위한 자체 스크립트 및 자동화 워크 플로를 구축했습니다.

이 두 그룹 모두 개발 환경 ! = 생산 환경이라는 산업계에서 인정한 표준을 고려할 때 이러한 구성에 익숙해졌습니다.

Docker는 이러한 개념에 도전하고이 두 그룹이 전체 제품 파이프 라인에서 표준 도구와 기술을 사용하도록 유도하고 있습니다.

개발자들은 Docker가 직관적이고 사용하기 쉽다고 생각하지만 특히 생산성을 얼마나 크게 향상시킬 수 있는지를 감안할 때 IT 관리자는 컨테이너와 VM이 공존 할 수있는 세상에서 아이디어를 쏟아 내고 작업을 시도하고 있습니다.

IT 관리자를위한 Docker 학습 곡선은 기존 스크립트를 변경해야하는만큼 가파른 수준입니다.

SSH 액세스는 기본적으로 사용할 수 없으며 보안 고려 사항은 새로운 것입니다.

또한 새로운 마이크로 서비스 아키텍처를 사용하여 일반적인 3-Tier 전통적 응용 프로그램과 관련된 일련의 프로세스에 도전합니다.

Image Registry

Docker 아키텍처의 핵심 구성 요소 중 하나는 Docker 이미지를 저장하고 배포 할 수있는 이미지 레지스트리입니다.

Docker는 개인 이미지 레지스트리와 모든 Docker 사용자가 액세스 할 수있는 Docker Hub라는이 레지스트리의 공개 호스팅 버전을 제공합니다.

또한 Docker 클라이언트는 Docker Hub와 직접 통합되어 있으므로 터미널에서`Docker run 우분투 '를 실행하면 데몬은 필수 Docker 이미지를 공개 레지스트리에서 가져옵니다.

Docker를 처음 사용하는 경우 Docker Hub를 방문하고 사용할 수있는 수십만 개의 컨테이너 이미지를 탐색하는 것이 가장 좋습니다.

Docker 허브는 2013 년 3 월에 출시되었지만 2016 년 10 월 현재 Docker Inc에 따르면 이미 60 억 개가 넘었습니다.

Docker Hub 외에도 Quay, AWS, JFrog 등 API 호환 Docker 레지스트리를 제공하는 많은 벤더가 있습니다.

반면에 LXC는 컨테이너 파일 시스템과 이미지 측면에서 스토리지 관리가 단순하기 때문에 특별한 레지스트리가 필요하지 않습니다.

LXC를 지원하는 대부분의 공급 업체는 일반적으로 LXC 이미지를 저장하고 이를 다른 서버에 스테이징하기위한 사용자 정의 메커니즘을 제공합니다.

Linuxcontainers.org 웹 사이트는 커뮤니티에서 지원하는 LXC 이미지 템플릿을 사용하여 빌드 된 기본 이미지 목록을 제공합니다.

Docker와 마찬가지로 LXC는 위의 소스에서 이미지를 검색하고 동적으로 컨테이너를 만드는 데 사용할 수있는 다운로드 템플릿을 제공합니다.

명령은`sudo lxc-create -t download -n`과 같습니다.

Application Support

응용 프로그램 공간은 대략 모던, 마이크로 서비스 기반 및 전통적인 엔터프라이즈 응용 프로그램으로 분류 할 수 있습니다.

Microservices 아키텍처는 Netflix, Google, Twitter 등과 같은 새로운 웹 규모의 회사들 사이에서 인기를 얻었습니다.

Microservices 아키텍처를 사용하는 응용 프로그램은 협소하게 집중화되고 독립적으로 배치 가능한 일련의 서비스로 구성되며 실패 할 것으로 예상됩니다.

장점 : 민첩성과 탄력성이 향상되었습니다.

민첩성은 개별 서비스를 개별적으로 업데이트하고 재배포 할 수 있기 때문에 가능합니다.

Microservices의 분산 된 특성을 감안할 때, 이들은 다양한 플랫폼과 인프라에 배치 될 수 있으며, 개발자는 사후 검토 대신에 처음부터 복원력에 대해 생각해야합니다.

Microservices 아키텍처와 컨테이너를 함께 사용하면 전반적으로 더 높은 품질을 유지하는 동시에 구축 및 유지 관리가 용이 한 애플리케이션을 만들 수 있습니다.

이것은 Docker를 완벽한 적합성으로 만듭니다.

Docker는 Microservices 철학에 대한 컨테이너 솔루션을 설계했으며 각 컨테이너가 단일 관심사를 처리 할 것을 권장합니다.

따라서 애플리케이션은 현재 100 대 또는 1000 대가 될 수 있습니다.

이제 마이크로 서비스 아키텍처는 상당히 새롭고 이에 따라 응용 프로그램이 제한적입니다.

엔터프라이즈 데이터 센터의 상당 부분은 일반적인 3 계층 응용 프로그램 (웹, 응용 프로그램 및 db)이 지배합니다.

이러한 응용 프로그램은 Java, Ruby, Python 등으로 작성되며 단일 논리 응용 프로그램 서버 및 데이터베이스 개념을 가지고 있으며 대부분의 구성 요소가 메모리 내 함수 호출을 통해 통신하기 때문에 큰 CPU 및 메모리 할당이 필요합니다.

이러한 응용 프로그램은 관리 측면에서 응용 프로그램 서비스를 중지하고 패치 및 업그레이드를 적용하고 구성을 변경 한 다음 서비스를 다시 시작해야합니다.

이 모든 것은 사용자가 앱을 완벽하게 제어 할 수 있으며 기본 인프라에 대한 액세스 권한을 잃지 않고 상태를 변경할 수 있다고 가정합니다.

기존 또는 기존 엔터프라이즈 응용 프로그램의 성격을 알려면 LXC는 더 자연스럽게 보입니다.

시스템 관리자는 베어 메탈 서버 또는 VM에서 실행중인 기존 응용 프로그램을 LXC 컨테이너로 쉽게 '들어 올리고 이동'할 수 있습니다.

Docker가 기존 응용 프로그램에 대한 기술을 홍보하는 동안 상당한 노력이 필요하며 작동하도록해야합니다.

물론 대부분의 공급 업체가 소프트웨어를 Docker 이미지로 제공하기 때문에 이러한 경험은 더 간단해질 것입니다. 그러면 새로운 응용 프로그램을 빠르게 시작할 수 있습니다.

요컨대, 마이크로 애플리케이션 기반이든 3 계층 아키텍처 기반이든 관계없이 새로운 애플리케이션을 작성하는 경우 Docker는 최고의 플랫폼입니다.

그러나 운영 프로세스를 크게 변경하지 않고 컨테이너의 모든 이점을 얻으려면 LXC가 더 적합 할 것입니다.

Vendor Support & Ecosystem

Docker와 LXC는 모두 오픈 소스 프로젝트입니다.

Docker는 Docker Inc의 지원을받으며, LXC & LXD (컨테이너 하이퍼 바이저)는 Ubuntu OS의 회사 인 Canonical에 의해 지원됩니다.

Docker Inc는 Docker DataCenter라고하는 Docker 솔루션의 엔터프라이즈 배포를 제공하지만 공식 배포판을 제공하는 많은 다른 공급 업체도 있습니다.

반대로 LXC만의 공급 업체는 거의 없습니다. 대부분의 경우 LXC를 추가 컨테이너 기술로 지원합니다.

VM과 달리 컨테이너 공간은 다소 젊습니다. 솔루션은 아직 미숙하고 기능 격차가 많습니다.

이로 인해 컨테이너 주위에 다양한 솔루션을 제공하는 회사가 폭발적으로 증가했으며 결과적으로 엄청난 양의 생태계가 생겨났습니다.

아래 이미지는 Docker 생태계를 지원하는 파트너 중 일부입니다.

LXC는 풍부하고 헌신적 인 생태계를 갖추고 있지는 않지만 주로 VM과 유사한 경험을 제공합니다.

VM에서 작동하는 대부분의 도구는 자연스럽게 LXC 컨테이너에서도 작동합니다.

마지막으로, 플랫폼 지원 측면에서 Docker는 이제 Windows에도 포팅되었습니다.

즉, AWS, Azure, Google 및 IBM의 모든 주요 클라우드 공급 업체가 이제 기본 Docker 지원을 제공합니다. 이것은 컨테이너에 대해 거대하며 성장 추세만을 보여줍니다.

Summary

이 성격의 블로그와 마찬가지로 매우 유사한 두 가지 기술을 비교하면 가장 좋은 답변은 실제로는 다릅니다.

Docker와 LXC는 모두 막대한 잠재력을 지니고 있으며 성능, 통합, 배포 속도면에서 동일한 이점을 제공합니다.

그러나 Docker가 개발자 커뮤니티에 집중하면서 인기가 급상승하고 계속 증가하고 있습니다.

반면에 LXC는 채택이 제한적이지만 기존의 기존 응용 프로그램을 대체 할 수있는 대안으로 여겨집니다.

또한 VM 관리자는 Docker보다 LXC로 쉽게 전환 할 수 있지만 이러한 컨테이너 기술을 확실히 지원해야합니다.