🤨 Базовые объекты Docker, но без воды: что реально нужно знать QA Можно годами работать с Docker и так и не понять, чем image отличается от container, а volume от bind mount - и всё равно жить. Но опытному тестировщику это мешает нормально расследовать баги. 🧱 1. Image (образ) Это как шаблон: “слепок файловой системы + инструкция, как запускать”. Образ - неизменяемый. Ты его не "испортишь". Примеры: python:3.11 postgres:15 mycorp/auth-service:1.4.2 QA-ценность: важно знать, с каким образом ты работаешь - версия сервиса часто = версия бага. 📦 2. Container (контейнер) Это запущенный экземпляр образа. Можно представить как “процесс + файловая система + сетевые настройки”. Ты можешь: запустить несколько контейнеров из одного образа; убить контейнер, а образ останется. Полезные команды: docker ps # запущенные docker ps -a # все, включая остановленные docker rm <id> # удалить контейнер QA-ошибка: думать, что “я удалил контейнер, значит всё чисто”. Нет. Могут остаться тома и кеш слоев. 💾 3. Volumes (тома) Это место, где живут данные, переживающие смерть контейнера: БД, загрузки файлов, кэш. Если ты: docker-compose down а данные всё ещё на месте - значит, они сидят в volume. docker volume ls # список томов docker volume rm <name> # удалить том (осторожно!) QA-ценность: когда баг “пропадает после полного удаления томов” - проблема может быть в грязных данных, а не в коде. 🌐 4. Network (сеть) Контейнеры общаются друг с другом по именам сервисов внутри одной сети. В docker-compose.yml ты пишешь: services: api: image: mycorp/api:1.2 db: image: postgres:15 И внутри контейнера api ты обращаешься к БД по хосту db, а не localhost. Классический баг: “локально к БД ходит, в контейнере нет” - неверный host. Понимая 4 вещи (image, container, volume, network), ты уже не просто “жмёшь docker-compose up”, а понимаешь, где может спрятаться баг: в корявом образе, застарелых томах, неправильном хосте или сетке. 📓 Заметки тестировщика