Контекст

Файл конфигурации связывает образы, сеть и хранилище.

Запустить сервис с постоянным томом и объяснить адреса внутри Compose.

Compose описывает желаемый запуск

Файл конфигурации связывает образы, сеть и хранилище.

Аналогия: список участников, помещений и оборудования одной лаборатории.

Имена сервисов и внутренние порты

Внутри сети Compose используем имя сервиса, а не порт хоста.

Аналогия: номер внутреннего телефона отличается от городского номера.

Named volume и bind mount

Данные не должны случайно зависеть от срока жизни контейнера.

Аналогия: квартира меняет жильца, а отдельное хранилище не выбрасывается вместе с мебелью.

Команды и наблюдения

Ubuntu / Bash, lab

docker compose config --quiet
docker compose up -d --build
docker compose ps
curl -sS -H "Content-Type: application/json" -d '{"hours":4}' http://127.0.0.1:8000/predict
docker compose exec app cat /data/events.jsonl
docker compose up -d --force-recreate app
docker compose exec app cat /data/events.jsonl

Разбор результата

Запись запроса остаётся в events.jsonl после пересоздания app.

Команда force-recreate затрагивает только app в собственной учебной Compose-папке. Перед опытом освобождаем порт от предыдущих демонстраций.

На macOS

Compose-команды одинаковы. Named volumes живут в Linux-среде Desktop; bind mount проходит через механизм обмена файлами macOS и может отличаться по скорости и правам. Не использовать down -v для обычной остановки.

docker compose config --quiet
docker compose up -d --build
docker compose ps
docker compose down

Состояние переживает пересоздание

1. Поднимите базовый compose, сделайте три POST-запроса.
2. Проверьте /data/events.jsonl и сохраните количество строк.
3. Выполните down без -v, затем up -d.
4. Убедитесь, что старые записи доступны; объясните, почему это ещё не backup.

Что должно получиться

compose.yaml и доказательство сохранности записей.

Данные переживают смену контейнера; опубликованные порты ограничены localhost.

Ошибка для диагностики

Использование down -v стирает именованный том.

Основные выводы

1. По имени app и внутреннему порту 8000.
2. Нет, он обеспечивает отдельное хранение, но не независимое восстановление.

После пары

Задокументировать назначение тома и команды безопасной остановки проекта.

localhost зависит от точки зрения

Контекст

Процесс существует, проверка проходит и пользовательский путь работает — разные факты.

Проверить healthcheck, задать лимиты и не путать порядок запуска с готовностью.

Running, healthy, ready

Процесс существует, проверка проходит и пользовательский путь работает — разные факты.

Аналогия: свет в кафе горит, кухня готова и заказ выдан — три проверки.

Зависимости Compose

Порядок старта не гарантирует завершение инициализации.

Аналогия: открыть дверь склада не значит закончить приёмку товаров.

Предел ресурсов и поверхность доступа

Ограничиваем ущерб и наблюдаем результат ограничения.

Аналогия: лабораторная работает в пределах выделенного бюджета, а не занимает всё здание.

Команды и наблюдения

Ubuntu / Bash, lab

docker compose up -d --build
docker compose ps
docker compose exec app python -c "import urllib.request; print(urllib.request.urlopen('http://127.0.0.1:8000/healthz').status)"
docker stats --no-stream
docker compose exec app sh -c "touch /app/test-write"
docker compose exec app sh -c "touch /data/test-write"

Разбор результата

Healthcheck становится healthy; запись в /app отказана, в /data разрешена; stats показывает потребление.

Отказ touch /app/test-write — ожидаемый результат политики, не дефект курса. Удалите собственный /data/test-write после проверки.

На macOS

Healthcheck и ограничения выполняются внутри Linux-VM Docker Desktop. Показатели контейнера не равны всему потреблению macOS. Проверяйте выделенный Desktop бюджет CPU/RAM и доступность устройства.

docker stats --no-stream
docker compose ps
docker compose exec app id

Проверки ограничений

1. Объясните каждое ограничение базового compose.
2. Покажите healthcheck и запрос predict отдельно.
3. Проверьте, что код нельзя изменить внутри контейнера, а учебные события можно сохранять.
4. Запишите configured limit и наблюдаемое потребление: почему это разные числа?

Что должно получиться

Таблица проверок: ожидаемое поведение / наблюдение / вывод.

Все ограничения сохраняют рабочий predict; unhealthy не объявляется автоматическим рестартом.

Ошибка для диагностики

Read-only root filesystem включён без writable-volume для событий.

Основные выводы

1. Нет, healthcheck и restart policy имеют разные механизмы.
2. Ожидание готовности зависимости при запуске, но не гарантию её вечной доступности.

После пары

Составить checklist контейнерного запуска и предложить healthcheck для реального ML-API.