Установка и настройка Docker4Drupal на Ubuntu
Блог

Установка и настройка Docker4Drupal на Ubuntu

Инструкция по установке, настройке и тюнинге Docker4Drupal от и до.
68 комментариев
Опубликовано 15.04.2018
17 мин.
Docker4Drupal — локальная среда для разработки на Drupal 8 (для Ubuntu)
image/svg+xml

В последние пол года, а может и больше, я перешел на Docker4Drupal с ранее описанного Drupal VM. Всё это время я набивал шишки, эксперементировал, и вот делюсь тем как всё "варить".

Сразу отвечу почему я перешел на вариант с Docker против Vagrant. Ответ один и очень простой — производительность. Докер работает под линуксом очень шустро (читай нативно), шустрее чем на Mac и Windows, точка. На виндоусах он разворачивает полноценную виртуальную машину для своей работы, что по сути, аналог Vagrant и какая между ними разница, не знаю, на Mac, как мне обьяснили, ситуация получше, но все же он доустанавливает какие-то либы и, вроде, часть ядра линукса, для работы и все же, работает медленнее чем под линуксом. На линуксе же, он не ставит вообще ничего, кроме того что требуется контейнеру для его работы. Он просто берет использует напрямую с хоста. В итоге, когда запущенный контейнер проекта от докера простаивает, он не ест практически никаких ресурсов вообще. Более того, докер может динамически забирать себе ресурсы для своей работы прямо с хоста, тогда как вагрант, требует задавать ограничения изначально, и резервирует ресурсы под виртуалку даже если она простаивает. Ну и сам докер, запускается, разворачивается, сворачивается нереально шустро. Когда Drupal VM у меня может стартовать под минуту с уже полноценным проектом, docker стартует с аналогичным проектом за секунд 5-10.

Также у вас может сложиться вопрос, а почему именно Docker4Drupal, ведь есть ещё куча аналогичных проектов заточенных под Drupal, но я пробовал лишь два:

  • Dockerized Drupal: Проект походу мертв, даже сайт не открывается. Но использовал я его давненько, и все было круто, но лагал он по сравнению с Drupal VM просто нереально. Как оказалось, внутри запускается 11 контейнеров под проект, и в каждом контейнере запускается Vagrant =_=. Думаю дальше продолжать не стоит и разьяснять, почему Drupal VM с одним вагрантом работал быстрее чем 11 завернутых в докер контейнеры :)
  • Docker4Drupal: Этот вариант использую на данный момент, так как с ним, у меня практически нет проблем (парочка всплыла когда у них появилась 5.x ветка и происходит какая-то путанница с правами на проектах, но я, вроде, их поборол уже, у вас же их не должно быть вообще, так как мы начнем сразу с 5.х). Работает шустро, гнется простой правкой конфигов. Легко развернуть и зачистить всё за ним. Всё предельно просто и понятно, работает очень быстро, никаких вирутуалок внутри не заметил.

И ведь никто не мешает вам собрать собственную сборочку сервера в докере под друпал и поделиться! Например, такой проектик есть у Chi — Drupal Lemp и у politsin — drupal-docker.

Установка Docker на Ubuntu

При установке, обратите внимание чтобы версия была Community Edition (CE).

Обновляем информацию о пакетах.

$ sudo apt update

Устанавливаем доп пакеты, которые необходимы для установки докера и поддержки загрузки через https.

$ sudo apt install apt-transport-https ca-certificates curl software-properties-common

Добавляем ключ репозитория Docker

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

Устанавливаем репозиторий Docker

$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"

Обновляем индекс и устанавливаем Docker CE

$ sudo apt update && sudo apt install docker-ce

Проверяем установку Docker

$ sudo docker run hello-world

Если все сделали корректно, то он должен скачать образ и вывести приветственное сообщение Hello from Docker! и немного информации. Если появились ошибки или что-то пошло не так, пройдитесь по пунктам заново.

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

Для начала создаем группу docker

$ sudo groupadd docker

Вероятнее всего, он напишет что такая группа уже существует, ничего страшного в этом нет, просто идем дальше.

Добавляем своего текущего пользователя в данную группу

$ sudo usermod -aG docker $USER

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

Теперь вновь можно проверить, работает ли докер без sudo:

$ docker run hello-world

Он должен вернуть все то же сообщение. На этом установка docker завершена.

Дополнительные действия после установки

Автозапуск docker

По-умолчанию, докер сам должен настроить автозапуск своего демона. Но если по каким-то причинам этого не произошло, или наоборот, вы желаете его отключить, то вот пара команд:

# Добавить автозапуск
$ sudo systemctl enable docker
# Отключить автозапуск
$ sudo systemctl disable docker

Хранение данных в альтернативном месте

Данный раздел рекомендую прочитать всем. Может вам и не нужно будет это делать, но знать об этом точно стоит.

По умолчанию Docker хранит все свои образы и данные для будущих контейнеров в /var/lib/docker, и это может вызвать серьезные проблемы со временем. Причина проблем кроется в том, что некоторые люди, например я, разбивают диск для Linux руками по разным на то причинам. Я, например, при установке линукса, отдаю 30-45 гб. для ядра /, а все остальное отдаю /home (это позволяет переустанавливать линукс или менять дистрибутив за считанные минуты, не теряя никакие данные вообще). Таким образом, директория /var попадает под ограничение 30-45 гб. А контейнера могут весить со временем очень много, и не стоит забывать что система также занимает место, как и другие програмки. У кого-то это может быть вообще два разных диска, где ядро на SSD, а остальное на HDD и место также ограниченно.

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

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

Для того чтобы изменить местоположение файлов для докера, нам необходимо поменять значение по умолчанию для демона. Мы можем переопределять значения для демона докера при помощи файла daemon.json, который нужно создать в папке /etc/docker. В данном файлике в формате JSON достаточно задать переменную graph, где значением будет путь до места хранения файлов докера.

Давайте это сделаем:

# Создаем файл
sudo touch /etc/docker/daemon.json
# Открываем его на правку
sudo nano /etc/docker/daemon.json

Добавляем значение

{
  "graph": "/home/USERNAME/.docker"
}

Сохраняем, закрываем.

Путь можете указать какой вам удобно. Я указываю домашнюю директорию своего юзера и скрытую папку .docker. Если папки нет, докер создаст её сам и все необходимые вложенные.

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

$ sudo service docker restart

И для того чтобы убедиться что всё ок, запустите тест hello world заново. Если вы не переносили уже имеющиеся данные из /var/lib/docker, то он заново скачает образ и выведет сообщение.

Установка Docker Compose

Docker Compose — это небольшая обертка для докера, которая позволяет описывать контейнеры в конфигурационном файле docker-compose.yml и управлять ими одновременно через данную утилиту. Это необходимо установить, потому что это во-первых, удобно, а во-вторых, требуется для Docker4Drupal.

Установка Docker Compose

# Качаем
$ sudo curl -L https://github.com/docker/compose/releases/download/1.21.0/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose
# Делаем метку выполняемого файла
$ sudo chmod +x /usr/local/bin/docker-compose
# Проверяем
$ docker-compose --version

Если вернул версию, всё готово.

Установка Docker4Drupal

Docker4Drupal — это по-сути, парочка конфиг файлов с настройками для Docker Compose, которые, под капотом, дергают определенные контейнера и связывают их между собой. Поэтому установка проста настолько, насколько это только реально.

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

Для проектов у меня в домашней директории есть папка Projects, внутри которой ещё несколько: github (для всяких контриб модулей и прочих разработок), local (для локальной разработки), remote (подключенные внешние проекты по (S)FTP). Как не сложно догадаться, разработка ведется в папке local, внутри которой, у меня есть папка для каждого проекта. В итоге я имею примерно такой путь ~/Projects/local/project-name. И вот внутрь папки проекта я кидаю конфиги Docker4Drupal.

Можете использовать всё по своему усмотрению, откуда вызывать - нет никакой разницы, я же приведу пример, создав папку для тестового проекта: ~/Projects/local/example.

После того как создали папку для своего проекта, необходимо скачать Docker4Drupal. Для этого переходим в их репозиторий, а затем, на вкладку releases и качаем самый последний релиз. На момент написания статьи, это 5.0.4, внутри которого есть архив docker4drupal.tar.gz, вот его то нам нужно скачать.

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

И на этом "установка" завершена.

Настройка Docker4Drupal

Из коробки всё само заведется и заработает, но я правлю конфиги под себя и покажу как это делаю, и какие полезные изменения можно внести.

Для базовой настройки нам интересны всего два файла .env (скрытый файл, в Ubuntu чтобы показать скрытые файлы CTRL + H, в KDE Dolphin F8) и docker-compose.yml.

Начем с .env, в нем настраиваются все базовые настройки для контейнеров. Их название, версии и доступы.

Первым делом стоит поменять название проекта под своё, чтобы контейнера не перепутались. Я указываю название такое же, как и папки проекта. Я меняю PROJECT_NAME, в нашем случае на example. Данная переменная может содержать только латиницу, цифры и знак подчеркивания. Так что тире заменяйте на подчеркивание или вообще пишите слитно. Далее я меняю PROJECT_BASE_URL, это адрес, по которому будет открываться сайт, а также базовый адрес для остальных поддоменов типа phpmyadmin и прочего. Я аналогично, указываю в нашем случае example.localhost чтобы было проще вводить. Больше я ничего не меняю.

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

Например, на момент написания статьи, раздел настройки PHP имеет следующий вид:

### --- PHP ----

PHP_TAG=7.1-dev-4.2.5
#PHP_TAG=7.0-dev-4.2.5
#PHP_TAG=5.6-dev-4.2.5
#PHP_TAG=5.3-dev-4.2.5
#PHP_TAG=7.1-dev-macos-4.2.5
#PHP_TAG=7.0-dev-macos-4.2.5
#PHP_TAG=5.6-dev-macos-4.2.5
#PHP_TAG=5.3-dev-macos-4.2.5

Т.е. по умолчанию, версия php будет 7.1. Если вы хотите 5.6, то файл будет выглядить следующим образом:

### --- PHP ----

#PHP_TAG=7.1-dev-4.2.5
#PHP_TAG=7.0-dev-4.2.5
PHP_TAG=5.6-dev-4.2.5
#PHP_TAG=5.3-dev-4.2.5
#PHP_TAG=7.1-dev-macos-4.2.5
#PHP_TAG=7.0-dev-macos-4.2.5
#PHP_TAG=5.6-dev-macos-4.2.5
#PHP_TAG=5.3-dev-macos-4.2.5

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

Теперь перейдем к настройке docker-compose.yml.

В первую очередь, в данном файле нас интересует конфиг traefik в самом низу, там где раздел ports и установлено '8000:80' я меняю на '80:80'. Если этого не поменять, то сайт будет открываться по адресу example.com:8000, если поменять, то просто по example.com. Согласитесь, удобнее.

Затем, я включаю Adminer, для этого надо найти его раздел в файле и убрать от всех его строк комментарии #. Получится так:

  adminer:
    container_name: "${PROJECT_NAME}_adminer"
    image: wodby/adminer:$ADMINER_TAG
    environment:
      ADMINER_SALT: adminer-salt
    labels:
      - 'traefik.backend=adminer'
      - 'traefik.port=9000'
      - 'traefik.frontend.rule=Host:adminer.${PROJECT_BASE_URL}'

Если вы предпочитаете PhpMyAdmin или хотите оба, то расскоменнтируйте pma раздел аналогичным обарзом. Тут же вы можете заметить в последней строке где задается по какому хосту будет открываться adminer. В нашем случае это превратиться в adminer.example.localhost (если вы поменяли порт 8000 на 80, если нет, то adminer.example.localhost:8000).

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

Также в docker-compose.yml есть две очень важные настройки. Первая находится в разделе php.volumes. Там, вы можете заметить, значение по умолчанию ./:/var/www/html. Это маппинг откуда:куда. Если опираться на стандартное значение, то его следует понимать следующим образом. Файлы из текущей (./) директории, нужно переносить в директорию /var/www/html контейнера php. Это настройка синхронизации исходного кода с контейнером. Папка "откуда", указывается относительно текущего местоположения docker-compose.yml.

Вторая аналогичная настройка есть в nginx, её тоже не забудьте поменять, если изменили в php. В nginx также находится ещё одна очень важная настройка nginx.environment.NGINX_SERVER_ROOT. Она отвечает за то, где в контейнере php находится index.php файл сайта. По умолчанию она имеет значение /var/www/html/web. Во-первых, если вы меняли место назначения файлов, это также должно быть изменено. Во-вторых, оно настроено под Drupal 8 drupal-project композер установку. Если у вас Drupal 7 или стандартная установка Drupal 8, то значение нужно поменять на /var/www/html.

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

Настройка алиасов

Docker4Drupal в PHP контейнере из коробки поставит вам composer, drupal console и drush launcher. Для их вызова, лучше всего, сделать алиасы.

Для этого надо добавить три алиаса, называйте их как хотите, я называл их обычными именами. Если вы не меняли шел в системе, то следующие правки вносите в ~/.bash_profile (если нету, то создайте touch ~/.bash_profile), если у вас Zsh, то следующие строки вносите в ~/.zshrc.

alias drush="docker-compose exec php drush"
alias drupal="docker-compose exec php drupal"
alias composer="docker-compose exec php composer"

Можно их добавить снизу файла, сохранить, закрыть и прописать source ~/.bash_profile или же source ~/.zshrc. В зависимости куда внесли алиасы.

Теперь, набирая в консоли drush, он будет вызывать команду docker-compose exec в контейнер php где он вызовет drush, а он, в свою очередь, уже вызовет драш. Аналогично и с остальными.

Данные команды будут работать в корне проекта, а также во всех вложенных его папках, за пределами проекта будет выдавать ошибку что docker-compose.yml не найден. Поэтому, перед тем как выполнять эти команды, зайдите в терминале в папку с проектом cd ~/Projects/local/example и вызывайте drush status или что вам нужно.

Запуск, установка, отключение, удаление

Если все установили и настроили как следует, то можно проверять.

Запуск сервера

Для того чтобы запустить сервер, заходите при помощи терминала в директорию с проектом cd ~/Projects/local/example и вызываете команду запуска docker-compose up -d (параметр -d отключит вывод сообщений после запуска и отдаст контроль над терминалом). У вас всё скачается, настроится и запустится. И по адресу example.localhost должна открываться страница и писать "File not found", потому что index.php по пути /var/www/html/web не обнаружен.

Если у вас пишет что соединение не удалось установить, вероятнее всего у вас Firefox или же ещё какие-то особенности. Для этого просто достаточно добавить в /etc/hosts записи для всех нужных вам доменов 127.0.0.1 example.localhost и, например, если включили adminer 127.0.0.1 adminer.localhost. Адреса начнут работать.

Установка Drupal

Для примера мы поставим Drupal 8 drupal-project. Так как стандартные настройки полностью под него подходят, и делается это крайне быстро и легко. Да и вообще drupal-project крутейшая штука, я, если интересно, могу о нем расписать, хотя там все предельно понятно и просто.

Для этого достаточно выполнить пару команд в терминале

# Переходим в папку проекта, если ещё не там или вышли
$ cd ~/Projects/local/example
# Клонируем проект
$ git clone https://github.com/drupal-composer/drupal-project.git
# Переносим клонируемые файлы в нашу основную директорию
$ cp -R drupal-project/* .
# Удаляем файлы которые скопировали из старой папки
$ rm -rf drupal-project/

У вас должно получиться примерно следующее.

Так как это drupal-project и он не содержит в себе ядра друпала из коробки, мы устанавливаем его со всеми зависимостями.

Для того чтобы это сделать просто пишем composer install и ждём окончания. Не будет лишним сразу помочь создать ему папку config/sync, на которую он может ругаться в начале установки, для этого просто напишите mkdir -p config/sync.

После окончания установки композера всё готово. Установщик Drupal будет доступен по адресу example.localhost.

Важно!. В процессе установки, или, если вы разворачиваете готовый проект, в качестве хоста для базы данных нужно указывать mariadb, вместо localhost.

Остановка сервера

Для того чтобы остановить сервер просто пишем docker-compose stop. Он выключит все контейнеры и всё, сервер больше не работает. Если захотите опять запустить его, просто пишите docker-compose up -d и сайт снова заработает.

Удаление данных

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

Для того чтобы удалить все данные по текущему проекту в докере, достаточно остановить сервер и написать docker-compose rm, он спросит подтверждение, убедитесь что удаляются файлы нужного проекта, это будет видно по названиям в подтверждении, если всё ок, соглашайтесь, они удалятся. После чего, уже можно удалять папку проекта, если она больше не нужна и у вас не останется никаких следов текущего проекта.

Также есть ещё одна команда, docker-compose halt. Её можно вызывать когда сервер запущен, и вы решили его удалить. Он выполнит команду docker-compose stop и docker-compose rm за вас.

Будьте очень аккуратны при удалении, данные будет не восстановить.

Дополнительные конфигурации и возможности

Данные конфигурации необязательны и только чтобы вы знали как, где и если потребуется, чтобы быстро сориентироваться.

Xdebug

В 8-ке xdebug порой необходим как воздух, с ним очень легко отследить как выполняется определенная часть кода и найти ошибку. К нашему счастью, с Docker4Drupal это делается очень просто.

Первым делом, рекомендую поставить расширение для браузера Xdebug helper Chrome \ Firefox. Он позволит простым нажатием в браузрной строке включать режим отладки.

Для того чтобы включить Xdebug в Docker4Drupal, заходим в файл docker-compose.yml и находим раздел php. Там будут закомментированы две переменные PHP_XDEBUG и PHP_XDEBUG_DEFAULT_ENABLE. Нам необходимо их раскомментировать.

  php:
    image: wodby/drupal-php:$PHP_TAG
    container_name: "${PROJECT_NAME}_php"
    environment:
      PHP_SENDMAIL_PATH: /usr/sbin/sendmail -t -i -S mailhog:1025
      DB_HOST: $DB_HOST
      DB_USER: $DB_USER
      DB_PASSWORD: $DB_PASSWORD
      DB_NAME: $DB_NAME
      DB_DRIVER: $DB_DRIVER
## Read instructions at https://wodby.com/stacks/drupal/docs/local/xdebug/
      PHP_XDEBUG: 1
      PHP_XDEBUG_DEFAULT_ENABLE: 1
#      PHP_XDEBUG_REMOTE_CONNECT_BACK: 0
#      PHP_IDE_CONFIG: serverName=my-ide
#      PHP_XDEBUG_REMOTE_HOST: 172.17.0.1 # Linux
#      PHP_XDEBUG_REMOTE_HOST: 10.254.254.254 # macOS
#      PHP_XDEBUG_REMOTE_HOST: 10.0.75.1 # Windows
    volumes:
      - ./:/var/www/html
## For macOS users (https://wodby.com/stacks/drupal/docs/local/docker-for-mac/)
#      - ./:/var/www/html:cached # User-guided caching
#      - docker-sync:/var/www/html # Docker-sync
## For Xdebug profiler files
#      - files:/mnt/files

После чего перезапускаем контейнера, если они запущены и запускаем заново docker-compose stop && docker-compose up -d.

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

Xdebug очень сильно снижает производительность даже в режиме ожидания. Чем крупнее проект, тем сильнее будет ощущаться его присутствие. Так что после успешного дебага под свои нужды, я рекомендую комментировать конфиги которые его включают и перезапускать контейнера. Включайте только когда действительно нужно.

Blackfire

Blackfire — это сервис профилирования проекта от создателей Symfony. Для локальных проектов он бесплатный. Его очень круто использовать, когда на проекте есть какие-то тормоза, которых раньше не было. Он помогает вам найти узкие места в проекте, а затем провести ещё одну проверку, и сравнить насколько изменился результат и были ли внесенные изменения действенные.

Для его использования, нам также потребуется браузерное расширение Blackfire Companion Chrome \ Firefox, а также, вы должны зарегистрировать в данном сервисе.

После регистрации в сервисе вам нужно нажать на свою аватарку, зайти в Account и получить Server ID и Server Token.

После чего заходим в docker-compose.yml, расскомментируем соответствующий раздел и укажем BLACKFIRE_SERVER_ID и BLACKFIRE_SERVER_TOKEN в соответствии с тем что вам выдали в профиле.

  blackfire:
    image: blackfire/blackfire
    container_name: "${PROJECT_NAME}_blackfire"
    environment:
      BLACKFIRE_SERVER_ID: XXXXX
      BLACKFIRE_SERVER_TOKEN: YYYYY

Также в раздел php нужно добавить переменную PHP_BLACKFIRE со значением 1. Видимо в новой версии про неё забыли, но без неё не заведется.

  php:
    image: wodby/drupal-php:$PHP_TAG
    container_name: "${PROJECT_NAME}_php"
    environment:
      PHP_SENDMAIL_PATH: /usr/sbin/sendmail -t -i -S mailhog:1025
      DB_HOST: $DB_HOST
      DB_USER: $DB_USER
      DB_PASSWORD: $DB_PASSWORD
      DB_NAME: $DB_NAME
      DB_DRIVER: $DB_DRIVER
## Read instructions at https://wodby.com/stacks/drupal/docs/local/xdebug/
#      PHP_XDEBUG: 1
#      PHP_XDEBUG_DEFAULT_ENABLE: 1
#      PHP_XDEBUG_REMOTE_CONNECT_BACK: 0
#      PHP_IDE_CONFIG: serverName=my-ide
#      PHP_XDEBUG_REMOTE_HOST: 172.17.0.1 # Linux
#      PHP_XDEBUG_REMOTE_HOST: 10.254.254.254 # macOS
#      PHP_XDEBUG_REMOTE_HOST: 10.0.75.1 # Windows
      PHP_BLACKFIRE: 1

Перезапускаем контейнера docker-compose stop && docker-compose up -d и всё готово!

Заходим на страницу где хотите профилировать. Жмете на иконку расширения, если всё корректно, будет кнопка "Profile!". Жмете на неё и начнется профилирование. Вы можете сразу тут задать название для своего профилирования.

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

Например, на скриншоте выше, дерево вызова для главной страницы. Видно, что вызов занял 253ms и в пике требовал 9.18MB оперативной памяти.

Поддержка HTTPS

По различным причинам, вам может потребоваться HTTPS для локалки. Например, захотите написать авторизацию через OAuth 2.0 на локалке, а без HTTPS этого сделать просто невозможно, так как https требуется на уровне OAuth 2.0 и все запросы с http, даже с локалки, будут просто откланяться. Что же делать в таком случае? И тут все просто!

Первым делом, нам надо сгенерировать самоподписанный сертификат для домена. Это очень просто, можно воспользоваться сервисом Self-Signed Certificate Generator. Заходим на сайт, вводим домен, в нашем примере example.localhost и жмем Generate. В результате он выдаст вам 2 ссылки на файлы example.localhost.key и example.localhost.cert. Их вам нужно скачать.

Вы также можете сгенерировать самостоятельно без всяких сайтов. Для этого достаточно ввести две команды заменив домен на нужный:

$ openssl genrsa -out example.localhost.key 2048
$ openssl req -new -x509 -key example.localhost.key -out example.localhost.cert -days 3650 -subj /CN=example.localhost

Эти файлы придется положить в проект. Я предлагаю сделать папку certs внутри проекта и положить оба файла туда. После чего, не забудьте эту папку добавить в .gitgnore (правило certs/).

Тогда как оба файла будут в этой папке, открываем docker-compose.yml. Находим настройки для traefik в самом низу и меняем command на новое значение (будет в примере ниже), добавить порты для SSL 443, а также подключить папку с сертификатами.

  traefik:
    image: traefik
    container_name: "${PROJECT_NAME}_traefik"
    command: -c /dev/null --web --docker --logLevel=INFO --defaultEntryPoints='https' --entryPoints="Name:https Address::443 TLS:/certs/example.localhost.cert,/certs/example.localhost.key" --entryPoints="Name:http Address::80"
    ports:
      - '80:80'
      - '443:443'
#      - '8080:8080' # Dashboard
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./certs:/certs

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

Перезапускаем контейнера docker-compose stop && docker-compose up -d.

Теперь сайт будет открываться по https://example.com.

Поддержка поддоменов\алиасов

Например, вы захотели добавить алиас для домена. Тут всё просто. Находим в nginx.label следующую строку: - 'traefik.frontend.rule=Host:${PROJECT_BASE_URL}' и добавляем новое правило через запятую - 'traefik.frontend.rule=Host:${PROJECT_BASE_URL},www.${PROJECT_BASE_URL}' — теперь сайт будет открываться и по www.example.localhost.

Но что если нужно открывать сайт по любом поддомену (читай регулярка) ?. Тогда под данной строкой нужно добавить новую: - 'traefik.frontend.rule=HostRegexp:{subdomain:[a-z]+}.${PROJECT_BASE_URL}' где [a-z]+ регулярное выражение. Перезапускаете сервак, и всё готово. Теперь сайт будет открываться по любому поддомену, например moscow.example.localhost.

На этом, пожалуй всё. Если что интересного узнаю, напишу отдельно или дополню.

веб-сервер
Docker
Drupal
Drupal 8
небольшой уютный чатик

Комментарии

I
Ingvar
сб, 06/09/2018 - 11:21

Никита, когда смотрю на разные способы виртуализации и изоляции типа Vagrant и Docker у меня все время возникает вопрос. Зачем вся эта кухня нужна? Ведь можно поставить на своей машине СУБД и WEB сервер и работать над своим проектом. Или, если сеть и возможности позволяют, вести разработку на удаленном сервере. У меня мало опыта по разработке, видимо поэтому такой вопрос и возникает. :) Очень хотелось бы услышать Ваше мнение на вопрос "Зачем?". Особенно применительно к Drupal. И огромное спасибо за Ваш блог! Последние время я на нем, в основном, и "пасусь".

N
Niklan Ingvar
сб, 06/09/2018 - 16:27

Хм, я тут хотел попробовать видеогайд сделать и думаю начать с этой темы. Хороший вопрос, объяснить зачем это.

Ведь можно поставить на своей машине СУБД и WEB сервер и работать над своим проектом

Кейс. У вас два проекта в работе, один Drupal 7, допустим какой-нибудь обвешенный или старый сайт, второй, тоже магазин, но на Drupal 8. В первом случае, очень вероятно, что у некоторых модулей код написал под php 5.3-5.6 используя возможности которые были удалены при релизе 7.0, во втором же случае, 7.1 будет уже минимальным требование для запуска? Как вы будите разруливать это всё дело?

Или, если сеть и возможности позволяют, вести разработку на удаленном сервере.

Опять же, честно говоря, для меня очень плохо представляется процесс разработки Drupal 8 на удаленной машине:

  1. Благодаря конфигам и git, можно деплоить изменения очень безболезненно и быстро. Что убивает надобность в удаленной работе. Можно иметь и дев версию, и продакшен и локальную.
  2. Для разработки на Drupal 8 потребуется второй сайт, это как минимум. Способ от 7-ки, когда всё писали прямо на продакшене — не прокатит в большинстве задач. Придётся полностью отключат кэширование. Сделав это на продакшене, где есть трафик — просто убьёт сайт и его производительность. Поэтому второй потребуется, как минимум, что не отменяет того факта, что Drupal 8 с отключенным кэшированием достаточно не хило нагружает систему.
  3. Из-за ООП в 8-ке, чаще приходится сталкиваться с xdebug и прочими инструментами. Вы их не поднимете на продакшене, а если поднимете, опять, нужен очень бодрый сервер и это скажется на производительности всех сайтов сервера. Собственно в этот пункт можно и отнести другие инструменты для разработчиков, например blackfire, который бесплатный для использования на локальное машине, и платный для удаленных серверов.
  4. Из-за того что все файлы на локальной системе IDE видит всё что используется на проекте, не больше, не меньше. В случае работы через FTP, придется подготавливать полную копию проекта или как-то ещё выкручиваться, чтобы можно было подключить кодовую базу с нужными vendor библиотеками на проекте и самим ядром друпала. Не в слепую же писать код, верно? А учитывая, что 8-ка очень зависима от композера, и вендоры отличаются от проекта к проекту, меняются версии из-за уменьшенного жизненного цикла ядра, ну, в общем это гемор. С FTP грузить весь друпал 8 с вендорами даже не рассматриваю как вариант. 7-ка то качается пипец сколько в том же phpstorm, 8-ку даже через Filizilla в 10 потоков едет еле-еле.
  5. Что касается нативный сервак vs докер, то вот в чём загвоздка. Я уже написал, что изолирование позволяет каждому проекту иметь изолированную среду с нужными ему PHP, СУБД и другими инструментами. Но это также не засирает систему, удалить следы за проектом очень просто, как подключить новый. В случае с ручным управлением, а опыт у меня такой был, это тот ещё гемор. Добавление virtual hosts только чего стоит в апач. Зачем мне этот гемор? Ну и самый главный козырь Docker, на Linux он работает максимально производительно. Жрет он очень мало, так как всё берет напрямую из ядра хоста. Нет никаких виртуальных машин, ничего, оперативку жрет только ту, которую надо. Он жрет ресурсы по необходимости и динамически как штатный софт системы. А не так, что изначально ему выделяется CPU, RAM и он в этом загоне варится даже если простаивает, то оно постоянно используется.

Если копать ещё дальше, то докеры используют на серверах, и можно пушить сразу с конфигами, сервак пересоберет всё под новое окружение. Но я этим не занимаюсь. Также, если над проектом работают 2 и более разработчиков, то работать на сервере с одним сайтом не выйдет, а плодить их с дебаг режимом - опять же, потребуется очень сильный сервак. В случае с докером, у всех общий docker-compose.yml файлик, в котором настроено всё. От версий PHP, Maridb, nginx и т.д. и т.п., то лимитов и спец. настроек php. У всех сайт работает на абсолютно идентичном окружении. И если потребуется, со временем, обновить PHP до новой версии, соответствующий параметр изменят в нужном файлике, и в следующий раз у всех разработчиков будет PHP новой версии, которую указали. Не получится так, что один пишет код на 5.6, а другой на 7.1, а потом оказывается что разработчик на 7.1 писал код с новыми возможностями, которых на 5.6.

Для новичков docker даже проще чем разворачивать полноценный сервак, хотя опыт такой был бы очень полезен. Но если накосячить с php или apache на нативном локальном сервере, то покрошатся все проекты, а в докере только тот, где ковырялись.

Из недостатков Docker можно отнести, разве что, то, что файлы ему приходится синхронизировать с хостом. Следовательно, проект начинает занимать х2 места на диске и увеличивается нагрузка на HDD\SSD. Но у меня на данный момент HDD, работает всё очень шустро и потребности в SSD не ощущаю. В общем то и всё, производительность, гибкость просто на высоте.

I
Ingvar Niklan
пт, 06/15/2018 - 12:05

В последнем абзаце комментария есть фраза файлы ему приходится синхронизировать с хостом. У меня есть более общий вопрос: А вообще, как лучше организовать, по Вашему мнению, обмен файлами и базой данных между локальной машиной для разработки и продакшен сервером? Например: есть хост с Drupal8, там уже что-то создано, есть какие-то типы материалов, таксономия и т.д. В какой-то момент времени понадобилось разработать какой-то модуль. Разработка предполагается в среде docker4drupal. Вот как дальше действовать?

N
Niklan Ingvar
пт, 06/15/2018 - 15:41

Могу видео записать (сам уже подумывал об этом) и\или статью.

В 8-ке то всё просто. Конфиги + git + drush и все наработки перебрасываются за минуту максимум и они уже на продакшене работают.

Я так и работаю. Вся разработка исключительно на локалке. Для некоторых проектов есть стейдж версии типа dev.exmaple.com закрытые от поисковиков, куда периодически выкатываются версии новых наработок на проверку заказчика, проверить, поиграться, попробовать, может чего поправить придется. Ну и конечно продакшен.

Поработал, сделал что-то: drush cex -y, git add -A, git commit -m "Commit comment", git push. А на продакшене или стейдже: git fetch && git pull, (если установлены новые зависимости и обновлены старые) composer install, drush cim -y, в некоторых случаях drush cr. Собственно весь деплой так и делается, ничего больше. Дальше только разжевывать и показывать)

П
Павел Ingvar
сб, 06/09/2018 - 19:17

Отвечу на ваш вопрос коротко...незачем если у вас windows. Если вы новичек используйте openserver и переключайте спокойно версии php кликом мышки, а файлы drupal 8 закачивайте архивом и распаковывайте средствами хостинга - это занимает порядка 30 секунд.

С
Сергей
чт, 06/14/2018 - 09:23

Но у меня на данный момент HDD, работает всё очень шустро и потребности в SSD не ощущаю.

У меня два SSD по 512 гиг - на первом Ubuntu, на втором - только папка /var. Что сразу решает все вопросы с нехваткой места для сайтов, контейнеров и т.д.

А потребность в SSD ощущается, когда надо импортировать тысячи нод в сайт на Drupal 8 из кастомной CMS. С копированием и переименованием тысяч картинок по шаблону, созданием десятков полей и т.д. Тогда вместо 20 мин на HDD импорт будет выполнен за 3 мин на SSD.

Или когда надо делать сайт, одновременно вытягивая другой проект с FTP в 8-10 потоков. На HDD это жуткие тормоза.

HDD - это боль. Даже простое индексирование проекта в PhpStorm занимает минуту, в то время как на SSD - десять секунд. Два Samsung 860 Evo с интерфейсом SATA - это 400 баксов в сумме. Но компьютер превращается из КАМАЗа в Боинг. За смешные деньги.

N
Niklan Сергей
чт, 06/14/2018 - 13:46

Согласен что на SSD всё быстрее.

Даже простое индексирование проекта в PhpStorm занимает минуту

Но у меня 8-ку индексирует недолго, может секунд 10-20. Тут же от HDD и его поношенности сильно зависит тоже.

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

Но да, SSD надо брать, я согласен. Я когда год назад обновлял ПК, хотел взять, но чот зажлобился, думаю потом возьму) А потом всё как-то тянется) У меня ещё дуалбут с виндой, не могу придумать как разруливать все сиутации в таком случае. Мне /home по любому надо отделять, для простоты восстановления работы или смены дистра, /var выйдет что тоже потребуется отделять и не ясно в таком случае что к чему. А тут 1ТБ срезал для линукса и файлов, и 2ТБ для винды и всем по горло хватает. Из-за объемов SSD это мне выльется в головняк.

I
Ingvar
чт, 06/14/2018 - 12:52

В статье есть один момент, который я пока так и не победил. Вы пишете:

Важно!. В процессе установки, или, если вы разворачиваете готовый проект, в качестве хоста для базы данных нужно указывать mariadb, вместо localhost

В моем случай я использую не mariadb, а postgres. Во время установки Drupal-а, указал postgres вместо localhost и все поставилось. Но, когда я запускаю drush, то вижу очень скудный список команд/опций. Например нет команды config:export. Даю drush команду с отладкой drush sql:dump --result-file=18.sql --debug и вижу (привожу кусок выдачи)

[info] sql-query: SELECT tablename FROM pg_tables WHERE schemaname='public'; [0.14 sec, 3.56 MB] [info] Executing: PGPASSFILE=/tmp/drush_tXl1pK psql -q --dbname=drupal --host=postgres --port=5432 --username=drupal --file /tmp/drush_gOjNMP [0.14 sec, 3.56 MB] psql: преобразовать имя "postgres" в адрес не удалось: Имя или служба не известны Calling system(PGPASSFILE=/tmp/drush_tXl1pK pg_dump drupal --host=postgres --port=5432 --username=drupal --data-only > 18.sql); pg_dump: [архиватор (БД)] не удалось подключиться к базе "drupal": преобразовать имя "postgres" в адрес не удалось: Имя или служба не известны [error] Database dump failed [0.2 sec, 3.56 MB]

из которого видно, что drush ничего не знает про хост postgres. Не встречались с такой проблемой?

I
Ingvar Niklan
пт, 06/15/2018 - 07:12

Решил проблему. На машине уже был установлен drush и именно он и запускался. Забыл alias-ы добавить. Добавил, теперь все нормально.

b
batkor
пн, 06/18/2018 - 02:37

Спасибо очень познавательно!

Для тех у кого стоит ubuntu18.04 Kubuntu18.04 то docker ce еще не вышел в bionic версии, используйте artful deb [arch=amd64] https://download.docker.com/linux/ubuntu artful stable

S
Sega
пт, 06/29/2018 - 17:18

Спасибо огромное за статью и видео! Такой вопрос: Docker установлен, проект создан

Создаю index.php файл, а браузер пишет File not found. Такое ощущение что что-то с путями напутал. По какой причине это может произойти?

N
Niklan Sega
пт, 06/29/2018 - 19:44

А docker-compose stop && docker-compose up -d делали? Эти изменения только после полного перезапуска контейнеров вступят в силу.

S
Sega Niklan
сб, 06/30/2018 - 13:23

Делал. По прежнему получаю File not found. Поставил docker на совсем другую машину и тоже самое... Все ставил последних версий. Может быть docker4drupal обновленный что-то мудрит... Или я что-то упускаю

N
Niklan Sega
сб, 06/30/2018 - 13:31

Скорее упускаете. Так как Docker4Drupal по факту юзается и для продакшен деплоя через wodby, там бы такое очень быстро обнаружили.

Раз на второй машине проблема сохраняется даже на другой машине, то можно исключить проблему с правами доступами. Но какой путь указан до index.php и что лежит в папке где docker-compose.yml это вопрос. Скиньте куда-нибудь на pastebin свой docker-compose.yml и скрин папки где он лежит с теми файлами, что рядом с ним.

S
Sega Niklan
сб, 06/30/2018 - 14:20

Никита, прошу прощения. Всему виной моя невнимательность. Пересмотрел еще раз видео и нашел свою ошибку. Злополучный web в пути NGINX_SERVER_ROOT. Спасибо за помощь )

А
Алексей
вс, 08/12/2018 - 15:26

Здравствуйте! Все установил как описано и все работает, за статью спасибо огромное! Осталось два не решенных вопроса, необходимо увеличить memory limit и время выполнения скрипта, где находятся файлы настроек (php.ini и другие)? и еще вопрос про изменение места хранения в папку home, у меня не создалась папка .docker, я ее создал в ручную, но она пустая?

N
Niklan Алексей
пн, 08/13/2018 - 07:11

Все это правится через переменные окружения в docker-compose.yml файлике.

  1. В этом разделе выбирается репозиторий нужного контейнера. Например PHP.
  2. Там видно что изображение для Drupal и есть ссылка на основной контейнер PHP. А вот там уже все переменные.
  3. Выбираете нужные, например PHP_MEMORY_LIMIT. Копируете эту строку.
  4. Открываете docker-compose.yml файл и в этот раздел, по аналогии с другими переменными окружения вставляется эта строка + нужное новое значение. Затем надо перезапустить контейнер(а) и оно обновится само.

и еще вопрос про изменение места хранения в папку home, у меня не создалась папка .docker, я ее создал в ручную, но она пустая

Возможно не там указали значение, возможно не перезагружали комп. Скорее всего это необходимо, как минимум демона докера.

Г
ГО
чт, 10/25/2018 - 14:47

Уважаемый автор опишите, пожалуйста, настройку xdebug в связке с docker4drupal для отладки консольных скриптов в PHPstorm.

N
Niklan ГО
пт, 10/26/2018 - 08:32

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

Р
Роман
сб, 11/17/2018 - 10:20

Никита, скажите пожалуйста. Разве в данном коде

{
  "graph": "/home/USERNAME/.docker"
}

не нужно вместь "/home/USERNAME/.docker" писать "/home/$USERNAME/.docker"

N
Niklan Роман
сб, 11/17/2018 - 13:01

Я написал капсом, чтобы внимание обратили и заменили на свой юзернейм. На момент написания статьи эти настройки не поддерживают данные переменные. Он в прямом смысле тогда создаст папку по пути /home/$USERNAME/.docker. Проверял ?

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

А
Александр
вт, 12/11/2018 - 23:59

Никита, спасибо за статью!

Сейчас при первом старте sudo docker-compose up -d Drupal 8.6.3 скачивается в ~/.docker/volumes/example_codebase/_data. К слову, сейчас уже доступен D 8.6.4. По адресу http://example.localhost после этого открывается стандартный установщик Друпал.

Не подскажешь, что нужно поправить в настройках, чтобы Drupal по дефолту качался в ~/Projects/local/example?

А
Александр Александр
ср, 12/12/2018 - 17:20

Нашел некое решение.

Всё-таки нужно удалить/переименовать/заархивировать docker-compose.override.yml файл и выполнить из папки ~/Projects/local/example стандартную команду composer create-project drupal-composer/drupal-project:8.x-dev some-dir --stability dev --no-interaction. Тогда код свежего друпала скачается в ~/Projects/local/example/some-dir. Потом его можно естественно перенести выше из some-dir, some-dir удалить. Пробовал удалять только строчку image: wodby/drupal:$DRUPAL_TAG из docker-compose.override.yml, но не помогает - всё равно код друпала ставится в ~/.docker/volumes/example_codebase/_data.

AT
Andrey T.
ср, 01/02/2019 - 22:48

Добрый день! Делал все по инструкции. После ввода команды 'composer install' вышла следующая ошибка: ''' Problem 1 - drupal/core 8.7.x-dev requires ext-dom * -> the requested PHP extension dom is missing from your system. - drupal/core 8.6.x-dev requires ext-dom * -> the requested PHP extension dom is missing from your system. - drupal/core 8.6.4 requires ext-dom * -> the requested PHP extension dom is missing from your system. - drupal/core 8.6.3 requires ext-dom * -> the requested PHP extension dom is missing from your system. - drupal/core 8.6.2 requires ext-dom * -> the requested PHP extension dom is missing from your system. - drupal/core 8.6.1 requires ext-dom * -> the requested PHP extension dom is missing from your system. - drupal/core 8.6.0-rc1 requires ext-dom * -> the requested PHP extension dom is missing from your system. - drupal/core 8.6.0-beta2 requires ext-dom * -> the requested PHP extension dom is missing from your system. - drupal/core 8.6.0-beta1 requires ext-dom * -> the requested PHP extension dom is missing from your system. - drupal/core 8.6.0-alpha1 requires ext-dom * -> the requested PHP extension dom is missing from your system. - drupal/core 8.6.0 requires ext-dom * -> the requested PHP extension dom is missing from your system. - Installation request for drupal/core ^8.6.0 -> satisfiable by drupal/core[8.6.0, 8.6.0-alpha1, 8.6.0-beta1, 8.6.0-beta2, 8.6.0-rc1, 8.6.1, 8.6.2, 8.6.3, 8.6.4, 8.6.x-dev, 8.7.x-dev].

To enable extensions, verify that they are enabled in your .ini files: - /etc/php/7.2/cli/php.ini - /etc/php/7.2/cli/conf.d/10-opcache.ini - /etc/php/7.2/cli/conf.d/10-pdo.ini - /etc/php/7.2/cli/conf.d/20-calendar.ini - /etc/php/7.2/cli/conf.d/20-ctype.ini - /etc/php/7.2/cli/conf.d/20-exif.ini - /etc/php/7.2/cli/conf.d/20-fileinfo.ini - /etc/php/7.2/cli/conf.d/20-ftp.ini - /etc/php/7.2/cli/conf.d/20-gettext.ini - /etc/php/7.2/cli/conf.d/20-iconv.ini - /etc/php/7.2/cli/conf.d/20-json.ini - /etc/php/7.2/cli/conf.d/20-mbstring.ini - /etc/php/7.2/cli/conf.d/20-phar.ini - /etc/php/7.2/cli/conf.d/20-posix.ini - /etc/php/7.2/cli/conf.d/20-readline.ini - /etc/php/7.2/cli/conf.d/20-shmop.ini - /etc/php/7.2/cli/conf.d/20-sockets.ini - /etc/php/7.2/cli/conf.d/20-sysvmsg.ini - /etc/php/7.2/cli/conf.d/20-sysvsem.ini - /etc/php/7.2/cli/conf.d/20-sysvshm.ini - /etc/php/7.2/cli/conf.d/20-tokenizer.ini You can also run php --ini inside terminal to see which files are used by PHP in CLI mode. ''' с чем это может быть связано? Пробовал и PHP7.2, и PHP7.1...

HP
Harry Potter
пт, 01/18/2019 - 03:02

Здравствуйте, я использую Ubuntu и кое что не понятно: 1. Почему когда я в .env файле PROJECT_URL задаю, например drupal.localhost, то все ок. На как только я пробую любой домен без .localhost, то сайт не хочет подыматься? После смены домена пробовал все контейнера удалять и ставил заново, все равно повиденние такое же. 2. Можно ли поднять среду без traeffik контейнера, если да то как обращаться к сайту? domain_name:8000/? 3. Стопаете ли вы апач когда работаете с докером? Апач же юзает 80 порт и контейнер нджинкса тоже юзает 80 порт.

N
Niklan Harry Potter
вт, 01/22/2019 - 07:10
  1. Не знаю с чем это связано. /etc/hosts настроен? Браузер хром? Хром без хостса сам пытается на .localhost дернуть 127.0.0.1, тот же firefox и на .localhost выдаст "не найден" пока не прописать в хост, так как это валидная доменная зона.

2-3. Не знаю, на счёт траефика лучше спросить у разработчиков докера. Апача на локалке не стоит, поэтому проблем нет. Но если он стоит и нужен, то да, юзать другой порт, тот же 8000 и указывать явно его при обращении к сайту.

m
mobilen
пн, 01/28/2019 - 15:31

Огромное спасибо за статью! Несколько дней разбирался. Просто я параллельно и ubuntu изучаю. Не все так просто. Но понял многое, еще раз спасибо.

Для начинающих оставлю пару комментов, вдруг кому поможет: 1. Пришлось действительно разобраться, что и зачем написано в этих конфигурационных файлах. И документацию читать. Без этого не получится. Без понимания малейший косяк вас в ступор вгоняет. 2. Файл docker-compose-override.yml нужно УДАЛИТЬ. Судя по докам к сборке на сайте github, он нужен только для демо-запуска vanilla drupal. Поэтому, если не удалить- выскакивает сразу страница установки. 3. Очевидно конечно, (но я ж не знал), composer и docker compose - разные вещи. Поэтому без установленного в саму систему composer команда composer install не сработает. 4. Если не убрать web в NGINX_SERVER_ROOT: /var/www/html/web, то файл index.php не сработает. Разумеется, web надо вернуть при установке drupal. 5. При работе composer install тоже выдавало ошибки, как я понял, из-за отсутствия некоторых расширений в php. Например, в ошибке фигурирует ext-gd, лечится установкой sudo apt-get install php7.2-gd. И другие по аналогии. Еще такая ошибка при работе с composer: Cannot create cache directory /home/user/.composer/cache/repo/https---packages.drupal.org-8/, or directory is not writable. Proceeding without cache Лечится: sudo chown -R $USER $HOME/.composer.

Одно только не понял. Я гит клон сделал. И установка шла через композер из скачанных материалов. Однако все равно что-то подкачивало и достаточно долго ставилось. Если честно, на винде семерке под опенсервером это гораздо быстрее происходит. Намного быстрее, если файлы drupal до этого скачаны. Т.е. для нового проекта сделал папку- вкинул файлы и все. Сразу идет установка. Да и стартует опенсервер с готовым проектом почему-то быстрее, чем docker. Комп один и тот же. У каждой системы свой отдельный SSD (не самые дешевые- скорость приличная). Может, на тяжелых сайтах с наполнением будет совсем наоборот, посмотрим. Пока непонятно.

Ушел рыть дальше).

N
Niklan mobilen
пн, 01/28/2019 - 15:51
  1. Не рекомендую удалять docker-compose.override.yml. Удаление поможет, но я бы не сказал что это правильное решение. Лучше поправить его под себя, например так:
version: "3"

services:
  php:
    environment:
      PHP_FPM_CLEAR_ENV: "no"
    volumes:
      - ./:/var/www/html

  nginx:
    volumes:
      - ./:/var/www/html

#  mariadb:
#    volumes:
#      - ../database:/var/lib/mysql

  traefik:
    ports:
      - '80:80'
  1. Composer ставить на систему совсем не обязательно. Этому посвящен целый раздел в статье, как вызывать композер из контейнера. И даже неправильно пользоваться системным composer, а не тем что в контейнере, так как версии PHP буду отличаться, а композер очень чувствителен к ним. В случае с контейнером их можно контролировать, в случае с системным, вы ограничены одной версией, и как правило, очень старой.

  2. /web приставка изначально добавлена для composer drupal project. Опять же, в статье об этом есть упоминание, чтобы не напороться. Вы либо её используете из-за composer drupal project, либо не используете. Если удалили и все работает - возвращать не нужно.

  3. Одна из причин не использовать композер на хосте. Отсылка к пункту 3.

m
mobilen
чт, 01/31/2019 - 02:29

Спасибо большое за комментарий! Разбираюсь.

В доках они именно говорят снести этот файл. Ну да ладно. С этим разберемся.

Спрошу другое: не до конца понимаю значение volumes.

Описаний крайне мало. Некое пространство (обмена? или что) между локальным хостом и виртуализированными контейнерами?

(Саму суть работы докера я хорошо понял, именно в чем он отличается от обычной виртуалки- тут проблем с пониманием вообще нет. Классная вещь, кстати- большой респект тому, кто это придумал!).

Если мы прописываем

 nginx:
    volumes:
      - ./:/var/www/html

Я так понимаю, nginx свои файлы при текущей работе будет хранить именно в этом разделе?

И никак не могу догнать, что меняется, если мы /web добавляем.

Никита, извините, если достаю.

Я просто технарь по складу ума. И, если я, как говорится, "физику процесса" не понимаю-я не могу дальше двигаться...

N
Niklan mobilen
чт, 01/31/2019 - 07:23

Ну если рекомендуют снести, сносите. Значит этот файл для тех кто склонил репо себе и надо под себя подогнать. Им виднее в этом плане.

Если мы прописываем nginx: volumes: - ./:/var/www/html Я так понимаю, nginx свои файлы при текущей работе будет хранить именно в этом разделе?

Вроде в статье расписывал, это биндинги для синхронизации. Грубо говоря любое изменение в ./ будет синхронизироваться с /var/www/html в контейнере и наоборот. Но основным источником данных является то, откуда монтируется ./. При инициализации контейнера, тоже, начальные данные возьмутся из ./ и будут скопированы в /var/www/html.

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

m
mobilen
чт, 01/31/2019 - 02:33

Еще извините, есть косяк в блоге: текст комментария не форматируется по нажатию enter. Т.е. я в комменте делаю абзац, а по факту- все сливается в сплошной текст. (сами видите). Очень неудобно. Хоть под виндой, хоть под линуксом- без разницы.

N
Niklan mobilen
чт, 01/31/2019 - 07:29

Markdown же, он корректно отрабатывает. Enter - перенос на следующую строку, абзац отделяется пустой линей (два раза enter).

  • Перенос на новую строку: https://i.imgur.com/KYZQvhp.png
  • Абзац: https://i.imgur.com/CNUDKmf.png

Вот ваш комментарий до правок: https://i.imgur.com/Z8N3Uck.png, а вот отформатированный: https://i.imgur.com/PkjfX70.png.

https://pastebin.com/q32fwQDW вот тут я сохранил оригинал и исправленную версию, можете сравнить.

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

ХС
Хрен Собочий
пт, 02/01/2019 - 00:53

так и не понял где физически должен лежать сам Drupal /var/www/html тут чтоли ?? если нет этого раздела где он должен валятся ,,, этот раздел ручками нужно создавать ? Тогда зачем вообще папка /Projects/local/example ,,,

N
Niklan Хрен Собочий
пт, 02/01/2019 - 06:48

В статье же расписано. В docker-compose.yml указывается биндинг откуда:куда. По умолчанию там ./:/var/www/html это значит что текущая папка будет синхронизироваться с /var/www/html папкой контейнера. Папка указанная после двоеточия - эта папка внутри контейнера, её просмотреть можно только зайдя в сам контейнер через терминал. Вас это волновать вообще никак не должно. Вам главное указать где у вас на компе друпал, а это первая часть ./ (текущая папка).

Если это вызывает проблемы, мой совет, ложите docker-compose.yml (и все остальные файлы от docker4drupal) в папку где лежите index.php друпала и всё, и дальше по инструкции. Если ядро установлено composer drupal project, тогда на уровень ниже, в корень сайта где лежит web.

ХС
Хрен Собачий Niklan
вс, 02/10/2019 - 02:17

поставил последний этот Docker 5.1.4 пути не работают пишет не найден файл не работает скачивание phpmyadmin adminer ! ,,, поставил 5.0.4 как в статье все ок пути заработали ./www:/var/www/html закинул в папку www index.php ,, надо отметить http://pma.example.localhost ,, phpmyadmin запускается по этому пути + http://adminer.example.localhost ,,, ищю возможность поменять настройки php.ini

ХС
Хрен Собачий Niklan
вс, 02/10/2019 - 23:42

Как Вы создаете несколько баз банных для нескольких проектов ? phpmyadmin закрыт от создания новой базы нехватает прав ? как разрабатывать несколько проектов????

А
Андрей
пт, 02/01/2019 - 11:23

Никита, а ты бы стал использовать docker не для разработки, а для боевого продакшен сервера (Ubuntu Server, например)? Очень конечно заманчиво быстро и автоматом разворачивать окружение, но лишний "посредник" (контейнер, CaaS) как-то смущает.

N
Niklan Андрей
пн, 02/04/2019 - 07:52

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

А
Андрей Niklan
пн, 03/25/2019 - 13:51

Не пойму, почему для продакшена я должен юзать этот сервис Wodby? Совсем не хочется быть к нему привязанным. Разве я не смогу на базе конфигурационных файлов локального docker4drupal запуститься на сервере?

N
Niklan Андрей
ср, 03/27/2019 - 12:59

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

Их сервис просто добавляет этому процессу удобство в виде UI и платной поддержки.

А
Алексей
пт, 02/01/2019 - 13:25

Никита, здравствуйте! Возникла такая проблема: необходимо что бы из контейнера докера выход в интернет был через прокси-сервер. Порылся в документации, но толком внятного ничего не нашел, подозреваю что надо как то настроить traefic. Сама проблема что не скачивает зависимости composer если его запускать из php контейнера докера.

m
mobilen
вс, 02/03/2019 - 22:07

Никита, еще раз спасибо. Но, вопросы остаются. (Замечу, что Вы предполагаете, что я, скажем, посмотрел все Ваши видео. Это не так. Я пытаюсь последовательно. Вы в ответах ссылаетесь на все, что Вы сказали во всех видео))). Это все понятно, не можете же полностью держать в памяти, где что говорили. Ерунда, разберемся.

  1. Все-таки файл docker-compose.override.yml каким то непонятным образом вызывает изначально установку drupal. Я понимаю, что он переопределяет файл docker-compose.yml в прописанных значениях. Тем не менее. Для меня загадка. Там же нет никакого кода/строк и т.д. Как так? Все-таки не зря они четко говорят в доках:- удалить этот файл. В итоге прописал папки и все нужные значения непосредственно в docker-compose.yml

  2. При запуске выдает ошибку "manifest for wodby/adminer:4.6-3.4.0 not found". (Явная отсылка к .env файлу. Я уже не стал заморачиваться. Почитал спецификацию. Написано we use adminer 4.6. Просто исправил на 4.6 без указания версии 3.4.0. Чем это грозит?

  3. Я окончательно запутался с этими composer. Есть composer (php) в самой убунту. Есть в docker. И есть в drupal. Так или что??? Все устанавливается и работает. Но я понять не могу, какая из прог это делает. И если проблемы возникнут- где искать...

N
Niklan mobilen
пн, 02/04/2019 - 07:55
  1. Потомучто в override файле прописан другой image для php контейнера. В нем уже находится drupal composer project. Он затирает контейнер с пустым php из оригинала, потому так и ведет себя.
  2. Не знаю, лучше спросить у авторов.
  3. В контексте Docker4Drupal: Composer есть в контейнере с php (можно обощить до веб-сервера), и больше нигде. У Drupal только файлик composer.json, с описанием зависимостей. Все делает Composer, а composer это просто php файлик установленный в системе. Его можно просто скачать с офф сайта и запускать php composer.php (очень грубо, там расширение будет .phar, но сути это не меняет).
V
Vladimir
сб, 03/09/2019 - 03:53

Никита, а как правильно разворачивать одновременно несколько проектов? Сейчас я делаю так: создаю под каждый проект папку, клонирую файлы с docker4drupal, меняю в yml файле порт и выполняю docker-compose up -d т.е получается под каждый проект создаются свои контейнеры, это правильный поход?

z
zven Vladimir
сб, 03/16/2019 - 02:17

Всё верно, редактируй в .env меняй PROJECT_NAME= PROJECT_BASE_URL= и в docker-compose.yml уникальный порт(чтоб не пересекался с другими проектами) в секции traefik:
Плюс не забываем читать историю изменений https://github.com/wodby/docker4drupal/releases, выше многие жалуются что контейнеры более не скачиваются с репозиториев, явно они устаревают и автор их более не поддерживает (чекаем на докерхабе: https://hub.docker.com/search?q=wodby%2Fdrupal&type=image какие tags сейчас есть и обновляются)

f
fox
вс, 05/26/2019 - 22:02

Как нужно настроить traefik, чтобы открыть drupal наружу? то есть по статье можно работать только на локальной машине, а хотелось бы открывать сайт и на других устройствах в пределах локальной среды, а может потом еще захочется развернуть на vps, поделись секретом будь другом.

V
VladSavitsky
пн, 06/10/2019 - 11:12

Если перемещать файлы докера в другой раздел, то нужно фиксить права доступа к разделу. Я потратил несколько дней пока нашел решение!... https://github.com/wodby/docker4drupal/issues/388

z
zven
ср, 07/03/2019 - 03:26

Проброс порта БД с контейнера на постоянной основе -"внешнийпорт:внутреннийпорт": mariadb: ports: - "3306:3306"