Что такое Docker и контейнеры: устройство, запуск и обслуживание

Один пример: как работает сайт в контейнерах

Представим небольшой интернет-магазин. Покупатель видит сайт, но на сервере работают несколько программ. Каждую можно запустить в своём контейнере.

Польза: сайт, обработчик и СУБД можно обслуживать как отдельные части. При этом они продолжают зависеть от сервера, сети и хранилища.

Что именно находится внутри контейнера

Образ — подготовленный пакет для запуска. Контейнер — экземпляр, который из этого пакета создали. Подробнее об этих понятиях — в документации Docker.

Образ и контейнер: пакет и запущенная программа

Разработчик подготовил сайт и всё необходимое для его запуска. Этот пакет называется образом. Docker создаёт из него контейнер.

Образы можно хранить и получать из registry — хранилища пакетов, например Docker Hub. Dockerfile описывает, как собрать свой пакет. Эти слова понадобятся в практической части.

Как запрос из браузера попадает в контейнер

Ниже в примере браузер открывает адрес http://127.0.0.1:18080/. Числа 18080 и 80 обозначают разные точки входа.

Docker не рисует сайт сам: он передаёт запрос запущенной программе. Для публичного сайта отдельно настраивают домен, HTTPS и правила доступа.

Чем это отличается от виртуальной машины

Они могут использоваться вместе: сначала создают ВМ, а Docker запускают внутри неё. При потере общего хоста доступность всех его контейнеров тоже пострадает. Изоляция требует настройки; одна рамка на схеме не является гарантией безопасности.

В практической части рассматриваются Linux-контейнеры. На Windows и macOS для них обычно нужна дополнительная Linux-среда; образ также должен подходить архитектуре процессора.

Где применять, а где сначала проверить поддержку

Несколько экземпляров приложения могут обслуживать запросы за балансировщиком, если само приложение поддерживает такую работу. Сессии, загрузки пользователей и очередь должны храниться согласованно. Запуск трёх копий монолитной программы не делает её автоматически распределённой системой.

Для 1С и другого лицензируемого ПО сначала подтверждают поддерживаемую архитектуру, права и условия сопровождения. Контейнеризация не отменяет клиентские и серверные лицензии, привязки защиты и ограничения платформы. Для обычной компании ВМ с документированной установкой иногда оказывается проще и надёжнее.

Перед запуском: проверьте Docker и выбранный сервер

Установка Engine зависит от ОС. Используйте официальную инструкцию для своего дистрибутива. Дальше начинается практическая часть: предполагается готовый учебный Linux-хост, доступный Docker и Compose V2; это не инструкция запускать установочный скрипт на рабочем сервере.

docker version
docker info
docker context show
docker compose version

Зачем: проверить клиент, серверную часть, контекст и Compose. Результат: сведения о доступном daemon и версиях. Если видна только клиентская часть или ошибка соединения, сначала исправляют доступ. Контекст может указывать на удалённый сервер: подтвердите адрес до любых изменений.

Выберите свободные порты 18080 и 18081 и уникальные учебные имена. Команды ниже рассчитаны на POSIX shell. При Docker Desktop и удалённом контексте localhost в публикации порта относится к Docker-хосту, который может отличаться от компьютера с браузером.

Первый контейнер: веб-сервер на локальном порту

docker run --detach --name avg-docker-demo --publish 127.0.0.1:18080:80 --memory 256m --cpus 0.5 --log-driver local nginx:alpine

Команда создаёт новый контейнер из образа NGINX, при необходимости загружая его. --detach оставляет работу в фоне; --name задаёт имя. --memory и --cpus ограничивают учебный экземпляр, а --log-driver local выбирает журналирование с управляемой ротацией по настройкам драйвера.

127.0.0.1:18080:80 связывает TCP-порт 18080 на loopback хоста с портом 80 контейнера. В отличие от публикации без IP это не запрос на привязку ко всем адресам. Поведение публикации описано в документации Docker. После запуска в любом случае проверяют фактические адреса и доступность из нужного сегмента.

Ожидаемый результат успешного запуска — идентификатор контейнера. Это ещё не доказательство исправного сайта. Тег nginx:alpine выбран для учебного примера и может меняться; для рабочей поставки фиксируют проверенную версию и digest, а не считают этот тег неизменным.

docker ps --filter name=avg-docker-demo
curl -I http://127.0.0.1:18080/
docker logs --tail 50 avg-docker-demo

Проверьте состояние, HTTP-ответ и последние журналы. Ожидается работающий контейнер и успешный ответ веб-сервера. Если curl выполняется не на Docker-хосте, этот адрес может быть неверным для вашей топологии. Запись Up не подтверждает, что приложение завершило инициализацию или может обратиться к своей базе.

Где заказы: почему данные сохраняют отдельно

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

• Внутри удаляемого слоя: временные изменения экземпляра.
• Volume, или том: отдельное хранилище, которым управляет Docker.
• Bind mount: подключённая папка или файл сервера.

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

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

Пример создаёт отдельный учебный том и файл-маркер. Он не использует данные рабочей системы.

docker volume create avg-docker-demo-data
docker run --rm --mount type=volume,source=avg-docker-demo-data,target=/data busybox:stable sh -c 'printf "persistent-demo\n" > /data/probe.txt'
docker run --rm --mount type=volume,source=avg-docker-demo-data,target=/data,readonly busybox:stable cat /data/probe.txt

Первый временный контейнер записывает файл и удаляется благодаря --rm. Второй читает тот же том в режиме read-only. Ожидаемый вывод — persistent-demo. Сохранение обеспечил том, а не имя контейнера. Тег busybox также учебный и изменяемый.

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

Сеть: порт хоста, порт контейнера и имена сервисов

Порт 80 внутри двух разных контейнеров не конфликтует сам по себе. Конфликт возникает, если оба пытаются занять один и тот же адрес и порт хоста. Поэтому в примерах используются 18080 и 18081.

В Compose сервисы одной сети могут обращаться друг к другу по имени сервиса. Например, API использует имя db, а не случайный IP контейнера. При пересоздании IP может измениться. Публикация порта базы на хосте для связи внутри этой сети обычно не требуется.

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

Собственный образ: страница, Dockerfile и сборка

В новой учебной папке создайте каталог site и файл site/index.html:

<!doctype html>
<html lang="ru">
<meta>
<title>Docker demo</title>
<h1>Учебный сервис работает</h1>
<p>Версия приложения: 1.0</p>
</html>

Рядом создайте файл с точным именем Dockerfile без расширения:

FROM nginx:alpine
COPY site/index.html /usr/share/nginx/html/index.html

FROM выбирает базовый образ, COPY добавляет нашу страницу. В примере наследуется штатный запуск NGINX. Это минимальная демонстрация Dockerfile, а не универсальная production-сборка с политикой обновлений и прав.

В контекст сборки не включают секреты, базы и рабочие архивы. Для исключений используют .dockerignore; состав контекста проверяют до передачи в удалённую сборочную среду. Образ не должен содержать пароли, даже если файл с ними удалён последующим слоем.

Compose: описываем запуск в одном файле

В той же папке создайте compose.yaml. Отступы — пробелами:

name: avg-docker-article
services:
  web:
    build: .
    image: avg-web-demo:1.0
    ports:
      - "127.0.0.1:18081:80"
    restart: unless-stopped
    mem_limit: 256m
    cpus: 0.5
    logging:
      driver: local

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

Compose описывает сервисы, сети и данные приложения, как поясняет официальная модель. Файл можно хранить в системе версий, если он не содержит секретов. Реальный проект может включать несколько сервисов; зависимость от запуска контейнера не гарантирует готовность его API или базы.

docker compose config --quiet
docker compose up --detach --build
docker compose ps
curl http://127.0.0.1:18081/

Первая команда проверяет конфигурацию; при успехе обычно не выводит текста. Вторая собирает образ и запускает сервис. Третья показывает состояние. Четвёртая должна вернуть созданную страницу с версией 1.0. Если YAML корректен, но страница не открылась, проверяют отдельно сборку, процесс, сеть и HTTP-ответ.

Что смотреть при ошибке

docker compose logs --tail 100 web
docker stats --no-stream
docker inspect avg-docker-demo

Журналы помогают увидеть ошибку приложения, stats — текущие показатели контейнеров, inspect — настройки конкретного учебного экземпляра. В рабочем проекте полный inspect может раскрывать окружение и внутренние сведения; перед передачей вывода его проверяют.

Обновление и откат: пересоздание вместо ручной правки

1. Сохраните известную рабочую версию образа и конфигурации.
2. Соберите новую поставку под новым тегом и зафиксируйте digest.
3. Проверьте её на стенде с нужными зависимостями и данными.
4. Сделайте согласованную копию изменяемого состояния.
5. Внедрите новую версию, проверьте готовность и контрольные операции.
6. При проблеме верните совместимую версию и состояние по плану.

Правка файла внутри работающего контейнера создаёт недокументированное расхождение: следующий запуск из образа её не повторит. Изменения должны возвращаться в исходники и сборку. При этом смена тега в YAML не откатывает миграцию базы данных. Совместимость схемы и предыдущего приложения проверяют до обновления.

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

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

Для восстановления нужен комплект: образы или доступный registry, Compose и параметры запуска, секреты в защищённом хранилище, данные томов и внешних систем, сведения о сетях и правах. Экспорт контейнера не заменяет этот комплект.

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

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

Права, секреты и границы изоляции

Безопасность Engine включает настройки ядра, daemon и контейнеров. Доступ к Docker daemon в обычной rootful-схеме даёт широкие возможности управления хостом; его нельзя выдавать как безобидное право просмотра.

• Не включайте privileged и доступ к Docker socket без конкретного обоснования.
• Используйте минимально необходимые права и поддерживаемого пользователем приложения режима запуска.
• Не помещайте секреты в Dockerfile, публичный Compose или репозиторий.
• Ограничьте публикацию портов и доступ к административным интерфейсам.
• Обновляйте образы и хост; контролируйте происхождение образов и уязвимости.
• Настройте лимиты ресурсов, хранение журналов и оповещения.

Compose secrets может предоставлять приложению секрет файлом, но не превращает локальную папку в защищённый vault и не шифрует автоматически все резервные копии. Права администраторов и способ хранения исходных секретов требуют отдельного решения.

Compose, Kubernetes и обслуживание

Compose удобен для описания приложения и запуска на выбранном хосте. Он не становится многосерверным отказоустойчивым кластером от добавления нескольких сервисов в YAML. Несколько экземпляров и restart policy также не защищают от потери общего диска.

Если нужны распределённое размещение, управляемые обновления и восстановление экземпляров на других узлах, рассматривают оркестратор, например Kubernetes. Это отдельный уровень сложности: сеть, хранение, секреты, доступ, наблюдаемость и работа приложений без привязки к одному узлу. Сначала формулируют требования, затем выбирают инструмент.

Регламент сопровождения должен отвечать: кто собирает, кто утверждает обновления, где находятся данные, кто получает оповещение, как восстанавливается сервис и сколько времени это занимает. Docker облегчает повторяемый запуск; эти договорённости остаются задачей людей.

Как остановить и убрать только учебные ресурсы

docker stop avg-docker-demo
docker rm avg-docker-demo
docker compose down

Первые две команды останавливают и удаляют первый контейнер. Compose down выполняют из учебной папки: он убирает ресурсы соответствующего проекта. Файлы Dockerfile, site и compose.yaml остаются на диске. Убедитесь в выбранном контексте и проекте перед выполнением.

docker volume inspect avg-docker-demo-data
docker volume rm avg-docker-demo-data

Последнюю команду выполняют только после завершения опыта, убедившись, что это именно учебный том с ненужным маркером. Удаление тома уничтожает его данные. Здесь не нужны широкие команды очистки вроде system prune с удалением всех неиспользуемых томов.

Материалы для самостоятельной проверки

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

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

Вопросы и ответы