Docker Operations

Краткое оглавление книги по Docker. Используется для быстрой навигации по разделам документации.

Содержание

1. Основы Docker

2. Диагностика и обслуживание

3. Управление проектами

4. Безопасность

5. Решение проблем

6. Deployment

Docker Operations — Как читать эту книгу

Эта карта показывает рекомендуемый порядок изучения разделов книги. Новым разработчикам рекомендуется читать страницы последовательно, чтобы понять основы Docker, а затем перейти к диагностике, обслуживанию и деплою проектов.

Шаг 1 — Базовые команды Docker

Начните с основных команд управления контейнерами.

После этого вы сможете:

Шаг 2 — Работа с контейнерами

Следующий шаг — научиться диагностировать контейнеры.

После этого вы сможете:

Шаг 3 — Понимание инфраструктуры Docker

Теперь важно понять основные компоненты Docker.

После этого станет понятно:

Шаг 4 — Мониторинг и обслуживание

Следующий уровень — поддержка серверов с Docker.

После этого вы сможете:

Шаг 5 — Работа с проектами

Теперь можно перейти к управлению реальными проектами.

После этого вы сможете:

Шаг 6 — Production и безопасность

Финальный этап — работа с production-системами.

После этого вы сможете:

Шаг 7 — Решение проблем

Эти страницы используются как справочник при проблемах.

Они помогают быстро понять:

Быстрая навигация

Если вы уже знакомы с Docker:

Задача Раздел
Запуск проекта Docker Compose — Управление сервисами
Ошибка контейнера Docker — Отладка контейнеров
Проверка логов Docker — Logs
Контейнеры не видят друг друга Docker — Работа с сетями
Docker занял весь диск Docker — Cleanup
Резервное копирование Docker — Backup
Обновление проекта Docker — Production Deployment Workflow

Итог

Эта книга покрывает весь жизненный цикл Docker-проектов:

Запуск → Диагностика → Инфраструктура → Обслуживание → Управление проектами → Deployment → Troubleshooting

Глава 1 — Основы работы с Docker


Глава 1 — Основы работы с Docker

Compose — Управление сервисами

Эта страница объясняет базовые команды docker compose, которые используются для запуска, остановки, пересборки и перезапуска сервисов в проекте. Материал рассчитан на начинающих: здесь разобрано, что делает каждая команда, в каких случаях её использовать и на что обратить внимание, чтобы случайно не сломать рабочее окружение.

Что такое Docker Compose

Docker Compose — это инструмент для управления несколькими контейнерами как единым приложением. Обычно в проекте есть файл docker-compose.yml, где описано:

Например, один проект может состоять из:

Вместо того чтобы запускать каждый контейнер отдельно длинными командами docker run, Compose позволяет поднять всё одной командой.

Перед началом работы

Обычно работа с Compose ведётся из директории проекта, где лежит docker-compose.yml.

Пример:

cd /opt/flamy_projects/project_name

Проверить, что файл действительно есть в текущей папке:

ls -la

Если нужно найти compose-файлы во всей папке проектов:

find /opt/flamy_projects -type f -name "docker-compose*.yml"

Примечание: Большинство команд docker compose нужно выполнять именно в той директории, где находится docker-compose.yml. Иначе Docker не поймёт, с каким проектом работать.

Базовый принцип работы

Чаще всего цикл работы выглядит так:

  1. перейти в папку проекта
  2. запустить сервисы
  3. проверить, что контейнеры работают
  4. посмотреть логи при ошибках
  5. при необходимости пересобрать или перезапустить сервисы

Запуск сервисов

Запуск всех сервисов в фоне

docker compose up -d

Эта команда:

Флаг -d означает detached mode, то есть запуск в фоне.

Когда использовать

Подходит почти для любого обычного старта проекта:

Пример

cd /opt/flamy_projects/site1
docker compose up -d

Что важно помнить

Если образа ещё нет локально, Docker попытается:

Для новичков: up не всегда означает просто «включить». Эта команда может не только запускать, но и создавать контейнеры заново, если это требуется по конфигурации.

Остановка и удаление контейнеров проекта

Остановка проекта

docker compose down

Команда останавливает и удаляет:

Когда использовать

Подходит, если нужно:

Что команда не удаляет

По умолчанию docker compose down не удаляет volumes. Это важно, потому что именно в volumes часто лежат данные:

Важно: Для новичков это одна из самых полезных вещей: обычный down не стирает данные сам по себе. Но всё равно всегда нужно понимать, где именно проект хранит данные — в volumes, bind mounts или внутри контейнера.

Пример

docker compose down

После этого проект можно снова поднять:

docker compose up -d

Принудительное пересоздание контейнеров

Пересоздать контейнеры даже без изменений

docker compose up -d --force-recreate

Эта команда заставляет Docker пересоздать контейнеры, даже если он считает, что ничего не поменялось.

Когда использовать

Полезно, если:

Что важно помнить

Пояснение: Контейнер и volume — это не одно и то же. Контейнер — это «запущенная оболочка приложения». Volume — это место, где могут лежать постоянные данные. Поэтому пересоздание контейнера не обязательно означает потерю данных.

Пересборка образов

Пересборка нужна тогда, когда меняется не только запуск контейнера, а именно его образ. Обычно это происходит, если вы изменили:

Пересборка без использования кэша

docker compose build --no-cache

Docker при сборке старается использовать кэш, чтобы не выполнять одинаковые шаги повторно. Это ускоряет работу, но иногда мешает, если нужен действительно «чистый» rebuild.

Флаг --no-cache говорит: не использовать ранее сохранённые слои, а собрать всё заново.

Когда использовать

Подходит, если:

Пример

docker compose build --no-cache
docker compose up -d

Примечание: Эта операция может занять заметно больше времени, чем обычная сборка.

Пересобрать и сразу запустить

docker compose up -d --build

Команда делает два действия сразу:

  1. при необходимости пересобирает образ
  2. запускает контейнеры

Когда использовать

Это один из самых частых сценариев после изменения:

Пример

docker compose up -d --build

Чем отличается от build --no-cache

Если нужно просто обновить контейнер после обычных изменений — чаще хватает:

docker compose up -d --build

Если есть сомнения в корректности кэша — используйте:

docker compose build --no-cache
docker compose up -d

Обновление образов из реестра

Скачать свежие версии образов

docker compose pull

Команда скачивает новые версии образов, которые указаны в docker-compose.yml.

Когда использовать

Подходит, если проект использует готовые образы из registry, например:

Важный момент

docker compose pull только скачивает образы, но не перезапускает контейнеры автоматически.

Чтобы применить обновление, обычно выполняют:

docker compose pull && docker compose up -d

Пример

cd /opt/flamy_projects/site1
docker compose pull
docker compose up -d

Важно: На production-серверах обновление образов нужно делать осторожно. Новая версия образа может изменить поведение приложения или сломать совместимость.

Перезапуск сервисов

Иногда контейнер не нужно пересобирать или пересоздавать — достаточно просто перезапустить процесс.

Перезапуск одного сервиса

docker compose restart <service>

Пример:

docker compose restart nginx

Когда использовать

Подходит, если:

Перезапуск всех сервисов

docker compose restart

Перезапускает все сервисы, описанные в compose-файле.

Когда использовать

Подходит, если:

Остановка и запуск отдельного сервиса вручную

docker compose stop <service> && docker compose start <service>

Пример:

docker compose stop php && docker compose start php

Зачем это нужно, если есть restart

Иногда удобнее разделить действия на две части:

Это бывает полезно при диагностике или когда нужно убедиться, что сервис полностью остановился.

Запуск только одного сервиса

docker compose up -d <service>

Пример:

docker compose up -d nginx

Когда использовать

Полезно, если:

Примечание: Если сервис зависит от других, Compose может поднять и их тоже.

Проверка итоговой конфигурации

Посмотреть итоговый compose-конфиг

docker compose config

Эта команда показывает итоговую конфигурацию после обработки:

Когда использовать

Очень полезно перед запуском, если:

Почему это важно для новичков

Иногда в YAML всё выглядит правильно, но итоговая конфигурация получается другой. docker compose config помогает увидеть конечный результат до запуска.

Наиболее частые сценарии в работе

Обычный запуск проекта

docker compose up -d

Обновить образы и применить изменения

docker compose pull && docker compose up -d

После изменения Dockerfile или зависимостей

docker compose up -d --build

Полная пересборка без кэша

docker compose build --no-cache
docker compose up -d

Быстро перезапустить один сервис

docker compose restart nginx

Полностью выключить проект

docker compose down

Что выбрать в типовых ситуациях

Ситуация: нужно просто запустить проект

Используйте:

docker compose up -d

Ситуация: поменялся Dockerfile

Используйте:

docker compose up -d --build

Ситуация: образ ведёт себя странно, нужен чистый rebuild

Используйте:

docker compose build --no-cache
docker compose up -d

Ситуация: нужно скачать свежие образы из registry

Используйте:

docker compose pull && docker compose up -d

Ситуация: сервис просто нужно перезапустить

Используйте:

docker compose restart <service>

Частые ошибки новичков

Запуск команды не из той директории

Если выполнить docker compose up -d не там, где лежит docker-compose.yml, можно получить ошибку о том, что конфигурационный файл не найден.

Путаница между restart, up, build и down

Кратко:

Ожидание, что pull сам обновит работающие контейнеры

docker compose pull только скачивает новый образ. Чтобы контейнеры начали работать на новой версии, нужен ещё запуск:

docker compose up -d

Краткая памятка

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 <service>         # Перезапуск одного сервиса
docker compose restart                   # Перезапуск всех сервисов
docker compose stop <service> && docker compose start <service>  # Остановить и запустить сервис отдельно
docker compose up -d <service>           # Запуск одного сервиса
docker compose config                    # Проверка итоговой конфигурации
Глава 1 — Основы работы с Docker

Docker — Отладка контейнеров

Эта страница объясняет основные команды Docker, которые используются для диагностики и отладки контейнеров. Здесь разобраны способы посмотреть запущенные контейнеры, проверить их состояние, изучить логи, подключиться внутрь контейнера и выполнить команды для анализа проблемы. Материал рассчитан на начинающих и помогает быстро понять, что происходит внутри контейнера, если приложение работает некорректно.

Когда используется отладка контейнеров

На практике команды из этой страницы используются в следующих ситуациях:

Типичный порядок диагностики:

  1. проверить список контейнеров
  2. проверить статус контейнера
  3. посмотреть логи
  4. зайти внутрь контейнера
  5. проверить процессы или выполнить команды

Просмотр контейнеров

Показать контейнеры текущего проекта

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

Что здесь можно увидеть

Когда использовать

Это первая команда, которую стоит выполнить, если нужно проверить:

Показать все запущенные контейнеры

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 все контейнеры на сервере

Показать все контейнеры (включая остановленные)

docker ps -a

Показывает:

Пример статуса:

Exited (1) 5 minutes ago

Что это означает

Контейнер запустился, но приложение внутри завершилось с ошибкой.

В таком случае следующим шагом нужно посмотреть логи.

Табличный формат вывода

docker ps -a --format "table {{.ID}}\t{{.Names}}\t{{.Status}}\t{{.Ports}}"

Этот формат удобен, если нужно быстро увидеть:

Пример вывода:

CONTAINER ID   NAMES         STATUS          PORTS
3acb1234       project_php   Up 10 minutes
7d8e5678       project_nginx Up 10 minutes   80/tcp

Просмотр логов контейнеров

Логи — это основной источник информации при отладке.

Именно здесь можно увидеть:

Просмотр логов сервиса

docker compose logs <service>

Пример:

docker compose logs nginx

Вывод покажет весь лог контейнера.

Просмотр логов в реальном времени

docker compose logs -f <service>

Флаг -f означает follow — следить за логом в реальном времени.

Пример:

docker compose logs -f php

Это удобно, если:

Выход из режима просмотра:

CTRL + C

Показать последние строки логов

docker compose logs --tail=100 <service>

Показывает только последние 100 строк.

Пример:

docker compose logs --tail=100 nginx

Когда использовать

Если контейнер работает давно и лог очень большой.

Логи с временными метками

docker compose logs --timestamps <service>

Пример:

docker compose logs --timestamps php

Вывод будет выглядеть примерно так:

2026-03-11T12:32:10 app started
2026-03-11T12:32:11 connected to database

Это удобно для анализа событий во времени.

Подключение внутрь контейнера

Иногда для диагностики нужно зайти внутрь контейнера, чтобы:

Подключиться через shell

docker compose exec <service> sh

Пример:

docker compose exec php sh

После выполнения команды вы окажетесь внутри контейнера.

Использование bash

Если в контейнере установлен bash, можно использовать:

docker compose exec <service> bash

Пример:

docker compose exec php bash

Важно: Не во всех контейнерах есть bash. Многие минимальные образы используют только sh.

Проверить файлы внутри контейнера

После входа можно выполнять обычные команды Linux:

ls
cd
cat
ps
top

Например:

ls /var/www/html

Просмотр процессов внутри контейнера

docker compose top <service>

Пример:

docker compose top php

Команда показывает список процессов внутри контейнера.

Пример вывода:

UID     PID     CMD
root    123     php-fpm

Когда использовать

Полезно, если:

Выполнение команды внутри контейнера

Можно выполнить команду без входа в shell.

Формат:

docker compose exec <service> <command>

Пример:

docker compose exec php php -v

Вывод:

PHP 8.2.4 (cli)

Ещё примеры

Проверить установленные пакеты:

docker compose exec php composer --version

Проверить Node.js:

docker compose exec node node -v

Копирование файлов из контейнера

Иногда нужно забрать файл из контейнера.

Копирование файла из контейнера

docker cp container:/path/file .

Пример:

docker cp project_php:/var/log/php.log .

Файл будет скопирован в текущую папку.

Копирование файла в контейнер

docker cp file container:/path/

Пример:

docker cp config.php project_php:/var/www/config.php

Типичный сценарий диагностики

Если сервис не работает, обычно делают следующее:

1 Проверить контейнеры

docker compose ps

2 Проверить логи

docker compose logs --tail=100

3 Если ошибка не очевидна — подключиться внутрь

docker compose exec php sh

4 Проверить процессы

docker compose top php

5 Проверить приложение вручную

Например:

curl localhost

Полезные советы для новичков

Всегда начинайте диагностику с логов

В большинстве случаев ошибка уже записана в лог.

Не путайте контейнер и сервис

В Compose:

Проверяйте статус контейнера

Если статус:

Exited

контейнер уже остановился, и нужно смотреть логи.

Краткая памятка

docker compose ps                          # контейнеры текущего проекта
docker ps                                  # все запущенные контейнеры
docker ps -a                               # все контейнеры включая остановленные

docker compose logs <service>              # логи сервиса
docker compose logs -f <service>           # логи в реальном времени
docker compose logs --tail=100 <service>   # последние строки логов
docker compose logs --timestamps <service> # логи с временными метками

docker compose exec <service> sh           # войти в контейнер
docker compose exec <service> bash         # войти через bash
docker compose exec <service> <command>    # выполнить команду

docker compose top <service>               # процессы контейнера

docker cp container:/path/file .           # копировать из контейнера
docker cp file container:/path/            # копировать в контейнер
Глава 1 — Основы работы с Docker

Docker Compose — Структура docker-compose.yml

Эта страница объясняет структуру файла docker-compose.yml и основные параметры, используемые при описании сервисов Docker. Здесь разобраны ключевые разделы конфигурации, такие как services, volumes, networks, environment, ports и другие. Материал рассчитан на начинающих и помогает понять, как правильно описывать инфраструктуру приложения в Docker Compose.

Что такое docker-compose.yml

docker-compose.yml — это файл конфигурации, который описывает:

Compose позволяет запускать всё приложение одной командой:

docker compose up -d

Базовая структура docker-compose.yml

Пример минимального файла:

version: "3.9"

services:
  nginx:
    image: nginx:1.25
    ports:
      - "8080:80"

Этот файл создаёт контейнер nginx и открывает порт 8080.

Основные разделы docker-compose.yml

Типичная структура файла выглядит так:

services:
volumes:
networks:

Раздел services

Раздел services описывает контейнеры проекта.

Пример:

services:
  nginx:
    image: nginx:1.25

  php:
    image: php:8.2-fpm

В этом примере создаются два сервиса:

Каждый сервис становится отдельным контейнером.

Параметр image

Определяет Docker-образ, который будет использоваться.

Пример:

services:
  nginx:
    image: nginx:1.25

Docker скачает образ nginx:1.25, если он отсутствует.

Параметр build

Используется, если образ нужно собрать локально из Dockerfile.

Пример:

services:
  app:
    build: .

Это означает:

собрать образ из Dockerfile текущей директории

Можно указать путь:

services:
  app:
    build: ./app

Параметр ports

Используется для проброса портов.

Пример:

ports:
  - "8080:80"

Это означает:

сервер:8080 → контейнер:80

После запуска приложение будет доступно:

http://server:8080

Параметр volumes

Подключает volumes или папки сервера.

Пример:

volumes:
  - ./src:/var/www/html

Это означает:

сервер ./src → контейнер /var/www/html

Использование Docker Volumes

Пример с volume:

services:
  mysql:
    image: mysql:8
    volumes:
      - mysql_data:/var/lib/mysql

volumes:
  mysql_data:

Volume будет хранить данные базы.

Параметр environment

Передаёт переменные окружения контейнеру.

Пример:

environment:
  MYSQL_ROOT_PASSWORD: secret
  MYSQL_DATABASE: app_db

Контейнер получит переменные:

MYSQL_ROOT_PASSWORD
MYSQL_DATABASE

Использование .env файла

Переменные можно хранить в .env.

Пример:

DB_PASSWORD=secret
APP_ENV=production

И использовать в Compose:

environment:
  DB_PASSWORD: ${DB_PASSWORD}

Параметр depends_on

Определяет зависимости между сервисами.

Пример:

services:
  php:
    depends_on:
      - mysql

Это означает:

сначала запускается mysql
затем php

Важно: depends_on не гарантирует, что сервис полностью готов к работе.

Параметр restart

Определяет политику перезапуска контейнера.

Пример:

restart: always

Возможные значения:

Значение Поведение
no не перезапускать
always всегда перезапускать
on-failure только при ошибке
unless-stopped перезапускать, пока не остановлен вручную

Параметр networks

Определяет сети Docker.

Пример:

services:
  app:
    networks:
      - backend

networks:
  backend:

Контейнер будет подключён к сети backend.

Пример полного docker-compose.yml

Пример простого веб-приложения:

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:

Этот файл запускает:

Проверка docker-compose.yml

Перед запуском полезно проверить конфигурацию:

docker compose config

Команда покажет итоговую конфигурацию после обработки переменных.

Запуск проекта

Запуск всех сервисов:

docker compose up -d

Остановка проекта

docker compose down

Типичные ошибки в docker-compose.yml

Ошибка YAML

Файл YAML чувствителен к отступам.

Неправильно:

services:
nginx:
image: nginx

Правильно:

services:
  nginx:
    image: nginx

Неверные порты

Если порт уже используется:

Bind for 0.0.0.0:80 failed

Нужно изменить порт.

Отсутствие volumes

Если данные не вынесены в volumes, они могут потеряться при пересоздании контейнера.

Краткая памятка

services     → контейнеры проекта
image        → используемый образ
build        → сборка образа
ports        → проброс портов
volumes      → подключение хранилища
environment  → переменные окружения
depends_on   → зависимости сервисов
restart      → политика перезапуска
networks     → сети контейнеров

Глава 2 — Диагностика и обслуживание

Глава 2 — Диагностика и обслуживание

Docker — Мониторинг и использование ресурсов

Эта страница объясняет, как отслеживать использование ресурсов Docker и как управлять дисковым пространством, занятым контейнерами, образами и volumes. Здесь разобраны команды для просмотра нагрузки на CPU и память, анализа использования диска, а также безопасной очистки неиспользуемых ресурсов. Материал ориентирован на начинающих и помогает понять, почему Docker может занимать много места на диске или ресурсов системы и как это контролировать.

Почему важно следить за ресурсами Docker

Docker активно использует ресурсы системы:

Со временем на сервере могут накапливаться:

Если их не очищать, Docker может занять десятки или даже сотни гигабайт дискового пространства.

Поэтому регулярный мониторинг и очистка — важная часть администрирования Docker.

Просмотр нагрузки контейнеров

Просмотр использования ресурсов в реальном времени

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 сетевой трафик

Когда использовать

Полезно, если:

Проверка ресурсов одного контейнера

docker stats --no-stream <container>

Флаг --no-stream выводит статистику один раз, без постоянного обновления.

Пример:

docker stats --no-stream project_php

Это удобно, если нужно быстро проверить текущую нагрузку.

Проверка процессов внутри контейнера

Иногда нагрузку создаёт конкретный процесс.

Можно посмотреть процессы внутри контейнера:

docker compose top <service>

Пример:

docker compose top php

Вывод покажет процессы, которые выполняются внутри контейнера.

Это помогает определить, что именно создаёт нагрузку:

Проверка использования диска Docker

Посмотреть сколько места занимает Docker

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 system df -v

Флаг -v (verbose) показывает более подробную информацию:

Очистка неиспользуемых ресурсов

Со временем Docker оставляет множество временных объектов:

Их можно безопасно удалить.

Удаление неиспользуемых образов

docker image prune -f

Удаляет dangling images — образы, которые больше не используются контейнерами.

Когда использовать

Если после сборок осталось много старых образов.

Полная очистка Docker

docker system prune -f

Удаляет:

Важно понимать

Эта команда не удаляет volumes.

То есть:

останутся на месте.

Очистка volumes

docker volume prune -f

Удаляет неиспользуемые volumes.

Осторожно

Volumes могут содержать:

Поэтому перед удалением нужно убедиться, что volume действительно не используется.

Очистка сетей

docker network prune -f

Удаляет неиспользуемые Docker-сети.

Эта команда безопасна, потому что:

Проверка ресурсов Docker Engine

Иногда полезно посмотреть информацию о самой Docker-системе.

Проверка доступной памяти

docker info | grep -i memory

Показывает информацию о памяти, доступной Docker.

Проверка CPU

docker info | grep -i cpu

Показывает количество доступных CPU.

Проверка лимитов контейнера

Некоторые контейнеры могут иметь ограничения по памяти.

Проверить это можно так:

docker inspect <container> | grep -i memory

Пример:

docker inspect project_php | grep -i memory

Эта команда покажет:

Типичные проблемы с ресурсами

Docker занимает слишком много места

Самая частая причина — накопившиеся:

Решение:

docker system prune -f

Заполнен диск сервера

Проверить использование:

docker system df

Затем очистить ненужные данные.

Контейнер использует слишком много CPU

Найти контейнер:

docker stats

После этого:

Контейнер использует слишком много памяти

Возможные причины:

Проверить:

docker stats

Рекомендуемая регулярная очистка

На серверах разработки полезно периодически выполнять:

docker system prune -f

Если используется активная сборка образов:

docker builder prune -f

Типичный сценарий диагностики

Если сервер начал тормозить:

1 Проверить контейнеры

docker stats

2 Проверить диск

docker system df

3 Очистить ненужные данные

docker system prune -f

4 Проверить снова

docker system df

Краткая памятка

docker stats                         # нагрузка контейнеров в реальном времени
docker stats --no-stream <container> # разовая статистика

docker compose top <service>         # процессы внутри контейнера

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 <container> | grep -i memory   # лимиты контейнера
Глава 2 — Диагностика и обслуживание

Docker — Работа с сетями (Networks)

Эта страница объясняет, как Docker управляет сетями и как контейнеры взаимодействуют друг с другом. Здесь разобраны основные команды для просмотра сетей, диагностики сетевых проблем и проверки портов сервисов. Материал ориентирован на начинающих и помогает понять, как контейнеры находят друг друга внутри Docker-проекта и как сервисы становятся доступными снаружи.

Как работают сети в Docker

По умолчанию каждый контейнер подключается к одной или нескольким Docker-сетям. Сеть позволяет контейнерам:

Например, в одном проекте могут работать контейнеры:

Все они находятся в одной сети и могут обращаться друг к другу по имени сервиса:

php -> mysql
php -> redis
nginx -> php

Пример подключения к базе внутри контейнера:

mysql:3306

Где mysql — имя сервиса из docker-compose.yml.

Список Docker-сетей

Показать все сети

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

Когда запускается проект через:

docker compose up -d

Docker автоматически создаёт сеть:

projectname_default

Например:

site1_default

Все сервисы из docker-compose.yml автоматически подключаются к этой сети.

Это позволяет контейнерам обращаться друг к другу по имени сервиса.

Проверка сети проекта

Посмотреть информацию о сети

docker network inspect <network_name>

Пример:

docker network inspect site1_default

Эта команда показывает:

Пример вывода

Внутри результата можно увидеть блок:

"Containers": {
  "php_container": {
    "Name": "site1_php",
    "IPv4Address": "172.20.0.3"
  },
  "mysql_container": {
    "Name": "site1_mysql",
    "IPv4Address": "172.20.0.4"
  }
}

Это означает, что контейнеры подключены к сети и могут взаимодействовать.

Проверка портов сервисов

Контейнер может быть доступен:

Для доступа извне используются проброшенные порты.

Проверить порт сервиса

docker compose port <service> <port>

Пример:

docker compose port nginx 80

Результат:

0.0.0.0:8080

Это означает, что контейнерный порт 80 доступен на сервере через порт 8080.

Проверка портов через docker ps

Можно также проверить порты так:

docker ps

Пример вывода:

CONTAINER ID   IMAGE      PORTS
ab12cd34       nginx      0.0.0.0:8080->80/tcp

Это означает:

сервер:8080 -> контейнер:80

Подключение контейнера к сети

Иногда контейнер нужно подключить к существующей сети.

Подключить контейнер

docker network connect <network> <container>

Пример:

docker network connect site1_default redis_container

После этого контейнер сможет взаимодействовать с сервисами сети.

Отключение контейнера от сети

docker network disconnect <network> <container>

Пример:

docker network disconnect site1_default redis_container

Контейнер больше не сможет общаться с сервисами этой сети.

Проверка сетевого доступа внутри контейнера

Если сервисы не могут взаимодействовать, нужно проверить соединение.

Подключиться к контейнеру

docker compose exec php sh

Проверить доступ к другому сервису

Например, проверить базу данных:

ping mysql

или

nc -zv mysql 3306

Если соединение работает — сеть настроена правильно.

Проверка DNS внутри Docker

Docker автоматически создаёт DNS внутри сети.

Это позволяет обращаться к сервисам по имени.

Например:

mysql
redis
php
nginx

Проверить DNS

Внутри контейнера:

nslookup mysql

или

ping mysql

Если DNS работает, контейнер получит IP.

Типичные сетевые проблемы

Контейнеры не видят друг друга

Возможные причины:

Проверить:

docker network inspect <network>

Неверное имя сервиса

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

Пример:

mysql

а не:

project_mysql_1

Порт не доступен снаружи

Проверить docker-compose.yml.

Пример правильного проброса:

ports:
  - "8080:80"

Это означает:

сервер:8080 -> контейнер:80

Контейнер запущен, но сайт не открывается

Проверить:

docker ps

Если порт не указан — он не проброшен наружу.

Типичный сценарий диагностики сети

Если сервис не работает:

1 Проверить контейнеры

docker compose ps

2 Проверить сеть

docker network ls

3 Проверить подключенные контейнеры

docker network inspect <network>

4 Проверить DNS внутри контейнера

docker compose exec php ping mysql

Краткая памятка

docker network ls                       # список сетей
docker network inspect <network>        # информация о сети

docker compose port <service> <port>    # проверить проброс порта

docker network connect <network> <container>     # подключить контейнер
docker network disconnect <network> <container>  # отключить контейнер

docker ps                               # посмотреть проброшенные порты
Глава 2 — Диагностика и обслуживание

Docker — Logs (Работа с логами)

Эта страница объясняет, как Docker хранит и обрабатывает логи контейнеров. Здесь разобраны команды для просмотра логов, способы ограничения их размера, настройка log rotation и рекомендации по работе с логами в production. Материал рассчитан на начинающих и помогает понять, где хранятся Docker-логи и как предотвратить переполнение диска из-за их роста.

Что такое Docker Logs

Каждый контейнер записывает стандартные потоки вывода:

Docker автоматически сохраняет эти данные как логи контейнера.

Пример логов:

[INFO] Server started
[INFO] Connection established
[ERROR] Database connection failed

Логи помогают:

Просмотр логов контейнера

Показать логи контейнера

docker logs <container>

Пример:

docker logs nginx_container

Показать последние строки логов

docker logs --tail=100 <container>

Пример:

docker logs --tail=100 nginx_container

Это покажет последние 100 строк логов.

Просмотр логов в реальном времени

docker logs -f <container>

Пример:

docker logs -f nginx_container

Флаг -f означает follow — поток логов в реальном времени.

Выход из режима просмотра:

CTRL + C

Логи Docker Compose

Если используется Docker Compose, можно смотреть логи сервисов.

Логи сервиса

docker compose logs <service>

Пример:

docker compose logs nginx

Логи в реальном времени

docker compose logs -f <service>

Последние строки логов

docker compose logs --tail=100

Где Docker хранит логи

По умолчанию Docker использует драйвер логирования:

json-file

Файлы логов находятся в директории:

/var/lib/docker/containers/

Пример пути:

/var/lib/docker/containers/<container_id>/<container_id>-json.log

Эти файлы могут со временем значительно увеличиваться.

Проверка размера логов

Если диск сервера заполняется, одной из причин могут быть логи контейнеров.

Проверить размер можно так:

du -sh /var/lib/docker/containers/*

Это покажет размер логов каждого контейнера.

Ограничение размера логов

Чтобы логи не занимали весь диск, можно настроить log rotation.

Настройка логов в docker-compose.yml

Пример конфигурации:

services:
  app:
    image: my_app
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

Что означают параметры

Параметр Назначение
max-size максимальный размер файла логов
max-file количество файлов

Пример выше означает:

максимум 3 файла по 10 MB

То есть максимум:

30 MB логов

Глобальная настройка логов Docker

Ограничение логов можно задать для всего Docker.

Файл конфигурации:

/etc/docker/daemon.json

Пример:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

После изменения нужно перезапустить Docker:

sudo systemctl restart docker

Очистка логов контейнера

Иногда логи могут стать очень большими.

Можно очистить файл логов:

truncate -s 0 /var/lib/docker/containers/<container_id>/<container_id>-json.log

Важно: Очищать логи нужно осторожно и только при необходимости.

Проверка драйвера логирования

Можно посмотреть настройки логирования контейнера:

docker inspect <container>

В выводе нужно найти раздел:

LogConfig

Альтернативные драйверы логирования

Docker поддерживает разные драйверы логов.

Драйвер Назначение
json-file стандартный
syslog системный лог
journald systemd
fluentd централизованный лог
gelf Graylog

Для production часто используют централизованные системы логирования.

Типичные проблемы с логами

Логи занимают весь диск

Если log rotation не настроен, файлы логов могут вырасти до нескольких гигабайт.

Решение:

Слишком много логов

Некоторые приложения пишут слишком подробные логи.

Решение:

Невозможно найти ошибку

Иногда полезно посмотреть логи нескольких сервисов:

docker compose logs

Типичный сценарий диагностики

Если сервис не работает:

1 Проверить контейнер

docker compose ps

2 Посмотреть логи

docker compose logs --tail=100

3 Следить за логами

docker compose logs -f

Краткая памятка

docker logs <container>                 # логи контейнера
docker logs -f <container>              # логи в реальном времени
docker logs --tail=100 <container>      # последние строки

docker compose logs                     # логи всех сервисов
docker compose logs -f <service>        # логи сервиса

du -sh /var/lib/docker/containers/*     # размер логов

truncate -s 0 logfile                   # очистить лог
Глава 2 — Диагностика и обслуживание

Docker — Cleanup (Очистка и обслуживание)

Эта страница описывает команды и практики очистки Docker-окружения. Со временем на сервере накапливаются остановленные контейнеры, старые образы, build-cache и неиспользуемые volumes. Здесь разобраны способы безопасной очистки этих ресурсов и рекомендации по регулярному обслуживанию Docker-системы.

Почему Docker со временем занимает много места

При работе Docker постоянно создаёт временные и устаревшие ресурсы:

Если их не удалять, они могут занять десятки гигабайт диска.

Проверка использования диска Docker

Перед очисткой полезно проверить, сколько места занимает Docker.

docker system df

Пример вывода:

TYPE            TOTAL     ACTIVE    SIZE
Images          12        5         3.4GB
Containers      8         4         150MB
Local Volumes   6         4         8.2GB
Build Cache     -         -         2.1GB

Это показывает:

Очистка остановленных контейнеров

Контейнеры, которые были остановлены, продолжают существовать в системе.

Удалить их можно так:

docker container prune

Docker попросит подтверждение.

Чтобы выполнить без подтверждения:

docker container prune -f

Очистка неиспользуемых образов

Если контейнеры пересобираются, старые образы остаются в системе.

Удалить их можно так:

docker image prune

Удаляются dangling images — образы без тегов.

Удаление всех неиспользуемых образов

docker image prune -a

Эта команда удаляет все образы, которые не используются контейнерами.

Важно: После удаления Docker при следующем запуске контейнера может заново скачать образ.

Очистка неиспользуемых volumes

Volumes могут занимать много места, особенно если в них хранятся базы данных.

Удалить неиспользуемые volumes:

docker volume prune

Без подтверждения:

docker volume prune -f

Важно: Удаляются только volumes, не подключённые к контейнерам.

Очистка сетей

Иногда остаются неиспользуемые Docker-сети.

Удалить их можно так:

docker network prune

Полная очистка Docker

Docker предоставляет команду для очистки большинства временных ресурсов.

docker system prune

Удаляются:

Без подтверждения:

docker system prune -f

Полная очистка включая образы

docker system prune -a

Удаляются:

Очистка build cache

Build cache создаётся при сборке Docker-образов.

Удалить cache можно так:

docker builder prune

Без подтверждения:

docker builder prune -f

Проверка больших Docker-директорий

Иногда полезно посмотреть, какие директории занимают больше всего места.

du -sh /var/lib/docker/*

Это поможет понять, где именно находятся большие файлы.

Регулярная очистка Docker

На серверах разработки рекомендуется периодически выполнять:

docker system prune -f

Если активно собираются образы:

docker builder prune -f

Пример полной очистки

Пример набора команд:

docker container prune -f
docker image prune -a -f
docker volume prune -f
docker network prune -f
docker builder prune -f

Эти команды удаляют почти все неиспользуемые ресурсы.

Типичные проблемы с очисткой

Удаление volumes с данными

Если выполнить:

docker compose down -v

Docker удалит все volumes проекта, включая базы данных.

Поэтому эту команду нужно использовать осторожно.

Удаление образов перед деплоем

Если удалить все образы, Docker будет вынужден заново скачивать их из registry.

Это может занять время.

Когда нужно выполнять очистку

Очистку стоит выполнять, если:

Краткая памятка

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 накапливает большое количество неиспользуемых ресурсов:

Регулярная очистка системы помогает:

Глава 3 — Управление проектами

Глава 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-команд необходимо перейти в директорию проекта.

cd /opt/flamy_projects

Просмотреть содержимое папки:

ls -la

Когда используется

Эта команда помогает:

Поиск docker-compose файлов

Иногда на сервере много проектов, и нужно найти все compose-файлы.

find /opt/flamy_projects -type f -name "docker-compose*.yml"

Эта команда покажет:

Пример результата:

/opt/flamy_projects/site1/docker-compose.yml
/opt/flamy_projects/site2/docker-compose.yml
/opt/flamy_projects/api_service/docker-compose.yml

Когда полезно

Проверка файлов проекта

Перед запуском проекта полезно проверить содержимое директории.

ls -la

Пример:

docker-compose.yml
.env
Dockerfile
src/
logs/

Что важно проверить

Если файл docker-compose.yml отсутствует — проект запустить не получится.

Изменение владельца файлов

Иногда файлы проекта принадлежат неправильному пользователю. Это может происходить, если:

Исправить владельца можно так:

sudo chown -R Crimson:Crimson /opt/flamy_projects

Что означает команда

Часть Значение
chown изменить владельца
-R рекурсивно для всех файлов
Crimson:Crimson пользователь и группа

Назначение текущего пользователя владельцем

Иногда проще назначить владельцем текущего пользователя.

sudo chown -R $(id -u):$(id -g) /opt/flamy_projects

Что делают параметры

Команда Значение
id -u ID текущего пользователя
id -g ID текущей группы

Это позволяет быстро исправить проблемы с правами.

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

Иногда Docker или приложение не может читать файлы из-за неправильных прав.

Исправить можно так:

sudo chmod -R 755 /opt/flamy_projects

Что означает 755

Право Значение
7 чтение, запись, выполнение
5 чтение и выполнение
5 чтение и выполнение

В итоге:

Важно: Не стоит использовать 777, так как это даёт полный доступ всем пользователям и может быть небезопасно.

Резервное копирование проектов

Регулярное резервное копирование помогает защититься от:

Архивирование проекта

Создать архив можно с помощью tar.

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 позволяет копировать файлы между серверами или папками.

rsync -avz /opt/flamy_projects/ backup_location/

Что означают параметры

Параметр Назначение
-a архивный режим
-v подробный вывод
-z сжатие данных

Пример копирования на другой сервер

rsync -avz /opt/flamy_projects user@backup-server:/backup/docker_projects

Это часто используется для:

Проверка размера проекта

Иногда полезно узнать размер проекта.

du -sh /opt/flamy_projects/*

Пример вывода:

1.2G site1
850M site2
430M api_service

Это помогает определить:

Проверка логов проекта

Некоторые проекты сохраняют логи внутри директории.

Например:

logs/
storage/logs
var/log

Посмотреть последние строки:

tail -n 100 logs/app.log

Типичный рабочий процесс

Обычно работа с проектом выглядит так:

1 Перейти в директорию проекта

cd /opt/flamy_projects/site1

2 Проверить файлы

ls -la

3 Запустить контейнеры

docker compose up -d

4 Проверить контейнеры

docker compose ps

5 Проверить логи

docker compose logs --tail=50

Работа с несколькими проектами

На сервере может быть десятки проектов.

Чтобы понять, какие контейнеры запущены:

docker ps

Можно увидеть:

site1_nginx
site2_php
api_service_db

Это помогает быстро определить, какие проекты работают.

Полезные советы

Храните проекты в одной директории

Это упрощает:

Используйте .env файлы

В .env удобно хранить:

Делайте регулярные backup

Минимум раз в день для production-серверов.

Краткая памятка

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/*                 # размер проектов
Глава 3 — Управление проектами

Docker — Volumes (Хранение данных)

Эта страница объясняет, как Docker хранит постоянные данные контейнеров с помощью Volumes. Здесь разобраны основные типы хранения данных, команды управления volumes, а также практические примеры резервного копирования и восстановления данных. Материал рассчитан на начинающих и помогает понять, где Docker хранит данные и как не потерять их при пересоздании контейнеров.

Что такое Docker Volume

По умолчанию контейнеры Docker не сохраняют данные после удаления. Если контейнер удалить и создать заново, все файлы внутри него исчезнут.

Чтобы сохранить данные между перезапусками контейнеров, используются Volumes.

Volume — это специальное хранилище данных Docker, которое:

Почему volumes важны

Volumes используются для хранения постоянных данных, например:

Пример:

mysql container
│
└── /var/lib/mysql  → volume

Если контейнер удалить и создать заново, данные в volume сохранятся.

Где Docker хранит volumes

По умолчанию volumes находятся в системе Docker:

/var/lib/docker/volumes/

Каждый volume имеет свою директорию.

Пример структуры:

/var/lib/docker/volumes/mysql_data/_data

Типы хранения данных в Docker

Docker поддерживает несколько способов хранения данных.

1. Docker Volume

Это основной и рекомендуемый способ хранения данных.

Пример в docker-compose.yml:

services:
  mysql:
    image: mysql:8
    volumes:
      - mysql_data:/var/lib/mysql

volumes:
  mysql_data:

Преимущества:

2. Bind Mount

Bind mount подключает обычную папку сервера внутрь контейнера.

Пример:

services:
  app:
    volumes:
      - ./src:/var/www/html

Это означает:

сервер ./src  → контейнер /var/www/html

Используется для:

Разница между Volume и Bind Mount

Тип Описание
Volume управляется Docker
Bind mount обычная папка сервера

Обычно используется:

Просмотр volumes

Список volumes

docker volume ls

Пример вывода:

DRIVER    VOLUME NAME
local     site1_mysql_data
local     redis_cache

Информация о volume

docker volume inspect <volume_name>

Пример:

docker volume inspect site1_mysql_data

Результат покажет:

Создание volume

Создать volume можно вручную:

docker volume create mysql_data

После этого volume можно использовать в контейнерах.

Удаление volumes

Удалить один volume

docker volume rm <volume>

Пример:

docker volume rm mysql_data

Удалить неиспользуемые volumes

docker volume prune -f

Команда удаляет volumes, которые не используются контейнерами.

Важно: Перед удалением нужно убедиться, что volume не содержит важных данных.

Использование volumes в Docker Compose

Пример конфигурации:

services:
  mysql:
    image: mysql:8
    volumes:
      - mysql_data:/var/lib/mysql

volumes:
  mysql_data:

Это создаёт volume mysql_data, который будет хранить данные базы.

Проверка volumes контейнера

Можно посмотреть volumes конкретного контейнера:

docker inspect <container>

Пример:

docker inspect site1_mysql

В выводе нужно найти блок:

Mounts

Он показывает подключённые volumes.

Резервное копирование volume

Очень важная операция — backup данных.

Backup volume

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

Чтобы восстановить данные:

docker run --rm \
  -v mysql_data:/data \
  -v $(pwd):/backup \
  alpine tar xzf /backup/mysql_backup.tar.gz -C /

После этого данные снова появятся в volume.

Типичные ошибки при работе с volumes

Потеря данных после удаления контейнера

Если данные хранятся внутри контейнера, а не в volume, они будут потеряны.

Правильная практика:

volumes:
  - mysql_data:/var/lib/mysql

Удаление volume вместе с проектом

Команда:

docker compose down -v

удаляет:

Это приведёт к потере данных.

Использование bind mount для базы данных

Не рекомендуется хранить базы данных через bind mount.

Лучше использовать:

volumes:
  - mysql_data:/var/lib/mysql

Проверка volumes проекта

Показать volumes Compose проекта:

docker compose config --volumes

Это помогает понять, какие volumes использует проект.

Краткая памятка

docker volume ls                    # список volumes
docker volume inspect <volume>     # информация о volume
docker volume create <volume>      # создать volume
docker volume rm <volume>          # удалить volume

docker volume prune -f             # удалить неиспользуемые volumes

docker inspect <container>         # посмотреть volumes контейнера
Глава 3 — Управление проектами

Docker — Images (Управление образами)

Эта страница объясняет, что такое Docker-образы (Images), как они создаются, хранятся и управляются. Здесь разобраны основные команды для просмотра, загрузки, удаления и очистки образов. Материал рассчитан на начинающих и помогает понять, как работают Docker-образы и как управлять ими на сервере.

Что такое Docker Image

Docker Image — это шаблон контейнера, из которого создаются запущенные контейнеры.

Проще говоря:

Docker Image → контейнер

Пример:

nginx:1.25  → контейнер nginx
mysql:8     → контейнер mysql
node:18     → контейнер node

Image содержит:

Контейнер создаётся на основе образа и запускается как отдельный процесс.

Как работают Docker Images

Docker Images состоят из слоёв (layers).

Пример:

Base OS
↓
System packages
↓
Application dependencies
↓
Application code

Каждый слой кэшируется. Это позволяет Docker ускорять сборку образов.

Просмотр образов

Показать список образов

docker images

Пример вывода:

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.

docker pull <image>

Пример:

docker pull nginx:1.25

После этого образ появится в списке docker images.

Теги образов

Docker использует теги для обозначения версии образа.

Пример:

nginx:latest
nginx:1.25
node:18

Почему не стоит использовать latest

Тег latest может измениться в любой момент.

Лучше использовать фиксированную версию:

nginx:1.25

Это делает окружение более предсказуемым.

Удаление Docker Images

Удалить образ

docker rmi <image>

Пример:

docker rmi nginx:1.25

Удалить образ по ID

docker rmi <image_id>

Пример:

docker rmi a1b2c3d4e5

Удалить неиспользуемые образы

docker image prune -f

Удаляются dangling images — образы, которые больше не используются.

Полная очистка старых образов

Если на сервере накопилось много старых образов:

docker system prune -a

Эта команда удалит:

Важно: Использовать эту команду нужно осторожно, особенно на production.

Сборка образа

Образы можно создавать самостоятельно через Dockerfile.

Пример сборки:

docker build -t my_app .

Где:

Параметр Значение
-t тег образа
my_app имя образа
. текущая директория

Проверка истории образа

Можно посмотреть, из каких слоёв состоит образ:

docker history <image>

Пример:

docker history nginx

Это помогает понять:

Использование образа для запуска контейнера

Контейнер можно запустить напрямую:

docker run nginx

Но чаще используется Docker Compose.

Пример:

services:
  nginx:
    image: nginx:1.25

Поиск образов

Можно искать образы на Docker Hub:

docker search nginx

Пример результата:

NAME              DESCRIPTION
nginx             Official build of Nginx
nginx-unit        Nginx Unit runtime

Лучше использовать официальные образы.

Типичные проблемы с образами

Слишком много образов на сервере

Проверить:

docker images

Удалить старые:

docker image prune -f

Образ не обновляется

Если используется:

nginx:latest

Docker может использовать старую версию.

Решение:

docker pull nginx

Слишком большой размер образа

Некоторые образы могут занимать несколько гигабайт.

Проверить:

docker images

При необходимости удалить неиспользуемые.

Краткая памятка

docker images                     # список образов
docker pull <image>               # скачать образ
docker search <image>             # поиск образа

docker rmi <image>                # удалить образ
docker image prune -f             # удалить неиспользуемые образы

docker build -t <name> .          # собрать образ
docker history <image>            # история слоев образа

Глава 4 — Безопасность

Глава 4 — Безопасность

Docker — Безопасность и аудит

Эта страница объясняет базовые практики безопасности при работе с Docker. Здесь разобраны команды для проверки уязвимостей образов, анализа конфигурации Docker Compose и рекомендации по безопасной эксплуатации контейнеров. Материал рассчитан на начинающих и помогает понять, как обнаруживать потенциальные проблемы безопасности и минимизировать риски при работе с Docker-проектами.

Почему безопасность Docker важна

Контейнеры упрощают развертывание приложений, но сами по себе не гарантируют безопасность. Основные риски могут возникать из-за:

Поэтому рекомендуется регулярно:

Проверка образов на уязвимости

Docker предоставляет инструменты для анализа безопасности образов.

Сканирование образа

docker scan <image_name>

Пример:

docker scan nginx:latest

Команда анализирует образ и ищет известные уязвимости (CVE) в:

Пример результата:

✗ High severity vulnerability found in openssl
✗ Medium severity vulnerability found in libssl

Анализ образов через Docker Scout

Docker Scout — более современный инструмент анализа образов.

docker scout quickview <image_name>

Пример:

docker scout quickview node:18

Инструмент покажет:

Когда использовать сканирование

Рекомендуется проверять образы:

Проверка конфигурации Docker Compose

Иногда проблемы безопасности возникают из-за неправильной конфигурации сервисов.

Просмотр сервисов проекта

docker compose config --services

Команда выводит список сервисов, описанных в docker-compose.yml.

Пример:

nginx
php
mysql
redis

Это помогает убедиться, что Compose видит именно те сервисы, которые ожидаются.

Проверка volumes

docker compose config --volumes

Команда показывает volumes, используемые проектом.

Пример:

mysql_data
redis_cache

Почему это важно

Volumes могут содержать:

Важно понимать, где именно хранятся данные.

Проверка сетей проекта

docker compose config --networks

Команда показывает сети, которые использует проект.

Пример:

default
internal_network

Это помогает проверить, какие сервисы могут взаимодействовать между собой.

Обновление Docker-образов

Одной из главных причин уязвимостей является использование старых образов.

Обновить образы можно так:

docker compose pull

После загрузки новых образов нужно перезапустить сервисы:

docker compose up -d

Минимизация прав контейнеров

По умолчанию контейнеры могут иметь довольно широкий доступ к системе.

Рекомендуется:

Пример безопасной настройки в docker-compose.yml:

services:
  app:
    user: "1000:1000"

Это означает, что контейнер будет работать от обычного пользователя.

Ограничение ресурсов контейнеров

Чтобы контейнер не мог использовать все ресурсы сервера, можно задать лимиты.

Пример:

services:
  app:
    deploy:
      resources:
        limits:
          memory: 512M

Это защищает сервер от ситуаций, когда приложение начинает потреблять слишком много памяти.

Ограничение доступа к портам

Не стоит открывать порты контейнеров без необходимости.

Пример безопасной конфигурации:

ports:
  - "127.0.0.1:8080:80"

Это означает:

Использование .env файлов

Часто конфиденциальные данные хранятся в .env.

Пример:

DB_PASSWORD=secret_password
API_KEY=xxxxxxxx

Важно:

Проверка привилегированных контейнеров

Контейнеры, запущенные в режиме privileged, имеют почти полный доступ к системе.

Проверить можно так:

docker inspect <container>

В выводе нужно обратить внимание на поле:

Privileged: true

Если оно включено — контейнер имеет расширенные права.

Проверка запущенных контейнеров

Полезно периодически проверять список контейнеров:

docker ps

Это помогает обнаружить:

Проверка используемых образов

Можно посмотреть, какие образы используются:

docker images

Пример вывода:

nginx        latest
mysql        8
redis        7

Если используются очень старые версии — рекомендуется обновить их.

Типичные ошибки безопасности

Использование latest в production

Тег latest может неожиданно измениться.

Лучше указывать конкретную версию:

nginx:1.25

Открытые порты без необходимости

Если порт не нужен извне — не стоит его публиковать.

Запуск контейнера с root-доступом

Лучше запускать контейнеры от обычного пользователя.

Хранение секретов в репозитории

Пароли и ключи лучше хранить:

Типичный сценарий проверки безопасности

1 Проверить контейнеры

docker ps

2 Проверить образы

docker images

3 Проверить уязвимости

docker scout quickview nginx

4 Проверить конфигурацию compose

docker compose config

5 Обновить образы

docker compose pull

Краткая памятка

docker scan <image>                     # сканирование уязвимостей
docker scout quickview <image>          # анализ безопасности образа

docker compose config --services        # список сервисов
docker compose config --volumes         # volumes проекта
docker compose config --networks        # сети проекта

docker compose pull                     # обновить образы

docker ps                               # список контейнеров
docker images                           # список образов
docker inspect <container>              # информация о контейнере

Глава 5 — Решение проблем

Глава 5 — Решение проблем

Docker Troubleshooting — Решение типичных проблем

Эта страница содержит инструкции по диагностике и устранению наиболее распространённых проблем при работе с Docker и Docker Compose. Здесь описаны типичные ситуации: контейнер не запускается, сервис падает после старта, приложение недоступно или контейнеры не видят друг друга. Материал ориентирован на начинающих и показывает пошаговый подход к поиску и устранению проблем.

Общий алгоритм диагностики

Если сервис или контейнер работает неправильно, рекомендуется придерживаться следующего порядка проверки:

  1. проверить статус контейнеров
  2. проверить логи
  3. проверить состояние сети
  4. проверить использование ресурсов
  5. проверить конфигурацию Docker Compose

Этот подход помогает быстро определить источник проблемы.

Контейнер не запускается

Проверить статус контейнеров

docker compose ps

Пример вывода:

NAME          STATUS
project_php   Exited (1)
project_nginx Up

Если контейнер имеет статус:

Exited

это означает, что приложение внутри контейнера завершилось с ошибкой.

Проверить логи контейнера

docker compose logs <service>

Пример:

docker compose logs php

Часто в логах можно увидеть причину проблемы:

Контейнер постоянно перезапускается

Иногда контейнер запускается, но сразу падает и перезапускается.

Проверить статус:

docker ps

Пример:

Restarting (1) 10 seconds ago

Посмотреть логи в реальном времени

docker compose logs -f <service>

Это позволит увидеть, на каком этапе происходит ошибка.

Порт уже используется

Ошибка запуска контейнера может выглядеть так:

Bind for 0.0.0.0:80 failed: port is already allocated

Это означает, что порт уже используется другим процессом.

Проверить, кто использует порт

sudo lsof -i :80

или

netstat -tulpn | grep 80

Возможные решения

Пример изменения порта:

ports:
  - "8080:80"

Изменения в Dockerfile не применяются

Docker активно использует кэш при сборке образов. Иногда это приводит к тому, что изменения не применяются.

Пересобрать образ без кэша

docker compose build --no-cache

После этого нужно запустить контейнеры:

docker compose up -d

Контейнер не видит изменения файлов

Если используется volume для подключения кода:

volumes:
  - ./app:/var/www/app

иногда изменения в коде могут не применяться.

Проверить содержимое внутри контейнера

docker compose exec <service> ls /var/www/app

Возможные причины

Контейнеры не видят друг друга

Если сервисы не могут взаимодействовать:

например:

php -> mysql

Проверить сеть

docker network ls

Проверить подключенные контейнеры

docker network inspect <network>

Проверить соединение внутри контейнера

docker compose exec php ping mysql

Если соединение не работает — возможно сервис не запущен или контейнеры находятся в разных сетях.

Контейнер завис

Иногда контейнер перестаёт реагировать на команды.

Попробовать перезапустить:

docker restart <container>

Если это не помогает:

docker kill <container>

Docker занимает слишком много места

Со временем Docker может занимать большое количество дискового пространства.

Проверить использование:

docker system df

Очистить неиспользуемые ресурсы

docker system prune -f

Очистить volumes

docker volume prune -f

Важно: Перед удалением volumes убедитесь, что они не содержат важных данных.

Контейнер не отвечает по HTTP

Если сайт или API не открывается:

Проверить контейнеры

docker compose ps

Проверить проброс портов

docker ps

Пример:

0.0.0.0:8080->80/tcp

Проверить доступ внутри контейнера

docker compose exec nginx curl localhost

Если внутри контейнера всё работает — проблема может быть в сетевых настройках.

Проверка конфигурации Docker Compose

Перед запуском полезно проверить итоговую конфигурацию:

docker compose config

Команда показывает:

Это помогает обнаружить:

Быстрая диагностика (чеклист)

Если сервис не работает:

1 Проверить контейнеры

docker compose ps

2 Проверить логи

docker compose logs --tail=100

3 Проверить ресурсы

docker stats

4 Проверить сеть

docker network inspect <network>

5 Проверить конфигурацию

docker compose config

Частые ошибки новичков

Запуск Docker-команд не из директории проекта

Если команда docker compose выполняется не там, где лежит docker-compose.yml, Docker не сможет найти конфигурацию.

Неправильные имена сервисов

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

Пример правильного имени:

mysql

Отсутствие .env файла

Если в docker-compose.yml используются переменные окружения, но файл .env отсутствует, сервис может не запуститься.

Краткая памятка

docker compose ps                        # статус контейнеров
docker compose logs <service>            # логи сервиса
docker compose logs -f <service>         # логи в реальном времени

docker restart <container>               # перезапуск контейнера
docker kill <container>                  # принудительная остановка

docker network inspect <network>         # проверка сети
docker stats                             # использование ресурсов

docker system df                         # использование диска
docker system prune -f                   # очистка Docker

docker compose config                    # проверка конфигурации

Итог

Большинство проблем Docker можно диагностировать с помощью нескольких команд:

Последовательное использование этих инструментов позволяет быстро определить источник проблемы и восстановить работу контейнеров.

Глава 5 — Решение проблем

Docker Debug Flow — Что делать, если контейнер не работает

Эта страница описывает пошаговый алгоритм диагностики Docker-контейнеров. Она помогает быстро определить причину проблемы, если контейнер не запускается, сервис недоступен или приложение работает некорректно. Материал ориентирован на начинающих и представляет собой универсальный чеклист диагностики Docker-проблем.

Общий принцип диагностики

Большинство проблем с Docker можно найти, последовательно проверив:

  1. статус контейнеров
  2. логи контейнеров
  3. сетевые настройки
  4. использование ресурсов
  5. конфигурацию Docker Compose

Чаще всего проблема обнаруживается уже на втором шаге — в логах.

Шаг 1 — Проверить контейнеры

Сначала нужно убедиться, что контейнер действительно запущен.

docker compose ps

или

docker ps

Пример результата:

NAME         STATUS
site_nginx   Up
site_php     Exited (1)
site_mysql   Up

Если контейнер имеет статус:

Exited

это означает, что приложение внутри контейнера завершилось с ошибкой.

Шаг 2 — Проверить логи

Логи — главный источник информации о проблеме.

docker compose logs <service>

Пример:

docker compose logs php

Если контейнер только что перезапустился, удобно смотреть логи в реальном времени:

docker compose logs -f php

Шаг 3 — Проверить порты

Если сервис работает, но недоступен извне, нужно проверить проброс портов.

docker ps

Пример:

0.0.0.0:8080->80/tcp

Это означает:

сервер:8080 → контейнер:80

Если порт не указан — он не открыт наружу.

Шаг 4 — Проверить сеть контейнеров

Если сервисы не видят друг друга, нужно проверить Docker-сети.

docker network ls

Проверить контейнеры в сети:

docker network inspect <network>

Шаг 5 — Проверить соединение внутри контейнера

Иногда нужно зайти внутрь контейнера.

docker compose exec <service> sh

После этого можно проверить соединение.

Пример проверки базы данных:

ping mysql

или

nc -zv mysql 3306

Шаг 6 — Проверить ресурсы

Если сервер перегружен, контейнеры могут работать нестабильно.

Проверить использование ресурсов:

docker stats

Проверить использование диска:

docker system df

Шаг 7 — Проверить конфигурацию Compose

Ошибки в docker-compose.yml могут привести к неправильному запуску контейнеров.

Проверить конфигурацию:

docker compose config

Эта команда покажет итоговую конфигурацию после обработки переменных.

Частые причины проблем

Ошибка в конфигурации

Неправильный YAML или пропущенная переменная.

Решение:

docker compose config

Порт уже используется

Ошибка:

Bind for 0.0.0.0:80 failed

Проверить процесс:

sudo lsof -i :80

Контейнер падает после запуска

Проверить логи:

docker compose logs

Контейнеры не видят друг друга

Проверить сеть:

docker network inspect <network>

Закончился диск

Проверить:

docker system df

Очистить Docker:

docker system prune -f

Быстрый алгоритм диагностики

1 Проверить контейнеры
docker compose ps

2 Проверить логи
docker compose logs

3 Проверить порты
docker ps

4 Проверить сеть
docker network inspect

5 Проверить ресурсы
docker stats

6 Проверить конфигурацию
docker compose config

Мини-чеклист диагностики

Если сервис не работает:

Глава 6 — Деплой и обновление проектов

Глава 6 — Деплой и обновление проектов

Docker — Production Deployment Workflow

Эта страница описывает рекомендуемый процесс обновления и развёртывания Docker-проектов на production-сервере. Здесь показан безопасный порядок действий при обновлении кода, образов и контейнеров, а также базовые проверки после деплоя. Материал ориентирован на начинающих и помогает выполнять обновления предсказуемо и без случайных простоев сервисов.

Что такое Deployment Workflow

Deployment Workflow — это последовательность действий, которую нужно выполнять при обновлении проекта.

Без чёткой процедуры часто возникают проблемы:

Поэтому важно использовать одинаковый и проверенный порядок действий.

Типичная структура проекта

Пример директории проекта:

/opt/flamy_projects/site1

docker-compose.yml
.env
Dockerfile
src/

Где:

Файл Назначение
docker-compose.yml конфигурация сервисов
Dockerfile инструкция сборки образа
.env переменные окружения
src исходный код приложения

Стандартная процедура обновления проекта

Шаг 1 — перейти в директорию проекта

cd /opt/flamy_projects/site1

Проверить файлы:

ls -la

Важно убедиться, что вы находитесь в правильной директории проекта.

Шаг 2 — обновить код проекта

Если используется Git:

git pull

Команда скачивает последние изменения из репозитория.

Когда это нужно

Шаг 3 — обновить Docker-образы

Если проект использует готовые образы из registry, нужно загрузить новые версии.

docker compose pull

Команда скачает новые версии образов, указанных в docker-compose.yml.

Шаг 4 — пересобрать контейнеры (если требуется)

Если изменились:

нужно пересобрать образ.

docker compose up -d --build

Эта команда:

  1. пересоберёт образы
  2. обновит контейнеры
  3. запустит сервисы

Шаг 5 — проверить состояние контейнеров

docker compose ps

Пример результата:

NAME           STATUS
site1_nginx    Up
site1_php      Up
site1_mysql    Up

Все сервисы должны иметь статус Up.

Шаг 6 — проверить логи

После обновления важно убедиться, что сервисы работают корректно.

docker compose logs --tail=50

В логах не должно быть:

Шаг 7 — проверить работу приложения

После деплоя рекомендуется проверить:

Быстрое обновление проекта

На практике часто используется короткая команда:

docker compose pull && docker compose up -d

Она:

  1. скачивает новые образы
  2. обновляет контейнеры

Это самый быстрый способ обновить сервис.

Полное обновление проекта

Если нужно полностью пересобрать контейнеры:

docker compose build --no-cache
docker compose up -d

Это полезно, если:

Полный перезапуск проекта

Иногда требуется полностью остановить и заново запустить сервисы.

docker compose down
docker compose up -d

Это может помочь при:

Перезапуск одного сервиса

Если проблема только в одном сервисе:

docker compose restart nginx

Это быстрее и безопаснее, чем перезапуск всего проекта.

Откат версии (Rollback)

Если после обновления возникли проблемы, можно откатиться к предыдущей версии.

Пример:

git checkout <previous_commit>
docker compose up -d --build

Это восстановит предыдущую рабочую версию приложения.

Проверка после деплоя

После обновления рекомендуется выполнить несколько проверок.

Проверить контейнеры

docker ps

Это покажет все работающие контейнеры.

Проверить ресурсы

docker stats

Позволяет убедиться, что сервисы не перегружают сервер.

Проверить сети

docker network ls

Если сервисы не взаимодействуют — возможно проблема в сети.

Типичный production workflow

Чаще всего используется следующий порядок действий:

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

Лучше указывать фиксированные версии образов:

nginx:1.25

Это делает деплой более предсказуемым.

Краткая памятка

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 <service>
docker compose down && docker compose up -d

Итог

Правильный workflow обновления Docker-проектов позволяет:

Использование чёткой процедуры деплоя помогает поддерживать стабильную работу production-систем и упрощает администрирование Docker-инфраструктуры.

Глава 6 — Деплой и обновление проектов

Docker — Backup (Резервное копирование данных)

Эта страница описывает способы резервного копирования данных Docker-проектов. Здесь разобраны методы backup контейнерных данных, volumes и баз данных, а также способы восстановления данных. Материал рассчитан на начинающих и помогает понять, как защитить данные Docker-приложений от потери при сбоях, обновлениях или ошибках администрирования.

Почему резервное копирование важно

Docker-контейнеры можно легко пересоздать, но данные приложения могут быть потеряны, если они не вынесены в volumes или не сохраняются отдельно.

Резервное копирование особенно важно для:

Даже небольшая ошибка (например, удаление volume) может привести к потере данных.

Что нужно резервировать

В Docker-проектах обычно нужно делать backup:

Тип данных Пример
Базы данных MySQL, PostgreSQL
Docker volumes данные контейнеров
Файлы приложения uploads, storage
Конфигурации .env, config

Backup базы данных из контейнера

Самый распространённый способ — использовать встроенные утилиты базы данных.

Backup MySQL

docker compose exec mysql mysqldump -u root -p database_name > backup.sql

Эта команда:

  1. подключается к контейнеру MySQL
  2. делает дамп базы
  3. сохраняет файл backup.sql

Backup PostgreSQL

docker compose exec postgres pg_dump -U postgres database_name > backup.sql

Backup Docker Volume

Если данные хранятся в volume, можно сделать архив.

Создание backup volume

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 создаёт архив

В результате появится файл:

volume_backup.tar.gz

Восстановление volume

Чтобы восстановить данные из backup:

docker run --rm \
  -v volume_name:/data \
  -v $(pwd):/backup \
  alpine tar xzf /backup/volume_backup.tar.gz -C /

Данные будут восстановлены в volume.

Backup директории проекта

Иногда нужно сохранить весь Docker-проект.

Архив проекта

tar -czf project_backup_$(date +%Y%m%d).tar.gz /opt/flamy_projects/site1

Архив будет содержать:

Backup пользовательских файлов

Если приложение хранит файлы в директории:

/var/www/storage

Можно сделать backup так:

tar -czf storage_backup.tar.gz storage/

Backup через rsync

rsync часто используется для копирования backup на другой сервер.

rsync -avz /opt/flamy_projects user@backup-server:/backup/docker_projects

Это позволяет хранить резервные копии на отдельном сервере.

Автоматизация backup (cron)

Backup можно запускать автоматически.

Пример cron-задачи:

crontab -e

Добавить строку:

0 3 * * * /usr/local/bin/docker_backup.sh

Это будет запускать backup каждый день в 03:00.

Пример простого backup-скрипта

#!/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

Очень важно проверять резервные копии.

Проверить архив:

tar -tzf backup.tar.gz

Проверить SQL-дамп:

head backup.sql

Типичные ошибки при backup

Backup только контейнеров

Контейнеры легко пересоздаются, поэтому важно сохранять данные, а не контейнеры.

Отсутствие автоматического backup

Ручной backup часто забывают делать.

Лучше использовать cron.

Хранение backup на том же сервере

Если сервер выйдет из строя, backup тоже может быть потерян.

Лучше хранить копии:

Рекомендуемая стратегия backup

Минимальная стратегия:

Краткая памятка

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 — Управление сервисами

Запуск всех сервисов:

docker compose up -d

Остановка проекта:

docker compose down

Пересборка контейнеров:

docker compose up -d --build

Пересоздание контейнеров:

docker compose up -d --force-recreate

Скачать новые образы:

docker compose pull

Перезапуск сервиса:

docker compose restart <service>

Запуск одного сервиса:

docker compose up -d <service>

Контейнеры

Список запущенных контейнеров:

docker ps

Все контейнеры (включая остановленные):

docker ps -a

Остановить контейнер:

docker stop <container>

Запустить контейнер:

docker start <container>

Перезапустить контейнер:

docker restart <container>

Удалить контейнер:

docker rm <container>

Удалить все остановленные контейнеры:

docker container prune

Логи

Показать логи контейнера:

docker logs <container>

Логи в реальном времени:

docker logs -f <container>

Последние строки логов:

docker logs --tail=100 <container>

Логи сервиса Compose:

docker compose logs <service>

Подключение к контейнеру

Подключиться к shell:

docker exec -it <container> sh

Использовать bash:

docker exec -it <container> bash

Выполнить команду:

docker exec <container> <command>

Образы (Images)

Список образов:

docker images

Скачать образ:

docker pull <image>

Удалить образ:

docker rmi <image>

Удалить неиспользуемые образы:

docker image prune

Собрать образ:

docker build -t <image_name> .

Volumes

Список volumes:

docker volume ls

Информация о volume:

docker volume inspect <volume>

Создать volume:

docker volume create <volume>

Удалить volume:

docker volume rm <volume>

Удалить неиспользуемые volumes:

docker volume prune

Сети

Список сетей:

docker network ls

Информация о сети:

docker network inspect <network>

Удалить неиспользуемые сети:

docker network prune

Мониторинг и ресурсы

Использование ресурсов контейнеров:

docker stats

Использование диска Docker:

docker system df

Информация о Docker:

docker info

Очистка Docker

Удалить остановленные контейнеры:

docker container prune

Удалить неиспользуемые образы:

docker image prune

Удалить volumes:

docker volume prune

Удалить сети:

docker network prune

Полная очистка системы:

docker system prune

Полезные команды

Копирование файла из контейнера:

docker cp <container>:/path/file .

Копирование файла в контейнер:

docker cp file <container>:/path/

Просмотр процессов контейнера:

docker top <container>

История образа:

docker history <image>

Быстрые сценарии

Перезапустить проект:

docker compose down
docker compose up -d

Обновить образы и контейнеры:

docker compose pull
docker compose up -d

Пересобрать контейнеры:

docker compose build --no-cache
docker compose up -d

Итог

Этот cheat sheet содержит основные команды Docker, которые чаще всего используются при:

Он предназначен для быстрого поиска команд без необходимости просматривать всю документацию.