Использование Docker для запуска приложений в контейнерах (основы)

В мире IT, где каждый год приносит с собой лавину новых технологий, есть вещи, которые не просто остаются на плаву, но и становятся фундаментом для всего остального. Для меня, старого сисадмина с двадцатилетним стажем, таким столпом стал Docker. Помню, как еще лет десять назад мы бились головой о стену, пытаясь воспроизвести рабочее окружение на разных машинах. Разработчик клянется, что у него «все работает», а у меня на тестовом сервере — крах за крахом. Сейчас же, в 2025 году, когда импортозамещение стало не просто лозунгом, а суровой реальностью, а доступ к некоторым привычным ресурсам то открывается, то закрывается, Docker стал настоящим спасением.

Что такое docker и почему он важен?

Представьте, что ваше приложение — это нежная рассада. Раньше ее нужно было высаживать прямо в огород, подбирать почву, следить за погодой, отгонять вредителей. А Docker — это как индивидуальный горшок со всем необходимым: своей землей, водой, даже микроклиматом. Вы просто берете этот горшок и ставите куда угодно — на подоконник, на балкон, в теплицу. И рассада растет, потому что ей комфортно, она не зависит от внешних условий. Точно так же и с приложениями: Docker упаковывает приложение со всеми его зависимостями (библиотеками, настройками, даже операционной системой) в изолированный «контейнер». Этот контейнер можно запустить где угодно — на вашей машине с Windows, на Linux-сервере в дата-центре, да хоть на Raspberry Pi (хотя тут есть свои нюансы, об этом ниже).

Главная магия Docker в том, что он позволяет забыть про извечный спор: «У меня на машине работает!». Если приложение работает в контейнере на машине разработчика, оно будет работать и на продакшене. Зуб даю, это сэкономило мне сотни часов нервов и бессонных ночей.

Первые шаги: не обжечься на горячем

Начать с Docker кажется просто: скачал, установил, запустил docker run hello-world. Но дьявол, как всегда, кроется в деталях. На Windows, например, без WSL2 (Windows Subsystem for Linux 2) жизнь с Docker Desktop будет неполной, а иногда и вовсе невыносимой. Я видел, как люди пытались запускать серьезные проекты без WSL2, и это было похоже на попытку проехать на запорожце по бездорожью: вроде едет, но очень медленно и с постоянными поломками. Убедитесь, что WSL2 настроен и работает корректно, иначе будете ловить необъяснимые тормоза и ошибки монтирования.

Для создания своего образа вам понадобится Dockerfile. Это как рецепт приготовления вашего горшка с рассадой. Вот базовые инструкции, которые вы будете использовать постоянно:

• FROM: откуда берем основу (например, ubuntu:22.04 или python:3.9-slim). Лайфхак: всегда используйте конкретные версии, а не latest. Завтра latest обновится, и ваш контейнер может перестать работать. Я сам на этом обжегся, когда один из базовых образов обновился и сломал сборку в пятницу вечером.
• RUN: выполнение команд внутри образа (установка зависимостей, компиляция).
• COPY: копирование файлов с вашей машины в образ.
• EXPOSE: объявление порта, который будет слушать приложение.
• CMD или ENTRYPOINT: команда, которая будет запускаться при старте контейнера.

Пример простейшего Dockerfile для Python-приложения:

FROM python:3.9-slim-buster
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["python", "app.py"]

Сборка образа: docker build -t my-python-app .

Запуск контейнера: docker run -p 8000:8000 my-python-app

Подводные камни и лайфхаки из траншей

Хранение данных: не наступите на грабли

Самая частая ошибка новичков, да и не только, — это игнорирование персистентного хранения данных. Контейнер по своей сути эфемерный: он может быть удален и создан заново в любой момент, и все, что было внутри, исчезнет. Если вы запускаете базу данных или приложение, которое генерирует пользовательские данные, и не монтируете внешние тома, то при первом же перезапуске или пересоздании контейнера вы потеряете все! Помню, как однажды молодой админ на тестовом сервере запустил базу данных без тома, а потом жаловался, что «данные исчезли». Так они и должны были исчезнуть, милок! Это не магия, это основы.

Используйте опцию -v при запуске контейнера или Docker Volumes. Например, для базы данных PostgreSQL:

docker run -d 
  --name some-postgres 
  -e POSTGRES_PASSWORD=mysecretpassword 
  -v pgdata:/var/lib/postgresql/data 
  postgres

Здесь pgdata — это именованный том, который Docker сам создаст и будет управлять его жизненным циклом. Это ваш якорь для данных. Лайфхак: для продакшена всегда используйте именованные тома или монтируйте директории с хоста, но с умом, чтобы не создать дыру в безопасности.

Обеспечение связи: сети и docker compose

Когда у вас не одно приложение, а целая экосистема (например, веб-сервер, база данных, кэш-сервер), связывать их через docker run становится адом. Тут на сцену выходит Docker Compose. На моем веку, Docker Compose — это как швейцарский нож для админа: вроде бы простая штука, но без нее руки связаны. Он позволяет описать всю вашу архитектуру в одном YAML-файле (docker-compose.yml).

Пример:

version: '3.8'
services:
  web:
    build: .
    ports:
      - "80:8000"
    volumes:
      - .:/app
    depends_on:
      - db
  db:
    image: postgres:14
    environment:
      POSTGRES_DB: mydatabase
      POSTGRES_USER: myuser
      POSTGRES_PASSWORD: mypassword
    volumes:
      - pgdata:/var/lib/postgresql/data
volumes:
  pgdata:

Запуск всего этого великолепия: docker-compose up -d. И все, магия! Контейнеры сами видят друг друга по именам сервисов (db для web), Docker сам создает для них внутреннюю сеть. Это колоссально упрощает развертывание сложных систем.

Ограничения ресурсов: не дайте соседу съесть все

Если вы запускаете несколько контейнеров на одной машине, особенно на физическом сервере без полноценной оркестрации типа Kubernetes, очень важно ограничивать ресурсы. Иначе один жадный контейнер может сожрать всю память или CPU, и остальные приложения начнут тормозить или падать. Это как в коммуналке: если один сосед врубит свою стиральную машину и духовой шкаф одновременно, пробки выбьет у всех. Используйте опции --memory, --cpus при docker run или в docker-compose.yml:

services:
  web:
    # ...
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: '0.5' # 50% одного ядра
        reservations:
          memory: 256M

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

Docker в российских реалиях 2025 года: с чем столкнетесь

Вот где начинается самое интересное, то, чего не найдешь в общих гайдах по Docker. В 2025 году мы живем в условиях, когда IT-ландшафт России претерпел значительные изменения. Это касается и Docker.

Импортозамещение и отечественные ос

Если вы работаете с российскими операционными системами, такими как Astra Linux или Red OS, будьте готовы к нюансам. Официальные инструкции по установке Docker на них есть, но иногда они отстают от актуальных версий или имеют свои особенности. Например, на Astra Linux с ее мандатным доступом и СЗИ (средствами защиты информации) иногда приходится плясать с бубном, чтобы Docker Engine корректно работал с файловыми системами и сетевыми интерфейсами. В моем опыте, модель безопасности «Орел» в Astra Linux имеет особенность: если вы не настроите SELinux/AppArmor или аналогичные механизмы для Docker-демона, то контейнеры могут получить неожиданные ограничения или, наоборот, слишком много прав. Всегда проверяйте официальную документацию для вашей версии ОС и Docker, а не полагайтесь только на Stack Overflow.

Доступ к публичным репозиториям: docker hub и его альтернативы

Помню, как в 2022-м мы судорожно перестраивали пайплайны, когда стало понятно, что некоторые публичные репозитории могут стать недоступны или работать с перебоями. Docker Hub, хоть и остается основным источником публичных образов, иногда может быть капризен. В России сейчас активно развиваются отечественные реестры контейнеров. Например, GitLab, Gitea, Harbor могут быть развернуты локально и служить вашим приватным репозиторием. Это не просто удобно, это вопрос стабильности и безопасности. Лайфхак: используйте локальный кэширующий прокси для Docker Hub или зеркалируйте критически важные базовые образы на свой приватный реестр. Это спасет вас от «сюрпризов» в самый неподходящий момент, когда очередной docker pull внезапно зависнет.

Интеграция с «нашим» софтом

Отдельная песня — это попытки контейнеризировать или подружить Docker-приложения с российским enterprise-софтом. Если вам надо подружить 1С с чем-то в контейнере, готовьтесь к танцам с бубном вокруг ODBC-драйверов, файловых шаров CIFS/NFS и, возможно, даже Wine для запуска некоторых утилит. Некоторые специализированные системы (например, для промышленной автоматизации или госсектора) просто не были спроектированы для работы в