Docker와 전체 VM의 차이점을 이해하기 위해 Docker 설명서 를 계속 읽으 십시오 . 무겁지 않고 완전한 파일 시스템, 격리 된 네트워킹 환경 등을 제공하는 방법은 무엇입니까?
일관된 프로덕션 환경에 단순히 배포하는 것보다 소프트웨어를 Docker 이미지에 배포하는 것이 왜 쉬운가?
답변
Docker는 원래 LinuX Containers (LXC)를 사용했지만 나중에 호스트와 동일한 운영 체제에서 실행되는 runC (이전의 libcontainer ) 로 전환했습니다 . 이를 통해 많은 호스트 운영 체제 리소스를 공유 할 수 있습니다. 또한 계층 파일 시스템 ( AuFS )을 사용하고 네트워킹을 관리합니다.
AuFS는 계층 파일 시스템이므로 함께 병합 된 읽기 전용 부분과 쓰기 부분을 가질 수 있습니다. 하나는 운영 체제의 공통 부분을 읽기 전용 (모든 컨테이너간에 공유)으로 설정 한 다음 각 컨테이너에 쓰기를위한 고유 한 마운트를 제공 할 수 있습니다.
따라서 1GB 컨테이너 이미지가 있다고 가정하겠습니다. 전체 VM을 사용하려면 원하는 1GB x 개수의 VM이 있어야합니다. Docker와 AuFS를 사용하면 모든 컨테이너간에 1GB의 대량을 공유 할 수 있으며 컨테이너가 1000 개인 경우 컨테이너 OS에 대해 1GB 이상의 공간이 남아있을 수 있습니다 (모두 동일한 OS 이미지를 실행한다고 가정) .
완전 가상화 시스템은 자체 리소스 세트를 할당받으며 최소한의 공유를 수행합니다. 더 많은 격리를 얻지 만 훨씬 더 무겁습니다 (더 많은 리소스가 필요함). Docker를 사용하면 격리가 줄어들지 만 컨테이너는 가벼워집니다 (더 적은 리소스 필요). 따라서 호스트에서 수천 개의 컨테이너를 쉽게 실행할 수 있으며 깜박 거리지 않습니다. Xen을 사용하여 시도해보십시오. 정말로 큰 호스트가 없다면 가능하지 않다고 생각합니다.
전체 가상화 시스템은 일반적으로 시작하는 데 몇 분이 걸리지 만 Docker / LXC / runC 컨테이너는 몇 초가 걸리고 종종 1 초도 채 걸리지 않습니다.
각 가상화 시스템 유형마다 장단점이 있습니다. 보장 된 리소스로 완벽한 격리를 원한다면 완전한 VM이 필요합니다. 프로세스를 서로 분리하고 합리적인 크기의 호스트에서 수많은 프로세스를 실행하려면 Docker / LXC / runC가 좋은 방법입니다.
자세한 내용 은 LXC 작동 방식을 잘 설명하는 이 블로그 게시물 을 확인하십시오 .
일관된 프로덕션 환경에 단순히 배포하는 것보다 소프트웨어를 도커 이미지 (적절한 경우)에 쉽게 배포하는 이유는 무엇입니까?
일관된 프로덕션 환경을 배포하는 것이 말하는 것보다 쉽습니다. Chef 및 Puppet 과 같은 도구를 사용하더라도 항상 호스트와 환경간에 변경되는 OS 업데이트 및 기타 사항이 있습니다.
Docker를 사용하면 OS를 공유 이미지로 스냅 샷 할 수 있으며 다른 Docker 호스트에 쉽게 배포 할 수 있습니다. 로컬로 dev, qa, prod 등 : 모두 동일한 이미지. 물론 다른 도구를 사용하여이 작업을 수행 할 수 있지만, 쉽고 빠르지는 않습니다.
이것은 테스트에 좋습니다. 데이터베이스에 연결해야하는 수천 개의 테스트가 있고 각 테스트에는 데이터베이스의 원시 복사본이 필요하며 데이터를 변경한다고 가정 해 봅시다. 이에 대한 고전적인 접근 방식은 모든 테스트 후에 사용자 지정 코드 또는 Flyway 와 같은 도구를 사용하여 데이터베이스를 재설정하는 것입니다. 시간이 많이 걸리고 테스트를 순차적으로 실행해야합니다. 그러나 Docker를 사용하면 데이터베이스 이미지를 생성하고 테스트 당 하나의 인스턴스를 실행 한 다음 모든 테스트가 데이터베이스의 동일한 스냅 샷에 대해 실행될 것이므로 모든 테스트를 병렬로 실행할 수 있습니다. 테스트가 병렬로 실행되고 Docker 컨테이너에서 실행되므로 동일한 상자에서 모두 동시에 실행할 수 있으며 훨씬 빠르게 완료됩니다. 완전한 VM을 사용하여 시도하십시오.
댓글에서 …
흥미 롭습니다! 나는 여전히 “OS 스냅 샷 [ting]”이라는 개념에 혼란스러워하고 있다고 생각한다. OS의 이미지를 만들지 않고도 어떻게 할 수 있습니까?
글쎄, 내가 설명 할 수 있는지 보자. 기본 이미지로 시작한 다음 변경하고 docker를 사용하여 해당 변경 사항을 커밋하면 이미지가 생성됩니다. 이 이미지에는 밑면과의 차이점 만 포함되어 있습니다. 이미지를 실행하려면 기본도 필요하며 계층 파일 시스템을 사용하여 기본 위에 이미지를 계층화합니다. 위에서 언급 한 것처럼 Docker는 AuFS를 사용합니다. AuFS는 서로 다른 레이어를 병합하여 원하는 것을 얻습니다. 당신은 그것을 실행해야합니다. 점점 더 많은 이미지 (레이어)를 계속 추가 할 수 있으며 diff 만 계속 저장합니다. Docker는 일반적으로 레지스트리 에서 기성품 이미지 위에 빌드하므로 전체 OS를 “스냅 샷”할 필요가 거의 없습니다.
답변
답변
가상화 및 컨테이너가 낮은 수준에서 작동하는 방식을 이해하면 도움이 될 수 있습니다. 그것은 많은 것들을 정리할 것입니다.
참고 : 아래 설명에서 약간 단순화하고 있습니다. 자세한 내용은 참조를 참조하십시오.
가상화가 낮은 수준에서 어떻게 작동합니까?
이 경우 VM 관리자는 CPU 링 0 (또는 최신 CPU의 “루트 모드”)을 인계 받아 게스트 OS가 수행 한 모든 권한있는 호출을 가로 채서 게스트 OS에 자체 하드웨어가 있다는 환상을 만듭니다. 재미있는 사실 : 1998 년 이전에는 이런 종류의 가로 채기를 수행 할 방법이 없었기 때문에 x86 아키텍처에서는이를 달성하는 것이 불가능하다고 생각되었습니다. VMWare의 사람들 은 처음이었습니다 이를 위해 게스트 OS의 특권 호출을 위해 실행 가능 바이트를 메모리에 다시 쓰는 아이디어를 가진 사람이 이었습니다.
결과적으로 가상화를 통해 동일한 하드웨어에서 완전히 다른 두 개의 OS를 실행할 수 있습니다. 각 게스트 OS는 부트 스트래핑, 커널로드 등의 모든 프로세스를 거칩니다. 예를 들어 게스트 OS는 호스트 OS 또는 다른 게스트에 대한 전체 액세스 권한을 얻지 못하고 엉망이 될 수 있습니다.
컨테이너가 낮은 수준에서 어떻게 작동합니까?
2006 년경 Google 직원 일부를 포함하여 사람들은 네임 스페이스 라는 새로운 커널 레벨 기능을 구현했습니다 (그러나 그 아이디어 는 FreeBSD에 오래 전부터 존재했습니다)). OS의 기능 중 하나는 네트워크 및 디스크와 같은 글로벌 리소스를 프로세스와 공유 할 수 있도록하는 것입니다. 이러한 전역 리소스가 네임 스페이스로 래핑되어 동일한 네임 스페이스에서 실행되는 프로세스에만 표시되도록하려면 어떻게해야합니까? 디스크 덩어리를 가져 와서 네임 스페이스 X에 넣은 다음 네임 스페이스 Y에서 실행중인 프로세스는 볼 수 없거나 액세스 할 수 없습니다. 마찬가지로 네임 스페이스 X의 프로세스는 네임 스페이스 Y에 할당 된 메모리의 아무것도 액세스 할 수 없습니다. 물론 X의 프로세스는 네임 스페이스 Y의 프로세스를 보거나 대화 할 수 없습니다. 이는 전역 리소스에 대한 일종의 가상화 및 격리를 제공합니다. 도커 작동 방식은 다음과 같습니다. 각 컨테이너는 고유 한 네임 스페이스에서 실행되지만 정확히 동일한다른 모든 컨테이너로 커널. 커널은 프로세스에 할당 된 네임 스페이스를 알고 있기 때문에 API 호출 중에 프로세스가 자체 네임 스페이스의 리소스에만 액세스 할 수 있도록합니다.
컨테이너와 VM의 한계는 이제 분명합니다. VM과 같은 컨테이너에서 완전히 다른 OS를 실행할 수는 없습니다. 그러나 동일한 커널을 공유하기 때문에 Linux의 다른 배포판을 실행할 수 있습니다 . 격리 수준은 VM만큼 강력하지 않습니다. 실제로 “게스트”컨테이너가 초기 구현에서 호스트를 인수 할 수있는 방법이있었습니다. 또한 새 컨테이너를로드 할 때 VM 에서처럼 새 OS의 전체 사본이 시작되지 않음을 알 수 있습니다. 모든 컨테이너 는 동일한 커널을 공유. 이것이 용기가 가벼운 이유입니다. 또한 VM과는 달리 새로운 OS 사본을 실행하지 않기 때문에 컨테이너에 상당한 양의 메모리를 사전 할당 할 필요가 없습니다. 이를 통해 하나의 OS에서 수천 개의 컨테이너를 샌드 박스 처리하는 동안 자체 VM에서 별도의 OS 사본을 실행하는 경우 불가능할 수 있습니다.
답변
나는 Ken Cochrane의 답변을 좋아합니다.
그러나 여기에 자세히 다루지 않은 추가 관점을 추가하고 싶습니다. 제 생각에는 Docker는 전체 프로세스에서도 다릅니다. VM과는 달리 Docker는 하드웨어의 최적의 자원 공유에 관한 것만이 아니며, 응용 프로그램 패키징을위한 “시스템”을 제공합니다 (마이크로 서비스 세트로는 바람직하지만 필수는 아님).
나에게 그것은 rpm, Debian 패키지, Maven , npm + Git 과 같은 개발자 중심 도구와 Puppet , VMware, Xen 과 같은 ops 도구 사이의 격차에 맞습니다 .
일관된 프로덕션 환경에 단순히 배포하는 것보다 소프트웨어를 도커 이미지 (적절한 경우)에 쉽게 배포하는 이유는 무엇입니까?
귀하의 질문은 일관된 프로덕션 환경을 가정합니다. 그러나 어떻게 일관성을 유지 하는가?
파이프 라인의 일부 단계 (> 10)의 서버 및 애플리케이션을 고려하십시오.
이를 동기화하기 위해 꼭두각시와 같은 것을 사용하기 시작합니다. Chef 또는 자체 프로비저닝 스크립트, 게시되지 않은 규칙 및 / 또는 많은 문서와 . 이론상 서버는 무한정 실행될 수 있으며 완전히 일관성 있고 최신 상태를 유지할 수 있습니다. 실습에서는 서버 구성을 완전히 관리하지 못하므로 구성 드리프트에 대한 범위가 넓고 실행중인 서버에 대한 예기치 않은 변경이 있습니다.
이것을 피하기 위해 알려진 패턴이 있습니다. 불변 서버있습니다. 그러나 불변의 서버 패턴은 사랑받지 못했습니다. 대부분 Docker 이전에 사용 된 VM의 한계 때문입니다. 응용 프로그램에서 일부 필드를 변경하기 위해 몇 기가 바이트의 큰 이미지를 다루고 큰 이미지를 옮기는 것은 매우 힘들었습니다. 이해할 수 있는…
Docker 에코 시스템을 사용하면 “소규모 변경 사항”(aus 및 Registry 덕분)을 기가 바이트 단위로 이동할 필요가 없으며 런타임시 응용 프로그램을 Docker 컨테이너에 패키징하여 성능을 잃을 염려가 없습니다. 해당 이미지의 버전에 대해 걱정할 필요가 없습니다.
그리고 마지막으로 Linux 랩톱에서도 복잡한 프로덕션 환경을 재현 할 수도 있습니다 (귀하의 경우 작동하지 않으면 전화하지 마십시오.)
물론 VM에서 Docker 컨테이너를 시작할 수 있습니다 (좋은 아이디어). VM 수준에서 서버 프로비저닝을 줄입니다. 위의 모든 내용은 Docker에서 관리 할 수 있습니다.
PS While Docker는 LXC 대신 자체 구현 “libcontainer”를 사용합니다. 그러나 LXC는 여전히 사용 가능합니다.
답변
Docker는 가상화 방법이 아닙니다. 실제로 컨테이너 기반 가상화 또는 운영 체제 수준 가상화를 구현하는 다른 도구를 사용합니다. 이를 위해 Docker는 처음에 LXC 드라이버를 사용하고 libcontainer로 이동했으며 이제는 runc로 이름이 변경되었습니다. Docker는 주로 응용 프로그램 컨테이너 내부의 응용 프로그램 배포 자동화에 중점을 둡니다. 응용 프로그램 컨테이너는 단일 서비스를 패키징하고 실행하도록 설계되었지만 시스템 컨테이너는 가상 시스템과 같은 여러 프로세스를 실행하도록 설계되었습니다. 따라서 Docker는 컨테이너화 된 시스템에서 컨테이너 관리 또는 응용 프로그램 배포 도구로 간주됩니다.
다른 가상화와 어떻게 다른지 알기 위해 가상화와 그 유형을 살펴 보겠습니다. 그렇다면 차이점이 무엇인지 이해하는 것이 더 쉬울 것입니다.
가상화
고안된 형태로, 여러 애플리케이션을 동시에 실행할 수 있도록 메인 프레임을 논리적으로 나누는 방법으로 간주되었습니다. 그러나 회사와 오픈 소스 커뮤니티가 권한있는 명령을 다른 방식으로 처리하는 방법을 제공하고 단일 x86 기반 시스템에서 여러 운영 체제를 동시에 실행할 수있게되면 시나리오가 크게 바뀌 었습니다.
하이퍼 바이저
하이퍼 바이저는 게스트 가상 머신이 작동하는 가상 환경 작성을 처리합니다. 게스트 시스템을 감독하고 필요에 따라 리소스가 게스트에 할당되도록합니다. 하이퍼 바이저는 실제 머신과 가상 머신 사이에 있으며 가상 머신에 가상화 서비스를 제공합니다. 이를 실현하기 위해 가상 머신에서 게스트 운영 체제 조작을 인터셉트하고 호스트 머신 운영 체제에서 조작을 에뮬레이트합니다.
주로 클라우드에서 가상화 기술의 빠른 개발로 인해 Xen, VMware Player, KVM 등과 같은 하이퍼 바이저의 도움으로 단일 물리적 서버에 여러 개의 가상 서버를 만들 수있어 가상화 사용이 더욱 확대되었습니다. Intel VT 및 AMD-V와 같은 상용 프로세서에 하드웨어 지원 통합
가상화 유형
가상화 방법은 게스트 운영 체제에서 하드웨어를 모방하고 게스트 운영 환경을 에뮬레이션하는 방법에 따라 분류 할 수 있습니다. 기본적으로 가상화에는 세 가지 유형이 있습니다.
- 에뮬레이션
- 반 가상화
- 컨테이너 기반 가상화
에뮬레이션
전체 가상화라고도하는 에뮬레이션은 소프트웨어에서 가상 머신 OS 커널을 완전히 실행합니다. 이 유형에 사용 된 하이퍼 바이저를 유형 2 하이퍼 바이저라고합니다. 게스트 운영 체제 커널 코드를 소프트웨어 명령으로 변환하는 호스트 운영 체제의 맨 위에 설치됩니다. 번역은 전적으로 소프트웨어로 수행되며 하드웨어가 필요하지 않습니다. 에뮬레이션을 통해 에뮬레이션되는 환경을 지원하는 수정되지 않은 운영 체제를 실행할 수 있습니다. 이 유형의 가상화의 단점은 다른 유형의 가상화에 비해 성능이 저하되는 추가 시스템 리소스 오버 헤드입니다.
이 범주의 예로는 VMware Player, VirtualBox, QEMU, Bochs, Parallels 등이 있습니다.
반 가상화
유형 1 하이퍼 바이저라고도하는 반 가상화는 하드웨어 또는 “베어 메탈 (bare-metal)”에서 직접 실행되며 가상화 서비스를 실행하는 가상 머신에 직접 가상화 서비스를 제공합니다. 운영 체제, 가상화 된 하드웨어 및 실제 하드웨어가 협업하여 최적의 성능을 달성하도록 도와줍니다. 이러한 하이퍼 바이저는 일반적으로 설치 공간이 다소 작으며 자체적으로 광범위한 리소스가 필요하지 않습니다.
이 범주의 예에는 Xen, KVM 등이 포함됩니다.
컨테이너 기반 가상화
운영 체제 수준 가상화라고도하는 컨테이너 기반 가상화는 단일 운영 체제 커널 내에서 여러 격리 된 실행을 가능하게합니다. 최상의 성능과 밀도를 가지며 동적 리소스 관리 기능이 있습니다. 이 유형의 가상화에서 제공하는 격리 된 가상 실행 환경을 컨테이너라고하며 추적 된 프로세스 그룹으로 볼 수 있습니다.
컨테이너 개념은 Linux 커널 버전 2.6.24에 추가 된 네임 스페이스 기능으로 가능합니다. 컨테이너는 모든 프로세스에 ID를 추가하고 모든 시스템 호출에 새로운 액세스 제어 검사를 추가합니다. 이전의 전역 네임 스페이스의 개별 인스턴스를 만들 수 있는 clone () 시스템 호출 로 액세스 합니다.
네임 스페이스는 다양한 방법으로 사용될 수 있지만 가장 일반적인 방법은 컨테이너 외부의 객체에 대한 가시성이나 액세스 권한이없는 격리 된 컨테이너를 만드는 것입니다. 컨테이너 내에서 실행되는 프로세스는 다른 종류의 객체와 마찬가지로 다른 네임 스페이스에있는 프로세스와 기본 커널을 공유하지만 일반 Linux 시스템에서 실행중인 것으로 보입니다. 예를 들어, 네임 스페이스를 사용할 때 컨테이너 내부의 루트 사용자는 컨테이너 외부의 루트로 취급되지 않으므로 추가 보안이 추가됩니다.
컨테이너 기반 가상화를 가능하게하는 다음 주요 구성 요소 인 Linux 제어 그룹 (cgroup) 서브 시스템은 프로세스를 그룹화하고 총 자원 소비를 관리하는 데 사용됩니다. 일반적으로 컨테이너의 메모리 및 CPU 소비를 제한하는 데 사용됩니다. 컨테이너화 된 Linux 시스템에는 커널이 하나만 있고 커널은 컨테이너를 완전히 볼 수 있으므로 리소스 할당 및 스케줄링 수준은 한 가지뿐입니다.
LXC, LXD, systemd-nspawn, lmctfy, Warden, Linux-VServer, OpenVZ, Docker 등을 포함하여 Linux 컨테이너에 여러 관리 도구를 사용할 수 있습니다.
컨테이너 대 가상 머신
가상 머신과 달리 컨테이너는 운영 체제 커널을 부팅 할 필요가 없으므로 컨테이너를 1 초 이내에 만들 수 있습니다. 이 기능은 컨테이너 기반 가상화를 다른 가상화 방식보다 독특하고 바람직하게 만듭니다.
컨테이너 기반 가상화는 호스트 시스템에 오버 헤드를 거의 또는 전혀 추가하지 않기 때문에 컨테이너 기반 가상화는 거의 기본 성능을 제공합니다.
컨테이너 기반 가상화의 경우 다른 가상화와 달리 추가 소프트웨어가 필요하지 않습니다.
호스트 시스템의 모든 컨테이너는 호스트 시스템의 스케줄러를 공유하므로 추가 자원이 필요하지 않습니다.
컨테이너 상태 (Docker 또는 LXC 이미지)는 가상 머신 이미지에 비해 크기가 작으므로 컨테이너 이미지를 쉽게 배포 할 수 있습니다.
컨테이너의 리소스 관리는 cgroup을 통해 수행됩니다. Cgroup은 컨테이너가 할당 된 것보다 더 많은 리소스를 소비하도록 허용하지 않습니다. 그러나 현재 호스트 시스템의 모든 리소스는 가상 시스템에서 볼 수 있지만 사용할 수는 없습니다. 이는 컨테이너와 호스트 시스템을 동시에 실행 top하거나 실행하여 실현할 수 있습니다 htop. 모든 환경에서의 출력은 비슷하게 보입니다.
최신 정보:
Docker는 Linux 이외의 시스템에서 컨테이너를 어떻게 실행합니까?
Linux 커널에서 사용 가능한 기능으로 인해 컨테이너가 가능한 경우 Linux 이외의 시스템에서 컨테이너를 실행하는 방법에 대한 분명한 질문이 있습니다. Mac 및 Windows 용 Docker는 모두 Linux VM을 사용하여 컨테이너를 실행합니다. Docker Toolbox는 Virtual Box VM에서 컨테이너를 실행하는 데 사용됩니다. 그러나 최신 Docker는 Windows에서는 Hyper-V를 사용하고 Mac에서는 Hypervisor.framework를 사용합니다.
이제 Docker for Mac이 어떻게 컨테이너를 실행하는지 설명하겠습니다.
Mac 용 Docker는 https://github.com/moby/hyperkit 을 사용 하여 하이퍼 바이저 기능을 에뮬레이트하고 Hyperkit은 코어에서 hypervisor.framework를 사용합니다. Hypervisor.framework는 Mac의 기본 하이퍼 바이저 솔루션입니다. Hyperkit은 또한 VPNKit과 DataKit을 사용하여 각각 네임 스페이스 네트워크와 파일 시스템을 만듭니다.
Docker가 Mac에서 실행하는 Linux VM은 읽기 전용입니다. 그러나 다음을 실행하여 bash를 만들 수 있습니다.
screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty.
이제이 VM의 커널 버전을 확인할 수도 있습니다.
# uname -a.
Linux linuxkit-025000000001 4.9.93-linuxkit-aufs #1 SMP Wed Jun 6 16:86_64 Linux
모든 컨테이너는이 VM 내에서 실행됩니다.
hypervisor.framework에는 몇 가지 제한 사항이 있습니다. Docker는 docker0Mac에서 네트워크 인터페이스를 노출시키지 않습니다 . 따라서 호스트에서 컨테이너에 액세스 할 수 없습니다. 현재로서는 docker0VM 내부에서만 사용할 수 있습니다.
Hyper-v는 Windows의 기본 하이퍼 바이저입니다. 또한 Windows 10의 기능을 활용하여 Linux 시스템을 기본적으로 실행하려고합니다.
답변
이 게시물을 통해 VM과 LXC의 차이점을 몇 가지 살펴 보겠습니다. 먼저 정의 해 봅시다.
VM :
가상 시스템은 물리적 컴퓨팅 환경을 에뮬레이트하지만 CPU, 메모리, 하드 디스크, 네트워크 및 기타 하드웨어 리소스에 대한 요청은 가상화 계층에서 관리하여 이러한 요청을 기본 물리적 하드웨어로 변환합니다.
이 컨텍스트에서 VM은 게스트라고하며 VM은 실행되는 환경을 호스트라고합니다.
LXC :
Linux Containers (LXC)는 하나의 제어 호스트 (LXC 호스트)에서 여러 개의 격리 된 Linux 컨테이너를 실행할 수있는 운영 체제 수준 기능입니다. Linux 컨테이너는 하이퍼 바이저 viz가 필요하지 않으므로 VM에 대한 간단한 대안으로 사용됩니다. Virtualbox, KVM, Xen 등
Alan (행 아웃 시리즈의 Zach Galifianakis-)에 의해 마약을 받고 작년에 라스베가스에 가본 적이 없다면, Linux 컨테이너 기술에 대한 엄청난 관심이 집중 될 것입니다. 지난 몇 달 동안 전 세계에 붐을 일으킨 프로젝트는 다음과 같습니다. Docker는 클라우드 컴퓨팅 환경이 가상 머신 (VM)을 버리고 더 낮은 오버 헤드와 잠재적으로 더 나은 성능으로 인해 컨테이너로 대체해야한다는 반향을 불러 일으 킵니다.
그러나 가장 큰 문제는 실현 가능합니까?
ㅏ. LXC는 Linux 인스턴스에 적용됩니다. Linux의 풍미가 다를 수 있습니다 (예 : CentOS 호스트의 Ubuntu 컨테이너이지만 여전히 Linux 임). VM을 살펴보면 Windows 기반 컨테이너의 범위가 넓어지고 하이퍼 바이저는 Linux 또는 Windows 운영 체제로 제한되지 않습니다.
비. LXC는 VM에 비해 오버 헤드가 낮고 성능이 더 좋습니다. 도구 즉. LXC 기술을 기반으로 구축 된 Docker는 개발자에게 응용 프로그램을 실행할 수있는 플랫폼을 제공했으며 동시에 운영 직원에게 프로덕션 서버 또는 데이터 센터에 동일한 컨테이너를 배포 할 수있는 도구를 제공했습니다. 개발자가 응용 프로그램을 실행하고, 응용 프로그램을 부팅 및 테스트하는 개발자와 해당 응용 프로그램을 완벽하게 배포하는 운영 담당자 사이에 경험을 쌓으려고 노력합니다. 이는 모든 마찰이 존재하고 DevOps의 목적이 이러한 사일로를 분해하기 때문입니다.
따라서 가장 좋은 방법은 클라우드 인프라 공급자가 VM과 LXC의 적절한 사용을 권장해야합니다. VM과 LXC는 각각 특정 워크로드와 시나리오를 처리하는 데 적합하기 때문입니다.
VM을 포기하는 것은 현재로서는 실용적이지 않습니다. 따라서 VM과 LXC는 각자 고유 한 존재와 중요성을 가지고 있습니다.
답변
여기에있는 대부분의 답변은 가상 머신에 대한 것입니다. Docker를 사용하는 지난 몇 년 동안 가장 도움이 된이 질문에 대한 한 줄짜리 응답을 제공 할 것입니다. 이것입니다 :
Docker는 가상 머신이 아닌 프로세스를 실행하는 멋진 방법입니다.
이제 그 의미에 대해 좀 더 설명하겠습니다. 가상 머신은 자신의 짐승입니다. Docker가 무엇인지 설명하고 싶습니다. 당신이 더 많은 가상 머신이 무엇인지 설명하는 것보다 이해하는 데 도움이됩니다. 특히 여기에 누군가가 “가상 머신”이라고 할 때의 의미를 정확하게 알려주는 많은 훌륭한 답변이 있기 때문입니다. 그래서…
Docker 컨테이너는 프로세스 (및 그 자식) 일 뿐이며 나머지 프로세스에서 호스트 시스템 커널 내부의 cgroup을 사용하여 구획화 됩니다. 실제로 ps aux호스트에서 실행하여 Docker 컨테이너 프로세스를 볼 수 있습니다 . 예를 들어, apache2“컨테이너에서”시작 apache2은 호스트에서 특수 프로세스로 시작 됩니다. 컴퓨터의 다른 프로세스에서 구획화되었습니다. 컨테이너는 컨테이너화 된 프로세스 수명 밖에서는 존재하지 않습니다. 프로세스가 죽으면 컨테이너가 죽습니다. Docker가 pid 1컨테이너 내부를 응용 프로그램으로 대체하기 때문 pid 1입니다 (일반적으로 init 시스템입니다). 마지막 요점 pid 1은 매우 중요합니다.
각 컨테이너 프로세스에서 사용하는 파일 시스템에 이르기까지 Docker는 UnionFS 지원 이미지를 사용합니다. 이 이미지는 다운로드 할 때 다운로드하는 이미지 docker pull ubuntu입니다. 각 “이미지”는 일련의 레이어 및 관련 메타 데이터입니다. 레이어링의 개념은 여기서 매우 중요합니다. 각 레이어는 그 아래 레이어에서 변경된 것입니다. 예를 들어 Docker 컨테이너를 빌드하는 동안 Dockerfile에서 파일을 삭제하면 실제로는 마지막 레이어 위에 “이 파일이 삭제되었습니다”라는 레이어가 생성됩니다. 또한 파일 시스템에서 큰 파일을 삭제할 수는 있지만 이미지는 여전히 같은 양의 디스크 공간을 차지합니다. 파일은 여전히 현재 레이어 아래에 있습니다. 레이어 자체는 단지 파일의 tarball입니다. 당신은 이것을 테스트 할 수 있습니다docker save --output /tmp/ubuntu.tar ubuntu다음 cd /tmp && tar xvf ubuntu.tar. 그런 다음 둘러 볼 수 있습니다. 긴 해시처럼 보이는 모든 디렉토리는 실제로 개별 레이어입니다. 각 파일에는 파일 ( layer.tar)과 메타 데이터 (json)를 해당 특정 레이어에 대한 정보와 함께 제공합니다. 이러한 레이어는 파일 시스템의 변경 사항을 설명하며 원래 상태의 “맨 위에”레이어로 저장됩니다. “현재”데이터를 읽을 때 파일 시스템은 최상위 계층의 변경 사항 만보고있는 것처럼 데이터를 읽습니다. 파일 시스템이 최상위 계층 만보고 있기 때문에 파일이 여전히 “이전”계층에 존재하더라도 파일이 삭제 된 것처럼 보입니다. 이렇게하면 각 컨테이너에서 최상위 계층의 파일 시스템에 약간의 변경이 있었더라도 완전히 다른 컨테이너가 파일 시스템 계층을 공유 할 수 있습니다. 컨테이너가 기본 이미지 레이어를 공유 할 때 많은 디스크 공간을 절약 할 수 있습니다. 하나,
Docker의 네트워킹은 이더넷 브리지 ( docker0 호스트에서 )와 호스트의 모든 컨테이너에 대한 가상 인터페이스를 . docker0컨테이너가 서로 “통신”할 수 있도록 가상 서브넷을 만듭니다 . 여기에는 컨테이너에 대한 사용자 지정 서브넷 생성 및 컨테이너가 직접 액세스 할 수 있도록 호스트의 네트워킹 스택을 “공유”하는 기능을 포함하여 네트워킹에 대한 많은 옵션이 있습니다.
Docker는 매우 빠르게 움직이고 있습니다. 그 문서 는 내가 본 최고의 문서 중 일부입니다. 일반적으로 잘 작성되고 간결하며 정확합니다. 자세한 내용은 사용 가능한 설명서를 확인하고 Stack Overflow를 포함하여 온라인에서 읽은 내용에 대한 설명서를 신뢰하는 것이 좋습니다. 구체적인 질문이 있으시면 #dockerFreenode IRC에 가입 하여 문의하는 것이 좋습니다 (Freenode의 웹 채팅 을 사용해도됩니다 ).
