Docker apache php mysql

Я искал в Интернете и читал руководства, и я просто не могу понять, что не так с моей настройкой Docker.

Для создания контейнеров Apache, PHP и MySQL, позволяющих настраивать их для каждого проекта. только Зависимость для развертывания стека должна быть докерской. Все другие зависимости / действия должны быть в состоянии быть построенными / запущенными через Dockerfile ,

Доказательство концепции

Из моего стека Apache + MySQL + PHP через docker-compose.yml файл — я хотел бы нацелить на index.php страница для успешного рендеринга Hello Docker! вместе со списком всех доступных баз данных.

Эта проблема

Когда я посещаю docker.dev/index.php В моем браузере вместо того, чтобы запускать код PHP, я могу просматривать только исходный код PHP. Вот что я вижу:

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

Я установил Apache для depends_on PHP и я связали их через network (вместе с MySQL), но, очевидно, я что-то упускаю, иначе все будет работать так, как я хочу).

Я создал репозиторий на github, который должен позволить вам проверить мои настройки с помощью нескольких простых команд:

Вам также придется редактировать добавить docker.dev в 127.0.0.1 в вашем хост-файле на вашем хост-компьютере!

Как я могу рендерить PHP, а не читать его источник, когда я посещаю docker.dev/index.php ?

я не хочу использовать объединенное изображение PHP и Apache, если это вообще возможно. Я хотел бы иметь три отдельных контейнера — PHP, Apache, MySQL.

Решение

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

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

Затем вы должны выполнить следующую команду в каталоге, где docker-compose.yml файл:

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

Естественно, тогда вам нужна конфигурация сайта nginx, которая указывает на /var/www/html , У вас практически не будет требований к конфигурации контейнера php-fpm.

Дополнительное примечание относительно конфигурации nginx. Приведенный выше docker-compose.yml является неполным без ссылки на контейнер php в конфигурации nginx. Это будет выглядеть так (грубо говоря):

Вы заметите, что я назвал контейнер «php7», вы можете добавить еще один контейнер «php5» к этому docker-compose.yml и затем это позволяет вам определять сайты nginx, которые используют разные версии PHP, все запущенные в одной и той же конфигурации docker-compose.

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

Надеюсь, это по крайней мере дает вам идеи, чтобы помочь решить ваши настройки.

Другие решения

Я решил этот вопрос и создал репо для тех, кто интересуется более глубоким объяснением или доказательством концепции.

TL; DR

Подход, который я использовал для решения этой проблемы, заключался в передаче всех запросов apache любому .php файлы в PHP-FPM через fcgi://php:9000 , Порт 9000 по умолчанию

Вы можете увидеть эту настройку Apache в действии Вот .

/var/www/html/$1 часть настройки — это то, где файлы отображаются в контейнере PHP.

Вы столкнулись с мемом «контейнеры должны делать одну вещь», что хорошо, но это не значит, что вы должны разделить его так далеко. Контейнер LAMP совершенно нормален в Docker-land, и я не знаю, какие усилия были предприняты для разделения Apache и PHP — я подозреваю, что это пустая трата инженерных усилий.

Как вы говорите, вы хотите иметь возможность запускать разные версии PHP. Это абсолютно нормально, и вы должны настроить это в своем Dockerfile , Если вы намереваетесь создать набор контейнеров, от которых ваши службы могут наследовать, тогда вы можете просто иметь базовый контейнер Apache, к которому вы добавляете PHP в наследовании. Dockerfile s.

Я запускаю набор микросервисов, которые используют смесь 5,6 и 7,0. Все они наследуют от очень простого alpine (разных версий: 3.5, 3.6 и новее, которые станут 3.7). Копирование и вставка моей занимает около 15 минут Dockerfile требования на вершине, плюс немного настройки контейнера, что я, вероятно, все равно буду делать. Итак, если ваша цель — готовый набор контейнеров, я не уверен, сколько времени вы сэкономите на практике.

Это все сказано, если вы действительно чтобы продолжить это, вы могли бы посмотреть на механизм, который Piwik использует. Я не знаком с этим, но контейнер PHP обслуживает FastCGI, и его необходимо прокси-сервер веб-сервером в другом контейнере.

Docker, docker, docker. Было время, когда это слово звучало в каждой курилке разработчиков. Хайп вокруг докера уже подугас, однако он по-прежнему может быть полезен как для локальной среды, так и как production-ready решение. Но в посте речь пойдет именно о среде для локальной разработки.

Но для тех, кто не в курсе, на всякий случай:

Docker — программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы. Позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, который может быть перенесён на любую Linux-систему с поддержкой cgroups в ядре, а также предоставляет среду по управлению контейнерами. Изначально использовал возможности LXC, с 2015 года применял собственную библиотеку, абстрагирующую виртуализационные возможности ядра Linux — libcontainer. С появлением ​Open Container Initiative начался переход от монолитной к модульной архитектуре.

Углубляться в то, что такое docker и как он работает в этой статье я не буду, это тема скорее для отдельного разговора. Если кому-то интересно — пишите в комментариях.

Что будет уметь наша сборка?

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

• Собственно сам PHP, последний стабильный релиз 7.1;
• Composer
• Mysql, последняя стабильная версия 8;
• Nginx

Также наша конфигурация будет поддерживать сколько угодно хостов nginx (см. проектов). Добавление новых компонентов в стек обычно не составляет труда, если это не заморская диковина конечно, но об этом позже.

Установка docker

Заострять внимание на процессе установки docker’а нет никакого смысла, на официальном сайте есть подробные мануалы по установке для всех популярных ОС:

Нам еще понадобится docker-compose . Как установить можно прочитать по ссылке.

Файловая структура

Переходим к организации папок и файлов нашей сборки. Создадим на диске какую-нибудь директорию, которая будет корневой для нашей сборки и в ней по порядку создаем следующие директории:

• www — в этой папке будут лежать файлы наших проектов, по директории на каждый проект;
• mysql — в этой папке будут храниться файлы наших баз данных;
• logs — здесь будет собриать логи из разных образов;
• hosts — здесь будут храниться файлы конфигурации nginx для наших проектов;
• images — папка с нашими образами — компонентами нашей системы.

Еще не помешает создать дефолтный проект, чтобы проверить работоспособность нашей сборки когда все запустится. В директории www создадим директорию тестового проекта — hello.dev с одим единственным файлом index.php . Содердимое файла index.php классическое:

Также в корне будет лежать наш docker-compose.yml — сердце любой docker-конфигурации 🙂

Собираем образ PHP

Стандартный официальный образ PHP не включает в себя никаких модулей, поэтому чтобы включить их нужно собрать свой образ на основе официального. Звучит немного страшновато, но на деле все просто. Создаем директорию для нашего образа images/php и в ней создаем файл Dockerfile следующего содержания:

Также в этой папке создадим пока пустой php.ini , чтобы не было ошибки при сборке образа. Можете добавить в него нужные вам настройки.

Docker Compose

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

Структура docker-compose.yml файла предельно простая, если будут вопросы — задавайте в комментариях.

Конфигурация nginx для проектов

Раньше мы уже создали тестовый проект hello.dev , давайте добавим для него конфиг nginx. В папке hosts создадим файл с названием hello-dev.conf :

Конфиг nginx для докер-контейнера ничем не отличается от обычного конфига для сайта. Стоит лишь обратить внимание на директиву fastcgi_pass , где мы используем не путь к unix-сокету, а адрес php:9000 . Здесь присутствует немного магии docker’а: php — это хост по которому доступен наш php контейнер внутри контейнера nginx , ну а 9000 — порт, по которому можно достучаться до fpm-сокета.

Run the magic!

Мы набросали минимальную конфигурацию для локальной среды разработки и можем ее смело запускать. Для этого из корня нашей сборки, где лежит docker-compose.yml файл нужно выполнить команду docker-compose up -d и немного подождать. Первый запуск будет дольше, потому что docker’у нужно скачать образы и собрать образ для php.

В конце концов мы увидим заветные строчки:

Они говорят нам что наши три контейнера запущены и готовы к работе. Проверимс. Для этого откроем браузер и перейдем по адресу http://hello.dev/ , но сперва добавим одну строку в hosts файл.

Важно для windows и mac адрес 127.0.0.1 нужно заменить на адрес виртуальной машины, в которой запускается докер, потому что нативной поддержки пока нет или она очень унылая.

Итак, окрываем браузер и видим:

Наша среда готова для работы. Можно легко добавлять новые проекты — просто создаем новую папку для проекта в www и добавляем новый конфиг для nginx, перезаускаем контейнеры и вперед! Удачи в разработке и пишите вопросы в комментариях.

Continuing with the Containerize This! series, we’re looking at common web application technologies and how they can be used within Docker containers effectively.

PHP, Apache, and MySQL have a very large market share on content management systems and web applications on the internet, and with so many developers using these technologies, there is a lot of interest to modernize the way that they use them from from local development all the way to production. Today we’ll take a look at several ways to containerize and link PHP, Apache, and MySQL together while demonstrating some tips, tricks, and best-practices that will help you take a modern approach when developing and deploying your PHP applications!

There are 5 simple files for this demo that you can clone from https://github.com/mzazon/php-apache-mysql-containerized or simply copy and paste from this post to replicate the following folder structure. Please note that some Docker and security principals have been skipped here for simplicity and demonstration purposes. Namely PHP using root credentials, hardcoded/weak MySQL password, lack of SSL, to name a few! Do not run this code in production!

Once this structure is replicated or cloned with these files, and Docker installed locally, you can simply run "docker-compose up" from the root of the project and point your browser (or curl) to http://localhost:8080 to see the demo. We will get into what "docker-compose" is, and what makes up this basic demonstration in the following sections!

We’ll use the following simple PHP application to demonstrate everything:

index.php

This code attempts to connect to a MySQL database using the mysqli interface from PHP. If successful, it prints a success. If not, it prints a failed message.

Docker Compose

This format has been around for a while in Dockerland and is now in version 3.6 at the time of this writing. We’ll use 3.2 here to ensure broad compatibility with those who may not be running the latest and greatest versions of Docker (however, you should always upgrade!)

This format allows for defining sets of services which make up an entire application. It allows you to define the dependencies for those services, networks, volumes, etc as code. As you roll into production, you can even specify deployment parameters on services which allow you to replicate, scale, update, and self-heal on Docker Swarm or even Kubernetes on the latest Docker for Mac or Docker Enterprise Edition!

docker-compose.yml

Decouple dependencies, run one process per container (PID 1)

Containers at the core are simply process encapsulation within a shared Linux kernel, to allow for many processes to run inside of their own spaces without interfering or interacting unless we explicitly tell them they can. Thus, it is a long-running best practice to run your primary service within a container as PID 1. This means that no other process should be running inside of your containers. It allows containers to maintain a native linux process lifecycle, respect linux process signals, allow for greater security, and will make your life easier when you schedule these containers on orchestrators such as Docker Swarm or Kubernetes in production.

A perfect example is decoupling Apache and PHP by building them out into separate containers. We see our customers often starting to couple Apache and PHP together early on in a Docker journey by building custom images which include both Apache and PHP in the image. This easily works in development scenarios and is a fast way to get off the ground, but as we want to follow a more modern approach of decoupling, we want to break these apart.

The following simple Dockerfiles are what we’re using in this example to build a decoupled Apache and PHP environment:

apache/Dockerfile

php/Dockerfile

Note that we run minimal containers wherever possible, in this example we’re using official alpine-based images!

Networking

Now that we have container images for Apache and PHP that are decoupled, how do we get these to interact with each other? Notice we’re using "PHP FPM" for this. We’re going to have Apache listen on port 80 and proxy connections which require PHP to port 9000 of our PHP container, and then have the PHP container serve those out as rendered HTML. Sound complicated? Don’t worry! This is very common in modern applications, Apache and NGINX are very good at this proxying, and there is plenty of documentationout there to support this behavior!

Notice in the above Docker Compose example, we link the containers together with overlay networks we define as "frontend" and "backend". By specifying these networks in our services, we can leverage some really cool Docker features! Namely, we can refer to the containers/services by their service names in code, so we don’t have to worry about messy hard-coding of IP addresses anymore. Phew! Docker handles this for us by managing and updating /etc/hosts files within containers seamlessly to allow for this cross-talk. We can also enforce which containers can talk to each other. This allows for more secure applications. Notice in this example we have "frontend" and "backend" defined. We can have our php and mysql services live in a network that is more restricted and not exposed to the outside world, and only expose our apache container on the required port. This is great for production environments!

One note: We need an apache vhost configuration file that is set up to proxy these requests for PHP files to the PHP container. You’ll notice in the Dockerfile for Apache we have defined above, we add this file and then include it in the base httpd.conf file. This is for the proxying which allows for the decoupling of Apache and PHP. In this example we called it demo.apache.conf and we have the proxying modules defined as well as the VirtualHost. Also notice that we call the php container in the code "php" which, because of the /etc/hosts file integration that Docker handles for us, works flawlessly!

apache/demo.apache.conf

Volumes

The last feature that we’ll call out here for demonstration purposes is the use of volumes to serve out our code. Both the PHP and Apache containers have access to a "volume" that we define in the docker-compose.yml file which maps the public_html folder of our repository to the respective services for them to access. When we do this, we map a folder on the host filesystem (outside of the container context) to inside of the running containers. Developers may wish to set their projects up like this because it allows them to edit the file outside of the container, yet have the container serve the updated PHP code out as soon as changes are saved.

Volumes are a very powerful construct of the Docker world and we’re only scratching the surface of what one can achieve by using them in development and production. Please see the official documentation on volumes for further use cases and best practices!

Demonstration of docker-compose up!

Notice how these 3 daemons run on PID 1 inside of each container, this is considered a best-practice for building containers!

Notice now in the logs that the apache container and php containers both respond to the request, as desired:

Conclusion

With these basic principles you can link services together to create applications. You could easily include "composer" in the PHP container to build and run your PHP/Laravel application in a similar manner. Perhaps you want to run Drupal or WordPress and decouple PHP from the Apache instance, that is possible too! You can even use this to seamlessly test PHP version or MySQL version upgrades with minimal code change. There are a lot of benefits to modernizing your application with Docker using docker-compose and some of the latest official images and features. If you start your Docker journey using these techniques, you’ll be off to a great start in your containerization journey!

Related Posts

Cloudreach Serverless Arena: Urly Wurly

We challenged our internal serverless community to create a URL shortener using serverless technology and their favourite cloud provider. In this post, we would like to introduce the winner: Urly Wurly.

Opportunity Cost: The Cost Of Not Moving To The Cloud

In this post, Cloud Strategist, Jeff DeVerter, addresses the commonly asked question: How much will it cost me to move to the Cloud? Jeff suggests it will cost you more if you don’t move to the Cloud.

Secret CxO Roundtable: Agile And Adaptable Organisations

In September, the Cloudbusting Podcast team held a roundtable discussion with CxOs from seven enterprises at different stages in their cloud journey.