Docker в 2026: Полное практическое руководство по установке, образам и контейнерам для DevOps и системных администраторов | AdminWiki
Timeweb Cloud — сервера, Kubernetes, S3, Terraform. Лучшие цены IaaS.
Попробовать

Docker в 2026: Полное практическое руководство по установке, образам и контейнерам для DevOps и системных администраторов

02 апреля 2026 12 мин. чтения
Содержание статьи

Docker остается фундаментальным инструментом для DevOps инженеров и системных администраторов в 2026 году. Его роль в обеспечении изоляции, воспроизводимости и масштабируемости инфраструктуры не уменьшилась, а методы работы с ним стали более стандартизированными и безопасными. Этот гайд предоставляет актуальные, проверенные на практике инструкции для установки Docker на современные серверные ОС, управления жизненным циклом контейнеров и создания оптимизированных образов для production-среды. Мы сосредоточимся на конкретных командах и конфигурациях, которые работают сегодня, чтобы вы могли сразу применять их в рабочих сценариях, экономя время и снижая риск ошибок.

Контейнерная технология, как показано в статье «Что такое Docker: концепция контейнеризации для системных администраторов и DevOps», решает ключевые задачи изоляции сред и управления зависимостями. В этом руководстве мы углубимся в практическую реализацию этих концепций.

Установка и настройка Docker в 2026: актуальные инструкции для Linux и Windows Server

Процесс установки Docker за последние годы стал более унифицированным благодаря официальным репозиториям, но сохраняет важные различия для Linux и Windows Server. Правильная первоначальная настройка предотвращает множество проблем с правами доступа, сетью и производительностью.

Установка на современных дистрибутивах Linux (Ubuntu 24.04+, RHEL 9+)

Для большинства серверных дистрибутивов Linux рекомендуется установка из официальных репозиториев Docker. Это обеспечивает получение актуальных и стабильных версий.

Ubuntu 24.04 LTS и Debian-based системы:

# 1. Обновление индексов пакетов
sudo apt update
sudo apt install -y ca-certificates curl

# 2. Добавление официального GPG-ключа Docker
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# 3. Добавление репозитория
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
  | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# 4. Установка пакетов Docker Engine
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# 5. Проверка установки
sudo docker run hello-world

RHEL 9, CentOS Stream 9, AlmaLinux 9:

# 1. Установка необходимых пакетов
sudo yum install -y yum-utils

# 2. Добавление репозитория Docker
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

# 3. Установка Docker Engine
sudo yum install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# 4. Запуск и проверка
sudo systemctl start docker
sudo docker run hello-world

Для кастомных окружений или систем без стандартного менеджера пакетов можно использовать установку из бинарного файла, но это требует дополнительных шагов по управлению зависимостями и обновлениям.

Развертывание Docker Engine на Windows Server 2022/2026

На Windows Server Docker работает в двух режимах: контейнеры Windows (для приложений .NET Framework и других Windows-сервисов) и контейнеры Linux (через подсистему WSL 2). Для большинства современных микросервисов и открытого ПО рекомендуется режим Linux.

Инструкция через PowerShell (администратор):

# 1. Установка модуля DockerMsftProvider
Install-Module -Name DockerMsftProvider -Force

# 2. Установка Docker с помощью PackageManagement
Install-Package -Name docker -ProviderName DockerMsftProvider -Force

# 3. После установки необходимо настроить WSL 2 для работы с Linux контейнерами
# (Если планируется использовать только контейнеры Windows, этот шаг можно пропустить)
wsl --install -d Ubuntu-24.04

# 4. Проверка установки
docker version

Ключевые различия от Linux-инсталляции:

  • Демон Docker на Windows интегрируется с Hyper-V для создания легких виртуальных машин, в которых запускаются контейнеры Linux.
  • Сетевые драйверы и управление хранилищами имеют специфичные для Windows параметры.
  • Режим контейнеров Windows обеспечивает полную интеграцию с системой, но поддерживает меньшее количество образов.

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

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

Добавление пользователя в группу docker:

sudo usermod -aG docker $USER
# После этого необходимо перелогиниться или выполнить
newgrp docker

Это позволяет запускать команды Docker без sudo, но требует понимания рисков безопасности (пользователь получает доступ к демону Docker).

Настройка демона Docker через daemon.json:

# Создание или редактирование файла конфигурации
sudo nano /etc/docker/daemon.json

Пример конфигурации для production-среды:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "data-root": "/var/lib/docker",
  "insecure-registries": [],
  "features": {
    "buildkit": true
  }
}

Проверка работоспособности и диагностика:

  • docker info – показывает общую информацию о установке, включая количество контейнеров, образов, версию и настройки.
  • docker version – проверяет версии клиента и сервера.
  • Ошибка «Cannot connect to the Docker daemon» обычно означает, что демон не запущен (sudo systemctl start docker).
  • Ошибка «permission denied» указывает на необходимость добавления пользователя в группу docker или использования sudo.

Важно: на некоторых системах (особенно RHEL/Fedora) может быть предустановлен Podman, который конфликтует с Docker. Убедитесь, что вы используете именно Docker демон.

Работа с Docker образами и контейнеры: от базовых команд до жизненного цикла

После установки необходимо освоить основные операции с образами и контейнерами. Это фундамент для ежедневного администрирования.

Ключевые команды для управления образами: поиск, загрузка, удаление

Образ – это шаблон, из которого создаются контейнеры. Эффективное управление ими критично для поддержания порядка в инфраструктуре.

# Поиск образов в Docker Hub
docker search nginx

# Загрузка (pull) образов
docker pull nginx:1.25-alpine
docker pull ubuntu:24.04

# Список локальных образов
docker image ls
# или
docker images

# Удаление образов
docker image rm nginx:1.25-alpine
# Удаление всех образов без тегов (dangling)
docker image prune
# Удаление всех неиспользуемых образов (агрессивная очистка)
docker image prune -a

# Инспекция образа для просмотра деталей
docker image inspect nginx:1.25-alpine

# Просмотр истории создания слоев образа
docker history nginx:1.25-alpine

Работа с тегами позволяет версионировать образы. Использование конкретного тега (например, 1.25-alpine) вместо latest повышает стабильность и воспроизводимость развертываний.

Запуск и мониторинг контейнеров: от detached-режима до просмотра логов

Контейнер – это запущенный экземпляр образа. Умение контролировать его состояние – ключевой навык.

# Запуск контейнера в фоновом режиме (detached)
docker run -d --name my-nginx -p 8080:80 nginx:1.25-alpine

# Запуск контейнера в интерактивном режиме (например, для тестирования)
docker run -it --rm ubuntu:24.04 /bin/bash

# Просмотр списка запущенных контейнеров
docker ps
# Просмотр всех контейнеров (включая остановленные)
docker ps -a

# Просмотр логов контейнера в реальном времени
docker logs -f my-nginx

# Мониторинг потребления ресурсов CPU и памяти
docker stats my-nginx

# Получение детальной информации о контейнере
docker inspect my-nginx

# Интерактивный вход в запущенный контейнер
docker exec -it my-nginx /bin/sh

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

Управление жизненным циклом: обновление, откат и graceful shutdown

В production-среде важно управлять контейнерами планово, обеспечивая обновления без простоя и корректное завершение работы.

Базовый паттерн обновления сервиса:

# 1. Остановка старого контейнера
docker stop my-nginx

# 2. Удаление старого контейнера (опционально)
docker rm my-nginx

# 3. Запуск нового контейнера с обновленным образом
docker run -d --name my-nginx -p 8080:80 nginx:1.26-alpine

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

Настройка политик перезапуска: Docker может автоматически перезапускать контейнеры при их завершении или при перезагрузке демона.

docker run -d --name my-nginx --restart unless-stopped -p 8080:80 nginx:1.25-alpine

Политика unless-stopped перезапускает контейнер всегда, кроме случаев, когда он был явно остановлен пользователем командой docker stop.

Graceful shutdown: Для корректного завершения работы приложения внутри контейнера необходимо:

  • В приложении реализовать обработку сигнала SIGTERM (для сохранения состояния, закрытия соединений).
  • Команда docker stop сначала отправляет SIGTERM, затем после таймаута (по умолчанию 10 секунд) – SIGKILL.
  • Таймаут можно увеличить: docker stop -t 30 my-nginx.

Создание оптимизированных Dockerfile: лучшие практики 2026 года для production

Dockerfile – это инструкция для создания образов. Следование современным практикам позволяет создавать безопасные, минимальные и эффективные образы, что критично для CI/CD и безопасности инфраструктуры. Глубокое погружение в эту тему доступно в отдельном руководстве «Практики создания Dockerfile в 2026: безопасные и эффективные образы».

Многоступенчатые сборки (Multi-stage builds) для минимальных образов

Многоступенчатая сборка позволяет использовать один Dockerfile для нескольких этапов, перенося только необходимые артефакты в финальный образ. Это главный инструмент для радикального уменьшения размера.

Пример для Go-приложения:

# Этап 1: Builder – используется для компиляции
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN go build -o myapp ./cmd/main.go

# Этап 2: Runtime – минимальный образ только для запуска
FROM alpine:3.20
WORKDIR /app
# Копируем только бинарный файл из builder-этапа
COPY --from=builder /app/myapp ./myapp
# Создаем непривилегированного пользователя для безопасности
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser
EXPOSE 8080
CMD ["./myapp"]

Результат: финальный образ содержит только бинарник и минимальную ОС Alpine (~5-10 MB), вместо полного образ Go с компилятором и инструментами (~300 MB).

Безопасность production-образов: non-root пользователи и сканирование уязвимостей

Запуск контейнеров от непривилегированного пользователя снижает риски в случае уязвимости в приложении.

FROM python:3.12-slim

# ... установка зависимостей ...

# Создание непривилегированного пользователя и группы
RUN groupadd -r appgroup && useradd -r -g appgroup appuser

# Переключение на непривилегированного пользователя
USER appuser

CMD ["python", "app.py"]

Регулярное сканирование образов на уязвимости (CVE) должно быть частью CI/CD процесса.

# Использование Docker Scan (интегрировано в Docker Desktop)
docker scan my-image:latest

# Использование Trivy (популярный standalone инструмент)
trivy image my-image:latest

Также важно фиксировать версии базовых образов и пакетов в Dockerfile, избегая latest, и регулярно обновлять их по расписанию.

Кэширование слоев и ускорение сборки: правильная структура инструкций

Docker кэширует результаты выполнения каждой инструкции в Dockerfile как отдельный слой. Правильный порядок инструкций значительно сокращает время сборки.

Плохая структура (частая пересборка):

FROM ubuntu:24.04
COPY . .
RUN apt update && apt install -y python3 python3-pip
RUN pip install -r requirements.txt

Оптимизированная структура (максимальное использование кэша):

FROM ubuntu:24.04
RUN apt update && apt install -y python3 python3-pip
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .

Принципы:

  • Инструкции, которые редко меняются (установка системных пакетов), должны быть выше.
  • Инструкции, которые часто меняются (копирование исходного кода), должны быть ниже.
  • Копирование файлов зависимостей (requirements.txt, package.json) и их установка должны происходить до копирования всего кода.
  • Группировка нескольких команд в одну инструкцию RUN уменьшает количество слоев.
  • Использование BuildKit (включен по умолчанию в современных версиях) предоставляет продвинутые возможности кэширования.

Docker Compose для оркестрации контейнеров: развертывание стека сервисов

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

Структура docker-compose.yml: от базовых настроек до зависимостей

Основные секции файла:

  • services: Определяет каждый контейнер (сервис) в приложении.
  • networks: Создает пользовательские сети для изоляции трафика.
  • volumes: Определяет тома для хранения данных.

Ключевые директивы для сервисов:

services:
  web:
    build: .  # Собрать образ из Dockerfile в текущей директории
    image: myapp:latest  # Использовать готовый образ
    ports:
      - "8080:80"
    environment:
      - DB_HOST=db
      - DB_PORT=5432
    volumes:
      - ./config:/app/config  # bind mount
      - app-data:/app/data    # named volume
    depends_on:
      - db  # Зависимость от другого сервиса
    healthcheck:  # Проверка здоровья для orchestration
      test: ["CMD", "curl", "-f", "http://localhost/health"]
      interval: 30s
      timeout: 10s
      retries: 3

Настройка healthcheck позволяет Docker Compose (и оркестраторам) понимать, когда сервис готов к работе.

Рабочий пример: развертывание веб-приложения с БД и reverse proxy

Полный пример docker-compose.yml для типового веб-приложения:

version: '3.8'

services:
  postgres:
    image: postgres:16-alpine
    container_name: app-db
    environment:
      POSTGRES_DB: myappdb
      POSTGRES_USER: appuser
      POSTGRES_PASSWORD: securepassword
    volumes:
      - postgres-data:/var/lib/postgresql/data
    networks:
      - app-network
    restart: unless-stopped

  backend:
    build: ./backend  # Dockerfile находится в директории ./backend
    container_name: app-backend
    environment:
      DATABASE_URL: postgresql://appuser:securepassword@postgres:5432/myappdb
    depends_on:
      postgres:
        condition: service_healthy
    volumes:
      - backend-logs:/app/logs
    networks:
      - app-network
    restart: unless-stopped

  nginx:
    image: nginx:1.26-alpine
    container_name: app-proxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d  # Конфигурация Nginx через bind mount
      - ./static:/usr/share/nginx/html/static
    depends_on:
      - backend
    networks:
      - app-network
    restart: unless-stopped

volumes:
  postgres-data:
  backend-logs:

networks:
  app-network:
    driver: bridge

Запуск стека:

docker compose up -d

В этой конфигурации сервисы взаимодействуют через пользовательскую сеть app-network и могут обращаться друг к другу по имени сервиса (например, postgres).

Работа с данными, сетями и мониторингом Docker контейнеров

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

Docker volumes и bind mounts: стратегии хранения данных

Docker предоставляет два основных способа работы с данными: volumes (управляются Docker) и bind mounts (монтирование директорий хоста).

Named volumes (рекомендуются для данных БД):

# Создание тома
docker volume create db-data

# Использование в контейнере
docker run -d --name postgres -v db-data:/var/lib/postgresql/data postgres:16-alpine

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

Bind mounts (удобны для конфигураций и разработки):

# Монтирование директории хоста в контейнер
docker run -d --name nginx -v /host/nginx/config:/etc/nginx/conf.d nginx:1.26-alpine

Bind mounts напрямую связывают файловую систему хоста и контейнера, что удобно для редактирования конфигов без пересоздания контейнера.

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

# Создание резервной копии тома в файл
docker run --rm -v db-data:/volume-data -v /backup:/backup alpine tar czf /backup/db-backup.tar.gz /volume-data

Для интеграции с NAS-системами, такими как TrueNAS, можно использовать драйверы volume plugins (например, для NFS или iSCSI).

Сетевые настройки Docker: изоляция и взаимодействие контейнеров

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

Пользовательская bridge-сеть для изоляции группы сервисов:

# Создание сети
docker network create app-net

# Запуск контейнеров в этой сети
docker run -d --name app1 --network app-net nginx
docker run -d --name app2 --network app-net redis

Контейнеры в одной сети могут обращаться друг к другу по имени (DNS Docker) и по IP.

Публикация портов для внешнего доступа:

docker run -d --name web -p 8080:80 -p 8443:443 nginx

Это связывает порт 8080 хоста с портом 80 контейнера.

Режим сети host (высокая производительность, минус изоляция):

docker run -d --name web --network host nginx

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

Базовый мониторинг и логирование Docker контейнеров

Для оперативного контроля за инфраструктурой необходимы базовые инструменты мониторинга.

Командный мониторинг ресурсов:

# Просмотр статистики CPU, памяти, сети для всех контейнеров
docker stats

# Просмотр процессов внутри конкретного контейнера
docker top my-container

# Просмотр событий Docker (создание, запуск, остановка)
docker events

Настройка централизованного логирования: Для production-среды стандартный драйвер json-file не достаточен.

# Пример настройки драйвера syslog в daemon.json
{
  "log-driver": "syslog",
  "log-opts": {
    "syslog-address": "tcp://192.168.1.10:514",
    "tag": "docker"
  }
}

Для комплексного мониторинга рекомендуется интеграция с Prometheus через экспортеры, такие как cAdvisor для контейнеров и node-exporter для хоста. Подробные практики для production-среды описаны в статье «Docker в Production: Гайд по безопасному деплою, мониторингу и логированию».

Для управления кластерами контейнеров в более крупных инфраструктурах рассмотрите использование Docker Swarm – встроенного оркестратора, который предоставляет балансировку нагрузки, масштабирование и отказоустойчивость без сложностей Kubernetes. Практическое руководство по его развертыванию доступно в статье «Docker Swarm 2026: Практический гайд по оркестрации контейнеров для системных администраторов».

Поделиться:
Сохранить гайд? В закладки браузера