docker php cli alpine
Docker php cli alpine
This PHP FPM and PHP CLI docker image based on Alpine. Alpine is based on Alpine Linux, lightweight Linux distribution based on BusyBox. The size of the image is very small, less than 50 MB!
Versions and tags are based on PHP versions.
Here are the supported tags and respective Dockerfile links.
The cli tag show that the PHP is used for command line and the fpm is designed to be used with PHP-FPM. It is fit with Alpine-Nginx docker image.
PHP 7.0 is still using edge/testing repository for PHP7 packages. PHP 7.0 CLI is not available yet, since there’s no php7-cli package in the repository.
This image is published in the Docker Hub. Simply run this command below to get it to your machine.
Or if you want to use cli image.
Alternatively you can clone this repository and build the image using the docker build command.
This image use Asia/Jakarta timezone by default. You can change the timezone by change the TIMEZONE environment on Dockerfile and then build.
The site data, config, and log data is configured to be located in a Docker volume so that it is persistent and can be shared by other containers or a backup container).
There is volume defined in this image /www that is shared with Nginx container. Please make sure both containers can access the directory. You can store the sites data to this directory.
The config is set using environments listed below on build.
Change it in Dockerfile and you can rebuild your image.
Create and Run The Container
If you run and want to link Nginx container, make sure you created and run this PHP-FPM the container before running this Nginx container. Make sure the /www volume in PHP-FPM container is mapped.
Stopping The Container
Start The Container Again
To ease the job, make alias for PHP-CLI. Add this line to
/.bashrc so we can call it as regular php command.
About
PHP FPM and PHP CLI docker image based on Alpine Linux
Среда разработки PHP на базе Docker
Решение, которое позволит создать на локальном компьютере универсальную среду разработки на PHP за 30 — 40 минут.
Почему Docker?
Docker не является VM-системой, он не моделирует аппаратное обеспечение компьютера. Используя Docker вы получите минимальное потребление ресурсов. Docker-контейнеры взаимодействуют напрямую с ядром вашего компьютера (или ядром хоста), но при этом изолируют программу на уровне процесса.
Высокая скорость развертывания. Вы можете использовать готовые docker-образы, которые устанавливаются и запускаются за секунды.
Приложения, находящееся внутри docker-контейнеров, можно запустить на любом компьютере с установленным Docker, при этом окружение будет одинаковым.
Возможность простой сегрегации пользовательских данных и контейнеров-сервисов. Если вы сломаете или удалите docker-контейнер, то данные не потеряются, так как они не будут принадлежать контейнеру. Контейнер выполняет лишь функцию сервиса, и не хранит данные, которые нельзя потерять между запусками.
Вы можете очень быстро добавлять новые контейнеры, изменять их конфигурацию, запускать различные версии баз данных на одной машине.
Требования
Docker engine 19.x и выше.
Возможности и особенности среды разработки
Несколько версий PHP — 7.3 и 7.1 с набором наиболее востребованных расширений.
Возможность использовать для web-проектов разные версии PHP.
Готовый к работе монитор процессов Supervisor.
Предварительно сконфигурированный веб-сервер Nginx.
Базы данных: MySQL 5.7, MySQL 8, PostgreSQL (latest), MongoDB 4.2, Redis (latest).
Настройка основных параметров окружения через файл .env.
Возможность модификации сервисов через docker-compose.yml.
Последняя версия docker-compose.yml.
Все docker-контейнеры базируются на официальных образах.
Структурированный Dockerfile для создания образов PHP.
Каталоги большинства docker-контейнеров, в которых хранятся пользовательские данные и параметры конфигурации смонтированы на локальную машину.
В целом, среда разработки удовлетворяет требованию — при использовании Docker каждый контейнер должен содержать в себе только один сервис.
Репозиторий проекта
Структура проекта
Рассмотрим структуру проекта.
Примечание
.gitkeep — является заполнением каталога, это фиктивный файл, на который не следует обращать внимание.
.env-example
Пример файла с основными настройками среды разработки.
.gitignore
Каталоги и файлы, в которых хранятся пользовательские данные, код ваших проектов и ssh-ключи внесены в. gitignore.
Этот каталог предназначен для хранения ssh-ключей.
readme.md
docker-compose.yml
Документ в формате YML, в котором определены правила создания и запуска многоконтейнерных приложений Docker. В этом файле описана структура среды разработки и некоторые параметры необходимые для корректной работы web-приложений.
mongo
Каталог базы данных MongoDB.
mongo.conf — Файл конфигурации MongoDB. В этот файл можно добавлять параметры, которые при перезапуске MongoDB будут применены.
db — эта папка предназначена для хранения пользовательских данных MongoDB.
dump — каталог для хранения дампов.
mysql-5.7
Каталог базы данных MySQL 5.7.
config-file.cnf — файл конфигурации. В этот файл можно добавлять параметры, которые при перезапуске MySQL 5.7 будут применены.
data — эта папка предназначена для хранения пользовательских данных MySQL 5.7.
dump — каталог для хранения дампов.
logs — каталог для хранения логов.
mysql-8
Каталог базы данных MySQL 8.
config-file.cnf — файл конфигурации. В этот файл можно добавлять параметры, которые при перезапуске MySQL 8 будут применены.
data — эта папка предназначена для хранения пользовательских данных MySQL 8.
dump — каталог для хранения дампов.
logs — каталог для хранения логов.
nginx
Эта папка предназначена для хранения файлов конфигурации Nginx и логов.
default.conf — файл конфигурации, который будет применён ко всем виртуальным хостам.
vhost.conf — здесь хранятся настройки виртуальных хостов web-проектов.
Рассмотрим vhost.conf подробнее:
В файле конфигурации описаны настройки для двух web-проектов — project-1.localhost и project-2.localhost.
Здесь следует обратить внимание на то, как производится перенаправление запросов к нужному docker-контейнеру.
Например, для проекта project-1.localhost указано:
php-7.3 — название docker-контейнера, а 9000 — порт внутренней сети. Контейнеры между собой связаны через внутреннюю сеть, которая определена в файле docker-compose.yml.
php-ini
В этом каталоге находятся файлы конфигурации PHP.
Для каждой версии PHP — свой файл конфигурации.
php-workers
Место для хранения файлов конфигурации Supervisor.
Для каждой версии PHP — могут быть добавлены свои файлы с настройками.
php-workspace
Здесь хранится файл, в котором описаны действия, выполняемые при создании образов docker-контейнеров PHP.
Dockerfile — это текстовый документ, содержащий все команды, которые следует выполнить для сборки образов PHP.
postgres
Каталог для системы управления базами данных PostgreSQL.
data — эта папка предназначена для хранения пользовательских данных PostgreSQL.
dump — каталог для хранения дампов.
projects
Каталог предназначен для хранения web-проектов.
Вы можете создать в это каталоге папки, и поместить в них ваши web-проекты.
Содержимое каталога projects доступно из контейнеров php-7.1 и php-7.3.
Если зайти в контейнер php-7.1 или php-7.3, то в каталоге /var/www будут доступны проекты, которые расположены в projects на локальной машине.
redis
Каталог key-value хранилища Redis.
conf — папка для хранения специфических параметров конфигурации.
data — если настройки конфигурации предполагают сохранения данных на диске, то Redis будет использовать именно этот каталог.
Программы в docker-контейнерах PHP
Полный перечень приложений, которые установлены в контейнерах php-7.xможно посмотреть в php-workspace/Dockerfile.
Здесь перечислим лишь некоторые, наиболее важные:
Начало работы
1. Выполните клонирование данного репозитория в любое место на вашем компьютере.
Перейдите в директорию, в которую вы клонировали репозиторий. Все дальнейшие команды следует выполнять именно в этой директории.
2. Скопируйте файл .env-example в .env
Если это необходимо, то внесите изменения в файл .env. Измените настройки среды разработки в соответствии с вашими требованиями.
3. Выполните клонирование web-проектов в каталог projects.
Для примера, далее мы будем исходить из предположения, что у вас есть 2 проекта:
project-1.ru — будет работать на версии PHP 7.3, а project-2.ru — на PHP 7.1.
4. Отредактируйте настройки виртуальных хостов Nginx.
Файл конфигурации виртуальных хостов находится в каталоге ./nginx/conf.d/.
5. Настройте хосты (доменные имена) web-проектов на локальной машине.
Необходимо добавить названия хостов web-проектов в файл hosts на вашем компьютере.
В файле hosts следует описать связь доменных имён ваших web-проектов в среде разработки на локальном компьютере и IP docker-контейнера Nginx.
На Mac и Linux этот файл расположен в /etc/hosts. На Windows он находится в C:\Windows\System32\drivers\etc\hosts.
Строки, которые вы добавляете в этот файл, будут выглядеть так:
В данном случае, мы исходим из того, что Nginx, запущенный в docker-контейнере, доступен по адресу 127.0.0.1 и web-сервер слушает порт 80.
6. [опционально, если это необходимо] Настройте маршрутизацию внутри контейнеров web-проектов.
Web-проекты должны иметь возможность отправлять http-запросы друг другу и использовать для этого название хостов.
Из одного запущенного docker-контейнера php-7.1 web-приложение № X должно иметь возможность отправить запрос к другому web-приложению № Y, которое работает внутри docker-контейнера php-7.3. При этом адресом запроса может быть название хоста, которое указано в файле /etc/hosts локального компьютера.
Чтобы это стало возможным нужно внутри контейнеров так же внести соответствующие записи в файл /etc/hosts.
Самый простой способ решить данную задачу — добавить секцию extra_hostsв описание сервисов php-7.1 и php-7.3 в docker-compose.yml.
IP_HOST_machine — IP адрес, по которому из docker-контейнера доступен ваш локальный компьютер.
Если вы разворачиваете среду разработки на Mac, то внутри docker-контейнера вам доступен хост docker.for.mac.localhost.
Узнать IP адрес вашего Mac можно при помощи команды, который нужно выполнить на локальной машине:
В результате вы получите, что-то подобное:
После того, как вам станет известен IP-адрес, укажите его в секции extra_hostsв описание сервисов php-7.1 и php-7.3 в docker-compose.yml.
8. Настройте параметры соединения с системами хранения данных.
Хосты и порты сервисов
Для того, чтобы настроить соединения с базами данных из docker-контейнеров php-7.1 и php-7.3 следует использовать следующие названия хостов и порты:
Запуск 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.
Всем желаю успехов в освоении новых технологий!
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 — алиас, который работает в контейнере. Выше я писал о том, что для общения с контейнерами предпочитаю использовать алиасы.
На этом всё, конструктивная критика, замечания приветствуются.