Docker란 무엇입니까? 역사와 기본 추상화에 대한 간략한 소개

10월 XNUMX일 Slurm이 시작되었습니다 Docker 비디오 강좌네트워크 매개변수부터 주요 추상화까지 모든 것을 철저히 분석합니다.

이 글에서는 Docker의 역사와 주요 추상화 개념인 Image, CLI, Dockerfile에 대해 알아보겠습니다. 이 강의는 초보자를 대상으로 했기 때문에, 숙련된 사용자에게는 흥미롭지 않을 수 있습니다. 여기서는 피도, 맹장도, 심해 잠수도 없습니다. 아주 기본적인 것부터.

Docker란 무엇인가

위키피디아에서 Docker의 정의를 살펴보겠습니다.

Docker는 컨테이너 기반 환경에서 애플리케이션의 배포와 관리를 자동화하는 소프트웨어입니다.

이 정의에서는 아무것도 명확하지 않습니다. 특히 "컨테이너화가 가능한 환경"이란 무엇을 의미하는지는 불분명합니다. 이를 이해하려면 과거로 돌아가보자. 제가 전통적으로 "모놀리식 시대"라고 부르는 시대부터 시작해 보겠습니다.

모놀리식 시대

모놀리식 시대는 2000년대 초반으로, 당시 모든 애플리케이션이 모놀리식이었고 많은 종속성이 있었습니다. 개발에는 오랜 시간이 걸렸습니다. 서버 수는 그렇게 많지 않았고, 우리는 모두 서버의 이름을 알고 모니터링했습니다. 재밌는 비교가 있습니다.

애완동물은 가축입니다. 일체화된 시대에 우리는 서빙 직원을 애완동물처럼 대하고, 애지중지하며 소중히 여기고 먼지를 털었습니다. 그리고 더 나은 리소스 관리를 위해 가상화를 사용했습니다. 즉, 서버를 여러 개의 가상 머신으로 나누어 환경의 고립성을 보장했습니다.

하이퍼바이저 기반 가상화 시스템

가상화 시스템에 대해 들어보신 적이 있으신가요? VMware, VirtualBox, Hyper-V, Qemu KVM 등이 있습니다. 이러한 가상화 시스템은 애플리케이션 격리 및 리소스 관리를 제공하지만 단점도 있습니다. 가상화를 위해서는 하이퍼바이저가 필요합니다. 하이퍼바이저는 리소스 오버헤드입니다. 가상 머신 자체는 일반적으로 거대한 머신입니다. 운영 체제, Nginx, Apache, MySQL 등이 포함된 무거운 이미지입니다. 이미지가 크고 가상 머신으로 작업하기 불편합니다. 결과적으로 가상 머신 작업이 느릴 수 있습니다. 이 문제를 해결하기 위해 커널 수준 가상화 시스템이 만들어졌습니다.

커널 수준 가상화 시스템

커널 수준 가상화는 OpenVZ, Systemd-nspawn 및 LXC에서 지원됩니다. 이러한 유형의 가상화의 대표적인 예는 LXC입니다.Linux 컨테이너).

LXC는 여러 개의 격리된 운영 체제 인스턴스를 실행하기 위한 운영 체제 수준의 가상화 시스템입니다. Linux 단일 노드에서 작동합니다. LXC는 가상 머신을 사용하지 않고 자체 프로세스 공간과 네트워크 스택을 갖춘 가상 환경을 생성합니다.

기본적으로 LXC는 컨테이너를 만듭니다. 가상 머신과 컨테이너의 차이점은 무엇인가요?

컨테이너는 프로세스를 격리하는 데 적합하지 않습니다. 가상화 시스템의 커널 수준에서 취약점이 발견되어 컨테이너에서 호스트로 나갈 수 있습니다. 따라서 무언가를 분리해야 하는 경우 가상 머신을 사용하는 것이 더 좋습니다.

가상화와 컨테이너화의 차이점은 다이어그램에서 확인할 수 있습니다.
하드웨어 하이퍼바이저, OS 위의 하이퍼바이저, 컨테이너가 있습니다.

정말로 무언가를 격리하고 싶다면 베어 메탈 하이퍼바이저가 좋습니다. 메모리 페이지 수준에서 프로세서를 격리할 가능성이 있기 때문입니다.

프로그램으로서의 하이퍼바이저가 있고, 컨테이너도 있는데, 이에 대해서는 나중에 더 자세히 살펴보겠습니다. 컨테이너화 시스템에는 하이퍼바이저가 없지만 컨테이너를 생성하고 관리하는 컨테이너 엔진은 있습니다. 이건 더 가볍기 때문에 핵심 작업을 하기 때문에 오버헤드가 적거나 전혀 없습니다.

커널 수준에서 컨테이너화에 사용되는 것은 무엇입니까?

다른 프로세스로부터 격리된 컨테이너를 만들 수 있는 주요 기술은 네임스페이스와 제어 그룹입니다.

네임스페이스: PID, 네트워킹, 마운트 및 사용자. 더 많은 내용이 있지만, 이해하기 쉽게 다음 내용에 집중하겠습니다.

PID 네임스페이스는 프로세스를 제한합니다. 예를 들어 PID 네임스페이스를 생성하고 거기에 프로세스를 배치하면 PID 1이 됩니다. 일반적으로 시스템에서 PID 1은 systemd 또는 init입니다. 따라서 프로세스를 새로운 네임스페이스에 넣으면 PID 1도 할당됩니다.

네트워킹 네임스페이스를 사용하면 네트워크를 제한/격리하고 해당 네트워크 내에 인터페이스를 배치할 수 있습니다. 마운트는 파일 시스템의 제한 사항입니다. 사용자 — 사용자 제한.

제어 그룹: 메모리, CPU, IOPS, 네트워크 - 총 12개 설정. 그렇지 않으면 Cgroup이라고도 불립니다.

제어 그룹은 컨테이너의 리소스를 관리합니다. 통제 그룹을 통해 컨테이너가 특정 양의 리소스 이상을 소비해서는 안 된다고 말할 수 있습니다.

컨테이너화가 제대로 작동하도록 하려면 기능, 쓰기 시 복사 등의 추가 기술이 사용됩니다.

역량이란 프로세스에 무엇을 할 수 있고 무엇을 할 수 없는지 알려주는 것입니다. 커널 수준에서 이는 많은 매개변수를 가진 비트맵일 뿐입니다. 예를 들어, 루트 사용자는 모든 권한을 가지고 모든 작업을 수행할 수 있습니다. 시간 서버는 시스템 시간을 변경할 수 있습니다. 이는 Time Capsule에 있는 기능이며, 그게 전부입니다. 권한을 사용하면 프로세스에 대한 제한을 유연하게 구성하여 자신을 보호할 수 있습니다.

Copy-on-write 시스템을 사용하면 Docker 이미지로 작업하고 더 효율적으로 사용할 수 있습니다.

Docker는 현재 Cgroups v2와 호환성 문제가 있으므로 이 문서에서는 Cgroups v1에 중점을 둡니다.

하지만 역사로 돌아가보죠.

커널 수준 가상화 시스템이 등장하자 적극적으로 사용되기 시작했습니다. 하이퍼바이저의 오버헤드는 사라졌지만 몇 가지 문제는 여전히 남아 있습니다.

• 큰 이미지: 동일한 OpenVZ에 운영 체제, 라이브러리, 다양한 소프트웨어가 로드되지만 결국 이미지는 여전히 상당히 커집니다.
• 패키징과 배달에 대한 일반적인 표준이 없으므로 종속성 문제가 여전히 존재합니다. 두 개의 코드가 동일한 라이브러리를 사용하지만 버전이 다른 경우가 있습니다. 그들 사이에 갈등이 있을 수도 있습니다.

이러한 모든 문제를 해결하기 위해 다음 시대가 왔습니다.

컨테이너의 시대

컨테이너 시대가 도래하면서 컨테이너를 다루는 철학도 바뀌었습니다.

• 하나의 프로세스 - 하나의 컨테이너.
• 우리는 프로세스에 필요한 모든 종속성을 컨테이너에 전달합니다. 이를 위해서는 모놀리스를 마이크로서비스로 분할해야 합니다.
• 이미지가 작을수록 더 좋습니다. 취약점이 발생할 가능성이 적고, 출시가 빨라집니다.
• 인스턴스는 덧없어집니다.

애완동물과 소에 대해 이야기했던 걸 기억하시나요? 인스턴스는 예전에는 가축과 같았지만, 이제는 소와 같아졌습니다. 이전에는 하나의 모놀리스, 즉 하나의 애플리케이션이 있었습니다. 지금은 100개의 마이크로서비스, 100개의 컨테이너가 있습니다. 일부 컨테이너에는 복제품이 2~3개 있을 수 있습니다. 우리가 각 컨테이너를 통제하는 것은 덜 중요해졌습니다. 우리에게 더 중요한 것은 서비스 자체의 가용성, 즉 컨테이너 세트가 무엇을 하는지입니다. 이로 인해 모니터링 접근 방식이 바뀌었습니다.

2014~2015년에는 Docker가 크게 발전했습니다. 이제부터 이 기술에 대해 이야기해 보겠습니다.

Docker는 철학을 바꾸고 애플리케이션 패키징을 표준화했습니다. Docker를 사용하면 애플리케이션을 패키징하고, 저장소에 푸시하고, 저장소에서 다운로드하여 배포할 수 있습니다.

우리는 필요한 모든 것을 Docker 컨테이너에 넣었으므로 종속성 문제가 해결되었습니다. Docker는 재현성을 보장합니다. 많은 사람이 재현 불가능성을 경험했을 것 같습니다. 모든 것이 잘 작동하다가, 그것을 운영에 적용하면 더 이상 작동하지 않는 것입니다. Docker를 사용하면 이런 문제는 사라집니다. Docker 컨테이너가 시작되어 예상대로 작동한다면, 프로덕션 환경에서도 컨테이너가 시작되어 동일한 작업을 수행할 가능성이 높습니다.

오버헤드에 대한 여담

오버헤드에 대한 논쟁은 끊이지 않습니다. 일부에서는 Docker가 커널을 사용하기 때문에 추가적인 오버헤드가 발생하지 않는다고 주장합니다. Linux 그리고 컨테이너화에 필요한 모든 프로세스도 마찬가지입니다. 예를 들어, "도커가 오버헤드라고 한다면 커널도 마찬가지입니다." Linux "간접비".

반면에, 더 깊이 파고들면 Docker에는 실제로 오버헤드라고 할 수 있는 몇 가지 사항이 있습니다.

첫 번째는 PID 네임스페이스입니다. 프로세스를 네임스페이스에 넣으면 PID 1이 할당됩니다. 동시에 이 프로세스는 컨테이너 외부의 호스트 네임스페이스에 있는 또 다른 PID를 갖습니다. 예를 들어, 컨테이너에서 Nginx를 실행하면 PID 1(마스터 프로세스)이 됩니다. 호스트에서는 PID가 12623입니다. 오버헤드가 얼마나 되는지 말하기는 어렵습니다.

두 번째는 Cgroups입니다. Cgroups를 메모리, 즉 컨테이너의 메모리를 제한하는 기능으로 살펴보겠습니다. 이 기능을 활성화하면 카운터와 메모리 계산이 활성화됩니다. 즉, 커널은 이 컨테이너에 할당된 페이지 수와 아직 사용 가능한 페이지 수를 파악해야 합니다. 이것이 오버헤드일 가능성은 있지만, 이것이 성능에 어떤 영향을 미치는지에 대한 구체적인 연구는 본 적이 없습니다. 그리고 Docker에서 실행되는 애플리케이션이 갑자기 성능을 잃었다는 사실조차 알아차리지 못했습니다.

성능에 대한 또 다른 참고사항. 일부 커널 매개변수는 호스트에서 컨테이너로 전달됩니다. 특히, 일부 네트워크 매개변수. 따라서 Docker에서 고성능을 요구하는 작업, 예를 들어 네트워크를 적극적으로 활용하는 작업을 실행하려면 최소한 이러한 매개변수를 조정해야 합니다. 예를 들어 nf_conntrack.

Docker 개념에 대하여

Docker는 여러 구성 요소로 구성됩니다.

1. Docker Daemon은 동일한 컨테이너 엔진입니다. 컨테이너를 발사합니다.
2. Docker CII는 Docker를 관리하는 유틸리티입니다.
3. Dockerfile - 이미지를 빌드하는 방법에 대한 지침.
4. 이미지 — 컨테이너가 펼쳐지는 이미지입니다.
5. 컨테이너.
6. Docker 레지스트리는 이미지 저장소입니다.

개략적으로 보면 다음과 같습니다.

Docker_host는 컨테이너를 시작하는 Docker 데몬을 실행합니다. 이미지 빌드, 이미지 다운로드, 컨테이너 실행 등의 명령을 전송하는 클라이언트가 있습니다. Docker 데몬은 레지스트리로 가서 이를 실행합니다. Docker 클라이언트는 로컬(Unix 소켓)과 원격 호스트의 TCP를 통해 모두 액세스할 수 있습니다.

각 구성 요소를 살펴보겠습니다.

도커 데몬 — 이건 서버 부분으로, 호스트 머신에서 실행됩니다. 이미지를 다운로드하고 이를 통해 컨테이너를 실행하고, 컨테이너 간에 네트워크를 생성하고, 로그를 수집합니다. 우리가 "이미지를 만들어라"고 말할 때, 악마도 같은 일을 합니다.

도커 CLI — Docker의 클라이언트 부분으로, 데몬 작업을 위한 콘솔 유틸리티입니다. 다시 말씀드리지만, 로컬로만 작동하는 것이 아니라 네트워크를 통해서도 작동할 수 있습니다.

기본 명령:

docker ps — 현재 Docker 호스트에서 실행 중인 컨테이너를 표시합니다.
docker images - 로컬에 다운로드된 이미지를 보여줍니다.
docker search <> — 레지스트리에서 이미지를 검색합니다.
docker pull <> — 레지스트리에서 머신으로 이미지를 다운로드합니다.
도커 빌드 < > — 이미지를 수집합니다.
docker run <> — 컨테이너를 실행합니다.
docker rm <> — 컨테이너를 제거합니다.
docker 로그 <> — 컨테이너 로그
docker start/stop/restart <> — 컨테이너 작업

이러한 명령어를 완벽하게 숙지하고 자신 있게 사용할 수 있다면 사용자 수준에서 Docker에 대한 숙련도가 70% 정도라고 볼 수 있습니다.

도커 파일 — 이미지를 만드는 방법에 대한 지침입니다. 거의 모든 명령어는 새로운 레이어입니다. 예를 들어 살펴보겠습니다.

Dockerfile은 대략 다음과 같습니다. 왼쪽에는 명령, 오른쪽에는 인수가 있습니다. 여기에 있는 각 명령(일반적으로 Dockerfile에 작성됨)은 이미지에 새 레이어를 만듭니다.

왼쪽만 봐도 무슨 일이 일어나고 있는지 대략 알 수 있습니다. 우리는 "폴더를 만들어 주세요"라고 말합니다. 이것은 하나의 계층입니다. "폴더를 작동하게 만들기"는 또 다른 계층입니다. 레이어 케이크는 삶을 더 편리하게 만들어줍니다. 다른 Dockerfile을 만들고 마지막 줄의 내용을 변경하는 경우(예: "python" "main.py"가 아닌 다른 것을 실행하거나 다른 파일에서 종속성을 설치하는 경우) 이전 계층이 캐시로 재사용됩니다.

영상 - 이것은 컨테이너 포장이며, 컨테이너는 이미지에서 발사됩니다. 패키지 관리자의 관점에서 Docker를 살펴보면(deb 또는 rpm 패키지를 다루는 것처럼), 이미지는 본질적으로 rpm 패키지입니다. yum install을 사용하면 애플리케이션을 설치, 제거하고, 저장소에서 찾아 다운로드할 수 있습니다. 여기서도 거의 동일합니다. 컨테이너는 이미지에서 시작되고 Docker 레지스트리(저장소에 있는 yum과 유사)에 저장되며 각 이미지에는 SHA-256 해시, 이름, 태그가 있습니다.

이미지는 Dockerfile의 지침에 따라 빌드됩니다. Dockerfile의 각 명령어는 새로운 계층을 생성합니다. 레이어는 재사용이 가능합니다.

도커 레지스트리 — Docker 이미지의 저장소입니다. Docker는 OS와 유사하게 공개적으로 사용 가능한 표준 레지스트리인 dockerhub를 갖고 있습니다. 하지만 나만의 저장소, 나만의 Docker 레지스트리를 만들 수 있습니다.

컨테이너 - 이미지로부터 시작되는 것. Dockerfile의 지침에 따라 이미지를 빌드한 다음, 이 이미지에서 실행합니다. 이 컨테이너는 다른 컨테이너와 분리되어 있으며 애플리케이션이 작동하는 데 필요한 모든 것을 포함해야 합니다. 이 경우, 하나의 컨테이너는 하나의 프로세스입니다. 두 가지 프로세스를 수행해야 하는 경우가 있는데, 이는 Docker의 이념과는 다소 어긋납니다.

"컨테이너 1개 - 프로세스 XNUMX개"라는 요구 사항은 PID 네임스페이스와 관련이 있습니다. PID XNUMX인 프로세스가 네임스페이스에서 시작될 때, 해당 프로세스가 갑자기 종료되면 컨테이너 전체도 종료됩니다. 두 개의 프로세스가 실행 중이고 하나는 살아 있고 다른 하나는 죽어 있는 경우에도 컨테이너는 계속 살아있습니다. 하지만 이건 모범 사례에 대한 질문이므로, 다른 자료에서 이에 대해 이야기하겠습니다.

이 과정의 특징과 전체 프로그램을 더 자세히 알아보려면 다음 링크를 클릭하세요:도커 비디오 코스".

저자: 마르셀 이브라에프, 쿠버네티스 인증 관리자, 사우스브리지의 실무 엔지니어, Slurm 과정의 강사이자 개발자.

출처 : habr.com