Как хранятся док-контейнеры в оперативной памяти и выполняются? - PullRequest
Новая
       38

Как хранятся док-контейнеры в оперативной памяти и выполняются?

3 голосов
/ 18 апреля 2019

Я хотел бы знать, как контейнеры Docker управляются операционной системой.Я мог бы найти некоторые объяснения здесь: https://stackoverflow.com/a/47784145/11377751,, но я не могу хорошо понять.

Я знаю основы операционной системы (понятия о PCB, ram, CPU, ядре, syscall и т. Д.).

Но я не понимаю, как ОС управляет контейнерами:

  • Процессы контейнеров или они "эмулируются" механизмом Docker (который будет единственным процессомсо своими нитками)?Как я могу представить контейнер в оперативной памяти?
  • Если в моем контейнере я запускаю приложение C, содержащее «fork ();», которое выполняет вызов ядра: контейнер или Docker Engine.?Кто дублирует печатную плату?Или "malloc (..);"?
  • Какова концепция пространства имен в ядре?в баран?Эти таблицы определяют права доступа или что-то еще?Почему в википедии говорится, что это понятие необходимо для контейнеров, зная, что в схемах Docker Engine представлен между контейнерами и ядром?

image:

Thisэто изображение, которое я нашел здесь: https://stackoverflow.com/a/42111368/11377751

заранее большое спасибо

1 Ответ

3 голосов
/ 18 апреля 2019

Предисловие: это было проверено на Arch Linux

  1. Контейнеры - это процессы. У нас есть dockerd и containerd - каждый из них только один раз. Затем у нас есть процессы docker и containerd-shim для каждого запущенного контейнера. Обратите внимание, что containerd-shim является родителем контейнера. Его цель:

    • Сначала он позволяет средам выполнения, то есть runc, выходить после запуска контейнера. Таким образом, нам не нужно иметь долго выполняющиеся процессы выполнения для контейнеров. Когда вы запускаете mysql, вы должны видеть только процесс mysql и шим.

    • Во-вторых, он сохраняет STDIO и другие fd открытыми для контейнера, если контейнер и / или докер оба умирают. Если прокладка не работает, родительская сторона труб или мастер TTY будет закрыта, и контейнер выйдет.

    • Наконец, он позволяет сообщать о состоянии выхода контейнера в инструмент более высокого уровня, например, в docker, не имея фактического родителя процесса контейнера и не делая wait4.

(взято из https://groups.google.com/forum/#!topic/docker-dev/zaZFlvIx1_k)

  1. Пожалуйста, прочитайте 2 хороших ответа о системных вызовах (https://stackoverflow.com/a/32842491/5247040) и ролях частей докера (https://stackoverflow.com/a/46650343/5247040). Еще одно хорошее чтение https://medium.com/devopslinks/docker-containerd-standalone-runtimes-heres-what-you-should-know-b834ef155426

РЕДАКТИРОВАТЬ: Быстрый ответ: приложение C вызывает fork и malloc => ядро ​​Linux. Я ошибался, Docker Engine не участвует в системных вызовах, все управление происходит через пространства имен / seccomp (https://stackoverflow.com/a/34871045/5247040)

  1. Представления пространства имен в ram довольно разные, вы можете проверить исходный код для

Почему в Википедии сказано, что это понятие важно для контейнеров

Потому что «Различные контейнерные программы используют пространства имен Linux в сочетании с cgroups для изоляции своих процессов, включая Docker [8] и LXC» (https://en.wikipedia.org/wiki/Linux_namespaces)

В основном пространства имен являются инструментом, с помощью которого Docker Engine контролирует ресурсы контейнеров

...