# Docker Operations Краткое оглавление книги по Docker. Используется для быстрой навигации по разделам документации. Содержание 1\. Основы Docker - **Docker Compose — Управление сервисами** - **Docker — Отладка контейнеров** - **Docker Compose — Структура docker-compose.yml** 2\. Диагностика и обслуживание - **Docker — Мониторинг и ресурсы** - **Docker — Работа с сетями** - **Docker — Logs (Работа с логами)** - **Docker — Cleanup (Очистка и обслуживание)** 3\. Управление проектами - **Docker — Операции с проектами** - **Docker — Volumes (Хранение данных)** - **Docker — Images (Управление образами)** 4\. Безопасность - **Docker — Безопасность и аудит** 5\. Решение проблем - **Docker Troubleshooting — Решение типичных проблем** - **Docker Debug Flow — Алгоритм диагностики** 6\. Deployment - **Docker — Production Deployment Workflow** - **Docker — Backup (Резервное копирование данных)** # Docker Operations — Как читать эту книгу Эта карта показывает рекомендуемый порядок изучения разделов книги. Новым разработчикам рекомендуется читать страницы последовательно, чтобы понять основы Docker, а затем перейти к диагностике, обслуживанию и деплою проектов. --- # Шаг 1 — Базовые команды Docker Начните с основных команд управления контейнерами. * **Docker Compose — Управление сервисами** * **Docker Compose — Структура docker-compose.yml** После этого вы сможете: * запускать проекты * управлять сервисами * понимать конфигурацию Docker Compose --- # Шаг 2 — Работа с контейнерами Следующий шаг — научиться диагностировать контейнеры. * **Docker — Отладка контейнеров** * **Docker — Logs (Работа с логами)** После этого вы сможете: * находить ошибки * читать логи * подключаться к контейнерам --- # Шаг 3 — Понимание инфраструктуры Docker Теперь важно понять основные компоненты Docker. * **Docker — Images (Управление образами)** * **Docker — Volumes (Хранение данных)** * **Docker — Работа с сетями** После этого станет понятно: * как Docker хранит данные * как контейнеры взаимодействуют * как управлять образами --- # Шаг 4 — Мониторинг и обслуживание Следующий уровень — поддержка серверов с Docker. * **Docker — Мониторинг и ресурсы** * **Docker — Cleanup (Очистка и обслуживание)** После этого вы сможете: * контролировать использование ресурсов * очищать систему Docker * предотвращать переполнение диска --- # Шаг 5 — Работа с проектами Теперь можно перейти к управлению реальными проектами. * **Docker — Операции с проектами** * **Docker — Backup (Резервное копирование данных)** После этого вы сможете: * управлять несколькими Docker-проектами * выполнять резервное копирование * поддерживать инфраструктуру серверов --- # Шаг 6 — Production и безопасность Финальный этап — работа с production-системами. * **Docker — Безопасность и аудит** * **Docker — Production Deployment Workflow** После этого вы сможете: * безопасно разворачивать проекты * обновлять сервисы без простоев * контролировать безопасность контейнеров --- # Шаг 7 — Решение проблем Эти страницы используются как справочник при проблемах. * **Docker Troubleshooting — Решение типичных проблем** * **Docker Debug Flow — Алгоритм диагностики** Они помогают быстро понять: * почему контейнер не запускается * почему сервис недоступен * где искать причину ошибки --- # Быстрая навигация Если вы уже знакомы с Docker: | Задача | Раздел | | ------------------------------ | --------------------------------------- | | Запуск проекта | Docker Compose — Управление сервисами | | Ошибка контейнера | Docker — Отладка контейнеров | | Проверка логов | Docker — Logs | | Контейнеры не видят друг друга | Docker — Работа с сетями | | Docker занял весь диск | Docker — Cleanup | | Резервное копирование | Docker — Backup | | Обновление проекта | Docker — Production Deployment Workflow | --- # Итог Эта книга покрывает весь жизненный цикл Docker-проектов: ```text Запуск → Диагностика → Инфраструктура → Обслуживание → Управление проектами → Deployment → Troubleshooting ``` # Глава 1 — Основы работы с Docker # Compose — Управление сервисами Эта страница объясняет базовые команды `docker compose`, которые используются для запуска, остановки, пересборки и перезапуска сервисов в проекте. Материал рассчитан на начинающих: здесь разобрано, что делает каждая команда, в каких случаях её использовать и на что обратить внимание, чтобы случайно не сломать рабочее окружение. --- ### Что такое Docker Compose `Docker Compose` — это инструмент для управления несколькими контейнерами как единым приложением. Обычно в проекте есть файл `docker-compose.yml`, где описано: * какие сервисы нужно запускать * какие образы использовать * какие порты пробрасывать * какие папки подключать как volumes * какие переменные окружения передавать контейнерам Например, один проект может состоять из: * `nginx` * `php` * `mysql` * `redis` Вместо того чтобы запускать каждый контейнер отдельно длинными командами `docker run`, Compose позволяет поднять всё одной командой. --- ### Перед началом работы Обычно работа с Compose ведётся из директории проекта, где лежит `docker-compose.yml`. Пример: ```bash cd /opt/flamy_projects/project_name ``` Проверить, что файл действительно есть в текущей папке: ```bash ls -la ``` Если нужно найти compose-файлы во всей папке проектов: ```bash find /opt/flamy_projects -type f -name "docker-compose*.yml" ``` > **Примечание:** > Большинство команд `docker compose` нужно выполнять именно в той директории, где находится `docker-compose.yml`. Иначе Docker не поймёт, с каким проектом работать. --- ### Базовый принцип работы Чаще всего цикл работы выглядит так: 1. перейти в папку проекта 2. запустить сервисы 3. проверить, что контейнеры работают 4. посмотреть логи при ошибках 5. при необходимости пересобрать или перезапустить сервисы --- ### Запуск сервисов #### Запуск всех сервисов в фоне ```bash docker compose up -d ``` Эта команда: * читает `docker-compose.yml` * создаёт нужные контейнеры * запускает их * оставляет терминал свободным для дальнейшей работы Флаг `-d` означает **detached mode**, то есть запуск в фоне. #### Когда использовать Подходит почти для любого обычного старта проекта: * после перезагрузки сервера * после первого клонирования проекта * после остановки контейнеров * после мелких изменений конфигурации #### Пример ```bash cd /opt/flamy_projects/site1 docker compose up -d ``` #### Что важно помнить Если образа ещё нет локально, Docker попытается: * скачать его из реестра * либо собрать локально, если это описано в конфигурации > **Для новичков:** > `up` не всегда означает просто «включить». Эта команда может не только запускать, но и создавать контейнеры заново, если это требуется по конфигурации. --- ### Остановка и удаление контейнеров проекта #### Остановка проекта ```bash docker compose down ``` Команда останавливает и удаляет: * контейнеры проекта * созданные Compose-сети #### Когда использовать Подходит, если нужно: * полностью выключить проект * освободить ресурсы * заново поднять окружение * сбросить сетевые проблемы внутри проекта #### Что команда **не удаляет** По умолчанию `docker compose down` **не удаляет volumes**. Это важно, потому что именно в volumes часто лежат данные: * база данных * загруженные файлы * кэш приложения * постоянные данные сервисов > **Важно:** > Для новичков это одна из самых полезных вещей: обычный `down` не стирает данные сам по себе. Но всё равно всегда нужно понимать, где именно проект хранит данные — в volumes, bind mounts или внутри контейнера. #### Пример ```bash docker compose down ``` После этого проект можно снова поднять: ```bash docker compose up -d ``` --- ### Принудительное пересоздание контейнеров #### Пересоздать контейнеры даже без изменений ```bash docker compose up -d --force-recreate ``` Эта команда заставляет Docker пересоздать контейнеры, даже если он считает, что ничего не поменялось. #### Когда использовать Полезно, если: * контейнер ведёт себя странно * изменились переменные окружения * конфигурация применена не так, как ожидалось * нужен «чистый» перезапуск контейнера без удаления volumes #### Что важно помнить * контейнеры будут пересозданы * volumes останутся на месте * данные в volumes не пропадут > **Пояснение:** > Контейнер и volume — это не одно и то же. > Контейнер — это «запущенная оболочка приложения». > Volume — это место, где могут лежать постоянные данные. > Поэтому пересоздание контейнера не обязательно означает потерю данных. --- ### Пересборка образов Пересборка нужна тогда, когда меняется не только запуск контейнера, а именно его образ. Обычно это происходит, если вы изменили: * `Dockerfile` * системные пакеты * зависимости приложения * шаги сборки --- #### Пересборка без использования кэша ```bash docker compose build --no-cache ``` Docker при сборке старается использовать кэш, чтобы не выполнять одинаковые шаги повторно. Это ускоряет работу, но иногда мешает, если нужен действительно «чистый» rebuild. Флаг `--no-cache` говорит: **не использовать ранее сохранённые слои**, а собрать всё заново. #### Когда использовать Подходит, если: * изменения в Dockerfile «не подхватываются» * обновились зависимости * есть подозрение на устаревший build cache * нужно убедиться, что образ собран полностью с нуля #### Пример ```bash docker compose build --no-cache docker compose up -d ``` > **Примечание:** > Эта операция может занять заметно больше времени, чем обычная сборка. --- #### Пересобрать и сразу запустить ```bash docker compose up -d --build ``` Команда делает два действия сразу: 1. при необходимости пересобирает образ 2. запускает контейнеры #### Когда использовать Это один из самых частых сценариев после изменения: * `Dockerfile` * зависимостей * конфигурации сборки #### Пример ```bash docker compose up -d --build ``` #### Чем отличается от `build --no-cache` * `docker compose up -d --build` может использовать кэш * `docker compose build --no-cache` собирает всё полностью заново Если нужно просто обновить контейнер после обычных изменений — чаще хватает: ```bash docker compose up -d --build ``` Если есть сомнения в корректности кэша — используйте: ```bash docker compose build --no-cache docker compose up -d ``` --- ### Обновление образов из реестра #### Скачать свежие версии образов ```bash docker compose pull ``` Команда скачивает новые версии образов, которые указаны в `docker-compose.yml`. #### Когда использовать Подходит, если проект использует готовые образы из registry, например: * `nginx:latest` * `redis:7` * `mysql:8` #### Важный момент `docker compose pull` **только скачивает образы**, но **не перезапускает контейнеры автоматически**. Чтобы применить обновление, обычно выполняют: ```bash docker compose pull && docker compose up -d ``` #### Пример ```bash cd /opt/flamy_projects/site1 docker compose pull docker compose up -d ``` > **Важно:** > На production-серверах обновление образов нужно делать осторожно. Новая версия образа может изменить поведение приложения или сломать совместимость. --- ### Перезапуск сервисов Иногда контейнер не нужно пересобирать или пересоздавать — достаточно просто перезапустить процесс. --- #### Перезапуск одного сервиса ```bash docker compose restart ``` Пример: ```bash docker compose restart nginx ``` #### Когда использовать Подходит, если: * сервис завис * нужно перечитать конфигурацию * произошёл временный сбой * после некоторых изменений достаточно обычного рестарта --- #### Перезапуск всех сервисов ```bash docker compose restart ``` Перезапускает все сервисы, описанные в compose-файле. #### Когда использовать Подходит, если: * нужно быстро перезапустить весь проект * нет уверенности, какой именно сервис работает некорректно * нужно «освежить» всё окружение без удаления контейнеров --- #### Остановка и запуск отдельного сервиса вручную ```bash docker compose stop && docker compose start ``` Пример: ```bash docker compose stop php && docker compose start php ``` #### Зачем это нужно, если есть `restart` Иногда удобнее разделить действия на две части: * сначала корректно остановить контейнер * затем отдельно запустить снова Это бывает полезно при диагностике или когда нужно убедиться, что сервис полностью остановился. --- ### Запуск только одного сервиса ```bash docker compose up -d ``` Пример: ```bash docker compose up -d nginx ``` #### Когда использовать Полезно, если: * нужно поднять только один сервис * вы тестируете конкретный контейнер * не хотите трогать всё окружение > **Примечание:** > Если сервис зависит от других, Compose может поднять и их тоже. --- ### Проверка итоговой конфигурации #### Посмотреть итоговый compose-конфиг ```bash docker compose config ``` Эта команда показывает итоговую конфигурацию после обработки: * `docker-compose.yml` * override-файлов * переменных окружения * подстановок из `.env` #### Когда использовать Очень полезно перед запуском, если: * не подставляются env-переменные * есть сомнения в корректности конфигурации * нужно понять, что Docker реально «видит» #### Почему это важно для новичков Иногда в YAML всё выглядит правильно, но итоговая конфигурация получается другой. `docker compose config` помогает увидеть конечный результат до запуска. --- ### Наиболее частые сценарии в работе #### Обычный запуск проекта ```bash docker compose up -d ``` --- #### Обновить образы и применить изменения ```bash docker compose pull && docker compose up -d ``` --- #### После изменения Dockerfile или зависимостей ```bash docker compose up -d --build ``` --- #### Полная пересборка без кэша ```bash docker compose build --no-cache docker compose up -d ``` --- #### Быстро перезапустить один сервис ```bash docker compose restart nginx ``` --- #### Полностью выключить проект ```bash docker compose down ``` --- ### Что выбрать в типовых ситуациях #### Ситуация: нужно просто запустить проект Используйте: ```bash docker compose up -d ``` --- #### Ситуация: поменялся Dockerfile Используйте: ```bash docker compose up -d --build ``` --- #### Ситуация: образ ведёт себя странно, нужен чистый rebuild Используйте: ```bash docker compose build --no-cache docker compose up -d ``` --- #### Ситуация: нужно скачать свежие образы из registry Используйте: ```bash docker compose pull && docker compose up -d ``` --- #### Ситуация: сервис просто нужно перезапустить Используйте: ```bash docker compose restart ``` --- ### Частые ошибки новичков #### Запуск команды не из той директории Если выполнить `docker compose up -d` не там, где лежит `docker-compose.yml`, можно получить ошибку о том, что конфигурационный файл не найден. --- #### Путаница между `restart`, `up`, `build` и `down` Кратко: * `restart` — просто перезапуск уже существующих контейнеров * `up` — поднять проект * `up --build` — поднять проект с пересборкой * `down` — остановить и удалить контейнеры проекта --- #### Ожидание, что `pull` сам обновит работающие контейнеры `docker compose pull` только скачивает новый образ. Чтобы контейнеры начали работать на новой версии, нужен ещё запуск: ```bash docker compose up -d ``` --- ### Краткая памятка ```bash docker compose up -d # Запуск проекта в фоне docker compose down # Остановка и удаление контейнеров проекта docker compose up -d --force-recreate # Пересоздать контейнеры принудительно docker compose build --no-cache # Полная пересборка без кэша docker compose up -d --build # Пересборка и запуск docker compose pull # Скачать свежие образы docker compose restart # Перезапуск одного сервиса docker compose restart # Перезапуск всех сервисов docker compose stop && docker compose start # Остановить и запустить сервис отдельно docker compose up -d # Запуск одного сервиса docker compose config # Проверка итоговой конфигурации ``` # Docker — Отладка контейнеров Эта страница объясняет основные команды Docker, которые используются для диагностики и отладки контейнеров. Здесь разобраны способы посмотреть запущенные контейнеры, проверить их состояние, изучить логи, подключиться внутрь контейнера и выполнить команды для анализа проблемы. Материал рассчитан на начинающих и помогает быстро понять, **что происходит внутри контейнера**, если приложение работает некорректно. --- # Когда используется отладка контейнеров На практике команды из этой страницы используются в следующих ситуациях: * контейнер **не запускается** * сервис **падает после старта** * приложение **возвращает ошибки** * сервис **не отвечает** * контейнер **постоянно перезапускается** * нужно проверить **что происходит внутри контейнера** Типичный порядок диагностики: 1. проверить список контейнеров 2. проверить статус контейнера 3. посмотреть логи 4. зайти внутрь контейнера 5. проверить процессы или выполнить команды --- # Просмотр контейнеров ## Показать контейнеры текущего проекта ```bash docker compose ps ``` Команда показывает контейнеры, которые относятся к текущему `docker-compose` проекту. Пример вывода: ``` NAME IMAGE STATUS PORTS project_nginx nginx:latest Up 2 hours 0.0.0.0:80->80/tcp project_php php:8.2-fpm Up 2 hours ``` ### Что здесь можно увидеть * имя контейнера * используемый образ * статус контейнера * проброшенные порты ### Когда использовать Это первая команда, которую стоит выполнить, если нужно проверить: * запущен ли сервис * работает ли контейнер * не упал ли он --- ## Показать все запущенные контейнеры ```bash docker ps ``` Эта команда показывает **все запущенные контейнеры в системе**, независимо от проекта. Пример: ``` CONTAINER ID IMAGE STATUS PORTS ab12cd34 nginx Up 2 hours 80/tcp cd34ef56 redis Up 3 hours 6379/tcp ``` ### Чем отличается от `docker compose ps` | Команда | Показывает | | ------------------- | --------------------------- | | `docker compose ps` | контейнеры текущего проекта | | `docker ps` | все контейнеры на сервере | --- ## Показать все контейнеры (включая остановленные) ```bash docker ps -a ``` Показывает: * работающие контейнеры * остановленные контейнеры * контейнеры с ошибками Пример статуса: ``` Exited (1) 5 minutes ago ``` ### Что это означает Контейнер **запустился, но приложение внутри завершилось с ошибкой**. В таком случае следующим шагом нужно посмотреть логи. --- ## Табличный формат вывода ```bash docker ps -a --format "table {{.ID}}\t{{.Names}}\t{{.Status}}\t{{.Ports}}" ``` Этот формат удобен, если нужно быстро увидеть: * ID контейнера * имя * статус * порты Пример вывода: ``` CONTAINER ID NAMES STATUS PORTS 3acb1234 project_php Up 10 minutes 7d8e5678 project_nginx Up 10 minutes 80/tcp ``` --- # Просмотр логов контейнеров Логи — это основной источник информации при отладке. Именно здесь можно увидеть: * ошибки приложения * ошибки запуска * проблемы подключения к базе * ошибки конфигурации --- ## Просмотр логов сервиса ```bash docker compose logs ``` Пример: ```bash docker compose logs nginx ``` Вывод покажет весь лог контейнера. --- ## Просмотр логов в реальном времени ```bash docker compose logs -f ``` Флаг `-f` означает **follow** — следить за логом в реальном времени. Пример: ```bash docker compose logs -f php ``` Это удобно, если: * вы только что перезапустили сервис * нужно увидеть новые ошибки Выход из режима просмотра: ``` CTRL + C ``` --- ## Показать последние строки логов ```bash docker compose logs --tail=100 ``` Показывает только последние 100 строк. Пример: ```bash docker compose logs --tail=100 nginx ``` ### Когда использовать Если контейнер работает давно и лог очень большой. --- ## Логи с временными метками ```bash docker compose logs --timestamps ``` Пример: ```bash docker compose logs --timestamps php ``` Вывод будет выглядеть примерно так: ``` 2026-03-11T12:32:10 app started 2026-03-11T12:32:11 connected to database ``` Это удобно для анализа событий во времени. --- # Подключение внутрь контейнера Иногда для диагностики нужно **зайти внутрь контейнера**, чтобы: * посмотреть файлы * проверить конфигурацию * выполнить команды * проверить сетевые подключения --- ## Подключиться через shell ```bash docker compose exec sh ``` Пример: ```bash docker compose exec php sh ``` После выполнения команды вы окажетесь внутри контейнера. --- ## Использование bash Если в контейнере установлен `bash`, можно использовать: ```bash docker compose exec bash ``` Пример: ```bash docker compose exec php bash ``` > **Важно:** > Не во всех контейнерах есть `bash`. Многие минимальные образы используют только `sh`. --- ## Проверить файлы внутри контейнера После входа можно выполнять обычные команды Linux: ``` ls cd cat ps top ``` Например: ``` ls /var/www/html ``` --- # Просмотр процессов внутри контейнера ```bash docker compose top ``` Пример: ```bash docker compose top php ``` Команда показывает список процессов внутри контейнера. Пример вывода: ``` UID PID CMD root 123 php-fpm ``` ### Когда использовать Полезно, если: * приложение зависло * нужно проверить, запущен ли процесс * нужно убедиться, что сервис действительно работает --- # Выполнение команды внутри контейнера Можно выполнить команду **без входа в shell**. Формат: ```bash docker compose exec ``` Пример: ```bash docker compose exec php php -v ``` Вывод: ``` PHP 8.2.4 (cli) ``` --- ### Ещё примеры Проверить установленные пакеты: ```bash docker compose exec php composer --version ``` Проверить Node.js: ```bash docker compose exec node node -v ``` --- # Копирование файлов из контейнера Иногда нужно забрать файл из контейнера. --- ## Копирование файла из контейнера ```bash docker cp container:/path/file . ``` Пример: ```bash docker cp project_php:/var/log/php.log . ``` Файл будет скопирован в текущую папку. --- ## Копирование файла в контейнер ```bash docker cp file container:/path/ ``` Пример: ```bash docker cp config.php project_php:/var/www/config.php ``` --- # Типичный сценарий диагностики Если сервис не работает, обычно делают следующее: ### 1 Проверить контейнеры ```bash docker compose ps ``` --- ### 2 Проверить логи ```bash docker compose logs --tail=100 ``` --- ### 3 Если ошибка не очевидна — подключиться внутрь ```bash docker compose exec php sh ``` --- ### 4 Проверить процессы ```bash docker compose top php ``` --- ### 5 Проверить приложение вручную Например: ``` curl localhost ``` --- # Полезные советы для новичков ## Всегда начинайте диагностику с логов В большинстве случаев ошибка уже записана в лог. --- ## Не путайте контейнер и сервис В Compose: * **service** — описание контейнера в `docker-compose.yml` * **container** — фактически запущенный экземпляр --- ## Проверяйте статус контейнера Если статус: ``` Exited ``` контейнер уже остановился, и нужно смотреть логи. --- # Краткая памятка ```bash docker compose ps # контейнеры текущего проекта docker ps # все запущенные контейнеры docker ps -a # все контейнеры включая остановленные docker compose logs # логи сервиса docker compose logs -f # логи в реальном времени docker compose logs --tail=100 # последние строки логов docker compose logs --timestamps # логи с временными метками docker compose exec sh # войти в контейнер docker compose exec bash # войти через bash docker compose exec # выполнить команду docker compose top # процессы контейнера docker cp container:/path/file . # копировать из контейнера docker cp file container:/path/ # копировать в контейнер ``` # Docker Compose — Структура docker-compose.yml Эта страница объясняет структуру файла `docker-compose.yml` и основные параметры, используемые при описании сервисов Docker. Здесь разобраны ключевые разделы конфигурации, такие как `services`, `volumes`, `networks`, `environment`, `ports` и другие. Материал рассчитан на начинающих и помогает понять, **как правильно описывать инфраструктуру приложения в Docker Compose**. --- # Что такое docker-compose.yml `docker-compose.yml` — это файл конфигурации, который описывает: * какие контейнеры нужно запустить * какие образы использовать * какие порты открыть * какие volumes подключить * какие сети создать Compose позволяет запускать всё приложение **одной командой**: ```bash docker compose up -d ``` --- # Базовая структура docker-compose.yml Пример минимального файла: ```yaml version: "3.9" services: nginx: image: nginx:1.25 ports: - "8080:80" ``` Этот файл создаёт контейнер nginx и открывает порт `8080`. --- # Основные разделы docker-compose.yml Типичная структура файла выглядит так: ```yaml services: volumes: networks: ``` --- # Раздел services Раздел `services` описывает контейнеры проекта. Пример: ```yaml services: nginx: image: nginx:1.25 php: image: php:8.2-fpm ``` В этом примере создаются два сервиса: * nginx * php Каждый сервис становится отдельным контейнером. --- # Параметр image Определяет Docker-образ, который будет использоваться. Пример: ```yaml services: nginx: image: nginx:1.25 ``` Docker скачает образ `nginx:1.25`, если он отсутствует. --- # Параметр build Используется, если образ нужно **собрать локально из Dockerfile**. Пример: ```yaml services: app: build: . ``` Это означает: ```text собрать образ из Dockerfile текущей директории ``` Можно указать путь: ```yaml services: app: build: ./app ``` --- # Параметр ports Используется для проброса портов. Пример: ```yaml ports: - "8080:80" ``` Это означает: ```text сервер:8080 → контейнер:80 ``` После запуска приложение будет доступно: ``` http://server:8080 ``` --- # Параметр volumes Подключает volumes или папки сервера. Пример: ```yaml volumes: - ./src:/var/www/html ``` Это означает: ```text сервер ./src → контейнер /var/www/html ``` --- # Использование Docker Volumes Пример с volume: ```yaml services: mysql: image: mysql:8 volumes: - mysql_data:/var/lib/mysql volumes: mysql_data: ``` Volume будет хранить данные базы. --- # Параметр environment Передаёт переменные окружения контейнеру. Пример: ```yaml environment: MYSQL_ROOT_PASSWORD: secret MYSQL_DATABASE: app_db ``` Контейнер получит переменные: ``` MYSQL_ROOT_PASSWORD MYSQL_DATABASE ``` --- # Использование .env файла Переменные можно хранить в `.env`. Пример: ```text DB_PASSWORD=secret APP_ENV=production ``` И использовать в Compose: ```yaml environment: DB_PASSWORD: ${DB_PASSWORD} ``` --- # Параметр depends_on Определяет зависимости между сервисами. Пример: ```yaml services: php: depends_on: - mysql ``` Это означает: ```text сначала запускается mysql затем php ``` > **Важно:** > `depends_on` не гарантирует, что сервис полностью готов к работе. --- # Параметр restart Определяет политику перезапуска контейнера. Пример: ```yaml restart: always ``` Возможные значения: | Значение | Поведение | | -------------- | ----------------------------------------- | | no | не перезапускать | | always | всегда перезапускать | | on-failure | только при ошибке | | unless-stopped | перезапускать, пока не остановлен вручную | --- # Параметр networks Определяет сети Docker. Пример: ```yaml services: app: networks: - backend networks: backend: ``` Контейнер будет подключён к сети `backend`. --- # Пример полного docker-compose.yml Пример простого веб-приложения: ```yaml services: nginx: image: nginx:1.25 ports: - "80:80" volumes: - ./src:/var/www/html php: image: php:8.2-fpm volumes: - ./src:/var/www/html depends_on: - mysql mysql: image: mysql:8 environment: MYSQL_ROOT_PASSWORD: root MYSQL_DATABASE: app volumes: - mysql_data:/var/lib/mysql volumes: mysql_data: ``` Этот файл запускает: * nginx * php * mysql --- # Проверка docker-compose.yml Перед запуском полезно проверить конфигурацию: ```bash docker compose config ``` Команда покажет итоговую конфигурацию после обработки переменных. --- # Запуск проекта Запуск всех сервисов: ```bash docker compose up -d ``` --- # Остановка проекта ```bash docker compose down ``` --- # Типичные ошибки в docker-compose.yml ## Ошибка YAML Файл YAML чувствителен к отступам. Неправильно: ```yaml services: nginx: image: nginx ``` Правильно: ```yaml services: nginx: image: nginx ``` --- ## Неверные порты Если порт уже используется: ```text Bind for 0.0.0.0:80 failed ``` Нужно изменить порт. --- ## Отсутствие volumes Если данные не вынесены в volumes, они могут потеряться при пересоздании контейнера. --- # Краткая памятка ```text services → контейнеры проекта image → используемый образ build → сборка образа ports → проброс портов volumes → подключение хранилища environment → переменные окружения depends_on → зависимости сервисов restart → политика перезапуска networks → сети контейнеров ``` # Глава 2 — Диагностика и обслуживание # Docker — Мониторинг и использование ресурсов Эта страница объясняет, как отслеживать использование ресурсов Docker и как управлять дисковым пространством, занятым контейнерами, образами и volumes. Здесь разобраны команды для просмотра нагрузки на CPU и память, анализа использования диска, а также безопасной очистки неиспользуемых ресурсов. Материал ориентирован на начинающих и помогает понять, **почему Docker может занимать много места на диске или ресурсов системы** и как это контролировать. --- # Почему важно следить за ресурсами Docker Docker активно использует ресурсы системы: * CPU * оперативную память (RAM) * дисковое пространство * сетевые ресурсы Со временем на сервере могут накапливаться: * старые контейнеры * неиспользуемые образы * volumes с данными * временные слои сборки Если их не очищать, Docker может занять **десятки или даже сотни гигабайт дискового пространства**. Поэтому регулярный мониторинг и очистка — важная часть администрирования Docker. --- # Просмотр нагрузки контейнеров ## Просмотр использования ресурсов в реальном времени ```bash docker stats ``` Эта команда показывает статистику всех работающих контейнеров. Пример вывода: ``` CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O a12bc34d project_php 2.5% 120MiB / 2GiB 5.8% 1.2MB / 500KB b45de67f project_nginx 0.2% 15MiB / 2GiB 0.7% 200KB / 100KB ``` ### Что показывает эта команда | Поле | Описание | | --------- | ------------------------------- | | CPU % | загрузка процессора контейнером | | MEM USAGE | используемая память | | MEM % | процент от доступной памяти | | NET I/O | сетевой трафик | ### Когда использовать Полезно, если: * сервер начал тормозить * приложение потребляет слишком много ресурсов * нужно найти контейнер с высокой нагрузкой --- ## Проверка ресурсов одного контейнера ```bash docker stats --no-stream ``` Флаг `--no-stream` выводит статистику **один раз**, без постоянного обновления. Пример: ```bash docker stats --no-stream project_php ``` Это удобно, если нужно быстро проверить текущую нагрузку. --- # Проверка процессов внутри контейнера Иногда нагрузку создаёт конкретный процесс. Можно посмотреть процессы внутри контейнера: ```bash docker compose top ``` Пример: ```bash docker compose top php ``` Вывод покажет процессы, которые выполняются внутри контейнера. Это помогает определить, что именно создаёт нагрузку: * веб-сервер * PHP-процесс * worker * cron-задача --- # Проверка использования диска Docker ## Посмотреть сколько места занимает Docker ```bash docker system df ``` Пример вывода: ``` TYPE TOTAL ACTIVE SIZE Images 12 4 3.2GB Containers 8 4 120MB Local Volumes 6 5 5.6GB Build Cache - - 2.1GB ``` ### Что означает каждая строка | Тип | Описание | | ----------- | ----------------- | | Images | Docker-образы | | Containers | контейнеры | | Volumes | постоянные данные | | Build Cache | кэш сборки Docker | ### Когда использовать Эта команда помогает понять: * почему Docker занимает много места * какие ресурсы занимают больше всего диска --- ## Подробная информация об использовании диска ```bash docker system df -v ``` Флаг `-v` (verbose) показывает более подробную информацию: * какие именно образы занимают место * какие контейнеры используют volumes * какие слои можно удалить --- # Очистка неиспользуемых ресурсов Со временем Docker оставляет множество временных объектов: * остановленные контейнеры * старые образы * временные сети * build cache Их можно безопасно удалить. --- # Удаление неиспользуемых образов ```bash docker image prune -f ``` Удаляет **dangling images** — образы, которые больше не используются контейнерами. ### Когда использовать Если после сборок осталось много старых образов. --- # Полная очистка Docker ```bash docker system prune -f ``` Удаляет: * остановленные контейнеры * неиспользуемые сети * dangling images * build cache ### Важно понимать Эта команда **не удаляет volumes**. То есть: * базы данных * файлы проекта * persistent storage останутся на месте. --- # Очистка volumes ```bash docker volume prune -f ``` Удаляет **неиспользуемые volumes**. ### Осторожно Volumes могут содержать: * базы данных * пользовательские файлы * кэш приложения Поэтому перед удалением нужно убедиться, что volume действительно не используется. --- # Очистка сетей ```bash docker network prune -f ``` Удаляет неиспользуемые Docker-сети. Эта команда безопасна, потому что: * сети удаляются только если они не используются контейнерами --- # Проверка ресурсов Docker Engine Иногда полезно посмотреть информацию о самой Docker-системе. --- ## Проверка доступной памяти ```bash docker info | grep -i memory ``` Показывает информацию о памяти, доступной Docker. --- ## Проверка CPU ```bash docker info | grep -i cpu ``` Показывает количество доступных CPU. --- # Проверка лимитов контейнера Некоторые контейнеры могут иметь ограничения по памяти. Проверить это можно так: ```bash docker inspect | grep -i memory ``` Пример: ```bash docker inspect project_php | grep -i memory ``` Эта команда покажет: * лимит памяти * настройки использования RAM --- # Типичные проблемы с ресурсами ## Docker занимает слишком много места Самая частая причина — накопившиеся: * старые образы * build cache * остановленные контейнеры Решение: ```bash docker system prune -f ``` --- ## Заполнен диск сервера Проверить использование: ```bash docker system df ``` Затем очистить ненужные данные. --- ## Контейнер использует слишком много CPU Найти контейнер: ```bash docker stats ``` После этого: * проверить логи * посмотреть процессы внутри контейнера --- ## Контейнер использует слишком много памяти Возможные причины: * утечка памяти * неправильная конфигурация приложения * слишком большие кэши Проверить: ```bash docker stats ``` --- # Рекомендуемая регулярная очистка На серверах разработки полезно периодически выполнять: ```bash docker system prune -f ``` Если используется активная сборка образов: ```bash docker builder prune -f ``` --- # Типичный сценарий диагностики Если сервер начал тормозить: ### 1 Проверить контейнеры ```bash docker stats ``` --- ### 2 Проверить диск ```bash docker system df ``` --- ### 3 Очистить ненужные данные ```bash docker system prune -f ``` --- ### 4 Проверить снова ```bash docker system df ``` --- # Краткая памятка ```bash docker stats # нагрузка контейнеров в реальном времени docker stats --no-stream # разовая статистика docker compose top # процессы внутри контейнера docker system df # использование диска Docker docker system df -v # подробная информация docker image prune -f # удалить неиспользуемые образы docker system prune -f # очистка контейнеров, сетей и cache docker volume prune -f # удалить неиспользуемые volumes docker network prune -f # удалить неиспользуемые сети docker info | grep -i memory # информация о памяти docker info | grep -i cpu # информация о CPU docker inspect | grep -i memory # лимиты контейнера ``` # Docker — Работа с сетями (Networks) Эта страница объясняет, как Docker управляет сетями и как контейнеры взаимодействуют друг с другом. Здесь разобраны основные команды для просмотра сетей, диагностики сетевых проблем и проверки портов сервисов. Материал ориентирован на начинающих и помогает понять, **как контейнеры находят друг друга внутри Docker-проекта и как сервисы становятся доступными снаружи**. --- # Как работают сети в Docker По умолчанию каждый контейнер подключается к одной или нескольким Docker-сетям. Сеть позволяет контейнерам: * общаться друг с другом по имени сервиса * передавать данные между сервисами * изолировать проекты друг от друга Например, в одном проекте могут работать контейнеры: * `nginx` * `php` * `mysql` * `redis` Все они находятся в одной сети и могут обращаться друг к другу по имени сервиса: ``` php -> mysql php -> redis nginx -> php ``` Пример подключения к базе внутри контейнера: ``` mysql:3306 ``` Где `mysql` — имя сервиса из `docker-compose.yml`. --- # Список Docker-сетей ## Показать все сети ```bash docker network ls ``` Пример вывода: ``` NETWORK ID NAME DRIVER 9a8b7c6d5e bridge bridge 8f7e6d5c4b host host 7e6d5c4b3a project_default bridge ``` ### Что означает каждая сеть | Сеть | Назначение | | --------------- | ------------------------------- | | bridge | стандартная сеть Docker | | host | контейнер использует сеть хоста | | project_default | сеть Docker Compose проекта | --- # Сеть Docker Compose Когда запускается проект через: ```bash docker compose up -d ``` Docker автоматически создаёт сеть: ``` projectname_default ``` Например: ``` site1_default ``` Все сервисы из `docker-compose.yml` автоматически подключаются к этой сети. Это позволяет контейнерам обращаться друг к другу **по имени сервиса**. --- # Проверка сети проекта ## Посмотреть информацию о сети ```bash docker network inspect ``` Пример: ```bash docker network inspect site1_default ``` Эта команда показывает: * подключенные контейнеры * IP-адреса контейнеров * настройки сети --- ## Пример вывода Внутри результата можно увидеть блок: ``` "Containers": { "php_container": { "Name": "site1_php", "IPv4Address": "172.20.0.3" }, "mysql_container": { "Name": "site1_mysql", "IPv4Address": "172.20.0.4" } } ``` Это означает, что контейнеры подключены к сети и могут взаимодействовать. --- # Проверка портов сервисов Контейнер может быть доступен: * **внутри Docker-сети** * **снаружи сервера** Для доступа извне используются **проброшенные порты**. --- ## Проверить порт сервиса ```bash docker compose port ``` Пример: ```bash docker compose port nginx 80 ``` Результат: ``` 0.0.0.0:8080 ``` Это означает, что контейнерный порт `80` доступен на сервере через порт `8080`. --- # Проверка портов через docker ps Можно также проверить порты так: ```bash docker ps ``` Пример вывода: ``` CONTAINER ID IMAGE PORTS ab12cd34 nginx 0.0.0.0:8080->80/tcp ``` Это означает: ``` сервер:8080 -> контейнер:80 ``` --- # Подключение контейнера к сети Иногда контейнер нужно подключить к существующей сети. ## Подключить контейнер ```bash docker network connect ``` Пример: ```bash docker network connect site1_default redis_container ``` После этого контейнер сможет взаимодействовать с сервисами сети. --- # Отключение контейнера от сети ```bash docker network disconnect ``` Пример: ```bash docker network disconnect site1_default redis_container ``` Контейнер больше не сможет общаться с сервисами этой сети. --- # Проверка сетевого доступа внутри контейнера Если сервисы не могут взаимодействовать, нужно проверить соединение. ## Подключиться к контейнеру ```bash docker compose exec php sh ``` --- ## Проверить доступ к другому сервису Например, проверить базу данных: ```bash ping mysql ``` или ```bash nc -zv mysql 3306 ``` Если соединение работает — сеть настроена правильно. --- # Проверка DNS внутри Docker Docker автоматически создаёт DNS внутри сети. Это позволяет обращаться к сервисам **по имени**. Например: ``` mysql redis php nginx ``` --- ## Проверить DNS Внутри контейнера: ```bash nslookup mysql ``` или ```bash ping mysql ``` Если DNS работает, контейнер получит IP. --- # Типичные сетевые проблемы ## Контейнеры не видят друг друга Возможные причины: * контейнеры находятся в разных сетях * неправильное имя сервиса * сервис не запущен Проверить: ```bash docker network inspect ``` --- ## Неверное имя сервиса В Docker Compose нужно использовать **имя сервиса**, а не имя контейнера. Пример: ``` mysql ``` а не: ``` project_mysql_1 ``` --- ## Порт не доступен снаружи Проверить `docker-compose.yml`. Пример правильного проброса: ```yaml ports: - "8080:80" ``` Это означает: ``` сервер:8080 -> контейнер:80 ``` --- ## Контейнер запущен, но сайт не открывается Проверить: ```bash docker ps ``` Если порт не указан — он не проброшен наружу. --- # Типичный сценарий диагностики сети Если сервис не работает: ### 1 Проверить контейнеры ```bash docker compose ps ``` --- ### 2 Проверить сеть ```bash docker network ls ``` --- ### 3 Проверить подключенные контейнеры ```bash docker network inspect ``` --- ### 4 Проверить DNS внутри контейнера ```bash docker compose exec php ping mysql ``` --- # Краткая памятка ```bash docker network ls # список сетей docker network inspect # информация о сети docker compose port # проверить проброс порта docker network connect # подключить контейнер docker network disconnect # отключить контейнер docker ps # посмотреть проброшенные порты ``` # Docker — Logs (Работа с логами) Эта страница объясняет, как Docker хранит и обрабатывает логи контейнеров. Здесь разобраны команды для просмотра логов, способы ограничения их размера, настройка log rotation и рекомендации по работе с логами в production. Материал рассчитан на начинающих и помогает понять, **где хранятся Docker-логи и как предотвратить переполнение диска из-за их роста**. --- # Что такое Docker Logs Каждый контейнер записывает стандартные потоки вывода: * **stdout** — обычные сообщения * **stderr** — ошибки Docker автоматически сохраняет эти данные как **логи контейнера**. Пример логов: ```text [INFO] Server started [INFO] Connection established [ERROR] Database connection failed ``` Логи помогают: * диагностировать ошибки * отслеживать работу приложения * анализировать поведение сервисов --- # Просмотр логов контейнера ## Показать логи контейнера ```bash docker logs ``` Пример: ```bash docker logs nginx_container ``` --- ## Показать последние строки логов ```bash docker logs --tail=100 ``` Пример: ```bash docker logs --tail=100 nginx_container ``` Это покажет последние 100 строк логов. --- ## Просмотр логов в реальном времени ```bash docker logs -f ``` Пример: ```bash docker logs -f nginx_container ``` Флаг `-f` означает **follow** — поток логов в реальном времени. Выход из режима просмотра: ``` CTRL + C ``` --- # Логи Docker Compose Если используется Docker Compose, можно смотреть логи сервисов. --- ## Логи сервиса ```bash docker compose logs ``` Пример: ```bash docker compose logs nginx ``` --- ## Логи в реальном времени ```bash docker compose logs -f ``` --- ## Последние строки логов ```bash docker compose logs --tail=100 ``` --- # Где Docker хранит логи По умолчанию Docker использует драйвер логирования: ```text json-file ``` Файлы логов находятся в директории: ```text /var/lib/docker/containers/ ``` Пример пути: ```text /var/lib/docker/containers//-json.log ``` Эти файлы могут со временем **значительно увеличиваться**. --- # Проверка размера логов Если диск сервера заполняется, одной из причин могут быть логи контейнеров. Проверить размер можно так: ```bash du -sh /var/lib/docker/containers/* ``` Это покажет размер логов каждого контейнера. --- # Ограничение размера логов Чтобы логи не занимали весь диск, можно настроить **log rotation**. --- # Настройка логов в docker-compose.yml Пример конфигурации: ```yaml services: app: image: my_app logging: driver: "json-file" options: max-size: "10m" max-file: "3" ``` --- # Что означают параметры | Параметр | Назначение | | -------- | ------------------------------- | | max-size | максимальный размер файла логов | | max-file | количество файлов | Пример выше означает: ```text максимум 3 файла по 10 MB ``` То есть максимум: ``` 30 MB логов ``` --- # Глобальная настройка логов Docker Ограничение логов можно задать для всего Docker. Файл конфигурации: ```text /etc/docker/daemon.json ``` Пример: ```json { "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } } ``` После изменения нужно перезапустить Docker: ```bash sudo systemctl restart docker ``` --- # Очистка логов контейнера Иногда логи могут стать очень большими. Можно очистить файл логов: ```bash truncate -s 0 /var/lib/docker/containers//-json.log ``` > **Важно:** > Очищать логи нужно осторожно и только при необходимости. --- # Проверка драйвера логирования Можно посмотреть настройки логирования контейнера: ```bash docker inspect ``` В выводе нужно найти раздел: ```text LogConfig ``` --- # Альтернативные драйверы логирования Docker поддерживает разные драйверы логов. | Драйвер | Назначение | | --------- | -------------------- | | json-file | стандартный | | syslog | системный лог | | journald | systemd | | fluentd | централизованный лог | | gelf | Graylog | Для production часто используют централизованные системы логирования. --- # Типичные проблемы с логами ## Логи занимают весь диск Если log rotation не настроен, файлы логов могут вырасти до нескольких гигабайт. Решение: * настроить `max-size` * настроить `max-file` --- ## Слишком много логов Некоторые приложения пишут слишком подробные логи. Решение: * уменьшить уровень логирования * использовать `INFO` вместо `DEBUG` --- ## Невозможно найти ошибку Иногда полезно посмотреть логи нескольких сервисов: ```bash docker compose logs ``` --- # Типичный сценарий диагностики Если сервис не работает: ### 1 Проверить контейнер ```bash docker compose ps ``` --- ### 2 Посмотреть логи ```bash docker compose logs --tail=100 ``` --- ### 3 Следить за логами ```bash docker compose logs -f ``` --- # Краткая памятка ```bash docker logs # логи контейнера docker logs -f # логи в реальном времени docker logs --tail=100 # последние строки docker compose logs # логи всех сервисов docker compose logs -f # логи сервиса du -sh /var/lib/docker/containers/* # размер логов truncate -s 0 logfile # очистить лог ``` # Docker — Cleanup (Очистка и обслуживание) Эта страница описывает команды и практики очистки Docker-окружения. Со временем на сервере накапливаются остановленные контейнеры, старые образы, build-cache и неиспользуемые volumes. Здесь разобраны способы безопасной очистки этих ресурсов и рекомендации по регулярному обслуживанию Docker-системы. --- # Почему Docker со временем занимает много места При работе Docker постоянно создаёт временные и устаревшие ресурсы: * остановленные контейнеры * старые образы * build cache после сборок * неиспользуемые сети * volumes с данными Если их не удалять, они могут занять **десятки гигабайт диска**. --- # Проверка использования диска Docker Перед очисткой полезно проверить, сколько места занимает Docker. ```bash id="7p0vfd" docker system df ``` Пример вывода: ```text id="ny1s4p" TYPE TOTAL ACTIVE SIZE Images 12 5 3.4GB Containers 8 4 150MB Local Volumes 6 4 8.2GB Build Cache - - 2.1GB ``` Это показывает: * сколько образов хранится * сколько контейнеров существует * сколько места занимают volumes * размер build cache --- # Очистка остановленных контейнеров Контейнеры, которые были остановлены, продолжают существовать в системе. Удалить их можно так: ```bash id="r3cqlj" docker container prune ``` Docker попросит подтверждение. Чтобы выполнить без подтверждения: ```bash id="2v9u3n" docker container prune -f ``` --- # Очистка неиспользуемых образов Если контейнеры пересобираются, старые образы остаются в системе. Удалить их можно так: ```bash id="p3h1y1" docker image prune ``` Удаляются **dangling images** — образы без тегов. --- # Удаление всех неиспользуемых образов ```bash id="n0oq1d" docker image prune -a ``` Эта команда удаляет все образы, которые не используются контейнерами. > **Важно:** > После удаления Docker при следующем запуске контейнера может заново скачать образ. --- # Очистка неиспользуемых volumes Volumes могут занимать много места, особенно если в них хранятся базы данных. Удалить неиспользуемые volumes: ```bash id="z3ibk9" docker volume prune ``` Без подтверждения: ```bash id="pcx9o7" docker volume prune -f ``` > **Важно:** > Удаляются только volumes, не подключённые к контейнерам. --- # Очистка сетей Иногда остаются неиспользуемые Docker-сети. Удалить их можно так: ```bash id="v6j8hd" docker network prune ``` --- # Полная очистка Docker Docker предоставляет команду для очистки большинства временных ресурсов. ```bash id="f0e67x" docker system prune ``` Удаляются: * остановленные контейнеры * неиспользуемые сети * dangling images * build cache Без подтверждения: ```bash id="v9qakf" docker system prune -f ``` --- # Полная очистка включая образы ```bash id="z6y9qt" docker system prune -a ``` Удаляются: * все остановленные контейнеры * все неиспользуемые образы * сети * build cache --- # Очистка build cache Build cache создаётся при сборке Docker-образов. Удалить cache можно так: ```bash id="1scnqs" docker builder prune ``` Без подтверждения: ```bash id="8n9y2n" docker builder prune -f ``` --- # Проверка больших Docker-директорий Иногда полезно посмотреть, какие директории занимают больше всего места. ```bash id="2r5y1s" du -sh /var/lib/docker/* ``` Это поможет понять, где именно находятся большие файлы. --- # Регулярная очистка Docker На серверах разработки рекомендуется периодически выполнять: ```bash id="0trvru" docker system prune -f ``` Если активно собираются образы: ```bash id="6a2vpc" docker builder prune -f ``` --- # Пример полной очистки Пример набора команд: ```bash id="l8s5a8" docker container prune -f docker image prune -a -f docker volume prune -f docker network prune -f docker builder prune -f ``` Эти команды удаляют почти все неиспользуемые ресурсы. --- # Типичные проблемы с очисткой ## Удаление volumes с данными Если выполнить: ```bash id="4fr4cf" docker compose down -v ``` Docker удалит **все volumes проекта**, включая базы данных. Поэтому эту команду нужно использовать осторожно. --- ## Удаление образов перед деплоем Если удалить все образы, Docker будет вынужден заново скачивать их из registry. Это может занять время. --- # Когда нужно выполнять очистку Очистку стоит выполнять, если: * диск сервера заполняется * Docker занимает слишком много места * накопилось много старых образов * часто выполняется сборка контейнеров --- # Краткая памятка ```bash id="88duh4" docker system df # использование диска Docker docker container prune # удалить остановленные контейнеры docker image prune # удалить dangling images docker image prune -a # удалить неиспользуемые образы docker volume prune # удалить неиспользуемые volumes docker network prune # удалить неиспользуемые сети docker builder prune # очистить build cache docker system prune # очистка системы Docker docker system prune -a # полная очистка ``` --- # Итог Со временем Docker накапливает большое количество неиспользуемых ресурсов: * контейнеров * образов * volumes * build cache Регулярная очистка системы помогает: * освободить дисковое пространство * поддерживать стабильную работу сервера * избежать проблем с переполнением диска. # Глава 3 — Управление проектами # Docker — Операции с проектами Эта страница описывает базовые операции по управлению Docker-проектами на сервере: организацию директорий, работу с файлами проектов, изменение прав доступа и создание резервных копий. Материал рассчитан на начинающих и помогает понять, **как правильно хранить и обслуживать несколько Docker-проектов на одном сервере**, что особенно актуально для веб-студий и хостинга клиентских проектов. --- # Типичная структура проектов на сервере На серверах с несколькими сайтами или сервисами Docker-проекты обычно размещаются в одной общей директории. Пример структуры: ``` /opt/flamy_projects ``` Внутри неё располагаются отдельные проекты: ``` /opt/flamy_projects │ ├─ site1 │ ├─ docker-compose.yml │ ├─ .env │ ├─ Dockerfile │ └─ src │ ├─ site2 │ ├─ docker-compose.yml │ └─ src │ └─ api_service ├─ docker-compose.yml └─ app ``` Каждый каталог — это **отдельный Docker Compose проект**. --- # Переход в директорию проекта Перед выполнением большинства Docker-команд необходимо перейти в директорию проекта. ```bash cd /opt/flamy_projects ``` Просмотреть содержимое папки: ```bash ls -la ``` ### Когда используется Эта команда помогает: * убедиться, что вы работаете в нужной директории * увидеть список проектов * проверить наличие файлов конфигурации --- # Поиск docker-compose файлов Иногда на сервере много проектов, и нужно найти все compose-файлы. ```bash find /opt/flamy_projects -type f -name "docker-compose*.yml" ``` Эта команда покажет: * все `docker-compose.yml` * дополнительные файлы вроде `docker-compose.prod.yml` Пример результата: ``` /opt/flamy_projects/site1/docker-compose.yml /opt/flamy_projects/site2/docker-compose.yml /opt/flamy_projects/api_service/docker-compose.yml ``` ### Когда полезно * аудит серверов * поиск старых проектов * диагностика конфигураций --- # Проверка файлов проекта Перед запуском проекта полезно проверить содержимое директории. ```bash ls -la ``` Пример: ``` docker-compose.yml .env Dockerfile src/ logs/ ``` ### Что важно проверить * наличие `docker-compose.yml` * наличие `.env` файла * наличие исходного кода Если файл `docker-compose.yml` отсутствует — проект запустить не получится. --- # Изменение владельца файлов Иногда файлы проекта принадлежат неправильному пользователю. Это может происходить, если: * проект копировали через `root` * архив был распакован другим пользователем * файлы были перенесены с другого сервера Исправить владельца можно так: ```bash sudo chown -R Crimson:Crimson /opt/flamy_projects ``` ### Что означает команда | Часть | Значение | | --------------- | -------------------------- | | chown | изменить владельца | | -R | рекурсивно для всех файлов | | Crimson:Crimson | пользователь и группа | --- # Назначение текущего пользователя владельцем Иногда проще назначить владельцем текущего пользователя. ```bash sudo chown -R $(id -u):$(id -g) /opt/flamy_projects ``` ### Что делают параметры | Команда | Значение | | ------- | ------------------------ | | `id -u` | ID текущего пользователя | | `id -g` | ID текущей группы | Это позволяет быстро исправить проблемы с правами. --- # Изменение прав доступа Иногда Docker или приложение не может читать файлы из-за неправильных прав. Исправить можно так: ```bash sudo chmod -R 755 /opt/flamy_projects ``` ### Что означает 755 | Право | Значение | | ----- | -------------------------- | | 7 | чтение, запись, выполнение | | 5 | чтение и выполнение | | 5 | чтение и выполнение | В итоге: * владелец может изменять файлы * остальные пользователи могут читать и выполнять > **Важно:** > Не стоит использовать `777`, так как это даёт полный доступ всем пользователям и может быть небезопасно. --- # Резервное копирование проектов Регулярное резервное копирование помогает защититься от: * ошибок обновления * повреждения данных * случайного удаления файлов --- # Архивирование проекта Создать архив можно с помощью `tar`. ```bash tar -czf flamy_projects_backup_$(date +%Y%m%d).tar.gz /opt/flamy_projects ``` ### Что делает команда | Часть | Значение | | ----- | ------------------------ | | tar | инструмент архивирования | | -c | создать архив | | -z | сжать через gzip | | -f | имя файла | Файл будет иметь имя вроде: ``` flamy_projects_backup_20260311.tar.gz ``` --- # Резервное копирование через rsync `rsync` позволяет копировать файлы между серверами или папками. ```bash rsync -avz /opt/flamy_projects/ backup_location/ ``` ### Что означают параметры | Параметр | Назначение | | -------- | --------------- | | -a | архивный режим | | -v | подробный вывод | | -z | сжатие данных | --- # Пример копирования на другой сервер ```bash rsync -avz /opt/flamy_projects user@backup-server:/backup/docker_projects ``` Это часто используется для: * ежедневных backup * синхронизации серверов * миграции проектов --- # Проверка размера проекта Иногда полезно узнать размер проекта. ```bash du -sh /opt/flamy_projects/* ``` Пример вывода: ``` 1.2G site1 850M site2 430M api_service ``` Это помогает определить: * какие проекты занимают больше всего места * где могут находиться большие логи или кэш --- # Проверка логов проекта Некоторые проекты сохраняют логи внутри директории. Например: ``` logs/ storage/logs var/log ``` Посмотреть последние строки: ```bash tail -n 100 logs/app.log ``` --- # Типичный рабочий процесс Обычно работа с проектом выглядит так: ### 1 Перейти в директорию проекта ```bash cd /opt/flamy_projects/site1 ``` --- ### 2 Проверить файлы ```bash ls -la ``` --- ### 3 Запустить контейнеры ```bash docker compose up -d ``` --- ### 4 Проверить контейнеры ```bash docker compose ps ``` --- ### 5 Проверить логи ```bash docker compose logs --tail=50 ``` --- # Работа с несколькими проектами На сервере может быть десятки проектов. Чтобы понять, какие контейнеры запущены: ```bash docker ps ``` Можно увидеть: ``` site1_nginx site2_php api_service_db ``` Это помогает быстро определить, какие проекты работают. --- # Полезные советы ## Храните проекты в одной директории Это упрощает: * резервное копирование * администрирование * поиск конфигураций --- ## Используйте `.env` файлы В `.env` удобно хранить: * пароли * порты * настройки окружения --- ## Делайте регулярные backup Минимум раз в день для production-серверов. --- # Краткая памятка ```bash cd /opt/flamy_projects # перейти в директорию проектов ls -la # список файлов find /opt/flamy_projects -name "docker-compose*.yml" # найти compose файлы sudo chown -R user:user /opt/flamy_projects # изменить владельца sudo chmod -R 755 /opt/flamy_projects # изменить права tar -czf backup_$(date +%Y%m%d).tar.gz /opt/flamy_projects # архив проекта rsync -avz /opt/flamy_projects/ backup/ # резервная копия du -sh /opt/flamy_projects/* # размер проектов ``` # Docker — Volumes (Хранение данных) Эта страница объясняет, как Docker хранит постоянные данные контейнеров с помощью **Volumes**. Здесь разобраны основные типы хранения данных, команды управления volumes, а также практические примеры резервного копирования и восстановления данных. Материал рассчитан на начинающих и помогает понять, **где Docker хранит данные и как не потерять их при пересоздании контейнеров**. --- # Что такое Docker Volume По умолчанию контейнеры Docker **не сохраняют данные после удаления**. Если контейнер удалить и создать заново, все файлы внутри него исчезнут. Чтобы сохранить данные между перезапусками контейнеров, используются **Volumes**. Volume — это специальное хранилище данных Docker, которое: * существует независимо от контейнера * сохраняет данные между перезапусками * может использоваться несколькими контейнерами --- # Почему volumes важны Volumes используются для хранения **постоянных данных**, например: * базы данных * загруженные пользователями файлы * кэш приложений * логи Пример: ```text mysql container │ └── /var/lib/mysql → volume ``` Если контейнер удалить и создать заново, данные в volume **сохранятся**. --- # Где Docker хранит volumes По умолчанию volumes находятся в системе Docker: ```text /var/lib/docker/volumes/ ``` Каждый volume имеет свою директорию. Пример структуры: ```text /var/lib/docker/volumes/mysql_data/_data ``` --- # Типы хранения данных в Docker Docker поддерживает несколько способов хранения данных. --- ## 1. Docker Volume Это основной и рекомендуемый способ хранения данных. Пример в `docker-compose.yml`: ```yaml services: mysql: image: mysql:8 volumes: - mysql_data:/var/lib/mysql volumes: mysql_data: ``` Преимущества: * безопасное хранение данных * управляется Docker * легко делать backup --- ## 2. Bind Mount Bind mount подключает **обычную папку сервера** внутрь контейнера. Пример: ```yaml services: app: volumes: - ./src:/var/www/html ``` Это означает: ```text сервер ./src → контейнер /var/www/html ``` Используется для: * разработки * подключения исходного кода * конфигурационных файлов --- ## Разница между Volume и Bind Mount | Тип | Описание | | ---------- | --------------------- | | Volume | управляется Docker | | Bind mount | обычная папка сервера | Обычно используется: * **Volumes → данные приложений** * **Bind mounts → код проекта** --- # Просмотр volumes ## Список volumes ```bash docker volume ls ``` Пример вывода: ```text DRIVER VOLUME NAME local site1_mysql_data local redis_cache ``` --- ## Информация о volume ```bash docker volume inspect ``` Пример: ```bash docker volume inspect site1_mysql_data ``` Результат покажет: * путь к volume * драйвер * настройки --- # Создание volume Создать volume можно вручную: ```bash docker volume create mysql_data ``` После этого volume можно использовать в контейнерах. --- # Удаление volumes ## Удалить один volume ```bash docker volume rm ``` Пример: ```bash docker volume rm mysql_data ``` --- ## Удалить неиспользуемые volumes ```bash docker volume prune -f ``` Команда удаляет volumes, которые **не используются контейнерами**. > **Важно:** > Перед удалением нужно убедиться, что volume не содержит важных данных. --- # Использование volumes в Docker Compose Пример конфигурации: ```yaml services: mysql: image: mysql:8 volumes: - mysql_data:/var/lib/mysql volumes: mysql_data: ``` Это создаёт volume `mysql_data`, который будет хранить данные базы. --- # Проверка volumes контейнера Можно посмотреть volumes конкретного контейнера: ```bash docker inspect ``` Пример: ```bash docker inspect site1_mysql ``` В выводе нужно найти блок: ```text Mounts ``` Он показывает подключённые volumes. --- # Резервное копирование volume Очень важная операция — backup данных. --- ## Backup volume ```bash docker run --rm \ -v mysql_data:/data \ -v $(pwd):/backup \ alpine tar czf /backup/mysql_backup.tar.gz /data ``` Эта команда: 1. подключает volume 2. создаёт архив 3. сохраняет backup в текущей директории --- # Восстановление volume Чтобы восстановить данные: ```bash docker run --rm \ -v mysql_data:/data \ -v $(pwd):/backup \ alpine tar xzf /backup/mysql_backup.tar.gz -C / ``` После этого данные снова появятся в volume. --- # Типичные ошибки при работе с volumes ## Потеря данных после удаления контейнера Если данные хранятся **внутри контейнера**, а не в volume, они будут потеряны. Правильная практика: ```yaml volumes: - mysql_data:/var/lib/mysql ``` --- ## Удаление volume вместе с проектом Команда: ```bash docker compose down -v ``` удаляет: * контейнеры * сети * volumes Это приведёт к **потере данных**. --- ## Использование bind mount для базы данных Не рекомендуется хранить базы данных через bind mount. Лучше использовать: ```yaml volumes: - mysql_data:/var/lib/mysql ``` --- # Проверка volumes проекта Показать volumes Compose проекта: ```bash docker compose config --volumes ``` Это помогает понять, какие volumes использует проект. --- # Краткая памятка ```bash docker volume ls # список volumes docker volume inspect # информация о volume docker volume create # создать volume docker volume rm # удалить volume docker volume prune -f # удалить неиспользуемые volumes docker inspect # посмотреть volumes контейнера ``` # Docker — Images (Управление образами) Эта страница объясняет, что такое Docker-образы (Images), как они создаются, хранятся и управляются. Здесь разобраны основные команды для просмотра, загрузки, удаления и очистки образов. Материал рассчитан на начинающих и помогает понять, **как работают Docker-образы и как управлять ими на сервере**. --- # Что такое Docker Image Docker Image — это **шаблон контейнера**, из которого создаются запущенные контейнеры. Проще говоря: ```text Docker Image → контейнер ``` Пример: ```text nginx:1.25 → контейнер nginx mysql:8 → контейнер mysql node:18 → контейнер node ``` Image содержит: * операционную систему * зависимости * приложение * конфигурацию запуска Контейнер создаётся на основе образа и запускается как отдельный процесс. --- # Как работают Docker Images Docker Images состоят из **слоёв (layers)**. Пример: ```text Base OS ↓ System packages ↓ Application dependencies ↓ Application code ``` Каждый слой кэшируется. Это позволяет Docker **ускорять сборку образов**. --- # Просмотр образов ## Показать список образов ```bash docker images ``` Пример вывода: ```text REPOSITORY TAG IMAGE ID SIZE nginx 1.25 a1b2c3d4e5 142MB mysql 8 f6g7h8i9j0 520MB node 18 k1l2m3n4o5 1.2GB ``` ### Что означает каждая колонка | Поле | Описание | | ---------- | ------------- | | REPOSITORY | имя образа | | TAG | версия образа | | IMAGE ID | уникальный ID | | SIZE | размер образа | --- # Загрузка образа из registry Docker может скачивать готовые образы из Docker Hub или другого registry. ```bash docker pull ``` Пример: ```bash docker pull nginx:1.25 ``` После этого образ появится в списке `docker images`. --- # Теги образов Docker использует **теги** для обозначения версии образа. Пример: ```text nginx:latest nginx:1.25 node:18 ``` ### Почему не стоит использовать `latest` Тег `latest` может измениться в любой момент. Лучше использовать фиксированную версию: ```text nginx:1.25 ``` Это делает окружение более предсказуемым. --- # Удаление Docker Images ## Удалить образ ```bash docker rmi ``` Пример: ```bash docker rmi nginx:1.25 ``` --- ## Удалить образ по ID ```bash docker rmi ``` Пример: ```bash docker rmi a1b2c3d4e5 ``` --- ## Удалить неиспользуемые образы ```bash docker image prune -f ``` Удаляются **dangling images** — образы, которые больше не используются. --- # Полная очистка старых образов Если на сервере накопилось много старых образов: ```bash docker system prune -a ``` Эта команда удалит: * остановленные контейнеры * неиспользуемые образы * сети * build cache > **Важно:** > Использовать эту команду нужно осторожно, особенно на production. --- # Сборка образа Образы можно создавать самостоятельно через `Dockerfile`. Пример сборки: ```bash docker build -t my_app . ``` Где: | Параметр | Значение | | -------- | ------------------ | | -t | тег образа | | my_app | имя образа | | . | текущая директория | --- # Проверка истории образа Можно посмотреть, из каких слоёв состоит образ: ```bash docker history ``` Пример: ```bash docker history nginx ``` Это помогает понять: * какие команды выполнялись при сборке * размер каждого слоя --- # Использование образа для запуска контейнера Контейнер можно запустить напрямую: ```bash docker run nginx ``` Но чаще используется Docker Compose. Пример: ```yaml services: nginx: image: nginx:1.25 ``` --- # Поиск образов Можно искать образы на Docker Hub: ```bash docker search nginx ``` Пример результата: ```text NAME DESCRIPTION nginx Official build of Nginx nginx-unit Nginx Unit runtime ``` Лучше использовать **официальные образы**. --- # Типичные проблемы с образами ## Слишком много образов на сервере Проверить: ```bash docker images ``` Удалить старые: ```bash docker image prune -f ``` --- ## Образ не обновляется Если используется: ```text nginx:latest ``` Docker может использовать старую версию. Решение: ```bash docker pull nginx ``` --- ## Слишком большой размер образа Некоторые образы могут занимать несколько гигабайт. Проверить: ```bash docker images ``` При необходимости удалить неиспользуемые. --- # Краткая памятка ```bash docker images # список образов docker pull # скачать образ docker search # поиск образа docker rmi # удалить образ docker image prune -f # удалить неиспользуемые образы docker build -t . # собрать образ docker history # история слоев образа ``` # Глава 4 — Безопасность # Docker — Безопасность и аудит Эта страница объясняет базовые практики безопасности при работе с Docker. Здесь разобраны команды для проверки уязвимостей образов, анализа конфигурации Docker Compose и рекомендации по безопасной эксплуатации контейнеров. Материал рассчитан на начинающих и помогает понять, **как обнаруживать потенциальные проблемы безопасности и минимизировать риски при работе с Docker-проектами**. --- # Почему безопасность Docker важна Контейнеры упрощают развертывание приложений, но сами по себе **не гарантируют безопасность**. Основные риски могут возникать из-за: * использования устаревших образов * уязвимостей в зависимостях * неправильных настроек сети * небезопасных прав доступа * запуска контейнеров с избыточными привилегиями Поэтому рекомендуется регулярно: * проверять образы на уязвимости * анализировать конфигурацию контейнеров * обновлять используемые образы * минимизировать доступ контейнеров к системе --- # Проверка образов на уязвимости Docker предоставляет инструменты для анализа безопасности образов. --- # Сканирование образа ```bash docker scan ``` Пример: ```bash docker scan nginx:latest ``` Команда анализирует образ и ищет известные уязвимости (CVE) в: * системных пакетах * библиотеках * зависимостях Пример результата: ``` ✗ High severity vulnerability found in openssl ✗ Medium severity vulnerability found in libssl ``` --- # Анализ образов через Docker Scout Docker Scout — более современный инструмент анализа образов. ```bash docker scout quickview ``` Пример: ```bash docker scout quickview node:18 ``` Инструмент покажет: * количество найденных уязвимостей * уровень риска * рекомендации по обновлению образа --- # Когда использовать сканирование Рекомендуется проверять образы: * перед использованием нового образа * перед деплоем на production * после обновления зависимостей --- # Проверка конфигурации Docker Compose Иногда проблемы безопасности возникают из-за неправильной конфигурации сервисов. --- # Просмотр сервисов проекта ```bash docker compose config --services ``` Команда выводит список сервисов, описанных в `docker-compose.yml`. Пример: ``` nginx php mysql redis ``` Это помогает убедиться, что Compose видит именно те сервисы, которые ожидаются. --- # Проверка volumes ```bash docker compose config --volumes ``` Команда показывает volumes, используемые проектом. Пример: ``` mysql_data redis_cache ``` ### Почему это важно Volumes могут содержать: * базы данных * пользовательские файлы * конфиденциальную информацию Важно понимать, где именно хранятся данные. --- # Проверка сетей проекта ```bash docker compose config --networks ``` Команда показывает сети, которые использует проект. Пример: ``` default internal_network ``` Это помогает проверить, какие сервисы могут взаимодействовать между собой. --- # Обновление Docker-образов Одной из главных причин уязвимостей является использование старых образов. Обновить образы можно так: ```bash docker compose pull ``` После загрузки новых образов нужно перезапустить сервисы: ```bash docker compose up -d ``` --- # Минимизация прав контейнеров По умолчанию контейнеры могут иметь довольно широкий доступ к системе. Рекомендуется: * запускать контейнеры от обычного пользователя * избегать режима `privileged` * ограничивать доступ к файловой системе Пример безопасной настройки в `docker-compose.yml`: ```yaml services: app: user: "1000:1000" ``` Это означает, что контейнер будет работать от обычного пользователя. --- # Ограничение ресурсов контейнеров Чтобы контейнер не мог использовать все ресурсы сервера, можно задать лимиты. Пример: ```yaml services: app: deploy: resources: limits: memory: 512M ``` Это защищает сервер от ситуаций, когда приложение начинает потреблять слишком много памяти. --- # Ограничение доступа к портам Не стоит открывать порты контейнеров без необходимости. Пример безопасной конфигурации: ```yaml ports: - "127.0.0.1:8080:80" ``` Это означает: * порт доступен только локально * извне сервера он не будет открыт --- # Использование .env файлов Часто конфиденциальные данные хранятся в `.env`. Пример: ``` DB_PASSWORD=secret_password API_KEY=xxxxxxxx ``` Важно: * не добавлять `.env` в публичные репозитории * использовать `.gitignore` --- # Проверка привилегированных контейнеров Контейнеры, запущенные в режиме `privileged`, имеют почти полный доступ к системе. Проверить можно так: ```bash docker inspect ``` В выводе нужно обратить внимание на поле: ``` Privileged: true ``` Если оно включено — контейнер имеет расширенные права. --- # Проверка запущенных контейнеров Полезно периодически проверять список контейнеров: ```bash docker ps ``` Это помогает обнаружить: * неизвестные контейнеры * забытые сервисы * тестовые окружения --- # Проверка используемых образов Можно посмотреть, какие образы используются: ```bash docker images ``` Пример вывода: ``` nginx latest mysql 8 redis 7 ``` Если используются очень старые версии — рекомендуется обновить их. --- # Типичные ошибки безопасности ## Использование latest в production Тег `latest` может неожиданно измениться. Лучше указывать конкретную версию: ```yaml nginx:1.25 ``` --- ## Открытые порты без необходимости Если порт не нужен извне — не стоит его публиковать. --- ## Запуск контейнера с root-доступом Лучше запускать контейнеры от обычного пользователя. --- ## Хранение секретов в репозитории Пароли и ключи лучше хранить: * в `.env` * в системных переменных --- # Типичный сценарий проверки безопасности ### 1 Проверить контейнеры ```bash docker ps ``` --- ### 2 Проверить образы ```bash docker images ``` --- ### 3 Проверить уязвимости ```bash docker scout quickview nginx ``` --- ### 4 Проверить конфигурацию compose ```bash docker compose config ``` --- ### 5 Обновить образы ```bash docker compose pull ``` --- # Краткая памятка ```bash docker scan # сканирование уязвимостей docker scout quickview # анализ безопасности образа docker compose config --services # список сервисов docker compose config --volumes # volumes проекта docker compose config --networks # сети проекта docker compose pull # обновить образы docker ps # список контейнеров docker images # список образов docker inspect # информация о контейнере ``` # Глава 5 — Решение проблем # Docker Troubleshooting — Решение типичных проблем Эта страница содержит инструкции по диагностике и устранению наиболее распространённых проблем при работе с Docker и Docker Compose. Здесь описаны типичные ситуации: контейнер не запускается, сервис падает после старта, приложение недоступно или контейнеры не видят друг друга. Материал ориентирован на начинающих и показывает **пошаговый подход к поиску и устранению проблем**. --- # Общий алгоритм диагностики Если сервис или контейнер работает неправильно, рекомендуется придерживаться следующего порядка проверки: 1. проверить статус контейнеров 2. проверить логи 3. проверить состояние сети 4. проверить использование ресурсов 5. проверить конфигурацию Docker Compose Этот подход помогает быстро определить источник проблемы. --- # Контейнер не запускается ## Проверить статус контейнеров ```bash id="trb9k3" docker compose ps ``` Пример вывода: ```id="z3fs3n" NAME STATUS project_php Exited (1) project_nginx Up ``` Если контейнер имеет статус: ```id="5z0c3a" Exited ``` это означает, что приложение внутри контейнера завершилось с ошибкой. --- ## Проверить логи контейнера ```bash id="yz2m6b" docker compose logs ``` Пример: ```bash id="3kt9q7" docker compose logs php ``` Часто в логах можно увидеть причину проблемы: * ошибка конфигурации * отсутствующий файл * ошибка подключения к базе данных * неправильные переменные окружения --- # Контейнер постоянно перезапускается Иногда контейнер запускается, но сразу падает и перезапускается. Проверить статус: ```bash id="9itp9r" docker ps ``` Пример: ```id="swdn6a" Restarting (1) 10 seconds ago ``` --- ## Посмотреть логи в реальном времени ```bash id="42s0pc" docker compose logs -f ``` Это позволит увидеть, на каком этапе происходит ошибка. --- # Порт уже используется Ошибка запуска контейнера может выглядеть так: ```id="j6vttc" Bind for 0.0.0.0:80 failed: port is already allocated ``` Это означает, что порт уже используется другим процессом. --- ## Проверить, кто использует порт ```bash id="p0h0p0" sudo lsof -i :80 ``` или ```bash id="n2ldib" netstat -tulpn | grep 80 ``` --- ## Возможные решения * остановить другой сервис * изменить порт в `docker-compose.yml` Пример изменения порта: ```yaml id="ozqg9u" ports: - "8080:80" ``` --- # Изменения в Dockerfile не применяются Docker активно использует кэш при сборке образов. Иногда это приводит к тому, что изменения не применяются. --- ## Пересобрать образ без кэша ```bash id="ib3bkh" docker compose build --no-cache ``` После этого нужно запустить контейнеры: ```bash id="y7vax4" docker compose up -d ``` --- # Контейнер не видит изменения файлов Если используется volume для подключения кода: ```yaml id="9tf49y" volumes: - ./app:/var/www/app ``` иногда изменения в коде могут не применяться. --- ## Проверить содержимое внутри контейнера ```bash id="j9y1ru" docker compose exec ls /var/www/app ``` --- ## Возможные причины * неправильный путь к папке * проблемы с правами доступа * файлы редактируются не в той директории --- # Контейнеры не видят друг друга Если сервисы не могут взаимодействовать: например: ```id="08s0nf" php -> mysql ``` --- ## Проверить сеть ```bash id="2rc7ds" docker network ls ``` --- ## Проверить подключенные контейнеры ```bash id="7q1mka" docker network inspect ``` --- ## Проверить соединение внутри контейнера ```bash id="w7oyv9" docker compose exec php ping mysql ``` Если соединение не работает — возможно сервис не запущен или контейнеры находятся в разных сетях. --- # Контейнер завис Иногда контейнер перестаёт реагировать на команды. Попробовать перезапустить: ```bash id="t0gns8" docker restart ``` Если это не помогает: ```bash id="5f7m39" docker kill ``` --- # Docker занимает слишком много места Со временем Docker может занимать большое количество дискового пространства. Проверить использование: ```bash id="mym4sl" docker system df ``` --- ## Очистить неиспользуемые ресурсы ```bash id="ntcd1k" docker system prune -f ``` --- ## Очистить volumes ```bash id="snxfg6" docker volume prune -f ``` > **Важно:** > Перед удалением volumes убедитесь, что они не содержат важных данных. --- # Контейнер не отвечает по HTTP Если сайт или API не открывается: --- ## Проверить контейнеры ```bash id="69a8vk" docker compose ps ``` --- ## Проверить проброс портов ```bash id="eq74mc" docker ps ``` Пример: ```id="m5r3tb" 0.0.0.0:8080->80/tcp ``` --- ## Проверить доступ внутри контейнера ```bash id="o6bfve" docker compose exec nginx curl localhost ``` Если внутри контейнера всё работает — проблема может быть в сетевых настройках. --- # Проверка конфигурации Docker Compose Перед запуском полезно проверить итоговую конфигурацию: ```bash id="5z2qkh" docker compose config ``` Команда показывает: * итоговый YAML * подставленные переменные окружения * конфигурацию сервисов Это помогает обнаружить: * ошибки YAML * пропущенные переменные * неправильные настройки сервисов --- # Быстрая диагностика (чеклист) Если сервис не работает: ### 1 Проверить контейнеры ```bash id="1eyx3o" docker compose ps ``` --- ### 2 Проверить логи ```bash id="b3z0yt" docker compose logs --tail=100 ``` --- ### 3 Проверить ресурсы ```bash id="ppqf0q" docker stats ``` --- ### 4 Проверить сеть ```bash id="e6d38k" docker network inspect ``` --- ### 5 Проверить конфигурацию ```bash id="u7y1fw" docker compose config ``` --- # Частые ошибки новичков ## Запуск Docker-команд не из директории проекта Если команда `docker compose` выполняется не там, где лежит `docker-compose.yml`, Docker не сможет найти конфигурацию. --- ## Неправильные имена сервисов В Docker Compose используется **имя сервиса**, а не имя контейнера. Пример правильного имени: ```id="2pydkr" mysql ``` --- ## Отсутствие `.env` файла Если в `docker-compose.yml` используются переменные окружения, но файл `.env` отсутствует, сервис может не запуститься. --- # Краткая памятка ```bash id="cc1zkp" docker compose ps # статус контейнеров docker compose logs # логи сервиса docker compose logs -f # логи в реальном времени docker restart # перезапуск контейнера docker kill # принудительная остановка docker network inspect # проверка сети docker stats # использование ресурсов docker system df # использование диска docker system prune -f # очистка Docker docker compose config # проверка конфигурации ``` --- # Итог Большинство проблем Docker можно диагностировать с помощью нескольких команд: * `docker compose ps` * `docker compose logs` * `docker stats` * `docker network inspect` * `docker compose config` Последовательное использование этих инструментов позволяет быстро определить источник проблемы и восстановить работу контейнеров. # Docker Debug Flow — Что делать, если контейнер не работает Эта страница описывает пошаговый алгоритм диагностики Docker-контейнеров. Она помогает быстро определить причину проблемы, если контейнер не запускается, сервис недоступен или приложение работает некорректно. Материал ориентирован на начинающих и представляет собой **универсальный чеклист диагностики Docker-проблем**. --- # Общий принцип диагностики Большинство проблем с Docker можно найти, последовательно проверив: 1. статус контейнеров 2. логи контейнеров 3. сетевые настройки 4. использование ресурсов 5. конфигурацию Docker Compose Чаще всего проблема обнаруживается уже на **втором шаге — в логах**. --- # Шаг 1 — Проверить контейнеры Сначала нужно убедиться, что контейнер действительно запущен. ```bash id="fdf0fa" docker compose ps ``` или ```bash id="q3wz9k" docker ps ``` Пример результата: ```text id="p3dr7m" NAME STATUS site_nginx Up site_php Exited (1) site_mysql Up ``` Если контейнер имеет статус: ```text id="g7y0ox" Exited ``` это означает, что приложение внутри контейнера завершилось с ошибкой. --- # Шаг 2 — Проверить логи Логи — главный источник информации о проблеме. ```bash id="n1oz5n" docker compose logs ``` Пример: ```bash id="gdr2k2" docker compose logs php ``` Если контейнер только что перезапустился, удобно смотреть логи в реальном времени: ```bash id="c04u70" docker compose logs -f php ``` --- # Шаг 3 — Проверить порты Если сервис работает, но недоступен извне, нужно проверить проброс портов. ```bash id="i5k7cl" docker ps ``` Пример: ```text id="6f4co1" 0.0.0.0:8080->80/tcp ``` Это означает: ```text id="d5oygs" сервер:8080 → контейнер:80 ``` Если порт не указан — он не открыт наружу. --- # Шаг 4 — Проверить сеть контейнеров Если сервисы не видят друг друга, нужно проверить Docker-сети. ```bash id="0hhm2f" docker network ls ``` Проверить контейнеры в сети: ```bash id="q49u9a" docker network inspect ``` --- # Шаг 5 — Проверить соединение внутри контейнера Иногда нужно зайти внутрь контейнера. ```bash id="0nhf52" docker compose exec sh ``` После этого можно проверить соединение. Пример проверки базы данных: ```bash id="hr9sl3" ping mysql ``` или ```bash id="h7l4do" nc -zv mysql 3306 ``` --- # Шаг 6 — Проверить ресурсы Если сервер перегружен, контейнеры могут работать нестабильно. Проверить использование ресурсов: ```bash id="r1jz3d" docker stats ``` Проверить использование диска: ```bash id="q7g34c" docker system df ``` --- # Шаг 7 — Проверить конфигурацию Compose Ошибки в `docker-compose.yml` могут привести к неправильному запуску контейнеров. Проверить конфигурацию: ```bash id="1svyzf" docker compose config ``` Эта команда покажет итоговую конфигурацию после обработки переменных. --- # Частые причины проблем ## Ошибка в конфигурации Неправильный YAML или пропущенная переменная. Решение: ```bash id="mj9eqk" docker compose config ``` --- ## Порт уже используется Ошибка: ```text id="7o1b5p" Bind for 0.0.0.0:80 failed ``` Проверить процесс: ```bash id="d1v6oy" sudo lsof -i :80 ``` --- ## Контейнер падает после запуска Проверить логи: ```bash id="6hbn7v" docker compose logs ``` --- ## Контейнеры не видят друг друга Проверить сеть: ```bash id="6tdvkt" docker network inspect ``` --- ## Закончился диск Проверить: ```bash id="s3eb2u" docker system df ``` Очистить Docker: ```bash id="9e0mxf" docker system prune -f ``` --- # Быстрый алгоритм диагностики ```text id="tnmxtg" 1 Проверить контейнеры docker compose ps 2 Проверить логи docker compose logs 3 Проверить порты docker ps 4 Проверить сеть docker network inspect 5 Проверить ресурсы docker stats 6 Проверить конфигурацию docker compose config ``` --- # Мини-чеклист диагностики Если сервис не работает: * контейнер запущен? * есть ли ошибки в логах? * открыт ли нужный порт? * контейнеры находятся в одной сети? * хватает ли ресурсов серверу? * правильная ли конфигурация Compose? # Глава 6 — Деплой и обновление проектов # Docker — Production Deployment Workflow Эта страница описывает рекомендуемый процесс обновления и развёртывания Docker-проектов на production-сервере. Здесь показан безопасный порядок действий при обновлении кода, образов и контейнеров, а также базовые проверки после деплоя. Материал ориентирован на начинающих и помогает выполнять обновления **предсказуемо и без случайных простоев сервисов**. --- # Что такое Deployment Workflow Deployment Workflow — это **последовательность действий**, которую нужно выполнять при обновлении проекта. Без чёткой процедуры часто возникают проблемы: * контейнеры запускаются со старыми образами * сервисы падают после обновления * изменения не применяются * ломается база данных * проект уходит в простой Поэтому важно использовать **одинаковый и проверенный порядок действий**. --- # Типичная структура проекта Пример директории проекта: ```text /opt/flamy_projects/site1 docker-compose.yml .env Dockerfile src/ ``` Где: | Файл | Назначение | | ------------------ | ------------------------ | | docker-compose.yml | конфигурация сервисов | | Dockerfile | инструкция сборки образа | | .env | переменные окружения | | src | исходный код приложения | --- # Стандартная процедура обновления проекта ## Шаг 1 — перейти в директорию проекта ```bash cd /opt/flamy_projects/site1 ``` Проверить файлы: ```bash ls -la ``` Важно убедиться, что вы находитесь **в правильной директории проекта**. --- # Шаг 2 — обновить код проекта Если используется Git: ```bash git pull ``` Команда скачивает последние изменения из репозитория. ### Когда это нужно * обновление приложения * исправления ошибок * новые функции --- # Шаг 3 — обновить Docker-образы Если проект использует готовые образы из registry, нужно загрузить новые версии. ```bash docker compose pull ``` Команда скачает новые версии образов, указанных в `docker-compose.yml`. --- # Шаг 4 — пересобрать контейнеры (если требуется) Если изменились: * Dockerfile * зависимости * системные пакеты нужно пересобрать образ. ```bash docker compose up -d --build ``` Эта команда: 1. пересоберёт образы 2. обновит контейнеры 3. запустит сервисы --- # Шаг 5 — проверить состояние контейнеров ```bash docker compose ps ``` Пример результата: ```text NAME STATUS site1_nginx Up site1_php Up site1_mysql Up ``` Все сервисы должны иметь статус **Up**. --- # Шаг 6 — проверить логи После обновления важно убедиться, что сервисы работают корректно. ```bash docker compose logs --tail=50 ``` В логах не должно быть: * ошибок запуска * ошибок подключения к базе * критических ошибок приложения --- # Шаг 7 — проверить работу приложения После деплоя рекомендуется проверить: * доступность сайта * работу API * соединение с базой данных * фоновые задачи (workers, cron) --- # Быстрое обновление проекта На практике часто используется короткая команда: ```bash docker compose pull && docker compose up -d ``` Она: 1. скачивает новые образы 2. обновляет контейнеры Это самый быстрый способ обновить сервис. --- # Полное обновление проекта Если нужно полностью пересобрать контейнеры: ```bash docker compose build --no-cache docker compose up -d ``` Это полезно, если: * изменения не применяются * образ собран неправильно * нужно выполнить чистую сборку --- # Полный перезапуск проекта Иногда требуется полностью остановить и заново запустить сервисы. ```bash docker compose down docker compose up -d ``` Это может помочь при: * сетевых проблемах * зависших контейнерах * некорректном состоянии сервисов --- # Перезапуск одного сервиса Если проблема только в одном сервисе: ```bash docker compose restart nginx ``` Это быстрее и безопаснее, чем перезапуск всего проекта. --- # Откат версии (Rollback) Если после обновления возникли проблемы, можно откатиться к предыдущей версии. Пример: ```bash git checkout docker compose up -d --build ``` Это восстановит предыдущую рабочую версию приложения. --- # Проверка после деплоя После обновления рекомендуется выполнить несколько проверок. --- ## Проверить контейнеры ```bash docker ps ``` Это покажет все работающие контейнеры. --- ## Проверить ресурсы ```bash docker stats ``` Позволяет убедиться, что сервисы не перегружают сервер. --- ## Проверить сети ```bash docker network ls ``` Если сервисы не взаимодействуют — возможно проблема в сети. --- # Типичный production workflow Чаще всего используется следующий порядок действий: ```bash cd /opt/flamy_projects/site1 git pull docker compose pull docker compose up -d --build docker compose ps docker compose logs --tail=50 ``` Этот процесс: 1. обновляет код 2. обновляет образы 3. пересобирает контейнеры 4. проверяет состояние сервисов --- # Частые ошибки при деплое ## Пропуск шага pull Если не выполнить `docker compose pull`, контейнеры могут запускаться со старыми образами. --- ## Запуск команд не из директории проекта Docker Compose работает с файлом `docker-compose.yml`, поэтому важно находиться в нужной папке. --- ## Игнорирование логов После деплоя всегда нужно проверять логи. --- ## Использование latest в production Лучше указывать фиксированные версии образов: ```yaml nginx:1.25 ``` Это делает деплой более предсказуемым. --- # Краткая памятка ```bash cd /opt/flamy_projects/project_name git pull docker compose pull docker compose up -d --build docker compose ps docker compose logs --tail=50 docker compose restart docker compose down && docker compose up -d ``` --- # Итог Правильный workflow обновления Docker-проектов позволяет: * безопасно обновлять сервисы * быстро диагностировать проблемы * минимизировать время простоя Использование чёткой процедуры деплоя помогает поддерживать стабильную работу production-систем и упрощает администрирование Docker-инфраструктуры. # Docker — Backup (Резервное копирование данных) Эта страница описывает способы резервного копирования данных Docker-проектов. Здесь разобраны методы backup контейнерных данных, volumes и баз данных, а также способы восстановления данных. Материал рассчитан на начинающих и помогает понять, **как защитить данные Docker-приложений от потери при сбоях, обновлениях или ошибках администрирования**. --- # Почему резервное копирование важно Docker-контейнеры можно легко пересоздать, но **данные приложения могут быть потеряны**, если они не вынесены в volumes или не сохраняются отдельно. Резервное копирование особенно важно для: * баз данных * пользовательских файлов * загрузок * конфигураций приложения * логов Даже небольшая ошибка (например, удаление volume) может привести к потере данных. --- # Что нужно резервировать В Docker-проектах обычно нужно делать backup: | Тип данных | Пример | | ---------------- | ------------------ | | Базы данных | MySQL, PostgreSQL | | Docker volumes | данные контейнеров | | Файлы приложения | uploads, storage | | Конфигурации | .env, config | --- # Backup базы данных из контейнера Самый распространённый способ — использовать встроенные утилиты базы данных. --- ## Backup MySQL ```bash id="kvx7ep" docker compose exec mysql mysqldump -u root -p database_name > backup.sql ``` Эта команда: 1. подключается к контейнеру MySQL 2. делает дамп базы 3. сохраняет файл `backup.sql` --- ## Backup PostgreSQL ```bash id="ecv8u4" docker compose exec postgres pg_dump -U postgres database_name > backup.sql ``` --- # Backup Docker Volume Если данные хранятся в volume, можно сделать архив. --- ## Создание backup volume ```bash id="fd9n6h" docker run --rm \ -v volume_name:/data \ -v $(pwd):/backup \ alpine tar czf /backup/volume_backup.tar.gz /data ``` ### Что делает команда | Параметр | Назначение | | -------------------- | -------------------- | | -v volume_name:/data | подключает volume | | -v $(pwd):/backup | папка для сохранения | | tar czf | создаёт архив | В результате появится файл: ```text id="f6a6fy" volume_backup.tar.gz ``` --- # Восстановление volume Чтобы восстановить данные из backup: ```bash id="op9dpp" docker run --rm \ -v volume_name:/data \ -v $(pwd):/backup \ alpine tar xzf /backup/volume_backup.tar.gz -C / ``` Данные будут восстановлены в volume. --- # Backup директории проекта Иногда нужно сохранить весь Docker-проект. --- ## Архив проекта ```bash id="zuybb6" tar -czf project_backup_$(date +%Y%m%d).tar.gz /opt/flamy_projects/site1 ``` Архив будет содержать: * docker-compose.yml * Dockerfile * исходный код * конфигурации --- # Backup пользовательских файлов Если приложение хранит файлы в директории: ```text id="0nh8k0" /var/www/storage ``` Можно сделать backup так: ```bash id="reye7v" tar -czf storage_backup.tar.gz storage/ ``` --- # Backup через rsync `rsync` часто используется для копирования backup на другой сервер. ```bash id="tbj02p" rsync -avz /opt/flamy_projects user@backup-server:/backup/docker_projects ``` Это позволяет хранить резервные копии **на отдельном сервере**. --- # Автоматизация backup (cron) Backup можно запускать автоматически. Пример cron-задачи: ```bash id="t8gmyc" crontab -e ``` Добавить строку: ```text id="zslg7o" 0 3 * * * /usr/local/bin/docker_backup.sh ``` Это будет запускать backup каждый день в 03:00. --- # Пример простого backup-скрипта ```bash id="f3khr0" #!/bin/bash DATE=$(date +%Y%m%d) docker compose exec mysql mysqldump -u root -psecret db > backup_$DATE.sql tar -czf docker_backup_$DATE.tar.gz /opt/flamy_projects/site1 ``` Скрипт делает: * дамп базы * архив проекта --- # Проверка backup Очень важно проверять резервные копии. Проверить архив: ```bash id="tk4s3d" tar -tzf backup.tar.gz ``` Проверить SQL-дамп: ```bash id="kchp9s" head backup.sql ``` --- # Типичные ошибки при backup ## Backup только контейнеров Контейнеры легко пересоздаются, поэтому важно сохранять **данные**, а не контейнеры. --- ## Отсутствие автоматического backup Ручной backup часто забывают делать. Лучше использовать cron. --- ## Хранение backup на том же сервере Если сервер выйдет из строя, backup тоже может быть потерян. Лучше хранить копии: * на другом сервере * в облаке * в S3-хранилище --- # Рекомендуемая стратегия backup Минимальная стратегия: * ежедневный backup базы данных * ежедневный backup volumes * хранение копий минимум 7 дней --- # Краткая памятка ```bash id="22r5v7" docker compose exec mysql mysqldump > backup.sql # backup MySQL docker compose exec postgres pg_dump > backup.sql # backup PostgreSQL docker run -v volume:/data alpine tar czf backup.tar.gz /data # backup volume tar -czf project_backup.tar.gz project/ # архив проекта rsync -avz project backup-server:/backup # копирование backup ``` # Docker Cheat Sheet — Часто используемые команды Краткий справочник наиболее часто используемых команд Docker и Docker Compose. Эта страница предназначена для быстрого поиска нужной команды при повседневной работе с контейнерами, образами и Docker-проектами. --- # Docker Compose — Управление сервисами Запуск всех сервисов: ```bash id="v0n4fy" docker compose up -d ``` Остановка проекта: ```bash id="2q0qju" docker compose down ``` Пересборка контейнеров: ```bash id="r4j8s6" docker compose up -d --build ``` Пересоздание контейнеров: ```bash id="o7d21s" docker compose up -d --force-recreate ``` Скачать новые образы: ```bash id="2kn6yu" docker compose pull ``` Перезапуск сервиса: ```bash id="94xjyd" docker compose restart ``` Запуск одного сервиса: ```bash id="c3ipd8" docker compose up -d ``` --- # Контейнеры Список запущенных контейнеров: ```bash id="u2y13x" docker ps ``` Все контейнеры (включая остановленные): ```bash id="1ntmim" docker ps -a ``` Остановить контейнер: ```bash id="n3s0hg" docker stop ``` Запустить контейнер: ```bash id="z0j3li" docker start ``` Перезапустить контейнер: ```bash id="0k2q2v" docker restart ``` Удалить контейнер: ```bash id="qjbd7s" docker rm ``` Удалить все остановленные контейнеры: ```bash id="0zslfx" docker container prune ``` --- # Логи Показать логи контейнера: ```bash id="bdl4y1" docker logs ``` Логи в реальном времени: ```bash id="twq0ib" docker logs -f ``` Последние строки логов: ```bash id="ehl1p5" docker logs --tail=100 ``` Логи сервиса Compose: ```bash id="dsb9n7" docker compose logs ``` --- # Подключение к контейнеру Подключиться к shell: ```bash id="p0biv9" docker exec -it sh ``` Использовать bash: ```bash id="f4n6xq" docker exec -it bash ``` Выполнить команду: ```bash id="h4c6z6" docker exec ``` --- # Образы (Images) Список образов: ```bash id="9g0uht" docker images ``` Скачать образ: ```bash id="c2on0y" docker pull ``` Удалить образ: ```bash id="ap0osd" docker rmi ``` Удалить неиспользуемые образы: ```bash id="1nq1sb" docker image prune ``` Собрать образ: ```bash id="4p4h1n" docker build -t . ``` --- # Volumes Список volumes: ```bash id="9eopq9" docker volume ls ``` Информация о volume: ```bash id="5hs4pn" docker volume inspect ``` Создать volume: ```bash id="y6pyw8" docker volume create ``` Удалить volume: ```bash id="5ph7w9" docker volume rm ``` Удалить неиспользуемые volumes: ```bash id="j8o1q6" docker volume prune ``` --- # Сети Список сетей: ```bash id="t8t3x1" docker network ls ``` Информация о сети: ```bash id="91u7q9" docker network inspect ``` Удалить неиспользуемые сети: ```bash id="o5n0ve" docker network prune ``` --- # Мониторинг и ресурсы Использование ресурсов контейнеров: ```bash id="8f6oel" docker stats ``` Использование диска Docker: ```bash id="q2w0bz" docker system df ``` Информация о Docker: ```bash id="tywh7p" docker info ``` --- # Очистка Docker Удалить остановленные контейнеры: ```bash id="8qysq3" docker container prune ``` Удалить неиспользуемые образы: ```bash id="8kn8b7" docker image prune ``` Удалить volumes: ```bash id="93soho" docker volume prune ``` Удалить сети: ```bash id="9m2gnv" docker network prune ``` Полная очистка системы: ```bash id="3dtdke" docker system prune ``` --- # Полезные команды Копирование файла из контейнера: ```bash id="y1fxa3" docker cp :/path/file . ``` Копирование файла в контейнер: ```bash id="e4y0k0" docker cp file :/path/ ``` Просмотр процессов контейнера: ```bash id="jehplh" docker top ``` История образа: ```bash id="ephv1i" docker history ``` --- # Быстрые сценарии Перезапустить проект: ```bash id="rj0n6r" docker compose down docker compose up -d ``` Обновить образы и контейнеры: ```bash id="nt5ihr" docker compose pull docker compose up -d ``` Пересобрать контейнеры: ```bash id="gs9ry2" docker compose build --no-cache docker compose up -d ``` --- # Итог Этот cheat sheet содержит основные команды Docker, которые чаще всего используются при: * запуске проектов * отладке контейнеров * управлении образами * работе с volumes и сетями * очистке системы Он предназначен для **быстрого поиска команд** без необходимости просматривать всю документацию.