Какие основные сущности есть в Docker

Что проверяют

Различаете ли вы образ и контейнер и понимаете ли, где живут данные и как сервисы находят друг друга. Следом обычно просят написать Dockerfile для Python-приложения или объяснить, куда деваются данные после удаления контейнера.

Как отвечать

• образ (image): неизменяемый набор слоёв плюс метаданные, то есть команда запуска, переменные, порты. Адресуется тегом (python:3.12-slim) или digest;
• контейнер: процесс, запущенный из образа, со своим записываемым слоем поверх, изолированный через namespaces и ограниченный cgroups. Ядро общее с хостом, это не виртуальная машина;
• Dockerfile: инструкции сборки, RUN и COPY дают слои, и слои кэшируются;
• реестр (registry): хранилище образов, Docker Hub, GitLab Registry, Harbor или облачный;
• том (volume): хранилище, которое переживает удаление контейнера. Есть именованные тома под управлением Docker, bind mount с папкой хоста и tmpfs в памяти;
• сеть: по умолчанию bridge. В пользовательской bridge-сети контейнеры находят друг друга по имени через встроенный DNS, в сети по умолчанию этого нет. Есть ещё host и none.

Отдельно назовите Compose: несколько сервисов, сетей и томов в compose.yaml, запуск через docker compose up.

Для Python покажите, что знаете про кэш слоёв: сначала COPY requirements.txt, затем pip install --no-cache-dir -r requirements.txt и только потом копирование кода. Тогда правка кода не переустанавливает зависимости. Базовый образ лучше slim, чем alpine: на musl часть пакетов с C-расширениями собирается из исходников, и сборка раздувается.

Где спотыкаются

Путают образ и контейнер или называют контейнер лёгкой виртуалкой. Образ это шаблон, контейнер это процесс, и ядро у всех контейнеров одно.

Хранят данные внутри контейнера без тома. Остановка их не сотрёт, а удаление или пересоздание контейнера сотрёт.

Пишут COPY . . первой строкой и удивляются, что каждая сборка ставит все зависимости заново. Заодно в образ попадают .venv и .git, если нет .dockerignore.