Docker는 가상 컴퓨터와 어떻게 다른가요?
질문
Docker 문서를 다시 읽고 Docker와 Full VM의 차이점을 이해하려고 노력합니다.무겁지 않고 전체 파일 시스템, 고립 된 네트워킹 환경 등을 어떻게 제공 할 수 있습니까?
왜 일관된 프로덕션 환경에 전개하는 것보다 단순히 Docker 이미지에 소프트웨어를 배포하는 이유는 무엇입니까?
답변
Docker는 원래 Linux 컨테이너 (LXC)를 사용했지만 나중에 호스트와 동일한 운영 체제에서 실행되는 RUNC (이전에 LibContainer라고 함)로 전환되었습니다.이를 통해 많은 호스트 운영 체제 자원을 공유 할 수 있습니다.또한 계층화 된 파일 시스템 (AUFS)을 사용하고 네트워킹을 관리합니다.
AUFS는 계층화 된 파일 시스템이므로 함께 읽기 전용 파트와 병합 된 쓰기 부분을 가질 수 있습니다.하나는 운영 체제의 공통 부품을 읽기 전용으로 (그리고 모든 컨테이너들 사이에서 공유) 한 다음 각 컨테이너를 작성하기 위해 자체 마운트를 제공 할 수 있습니다.
그래서 1GB 컨테이너 이미지가 있는지 말해 봅시다.전체 VM을 사용하려면 1GB x의 VM을 1GB x 수있게해야합니다.Docker 및 AUFS를 사용하면 모든 컨테이너간에 1GB의 대량을 공유 할 수 있으며 1000 개의 컨테이너가있는 경우 컨테이너 OS에 대해 1GB 이상의 공간이 약간 넘습니다....에
완전한 가상화 된 시스템은 자체 자원을 할당하고 최소한의 공유를 수행합니다.당신은 더 많은 격리를 얻었지만 훨씬 더 무겁습니다 (더 많은 자원이 필요함).Docker를 사용하면 절연이 적지 만 컨테이너는 가볍습니다 (리소스가 적습니다).따라서 호스트에서 수천 개의 컨테이너를 쉽게 실행할 수 있으며 깜박이지 않습니다.Xen에서 그 일을 시도하고 정말로 큰 호스트가 없다면, 나는 그것이 가능하다고 생각하지 않는다.
완전 가상화 된 시스템은 일반적으로 시작하는 데 몇 분이 걸리지만 Docker / LXC / Runc 컨테이너는 몇 초 이상 걸리고 종종조차합니다.
가상화 된 시스템의 각 유형에 대한 장단점이 있습니다.보장 된 리소스로 완전한 격리를 원한다면 완전한 VM은가는 길입니다.서로의 프로세스를 격리하고 합리적으로 크기의 호스트에서 톤을 실행하고 싶다면 Docker / LXC / RUNC가가는 방법 인 것 같습니다.
자세한 내용은 LXC 작동 방식을 설명하는 좋은 작업을 수행하는 블로그 게시물 세트를 확인하십시오.
왜 일관된 프로덕션 환경에 전개하는 것보다 단순히 Docker 이미지에 소프트웨어를 배포하는 이유는 무엇입니까?
일관된 프로덕션 환경을 배포하는 것은 완료보다 쉽습니다.요리사와 꼭두각시와 같은 도구를 사용하는 경우에도 항상 OS 업데이트 및 호스트와 환경간에 변경되는 다른 것들이 있습니다.
Docker를 사용하면 OS를 공유 이미지로 스냅 샷하는 기능을 제공하며 다른 Docker 호스트에 쉽게 배포 할 수 있습니다.국지적으로, dev, qa, prod, etc.: 모든 동일한 이미지.확실히 다른 도구 로이 작업을 수행 할 수 있지만 거의 쉽게 또는 빠르지 않습니다.
이것은 테스트에 적합합니다.데이터베이스에 연결 해야하는 수천 가지 테스트가 있고 각 테스트는 데이터베이스의 깨끗한 복사본이 필요하며 데이터를 변경합니다.클래식 한 접근 방식은 사용자 정의 코드 또는 플라이 웨이와 같은 도구로 모든 테스트 후에 데이터베이스를 재설정하는 것입니다. 이는 매우 시간이 많이 걸릴 수 있으며 테스트가 직렬로 실행되어야 함을 의미합니다.그러나 Docker를 사용하면 데이터베이스의 이미지를 만들고 테스트 당 하나의 인스턴스를 실행할 수 있으며 모든 테스트를 병렬로 실행하여 데이터베이스의 동일한 스냅 샷과 동일하게 실행됩니다.테스트가 병렬로 실행되고 Docker 컨테이너에서는 동시에 같은 상자에서 모두 실행될 수 있으며 훨씬 더 빠르게 끝납니다.완전한 VM으로 그것을 해보십시오.
코멘트에서 ...
흥미로운!나는 "스냅 샷 [ting] OS"의 개념으로 여전히 혼란스러워한다고 생각합니다.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의 한 기능은 프로세스 간의 네트워크 및 디스크와 같은 전역 리소스를 공유 할 수있는 것입니다. 이러한 전역 리소스가 네임 스페이스에 래핑 된 경우 동일한 네임 스페이스에서 실행되는 프로세스에만 표시되도록합니다. Say, 디스크 덩어리를 가져 와서 네임 스페이스 X에 넣은 다음 네임 스페이스 Y에서 실행중인 프로세스를보고 액세스 할 수 없습니다. 마찬가지로 네임 스페이스 x의 프로세스는 네임 스페이스 Y에 할당 된 메모리에 액세스 할 수 없습니다. 물론 X의 프로세스는 네임 스페이스 Y에서 프로세스를 볼 수 없거나 대화 할 수 없습니다.이를 통해 글로벌 리소스에 대한 가상화 및 격리의 종류가 제공됩니다. 이것은 Docker가 작동하는 방식입니다. 각 컨테이너는 자체 네임 스페이스에서 실행되지만 다른 모든 컨테이너와 동일한 커널을 정확하게 사용합니다. 절연은 커널이 프로세스에 할당 된 네임 스페이스를 알고 API 호출 중에 프로세스가 자체 네임 스페이스의 리소스에만 액세스 할 수 있는지 확인하기 때문에 발생합니다.
Containers VS VM의 한계는 지금 분명해야합니다. VMS와 같은 컨테이너에서 완전히 다른 OS를 실행할 수 없습니다.그러나 동일한 커널을 공유하기 때문에 Linux의 다른 리눅스를 실행할 수 있습니다.격리 수준은 VM과만큼 강하지 않습니다.사실, "손님"컨테이너가 초기 구현에서 호스트를 인수하는 방법이있었습니다.또한 새 컨테이너를로드 할 때 VM에서처럼 모든 작업의 새 복사본이 시작되지 않음을 알 수 있습니다.모든 컨테이너는 동일한 커널을 공유합니다.이것이 용기가 가벼운 무게이기 때문입니다.또한 VM과 달리 OS의 새 복사본을 실행하지 않기 때문에 컨테이너에 중요한 메모리를 미리 할당 할 필요가 없습니다.이를 통해 하나의 OS에서 수천 개의 컨테이너를 실행하면 샌드 박스를 사용하여 자신의 VM에서 OS의 별도 사본을 실행 중일 수 없을 수 있습니다.
답변
좋은 답변.컨테이너 대 VS VM의 이미지 표현을 얻으려면 아래에서 볼 수 있습니다.
원천
답변
나는 Ken Cochrane의 대답을 좋아합니다.
그러나 나는 여기에 자세히 다루지 않고 추가적인 관점을 추가하고 싶습니다.내 의견 Docker에서 전체 과정에서도 다릅니다.VMS와는 달리 Docker는 하드웨어의 최적 리소스 공유에 대해서만 (에만 해당)되지 않습니다. 또한 패키징 응용 프로그램에 대한 "시스템"을 제공합니다 (필수는 아니지만 마이크로 서비스 집합으로 필수가 아닙니다).
나에게 RPM, 데비안 패키지, Maven, NPM + Git과 같은 개발자 지향 도구 간의 격차가 꼭두각시, vmware, xen, 당신이 이름을 지정하는 것과 같은 ops 도구와 같은 갭에 맞습니다 ...
왜 일관된 프로덕션 환경에 전개하는 것보다 단순히 Docker 이미지에 소프트웨어를 배포하는 이유는 무엇입니까?
귀하의 질문은 일관된 생산 환경을 가정합니다.그러나 일관성을 유지하는 방법은 무엇입니까? 파이프 라인의 단계 및 응용 프로그램의 일부 (> 10)를 고려하십시오.
이를 동기화하려면 꼭두각시, 요리사 또는 자신의 프로비저닝 스크립트, 게시되지 않은 규칙 및 / 또는 많은 문서와 같은 것을 사용하기 시작합니다.이 서버에서는 무기한으로 실행될 수 있으며 완전히 일관성 있고 최신 상태로 유지됩니다.실무 실패는 서버 구성을 완전히 관리하지 않으므로 구성 드리프트 및 실행중인 서버의 예기치 않은 변경 사항이 있습니다.
그래서이를 피할 수있는 알려진 패턴이 있습니다.그러나 불변 서버 패턴은 사랑받지 못했습니다.주로 Docker 이전에 사용 된 VM의 한계 때문입니다.여러 기가 바이트 큰 이미지를 다루는 큰 이미지를 다루고 응용 프로그램의 일부 필드를 변경하기 위해서는 그 큰 이미지를 이동시키는 것만으로 매우 매우 힘들었습니다.이해할 수 있는...
Docker Ecosystem을 사용하면 "작은 변경"(AuFS 및 레지스트리 감사의 감사의)에서 기가 바이트를 이동할 필요가 없으며 런타임시 Docker 컨테이너에 응용 프로그램을 패키징하여 성능을 잃을 필요가 없습니다.그 이미지 버전에 대해 걱정할 필요가 없습니다.
그리고 마지막으로 Linux 노트북에서도 복잡한 생산 환경을 재현 할 수 있습니다 (귀하의 경우에 작동하지 않는 경우 저에게 전화하지 마십시오.))
물론 VMS에서 Docker 컨테이너를 시작할 수 있습니다 (좋은 생각입니다).VM 레벨에서 서버 프로비저닝을 줄입니다.위의 모든 것은 Docker가 관리 할 수 있습니다.
추신한편 Docker는 LXC 대신 "LibContainer"자체 구현을 사용합니다.그러나 LXC는 여전히 사용 가능합니다.
답변
Docker는 가상화 방법론이 아닙니다.컨테이너 기반 가상화 또는 운영 체제 수준 가상화를 실제로 구현하는 다른 도구에 의존합니다.이를 위해 Docker는 초기에 LXC 드라이버를 사용하여 Runc로 이름이 바뀐 LibContainer로 이동했습니다.Docker는 주로 응용 프로그램 컨테이너 내에서 응용 프로그램 배포를 자동화하는 데 주로 초점을 맞 춥니 다.응용 프로그램 컨테이너는 단일 서비스를 패키지화하고 실행하도록 설계되었지만 시스템 컨테이너는 가상 컴퓨터와 같은 여러 프로세스를 실행하도록 설계되었습니다.따라서 Docker는 컨테이너 관리 시스템의 컨테이너 관리 또는 응용 프로그램 배포 도구로 간주됩니다.
다른 가상화와 다른 방법을 알고 싶으면 가상화와 유형을 살펴 보겠습니다.그런 다음 그 차이점이 무엇인지 이해하는 것이 더 쉬울 것입니다.
가상화
그것의 잉태 된 형태에서는 여러 응용 프로그램이 동시에 실행되도록 메인 프레임을 논리적으로 분할하는 방법으로 간주되었습니다.그러나 회사와 오픈 소스 커뮤니티가 한 방향으로 또는 다른 방식으로 권한있는 지침을 처리하는 방법을 제공 할 수 있었고 단일 X86 기반 시스템에서 여러 운영 체제를 동시에 실행할 수있는 경우 시나리오가 크게 바뀌 었습니다.
하이퍼 바이저
하이퍼 바이저는 게스트 가상 컴퓨터가 작동하는 가상 환경을 만드는 것을 처리합니다.그것은 게스트 시스템을 감독하고 필요에 따라 자원이 손님에게 할당되었는지 확인합니다.하이퍼 바이저는 물리적 인 기계와 가상 시스템 사이에 위치하고 가상화 서비스를 가상 컴퓨터에 제공합니다.그것을 실현하기 위해 가상 컴퓨터에서 게스트 운영 체제 작업을 가로 챌 수 있으며 호스트 시스템의 운영 체제에서 작업을 수행합니다.
클라우드에서 주로 가상화 기술의 급속한 개발은 Xen, VMware 플레이어, KVM 등과 같은 하이퍼 바이저의 도움을 받아 단일 실제 서버에서 여러 가상 서버를 만들 수있게하여 가상화를 더욱 첨부했습니다.Intel VT 및 AMD-V와 같은 상품 프로세서의 하드웨어 지원을 통합합니다.
가상화의 유형
가상화 방법은 게스트 운영 체제로의 하드웨어를 모방 한 방식을 기준으로 분류 할 수 있으며 게스트 운영 환경을 에뮬레이트합니다.주로 3 가지 유형의 가상화가 있습니다.
에뮬레이션 반전 컨테이너 기반 가상화
에뮬레이션
전체 가상화라고도하는 에뮬레이션은 가상 컴퓨터 OS 커널을 소프트웨어에서 완전히 실행합니다.이 유형에서 사용되는 하이퍼 바이저는 유형 2 하이퍼 바이저라고합니다.게스트 OS 커널 코드를 소프트웨어 지침으로 번역 할 책임이있는 호스트 운영 체제의 상단에 설치됩니다.번역은 완전히 소프트웨어로 수행되며 하드웨어 개입이 필요하지 않습니다.에뮬레이션을 통해 에뮬레이트되는 환경을 지원하는 비 수정되지 않은 운영 체제를 실행할 수 있습니다.이러한 유형의 가상화의 단점은 다른 유형의 가상화와 비교하여 성능이 저하되는 추가 시스템 자원 오버 헤드입니다.
이 범주의 예에는 VMware Player, VirtualBox, Qemu, Bochs, Parallels 등이 포함됩니다.
반전
유형 1 하이퍼 바이저라고도하는 ParavirTualization은 하드웨어 또는 "맨손 금속"으로 직접 실행되며 가상화 서비스를 실행중인 가상 시스템에 직접 제공합니다.운영 체제, 가상화 된 하드웨어 및 실제 하드웨어가 최적의 성능을 달성하기 위해 공동 작업하는 데 도움이됩니다.이러한 하이퍼 바이저는 일반적으로 다소 작은 풋 프린트가 있으며 스스로는 광범위한 자원이 필요하지 않습니다.
이 범주의 예제에는 Xen, KVM 등이 포함됩니다.
컨테이너 기반 가상화
운영 체제 수준 가상화로 알려진 컨테이너 기반 가상화는 단일 운영 체제 커널 내에서 여러 격리 된 실행을 가능하게합니다.그것은 최상의 성능과 밀도를 가지고 있으며 동적 자원 관리 기능을 갖추고 있습니다.이러한 유형의 가상화에 의해 제공되는 격리 된 가상 실행 환경을 컨테이너라고하며 추적 된 프로세스 그룹으로 볼 수 있습니다.
컨테이너의 개념은 Linux 커널 버전 2.6.24에 추가 된 네임 스페이스 기능으로 가능합니다.컨테이너는 모든 프로세스에 ID를 추가하고 모든 시스템 호출에 새 액세스 제어 검사를 추가합니다.이전에 글로벌 네임 스페이스의 별도의 인스턴스를 만드는 clone () 시스템 호출에 의해 액세스됩니다.
네임 스페이스는 다양한 방법으로 사용할 수 있지만 가장 일반적인 접근 방식은 컨테이너 외부의 객체에 가시성이나 액세스가없는 격리 된 컨테이너를 만드는 것입니다.컨테이너 내에서 실행되는 프로세스는 다른 종류의 객체에 대해 동일한 네임 스페이스에있는 프로세스를 사용하여 기본 커널을 공유하지만 일반적인 Linux 시스템에서 실행되는 것처럼 보입니다.예를 들어 네임 스페이스를 사용할 때 컨테이너 내부의 루트 사용자가 컨테이너 외부의 루트로 처리되지 않아 추가 보안을 추가합니다.
Linux 제어 그룹 (CGroups) 서브 시스템 인 컨테이너 기반 가상화를 가능하게하는 다음 주요 구성 요소는 프로세스를 그룹화하고 집계 자원 소비를 관리하는 데 사용됩니다.그것은 일반적으로 컨테이너의 메모리 및 CPU 소비를 제한하는 데 사용됩니다.컨테이너 화 된 Linux 시스템에는 하나의 커널 만 있고 커널은 컨테이너에 완벽한 가시성을 가지고 있기 때문에 리소스 할당 및 스케줄링 수준이 하나만 있습니다.
LXC, LXD, SystemD-NSPAWN, LMCTFY, Warden, Linux-VServer, OpenVZ, Docker 등을 포함한 Linux 컨테이너에서 여러 관리 도구를 사용할 수 있습니다.
컨테이너 vs 가상 컴퓨터
가상 컴퓨터와 달리 컨테이너는 운영 체제 커널을 부팅 할 필요가 없으므로 컨테이너를 1 초 이내에 생성 할 수 있습니다.이 기능을 사용하면 다른 가상화 접근법보다 컨테이너 기반 가상화를 고유하고 바람직하게 만듭니다.
컨테이너 기반 가상화는 호스트 시스템에 오버 헤드가 거의 없거나 전혀 없으므로 컨테이너 기반 가상화는 기본 성능이 거의 없습니다.
컨테이너 기반 가상화의 경우 다른 가상화와 달리 추가 소프트웨어가 필요하지 않습니다.
호스트 시스템의 모든 컨테이너는 호스트 시스템의 스케줄러를 공유하여 추가 자원을 절약해야합니다.
컨테이너 상태 (Docker 또는 LXC 이미지)는 가상 컴퓨터 이미지와 비교하여 크기가 작으므로 컨테이너 이미지는 배포가 쉽습니다.
컨테이너의 자원 관리는 CGroup을 통해 이루어집니다.CGroups는 컨테이너가 할당 된 것보다 많은 자원을 소비 할 수 없습니다.그러나 현재 호스트 시스템의 모든 자원은 가상 컴퓨터에서 볼 수 있지만 사용할 수 없습니다.컨테이너 및 호스트 시스템에서 상단 또는 HTOP를 동시에 실행하여 실현할 수 있습니다.모든 환경에서의 출력은 유사합니다.
업데이트:
Docker는 비 - 리눅스 시스템에서 컨테이너를 어떻게 실행합니까?
Linux 커널에서 사용할 수있는 기능으로 인해 컨테이너가 가능하면 분명한 질문은 비 -19 호 시스템이 컨테이너를 실행하는 방법입니다.Mac 및 Windows 용 두 도커 모두 Linux VM을 사용하여 컨테이너를 실행합니다.Docker Toolbox 가상 상자 VM의 컨테이너를 실행하는 데 사용됩니다.그러나 최신 Docker는 Windows에서 Hyper-V와 HyperVisor.Framework를 Mac에서 사용합니다.
이제 Mac 용 Docker가 컨테이너를 자세히 실행하는 방법을 설명하겠습니다.
Mac 용 Docker는 https://github.com/moby/hyperkit을 사용하여 하이퍼 바이저 기능을 에뮬레이션하고 HyperKit은 해당 핵심에서 Hypervisor.Framework를 사용합니다.HyperVisor.Framework는 Mac의 기본 하이퍼 바이저 솔루션입니다.또한 HyperKit은 VPNKIT 및 DataKit을 각각 네임 스페이스 네트워크 및 파일 시스템으로 사용합니다.
Docker가 Mac에서 실행되는 Linux VM은 읽기 전용입니다.그러나 다음을 실행하여 부팅 할 수 있습니다.
화면 ~ / 라이브러리 / 컨테이너 / com.docker.docker / data / vms / 0 / tty.
이제이 VM의 커널 버전을 확인할 수도 있습니다.
# uname -a. Linux Linuxkit-025000000001 4.9.93-linuxkit-aufs # 1 SMP Wed Wed 6 월 6 : 86_64 Linux.
모든 컨테이너는이 VM에서 실행됩니다.
Hypervisor.Framework에 몇 가지 제한 사항이 있습니다.Docker가 Docker0 네트워크 인터페이스를 Mac에 노출시키지 않기 때문입니다.따라서 호스트에서 컨테이너에 액세스 할 수 없습니다.현재 Docker0은 VM 내부에서만 사용할 수 있습니다.
Hyper-V는 Windows의 기본 하이퍼 바이저입니다.또한 Windows 10의 기능을 활용하여 기본적으로 Linux 시스템을 실행하려고 노력하고 있습니다.
답변
대부분의 답변은 가상 컴퓨터에 대해 이야기합니다.Docker를 사용하는 지난 5 년 동안 가장 많은 도움이되는이 질문에 대한 하나의 라이너 응답을 제공 할 것입니다.이게 :
Docker는 가상 컴퓨터가 아닌 프로세스를 실행하는 멋진 방법입니다.
이제 그게 무엇을 의미하는지 조금 더 설명하겠습니다.가상 컴퓨터는 자신의 짐승입니다.Docker가 가상 컴퓨터가 무엇인지 설명하는 것보다 더 많은 것을 이해하는 데 도움이되는 것을 설명하는 것 같습니다.특히 누군가가 "가상 컴퓨터"라고 말할 때 누군가가 의미하는 것을 정확히 말하고있는 훌륭한 답변이 있습니다.그래서...
Docker 컨테이너는 나머지 프로세스에서 호스트 시스템 커널 내부의 CGroups를 사용하여 구획화 된 프로세스 (및 자식) 일뿐입니다.호스트에서 PS Aux를 실행하여 실제로 Docker 컨테이너 프로세스를 볼 수 있습니다.예를 들어, Apache2에서 "컨테이너에서"시작하는 Apache2는 호스트의 특수 프로세스로 Apache2를 시작하는 것입니다.그것은 단지 기계의 다른 프로세스에서 구획 할 수 있습니다.컨테이너가 컨테이너 화 된 프로세스의 수명 외에는 컨테이너가 존재하지 않는다는 점에 유의해야합니다.프로세스가 사망하면 컨테이너가 죽습니다.Docker는 컨테이너 내부에서 PID 1을 응용 프로그램으로 바꿉니다 (PID 1은 일반적으로 init 시스템)을 대체하기 때문입니다.PID 1에 대한이 마지막 지점은 매우 중요합니다.
각 컨테이너 프로세스에서 사용하는 파일 시스템의 한, Docker는 UnionFS 백업 된 이미지를 사용합니다. 이는 Ubuntu를 당기는 일을 할 때 다운로드 한 것입니다. 각 "이미지"는 일련의 레이어 및 관련 메타 데이터 일뿐입니다. 레이어리의 개념은 매우 중요합니다. 각 레이어는 밑에 레이어에서 바뀌는 것입니다. 예를 들어 Docker 컨테이너를 구축하는 동안 Dockerfile에서 파일을 삭제하면 실제로 "이 파일이 삭제되었습니다"라는 마지막 레이어 위에 레이어를 생성합니다. 덧붙여, 이것은 파일 시스템에서 큰 파일을 삭제할 수 있지만 이미지는 여전히 동일한 양의 디스크 공간을 차지합니다. 파일은 현재 하나의 레이어 아래에 있습니다. 레이어 스스로는 파일의 타르볼입니다. Docker Save -output /tmp/ubuntu.tar Ubuntu를 사용하여이를 테스트 할 수 있습니다. 그리고 CD / TMP && Tar XVF Ubuntu.tar. 그럼 당신은 둘러보기를 할 수 있습니다. 긴 해시처럼 보이는 모든 디렉토리는 실제로 개별 레이어입니다. 각각에는 해당 레이어에 대한 정보가 포함 된 파일 (layer.tar) 및 메타 데이터 (JSON)가 포함되어 있습니다. 이러한 레이어는 "맨 위에"레이어로 저장된 파일 시스템으로 변경 사항을 설명합니다. "현재"데이터를 읽을 때 파일 시스템은 가장 중요한 변화의 최상위 레이어에서만 보는 것처럼 데이터를 읽습니다. 이는 파일 시스템이 최상위 레이어를 바라 볼 수 있기 때문에 파일 시스템이 "이전"레이어에 여전히 존재하더라도 파일이 삭제 된 것으로 보이는 이유입니다. 이렇게하면 각 컨테이너의 최상위 레이어의 파일 시스템에 중요한 변경 사항이 일어날 수 있지만 완전히 다른 컨테이너가 파일 시스템 레이어를 공유 할 수 있습니다. 컨테이너가 기본 이미지 레이어를 공유 할 때 디스크 공간을 절약 할 수 있습니다. 그러나 호스트 시스템의 디렉토리와 파일을 볼륨으로 컨테이너로 마운트 할 때 이러한 볼륨은 UnionFS를 "바이 패스"하므로 변경 사항은 레이어에 저장되지 않습니다.
Docker의 네트워킹은 이더넷 브리지 (호스트의 Docker0라는)와 호스트의 모든 컨테이너에 대한 가상 인터페이스를 사용하여 이루어집니다.컨테이너가 서로 통신하기 위해 Docker0의 가상 서브넷을 만듭니다.컨테이너에 대한 사용자 정의 서브넷 만들기 및 컨테이너에 대한 호스트의 네트워킹 스택을 "공유"할 수있는 다양한 옵션이 있습니다.
Docker가 매우 빠르게 움직이고 있습니다.그 문서는 내가 본 최상의 문서 중 일부입니다.일반적으로 잘 쓰여지고 간결하고 정확합니다.자세한 내용은 사용 가능한 설명서를 확인하고 스택 오버플로를 포함하여 온라인으로 읽은 다른 항목을 통해 문서를 신뢰할 것을 권장합니다.특정 질문이있는 경우 FreeNode IRC에 # 모자와 함께 가입하고 거기에서 묻는 것이 좋습니다 (Freenode의 Webchat을 사용할 수도 있습니다!).
출처:https://stackoverflow.com/questions/16047306/how-is-docker-different-from-a-virtual-machine
최근댓글