Docker는 가상 머신과 어떻게 다릅니까?

질문자 :zslayton

Docker와 전체 VM의 차이점을 이해하기 위해 Docker 설명서 를 계속 다시 읽고 있습니다. 무겁지 않으면서 어떻게 전체 파일 시스템, 격리된 네트워킹 환경 등을 제공할 수 있습니까?

소프트웨어를 Docker 이미지에 배포하는 것이 일관성 있는 프로덕션 환경에 배포하는 것보다 쉬운 이유는 무엇입니까?

답변자 : Ken Cochrane

Docker는 원래 LXC(LinuX Containers )를 사용했지만 나중에 호스트와 동일한 운영 체제에서 실행되는 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"의 개념에 대해 혼란스러워하고 있다고 생각합니다. OS의 이미지를 만들지 않고 어떻게 그것을 할 수 있습니까?

글쎄, 내가 설명할 수 있는지 보자. 기본 이미지로 시작한 다음 변경하고 도커를 사용하여 변경 사항을 커밋하면 이미지가 생성됩니다. 이 이미지에는 기본과의 차이점만 포함되어 있습니다. 이미지를 실행하려면 기본도 필요하며 계층화된 파일 시스템을 사용하여 기본 위에 이미지를 계층화합니다. 위에서 언급했듯이 Docker는 AuFS를 사용합니다. AuFS는 서로 다른 레이어를 병합하여 원하는 것을 얻습니다. 실행하기만 하면 됩니다. 계속해서 더 많은 이미지(레이어)를 추가할 수 있으며 계속해서 diff만 저장됩니다. Docker는 일반적으로 레지스트리 의 기성품 이미지를 기반으로 하기 때문에 전체 OS를 직접 "스냅샷"할 필요가 거의 없습니다.

답변자 : manu97

좋은 답변입니다. 컨테이너 대 VM의 이미지 표현을 얻으려면 아래를 살펴보십시오.

원천

답변자 : Shital Shah

가상화 및 컨테이너가 낮은 수준에서 작동하는 방식을 이해하는 것이 도움이 될 수 있습니다. 그러면 많은 것이 해결될 것입니다.

참고: 아래 설명에서 약간 단순화했습니다. 자세한 내용은 참조를 참조하십시오.

가상화는 낮은 수준에서 어떻게 작동합니까?

이 경우 VM 관리자는 CPU 링 0(또는 최신 CPU의 경우 "루트 모드")을 인수하고 게스트 OS가 자체 하드웨어를 가지고 있다는 환상을 만들기 위해 게스트 OS에서 만든 모든 권한 있는 호출을 가로챕니다. 재미있는 사실: 1998년 이전에는 이러한 종류의 가로채기를 수행할 방법이 없었기 때문에 x86 아키텍처에서 이를 달성하는 것이 불가능하다고 생각되었습니다. VMware의 사람들은 이를 달성하기 위해 게스트 OS의 권한 있는 호출을 위해 메모리에 실행 가능한 바이트를 다시 쓰는 아이디어를 처음으로 가졌습니다.

실질적인 효과는 가상화를 통해 동일한 하드웨어에서 완전히 다른 두 개의 OS를 실행할 수 있다는 것입니다. 각 게스트 OS는 부트스트랩, 커널 로딩 등의 모든 과정을 거칩니다. 매우 엄격한 보안을 가질 수 있습니다. 예를 들어 게스트 OS는 호스트 OS 또는 다른 게스트에 대한 전체 액세스 권한을 얻을 수 없어 문제를 망칠 수 있습니다.

컨테이너는 낮은 수준에서 어떻게 작동합니까?

2006년 즈음 에 Google 직원을 비롯한 사람들이 네임스페이스 라는 새로운 커널 수준 기능을 구현했습니다(하지만 이 아이디어 는 FreeBSD에 오래 전부터 존재했습니다). OS의 기능 중 하나는 프로세스 간에 네트워크 및 디스크와 같은 전역 리소스를 공유할 수 있도록 하는 것입니다. 이러한 전역 리소스가 동일한 네임스페이스에서 실행되는 프로세스에서만 볼 수 있도록 네임스페이스로 래핑된 경우 어떻게 될까요? 예를 들어 디스크 덩어리를 가져와서 네임스페이스 X에 넣으면 네임스페이스 Y에서 실행 중인 프로세스가 이를 보거나 액세스할 수 없습니다. 마찬가지로, 네임스페이스 X의 프로세스는 네임스페이스 Y에 할당된 메모리의 어떤 것도 액세스할 수 없습니다. 물론 X의 프로세스는 네임스페이스 Y의 프로세스를 보거나 통신할 수 없습니다. 이는 전역 리소스에 대한 일종의 가상화 및 격리를 제공합니다. Docker가 작동하는 방식은 다음과 같습니다. 각 컨테이너는 자체 네임스페이스에서 실행되지만 다른 모든 컨테이너와 정확히 동일한 커널을 사용합니다. 커널은 프로세스에 할당된 네임스페이스를 알고 API 호출 중에 프로세스가 자체 네임스페이스의 리소스에만 액세스할 수 있도록 하기 때문에 격리가 발생합니다.

컨테이너 대 VM의 한계는 이제 명백해야 합니다. VM에서와 같이 컨테이너에서 완전히 다른 OS를 실행할 수는 없습니다. 그러나 동일한 커널을 공유하기 때문에 다른 Linux 배포판을 실행할 수 있습니다. 격리 수준은 VM만큼 강력하지 않습니다. 사실 초기 구현에서 "게스트" 컨테이너가 호스트를 인수하는 방법이 있었습니다. 또한 새 컨테이너를 로드할 때 OS의 전체 새 복사본이 VM에서와 같이 시작되지 않는 것을 볼 수 있습니다. 모든 컨테이너 는 동일한 커널을 공유합니다 . 이것이 컨테이너가 가벼운 이유입니다. 또한 VM과 달리 OS의 새 복사본을 실행하지 않기 때문에 컨테이너에 상당한 양의 메모리를 미리 할당할 필요가 없습니다. 이를 통해 하나의 OS에서 수천 개의 컨테이너를 샌드박싱하면서 실행할 수 있습니다. 자체 VM에서 별도의 OS 복사본을 실행하는 경우에는 불가능할 수 있습니다.

답변자 : aholbreich

나는 Ken Cochrane의 대답을 좋아합니다.

그러나 여기서 자세히 다루지 않은 추가적인 관점을 추가하고 싶습니다. 제 생각에는 Docker는 전체 프로세스에서도 다릅니다. VM과 달리 Docker는 하드웨어의 최적 리소스 공유에 관한 것일 뿐만 아니라 애플리케이션 패키징을 위한 "시스템"을 제공합니다(마이크로서비스 세트로 바람직하지만 필수는 아님).

나에게 그것은 rpm, Debian 패키지, Maven , npm + Git 과 같은 개발자 지향 도구와 Puppet , VMware, Xen과 같은 작업 도구 사이의 간격에 맞습니다.

소프트웨어를 도커 이미지에 배포하는 것이 일관된 프로덕션 환경에 배포하는 것보다 쉬운 이유는 무엇입니까?

귀하의 질문은 일관된 생산 환경을 가정합니다. 그러나 일관성을 유지하는 방법은 무엇입니까? 파이프라인의 일부(>10) 서버 및 애플리케이션 단계를 고려하십시오.

동기화를 유지하기 위해 Puppet, Chef 또는 자체 프로비저닝 스크립트, 게시되지 않은 규칙 및/또는 많은 문서와 같은 것을 사용하기 시작합니다. 이론상 서버는 무기한 실행될 수 있으며 완전히 일관되고 최신 상태로 유지될 수 있습니다. Practice는 서버의 구성을 완전히 관리하는 데 실패하므로 구성 드리프트 및 실행 중인 서버에 대한 예기치 않은 변경이 발생할 수 있습니다.

그래서 이것을 피하기 위한 알려진 패턴이 있습니다. 이른바 immutable server 입니다. 그러나 불변의 서버 패턴은 사랑받지 못했습니다. 주로 Docker 이전에 사용된 VM의 제한 때문입니다. 응용 프로그램의 일부 필드를 변경하기 위해 몇 기가바이트의 큰 이미지를 처리하고 큰 이미지를 이동하는 것은 매우 힘든 작업이었습니다. 이해할 수 있는...

Docker 에코시스템을 사용하면 "작은 변경"(aufs 및 Registry 덕분)으로 기가바이트를 이동할 필요가 없으며 런타임에 애플리케이션을 Docker 컨테이너에 패키징하여 성능 손실에 대해 걱정할 필요가 없습니다. 해당 이미지의 버전에 대해 걱정할 필요가 없습니다.

마지막으로 Linux 랩톱에서도 복잡한 프로덕션 환경을 재현할 수 있는 경우가 많습니다(귀하의 경우에 작동하지 않으면 저에게 전화하지 마세요 ;))

물론 VM에서 Docker 컨테이너를 시작할 수 있습니다(좋은 생각입니다). VM 수준에서 서버 프로비저닝을 줄입니다. 위의 모든 것은 Docker로 관리할 수 있습니다.

PS 한편 Docker는 LXC 대신 자체 구현 "libcontainer"를 사용합니다. 그러나 LXC는 여전히 사용할 수 있습니다.

답변자 : Ashish Bista

Docker는 가상화 방법론이 아닙니다. 실제로 컨테이너 기반 가상화 또는 운영 체제 수준 가상화를 구현하는 다른 도구에 의존합니다. 이를 위해 Docker는 처음에 LXC 드라이버를 사용한 다음 libcontainer로 이동했으며 현재는 runc로 이름이 변경되었습니다. Docker는 주로 애플리케이션 컨테이너 내부의 애플리케이션 배포 자동화에 중점을 둡니다. 애플리케이션 컨테이너는 단일 서비스를 패키징하고 실행하도록 설계된 반면 시스템 컨테이너는 가상 머신과 같은 여러 프로세스를 실행하도록 설계되었습니다. 따라서 Docker는 컨테이너화된 시스템에서 컨테이너 관리 또는 애플리케이션 배포 도구로 간주됩니다.

다른 가상화와 어떻게 다른지 알기 위해 가상화와 그 종류를 살펴보자. 그러면 차이점이 무엇인지 이해하기가 더 쉬울 것입니다.

가상화

구상된 형태에서는 여러 애플리케이션이 동시에 실행될 수 있도록 메인프레임을 논리적으로 분할하는 방법으로 간주되었습니다. 그러나 회사와 오픈 소스 커뮤니티가 어떤 방식으로든 권한 있는 명령을 처리하는 방법을 제공하고 단일 x86 기반 시스템에서 여러 운영 체제를 동시에 실행할 수 있게 되면서 시나리오가 크게 바뀌었습니다.

하이퍼바이저

하이퍼바이저는 게스트 가상 머신이 작동하는 가상 환경 생성을 처리합니다. 게스트 시스템을 감독하고 필요에 따라 리소스가 게스트에게 할당되는지 확인합니다. 하이퍼바이저는 물리적 머신과 가상 머신 사이에 위치하며 가상 머신에 가상화 서비스를 제공합니다. 이를 실현하기 위해 가상 시스템에서 게스트 운영 체제 작업을 가로채고 호스트 시스템의 운영 체제에서 작업을 에뮬레이트합니다.

주로 클라우드에서 가상화 기술의 급속한 발전은 Xen, VMware Player, KVM 등과 같은 하이퍼바이저의 도움으로 단일 물리적 서버에서 여러 가상 서버를 생성할 수 있게 함으로써 가상화 사용을 더욱 촉진했습니다. Intel VT 및 AMD-V와 같은 상용 프로세서에 하드웨어 지원 통합.

가상화 유형

가상화 방법은 하드웨어를 게스트 운영 체제로 모방하고 게스트 운영 환경을 에뮬레이트하는 방법에 따라 분류할 수 있습니다. 기본적으로 세 가지 유형의 가상화가 있습니다.

• 에뮬레이션
• 반가상화
• 컨테이너 기반 가상화

에뮬레이션

전체 가상화라고도 하는 에뮬레이션은 가상 머신 OS 커널을 완전히 소프트웨어에서 실행합니다. 이 유형에 사용되는 하이퍼바이저는 유형 2 하이퍼바이저로 알려져 있습니다. 게스트 OS 커널 코드를 소프트웨어 지침으로 변환하는 책임이 있는 호스트 운영 체제의 맨 위에 설치됩니다. 번역은 전적으로 소프트웨어에서 수행되며 하드웨어 개입이 필요하지 않습니다. 에뮬레이션을 사용하면 에뮬레이션되는 환경을 지원하는 수정되지 않은 운영 체제를 실행할 수 있습니다. 이러한 유형의 가상화의 단점은 다른 유형의 가상화에 비해 성능이 저하되는 추가 시스템 리소스 오버헤드입니다.

이 범주의 예로는 VMware Player, VirtualBox, QEMU, Bochs, Parallels 등이 있습니다.

반가상화

유형 1 하이퍼바이저라고도 하는 반가상화는 하드웨어 또는 "베어메탈"에서 직접 실행되며 하드웨어에서 실행되는 가상 머신에 직접 가상화 서비스를 제공합니다. 운영 체제, 가상화된 하드웨어 및 실제 하드웨어가 협력하여 최적의 성능을 달성하도록 돕습니다. 이러한 하이퍼바이저는 일반적으로 설치 공간이 다소 작으며 자체적으로 광범위한 리소스가 필요하지 않습니다.

이 범주의 예로는 Xen, KVM 등이 있습니다.

컨테이너 기반 가상화

운영 체제 수준 가상화라고도 하는 컨테이너 기반 가상화는 단일 운영 체제 커널 내에서 여러 개의 격리된 실행을 가능하게 합니다. 가능한 최고의 성능과 밀도를 제공하며 동적 리소스 관리 기능을 제공합니다. 이러한 유형의 가상화가 제공하는 격리된 가상 실행 환경을 컨테이너라고 하며 추적되는 프로세스 그룹으로 볼 수 있습니다.

컨테이너의 개념은 Linux 커널 버전 2.6.24에 추가된 네임스페이스 기능에 의해 가능하게 되었습니다. 컨테이너는 모든 프로세스에 ID를 추가하고 모든 시스템 호출에 새로운 액세스 제어 검사를 추가합니다. 이전 전역 네임스페이스의 개별 인스턴스를 생성할 수 있는 clone() 시스템 호출에 의해 액세스됩니다.

네임스페이스는 다양한 방식으로 사용될 수 있지만 가장 일반적인 접근 방식은 컨테이너 외부의 개체에 대한 가시성 또는 액세스 권한이 없는 격리된 컨테이너를 만드는 것입니다. 컨테이너 내부에서 실행되는 프로세스는 다른 종류의 객체와 마찬가지로 다른 네임스페이스에 있는 프로세스와 기본 커널을 공유하지만 일반 Linux 시스템에서 실행되는 것처럼 보입니다. 예를 들어 네임스페이스를 사용할 때 컨테이너 내부의 루트 사용자는 컨테이너 외부의 루트로 취급되지 않아 보안이 강화됩니다.

컨테이너 기반 가상화를 가능하게 하는 다음 주요 구성 요소인 Linux 제어 그룹(cgroups) 하위 시스템은 프로세스를 그룹화하고 총 리소스 소비를 관리하는 데 사용됩니다. 일반적으로 컨테이너의 메모리 및 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을 사용하여 컨테이너를 실행합니다. Virtual Box VM에서 컨테이너를 실행하는 데 사용되는 Docker Toolbox입니다. 그러나 최신 Docker는 Windows에서 Hyper-V를 사용하고 Mac에서 Hypervisor.framework를 사용합니다.

이제 Mac용 Docker가 컨테이너를 실행하는 방법을 자세히 설명하겠습니다.

Mac용 Docker는 https://github.com/moby/hyperkit 을 사용하여 하이퍼바이저 기능을 에뮬레이트하고 Hyperkit은 코어에서 hypervisor.framework를 사용합니다. Hypervisor.framework는 Mac의 기본 하이퍼바이저 솔루션입니다. Hyperkit은 또한 VPNKit 및 DataKit을 각각 네임스페이스 네트워크 및 파일 시스템에 사용합니다.

Docker가 Mac에서 실행하는 Linux VM은 읽기 전용입니다. 그러나 다음을 실행하여 공격할 수 있습니다.

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는 docker0 네트워크 인터페이스를 노출하지 않습니다. 따라서 호스트에서 컨테이너에 액세스할 수 없습니다. 현재 docker0 은 VM 내에서만 사용할 수 있습니다.

Hyper-v는 Windows의 기본 하이퍼바이저입니다. 또한 Windows 10의 기능을 활용하여 Linux 시스템을 기본적으로 실행하려고 합니다.

답변자 : L0j1k

여기에 있는 대부분의 답변은 가상 머신에 대해 설명합니다. 지난 몇 년 동안 Docker를 사용하는 데 가장 도움이 된 이 질문에 대한 한 줄짜리 답변을 드리겠습니다. 이것은 다음과 같습니다.

Docker는 가상 머신이 아니라 프로세스를 실행하는 멋진 방법입니다.

이제 그 의미에 대해 조금 더 설명하겠습니다. 가상 머신은 그 자체로 짐승입니다. 가상 머신이 무엇인지 설명하는 것보다 Docker 가 무엇인지 설명하는 것이 이것을 이해하는 데 도움이 될 것입니다. 특히 누군가가 "가상 머신"이라고 말할 때 정확히 무엇을 의미하는지 알려주는 훌륭한 답변이 많기 때문입니다. 그래서...

Docker 컨테이너는 나머지 프로세스에서 호스트 시스템 커널 내부의 cgroup을 사용하여 구획화된 프로세스(및 해당 하위)일 뿐입니다. 호스트 ps aux 를 실행하여 실제로 Docker 컨테이너 프로세스를 볼 수 있습니다. 예를 들어, 시작 apache2 "용기에"단지 시작 apache2 호스트에 대한 특별 과정으로. 그것은 기계의 다른 프로세스에서 구획화되었을 뿐입니다. 컨테이너는 컨테이너화된 프로세스의 수명 밖에 존재하지 않는다는 점에 유의하는 것이 중요합니다. 프로세스가 죽으면 컨테이너도 죽습니다. 부두 노동자의 대체합니다이기 때문에 그건 pid 1 응용 프로그램과 함께 컨테이너 내부 ( pid 1 일반적으로 초기화 시스템입니다). pid 1 에 대한 이 마지막 요점은 매우 중요합니다.

각 컨테이너 프로세스에서 사용하는 파일 시스템에 관한 한 Docker는 UnionFS docker pull 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에서 #docker 에 가입하여 질문하는 것이 좋습니다 (Freenode의 웹 채팅 을 사용할 수도 있습니다!).

답변자 : Pankaj Arora

이 게시물을 통해 우리는 VM과 LXC 사이의 몇 가지 차이점을 그릴 것입니다. 먼저 정의합시다.

VM :

가상 머신은 물리적 컴퓨팅 환경을 에뮬레이트하지만 CPU, 메모리, 하드 디스크, 네트워크 및 기타 하드웨어 리소스에 대한 요청은 이러한 요청을 기본 물리적 하드웨어로 변환하는 가상화 계층에 의해 관리됩니다.

이 컨텍스트에서 VM은 게스트라고 하고 VM이 실행되는 환경은 호스트라고 합니다.

LXC :

Linux 컨테이너(LXC)는 하나의 제어 호스트(LXC 호스트)에서 격리된 여러 Linux 컨테이너를 실행할 수 있게 해주는 운영 체제 수준 기능입니다. Linux 컨테이너는 하이퍼바이저가 필요하지 않기 때문에 VM에 대한 경량 대안 역할을 합니다. 버추얼박스, KVM, 젠 등

이제 당신이 Alan(Hangover 시리즈의 Zach Galifianakis)에 의해 약을 먹지 않고 작년에 Vegas에 있지 않았다면 Linux 컨테이너 기술에 대한 엄청난 관심에 대해 꽤 알고 있을 것입니다. 지난 몇 개월 동안 전 세계적으로 화제를 모은 프로젝트는 – Docker는 클라우드 컴퓨팅 환경이 더 낮은 오버헤드와 잠재적으로 더 나은 성능으로 인해 가상 머신(VM)을 포기하고 컨테이너로 대체해야 한다는 일부 반향을 불러일으키는 의견을 제시합니다.

그러나 가장 큰 문제는 실현 가능합니까? 합리적입니까?

NS. LXC는 Linux 인스턴스로 범위가 지정됩니다. 다른 종류의 Linux일 수 있습니다(예: CentOS 호스트의 Ubuntu 컨테이너이지만 여전히 Linux입니다.). 마찬가지로 Windows 기반 컨테이너는 이제 VM을 보면 Windows 인스턴스로 범위가 지정됩니다. 하이퍼바이저는 Linux 또는 Windows 운영 체제에 국한되지 않습니다.

NS. LXC는 VM에 비해 오버헤드가 낮고 성능이 더 좋습니다. 도구 즉. LXC 기술을 기반으로 구축된 Docker는 개발자에게 애플리케이션을 실행할 수 있는 플랫폼을 제공하는 동시에 운영 담당자에게 프로덕션 서버 또는 데이터 센터에 동일한 컨테이너를 배포할 수 있는 도구를 제공합니다. 애플리케이션을 실행하고 애플리케이션을 부팅 및 테스트하는 개발자와 해당 애플리케이션을 배포하는 운영 담당자 간의 경험을 원활하게 만들려고 합니다. DevOps의 목적은 이러한 사일로를 무너뜨리는 데 모든 마찰이 있는 곳이기 때문입니다.

따라서 최선의 접근 방식은 클라우드 인프라 제공업체가 VM 및 LXC의 적절한 사용을 옹호해야 한다는 것입니다. VM 및 LXC는 각각 특정 워크로드 및 시나리오를 처리하는 데 적합하기 때문입니다.

VM을 포기하는 것은 현재로서는 실용적이지 않습니다. 따라서 VM과 LXC는 모두 고유한 개별 존재와 중요성을 가지고 있습니다.

답변자 : Giovanni De Gasperis

Docker는 모든 종속성과 함께 애플리케이션을 캡슐화합니다.

가상화 장치는 일반적으로 베어메탈 머신에서 실행할 수 있는 모든 애플리케이션을 실행할 수 있는 OS를 캡슐화합니다.

답변자 : resultsway

둘 다 매우 다릅니다. Docker는 가볍고 LXC/libcontainer(커널 네임스페이스 및 cgroups에 의존)를 사용하며 하이퍼바이저, KVM과 같은 기계/하드웨어 에뮬레이션이 없습니다. 무거운 젠.

Docker 및 LXC는 샌드박싱, 컨테이너화 및 리소스 격리에 더 적합합니다. IPC, NS(마운트), 네트워크, PID, UTS 등에 대한 네임스페이스를 제공하는 호스트 OS(현재는 Linux 커널만) 복제 API를 사용합니다.

메모리, I/O, CPU 등은 어떻습니까? 이는 특정 리소스(CPU, 메모리 등) 사양/제한이 있는 그룹을 만들고 거기에 프로세스를 넣을 수 있는 cgroup을 사용하여 제어됩니다. LXC 위에 Docker는 스토리지 백엔드( http://www.projectatomic.io/docs/filesystems/ )를 제공합니다. 예를 들어, 다른 마운트 네임스페이스 간에 레이어를 추가하고 레이어를 공유할 수 있는 유니온 마운트 파일 시스템입니다.

이것은 기본 이미지가 일반적으로 읽기 전용이고 컨테이너가 레이어에서 무언가를 수정할 때만 읽기-쓰기 파티션(일명 copy on write)에 무언가를 쓰는 강력한 기능입니다. 또한 레지스트리 및 이미지 버전 관리와 같은 다른 많은 래퍼를 제공합니다.

일반 LXC를 사용하면 일부 rootfs와 함께 제공되거나 rootfs를 공유해야 하며 공유할 때 변경 사항이 다른 컨테이너에 반영됩니다. 이러한 추가 기능이 많기 때문에 LXC보다 Docker가 더 유명합니다. LXC는 네트워크 및 UI와 같은 외부 엔터티에 노출된 프로세스 주변의 보안을 구현하기 위해 임베디드 환경에서 널리 사용됩니다. Docker는 일관된 프로덕션 환경이 예상되는 클라우드 멀티 테넌시 환경에서 인기가 있습니다.

일반 VM(예: VirtualBox 및 VMware)은 하이퍼바이저를 사용하며 관련 기술에는 첫 번째 OS(호스트 OS 또는 게스트 OS 0)의 첫 번째 계층이 되는 전용 펌웨어 또는 호스트 OS에서 실행되는 소프트웨어가 있습니다. CPU, USB/액세서리, 메모리, 네트워크 등과 같은 하드웨어 에뮬레이션을 게스트 OS에 제공합니다. VM은 여전히(2015년 현재) 높은 보안 다중 테넌트 환경에서 널리 사용됩니다.

Docker/LXC는 거의 모든 저렴한 하드웨어에서 실행할 수 있습니다(최신 커널이 있는 한 1GB 미만의 메모리도 괜찮음). 일반 VM은 의미 있는 작업을 수행하기 위해 최소 2GB의 메모리 등이 필요합니다. . 그러나 호스트 OS에 대한 Docker 지원은 Windows(2014년 11월 기준)와 같은 OS에서 사용할 수 없으며 Windows, Linux 및 Mac에서 VM 유형을 실행할 수 있습니다.

다음은 docker/rightscale의 사진입니다.

답변자 : cizixs

1. 경량

이것은 아마도 많은 도커 학습자에게 첫인상일 것입니다.

첫째, 도커 이미지는 일반적으로 VM 이미지보다 작기 때문에 빌드, 복사, 공유가 쉽습니다.

둘째, Docker 컨테이너는 몇 밀리초 만에 시작할 수 있는 반면 VM은 몇 초 만에 시작할 수 있습니다.

2. 계층화된 파일 시스템

이것은 Docker의 또 다른 핵심 기능입니다. 이미지에는 레이어가 있고 다른 이미지는 레이어를 공유할 수 있으므로 공간을 더욱 절약하고 빠르게 구축할 수 있습니다.

모든 컨테이너가 기본 이미지로 Ubuntu를 사용하는 경우 모든 이미지에 자체 파일 시스템이 있는 것은 아니지만 동일한 밑줄 ubuntu 파일을 공유하고 자체 애플리케이션 데이터만 다릅니다.

3. 공유 OS 커널

컨테이너를 프로세스로 생각하십시오!

호스트에서 실행되는 모든 컨테이너는 실제로 서로 다른 파일 시스템을 가진 프로세스의 무리입니다. 동일한 OS 커널을 공유하고 시스템 라이브러리와 종속성만 캡슐화합니다.

이것은 대부분의 경우에 좋지만(추가 OS 커널 유지 관리 없음) 컨테이너 간에 엄격한 격리가 필요한 경우 문제가 될 수 있습니다.

중요한 이유는 무엇입니까?

이 모든 것은 혁명이 아니라 개선처럼 보입니다. 음, 양적 축적은 질적 변형으로 이어집니다 .

애플리케이션 배포에 대해 생각해 보십시오. 새 소프트웨어(서비스)를 배포하거나 업그레이드하려면 새 VM을 만드는 것보다 구성 파일과 프로세스를 변경하는 것이 좋습니다. 업데이트된 서비스로 VM을 만들고 테스트(개발자와 QA 간 공유)하기 때문에 프로덕션에 배포하는 데 몇 시간, 심지어 며칠이 걸립니다. 문제가 발생하면 다시 시작해야 하므로 더 많은 시간을 낭비하게 됩니다. 따라서 구성 관리 도구(puppet, saltstack, chef 등)를 사용하여 새 소프트웨어를 설치하고 새 파일을 다운로드하는 것이 좋습니다.

도커의 경우 새로 생성된 도커 컨테이너를 사용하여 이전 컨테이너를 대체하는 것은 불가능합니다. 유지 관리가 훨씬 쉽습니다! 새 이미지를 빌드하고, QA와 공유하고, 테스트하고, 배포하는 데 몇 분(모든 것이 자동화된 경우), 최악의 경우 몇 시간이면 됩니다. 이것을 불변 인프라 라고 합니다. 소프트웨어를 유지 관리(업그레이드)하지 말고 대신 새 소프트웨어를 만드십시오.

서비스 제공 방식을 변화시킵니다. 우리는 애플리케이션을 원하지만 VM을 유지해야 합니다(이는 고통스럽고 애플리케이션과 거의 관련이 없음). Docker를 사용하면 애플리케이션에 집중할 수 있고 모든 것이 원활해집니다.

답변자 : Ali Kahoot

기본적으로 컨테이너인 Docker는 OS 가상화를 지원합니다. 즉, 애플리케이션은 OS의 완전한 인스턴스가 있다고 느끼는 반면 VM은 하드웨어 가상화를 지원합니다. 모든 OS를 부팅할 수 있는 물리적 시스템처럼 느껴집니다.

Docker에서 실행 중인 컨테이너는 호스트 OS 커널을 공유하는 반면 VM에서는 자체 OS 파일이 있습니다. 애플리케이션을 개발하는 환경(OS)은 "테스트" 또는 "프로덕션"과 같은 다양한 서비스 환경에 배포할 때 동일합니다.

예를 들어, 포트 4000에서 실행되는 웹 서버를 개발하는 경우 "테스트" 환경에 배포할 때 해당 포트는 이미 다른 프로그램에서 사용하고 있으므로 작동이 중지됩니다. 컨테이너에는 레이어가 있습니다. OS에 대한 모든 변경 사항은 하나 이상의 레이어에 저장되고 해당 레이어는 이미지의 일부가 되므로 이미지가 어디에 있든 종속성도 존재합니다.

아래 표시된 예에서 호스트 시스템에는 3개의 VM이 있습니다. VM의 애플리케이션에 완전한 격리를 제공하기 위해 각각에는 OS의 전체 메모리 내 인스턴스와 함께 OS 파일, 라이브러리 및 애플리케이션 코드의 자체 복사본이 있습니다. 아래 그림은 컨테이너와 동일한 시나리오를 보여줍니다. 여기서 컨테이너는 커널과 라이브러리를 포함한 호스트 운영 체제를 단순히 공유하므로 OS를 부팅하거나 라이브러리를 로드하거나 해당 파일에 대한 개인 메모리 비용을 지불할 필요가 없습니다. 그들이 차지하는 유일한 증분 공간은 애플리케이션이 컨테이너에서 실행되는 데 필요한 모든 메모리와 디스크 공간입니다. 애플리케이션의 환경은 전용 OS처럼 느껴지지만 애플리케이션은 전용 호스트에 배포하는 것처럼 배포됩니다. 컨테이너화된 애플리케이션은 몇 초 만에 시작되며 VM의 경우보다 더 많은 애플리케이션 인스턴스가 시스템에 들어갈 수 있습니다.

출처: https://azure.microsoft.com/en-us/blog/containers-docker-windows-and-trends/

답변자 : mohan08p

애플리케이션을 실행할 스택을 제공하는 세 가지 설정이 있습니다(이는 컨테이너가 무엇이며 다른 솔루션보다 훨씬 강력한 이유를 인식하는 데 도움이 됩니다).

 1) Traditional Servers(bare metal) 2) Virtual machines (VMs) 3) Containers

1) 기존 서버 스택은 운영 체제와 애플리케이션을 실행하는 물리적 서버로 구성됩니다.

장점:

• 원시 자원의 활용

• 격리

단점:

• 매우 느린 배포 시간
• 값 비싼
• 낭비되는 자원
• 확장하기 어려움
• 마이그레이션이 어려움
• 복잡한 구성

2) VM 스택 은 운영 체제를 실행하는 물리적 서버와 가상 머신, 공유 리소스 및 네트워킹 인터페이스를 관리하는 하이퍼바이저로 구성됩니다. 각 VM은 게스트 운영 체제, 애플리케이션 또는 애플리케이션 세트를 실행합니다.

장점:

• 자원의 좋은 사용
• 간편한 확장
• 간편한 백업 및 마이그레이션
• 비용 효율성
• 유연성

단점:

• 리소스 할당이 문제
• 공급업체 잠금
• 복잡한 구성

3) 컨테이너 설정 , 다른 스택과의 주요 차이점은 컨테이너 기반 가상화가 호스트 OS의 커널을 사용하여 여러 개의 격리된 게스트 인스턴스를 럼핑한다는 것입니다. 이러한 게스트 인스턴스를 컨테이너라고 합니다. 호스트는 물리적 서버 또는 VM일 수 있습니다.

장점:

• 격리
• 경량
• 효율적인 자원
• 간편한 마이그레이션
• 보안
• 낮은 간접비
• 미러 생산 및 개발 환경

단점:

• 동일한 아키텍처
• 리소스가 많은 앱
• 네트워킹 및 보안 문제.

컨테이너 설정을 이전 버전과 비교하여 컨테이너화가 우리가 지금까지 알고 있는 가장 빠르고 리소스 효율적이며 안전한 설정이라는 결론을 내릴 수 있습니다. 컨테이너는 애플리케이션을 실행하는 격리된 인스턴스입니다. Docker는 컨테이너를 어떤 방식으로 스핀업하고, 레이어는 몇 초 안에 실행되는 기본 스토리지 드라이버(오버레이 드라이버)와 함께 런타임 메모리를 가져오고 컨테이너에 커밋하면 그 위에 작성되는 copy-on-write 레이어가 실행을 지원합니다. 컨테이너. VM의 경우 가상화 환경에 모든 것을 로드하는 데 약 1분이 소요됩니다. 이러한 경량 인스턴스는 쉽게 교체, 재구축 및 이동할 수 있습니다. 이를 통해 프로덕션 및 개발 환경을 미러링할 수 있으며 CI/CD 프로세스에 큰 도움이 됩니다. 컨테이너가 제공할 수 있는 이점은 매우 강력하여 계속 유지될 것입니다.

답변자 : Greg Trevellick

관련하여:-

"간단히 일관된 프로덕션 환경에 배포하는 것보다 소프트웨어를 도커 이미지에 배포하는 것이 더 쉬운 이유는 무엇입니까?"

대부분의 소프트웨어는 일반적으로 다음 중 최소 세 가지를 비롯한 많은 환경에 배포됩니다.

1. 개별 개발자 PC
2. 공유 개발자 환경
3. 개별 테스터 PC
4. 공유 테스트 환경
5. 품질보증 환경
6. UAT 환경
7. 부하/성능 테스트
8. 라이브 스테이징
9. 생산
10. 보관소

다음과 같은 요소도 고려해야 합니다.

• 개발자와 실제로 테스터는 모두 작업의 특성에 따라 미묘하게 또는 크게 다른 PC 구성을 갖습니다.
• 개발자는 종종 기업 또는 비즈니스 표준화 규칙의 통제를 벗어난 PC에서 개발할 수 있습니다(예: 자신의 컴퓨터(종종 원격으로)에서 개발하는 프리랜서 또는 특정 PC를 구성하기 위해 '고용' 또는 '계약'되지 않은 오픈 소스 프로젝트 기여자 방법)
• 일부 환경은 로드 밸런싱된 구성에서 고정된 수의 여러 시스템으로 구성됩니다.
• 많은 프로덕션 환경에는 트래픽 수준에 따라 클라우드 기반 서버가 동적으로(또는 '탄력적으로') 생성 및 삭제됩니다.

보시다시피 외삽된 조직의 총 서버 수는 단일 숫자로 표시되는 경우가 거의 없으며 매우 자주 3자리 숫자로 표시되며 여전히 훨씬 더 높을 수 있습니다.

이 처음부터 일관성있는 환경을 조성하는 것은 단지 때문에 엄청난 양의 (심지어 그린 필드 시나리오)의 열심히는하지만, 그 일관성 유지하는 것은 제외한 모든 동적 (새 서버 추가 서버의 높은 숫자, 주어진 불가능하거나하는 모든 수단 수동), 운영 체제 공급업체, 안티바이러스 공급업체, 브라우저 공급업체 등의 자동 업데이트, 개발자 또는 서버 기술자가 수행하는 수동 소프트웨어 설치 또는 구성 변경 등. 다시 말씀드리지만 - 사실상(말장난이 아닌) 불가능합니다. 환경을 일관되게 유지하기 위해(예, 순수주의자에게는 가능하지만 엄청난 시간, 노력 및 훈련이 필요합니다. 이것이 바로 VM과 컨테이너(예: Docker)가 처음에 고안된 이유입니다).

따라서 귀하의 질문을 "모든 환경을 일관성 있게 유지하는 것이 극도로 어렵다는 점을 감안할 때 학습 곡선을 고려할 때에도 도커 이미지에 소프트웨어를 배포하는 것이 더 쉽습니까?"와 같이 생각하십시오. . 답은 항상 "예"일 것입니다. 하지만 알아낼 수 있는 방법은 단 한 가지뿐입니다. 이 새로운 질문을 스택 오버플로에 게시하세요.

답변자 : Jayabalan Bala

차이점에 대해 더 자세히 설명하는 답변이 많이 있지만 여기에 아주 간단한 설명이 있습니다.

한 가지 중요한 차이점은 VM이 별도의 커널을 사용하여 OS를 실행한다는 것 입니다. 이것이 무겁고 부팅하는 데 시간이 걸리고 더 많은 시스템 리소스를 소비하는 이유입니다.

Docker에서 컨테이너 는 호스트와 커널을 공유합니다. 따라서 가볍고 빠르게 시작하고 멈출 수 있습니다.

가상화에서 리소스는 설정 초기에 할당되므로 가상 머신이 많은 시간 동안 유휴 상태일 때 리소스가 완전히 활용되지 않습니다. Docker에서는 컨테이너에 고정된 양의 하드웨어 리소스가 할당되지 않고 요구 사항에 따라 리소스를 자유롭게 사용할 수 있으므로 확장성이 뛰어납니다.

Docker는 UNION 파일 시스템을 사용합니다. Docker는 쓰기 시 복사 기술을 사용하여 컨테이너가 사용하는 메모리 공간을 줄입니다. 여기에서 더 읽어보기

답변자 : Nedzad G

가상 머신을 사용하면 서버가 있고 해당 서버에 호스트 운영 체제가 있고 하이퍼바이저가 있습니다. 그런 다음 해당 하이퍼바이저 위에서 실행하면 해당 서버에 애플리케이션과 종속 바이너리, 라이브러리가 있는 게스트 운영 체제가 얼마든지 있습니다. 전체 게스트 운영 체제를 제공합니다. 상당히 무겁습니다. 또한 각 물리적 시스템에 실제로 넣을 수 있는 양에는 제한이 있습니다.

반면 Docker 컨테이너 는 약간 다릅니다. 서버가 있습니다. 호스트 운영 체제가 있습니다. 그러나 이 경우에는 하이퍼바이저 대신 Docker 엔진 이 있습니다. 이 경우 전체 게스트 운영 체제를 가져오지 않습니다. 우리는 운영 체제의 매우 얇은 계층을 가져올 것이며 컨테이너는 커널 기능에 도달하기 위해 호스트 OS와 통신할 수 있습니다. 그리고 그것은 우리가 매우 가벼운 컨테이너를 가질 수 있게 해줍니다.

필요한 것은 애플리케이션 코드와 바이너리 및 라이브러리뿐입니다. 그리고 이러한 바이너리와 라이브러리는 원하는 경우 실제로 다른 컨테이너에서 공유할 수 있습니다. 그리고 이것이 우리가 할 수 있게 해주는 것은 여러 가지입니다. 그들 은 훨씬 더 빠른 시작 시간 을 가지고 있습니다 . 그렇게 몇 초 만에 단일 VM을 세울 수 없습니다. 마찬가지로 빠르게 축소하여 매우 빠르게 확장 및 축소할 수 있으며 나중에 살펴보겠습니다.

모든 컨테이너는 자체 운영 체제 복사본에서 실행되고 있다고 생각합니다. 그것은 일종의 거짓말인 자체 파일 시스템, 자체 레지스트리 등이 있습니다. 실제로 가상화되고 있습니다.

답변자 : TastyCode

출처: 실행 중인 Kubernetes.

답변자 : Touraj Ebrahimi

프로덕션 환경과 스테이징에서 Docker를 많이 사용했습니다. 익숙해지면 다중 컨테이너 및 격리된 환경을 구축하는 데 매우 강력하다는 것을 알게 될 것입니다.

Docker는 LXC(Linux Container)를 기반으로 개발되었으며 많은 Linux 배포판, 특히 Ubuntu에서 완벽하게 작동합니다.

Docker 컨테이너는 격리된 환경입니다. Docker 이미지에서 생성된 Docker 컨테이너에서 top 명령을 실행하면 확인할 수 있습니다.

게다가 dockerFile 구성 덕분에 매우 가볍고 유연합니다.

예를 들어, Docker 이미지를 생성하고 DockerFile을 구성하고 예를 들어 실행 중일 때 wget 'this', apt-get 'that', '일부 셸 스크립트' 실행, 환경 변수 설정 등을 알릴 수 있습니다.

마이크로 서비스 프로젝트 및 아키텍처에서 Docker는 매우 실행 가능한 자산입니다. Docker, Docker Swarm, Kubernetes 및 Docker Compose를 사용하여 확장성, 탄력성 및 탄력성을 달성할 수 있습니다.

Docker와 관련된 또 다른 중요한 문제는 Docker Hub와 해당 커뮤니티입니다. 예를 들어 Prometheus, Grafana, Prometheus-JMX-Exporter 및 Docker를 사용하여 kafka를 모니터링하는 에코시스템을 구현했습니다.

이를 위해 Zookeeper, kafka, Prometheus, Grafana 및 jmx-collector용으로 구성된 Docker 컨테이너를 다운로드한 다음 YAML 파일을 사용하여 일부에 대해 자체 구성을 마운트하거나 Docker 컨테이너에서 일부 파일 및 구성을 변경했습니다. 이 아키텍처를 여러 서버로 쉽게 이동할 수 있는 격리 및 확장성 및 탄력성을 갖춘 단일 시스템에서 다중 컨테이너 Docker를 사용하여 kafka를 모니터링하기 위한 전체 시스템을 구축합니다.

Docker Hub 사이트 외에도 quay.io라는 다른 사이트가 있습니다. 이 사이트를 사용하면 자신의 Docker 이미지 대시보드를 갖고 여기에서 끌어오기/푸시할 수 있습니다. Docker Hub에서 부두로 Docker 이미지를 가져온 다음 자체 머신의 부두에서 실행할 수도 있습니다.

참고: Docker를 배우는 것은 처음에는 복잡하고 어려워 보이지만 익숙해지면 Docker 없이는 작업할 수 없습니다.

Docker로 작업한 첫 날에 잘못된 명령을 실행하거나 컨테이너와 모든 데이터 및 구성을 실수로 제거했을 때를 기억합니다.

답변자 : Alireza

Docker 는 다음과 같이 소개합니다.

Docker는 컨테이너 이동을 주도하는 회사이자 하이브리드 클라우드에서 모든 애플리케이션을 처리하는 유일한 컨테이너 플랫폼 제공업체입니다. 오늘날의 기업은 디지털 혁신에 대한 압박을 받고 있지만 기존 애플리케이션 및 인프라의 제약을 받는 동시에 점점 더 다양한 클라우드, 데이터 센터 및 애플리케이션 아키텍처 포트폴리오를 합리화합니다. Docker는 애플리케이션과 인프라, 개발자 및 IT 운영 간의 진정한 독립을 가능하게 하여 잠재력을 발휘하고 더 나은 협업 및 혁신을 위한 모델을 만듭니다.

따라서 Docker 는 컨테이너 기반입니다. 즉, 현재 컴퓨터에서 실행할 수 있는 이미지와 컨테이너가 있습니다. VM 과 같은 운영 체제는 포함하지 않지만 Java, Tomcat 등과 같은 다양한 작업 팩 팩과 같습니다.

컨테이너를 이해하면 Docker가 무엇이고 VM 과 어떻게 다른지 알 수 있습니다.

그렇다면 컨테이너는 무엇일까요?

컨테이너 이미지는 코드, 런타임, 시스템 도구, 시스템 라이브러리, 설정 등 이를 실행하는 데 필요한 모든 것을 포함하는 가벼운 독립 실행형 소프트웨어 패키지입니다. Linux 및 Windows 기반 앱 모두에서 사용할 수 있는 컨테이너화된 소프트웨어는 환경에 관계없이 항상 동일하게 실행됩니다. 컨테이너는 개발 환경과 스테이징 환경 간의 차이와 같이 주변 환경에서 소프트웨어를 격리하고 동일한 인프라에서 서로 다른 소프트웨어를 실행하는 팀 간의 충돌을 줄이는 데 도움이 됩니다.

따라서 아래 이미지에서 볼 수 있듯이 각 컨테이너에는 별도의 팩이 있으며 단일 시스템에서 실행되어 해당 시스템의 운영 체제를 공유합니다... 안전하고 배송이 쉽습니다...

답변자 : TJA

여기에 VM과 컨테이너의 차이점과 Docker의 기원을 명확하게 설명하는 멋진 기술 답변이 많이 있습니다.

저에게 VM과 Docker의 근본적인 차이점은 애플리케이션 프로모션을 관리하는 방법입니다.

VM을 사용하면 애플리케이션과 해당 종속성을 한 VM에서 다음 DEV, UAT, PRD로 승격합니다.

1. 종종 이러한 VM에는 다른 패치와 라이브러리가 있습니다.
2. 여러 애플리케이션이 VM을 공유하는 것은 드문 일이 아닙니다. 이를 위해서는 모든 애플리케이션에 대한 구성 및 종속성을 관리해야 합니다.
3. 취소하려면 VM에서 변경 사항을 실행 취소해야 합니다. 또는 가능하면 복원합니다.

Docker의 아이디어는 필요한 라이브러리와 함께 자체 컨테이너 내부에 애플리케이션을 묶은 다음 전체 컨테이너를 단일 단위로 승격하는 것입니다.

1. 커널을 제외하고 패치와 라이브러리는 동일합니다.
2. 일반적으로 구성을 단순화하는 컨테이너당 하나의 애플리케이션만 있습니다.
3. 백아웃은 컨테이너 중지 및 삭제로 구성됩니다.

따라서 VM의 가장 기본적인 수준에서는 애플리케이션과 해당 종속성을 개별 구성 요소로 승격하는 반면 Docker를 사용하면 모든 것을 한 번에 승격할 수 있습니다.

Kubernetes 또는 Docker Swarm과 같은 도구가 작업을 크게 단순화하지만 컨테이너 관리를 포함하여 컨테이너에 문제가 있습니다.

답변자 : Sulaiman Al-farisi

내 생각에 그것은 당신의 응용 프로그램의 요구에서 볼 수 있습니다. Docker가 기능에 따라 응용 프로그램을 작은 부분으로 나누기 때문에 Docker에 배포하기로 결정한 이유는 하나의 응용 프로그램 / 기능이 오류 일 때 효과적이기 때문입니다. 전체 VM을 사용하는 것과 달리 다른 응용 프로그램에는 영향을 미치지 않습니다. 구성이 느리고 복잡하지만 어떤 면에서는 도커보다 안전합니다.

답변자 : peterh

도커 문서(및 자체 설명)는 "가상 머신"과 "컨테이너"를 구분합니다. 그들은 조금 특이한 방식으로 사물을 해석하고 사용하는 경향이 있습니다. 그들이 그렇게 할 수 있는 이유는 그들이 문서에 무엇을 작성했는지, 그리고 가상화에 대한 용어가 아직 정확하지 않기 때문입니다.

사실은 Docker 문서가 "컨테이너"에 대해 이해하는 것이며, 실제로는 반가상화 (때로는 "OS 수준 가상화")이며, 반대로 하드웨어 가상화 는 도커가 아닙니다.

Docker는 저품질 반가상화 솔루션입니다. 컨테이너 대 VM 구별은 제품의 심각한 단점을 설명하기 위해 도커 개발에 의해 발명되었습니다.

그것이 대중화 된 이유는 " 보통 사람들에게 불을 주었다 ", 즉 Win10 워크 스테이션에서 일반적으로 서버 (= Linux) 환경 / 소프트웨어 제품을 간단하게 사용할 수있게했기 때문입니다. 이것은 또한 우리가 그들의 작은 "뉘앙스"를 용인하는 이유이기도 합니다. 하지만 그렇다고 해서 우리도 믿어야 하는 것은 아닙니다.

Windows 호스트의 docker가 HyperV에 내장된 Linux를 사용하고 해당 컨테이너가 그 안에서 실행되었다는 사실로 인해 상황이 더욱 흐려졌습니다. 따라서 Windows의 docker는 결합된 하드웨어 및 반가상화 솔루션을 사용합니다.

요컨대, Docker 컨테이너는 큰 장점과 많은 단점이 있는 저품질(반)가상 머신입니다.

출처 : Here

출처 : http:www.stackoverflow.com/questions/16047306/how-is-docker-different-from-a-virtual-machine">