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

10월 XNUMX일 Slurm에서 시작됨 도커 비디오 코스, 기본 추상화부터 네트워크 매개변수까지 완벽하게 분석합니다.

이 기사에서는 Docker의 역사와 주요 추상화인 Image, Cli, Dockerfile에 대해 설명합니다. 해당 강의는 초보자를 대상으로 한 것이므로 숙련된 사용자에게는 흥미가 없을 것 같습니다. 혈액, 맹장 또는 깊은 침수가 없습니다. 매우 기본적인 것입니다.

도커란 무엇인가

Wikipedia에서 Docker의 정의를 살펴보겠습니다.

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

이 정의에서 명확한 것은 없습니다. 특히 "컨테이너화를 지원하는 환경에서"가 무엇을 의미하는지 불분명합니다. 알아보기 위해 시간을 거슬러 올라가 보겠습니다. 제가 전통적으로 '모놀리식 시대'라고 부르는 시대부터 시작하겠습니다.

모놀리식 시대

모놀리식 시대는 모든 애플리케이션이 수많은 종속성과 함께 모놀리식이었던 2000년대 초반입니다. 개발에는 오랜 시간이 걸렸습니다. 동시에 서버가 많지 않아 우리 모두 이름을 알고 모니터링했습니다. 이렇게 재미있는 비교가 있습니다.

애완동물은 가축이다. 모놀리식 시대에 우리는 서버를 애완동물처럼 대하고 손질하고 소중히 여기며 먼지를 날려 버립니다. 그리고 더 나은 리소스 관리를 위해 가상화를 사용했습니다. 서버를 여러 개의 가상 머신으로 나누어 환경을 격리했습니다.

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

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

커널 수준 가상화 시스템

커널 수준 가상화는 OpenVZ, Systemd-nspawn, LXC 시스템에서 지원됩니다. 이러한 가상화의 대표적인 예가 LXC(Linux Containers)입니다.

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

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

컨테이너는 프로세스를 격리하는 데 적합하지 않습니다. 컨테이너에서 호스트로 탈출할 수 있는 커널 수준의 가상화 시스템에서 취약점이 발견됩니다. 따라서 무언가를 격리해야 한다면 가상 머신을 사용하는 것이 좋습니다.

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

정말로 무언가를 분리하고 싶다면 하드웨어 하이퍼바이저가 좋습니다. 메모리 페이지와 프로세서 수준에서 분리가 가능하기 때문입니다.

프로그램으로는 하이퍼바이저가 있고 컨테이너도 있는데 이에 대해 더 자세히 설명하겠습니다. 컨테이너화 시스템에는 하이퍼바이저가 없지만 컨테이너를 생성하고 관리하는 컨테이너 엔진이 있습니다. 이것은 더 가볍기 때문에 코어 작업으로 인해 오버헤드가 적거나 전혀 없습니다.

커널 수준에서 컨테이너화에 사용되는 것

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

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

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

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

제어 그룹: 메모리, CPU, IOPS, 네트워크 - 총 약 12가지 설정. 그렇지 않으면 C그룹(“C-그룹”)이라고도 합니다.

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

컨테이너화가 완벽하게 작동하려면 기능, 기록 시 복사 등의 추가 기술이 사용됩니다.

능력은 프로세스가 무엇을 할 수 있고 무엇을 할 수 없는지를 알려줄 때 나타납니다. 커널 수준에서 이는 많은 매개변수가 포함된 단순한 비트맵입니다. 예를 들어 루트 사용자는 모든 권한을 가지며 모든 작업을 수행할 수 있습니다. 시간 서버는 시스템 시간을 변경할 수 있습니다. 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 커널과 컨테이너화에 필요한 모든 프로세스를 사용하기 때문에 추가 로드를 전달하지 않는다고 생각합니다. 예를 들어, "Docker가 오버헤드라고 말하면 Linux 커널이 오버헤드입니다."

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

첫 번째는 PID 네임스페이스입니다. 프로세스를 네임스페이스에 배치하면 PID 1이 할당됩니다. 동시에 이 프로세스에는 컨테이너 외부의 호스트 네임스페이스에 있는 또 다른 PID가 있습니다. 예를 들어 컨테이너에서 Nginx를 시작했는데 PID 1(마스터 프로세스)이 되었습니다. 그리고 호스트에는 PID 12623이 있습니다. 그리고 그것이 얼마나 많은 오버헤드인지 말하기는 어렵습니다.

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

그리고 성능에 관해 한 가지 더 언급하겠습니다. 일부 커널 매개변수는 호스트에서 컨테이너로 전달됩니다. 특히 일부 네트워크 매개변수. 따라서 Docker에서 네트워크를 적극적으로 사용하는 것과 같은 고성능 항목을 실행하려면 최소한 이러한 매개변수를 조정해야 합니다. 예를 들어 일부 nf_conntrack.

Docker 개념 정보

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

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

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

Docker 데몬은 Docker_host에서 실행되고 컨테이너를 시작합니다. 명령을 보내는 클라이언트가 있습니다: 이미지 빌드, 이미지 다운로드, 컨테이너 실행. 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에 기록된) 각 명령은 Image에 새 레이어를 생성합니다.

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

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

이미지는 Dockerfile의 지침에 따라 빌드됩니다. Dockerfile의 각 명령은 새 레이어를 생성합니다. 레이어를 재사용할 수 있습니다.

도커 레지스트리 Docker 이미지 저장소입니다. OS와 유사하게 Docker에는 공개 표준 레지스트리인 dockerhub가 있습니다. 하지만 자신만의 저장소, 즉 Docker 레지스트리를 구축할 수 있습니다.

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

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

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

작성자: Marcel Ibraev, 공인 Kubernetes 관리자, Southbridge의 실무 엔지니어, Slurm 과정의 강사 및 개발자.

출처 : habr.com