Как работает поиск файлов в контейнере Docker
Согласно документации Docker, каждая инструкция Dockerfile создает слой, и все слои сохраняются, когда вы создаете новое изображение на основе старого. Затем, когда я создаю свое собственное изображение, у меня могут быть сотни слоев из-за рекурсивного наследования слоев базового изображения.
Насколько я понимаю, поиск файлов в контейнере работает следующим образом:
- процесс хочет получить доступ к файлу
aпоиск начинается со слоя контейнера (тонкий слой w/ r) . - UnionFS проверяет, есть ли для этого слоя запись для него (есть ли она или помечена как удаленная) . Если да, верните его или скажите, что он не найден, соответственно, завершив поиск. Если нет, передайте задачу слою ниже.
- конец поиска в нижнем слое.
Если это так, рассмотрим файл, который находится в нижнем слое и не изменяется другими слоями, /bin/sh возможно, потребуется пройти все слои до дна. Хотя слои могут быть очень легкими, поиск все же требует в 100 раз больше времени, чем обычный, что заметно. Но по моему опыту, Docker довольно быстрый, почти такой же, как нативная ОС. Где я не прав?
2 ответа
Это все благодаря UnionFS и Union Mounts!
Прямо из Википедии:
Это позволяет прозрачно накладывать файлы и каталоги отдельных файловых систем, называемых ветвями, образуя единую согласованную файловую систему.
И из интересной статьи:
В ядре файловые системы располагаются в порядке их последовательности монтирования, первая смонтированная файловая система находится в нижней части стека монтирования, а последняя монтируется в верхней части стека. Видны только файлы и каталоги вершины стека монтирования. При объединении монтирования записи каталога из нижних файловых систем объединяются с записями каталога верхней файловой системы, что делает логическую комбинацию всех смонтированных файловых систем. Файлы с одинаковыми именами в нижней файловой системе маскируются, так как верхняя имеет приоритет.
Таким образом, он не "проходит слои" в обычном смысле (например, по одному за раз), а скорее знает (в любой момент времени), какой файл находится на каком диске.
Выполнение этого на уровне файловой системы также означает, что никому из программного обеспечения не нужно беспокоиться о том, где находится файл, оно знает, что нужно спросить /bin/sh и файловая система знает, где его взять.
Более подробную информацию можно найти на этом вебинаре.
Итак, чтобы ответить на ваш вопрос:
Где я не прав?
Вы думаете, что он должен просматривать слои по одному, в то время как он не должен этого делать. (UnionFS - это круто!)
Чтобы добавить к правильному предыдущему ответу, разработчики файловых систем copy-on-write (CoW) и union хотят иметь почти естественную производительность, поэтому, конечно, настроили свои реализации и "API", чтобы иметь максимально возможную производительность поиска / производительности файловой системы.
Тем не менее, хорошо знать, что Docker работает не только над одним "типом" файловой системы union/CoW, но имеет небольшой набор доступных опций со значениями по умолчанию в зависимости от дистрибутива Linux, на котором он установлен.
AUFS и overlay(fs) являются наиболее распространенными, но Docker также поддерживает устройство устройств (Red Hat предоставлено и поддерживается в Fedora/RHEL/CentOS), btrfs и zfs. У меня есть запись в блоге, сравнивающая и противопоставляющая различные варианты, которые могут представлять интерес.