#docker
Прежде чем разбирать какие-то частные случаи использования контейнеров, хотелось бы разобрать базовые сущности того-же docker. Это подготовит несколько ступенек, которые станут основой для лестницы. С помощью этой лестницы, мы погрузимся в тему достаточно глубоко, чтобы стать интересным собеседником для нашего будущего интервьюера.
Сегодня docker.sock
Если бы меня спросили на том же собеседовании из чего состоит docker как утилита, я бы ответил следующим образом:
dockerd
docker API
docker CLI
Давайте разберемся в каждом из этих пунктов. C dockerd всё более менее понятно, это фоновый процесс (демон), управляющий всеми аспектами работы docker на хосте. Обрабатывает запросы на создания контейнеров, создает контейнеры, уничтожает контейнеры. Командный центр, взаимодействующий непосредственно с ОС хоста в части изоляции, также управляет сетями и хранилищами.
Docker CLI (Command Line Interface) тоже затруднений вызывать не должен, самый базовый способ взаимодействия с docker. Если вы знакомы с командами docker run / ps / images / build / stop / rm / rmi, значит с CLI вы уже работали.
Эти две сущности должно что-то связывать и эту работу берет на себя REST API через UNIX сокеты или сетевой интерфейс. По умолчанию сокет докера располагается в /var/run/docker.sock и готов принять запросы не только от Docker CLI, но и любого другого клиентского приложения.
Возможность обращаться к сокету напрямую, очень удобна, но является благодатной почвой для разного рода уязвимостей. Владельцем данного ресурса должен быть пользователь root. Предоставлять доступ к docker.sock другому пользователю означает, означает выдать ему root-привилегий хоста, поскольку сам демон dockerd запускается с такими правами. Кроме того, не следует монтировать этот сокет внутрь контейнера (например, через volume), по сути подобное действие означает передачу контроля над хост системой контейнеру.