korobovn15 июл 2019 в 21:43

Разработка под Docker. Локальное окружение. Часть 2 — Nginx+PHP+MySql+phpMyAdmin

6 мин

58K

PHP * Веб-разработка *

+12

Комментарии 17

trawl 16 июл 2019 в 03:30

А почему именно PMA? Можно взять Adminer, который будет пошустрее и полегче. Да и в установке попроще (поставляется одним файлом)

korobovn 16 июл 2019 в 18:31

phpmyadmin — личные предпочтения. В докере как раз сложность установки нивелируется. Куда уж проще пару строк в композ-файл добавить.

mshewzov 13 сен 2024 в 15:28

Прошли годы и Adminer завис в 2021 году, а PMA развивается до сих пор...

zhulan0v 16 июл 2019 в 05:09

Ну теперь пора писать про докер в проде

Arik 16 июл 2019 в 05:50

COPY --from=composer:latest /usr/bin/composer /usr/bin/composer

Далее копируется composer из другого базового образа

просто скопировать достаточно? в дальнейшем можно спокойно делать composer selfupdate? как-то в composer/docker более интересные вещи происходят. Интересно куда кэш пойдет писать, зависимости в целом, php.ini для php-cli, к тому же можно выбрать php 7.1, а composer тянет последний PHP и т.д. со всем этим не будет проблем?
Интересно в целом работа с php-cli под докером, допустим тот же artisan.php от Лары и yii.php от Yii. Можно отдельный поднять контейнер от php:*-cli, но тогда как все будет или все в один контейнер закинуть?) npm и в целом сборку фронта если нужно поднять, то как лучше? или я рано начал про это все?)

korobovn 16 июл 2019 в 18:52

composer:latest — это последний образ. Есть сомнения, что его потребуется обновить, но полагаю ничего не помешает ему обновиться при необходимости.
В указанном докер файле все сводится к установке лишь одного файла composer.phar, который в дальнейшем переименовывается в /usr/bin/composer. Копирование вполне корректно. Набором исходников он точно не поставляется, если разговор про это. Кеш писать? Что при копирование мешает это делать? Зависимости? Опять же он поставляется одним файлом, для выполнения, которого нужен php.
В образе с php-fpm ничего не мешает выполнить любой скрипт в консольном режиме. Для докера есть образы php-cli, но такой образ можно использовать, если нет потребности в php в роли fastcgi.
Касаемо сборки фронта и бекенда. В бекенде должен быть в основном php код и образ основывается на php-fpm, а фронт как правило всегда базируется на nginx. В этом образе должен быть публичный код, т.е. всякие js, css и например публичный index.php запрос к которому будет перенаправляться на бекенд. Если для сборки фронта требуется node, то проект можно собрать в образе нода и перекопировать скомпилированные js и css в образ фронта. Это речь больше про сборку для прода. Для дева тоже ничего особо не мешает использовать для сборки образ с нод или чем-то еще. Ну или на худой конец собрать свой.

В дальнейшем будут посты на эту тему.

ArtMares 16 июл 2019 в 18:53

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

Для выполнения cli набираешь простую команду

docker-compose exec php

Проваливаешься внутрь запущенного контейнера и там уже выполняешь все необходимые тебе команды: composer install(update) yii и тд.

Atton 16 июл 2019 в 18:53

про php.ini и версии php верно подметили. меня тоже очень интересует cli, это стоит осветить.
В сетях уже я думаю стоило бы упомянуть ipam, да и про make файлы можно тоже было бы сказать, часть программистов незаслуженно игнорируют этот удобный функционал.

korobovn 16 июл 2019 в 19:06

И установка composer путем копирования не единственный вариант, скорее как одно из интересных решений. Если вдруг не сработает, то можно и по официальной инструкции пойти.
Про последнюю версию php, что-то в первые слышу. В системных требованиях getcomposer.org/doc/00-intro.md#system-requirements сказано, что достаточно и PHP 5.3.2

Arik 17 июл 2019 в 03:51

Про последнюю версию php, что-то в первые слышу. В системных требованиях getcomposer.org/doc/00-intro.md#system-requirements сказано, что достаточно и PHP 5.3.2

я тут про образ в котором «собирается»(?) композер, сейчас в нем FROM php:7-alpine сегодня может проблем нет, но что будет завтра? Как пример composer начал собираться FROM php:8-*, используется новая мажорная версия самого композера, а мы перетаскиваем его в контейнер, где стоит php7?) да и джуны могут начать юзать такой подход там где совсем нельзя. Я к тому, что разные компоненты собираются в разных средах/окружениях: fpm собирается от одного (docker FROM), php-cli под другим (docker FROM), а composer может совсем под другим. Выходит кто-то собрался от php7.1-alpine, кто-то от php7.3-debian, а кто-то умудрился от php7.4-windows(?). Вот и думал, может все что связано с php собрать в один образ-контейнер, где всегда одна версия php?

по зависимостям имел виду, что composer/docker собирается со своими зависимостями (it subversion openssh-client mercurial tini bash patch make zip unzip coreutils), модули php (zip opcache), со своими переменными окружениями композера и настройкой php-cli в контейнере образа composer/docker! А мы просто вытащили из этой среды сам composer, который если не ошибаюсь юзает системный php, а он скорее всего настроен совсем по другому. Выходит при таком подходе composer работает по дефолтным настройкам, а не от composer:latest?