도커는 가상 시스템과 어떻게 다릅니까?

도커는 가상 시스템과 어떻게 다릅니까?

Docker 설명서를 계속 다시 읽고 Docker와 전체 VM의 차이점을 이해하려고 합니다.전체 파일 시스템, 격리된 네트워킹 환경 등을 대량으로 제공하는 방법은 무엇입니까?

소프트웨어를 Docker 이미지(적절한 용어인 경우)에 배포하는 것이 일관된 프로덕션 환경에 배포하는 것보다 쉬운 이유는 무엇입니까?

도커는 원래 LXC(LinuX Containers)를 사용했지만 나중에 호스트와 동일한 운영 체제에서 실행되는 runC(이전의 lib Container)로 전환했습니다.따라서 많은 호스트 운영 체제 리소스를 공유할 수 있습니다.또한 계층형 파일 시스템(AuFS)을 사용하고 네트워킹을 관리합니다.

AuFS는 계층화된 파일 시스템이므로 읽기 전용 부분과 쓰기 부분을 함께 병합할 수 있습니다.운영 체제의 공통 부분을 읽기 전용으로 하고(모든 컨테이너 간에 공유) 각 컨테이너에 쓰기 위한 마운트를 지정할 수 있습니다.

예를 들어 1GB 컨테이너 이미지가 있다고 가정합니다. 전체 VM을 사용하려면 1GB x 수의 VM이 필요합니다.Docker 및 AuFS를 사용하면 모든 컨테이너 간에 1GB의 대부분을 공유할 수 있으며, 1000개의 컨테이너가 있는 경우에도 컨테이너 OS를 위한 공간이 1GB를 약간 초과할 수 있습니다(모두 동일한 OS 이미지를 실행하고 있다고 가정).

전체 가상화된 시스템은 고유한 리소스 집합을 할당받고 공유를 최소화합니다.더 많은 격리를 얻을 수 있지만 훨씬 더 무겁습니다(더 많은 리소스가 필요함)도커를 사용하면 격리가 덜 되지만 컨테이너는 경량입니다(필요한 리소스가 더 적습니다).따라서 호스트에서 수천 개의 컨테이너를 쉽게 실행할 수 있으며 깜박이지도 않습니다.Xen과 함께 시도해 보십시오. 그리고 당신이 정말 큰 호스트를 가지고 있지 않는 한, 저는 그것이 가능하다고 생각하지 않습니다.

Docker/LXC/runC 컨테이너를 시작하는 데 몇 초, 심지어 1초도 걸리지 않는 경우가 있는 반면, 전체 가상화 시스템은 시작하는 데 몇 분이 걸립니다.

가상화된 시스템 유형별로 장단점이 있습니다.보장된 리소스로 완벽하게 격리하려면 전체 VM을 사용하는 것이 좋습니다.프로세스를 서로 분리하고 합리적인 크기의 호스트에서 대량의 프로세스를 실행하려면 Docker/LXC/runC가 최선의 방법인 것 같습니다.

자세한 내용은 LXC 작동 방식을 설명하는 데 도움이 되는 블로그 게시물을 확인하십시오.

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

일관된 프로덕션 환경을 구축하는 것은 말처럼 쉽지 않습니다.Chef 및 Puppet과 같은 도구를 사용하더라도 호스트와 환경 간에 변경되는 OS 업데이트 및 기타 사항이 항상 있습니다.

도커를 사용하면 OS를 공유 이미지로 스냅샷할 수 있으며 다른 도커 호스트에 쉽게 배포할 수 있습니다.로컬, 개발, qa, prod 등: 모두 동일한 이미지.물론 다른 도구로도 이 작업을 수행할 수 있지만, 그렇게 쉽게 또는 빠르게 수행할 수는 없습니다.

데이터베이스에 연결해야 하는 수천 개의 테스트가 있고 각 테스트에 데이터베이스의 원본 복사본이 필요하며 데이터를 변경한다고 가정해 보겠습니다.이에 대한 고전적인 접근 방식은 사용자 지정 코드 또는 Flyway와 같은 도구를 사용하여 모든 테스트 후에 데이터베이스를 재설정하는 것입니다. 이는 매우 많은 시간이 소요될 수 있으며 테스트를 연속적으로 실행해야 함을 의미합니다.그러나 Docker를 사용하면 데이터베이스 이미지를 생성하고 테스트당 하나의 인스턴스를 실행한 다음 모든 테스트를 데이터베이스의 동일한 스냅샷에 대해 실행할 수 있으므로 병렬로 실행할 수 있습니다.테스트가 병렬로 실행되고 도커 컨테이너에서 실행되므로 동일한 상자에서 동시에 모두 실행할 수 있으며 훨씬 더 빨리 완료되어야 합니다.전체 VM을 사용하여 이 작업을 수행해 보십시오.

댓글에서...

흥미롭군요!저는 아직도 "운영 체제 스냅샷"이라는 개념 때문에 혼란스러워하는 것 같습니다.OS 이미지를 만들지 않고 어떻게 그렇게 할 수 있을까요?

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

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

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

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

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

가상화를 통해 동일한 하드웨어에서 완전히 다른 두 OS를 실행할 수 있습니다.각 게스트 OS는 부트스트래핑, 커널 로드 등의 모든 프로세스를 거칩니다.보안이 매우 철저할 수 있습니다.예를 들어 게스트 OS가 호스트 OS나 다른 게스트에 완전히 액세스할 수 없어 상황이 엉망이 됩니다.

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

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

컨테이너와 VM의 한계는 분명합니다. VM과 같은 컨테이너에서 완전히 다른 OS를 실행할 수는 없지만 동일한 커널을 공유하기 때문에 서로 다른 Linux 디스트리뷰터를 실행할 수 있습니다.분리 수준은 VM만큼 강력하지 않습니다.실제로 초기 구현에서는 "게스트" 컨테이너가 호스트를 인계하는 방법이 있었습니다.또한 새 컨테이너를 로드할 때 전체 새 OS 복사본이 VM에서 시작되는 것처럼 시작되지 않음을 알 수 있습니다.모든 컨테이너는 동일한 커널을 공유합니다.이것이 용기가 가벼운 이유입니다.또한 VM과 달리 OS의 새 복사본을 실행하지 않기 때문에 상당한 양의 메모리를 컨테이너에 사전 할당할 필요가 없습니다.따라서 한 OS에서 수천 개의 컨테이너를 실행하는 동시에 샌드박스를 만들 수 있습니다. 이는 자체 VM에서 별도의 OS 복사본을 실행하는 경우에는 불가능할 수 있습니다.

좋은 답변.컨테이너와 VM의 이미지 표현을 보려면 아래의 이미지를 확인하십시오.

원천

켄 코크레인의 대답이 마음에 듭니다.

하지만 여기서 자세히 다루지 않는 추가적인 관점을 추가하고 싶습니다.내 생각에 도커는 전체 과정에서도 다릅니다.VM과 달리 Docker는 하드웨어의 최적 리소스 공유에 관한 것만이 아닙니다. 더욱이 애플리케이션 패키징을 위한 "시스템"을 제공합니다(마이크로 서비스 집합으로 필수는 아니지만 선호).

RPM, Debian 패키지, Maven, npm + Git와 같은 개발자 지향 툴과 Puppet, VMware, Xen과 같은 운영 툴 사이의 간극에 딱 들어맞습니다.

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

질문은 일관된 운영 환경을 가정한 것입니다.하지만 어떻게 하면 일관성을 유지할 수 있을까요?파이프라인의 단계인 서버 및 애플리케이션의 양(>10)을 고려합니다.

이러한 동기화를 유지하려면 Puppet, Chef 또는 자체 프로비저닝 스크립트, 게시되지 않은 규칙 및/또는 많은 문서를 사용해야 합니다.이론적으로 서버는 무제한으로 실행될 수 있으며 완전히 일관되고 최신 상태로 유지됩니다.연습은 서버의 구성을 완전히 관리하지 못하므로, 구성 드리프트 및 실행 중인 서버에 예상치 못한 변경 사항이 발생할 수 있는 상당한 범위가 있습니다.

따라서 이를 방지하기 위한 알려진 패턴, 이른바 불변 서버가 있습니다.그러나 불변의 서버 패턴은 사랑받지 못했습니다.대부분 도커 이전에 사용된 VM의 제한 때문입니다.몇 기가바이트의 큰 이미지를 처리하고, 애플리케이션의 일부 필드를 변경하기 위해 큰 이미지를 이동하는 것은 매우 힘든 일이었습니다.이해할 수 있는...

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

마지막으로 Linux 노트북에서도 복잡한 운영 환경을 재현할 수 있습니다(이 경우 작동하지 않으면 전화하지 마십시오 ;).

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

추신: 한편 Docker는 LXC 대신 자체 구현 "libcontainer"를 사용합니다.하지만 LXC는 여전히 사용 가능합니다.

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

다른 가상화와 어떻게 다른지 알아보기 위해 가상화와 가상화 유형을 살펴보겠습니다.그렇다면, 그곳의 차이점이 무엇인지 이해하는 것이 더 쉬울 것입니다.

가상화

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

하이퍼바이저

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

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

가상화 유형

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

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

에뮬레이션

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

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

반가상화

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

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

컨테이너 기반 가상화

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

컨테이너의 개념은 리눅스 커널 버전 2.6.24에 추가된 네임스페이스 기능을 통해 가능합니다.컨테이너는 모든 프로세스에 ID를 추가하고 모든 시스템 호출에 새로운 액세스 제어 검사를 추가합니다.이전 글로벌 네임스페이스의 별도 인스턴스를 만들 수 있는 clone() 시스템 호출을 통해 액세스할 수 있습니다.

네임스페이스는 여러 가지 방법으로 사용할 수 있지만, 가장 일반적인 방법은 컨테이너 외부의 개체를 표시하거나 액세스할 수 없는 격리된 컨테이너를 만드는 것입니다.컨테이너 내부에서 실행 중인 프로세스는 다른 종류의 개체와 마찬가지로 다른 네임스페이스에 위치한 프로세스와 기본 커널을 공유하지만 일반 Linux 시스템에서 실행 중인 것으로 보입니다.예를 들어 네임스페이스를 사용할 때 컨테이너 내부의 루트 사용자는 컨테이너 외부의 루트로 취급되지 않으므로 보안이 강화됩니다.

컨테이너 기반 가상화를 지원하는 다음 주요 구성 요소인 리눅스 제어 그룹(cgroups) 하위 시스템은 프로세스를 그룹화하고 프로세스의 총 리소스 사용량을 관리하는 데 사용됩니다.일반적으로 컨테이너의 메모리 및 CPU 소비를 제한하는 데 사용됩니다.컨테이너화된 Linux 시스템은 하나의 커널만 가지고 있고 커널은 컨테이너에 대한 완전한 가시성을 가지고 있기 때문에 리소스 할당 및 스케줄링 수준은 하나뿐입니다.

LXC, LXD, systemd-nspawn, lmctfy, Warden, Linux-V서버, OpenVZ, Docker 등과 같은 Linux 컨테이너에 대한 여러 관리 툴을 사용할 수 있습니다.

컨테이너 대 가상 시스템

가상 시스템과 달리 컨테이너는 운영 체제 커널을 부팅할 필요가 없으므로 1초 이내에 컨테이너를 생성할 수 있습니다.이 기능은 컨테이너 기반 가상화를 다른 가상화 접근 방식보다 고유하고 바람직한 것으로 만듭니다.

컨테이너 기반 가상화는 호스트 시스템에 오버헤드를 거의 또는 전혀 추가하지 않으므로, 컨테이너 기반 가상화는 기본 성능에 가깝습니다.

컨테이너 기반 가상화의 경우 다른 가상화와 달리 추가 소프트웨어가 필요하지 않습니다.

호스트 시스템의 모든 컨테이너는 호스트 시스템의 스케줄러를 공유하며 추가 리소스가 필요합니다.

컨테이너 상태(Docker 또는 LXC 이미지)는 가상 시스템 이미지에 비해 크기가 작으므로 컨테이너 이미지를 쉽게 배포할 수 있습니다.

컨테이너의 자원 관리는 cgroups를 통해 이루어집니다.그룹은 컨테이너가 할당된 것보다 더 많은 리소스를 사용하도록 허용하지 않습니다.그러나 현재 호스트 시스템의 모든 리소스는 가상 시스템에 표시되지만 사용할 수 없습니다.은 실하면이실수있다습니현할를행▁running를 실행함으로써 될 수 .top또는htop컨테이너와 호스트 시스템에서 동시에.모든 환경에서 출력이 유사하게 표시됩니다.

업데이트:

도커는 Linux가 아닌 시스템에서 컨테이너를 어떻게 실행합니까?

리눅스 커널에서 사용할 수 있는 기능 때문에 컨테이너가 가능한 경우, 분명한 문제는 비 리눅스 시스템이 컨테이너를 어떻게 실행하느냐 하는 것입니다.Mac용 도커와 윈도우즈는 모두 Linux VM을 사용하여 컨테이너를 실행합니다.Virtual Box VM에서 컨테이너를 실행하는 데 사용되는 Docker Toolbox입니다. 그러나 최신 Docker는 Windows에서는 Hyper-V를 사용하고 Mac에서는 Hypervisor.framework를 사용합니다.

이제 Mac용 도커가 컨테이너를 어떻게 실행하는지 자세히 설명하겠습니다.

Mac용 Docker는 https://github.com/moby/hyperkit 을 사용하여 하이퍼바이저 기능을 에뮬레이트하고 Hyperkit는 코어에서 hypervisor.dll을 사용합니다.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.dll 파일을 참조하십시오. 는 노출을 하지 docker0Mac의 네트워크 인터페이스입니다.따라서 호스트에서 컨테이너에 액세스할 수 없습니다.지금으로선docker0VM 내에서만 사용할 수 있습니다.

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

여기서는 대부분의 답변이 가상 시스템에 대해 설명합니다.저는 도커를 사용한 지난 몇 년 동안 제게 가장 큰 도움이 되었던 이 질문에 대해 한 줄로 답변을 드리겠습니다.다음과 같습니다.

도커는 가상 머신이 아닌 프로세스를 실행하는 멋진 방법일 뿐입니다.

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

도커 컨테이너는 나머지 프로세스에서 호스트 시스템 커널 내부의 cgroup을 사용하여 구획화된 프로세스(및 하위 프로세스)일 뿐입니다.다음을 실행하여 도커 컨테이너 프로세스를 실제로 확인할 수 있습니다.ps aux를 들어 예: 시를 합니다.apache2"container"는 "in a container"로 막 apache2호스트에 대한 특수 프로세스입니다.그것은 기계의 다른 프로세스들과 구분되어 있습니다.컨테이너는 컨테이너화된 프로세스의 수명을 초과하여 존재하지 않습니다.프로세스가 중단되면 용기도 중단됩니다.가 그것도대때문다니입기체하커가은▁dock다때를 대체하기 때문입니다.pid 1.pid 1일반적으로 init 시스템)입니다.다음에 대한 마지막 요점입니다.pid 1매우 중요합니다.

이러한 각 컨테이너 프로세스에서 사용되는 파일 시스템에 대해서는 Docker는 UnionFS 지원 이미지를 사용합니다. 이 이미지는 다음 작업을 수행할 때 다운로드하는 것입니다.docker pull ubuntu각 "이미지"는 일련의 레이어 및 관련 메타데이터일 뿐입니다.계층화의 개념은 여기서 매우 중요합니다.각각의 층은 그 아래의 층으로부터 단지 변화한 것입니다.예를 들어 Docker 컨테이너를 작성하는 동안 Docker 파일의 파일을 삭제하면 실제로 마지막 레이어 위에 "이 파일이 삭제되었습니다."라는 레이어가 생성됩니다.참고로 파일 시스템에서 큰 파일을 삭제할 수 있지만 이미지는 여전히 동일한 디스크 공간을 차지합니다.파일은 여전히 현재 파일 아래의 레이어에 있습니다.계층 자체는 파일의 타르볼에 불과합니다.이 테스트는 다음을 사용하여 수행할 수 있습니다.docker save --output /tmp/ubuntu.tar ubuntu그리고 나서.cd /tmp && tar xvf ubuntu.tar그러면 당신은 주위를 둘러볼 수 있습니다.긴 해시처럼 보이는 모든 디렉터리는 실제로 개별 계층입니다.의 파일은파일을 합니다.layer.tar및 메타데이터json를 포함합니다. 특정 계층에 대한 정보를 포함합니다.이러한 계층은 원래 상태의 "위에" 계층으로 저장되는 파일 시스템의 변경 사항을 설명할 뿐입니다.파일 시스템은 "현재" 데이터를 읽을 때 맨 위의 변경 사항 계층만 보는 것처럼 데이터를 읽습니다.파일 시스템이 최상위 계층만 보기 때문에 파일이 "이전" 계층에 여전히 존재함에도 불구하고 삭제된 것처럼 보이는 이유입니다.이렇게 하면 각 컨테이너의 최상위 계층에 있는 파일 시스템에 몇 가지 중요한 변경 사항이 발생했을 수도 있지만 완전히 다른 컨테이너가 파일 시스템 계층을 공유할 수 있습니다.이렇게 하면 컨테이너가 기본 이미지 계층을 공유할 때 디스크 공간을 크게 절약할 수 있습니다.그러나 볼륨을 통해 호스트 시스템의 디렉토리와 파일을 컨테이너에 마운트하면 해당 볼륨이 UnionFS를 "바이패스"하므로 변경 사항이 계층에 저장되지 않습니다.

브리지(" Bridge"라고 함)를.docker0호스트) 및 호스트의 모든 컨테이너에 대한 가상 인터페이스입니다.은 서생다니성합가상에 .docker0컨테이너가 서로 "간" 통신할 수 있습니다.여기에는 컨테이너에 대한 사용자 지정 서브넷 생성, 컨테이너가 직접 액세스할 수 있도록 호스트의 네트워킹 스택을 "공유"하는 기능 등 네트워킹에 대한 다양한 옵션이 있습니다.

도커는 매우 빠르게 움직이고 있습니다.그것의 문서는 제가 본 문서 중 가장 좋은 것입니다.그것은 일반적으로 잘 쓰여지고 간결하며 정확합니다.자세한 내용은 사용 가능한 설명서를 확인하고 스택 오버플로를 포함하여 온라인에서 읽은 다른 모든 문서보다 설명서를 신뢰하는 것이 좋습니다.구체적인 질문이 있다면, 참여하는 것을 강력히 추천합니다.#dockerFreenode IRC에서 질문합니다(Freenode의 웹챗을 사용할 수도 있습니다!).

이 게시물을 통해 VM과 LXC 간의 차이점을 몇 가지 설명할 예정입니다.먼저 정의해 보겠습니다.

VM:

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

이 경우 VM을 게스트라고 하고 VM이 실행되는 환경을 호스트라고 합니다.

LXC:

리눅스 컨테이너(LXC)는 하나의 제어 호스트(LXC 호스트)에서 여러 개의 분리된 리눅스 컨테이너를 실행할 수 있도록 하는 운영 체제 수준 기능입니다.리눅스 컨테이너는 하이퍼바이저 viz가 필요하지 않기 때문에 VM을 대신할 수 있습니다.Virtualbox, KVM, Xen 등.

이제 여러분이 앨런(행오버 시리즈의 잭 갈리피아나키스)에게 약을 먹고 지난 1년 동안 라스베이거스에 있지 않았다면 리눅스 컨테이너 기술에 대한 엄청난 관심에 대해 잘 알고 있을 것입니다.지난 몇 달 동안 전 세계적으로 화제가 된 컨테이너 프로젝트 중 하나를 구체적으로 말씀드리자면, Docker는 클라우드 컴퓨팅 환경에서 가상 머신(VM)을 포기하고 더 낮은 오버헤드와 잠재적으로 더 나은 성능을 제공하기 위해 컨테이너로 대체해야 한다는 의견을 제시했습니다.

하지만 큰 문제는, 실현 가능성이 있는가 하는 것입니다. 과연 합리적일까요?

LXC는 Linux 인스턴스로 범위가 지정됩니다.다른 Linux 버전일 수 있습니다(예: Cent의 Ubuntu 컨테이너).OS 호스트이지만 여전히 Linux입니다.)마찬가지로 윈도우즈 기반 컨테이너는 현재 윈도우즈 인스턴스로 범위가 지정되어 있습니다. VM의 범위는 상당히 넓으며 하이퍼바이저를 사용하면 운영 체제인 Linux 또는 윈도우즈에 국한되지 않습니다.

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

따라서 클라우드 인프라 공급업체는 VM 및 LXC가 특정 워크로드 및 시나리오를 처리하는 데 적합하므로 이를 적절히 사용할 것을 권장해야 합니다.

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

도커는 모든 종속성을 가진 응용프로그램을 캡슐화합니다.

버추얼라이저는 베어메탈 시스템에서 일반적으로 실행할 수 있는 모든 애플리케이션을 실행할 수 있는 OS를 캡슐화합니다.

그들은 둘 다 매우 다릅니다.Docker는 경량이며 LXC/lib 컨테이너(커널 네임스페이스 및 cgroup에 의존)를 사용하며 하이퍼바이저, KVM. Xen과 같은 시스템/하드웨어 에뮬레이션이 없습니다.

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

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

이것은 기본 이미지가 일반적으로 읽기 전용이며 컨테이너가 계층에서 무언가를 수정할 때만 읽기-쓰기 파티션(예: 쓰기 시 복사)에 무언가를 쓸 수 있는 강력한 기능입니다.또한 레지스트리 및 이미지 버전 지정과 같은 많은 다른 래퍼를 제공합니다.

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

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

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

다음은 도커/우량 척도의 사진입니다.

라이트급

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

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

둘째, 도커 컨테이너는 몇 밀리초 안에 시작할 수 있고 VM은 몇 초 안에 시작할 수 있습니다.

계층화된 파일 시스템

이것은 도커의 또 다른 주요 기능입니다.이미지에는 레이어가 있으며 서로 다른 이미지는 레이어를 공유할 수 있으므로 공간을 훨씬 더 절약하고 빠르게 빌드할 수 있습니다.

모든 컨테이너가 Ubuntu를 기본 이미지로 사용하는 경우 모든 이미지에 고유한 파일 시스템이 있는 것은 아니지만 동일한 밑줄 Ubuntu 파일을 공유하며 고유한 응용 프로그램 데이터만 다릅니다.

공유 OS 커널

컨테이너를 프로세스로 생각하세요!

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

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

왜 그게 중요합니까?

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

애플리케이션 배포에 대해 생각해 보십시오.새 소프트웨어(서비스)를 배포하거나 업그레이드하려면 새 VM을 생성하는 대신 구성 파일 및 프로세스를 변경하는 것이 좋습니다.업데이트된 서비스를 사용하여 VM을 생성하고 테스트(개발 및 QA 간 공유)하기 때문에 운영 환경에 구축하는 데 몇 시간 또는 며칠이 걸립니다.뭔가 잘못되면 다시 시작해서 시간을 더 낭비해야 합니다.따라서 구성 관리 도구(퍼펫, 솔트스택, 셰프 등)를 사용하여 새 소프트웨어를 설치하고 새 파일을 다운로드하는 것이 좋습니다.

도커와 관련하여, 기존 도커 컨테이너를 대체하기 위해 새로 만든 도커 컨테이너를 사용하는 것은 불가능합니다.유지보수가 훨씬 쉽습니다!새로운 이미지를 구축하고, QA와 공유하고, 테스트하고, 구축하는 데는 최악의 경우 몇 분(모든 것이 자동화된 경우)밖에 걸리지 않습니다.이를 불변 인프라라고 합니다. 소프트웨어를 유지보수(업그레이드)하지 않고 대신 새 인프라를 만듭니다.

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

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

Docker에서 실행 중인 컨테이너는 호스트 OS 커널을 공유하지만 VM에서는 자체 OS 파일을 가집니다.애플리케이션을 개발하는 환경(OS)은 "테스트" 또는 "운영"과 같은 다양한 서비스 환경에 배포할 때와 동일합니다.

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

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

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

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

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

기존 서버 스택은 운영 체제와 응용프로그램을 실행하는 물리적 서버로 구성됩니다.

장점:

• 원시 리소스 활용

• 격리

단점:

• 배포 시간이 매우 느림
• 비싼.
• 리소스 낭비
• 확장이 어려움
• 마이그레이션이 어려움
• 복잡한 구성

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

장점:

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

단점:

• 리소스 할당에 문제가 있습니다.
• 공급업체 잠금
• 복잡한 구성

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

장점:

• 격리
• 라이트급
• 리소스 유효성
• 간편한 마이그레이션
• 보안.
• 낮은 오버헤드
• 생산 및 개발 환경 미러링

단점:

• 동일한 아키텍처
• 리소스를 많이 사용하는 경우
• 네트워킹 및 보안 문제.

컨테이너 설정을 이전 버전과 비교하여 컨테이너 설정이 현재까지 알려진 설정 중 가장 빠르고 리소스 효율적이며 가장 안전하다는 결론을 내릴 수 있습니다.컨테이너는 응용프로그램을 실행하는 격리된 인스턴스입니다.도커는 컨테이너를 스핀업하고, 레이어는 몇 초 이내에 실행되는 기본 스토리지 드라이버(오버레이 드라이버)를 사용하여 런타임 메모리를 얻고, 컨테이너에 커밋하면 그 위에 작성된 쓰기 시 복사 계층을 사용하여 컨테이너를 실행할 수 있습니다.VM이 가상화 환경에 모든 것을 로드하는 데 1분 정도 소요되는 경우이러한 경량 인스턴스는 쉽게 교체, 재구축 및 이동할 수 있습니다.이를 통해 생산 및 개발 환경을 미러링할 수 있으며 CI/CD 프로세스에 큰 도움이 됩니다.컨테이너가 제공할 수 있는 이점은 매우 강력하기 때문에 그들은 분명히 여기에 있습니다.

다음과 관련하여

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

대부분의 소프트웨어는 여러 환경에 배포됩니다. 일반적으로 다음 중 최소 3개가 해당됩니다.

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

고려해야 할 요소는 다음과 같습니다.

• 개발자와 실제로 테스터는 작업의 특성상 PC 구성이 미묘하거나 크게 다를 것입니다.
• 개발자들은 종종 기업 또는 비즈니스 표준화 규칙의 통제를 벗어나 PC에서 개발할 수 있습니다(예: 자신의 기계(종종 원격)로 개발하는 프리랜서 또는 특정 방식으로 PC를 구성하도록 '고용'되거나 '계약'되지 않은 오픈 소스 프로젝트의 기여자).
• 일부 환경은 로드 밸런싱 구성에서 고정된 수의 여러 시스템으로 구성됩니다.
• 많은 운영 환경에서 트래픽 수준에 따라 동적으로(또는 '탄력적으로') 생성 및 폐기되는 클라우드 기반 서버가 있음

조직의 총 서버 수 추정치는 단일 숫자로 표시되는 경우가 드물고, 3배 숫자로 표시되는 경우가 매우 많으며, 훨씬 더 많을 수도 있습니다.

이 모든 것은 처음부터 일관성 있는 환경을 만드는 것이 단순히 볼륨만으로 충분히 어렵다는 것을 의미하지만(그린필드 시나리오에서도), 서버 수가 많고 새로운 서버 추가(동적 또는 수동적), OS 공급업체, 안티바이러스 공급업체, 브라우저 v의 자동 업데이트를 고려할 때 일관성을 유지하는 것은 거의 불가능합니다.개발자 또는 서버 기술자 등이 수행하는 수동 소프트웨어 설치 또는 구성 변경 등을 승인합니다.다시 한 번 말씀드리지만, 환경의 일관성을 유지하는 것은 사실상 불가능합니다(순수주의자의 경우 가능하지만 엄청난 시간과 노력, 규율이 필요합니다). 그렇기 때문에 VM과 컨테이너(예: Docker)가 애초에 고안된 것입니다.

따라서 "모든 환경을 일관성 있게 유지하는 것이 매우 어렵다는 점을 감안할 때 학습 곡선을 고려하더라도 도커 이미지에 소프트웨어를 배포하는 것이 더 쉽습니까?"와 같은 질문을 생각해 보십시오.답은 변함없이 "예"가 될 것이라고 생각합니다. 하지만 확인할 수 있는 방법은 단 한 가지입니다. 스택 오버플로에 이 새로운 질문을 게시하십시오.

차이점에 대해 더 자세히 설명하는 많은 답변이 있지만, 여기 저의 매우 간단한 설명이 있습니다.

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

도커에서는 컨테이너가 호스트와 커널을 공유하므로 커널이 가볍고 빠르게 시작 및 중지할 수 있습니다.

가상화에서 리소스는 설정 초기에 할당되므로 대부분의 경우 가상 시스템이 유휴 상태일 때 리소스가 완전히 활용되지 않습니다.도커에서 컨테이너는 고정된 양의 하드웨어 리소스로 할당되지 않으며 요구 사항에 따라 리소스를 자유롭게 사용할 수 있으므로 확장성이 높습니다.

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

가상 머신을 사용하면 서버와 해당 서버에 호스트 운영 체제가 있고 하이퍼바이저가 있습니다.그런 다음 하이퍼바이저 위에서 실행하면 애플리케이션 및 종속 바이너리가 있는 게스트 운영 체제와 해당 서버의 라이브러리가 얼마든지 있습니다.게스트 운영 체제 전체가 함께 제공됩니다.무게가 꽤 나가요.또한 각 물리적 시스템에 실제로 설치할 수 있는 용량에는 제한이 있습니다.

반면 도커 컨테이너는 약간 다릅니다.서버가 있습니다.호스트 운영 체제가 있습니다.하지만 하이퍼바이저 대신 도커 엔진이 있습니다.이 경우 게스트 운영 체제 전체를 함께 제공하지 않습니다.우리는 운영 체제의 매우 얇은 계층을 가져오고 있으며, 컨테이너는 커널 기능을 이용하기 위해 호스트 OS로 대화할 수 있습니다.그리고 그것은 우리가 매우 가벼운 용기를 가질 수 있게 해줍니다.

안에 있는 것은 응용 프로그램 코드와 필요한 이진 파일 및 라이브러리뿐입니다.이러한 바이너리와 라이브러리는 서로 다른 컨테이너에서 공유할 수 있습니다.그리고 이것이 우리가 할 수 있게 해주는 것은, 많은 것들입니다.시작 시간이 훨씬 빠릅니다.단 몇 초 만에 단일 VM을 구축할 수는 없습니다.그리고 마찬가지로, 그들을 빨리 무너뜨리는 것.따라서 매우 빠르게 스케일업 및 스케일다운할 수 있으며 나중에 살펴보겠습니다.

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

출처: 행동 중인 쿠베르네테스.

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

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

도커 컨테이너는 격리된 환경입니다.다음을 발행하면 볼 수 있습니다.top도커 이미지에서 생성된 도커 컨테이너의 명령입니다.

그 외에도 도커 파일 구성 덕분에 매우 가볍고 유연합니다.

예를 들어 Docker 이미지를 생성하고 Docker 파일을 구성한 후 실행 중인 경우 wget 'this', apt-get 'that', some shell script 실행, 환경 변수 설정 등을 알릴 수 있습니다.

마이크로 서비스 프로젝트 및 아키텍처에서 도커는 매우 실행 가능한 자산입니다.도커, 도커 스웜, 쿠버네티스 및 도커 컴포지트를 통해 확장성, 복원력 및 탄력성을 달성할 수 있습니다.

도커와 관련된 또 다른 중요한 문제는 도커 허브와 그 커뮤니티입니다.예를 들어, 저는 Prometeus, Grafana, Prometeus-JMX-Exporter, Docker를 사용하여 카프카를 모니터링하는 생태계를 구현했습니다.

이를 위해, 저는 사육사, 카프카, 프로메테우스, 그라파나, jmx-collector를 위해 구성된 도커 컨테이너를 다운로드한 다음, 일부는 YAML 파일을 사용하거나 다른 것들을 위해 구성을 마운트했습니다.Docker 컨테이너의 일부 파일과 구성을 변경하고 단일 시스템에서 다중 컨테이너 Docker를 사용하여 카프카를 모니터링하기 위한 전체 시스템을 구축했습니다. 이 아키텍처를 여러 서버로 쉽게 이동할 수 있는 격리, 확장성 및 복원력을 제공합니다.

Docker Hub 사이트 외에도 quay.io 이라는 다른 사이트가 있습니다. 이 사이트를 사용하여 Docker 이미지 대시보드를 해당 대시보드로 이동하거나 이동할 수 있습니다.도커 허브에서 도커 이미지를 가져와 자체 시스템의 부두에서 실행할 수도 있습니다.

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

저는 도커와 처음 작업할 때 잘못된 명령을 내리거나 컨테이너와 모든 데이터 및 구성을 실수로 제거했던 것을 기억합니다.

도커는 다음과 같이 자신을 소개합니다.

Docker는 컨테이너 이동을 주도하는 회사이자 하이브리드 클라우드 전반의 모든 애플리케이션을 처리하는 유일한 컨테이너 플랫폼 공급자입니다.오늘날의 기업은 디지털로 전환해야 하는 압박을 받고 있지만 기존 애플리케이션과 인프라에 의해 제약을 받는 동시에 점점 더 다양해지는 클라우드, 데이터 센터 및 애플리케이션 아키텍처 포트폴리오를 합리화하고 있습니다.Docker는 애플리케이션과 인프라 간의 진정한 독립성을 실현하고 개발자와 IT 운영진이 잠재력을 발휘할 수 있도록 지원하며 더 나은 협업과 혁신을 위한 모델을 구축합니다.

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

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

그럼, 용기란 무엇입니까?

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

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

여기에는 VM과 컨테이너의 차이점과 도커의 기원에 대해 명확하게 설명하는 훌륭한 기술적 답변이 많이 있습니다.

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

VM을 사용하면 애플리케이션과 애플리케이션의 종속성을 한 VM에서 다음 DEV, UAT, PRD로 승격할 수 있습니다.

1. 종종 이러한 VM에는 서로 다른 패치와 라이브러리가 있습니다.
2. 여러 애플리케이션이 VM을 공유하는 경우는 드물지 않습니다.이를 위해서는 모든 응용프로그램에 대한 구성 및 종속성을 관리해야 합니다.
3. 백업을 수행하려면 VM의 변경 내용을 실행 취소해야 합니다.또는 가능하면 복원합니다.

Docker를 사용하면 응용 프로그램을 필요한 라이브러리와 함께 자체 컨테이너 안에 묶은 다음 전체 컨테이너를 단일 단위로 승격할 수 있습니다.

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

VM의 가장 기본적인 수준에서는 애플리케이션과 애플리케이션의 종속성을 별개의 구성 요소로 홍보하는 반면, Docker의 경우 한 번에 모든 것을 홍보합니다.

그리고 쿠버네티스나 도커 스웜과 같은 도구가 작업을 크게 단순화시키긴 하지만 컨테이너 관리를 포함한 문제가 있습니다.

Feature	Virtual Machine	(Docker) Containers
OS	각 VM에 다음이 포함됩니다.Operating System	각 도커 컨테이너에는 다음이 포함되지 않습니다.Operating System
H/W	각 VM에는 OS가 실행해야 하는 하드웨어의 가상 복사본이 포함되어 있습니다.	컨테이너를 사용한 H/W 가상화는 없습니다.
체중	VM이 무겁습니다. 위에 언급된 이유는 --	컨테이너는 가볍기 때문에 빠릅니다.
필수 S/W	하이퍼바이저라는 소프트웨어를 사용하여 가상화 실현	도커라고 하는 소프트웨어를 사용하여 컨테이너화를 달성합니다.
코어	가상 시스템은 가상 하드웨어(또는 운영 체제 및 기타 프로그램을 설치할 수 있는 하드웨어)를 제공합니다.	도커 컨테이너는 하드웨어 가상화를 사용하지 않습니다.**용기 사용에 도움이 됩니다.
추상화	가상 시스템은 여러 운영 체제를 실행할 수 있도록 하드웨어 추상화를 제공합니다.	컨테이너는 OS 추상화를 제공하므로 여러 컨테이너를 실행할 수 있습니다.
부팅 시간	사용할 소프트웨어 외에도 전체 운영 체제를 실행하기 때문에 상당한 리소스 오버헤드를 생성하는 데 오랜 시간(종종 몇 분)이 걸리고 필요합니다.	Docker 컨테이너 내부에서 실행되는 프로그램은 호스트의 Linux 커널과 직접 연결되기 때문에 시간이 더 적게 걸립니다.

컨테이너는 라이브러리와 소프트웨어 패키지를 시스템에서 분리하여 동일한 소프트웨어 및 라이브러리의 다른 버전을 충돌 없이 설치할 수 있도록 합니다.유휴 상태일 때는 최소한의 스토리지와 RAM을 사용하며, 동일한 기본 운영 체제 커널 및 가능한 경우 델타 차이가 작은 사용 가능한 라이브러리를 사용하여 오버헤드가 거의 없습니다.계산에 GPU와 같은 가속을 사용할 수 있도록 하드웨어를 컨테이너에 직접 또는 간접적으로 노출할 수 있습니다.

실제로 사전 제작된 컨테이너에는 도커를 사용합니다.설치하고 한 줄로 실행합니다.텐서플로-gpu를 설치하는 것은 매우 쉽습니다.docker run -it tensorflow-gpu많은 사전 제작된 lxd(lxc 컨테이너) 컨테이너를 발견하지는 못했지만, 사용자 지정이 더 쉽고 안정적이며 성능이 우수합니다.

컨테이너와 VM을 모두 사용하여 로드를 분산할 수 있습니다.그러나 컨테이너에는 오버헤드가 거의 없기 때문에 컨테이너 관리 소프트웨어는 컨테이너 클러스터를 생성하는 데 초점을 맞추고 있으므로 부하를 금속 기계에 쉽게 분산시킬 수 있습니다.

실생활의 예:

50개 이상의 컴퓨팅 환경과 mysql, 웹 호스팅 및 클라우드 기반 서비스(Jenkins 및 객체 스토리지)와 같은 50개 이상의 서비스가 필요하고 50개 이상의 다양한 베어메탈 서버가 있다고 가정합니다.전형적으로 그것은 많은 능력을 가진 학문적 환경입니다.또한 리소스를 효율적으로 사용하고 고가용성이 필요합니다.서버 하나가 다운될 때 사용자는 문제를 겪지 않아야 합니다.이 문제를 해결하기 위해 기본적으로 모든 유형의 컨테이너를 모든 서버에 설치합니다.그리고 모든 금속 기계에 하중을 분배합니다.한 가지 유형의 용기가 더 많이 필요하므로 하나 이상의 베어 메탈 기계에서 더 많은 용기를 자동으로 생성할 수 있습니다.다양한 사용자가 다양한 서비스와 환경을 지속적이고 유연하게 사용할 수 있도록 지원합니다.

이 설정에서 100명의 학생이 동시에 시스템을 사용한다고 가정합니다.그 중 95개는 학점, 교육과정, 도서관 데이터베이스 등 기본적인 서비스를 위해 서버를 사용하고 있습니다.하지만 그 중 5개는 5가지 유형의 엔지니어링 시뮬레이션을 수행하고 있습니다.49개의 베어 메탈 서버가 엔지니어링 시뮬레이션 전용으로 완전히 구성되어 있으며, 각각 5개의 서로 다른 유형의 컴퓨팅 컨테이너가 경합을 벌이고 있지만 리소스 사용량은 %20hw로 균형을 이루고 있음을 알 수 있습니다.기본적인 작업을 위해 2500명의 학생을 추가하면 두 학생 중 하나가 모든 베어메탈 기계의 %5을 사용합니다.나머지는 계산에 사용됩니다.

따라서 이러한 유연성 이점을 제공하는 컨테이너의 가장 중요한 구별되는 특징은 다음과 같습니다.

서로 다른 버전의 동일한 소프트웨어 및 라이브러리를 충돌 없이 사용할 수 있으며, 사전 제작된 컨테이너를 배포할 준비가 되어 있으며, 오버헤드가 거의 없고 실시간으로 조정 가능한 할당량을 통해 빠른 생성 가능성이 있습니다.

.cpu_allowence, .ram_allowances 또는 직접 cgroup을 사용합니다.쿠버네티스는 이 모든 걸 당신을 위해 합니다.도커와 lxd를 만지작거린 후에 당신은 그것을 확인해 보는 것이 좋을 것입니다.

가상 시스템이 하드웨어 수준 에뮬레이션에 의존하는 방식에 대해 이미 잘 알고 있을 것입니다.

그러나 Docker 컨테이너는 호스트 운영 체제에서 정기적인 프로세스로 실행되며 네임스페이스와 같은 분리 기능을 제공하는 Linux 커널 기능에 의존합니다.원하는 경우 "컨테이너"와 별도로 네임스페이스를 사용할 수 있으며, 이 모든 것이 어떻게 조화되는지 이해하는 데 도움이 될 수 있습니다.다음은 목록입니다.

• 프로세스 네임스페이스: PID 네임스페이스의 프로세스에는 동일한 네임스페이스의 프로세스만 표시됩니다.따라서 실질적으로 프로세스 네임스페이스에서 bash 셸을 실행하고 있고 "ps -a"를 수행하는 경우 커널은 동일한 네임스페이스의 프로세스만 표시합니다.특히 흥미로운 점은 도커 호스트 시스템에서 커널이 네임스페이스 외부에서 사용자를 제한하지 않기 때문에 "ps-a"를 수행하여 모든 컨테이너 프로세스를 볼 수 있다는 것입니다. 이는 가시성이 제한된 일반 프로세스일 뿐입니다.
• 네트워크 네임스페이스: 네트워크 네임스페이스에는 전체 Linux 네트워크 스택의 고유한 분리된 인스턴스가 있습니다.인터페이스, iptable 규칙, 라우팅 테이블 등을 생각해 보십시오.실제로 네트워크 네임스페이스는 외부와 완전히 단절되기 시작하고 도커는 일부 network-fu를 위에 추가하여 컨테이너에 호스트 네트워크 연결에 대한 NAT 액세스 권한을 부여합니다.
• IPC 네임스페이스: 여기서는 별로 할 말이 없습니다. PID 네임스페이스와 함께 사용됩니다.
• Mount Namespace: 이것은 도커가 컨테이너에 자체 파일 시스템을 제공하는 방법입니다.마운트 네임스페이스 내에서 도커는 파일의 전체 파일 시스템을 루트에 마운트합니다.네임스페이스의 멤버인 프로세스만 이를 볼 수 있습니다.다른 답변에서는 도커가 UnionFS를 사용하는 방법의 영리함을 설명했으므로 여기서는 자세히 설명하지 않겠습니다(편집:하단 섹션에서 이것이 도커를 경량화하는 데 어떻게 도움이 되는지 자세히 설명하기로 결정했습니다.)
• 사용자 네임스페이스: 사용자 네임스페이스는 도커 컨테이너가 시스템의 나머지 부분에 영향을 미치지 않고 전용 사용자를 가질 수 있도록 해줍니다.(이러한 사용자는 여전히 UID/GID를 가지고 있으므로 컨테이너에서 파일을 꺼낼 때 생성한 파일은 UID/GID에 의해 소유되며 컨테이너의 루트 내부에서는 사용자가 컨테이너에 마운트한 모든 파일을 수정할 수 있으므로 주의가 필요합니다.)
• UTS 네임스페이스: 보아하니 컨테이너는 자체 호스트 이름과 도메인 이름을 가질 수 있습니다. 저는 이것에 대해 자주 생각하지 않습니다.
• 시간 네임스페이스: 컨테이너가 자체 시스템 클럭을 가질 수 있습니다.NTP와 같은 백그라운드 서비스는 컨테이너에서 실행되지 않을 것이기 때문에 도커는 이것을 신경쓰지 않을 것입니다.

컨테이너를 정의할 때 일반적으로 도커 부트스트랩을 컨테이너라고 하는 전용 네임스페이스 집합으로 묶는 단일 루트 프로세스를 정의합니다.도커는 이 상위 프로세스를 컨테이너로 모니터링하고, 도커가 죽으면 컨테이너가 중지된 것으로 간주합니다.이것이 일반적으로 컨테이너 내부에서 백그라운드 서비스를 실행하려고 해서는 안 되는 이유입니다. 도커를 서비스 관리자로 생각하고 앱은 단일 서비스입니다.하위 프로세스는 상위 프로세스와 동일한 네임스페이스에 포함되므로 분리가 유지됩니다."Docker exec"은 실제로 커널이 제공하는 실제 "nsenter" 명령을 사용하여 네임스페이스 내에서 프로그램을 실행할 수 있도록 하는 고급 오케스트레이션입니다.

---

도커는 동일한 커널을 공유하는 것 외에도 경량화를 위해 몇 가지 트릭을 더 사용합니다.

이미지 레이어

먼저, 다른 사람들이 지적했듯이 도커는 계층화된 파일 시스템인 UnionFS를 사용합니다.이전 계층은 읽기 전용이며 현재 계층은 편집 가능하지만 쓰기 시 복사가 가능합니다.따라서 이전 계층에 A 파일이 있고 해당 파일을 수정하면 전체 파일과 수정 사항이 현재 r/w 계층에 저장됩니다.UnionFS는 파일의 최신 복사본만 표시합니다.오래된 문서를 더 이상 사용하지 않는데도 사본을 보관하고 계십니까?그러나 이를 통해 이미지 계층을 트리처럼 구성할 수 있으므로 언제든지 기본 계층의 파일을 복제하지 않고도 공통 기본 이미지에서 수많은 구성을 분기할 수 있습니다.

웹 서버에 대한 도커 이미지를 구축한다고 가정합니다.시작하는 첫 번째 계층은 OS인 경우가 많습니다.OS 개발자들은 일반적으로 OS를 사전 구축하고 단일 이미지 계층으로 분리하기 때문에 한두 개의 계층만 포함된 이미지를 릴리스합니다.Docker 파일에서 각 명령어는 일반적으로 새 계층을 생성하기 때문에 많은 줄이 연속되고 임시 파일이 삭제되는 RUN 명령어를 자주 볼 수 있습니다. 이미지 계층에 남겨둔 모든 것은 새 계층에서 삭제하더라도 영구적으로 유지됩니다.웹 서버 이미지를 작성한 후에는 모든 계층이 읽기 전용이 됩니다.

이제 100개의 웹 서버 컨테이너를 회전시킨다고 가정해 보겠습니다.각 컨테이너에는 자체 편집 가능한 런타임 계층이 있지만, 중요한 것은 컨테이너가 모두 웹 서버 이미지 계층을 공유한다는 것입니다. 따라서 1개 웹 서버의 스토리지 요구량의 100배에 달하는 비용을 들일 필요가 없습니다.실행 중에 컨테이너는 로그 또는 임시 파일과 같은 런타임 아티팩트에 대한 새 저장소 공간만 사용합니다.일반적으로 컨테이너화된 앱은 이러한 컨테이너 계층이 일시적인 것이며 결과 없이 삭제될 수 있도록 설계됩니다.

이 답변의 범위를 벗어나지만, 컨테이너가 단일 컨테이너의 수명(예: 데이터베이스)보다 더 오래 보존되어야 하는 중요한 파일을 만드는 경우 런타임에 "볼륨"을 컨테이너에 마운트합니다.이러한 볼륨은 이미지/데이터 세트 라이프사이클과 별도로 데이터의 안전한 지속성을 제공합니다.

그룹

컨테이너에서 사용할 수 있는 또 다른 커널 기능을 "cgroups" 또는 "control groups"라고 합니다. 이러한 기능을 사용하면 프로세스 그룹에서 사용할 수 있는 하드웨어 리소스를 컨테이너와 같이 제한할 수 있습니다.

기본적으로 도커 컨테이너에는 사용 가능한 모든 RAM 및 CPU 리소스가 있으므로 매우 효율적일 수 있습니다.리소스가 상대적으로 전용인 VM과 달리 컨테이너는 로드에 따라 리소스를 공동으로 공유하면서 서로 나란히 스케일업 및 스케일다운(수직)할 수 있습니다.

그러나 이는 때때로 안전하지 않을 수 있습니다. 애플리케이션에 로드 스파이크가 발생하고 리소스가 너무 많이 소모되며 다른 컨테이너가 부족해질 수 있습니다.이 앱이 악의적이거나 잘못 작성된 앱이 아니라고 가정할 때, 이러한 합법적인 로드 급증을 처리하는 좋은 방법은 클러스터에서 특정 종류 또는 조정 시스템을 사용하여 컨테이너의 새 인스턴스를 동적으로 스핀업하는 것입니다.

Docker가 애플리케이션을 기능에 따라 작은 부분으로 나누기 때문에 Docker에 배포하기로 결정한 이유는 애플리케이션의 요구 사항에서 알 수 있습니다. 한 애플리케이션/기능이 오류일 경우 전체 VM을 사용하는 것과 달리 다른 애플리케이션에 영향을 미치지 않기 때문에 Docker에 배포하기로 결정한 이유는 무엇입니까?구성이 더 복잡하고, 어떤 면에서는 도커보다 더 안전합니다.

도커 설명서(및 자체 설명)에서는 "가상 시스템"과 "컨테이너"를 구분합니다.그들은 약간 특이한 방법으로 사물을 해석하고 사용하는 경향이 있습니다.이는 문서에 무엇을 적느냐에 따라 결정되며 가상화에 대한 용어가 아직 정확하지 않기 때문입니다.

사실 Docker 설명서가 "컨테이너"에 대해 이해하고 있는 것은 반가상화(때로는 "OS 레벨 가상화")이며, 하드웨어 가상화와는 반대로 Docker는 그렇지 않다는 것입니다.

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

이 제품이 인기를 끈 이유는 "일반인에게 불을 지폈기 때문"입니다. 즉, Win10 워크스테이션에서 일반적으로 서버(= Linux) 환경/소프트웨어 제품을 간단하게 사용할 수 있게 되었습니다.이것은 또한 우리가 그들의 작은 " 뉘앙스"를 용인해야 하는 이유입니다.하지만 그것은 우리가 그것을 믿어야 한다는 것을 의미하지 않습니다.

Windows 호스트의 도커가 HyperV에 내장된 Linux를 사용하고 컨테이너가 그 안에서 실행되고 있기 때문에 상황은 더욱 흐리게 됩니다.따라서 윈도우즈의 도커는 하드웨어와 반가상화 솔루션을 결합하여 사용합니다.

간단히 말해서, 도커 컨테이너는 매우 큰 이점과 많은 단점을 가진 저품질(para) 가상 머신입니다.

언급URL : https://stackoverflow.com/questions/16047306/how-is-docker-different-from-a-virtual-machine