Запуск PHP приложения на Docker контейнерах (PHP-FPM, Nginx, PostgreSQL)
За последний год программное обеспечение для автоматизации развертывания в среде виртуализации на уровне операционной системы набирает большие обороты. Эта статья послужит новичкам в этой сфере примером, как нужно упаковывать свое приложение в Docker контейнеры.
В классическом виде, PHP приложение представляет из себя следующие составляющие:
1. Установка Docker
Для начала работы, нам потребуется Docker. Скачать его можно на официальном сайте Docker.
2. Создание образов
Docker создает образы на основе DockerFile файлов, в котором описывается функционал. Мы создадим 3 образа для наших составляющих.
DockerFileNginx
В данном DockerFile мы создаем пользователя www-data с группой 82 и устанавливаем Nginx. Последняя строка COPY предполагает, что у вас конфигурация приложения лежит в папке config/website.conf. Она скопируется в /etc/nginx/conf.d/website.conf.
DockerFilePostgresql
В этом образе, мы будем отталкиваться от образа postgres:9.5.2 и выполним команду для определения локали и языка.
DockerFile
Этот образ послужит нам основным образом для нашего приложения. Сначала мы устанавливаем все необходимое для PHP и PHP-FPM. Далее, мы копируем текущую папку приложения в /usr/src/app, где будет распологаться наше приложение. В самом конце мы запускаем PHP-FPM.
Создание образов на основе DockerFile’ов
И так, у нас есть есть DockerFile’ы, на основе которых мы должны создать образы. Образы создаются очень просто. Достаточно выполнить следующие команды:
Мы создаем образы, прикрепляем их к нашему аккаунту на Docker Hub. Теперь, нам нужно отправить наши образы на репозиторий в Docker Hub. Выполняем следующие команды:
Запуск образов на сервере
Мы почти у цели! Нам осталось загрузить образы из репозитория и запустить их. Загружаем их с помощью следующих команд:
Осталось их запустить. Делается это так же просто.
Вуаля! Наше приложение запущено на Docker контейнерах. И тем не менее, всем читателям-новичкам я бы обязательно ознакомиться с документацией Docker.
Всем желаю успехов в освоении новых технологий!
giansalex / docker-php-ext-install.md
This comment has been minimized.
Copy link Quote reply
telepresencebot2 commented Jan 20, 2019
This comment has been minimized.
Copy link Quote reply
mahavirhirani commented Dec 10, 2019
This comment has been minimized.
Copy link Quote reply
AlekseyBusarev commented Dec 22, 2019
Replace from mysql-client to mariadb-client for php:7.1-apache. It’s works for me.
Thanks. It’s the really helpful note.
This comment has been minimized.
Copy link Quote reply
guazontsubasa commented Apr 10, 2020 •
This comment has been minimized.
Copy link Quote reply
giansalex commented Apr 10, 2020
This comment has been minimized.
Copy link Quote reply
ivano9 commented Dec 1, 2020 •
Openssl extension are supported by the docker-php-ext?
This comment has been minimized.
Copy link Quote reply
giansalex commented Dec 1, 2020
@ivano9 openssl is included in base image.
This comment has been minimized.
Copy link Quote reply
joaomarcosmareto commented Jan 22, 2021
Can anyone provide the code to get the cas extension php-cas?
This comment has been minimized.
Copy link Quote reply
DurandSacha commented Apr 9, 2021
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
PHP Extension «APCu» Not Installed #78
Comments
pdhimal1 commented Sep 19, 2017
Installing the «APCu» PHP extension will improve performance. This extension is strongly recommended. Without it, Phabricator must rely on a very inefficient disk-based cache.
I followed the steps in here https://docs.bitnami.com/virtual-machine/components/php/#how-to-install-the-apcu-module to install APCu on my bitnami phabricator container.
Added the following to my custom app-entrypoint.sh
I get this PHP warning which tells me that APCu is not configured correctly.
PHP Extension «APCu» Not Installed still shows up as a setup issue on phabricator.
The text was updated successfully, but these errors were encountered:
We are unable to convert the task to an issue at this time. Please try again.
The issue was successfully created but we are unable to update the comment at this time.
pdhimal1 commented Sep 19, 2017
Now look at the warning message:
It looks like the shared extension is being installed in /opt/bitnami/php/lib/php/extensions/no-debug-non-zts-20160303/ directory. PHP is trying to load the library from /opt/bitnami/php/lib/php/extensions/
chipironcin commented Sep 28, 2017
Hi @pdhimal1
I have checked and I was able to reproduce and narrow down the issue.
We are working on a fix and will release a PHP revision fixing this issue, and maybe include APCU by default but disabled so Phabricator can easily enable it. Subscribe to this repo to get updates.
pdhimal1 commented Oct 31, 2017
@chipironcin Thanks for looking at this.
Any updates?
chipironcin commented Nov 4, 2017
Hi @pdhimal1
I filed an internal issue and worked on it for a bit but haven’t fixed it yet.
The issue has been bumped, we will try to fix it shortly.
pdhimal1 commented Apr 27, 2018
@chipironcin Were you guys able to fix this issue? Updates?
juan131 commented Apr 30, 2018
We have at task included in our backlog. As the impact of the issue is moderate, there are no immediate plans to work on it. Nevertheless it will be considered for future application versions.
We will update this thread as soon as we have more news.
marcosbc commented Jun 26, 2018 •
Sorry for the delay on this. We have downloaded the latest Phabricator container, followed the steps below and were unable to reproduce your previous issue: APCu was properly installed, as it may have been fixed in later versions of our PHP containers.
Please find the exact same steps we followed:
Do you get different results? If so, which Phabricator container version are you using? Could you check with the latest version?
We still haven’t started working on adding APCu to our products by default (without requiring to compile it for yourself), but it is in our pipeline.
marcosbc commented Jul 5, 2018
Just wanted to let you know that we released a new revision of the Bitnami Phabricator Docker image, which now includes APCu enabled by default.
The version numbers are 2018.25.0-r6 (Debian) and 2018.25.0-ol-7-r10 (Oracle Linux).
adarshaj commented Aug 16, 2018 •
marcosbc commented Aug 16, 2018
Hi @adarshaj, we have reopened this issue until your issue is resolved.
Your issue is really strange, since we ran the following docker-compose setup and everything was correct:
After the container started, we were able to confirm that APCu was loaded:
With the following command, you will see that APCu exists:
In addition to the above, when we access that same Phabricator installation’s Setup Issues, we don’t see any reference to APCu not being installed.
Could you provide more details for reproducing this issue in a clean envirnoment? Could it be possible that you were using an outdated image?
adarshaj commented Aug 16, 2018
adarshaj commented Aug 16, 2018
pecl install apcu fails on php7.2-apache stretch image #536
Comments
DepGr commented Dec 10, 2017
The text was updated successfully, but these errors were encountered:
We are unable to convert the task to an issue at this time. Please try again.
The issue was successfully created but we are unable to update the comment at this time.
DepGr commented Dec 10, 2017
tianon commented Dec 10, 2017
I can’t seem to reproduce: 😕
DepGr commented Dec 11, 2017
Thank you for quick reply. i redid the test but i still get the same error.
The image I used is : php:7.2.0RC3-apache
and here is the error message:
pecl install APCu-5.1.8
No releases available for package «pecl.php.net/APCu»
install failed
DepGr commented Dec 11, 2017
Thanks a lot and sorry for bothering
DepGr commented Dec 13, 2017
yosifkit commented Dec 13, 2017
What are you apt-get installing? If you are installing something php-apcu it will probably not work with the php that is installed in the image, since it is compiled from source while the package is specific to the Debian provided php7.0 package.
I will say to use a newer version since 7.2.0RC6-apache is available. I did just pull and try on php:7.2.0RC3-apache and RC6 and both had the same output that @tianon gave above.
DepGr commented Dec 14, 2017
Runrioter commented Dec 14, 2017
There is something wrong with pecl. When I install memcached & redis, I alse get this errors:
DepGr commented Dec 14, 2017
Runrioter commented Dec 14, 2017
@DepGr Maybe you are right.
In fact, it worked well before.
When I saw this message :
tianon commented Dec 23, 2017
I still cannot reproduce, so this is definitely something related to your environment or local configuration (and not the PHP image), so I’m going to close this issue.
For further help debugging, I’d recommend posting to the Docker Community Forums, the Docker Community Slack, or Stack Overflow. Thanks!
Docker + php-fpm + PhpStorm + Xdebug
Не так давно тимлид нашей команды сказал: ребята я хочу, чтобы у всех была одинаковая среда разработки для наших боевых проектов + мы должны уметь дебажить всё — и web приложения, и api запросы, и консольные скрипты, чтобы экономить свои нервы и время. И поможет нам в этом docker.
Поэтому, давайте уточним условия задачи:
На боевых серверах используется стандартная связка nginx + php-fpm + mysql. И, в чем проблема?
Разворачиваем на локальной машине точно такое же окружение + Xdebug, настраиваем наши проекты в PhpStorm, работаем. Для дебага включаем «трубку» в PhpStorm, всё работает из коробки, всё замечательно.
Всё это действительно так — всё работает из коробки. Но, давайте попробуем заглянуть под капот нашего рабочего окружения.
Nginx + php-fpm общаются через сокет, xdebug слушает порт 9000, PhpStorm тоже, по умолчанию, слушает порт 9000 для дебага и всё вроде бы замечательно. А если у нас открыто несколько приложений в PhpStorm, и включена прослушка («трубка)» для нескольких приложений? Что сделает PhpStorm? Он начнет ругаться, что обнаружено новое подключение для Xdebug, вы хотите его игнорировать, или нет?
Т.е., при настройках по умолчанию в PhpStorm, в конкретный момент времени, я могу дебажить только одно приложение. У всех других открытых приложений дебаг должен быть выключен. Блин, но это же неудобно. Я хочу слушать для дебага все приложения, и если в каком-то из них стоит точка останова, то я хочу, чтобы PhpStorm остановился в этом приложении, на той строке, где мне нужно.
А что для этого нужно? А нужно, чтобы каждое приложение запускалось со своими настройками для Xdebug. Чтобы каждое приложение слушало свой порт, искало свой сервер, а не так, как у нас всё общее, всё в одной куче.
А для этого есть замечательный докер! Мы можем запустить каждое наше боевое приложение в отдельном контейнере, на основе одного общего образа, например, php:7.1-fpm. Благодаря технологии докера мы можем изолировать наши приложения, при минимальных накладных расходах.
Ок, давайте заведем наши боевые проекты под докер, запустим каждый проект в отдельном контейнере, настроим каждый проект в PhpStorm для дебага индивидуально, всё должно быть замечательно.
Костылим, вот пример образа php:7.1-fpm, который будет собираться.
Update
Как справедливо указало сообщество — совсем уж жестко костылить всё-таки не надо.
Например хаброюзер 1ntrovert в своем комментарии
Поправленный пример Dockerfile
При запуске контейнера из данного образа пользователь www-data получает uid=1000, gid=1000. Обычно такие права у первого созданного пользователя в операционной системе Линукс. И, именно с такими правами будут работать наши php-fpm контейнеры. Буду очень благодарен, если кто-то подскажет как можно работать без костылей с правами доступа в докер.
При запуске контейнера из данного образа пользователь www-data получает uid и gid, которые будут переданы извне.
Также в комментариях поднималась тема: зачем вообще менять права пользователю www-data, чем не устраивают стандартные права 33. Только одним: когда мы зайдем в контейнер, и создадим, например, файл миграции, то на машине хоста владельцем этого файла будем не мы. И каждый раз надо будет запускать что-то вроде
И вторая небольшая проблема: для корректной работы Xdebug необходимо прописать верный ip адрес для машины хоста. У каждого члена команды он разный. 127.0.0.1 не катит. И тут нам на помощь приходит сам докер. Например, мы можем явно сконфигурировать сеть — 192.168.220.0/28. И тогда наша машина всегда будет иметь адрес 192.168.220.1. Этот адрес мы будем использовать как для настройки PhpStorm, так и для настройки других приложений. Например, при работе с MySql.
Сам docker-compose.yml, после учета замечаний, выглядит так:
Мы видим, что в данном конфиге создаются два контейнера php71-first и php71-two, на основе одного образа php:7.1-fpm. У каждого контейнера свои настройки для Xdebug. Каждый отдельно взятый контейнер будет слушать, для дебага, свой порт и свой сервер.
Также, обращаю ваше внимание на директивы
Без этих переменных образ php-fpm не запустится. Вопрос: как их передать в docker-compose.yml? Ответ: так как удобнее вам. Можно при запуске:
Полный код для демо версии выложен на гитхабе.
Листинг демо проекта:
Пробежимся, кратко, по листингу проекта.
Каталог hosts — конфигурационные файлы для Nginx. В каждом конфиге прописан свой контейнер php-fpm. Пример:
Каталог images — инструкции для сборки образов php-fpm, каталог mysql — храним базы, каталог www — все наши web проекты, в нашем примере first.loc и two.loc.
Давайте подведем промежуточные итоги: используя возможности докера мы запустили все свои рабочие проекты в одном окружении. Все наши проекты видят друг друга, для каждого из проектов прописаны уникальные настройки для Xdebug.
Осталось корректно настроить PhpStorm для каждого из проектов. При настройке мы должны прописать порт для дебага и имя сервера в нескольких местах.
Создаем проект в PhpStorm
Настраивать будем разделы меню
— PHP (необходимо верно прописать CLI Interpreter),
— Debug (меняем порт на 9008, как в файле docker-compose.yml),
— DBGp proxy (IDE key, Host, Port),
update Спасибо хаброюзеру CrazyLazy за важное замечание. Пункт меню DBGp proxy настраивать не надо.
— Servers (необходимо верно указать имя сервера, как в файле docker-compose.yml, и use path mappings)
Все дальнейшие скрины буду прятать под спойлер.
Хитрого ничего нет — важно, при настройке выбрать нужный образ, и верно прописать имя сервера. По умолчанию имя сервера Docker, у нас оно своё.
Опять же всё прописываем из настроек docker-compose.yml для конкретного контейнера. На этом же шаге валидируем как работает наш дебаг.
Важно правильно прописать use path mappings, имя сервера опять же берем из настроек
Сервер выбираем наш, созданный на предыдущем шаге.
Ну, собственно и всё. Написано много букв, вроде бы всё непросто
На самом деле — главное понять очень простую вещь. Благодаря технологии докера мы можем запустить все наши рабочие приложения в едином пространстве, но с разными настройками для Xdebug. Каждое приложение работает в своем контейнере, и нам остаётся аккуратно прописать настройки для каждого приложения в PhpStorm.
И на выходе мы получаем чудесную картину.
2. Прописываем узлы first.loc и two.loc в файле /etc/hosts
4. Настраиваем оба проекта first.loc и two.loc в PhpStorm, так как описано выше, и запускаем оба проекта в PhpStorm. Т.е. у нас открыто два окна PhpStorm, с двумя проектами, каждый из них слушает входящие соединения (трубка включена).
5. В проекте two.loc ставим точку останова на второй, например, строке. В первом проекте first.loc запускаем http запрос из файла http.http
И о чудо! Нас перекидывает во второй проект, на нашу точку останова.
Для дебага консольных скриптов делаем всё ровно тоже самое. Включаем трубку для прослушки, ставим точку останова, заходим в нужный контейнер, запускаем нужный скрипт.
Где php71first — алиас на машине хоста:
cdf — алиас, который работает в контейнере. Выше я писал о том, что для общения с контейнерами предпочитаю использовать алиасы.
На этом всё, конструктивная критика, замечания приветствуются.