Настройка среды разработки PHP с помощью Docker

В этом руководстве я расскажу, как лучше всего приступить к настройке среды разработки PHP, и расскажу, как настроить Docker. Существует так много способов настроить среду разработки PHP, но использование Docker — это лучшая практика.

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

Содержание

Немного предыстории
1. Установка PHP, MySQL и Apache вручную
2. Предварительно настроенные пакеты, такие как XAMPP.
3. Виртуальные машины и бродяги
4. Docker
Что не так с Vagrant?
Представляем Docker
Настройка
docker-compose.yml для NGINX
Запуск службы
PHP
MySQL
Выполнено!
TL; DR! Просто отдай мне файлы!

Немного предыстории

Одна из проблем веб-разработки заключается в том, что всё быстро меняется. Лучшие практики CSS меняются по мере добавления в спецификацию новых свойств. (Как мы вообще обходились без CSS Grid ?) Сейчас PHP находится в версии 8, и даже инструменты, которые мы используем для выполнения скриптов PHP, со временем совершенствуются. В результате многие учебные пособия довольно быстро устаревают.

Ещё пару лет назад я отправлял всех, кого учил, к прекрасной статье Бруно Скворца » Повторное знакомство с Vagrant: правильный способ начать с PHP«. В то время это было фантастическое введение в (на тот момент) лучший способ создания локальной среды разработки.

Эта статья только за 2015 год, но пять или шесть лет — это целая вечность в постоянно меняющихся временных рамках веб-разработки. С тех пор «правильный путь» продвинулся довольно значительно.

Я быстро напомню, как всё изменилось за эти годы.

1. Установка PHP, MySQL и Apache вручную

Если вы, как и я, достаточно взрослые, чтобы заниматься разработкой веб-сайтов в 90-е годы, вы вспомните, насколько неприятным был этот опыт. В то время, если вы были в меньшинстве, кто не разрабатывал только на реальном веб-сервере (да, мы действительно это сделали, да, это была ужасная идея), вы бы вручную установили Apache, PHP и MySQL на свою машину разработки.

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

2. Предварительно настроенные пакеты, такие как XAMPP.

К началу и середине 2000-х люди начали собирать всё необходимое программное обеспечение в один пакет, который устанавливал и настраивал всё необходимое программное обеспечение. Это были такие пакеты, как XAMPP и WAMP, и одним нажатием кнопки они давали вам удобную среду разработки.

Если вы будете болтаться по различным группам PHP в Facebook, вы обнаружите, что значительная часть новых разработчиков всё ещё следуют руководствам той эпохи, а большое количество существующих разработчиков никогда не уходили, поэтому XAMPP по-прежнему используется довольно широко. Если это описывает вас, пора двигаться дальше.

Использование XAMPP упростило настройку и запуск среды веб-разработки на вашем компьютере. В статье Бруно описаны проблемы этого подхода, но основная проблема возникает, когда вы хотите разместить свой сайт в Интернете. Версии PHP, MySQL и Apache (или NGINX) могут отличаться от тех, которые вы установили как часть вашего пакета XAMPP. Кроме того, между Windows и Linux есть пара незначительных, но разочаровывающих различий. Если вы разрабатываете свой сайт на машине с Windows и загружаете его на сервер Linux, часть вашего кода может вообще не работать после загрузки.

3. Виртуальные машины и бродяги

В конце 2000-х — начале 2010-х годов среди разработчиков была тенденция к переходу на виртуальные машины. Идея заключалась в том, чтобы вы могли запустить копию реальной операционной системы веб-сервера со всеми установленными на нём программами — точно такую же конфигурацию и настройку, как и реальный веб-сервер, на котором вы собирались в конце концов развернуть свой веб-сайт. Таким образом, когда вы запустили сайт, не было никаких шансов, что он не заработает.

Хотя многие программисты увидели преимущества такой среды, сложность и время, необходимые для её настройки, означали, что это сделали немногие. Так было до тех пор, пока не появился Vagrant (и связанные с ним инструменты, такие как Puphpet), которые избавили его от всех хлопот.

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

4. Docker

Всё это подводит нас к сегодняшнему дню и к причине этой статьи. Если Vagrant так хорош, зачем использовать что-то другое?

Основные преимущества виртуальной среды, созданной с помощью Vagrant:

Ваш компьютер разработки не привязан к определённой среде. Вы можете разместить несколько веб-сайтов: один на Apache, один на NGINX, один на PHP 7 и один на PHP 8.
Когда сайт запускается, он загружается в ту же среду, в которой он был разработан.

Легко понять, зачем это нужно разработчикам. Сделав следующий шаг к Docker, мы сохраним эти преимущества, избегая при этом некоторых недостатков сред Vagrant / Virtual Machine.

Что не так с Vagrant?

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

Системные ресурсы. Vagrant требует запуска совершенно другой операционной системы. Вам необходимо загрузить и установить операционную систему, работающую на вашем веб-сервере, и все установленные ею пакеты. При этом используется значительный объём дискового пространства и памяти. Виртуальной машине обычно требуется как минимум 512 МБ ОЗУ. Это немного для современных компьютеров, но быстро складывается. Если вы хотите разместить один веб-сайт на PHP 7 и один на PHP 8, вам необходимо установить и настроить на вашем компьютере два разных экземпляра виртуальных машин.
Вы должны убедиться, что виртуальная машина и сервер синхронизированы. Всякий раз, когда вы обновляете сервер или изменяете конфигурацию сервера, вы должны не забывать обновить локальную среду разработки с такими же изменениями.
Это жёстко фиксирует вас в операционной системе и конфигурации сервера. Перенести сайт с одного сервера на другой — сложная задача. Веб-сайт — это больше, чем просто сценарии PHP, изображения и CSS, из которых он состоит. Для правильной работы веб-сайта также требуется определённая конфигурация сервера (например, установленные расширения PHP и conf/ httpd.conf).
Существует очень ограниченный выбор доступных пакетов. В зависимости от того, какой дистрибутив Linux работает на вашем веб-сервере, у вас может не быть выбора, какую версию PHP вы запускать. Если вы не установите пакеты из сторонних репозиториев, вы не сможете использовать самую последнюю и лучшую версию PHP. На момент написания недавно стал доступен PHP 8. Если вы используете CentOS 8 / RHEL 8, вы застряли на PHP 7.3, пока не получите новую версию операционной системы. Если вы используете Debian, последняя доступная версия — 7.3. В других дистрибутивах будут доступны другие версии.
Конфигурация сервера глобальная. В PHP есть файл настроек с именем ini. При изменении этого параметра обновлённая конфигурация применяется ко всем веб-сайтам, размещённым на сервере. То же самое касается nginx.confNGINX или httpd.confApache. Экземпляр базы данных MySQL имеет базы данных для всех сайтов, размещённых на сервере. Внесение каких-либо крупномасштабных изменений конфигурации базы данных имеет далеко идущие последствия. Обновление настройки MySQL повлияет на каждый веб-сайт, использующий этот сервер MySQL!
Версии пакета являются глобальными на реальном сервере. Хотя можнозапустить несколько версий PHP на одном веб-сервере, его сложно настроить и могут возникнуть странные побочные эффекты в зависимости от того, что делает ваш скрипт (например, когда у вас есть скрипт, который вы хотите запустить в модуле systemd / cronjob и забудьте, что вы должны использовать, /bin/php72а не /bin/php).

Хотя точки 5 и 6 можно преодолеть на машине разработки, запустив разные виртуальные машины Vagrant, вам понадобится реальный веб-сервер, который отражает каждую используемую вами конфигурацию, чтобы веб-сайты работали, когда вы их загружаете.

Представляем Docker

Docker решает все перечисленные выше проблемы. Но что такое Docker и как он работает?

Начнём с вступления из Википедии:

Docker — это набор продуктов «платформа как услуга» (PaaS), которые используют виртуализацию на уровне ОС для доставки программного обеспечения в пакетах, называемых контейнерами. Контейнеры изолированы друг от друга и объединяют собственное программное обеспечение, библиотеки и файлы конфигурации; они могут общаться друг с другом через чётко определённые каналы.

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

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

«Разве это не то, что виртуальная машина уже делает?» Я слышал, вы спросите. Да, но есть большая разница между тем, как Vagrant и Docker обрабатывают установку программного обеспечения.

С Vagrant, работающим на виртуальной машине, полная операционная система с определённой версией PHP, версией MySQL и (обычно) конфигурацией сервера клонируется с реального веб-сервера. Когда сервер обновляется, виртуальная машина также должна быть обновлена.

Однако при использовании Docker версия PHP / MySQL / NGINX предоставляется в виде единого пакета, известного как образ, и сервер может запускать столько разных образов, сколько захотите.

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

Кроме того, каждое изображение полностью отделено от другого изображения на сервере. Каждое изображение (по одному на веб-сайт в этом упрощённом примере) отделено друг от друга. Каждый веб-сайт будет иметь свою собственную конфигурацию NGINX, php.iniсвои собственные установки PHP и MySQL. На каждом веб-сайте могут быть разные версии PHP. У вас даже может быть один веб-сайт, работающий на Apache, и один веб-сайт, работающий на NGINX, на одном компьютере одновременно. Даже когда вы запускаете два разных веб-сайта NGINX, у вас будут одновременно работать два разных процесса NGINX с собственными конфигурациями.

У этого есть небольшие накладные расходы на память, но предоставляемая им гибкость делает это очень полезным компромиссом:

Весь веб-сайт с необходимыми версиями PHP / MySQL, всю конфигурацию и весь код можно легко перемещать. Для переноса веб-сайта на новый сервер необходимо просто скопировать одну папку. Вам не нужно вносить какие-либо изменения в конфигурацию PHP или NGINX на новом сервере. Вам даже не нужно устанавливать PHP или NGINX на самом сервере. Они будут автоматически установлены Docker при запуске приложения.
Вы можете запустить точно такой же образна своей машине для разработки. Используя Vagrant, вы фактически запускаете копию конфигурации / установленных пакетов сервера на том же компьютере. С Docker на вашем ПК для разработки запускается тот же образ, что и на сервере.
php.iniщипки, nginx.confизменения конфигурации или обновления PHP до последней версии, обрабатывают так же, как загрузка обновлён PHP кода на сервере. Вы обновляете приложение, и неважно, меняет ли это PHP-код или обновляетесь php.ini.
Каждое изображение замкнуто в чём-то, что называется «контейнером». Скрипт PHP, запущенный в одном изображении, не может получить доступ к файлам, запущенным в другом. Думаю, open_basedirно гораздо строже. Контейнер похож на очень лёгкую виртуальную машину. Он действует как собственная операционная система, и код, работающий в контейнере, даже не знает, что он запущен внутри контейнера, не имея возможности видеть что-либо за пределами контейнера. Если один из ваших сценариев PHP небезопасен и даёт кому-то эффективный доступ к оболочке, они могут получить доступ только к файлам на сервере, к которому вы предоставили доступ контейнеру.
В отличие от виртуальной машины, если два разных веб-сайта находятся в совершенно разных контейнерах, но используют одни и те же версии NGINX или PHP, дисковое пространство и оперативная память распределяются между двумя контейнерами.
Поскольку каждое изображение является самодостаточным, переместить веб-сайт на другой сервер очень просто. Приложение не полагается на версию PHP, установленную на сервере, и ему всё равно, какие пакеты установлены на сервере. Если вы хотите переместить Dockerized-приложение на другой сервер, это так же просто, как скопировать все файлы веб-сайта и запустить приложение.
Вы можете запустить на сервере столько образов Docker, сколько захотите, каждый со своей собственной версией PHP, программным обеспечением веб-сервера, базой данных и связанными файлами.

Настройка

Это теория в стороне. Теперь давайте перейдём к созданию сервера с помощью Docker.

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

Если вы на Linux, вы должны установить dockerи docker-composeпакеты через менеджера пакетов вашего дистрибутива. В зависимости от вашего дистрибутива вам может потребоваться:

Добавьте своего пользователя в dockerгруппу.
Запустите dockerслужбу systemctl start docker.serviceи включите её с помощью systemctl enable docker.

Если вы используете Windows или macOS, установщик сделает это за вас.

Во-вторых, поскольку мы собираемся запустить веб-сервер внутри Docker и перенаправить некоторые порты, если у вас уже есть веб-сервер (Apache, NGINX, XAMPP, IIS и т.д.) Или MySQL, работающий на вашем компьютере, остановите их, прежде чем продолжить.

Веб-сервер обычно состоит из нескольких различных программ, таких как NGINX, PHP и MySQL. В терминологии Docker каждая программа, которую вы хотите установить, является службой.

В Docker есть несколько способов создания этих сервисов. Я расскажу о самом удобном для пользователя. Docker поддерживает создание файла конфигурации с использованием YAML (ещё один язык разметки).

Хотя вы можете ввести все параметры в командной строке, я рекомендую использовать файл конфигурации YAML по нескольким причинам:

Это намного легче читать / понимать.
Вам не нужно повторно вводить несколько длинных команд каждый раз, когда вы хотите запустить сервер.
Вы можете отслеживать изменения в файле с помощью Git.

docker-compose.yml для NGINX

Docker предоставляет инструмент под названием, docker-composeкоторый принимает файл конфигурации с именем docker-compose.ymlи запускает перечисленные в нём службы. Начнём с добавления веб-сервера NGINX.

Во-первых, создайте где-нибудь на вашем компьютере папку, в которой будет храниться ваш сайт. Вам нужно будет регулярно возвращаться в эту папку, поэтому помните, где она находится. Создайте docker-compose.ymlсо следующим содержимым:

version: '3'
services:
    web:
        image: nginx:latest
        ports:
            - "80:80"

Давайте посмотрим на конфигурацию по очереди:

version: '3'

Это указывает, docker-composeкакую версию спецификации YAML использовать. 3является последним, и разные версии имеют немного разные спецификации, ключевые слова и структуру.

За следующей строкой services:,, будет список всех служб, которые вы хотите запустить.

В нашем примере до сих пор webвызывается только одна служба (вы можете называть её как угодно) с использованием официального образа NGINX nginx:latest. Обратите внимание, что отступ с использованием пробелов (не табуляции!) Имеет значение. YAML полагается на уровень вложенности для определения структуры файла.

Если вы хотите указать другую версию NGINX, вы можете указать это здесь так:

version: '3'
services:
    web:
        image: nginx:1.18.0
        ports:
            - "80:80"

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

portsБлок устанавливает переадресацию портов. Он пересылает 80на локальный компьютер 80образ. Любой запрос на хост-машине http://127.0.0.1будет перенаправлен на сервер NGINX, работающий в контейнере.

Запуск службы

Чтобы запустить сервер, вам нужно открыть терминал в вашей операционной системе и указать в нём папку, содержащую ваш docker-compose.ymlфайл. В Windows 10 самый простой способ — использовать проводник (ранее известный как проводник Windows, и его не следует путать с Internet Explorer). Перейдите в папку, в которой находится ваш docker-compose.yml, затем щёлкните Файл, а затем откройте Windows Powershell. В Linux у большинства файловых менеджеров есть кнопка «Открыть терминал здесь» или аналогичная. В macOS вам сначала нужно включить эту опцию.

Как только ваш терминал будет открыт в правильном месте, введите docker-compose up. Вы должны увидеть результат, подобный изображению ниже.

Если вы получаете сообщения об ошибках, убедитесь, что Docker установлен и работает правильно. Если вы видите вывод, подобный приведённому выше, вы можете подключиться к серверу, посетив http://127.0.0.1 в своём браузере. Если он работает, вы увидите тестовую страницу NGINX, как показано на рисунке ниже.

Почему не Апач?

Прежде чем мы продолжим, вам может быть интересно, почему я здесь не использую Apache. Если вы использовали XAMPP или аналогичный пакет, то используемый вами веб-сервер — Apache. Веб-сервер — это часть сервера, которая слушает запросы веб-браузера и отправляет ему файлы.

Apache в порядке, и он работает, но он существует всегда. Когда был создан Apache, Интернет был совсем другим местом. Apache большой, и есть много разных функций, которые пришли и ушли, но которые Apache всё ещё поддерживает. Интернет сильно изменился с тех пор, как был создан Apache, и, хотя это мощный сервер и будет работать нормально, большинство веб-сайтов в наши дни, как правило, используют NGINX. Его легче настроить, он легче и лучше настроен для задач, которые используются на многих современных веб-сайтах (например, потокового видео), и поэтому его доля на рынке быстро растёт за счёт Apache.

Мой общий совет: если у вас уже есть веб-сайт, на котором запущен Apache, нет причин беспокоиться о его изменении, но если вы начинаете новый проект с нуля, используйте NGINX.

Размещение файлов на сервере

Теперь, когда сервер установлен и работает через Docker, мы можем сделать наши файлы видимыми на сервере. Если вы привыкли к Apache, вы бы поместили их в папку httpdocs, htdocsили publicгде-нибудь на вашем компьютере.

Поскольку сервер работает в контейнере, он не имеет доступа ни к одному из файлов на вашем компьютере. Однако Docker позволяет указать том — файл или папку на вашем компьютере, которые используются совместно с контейнером. Вам понадобятся два тома: nginx.confфайл конфигурации (который мы ещё не создали) и папка, в которой будут храниться файлы вашего сайта. Измените свой, docker-compose.ymlвключив два volumes:

version: '3'
services:
    web:
        image: nginx:latest
        ports:
            - "80:80"
        volumes:
            - ./nginx.conf:/etc/nginx/conf.d/nginx.conf
            - ./app:/app

Это делает файл nginx.confи appкаталог из той же папки, что и ваши, docker-compose.ymlдоступными в контейнере. Любые изменения, которые вы вносите в файлы в томах, немедленно изменяются в контейнере, и файлы становятся общими для них.

nginx.confФайл с хоста помещается в /etc/nginx/conf.d/nginx.confвнутри контейнера. Это папка, из которой NGINX читает файлы конфигурации. appПапка создаётся в корне контейнера /appи где вы будете размещать всё ваш сайт PHP скрипты, изображения и файлы JavaScript.

Перед перезапуском сервера создайте файл nginx.confв том же каталоге, что и ваш, docker-compose.ymlсо следующим содержимым:

server {
    listen 80 default_server;
    root /app/public;
}

Это сообщает NGINX, что это конфигурация, которую он должен использовать для сервера по умолчанию, и что он должен обслуживать файлы из каталога /app/public. Мы могли бы просто обслуживать файлы из /appкаталога, но рекомендуется держать большинство файлов PHP вне общедоступного каталога. Поскольку скрипты PHP должны будут загружать файлы../, мы поместим наш общедоступный каталог на один уровень ниже.

Чтобы проверить его работу, создайте страницу «Hello, World» на app/public/index.html, создавая каталоги по мере продвижения. Содержимое может быть таким:

<h1>Hello, World!</h1>

Перезагрузите сервер, вернувшись в терминал и нажав, ctrl-cчтобы остановить сервер, затем docker-compose upснова запустите команду, чтобы перезапустить его. (Вы можете нажать стрелку вверх, а затем Enterвместо того, чтобы вводить её повторно.)

Перезагрузите http://127.0.0.1 в своём браузере, и вы увидите сообщение Hello, World! тестовая страница. Теперь у вас есть рабочий веб-сервер, файлы которого обслуживаются по адресу http://127.0.0.1 из вашего app/publicкаталога.

PHP

Если вы хотите запускать сценарии PHP, вам необходимо добавить ещё одну службу для PHP в свой docker-compose.ymlи связать её с nginx:

version: '3'
services:
    web:
        image: nginx:latest
        ports:
            - "80:80"
        volumes:
            - ./nginx.conf:/etc/nginx/conf.d/nginx.conf
            - ./app:/app
    php:
        image: php:fpm
        volumes:
            - ./app:/app

Есть новый сервис php, использующий изображение php:fpm-latest. Для NGINX, вам необходимо использовать fpmпакет (FastCGI Process Manager), но вы можете выбрать любой PHP версии вам нравится — такие, как php:7.4-fpm, php:7.3-fpm, php:8.0-fpm. Если вы не укажете версию и используете только php:fpmее, будет использоваться последняя версия, которая на момент написания была 8.0.

Поскольку PHP потребуется доступ к вашим.phpфайлам из /appкаталога, вам необходимо смонтировать том в образе PHP так же, как вы это сделали для образа NGINX. PHP не требует доступа к nginx.confфайлу конфигурации, поэтому нет необходимости предоставлять ему доступ к нему.

appПапка теперь доступна на хост — машине, а в nginxи phpконтейнерах.

Перед перезапуском сервера docker-compose upнам необходимо настроить NGINX для запуска.phpфайлов через службу PHP. Откройте свой nginx.confи измените его на следующее:

server {
    listen 80 default_server;
    root /app/public;

    index index.php index.html index.htm;

    location ~ \.php$ {
        fastcgi_pass php:9000;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;     
    }
}

indexСтрока сообщает серверу искать index.phpвместо index.htmlкак страницу по умолчанию. locationБлок инструктирует NGINX запустить любой файл с.phpрасширением через службу PHP ( fastcgi_pass php:9000, где phpэто имя службы, сконфигурированной в docker-compose.yml).

Создайте phpinfoфайл по адресу app/public/index.php:

<?php
phpinfo();

Перезагрузите сервер, нажав ctrl-cна своем терминале, и повторно запустите docker-compose upкоманду. Если все настроено правильно, при посещении http://127.0.0.1 вы должны увидеть phpinfo()вывод:

Предполагая, что ваш веб-сайт использует MySQL, если вы просмотрите phpinfo()страницу, вы заметите, что драйвер PHP MySQL не установлен. Мы хотим установить пакет PDO на PHP.

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

Мы возьмем php:fpmза основу официальный образ и установим в него драйвер PDO MySQL. Это требует создания собственного имиджа, но это не так сложно, как кажется.

Во-первых, внесите изменения, docker-compose.ymlчтобы указать ему, что он должен создавать образ для PHP, а не использовать существующий php:fpmобраз:

version: '3'
services:
    web:
        image: nginx:latest
        ports:
            - "80:80"
        volumes:
            - ./nginx.conf:/etc/nginx/conf.d/nginx.conf
            - ./app:/app
    php:
        build:
            context: .
            dockerfile: PHP.Dockerfile
        volumes:
            - ./app:/app

Вместо imageзаписи, теперь buildвнизу есть строка php. contextДиректива является папка, файл конфигурации находится, что в нашем случае., текущий каталог (в той же папке в качестве нашего docker-compose.yml) и dockerfileэто имя файла, который мы будем использовать, чтобы построить свой имидж.

Создайте PHP.Dockerfileв той же папке, что и ваша, docker-compose.ymlи добавьте следующее:

FROM php:fpm

RUN docker-php-ext-install pdo pdo_mysql

Это установит pdo_mysqlрасширение для PHP. FROMДиректива говорит докер, что он должен использовать в php:fpmкачестве базового изображения и RUNдиректива используется для выполнения команд внутри изображения. Здесь вы можете запустить любую команду Linux. В этом случае мы запускаем docker-php-ext-installсценарий, который удобно предоставляется как часть официального пакета PHP и позволяет нам устанавливать расширения PHP.

Если вы хотите использовать библиотеку MySQLi ( хотя, вероятно, вам следует использовать PDO ), вы можете установить ее вместо или вместе с PDO:

FROM php:fpm

RUN docker-php-ext-install mysqli

Перезагрузите сервер с помощью docker-compose upкоманды. На этот раз вы увидите намного больше результатов, когда он построит изображение. Это произойдет только при первом запуске docker-compose up. Однако, если PHP.Dockerfileв будущем вы внесете какие-либо изменения, вам придется вручную перестроить его, выполнив команду docker-compose build.

Вы можете убедиться, что pdo_mysqlрасширение установлено, просмотрев phpinfo()вывод на http://127.0.0.1.

Пока мы устанавливаем расширения, давайте добавим xdebugрасширение для более удобных сообщений об ошибках на нашем сервере разработки:

FROM php:fpm

RUN docker-php-ext-install pdo pdo_mysql

RUN pecl install xdebug && docker-php-ext-enable xdebug

xdebugустанавливается через pecl, который предоставляется как часть официального образа PHP. Восстановите образ с помощью docker-compose build, затем перезапустите сервер с помощью docker-compose up. Вывод phpinfo()должен показать, что оба pdo_mysqlи xdebugустановлены.

MySQL

Теперь мы готовы установить MySQL. Еще раз, мы добавим его как службу в docker-compose.yml. Однако вместо установки официального образа MySQL мы будем использовать MariaDB, замену с потенциально лучшими будущими условиями лицензирования теперь, когда MySQL принадлежит Oracle. Если вы раньше использовали MySQL, MariaDB будет работать точно так же:

version: '3'
services:
    web:
        image: nginx:latest
        ports:
            - "80:80"
        volumes:
            - ./nginx.conf:/etc/nginx/conf.d/nginx.conf
            - ./app:/app
    php:
        build:
            context: .
            dockerfile: PHP.Dockerfile
        volumes:
            - ./app:/app
    mysql:
        image: mariadb:latest
        environment:
            MYSQL_ROOT_PASSWORD: 'secret'
            MYSQL_USER: 'tutorial'
            MYSQL_PASSWORD: 'secret'
            MYSQL_DATABASE: 'tutorial'
        volumes:
            - mysqldata:/var/lib/mysql
        ports:
            - 3306:3306
volumes:
    mysqldata: {}

Мы используем изображение mariadb:latest. Как и в случае с NGINX и PHP, при желании вы можете указать здесь конкретную версию MariaDB.

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

MYSQL_ROOT_PASSWORD: пароль root для базы данных. Вы можете использовать это для входа в систему rootи управления базой данных.
MYSQL_USERи MYSQL_PASSWORD: имя и пароль для пользователя MySQL, который создаётся с ограниченными правами. Вы захотите использовать это из своих сценариев PHP.
MYSQL_DATABASE: имя автоматически создаваемой схемы, к которой указанный выше пользователь имеет доступ.

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

Вы также заметите, что volumesвнизу есть запись. Это создаёт специальный тип тома, который не отображается в локальной файловой системе. Здесь будут храниться данные для MySQL — все ваши таблицы, записи и т.д.

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

Наконец, portsблок предоставляет порт 3306, чтобы мы могли подключиться к нему с помощью клиента, такого как MySQL Workbench, для управления базой данных. Я настоятельно рекомендую использовать это вместо PHPMyAdmin, если вы к этому привыкли, хотя вы можете поместить PHPMyAdmin в app/publicпапку и запустить его оттуда, если хотите.

Перезагрузите ваш сервер. На загрузку и настройку MariaDB в первый раз потребуется минута или две. Затем в сценарии PHP попробуйте подключиться к MySQL с PDO и выбранным вами именем пользователя, паролем и именем базы данных:

<?php
$pdo = new PDO('mysql:dbname=tutorial;host=mysql', 'tutorial', 'secret', [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]);

$query = $pdo->query('SHOW VARIABLES like "version"');

$row = $query->fetch();

echo 'MySQL version:' . $row['Value'];

Запустите этот сценарий на сервере. Если вы видите версию MySQL и сообщений об ошибках нет, вы подключены к серверу MySQL и все настроено правильно.

Выполнено!

Как вы только что обнаружили, Docker требует небольшой настройки, если вы делаете это самостоятельно. Если вы используете существующий docker-compose.ymlи конфигурационный файлы, это может быть всего пара команд.

Когда вы сделаете свой сайт жить, вы будете просто загрузить весь проект, в том числе docker-compose.yml, nginx.confи PHP.Dockerfileзапустите docker-compose up -dна сервере ( -dфлаг запускает его в качестве службы в фоновом режиме), и он будет работать точно такой же сайт, что вы видите на вашем машина разработки! Вам не нужно вручную настраивать и устанавливать PHP, MariaDB и NGINX на веб-сервере.

Как только вы освоите это, вы никогда не оглянетесь назад. Docker значительно упрощает процесс разработки веб-сайта, потому что все самодостаточно.

TL; DR! Просто отдай мне файлы!

Если вы просто хотите загрузить сервер с показанной здесь конфигурацией, выполните следующие действия:

Установите Docker.
Откройте терминал в папке, в которой вы хотите сохранить свой веб-сайт (используйте Файл> Открыть Powershell в Windows, чтобы открыть PowerShell в текущей открытой папке).
Запустите команду docker run -v ${PWD}:/git alpine/git clone git@github.com:sitepoint-editors/sitepoint-docker-tutorial.git.(последняя точка важна!).
Беги docker-compose up.
Перейдите на http://127.0.0.1.
Создавайте сценарии и файлы PHP в формате app/public.