Что такое контейнер

Представьте баг: разработчик получает от API JSON, а на тестовом стенде сервис падает при запуске. Исходный код одинаковый, но на стенде другая версия Python. Проверять только коммит недостаточно: поведение зависит ещё от интерпретатора, библиотек, файлов и параметров запуска.

Для QA полезно разделять эти составляющие. Код отвечает на вопрос «что делает программа», окружение — «какими средствами она выполняется», конфигурация — «с какими настройками её запустили». Начните расследование с двух коротких проверок:

python --version
python app.py

Первая команда проверяет доступный интерпретатор. Вторая пытается выполнить файл относительно текущей папки. Ошибка python: command not found возникает ещё до выполнения вашего кода; ошибка из app.py относится уже к следующему этапу. Docker помогает описать окружение, но читать ошибки всё равно нужно по месту возникновения.

Контейнер — запущенный процесс с изолированным представлением файлов, сети и других ресурсов. В нашем случае главным процессом будет Python, выполняющий HTTP-сервер. Контейнеру не требуется рабочий стол или отдельная полноценная ОС с собственным ядром.

Обычные Linux-контейнеры используют ядро машины, на которой работает Docker Engine. На macOS и Windows Linux Engine обычно работает внутри виртуальной машины. Поэтому фраза «контейнер — маленькая виртуальная машина» мешает понять, почему контейнер заканчивается вместе с главным процессом. Эти различия описаны в Docker Docs: контейнеры и виртуальные машины.

docker run --rm python:3.12-alpine python --version

Здесь Docker запускает Python внутри нового контейнера. После вывода версии процесс завершается, а флаг --rm удаляет завершившийся контейнер. Отсутствие такого контейнера в списке работающих — ожидаемый результат, а не сбой.

Мы будем работать с небольшим API на стандартной библиотеке Python. Он принимает GET-запрос и возвращает JSON. Небольшой размер полезен для обучения: если проверка не прошла, можно последовательно проверить упаковку, запуск процесса и HTTP-ответ, не разбираясь одновременно с фреймворком и базой данных.

Dockerfile + app.py + .dockerignore
                  ↓ сборка
                образ
                  ↓ запуск
              контейнер
                  ↓ HTTP-запрос
          статус, заголовки, JSON

В лаборатории вы редактируете три файла в браузере, затем запускаете настоящую сборку и проверку. Для неё подготовлен образ python:3.12-alpine; скачивать зависимости не нужно. Команды в теории предназначены для понимания и самостоятельного повторения там, где установлен Docker. В редакторе лаборатории меняются файлы, команды запуска выполняет проверяющая среда.

Не объединяйте все ошибки в «Docker не работает». Если сборка остановилась на COPY, сервер ещё не запускался. Если сборка прошла, но получен неверный JSON, начните с обработчика запроса. В каждом следующем уроке будем связывать симптом с конкретным этапом.