Docker php ext configure
Docker, docker, docker. Было время, когда это слово звучало в каждой курилке разработчиков. Хайп вокруг докера уже подугас, однако он по-прежнему может быть полезен как для локальной среды, так и как production-ready решение. Но в посте речь пойдет именно о среде для локальной разработки.
Но для тех, кто не в курсе, на всякий случай:
Docker — программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы. Позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, который может быть перенесён на любую Linux-систему с поддержкой cgroups в ядре, а также предоставляет среду по управлению контейнерами. Изначально использовал возможности LXC, с 2015 года применял собственную библиотеку, абстрагирующую виртуализационные возможности ядра Linux — libcontainer. С появлением Open Container Initiative начался переход от монолитной к модульной архитектуре.
Что будет уметь наша сборка?
Простейшая среда разработки на php включает в себя следующие компоненты:
Также наша конфигурация будет поддерживать сколько угодно хостов nginx (см. проектов). Добавление новых компонентов в стек обычно не составляет труда, если это не заморская диковина конечно, но об этом позже.
Установка docker
Заострять внимание на процессе установки docker’а нет никакого смысла, на официальном сайте есть подробные мануалы по установке для всех популярных ОС:
Файловая структура
Переходим к организации папок и файлов нашей сборки. Создадим на диске какую-нибудь директорию, которая будет корневой для нашей сборки и в ней по порядку создаем следующие директории:
Собираем образ PHP
Стандартный официальный образ PHP не включает в себя никаких модулей, поэтому чтобы включить их нужно собрать свой образ на основе официального. Звучит немного страшновато, но на деле все просто. Создаем директорию для нашего образа images/php и в ней создаем файл Dockerfile следующего содержания:
Docker Compose
Конфигурация nginx для проектов
Run the magic!
В конце концов мы увидим заветные строчки:
Важно для windows и mac адрес 127.0.0.1 нужно заменить на адрес виртуальной машины, в которой запускается докер, потому что нативной поддержки пока нет или она очень унылая.
Итак, окрываем браузер и видим:
Разворачиваем связку Nginx+Php-Fpm+MySQL с magento2 на борту и раскладываем по контейнерам в Docker
Все чаще стучась в различные компании разработчиков в качестве DevOps инженера, я получаю приблизительно одни и те же тестовые задания. Они отличаются друг от друга версиями PHP или проектами которые надо запустить.
Но в целом они упираются в одну связку это Nginx\Appache, SQL (тут вариаций много, все зависит от предпочтений заказчика), PHP и желательно чтобы это было разложено по контейнерам.
Поэтому я решил рассказать на примере, как все это поднять без особых усилий.
Возможно кому-то это поможет понять, на простом примере, что к чему. Описывать что такое Docker я не буду, т.к. статей на эту тему вагон и маленькая тележка.
В данной статье, мы подготовим небольшую структуру:
Все зависит от системы в которой вы хотите работать, в отношении кроссплатформенности, docker приятно удивляет (один и тот же файл конфигурации позволяет собрать и запустить контейнеры на любой системе *nix, Win, iOS).
Для Linux (к примеру в CentOS)
Включаем и стартуем сервис:
Чтобы наша структура создавалась одной командой нам потребуется docker-compose.
Для начала поставим необходимые для него компоненты:
Дальше устанавливаем docker-compose и обновляем python:
(или # pip install docker-compose)
Для Win систем (многие считают это извращением)
Но если вы решили, настоятельно рекомендую вам это делать на версии которая поддерживает Hyper-V (например win10 Prof).
Включаем компонент Hyper-V в «Включении и отключении компонентов Windows» (Turn Windows features on or of).
Скачиваем установщик с оф.сайта докера и устанавливаем. Также, дополнительно вы можете поставить GUI (Kitematiс) для наглядного отображения.
Приступим к созданию окружения:
Для начала создадим под этот проект папку и заходим в нее:
Дальше строим структуру папок таким образом:
Создаем понятную среду для nginx:
MySQL — в этой папке будут храниться базы. Удобно бэкапить и переносить.
Nginx — тут будут храниться логи, файл конфигурации и наш проект.
PHP — сюда мы сложим Dockerfile с настройками и php.ini.
в корне (в нашем случе папка /mage) будет лежать файл docker-compose.yml.
Создадим конфигурационный файл для Nginx:
Можно использовать любой другой редактор. Если его нет — можно установить с помощью:
И добавляем в nginx.conf следующее:
Во втором блоке прописываем параметры fastcgi.
Третий блок нужен для решения проблемы отображения, в проекте показывалась пустая страница. Из документации вычитал что magento2 требует реврайтинга. (на других проектах таким проблем не возникало).
В папке www создаем каталог для нашего проекта:
Скачиваем с оф.сайта magento2
и извлекаем из архива в папку /mage/Nginx/www/magento2
C настройками для Nginx мы закончили.
Теперь займемся PHP:
Начнем с Dockerfile
Это нужно, чтобы мы могли использовать те модули, которые нужны именно под этот проект.
В этом файле мы рассказали что должно быть установленно в этом образе, а так же указали где будет располагаться корневая директория и куда скопировать настройки из php.ini
Теперь настроим php.ini:
Это взято из php.ini.sample который предлагают сами разработчики Magento2. Нечего сверхъестественного я в него не добавлял.
Все, на этом настройка PHP закончена.
Дальше создаем файл docker-compose который нам все соберет в одну удобную систему.
Тут мы распишем какие сервисы и с какими настройками должны запуститься:
И по экрану побегут строчки, а вы спокойно можете налить себе кружечку горячего кофе, пока машина будет работать за вас.
После установки, у вас в папке MySQL, создастся много файлов и папок, одна из которых будет magento2, а в папке Nginx/Logs появятся 2 лога.
Открыв браузер и набрав там localhost вы должны увидеть приглашение к установке Magento2.
Если все таки что-то не получилось, то возможно этот список решений, сможет вам помочь:
1) Версия docker-compose файла не подошла, тогда нужно поправить «version: ‘3.3’», посмотреть какая именно подойдет вам можно тут
2) Все нормально запустилось, но браузер открывает чистую страницу, без единой ошибки — поможет строчка в nginx.conf
3) Если после установки самой Magento2 (в браузере) у вас не прорисовываются фреймы и все выглядит как текстовый вариант сайта, вам нужно сделать следующее:
3.1 в SQL, советую зайти через phpmyadmin localhost:8090 логин root пароль mypassword, выбрать базу magento2 и ввести sql запрос
3.2 подключиться к контейнеру c PHP (php-fpm) и набрать
Он должен пересчитать и проверить все. И после этого все корректно должно отображаться.
4.1 в линуксе надо отключить политику защиты
Отключение до перезагрузки
или отключение навсегда
4.2 В windows нужно в настройках docker выбрать shared drivers и выбрать диск на котором у вас лежит проект. После перезапуска Docker проблема уйдет.
Разработка под Docker. Локальное окружение. Часть 2 — Nginx+PHP+MySql+phpMyAdmin
Для лучшего понимания нижеследующего материала сначала рекомендуется ознакомится с Предыдушим постом
Рассмотрим пример развертки локального окружения состоящего из связки Nginx+PHP+MySql+phpMyAdmin. Данная связка очень популярна и может удовлетворить ряд стандартных потребностей рядового разработчика.
Как и в прошлом посте акцент будет смещен в сторону утилиты docker-compose, чем докера в чистом виде.
Итак, поехали!
Начнем вот с такого docker-compose.yml, который лежит в отдельной папке proxy:
В представленном файле описана конфигурация для создания одного контейнера с именем proxy на базе образа image: jwilder/nginx-proxy и создание сети с одноименным именем. Директива networks указывает к каким сетям подключен контейнер, в данном примере, это наша сеть proxy.
При создание сети директиву driver: bridge можно было бы и не указывать. Драйвер типа «мост» является драйвером по умолчанию. Данный контейнер будет связываться по сети с прочими контейнерами.
Образ jwilder/nginx-proxy является базовым и взят и Docker Hub там же представлено довольно обширное и подробное описание по его использованию. Принцип работы nginx-proxy довольно простой, он через пробрасываемый сокет докера получает доступ к информации о запущенных контейнерах, анализирует наличие переменной окружения с именем VIRTUAL_HOST и перенаправляет запросы с указанного хоста на контейнер, у которого данная переменная окружения задана.
Данный вывод информирует нас о том, что в начале была создана сеть proxy_proxy, а затем был создан контейнер proxy_proxy_1. Имя сети получилось из названия папки, в которой размещался файл docker-compose.yml, у меня это proxy и одноименного имени сети.
Если ввести команду docker network ls, то мы увидим список сетей докера в нашей системе и одна из них должна быть proxy_proxy.
Имя контейнера строиться по аналогичному принципу имя папки плюс название сервиса и число, которое позволяет, чтобы контейнеры со схожими именами не дублировались. Через директиву container_name можно задать имя контейнера явно, но я считаю это довольно бесполезной функцией. Подробнее пойдет речь об этом в следующих постах.
Создаем второй docker-compose.yml следующего содержания:
Что тут у нас объявлено?
Перечислены четыре сервиса: nginx, php, mysql и phpmyadmin. И две сети. Одна сеть прокси с именем frontend, объявлена как внешняя сеть и новая внутренняя сеть backend. Драйвер для нее не указан, как и писал ранее, будет использоваться драйвер по умолчанию типа bridge.
nginx
Тут примерно должно быть все понятно. Используем базовый образ с докер хаб. Переменная окружения необходима для работы прокси и сообщает ему, по какому адресу должен быть доступен контейнер. Опция depends_on указывает, на зависимость данного контейнера от контейнера php. Это означает, что вперед будет запущен контейнер php, а после него будет выполнен запуск зависимого от него контейнера nginx. Далее пробрасываем конфигурацию для нашего nginx. Она будет чуть ниже и монтируем папку с html. Так же замечаем, что контейнер имеет доступ сразу к двум сетям. Он должен связываться и прокси из сети frontend и с php из сети backend. В принципе, можно было бы все контейнеры и в одну сеть frontend попихать, но я придерживаюсь, что подобное разделение более верное.
default.nginx — это конфиг для nginx, который пробрасывается в контейнер. Ключевой момент тут директива fastcgi_pass php:9000. Она задает адрес FastCGI-сервера. Адрес может быть указан в виде доменного имени или IP-адреса, и порта.
php:9000 — имя сервиса это и есть адрес FastCGI-сервера. Nginx обращаясь по адресу php будет получать IP-адрес контейнера, в котором работает php. Порт 9000 это стандартный порт, он объявлен при создание базового контейнера. Данный порт доступен для nginx по сети, но не доступен на хостовой машине, так как не был проброшен.
Тут необычно то, что не указан образ. Вместо этого происходит сборка собственного образа прямо из compose-файла. Директива context указывает на папку, в которой находится Dockerfile.
В Dockerfile указано, что для сборки используется базовый образ php:7.3.2-fpm, далее выполняется запуск команд для установки php-расширений. Далее копируется composer из другого базового образа и устанавливается рабочая директория для проекта. Детальнее вопросы сборки рассмотрю в других постах.
Также во внутрь контейнера пробрасывается файл php.ini и папка html с нашим проектом.
Заметим, что php находится в сети backend и к примеру прокси к нему доступ получить уже не может.
mysql
База находится в сети backend, что позволяет ей держать связь с php. В базовом образе используется стандартный порт 3306. Он доступен по сети докера для php, но не доступен на хостовой машине. Если выполнить проброс для данного порта, то можно к нему коннектиться к примеру из того же PHPSTORM. Но если вам достаточно интерфейса phpmyadmin, то этого можно и не делать.
phpmyadmin
Официальный образ phpmyadmin. В переменных окружения используется VIRTUAL_HOST для взаимодействия с прокси, аналогично nginx. PMA_USER и PMA_PASSWORD доступ к базе. И PMA_HOST сам хост базы. Но это не localhost, как обычно бывает, а mysql. Т.е. связь с базой доступна по имени ее сервиса, т.е. mysql. Контейнер phpmyadmin может связаться с базой, т.к имеет подключение к сети backend.
Видим следующий вывод:
Видим, что в начале происходит создание сети lesson2_backend, затем сборка образа php, потом может происходить скачивание образов, которых еще нет в системе (pull) и собственно запуск описанных сервисов.
Последний штрих, чтобы все заработало это добавление в hosts или доменов site.local и phpmyadmin.local.
Содержимое index.php может быть следующим:
Тут мы проверяем корректность подключения расширения php — mysqli, которое было добавлено при сборке Dockerfile.
И заметим, что для связи с контейнером используется название сервиса — mysql.
Структура всего проекта получилась следующей:
Настройка среды разработки PHP с помощью Docker
В этом руководстве я расскажу, как лучше всего приступить к настройке среды разработки PHP, и расскажу, как настроить Docker. Существует так много способов настроить среду разработки PHP, но использование Docker — это лучшая практика.
Я начну с краткой истории того, как люди настраивали свою среду разработки 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:
Легко понять, зачем это нужно разработчикам. Сделав следующий шаг к Docker, мы сохраним эти преимущества, избегая при этом некоторых недостатков сред Vagrant / Virtual Machine.
Что не так с Vagrant?
Несмотря на преимущества, среда разработки на основе Vagrant вводит свой собственный набор ограничений и проблем.
Хотя точки 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 с собственными конфигурациями.
У этого есть небольшие накладные расходы на память, но предоставляемая им гибкость делает это очень полезным компромиссом:
Настройка
Это теория в стороне. Теперь давайте перейдём к созданию сервера с помощью Docker.
Прежде чем мы начнём, вам необходимо скачать и установить Docker. Перейдите на сайт Docker, затем загрузите и установите его для своей операционной системы.
Если вы на Linux, вы должны установить dockerи docker-composeпакеты через менеджера пакетов вашего дистрибутива. В зависимости от вашего дистрибутива вам может потребоваться:
Если вы используете Windows или macOS, установщик сделает это за вас.
Во-вторых, поскольку мы собираемся запустить веб-сервер внутри Docker и перенаправить некоторые порты, если у вас уже есть веб-сервер (Apache, NGINX, XAMPP, IIS и т.д.) Или MySQL, работающий на вашем компьютере, остановите их, прежде чем продолжить.
Веб-сервер обычно состоит из нескольких различных программ, таких как NGINX, PHP и MySQL. В терминологии Docker каждая программа, которую вы хотите установить, является службой.
В Docker есть несколько способов создания этих сервисов. Я расскажу о самом удобном для пользователя. Docker поддерживает создание файла конфигурации с использованием YAML (ещё один язык разметки).
Хотя вы можете ввести все параметры в командной строке, я рекомендую использовать файл конфигурации YAML по нескольким причинам:
docker-compose.yml для NGINX
Docker предоставляет инструмент под названием, docker-composeкоторый принимает файл конфигурации с именем docker-compose.ymlи запускает перечисленные в нём службы. Начнём с добавления веб-сервера NGINX.
Во-первых, создайте где-нибудь на вашем компьютере папку, в которой будет храниться ваш сайт. Вам нужно будет регулярно возвращаться в эту папку, поэтому помните, где она находится. Создайте docker-compose.ymlсо следующим содержимым:
Давайте посмотрим на конфигурацию по очереди:
Это указывает, docker-composeкакую версию спецификации YAML использовать. 3является последним, и разные версии имеют немного разные спецификации, ключевые слова и структуру.
За следующей строкой services. будет список всех служб, которые вы хотите запустить.
В нашем примере до сих пор webвызывается только одна служба (вы можете называть её как угодно) с использованием официального образа NGINX nginx:latest. Обратите внимание, что отступ с использованием пробелов (не табуляции!) Имеет значение. YAML полагается на уровень вложенности для определения структуры файла.
Если вы хотите указать другую версию NGINX, вы можете указать это здесь так:
Я рекомендую использовать, 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:
Это делает файл nginx.confи appкаталог из той же папки, что и ваши, docker-compose.ymlдоступными в контейнере. Любые изменения, которые вы вносите в файлы в томах, немедленно изменяются в контейнере, и файлы становятся общими для них.
nginx.confФайл с хоста помещается в /etc/nginx/conf.d/nginx.confвнутри контейнера. Это папка, из которой NGINX читает файлы конфигурации. appПапка создаётся в корне контейнера /appи где вы будете размещать всё ваш сайт PHP скрипты, изображения и файлы JavaScript.
Перед перезапуском сервера создайте файл nginx.confв том же каталоге, что и ваш, docker-compose.ymlсо следующим содержимым:
Это сообщает NGINX, что это конфигурация, которую он должен использовать для сервера по умолчанию, и что он должен обслуживать файлы из каталога /app/public. Мы могли бы просто обслуживать файлы из /appкаталога, но рекомендуется держать большинство файлов PHP вне общедоступного каталога. Поскольку скрипты PHP должны будут загружать файлы../, мы поместим наш общедоступный каталог на один уровень ниже.
Чтобы проверить его работу, создайте страницу «Hello, World» на app/public/index.html, создавая каталоги по мере продвижения. Содержимое может быть таким:
Перезагрузите сервер, вернувшись в терминал и нажав, ctrl-cчтобы остановить сервер, затем docker-compose upснова запустите команду, чтобы перезапустить его. (Вы можете нажать стрелку вверх, а затем Enterвместо того, чтобы вводить её повторно.)
Перезагрузите http://127.0.0.1 в своём браузере, и вы увидите сообщение Hello, World! тестовая страница. Теперь у вас есть рабочий веб-сервер, файлы которого обслуживаются по адресу http://127.0.0.1 из вашего app/publicкаталога.
Если вы хотите запускать сценарии PHP, вам необходимо добавить ещё одну службу для PHP в свой docker-compose.ymlи связать её с nginx:
Есть новый сервис 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и измените его на следующее:
indexСтрока сообщает серверу искать index.phpвместо index.htmlкак страницу по умолчанию. locationБлок инструктирует NGINX запустить любой файл с.phpрасширением через службу PHP ( fastcgi_pass php:9000, где phpэто имя службы, сконфигурированной в docker-compose.yml).
Создайте phpinfoфайл по адресу app/public/index.php:
Предполагая, что ваш веб-сайт использует MySQL, если вы просмотрите phpinfo()страницу, вы заметите, что драйвер PHP MySQL не установлен. Мы хотим установить пакет PDO на PHP.
Это немного сложнее, так как нам нужно установить пакеты в образе. К счастью, официальный образ PHP содержит сценарий для этого.
Мы возьмем php:fpmза основу официальный образ и установим в него драйвер PDO MySQL. Это требует создания собственного имиджа, но это не так сложно, как кажется.
Во-первых, внесите изменения, docker-compose.ymlчтобы указать ему, что он должен создавать образ для PHP, а не использовать существующий php:fpmобраз:
Вместо imageзаписи, теперь buildвнизу есть строка php. contextДиректива является папка, файл конфигурации находится, что в нашем случае., текущий каталог (в той же папке в качестве нашего docker-compose.yml) и dockerfileэто имя файла, который мы будем использовать, чтобы построить свой имидж.
Создайте PHP.Dockerfileв той же папке, что и ваша, docker-compose.ymlи добавьте следующее:
Это установит pdo_mysqlрасширение для PHP. FROMДиректива говорит докер, что он должен использовать в php:fpmкачестве базового изображения и RUNдиректива используется для выполнения команд внутри изображения. Здесь вы можете запустить любую команду Linux. В этом случае мы запускаем docker-php-ext-installсценарий, который удобно предоставляется как часть официального пакета PHP и позволяет нам устанавливать расширения PHP.
Если вы хотите использовать библиотеку MySQLi ( хотя, вероятно, вам следует использовать PDO ), вы можете установить ее вместо или вместе с PDO:
Перезагрузите сервер с помощью docker-compose upкоманды. На этот раз вы увидите намного больше результатов, когда он построит изображение. Это произойдет только при первом запуске docker-compose up. Однако, если PHP.Dockerfileв будущем вы внесете какие-либо изменения, вам придется вручную перестроить его, выполнив команду docker-compose build.
Вы можете убедиться, что pdo_mysqlрасширение установлено, просмотрев phpinfo()вывод на http://127.0.0.1.
Пока мы устанавливаем расширения, давайте добавим 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 будет работать точно так же:
Мы используем изображение mariadb:latest. Как и в случае с NGINX и PHP, при желании вы можете указать здесь конкретную версию MariaDB.
На этот раз есть environmentблок, который используется для передачи некоторых переменных в контейнер при его создании. Они используются для настройки базы данных со следующими параметрами. Задайте свои собственные значения для следующих переменных:
В приведённом выше примере создаётся база данных с именем tutorial, доступ к которой можно получить с помощью пользователя tutorialи пароля secret.
Вы также заметите, что volumesвнизу есть запись. Это создаёт специальный тип тома, который не отображается в локальной файловой системе. Здесь будут храниться данные для MySQL — все ваши таблицы, записи и т.д.
Причина, по которой мы не хотим использовать папку в локальной файловой системе, заключается в том, что когда приложение загружается на реальный веб-сервер, вы не хотите перезаписывать реальную базу данных тестовой. Здесь будут храниться все ваши записи среды тестирования / разработки. Это позволяет вам иметь разные базы данных на реальном сервере и сервере разработки, когда вы загружаете свой веб-сайт.
Наконец, portsблок предоставляет порт 3306, чтобы мы могли подключиться к нему с помощью клиента, такого как MySQL Workbench, для управления базой данных. Я настоятельно рекомендую использовать это вместо PHPMyAdmin, если вы к этому привыкли, хотя вы можете поместить PHPMyAdmin в app/publicпапку и запустить его оттуда, если хотите.
Перезагрузите ваш сервер. На загрузку и настройку MariaDB в первый раз потребуется минута или две. Затем в сценарии PHP попробуйте подключиться к MySQL с PDO и выбранным вами именем пользователя, паролем и именем базы данных:
Запустите этот сценарий на сервере. Если вы видите версию MySQL и сообщений об ошибках нет, вы подключены к серверу MySQL и все настроено правильно.
Выполнено!
Как вы только что обнаружили, Docker требует небольшой настройки, если вы делаете это самостоятельно. Если вы используете существующий docker-compose.ymlи конфигурационный файлы, это может быть всего пара команд.
Как только вы освоите это, вы никогда не оглянетесь назад. Docker значительно упрощает процесс разработки веб-сайта, потому что все самодостаточно.
TL; DR! Просто отдай мне файлы!
Если вы просто хотите загрузить сервер с показанной здесь конфигурацией, выполните следующие действия: