Сайт работает у разработчика, но после переноса на сервер не видит нужную библиотеку. Другой специалист подключается к проекту и тратит день на настройку окружения. Docker помогает описать и упаковать среду приложения, чтобы меньше зависеть от ручной установки компонентов. Однако база заказов, пароли и работоспособность формы не появляются в этой упаковке автоматически.
В Гуси-Лебеди предлагаем разбирать контейнеризацию через простой вопрос: сможет ли следующий специалист запустить, обновить и восстановить ваш проект по понятной инструкции? Ниже объясняем основные понятия и показываем, что нужно согласовать до переноса сайта в контейнеры.
Образ, контейнер и виртуальная машина: что именно запускается
Docker позволяет собирать приложения в образы и запускать их в контейнерах. Образ содержит файлы и настройки, необходимые для запуска. Контейнер представляет собой экземпляр, созданный на основе образа. Один образ можно использовать для нескольких контейнеров: например, отдельного тестового запуска и рабочего приложения.
Представьте интернет-магазин. Код приложения и его зависимости входят в образ, а запущенный контейнер обрабатывает запросы посетителей. Сведения о заказах и загруженные фотографии нужно хранить отдельно от заменяемого контейнера. Иначе удобное обновление приложения может обернуться потерей рабочих данных.
| Понятие | За что отвечает | Что проверить в проекте |
|---|---|---|
| Docker image, образ | Подготовленные файлы приложения и инструкция запуска | Какому выпуску кода соответствует образ |
| Docker container, контейнер | Запущенный или остановленный экземпляр на основе образа | Какие настройки и хранилища подключены именно к нему |
| Registry, реестр образов | Хранение и получение образов | Кто имеет доступ к загрузке и скачиванию |
| Volume, том | Хранение данных вне записываемого слоя контейнера | Что хранится в томе и как это восстанавливается |
Контейнер и виртуальная машина решают разные задачи. Виртуальная машина запускает гостевую операционную систему со своим ядром. Контейнеры используют ядро среды, в которой работает контейнерный движок. Поэтому контейнер нельзя считать отдельным сервером с независимой операционной системой. Подробное сравнение есть в документации Docker о контейнерах.
Docker Desktop и Docker Engine тоже не синонимы. Desktop является приложением для работы с контейнерами на компьютере и включает несколько инструментов. Engine обеспечивает сборку и выполнение контейнеров. Docker Hub является реестром образов. Когда подрядчик говорит «установим Docker», уточните, о каком компоненте и какой машине идёт речь.
Одинаковый образ не гарантирует одинаковую работу всего сайта. На результат влияют платформа, параметры запуска, внешняя база, сеть, права и доступность сторонних сервисов. Если приложение не отправляет письмо из-за неверного адреса почтового сервера, контейнеризация сама по себе это не исправит.
Вместо вопроса «Docker нужен любому сайту?» лучше выяснить, какие трудности он снимет у вас. Повторяемая подготовка среды, несколько связанных сервисов и передача проекта между специалистами являются понятными основаниями для обсуждения. Добавлять новый способ эксплуатации только ради названия технологии не стоит: его тоже придётся поддерживать.
Dockerfile и Docker Compose: сначала сборка, затем запуск проекта
Эти файлы часто упоминают рядом, но они отвечают на разные вопросы. Dockerfile описывает сборку образа: какую основу использовать, какие файлы добавить, какие действия выполнить. Compose описывает приложение при запуске: его сервисы, сети, подключённые хранилища и другие параметры. Один файл не заменяет другой.
Для условного магазина это можно представить так: Dockerfile готовит образ приложения, а файл compose.yaml описывает его запуск вместе с нужными сервисами. База может находиться в отдельном контейнере или за пределами этой схемы. Необязательно переносить в контейнеры всё одновременно.
В официальном описании Compose используются понятия services, networks и volumes. По ним удобно проверять, полон ли переданный комплект: описание только приложения ещё не объясняет, как оно соединяется с базой и где сохраняет файлы.
Ниже приведены команды для просмотра состояния уже настроенного проекта. Выполнять их нужно в каталоге с его Compose-файлом; Docker и доступ к движку должны быть настроены заранее.
docker compose ps
docker compose logs --tail 50Первая команда показывает состояние сервисов. Вторая выводит последние 50 строк журнала каждого контейнера. Команды приведены как пример, а не как результат проверки вашего сайта. Перед передачей журналов другому человеку проверьте, нет ли в них персональных данных, токенов и паролей.
Сам запуск обычно выполняют через docker compose up, но «контейнер запущен» и «сайт исправен» являются разными результатами. Приложение может работать как процесс и при этом не подключаться к базе или возвращать ошибку на странице оформления заказа. Нужна проверка пользовательского действия, а не только статуса контейнера.
В передаваемом проекте должны быть понятны три связи: версия исходного кода, собранный образ и реально развёрнутый выпуск. Историю кода ведут в системе контроля версий Git, а образ используется для запуска. Хранить исходники только внутри контейнера неудобно для дальнейшей разработки и проверки изменений.
При обсуждении разработки веб-сервиса полезно сразу добавить в требования способ сборки и передачи окружения. Тогда к моменту запуска будет ясно, какие файлы получает заказчик, где лежат образы и кто может выпустить обновление.
Контейнер можно заменить. Заказы и файлы должны остаться
Здесь проходит самая важная граница. Записываемый слой контейнера не предназначен для единственного хранения ценных данных. При удалении контейнера этот слой удаляется вместе с ним. Том имеет отдельный жизненный цикл и позволяет сохранить данные при замене контейнера. Эти особенности описаны в документации Docker о томах.
Для рабочих данных явно укажите именованный том или другое постоянное хранилище в конфигурации проекта. Анонимный том, созданный при запуске с --rm, может удалиться вместе с контейнером. Поэтому перед обновлением проверяйте тип хранилища и параметры запуска, а не только наличие тома.
Остановка контейнера не равна его удалению. А сохранение данных в томе не равно резервному копированию. Если ошибочно удалить записи в базе, том может сохранить именно это ошибочное состояние. Нужна отдельная копия и понятный способ восстановления.
Разберём учебный сценарий: приложение принимает заказ и сохраняет его в базе. После обновления приложения новый контейнер должен подключиться к нужной базе, а заказ должен остаться доступным. Фотографии товаров также должны находиться в предусмотренном постоянном хранилище. Это может быть том, подключённый каталог или внешнее хранилище: выбор зависит от устройства проекта.
Для каждой группы данных запишите место хранения и действие при обновлении. Для заказов это база и её резервная копия; для пользовательских загрузок это отдельное файловое хранилище и его копирование; для временного кэша может быть допустима повторная генерация. Не нужно одинаково обращаться со всеми файлами только потому, что они находятся на одном сервере.
Есть и менее очевидный вопрос: что произойдёт, если новый код изменит структуру базы? Возврат прежнего образа не обязательно вернёт прежнюю схему данных. До выпуска обсудите миграции и совместимость версий. Порядок отката нужно проверять вместе с базой и файлами, а не только с приложением.
Не начинайте освобождение места с случайной команды очистки из интернета. Сначала установите, какие контейнеры, образы и тома относятся к рабочему проекту, что можно удалить и где находится проверенная копия. Полезный критерий готовности: ответственный специалист может объяснить судьбу каждого постоянного хранилища после обновления.
Как принять запуск в Docker и передать сайт в поддержку
Просить только скриншот со списком работающих контейнеров недостаточно. Приёмка должна показывать, что приложение выполняет свою задачу и что его можно обслуживать после ухода разработчика.
Проведите короткую проверку на тестовом окружении с заранее согласованными данными:
- Откройте сайт и выполните основное действие: отправьте тестовую форму или оформите тестовый заказ.
- Проверьте результат там, где он должен появиться: в базе, панели управления или согласованной системе обработки обращений.
- Обновите приложение по подготовленной инструкции и повторите действие. Проверьте сохранность предыдущих тестовых данных и загрузок.
- Выполните согласованный сценарий восстановления из копии на тестовой среде. Сверьте восстановленные данные, а не только сообщение об успешном завершении команды.
- Зафиксируйте, кто принимает уведомления об ошибках и кто имеет доступ для восстановления.
Это пример программы приёмки. Для конкретного сайта её нужно дополнить интеграциями и действиями, важными для бизнеса. Проверка платежей, например, требует согласованного тестового сценария платёжной системы.
Передача должна содержать не только Dockerfile и Compose-файл. Нужны инструкция запуска, адрес реестра образов, соответствие выпусков версиям кода, описание хранения данных, порядок резервирования и восстановления. Отдельно определите способ передачи секретов и владельцев доступов. Пароль, вписанный в общедоступный репозиторий ради быстрого запуска, не становится защищённым благодаря контейнеру.
Если возникают ошибки, начните с конкретного симптома. Не открывается сайт: проверяйте путь запроса до приложения. Контейнер завершает работу: изучайте его состояние и журнал. Форма открывается, но обращение не поступает: проверяйте обработчик и интеграцию. Причину нельзя определить только по наличию слова Docker в архитектуре.
При выборе технического сопровождения сайта согласуйте ответственность за образы, сервер, базу, резервные копии и внешние сервисы. Такой список помогает избежать ситуации, когда приложение обслуживает одна команда, а восстановить его данные некому.
В Гуси-Лебеди считаем полезным результатом понятную эксплуатацию: известно, какой выпуск работает, где находятся данные и как проверить восстановление. Если после контейнеризации эти вопросы остались без ответа, работа по передаче проекта ещё не закончена.