Когда я подключаюсь к проекту Drupal или переношу его на новый компьютер, я не пытаюсь восстановить окружение по памяти. Я воспроизвожу настройки проекта: версию PHP, базу данных, зафиксированные зависимости и загруженные файлы. DDEV делает этот процесс предсказуемее: окружение описывается в .ddev/config.yaml, а сервисы запускаются в контейнерах.
Здесь рассмотрены три задачи: создать новый проект, перенести существующий сайт на свой компьютер и подготовить полный пакет для другой среды. Важно помнить: код — лишь одна часть Drupal-сайта. База данных и публичные файлы переносятся отдельно, а секреты хранятся вне пакета.
Что собрать перед импортом
Для существующего сайта нужны версия кода, соответствующая дампу базы данных, файлы composer.json и composer.lock, SQL-экспорт, каталог публичных файлов и все необходимые приватные файлы. Также я записываю версии PHP и MariaDB или MySQL, а ещё требования к Redis, Solr и другим сервисам.
По возможности я использую обезличенные данные, а архивы храню вне публичного корня сайта. Перед запуском импортированного приложения проверяю локальные настройки и отключаю интеграции, которые могут отправлять письма или обращаться к рабочим сервисам.
Новый проект в DDEV
После установки DDEV и совместимого Docker-провайдера я создаю каталог проекта, настраиваю и запускаю контейнеры. Для нового проекта Drupal 11 стоит начать с официального quickstart DDEV:
mkdir -p ~/projects/drupal-local
cd ~/projects/drupal-local
ddev config --project-type=drupal11 --docroot=web
ddev start
ddev composer create-project drupal/recommended-project:^11 .
ddev composer require drush/drushЗатем я один раз устанавливаю новый сайт и проверяю локальный адрес. Этот шаг подходит для пустой базы данных. Если нужно сохранить контент существующего сайта, запускать site:install нельзя.
Перенос существующего сайта
Я клонирую репозиторий на нужном commit и сверяю настройки DDEV с исходной средой. Например, текущий проект у меня рассчитан на PHP 8.4 и MariaDB 11.8. Для копии другого проекта нужно сохранить его требования, а не переносить эти значения автоматически.
git clone https://example.com/team/drupal-project.git ~/projects/drupal-project
cd ~/projects/drupal-project
ddev start
ddev composer installcomposer install</code> устанавливает версии из lock-файла. Команда <code>composer update</code> разрешила бы другие версии и изменила условия импорта, поэтому я использую её только при запланированном обновлении зависимостей.</p>
<p>До импорта базы данных я проверяю <code>settings.php</code> и локальные переопределения. DDEV задаёт локальное подключение через <code>settings.ddev.php</code>; рабочие учётные данные не должны попадать в локальные файлы и репозиторий. Для дополнительных сервисов настраиваю локальные аналоги или предусмотренный проектом fallback.</p>
<p>База данных и файлы импортируются раздельно:</p>
<p><code>ddev import-db --file=/path/to/database.sql.gz
ddev import-files --source=/path/to/files.tar.gz
ddev drush cr
ddev drush statusВ корне архива должны находиться файлы из публичного каталога files, без дополнительной вложенной папки с тем же названием. Импорт заменяет содержимое целевого каталога и не объединяет наборы файлов. Приватные файлы и внешнее объектное хранилище требуют отдельного переноса.
Проверяйте не только главную страницу
После очистки и пересборки кэша я проверяю вход, несколько материалов, изображения, вложения, формы, поиск и специфические функции проекта. Просматриваю отчёт о состоянии системы и журналы, затем создаю или редактирую тестовый материал. Работающая главная страница ещё не гарантирует, что перенесены файлы или работают cron и интеграции.
Для полного экспорта нужен не только SQL
Чтобы копию можно было восстановить, я готовлю отдельно базу данных, загруженные файлы и код. Экспорт конфигурации Drupal описывает структуру и настройки, но не содержит материалы и пользователей. Версия кода должна соответствовать commit, с которым сделаны остальные экспорты.
mkdir -p ../handoff
ddev export-db --file=../handoff/database.sql.gz
tar -czf ../handoff/files.tar.gz -C web/sites/default/files .
ddev drush config:export -y
git archive --format=tar.gz --output=../handoff/code.tar.gz HEADПеред передачей пакета я проверяю изменения конфигурации и наличие необходимых файлов в Git-архиве. git archive не включает незакоммиченные изменения, игнорируемые файлы и подмодули. В README указываю commit, версии PHP и базы данных, а также дополнительные сервисы. Секреты передаются отдельно через утверждённый командой менеджер секретов.
Восстановление на другом компьютере
Надёжнее всего проверить передачу, восстановив её в новом каталоге. Я распаковываю код, задаю проекту другое имя DDEV, устанавливаю зависимости из lock-файла, импортирую базу и файлы, а затем пересобираю кэш. После этого повторяю функциональные проверки. Так отсутствующий модуль, приватный файл или сервисная настройка обнаружатся до того, как проект получит коллега.
Экспорт — это снимок сайта на определённый момент, а не способ развернуть его в production. Импорт базы поверх работающего сайта может затереть новые материалы и действия пользователей. Для публикации я использую процесс релиза проекта: переношу проверенный код и конфигурацию, сохраняя текущий контент.
Команды, которые полезно держать под рукой
ddev startзапускает проект.ddev describeпоказывает URL и сервисы.ddev drush statusпроверяет установку.ddev drush crпересобирает кэш Drupal.ddev export-dbиddev import-dbпереносят базу.ddev import-filesимпортирует публичные файлы.
Официальные материалы DDEV Drupal quickstart и руководство DDEV по импорту базы данных помогают уточнить параметры команд, которые могут меняться между выпусками.
Оригинальная статья Павла Кулакова. Написана самостоятельно на основе практической работы с Drupal и DDEV; ссылки на официальную документацию приведены для уточнения команд.