• Внедрение предметно-ориентированного проектирования в PHP
    0
    Отчего-то кажется, что Эванс бы поперхнулся от такой реализации. На доменный уровень для реализации репозиториев и сущностей протаскивать инфраструктурную зависимость в виде доктрины) Даже по неймспейсам забавно выглядит, где в домене встречаются упоминания о доктрине орм. Осталось только расширить общий язык и просветить бизнес, что же такое доктрина и как она работает))
  • Разработка под Docker. Локальное окружение. Часть 2 — Nginx+PHP+MySql+phpMyAdmin
    0
    ок
  • Разработка под Docker. Локальное окружение. Часть 2 — Nginx+PHP+MySql+phpMyAdmin
    0
    А nginx-proxy чем конкретно не нравится?
  • Разработка под Docker. Локальное окружение. Часть 1
    0
    в dockerfile на этапе сборки
  • Разработка под Docker. Локальное окружение. Часть 2 — Nginx+PHP+MySql+phpMyAdmin
    0
    И установка composer путем копирования не единственный вариант, скорее как одно из интересных решений. Если вдруг не сработает, то можно и по официальной инструкции пойти.
    Про последнюю версию php, что-то в первые слышу. В системных требованиях getcomposer.org/doc/00-intro.md#system-requirements сказано, что достаточно и PHP 5.3.2
  • Разработка под Docker. Локальное окружение. Часть 2 — Nginx+PHP+MySql+phpMyAdmin
    0
    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 в образ фронта. Это речь больше про сборку для прода. Для дева тоже ничего особо не мешает использовать для сборки образ с нод или чем-то еще. Ну или на худой конец собрать свой.

    В дальнейшем будут посты на эту тему.
  • Разработка под Docker. Локальное окружение. Часть 2 — Nginx+PHP+MySql+phpMyAdmin
    –1
    phpmyadmin — личные предпочтения. В докере как раз сложность установки нивелируется. Куда уж проще пару строк в композ-файл добавить.
  • Разработка под Docker. Локальное окружение. Часть 1
    0
    В последнее время использую следующий подход. В контейнер с композером копируется два файла composer.json composer.lock при необходимости можно добавлять приватный ключ в контейнер и запускается инстал, без проверки зависимостей. Затем в основной образ бекенда копируется все то что собрал композер. Копирование выполняется с использованием параметра chown: COPY [--chown=:]. И далее в основном образе выполняется композер дамп и пост-скрипты. Если изменений в composer.json composer.lock не было, то при сборке используется кеш, что значительно ускоряет процесс.
  • Разработка под Docker. Локальное окружение. Часть 1
    0
    На проде используется «монолитный» собранный образ без проброса кода, на деве пробрасывать код необходимо, в этом вся суть разработки. И в том и другом образах основа одинаковая, один и тот же php, одни и те же расширения. Образ для прода в идеале должен собираться автоматически через CI, точно также автоматически должен и деплой происходить. После сборки в идеале должны запускаться различные тесты, юнит-тестирование как минимум. Потом бы в идеале чтобы образ выгружался сначала на тестовый сервер, там дополнительно проверялась логика работы кода и только затем уже аналогичный образ устанавливается на прод.
  • Разработка под Docker. Локальное окружение. Часть 1
    0
    Я постараюсь разогнаться) А за мысли спасибо, но как-то они воспринимались само-собой разумеющимися.
  • Разработка под Docker. Локальное окружение. Часть 1
    +1
    Поначалу когда начинаешь с ним разбираться, да, бывают сложности. Но это именно от опускания каких-то моментов и недостатка опыта. Как и в любом деле со временем рука набивается. Лично мне кажется, что докер может стать в перспективе неотъемлемой частью программирования. Развертывание окружение это тоже самое что и минимальные познания в веб-серверах и прочей инфраструктуре.
  • Разработка под Docker. Локальное окружение. Часть 1
    +2
    По идее если вы монтируете исходники снаружи, то вы должны полностью перекрывать то что внутри и принадлежало www-data, потом выполнять сборку своих исходников в виде. composer install или чего-то подобного. И тогда никаких проблем с правами быть не должно.
    А по хорошему, вообще кажется не совсем верный подход монтировать образ с прода.
    Должно быть локальное окружение для нужд разработчиков и отдельно сборка из исходников образа для прода.
  • Разработка под Docker. Локальное окружение. Часть 1
    0
    Проба пера, продолжение следует)
  • Разработка под Docker. Локальное окружение. Часть 1
    0
    Что-то не видел функции у шторма соединяться с сокетом…
  • Разработка под Docker. Локальное окружение. Часть 1
    0
    Минус в том, что при перезапуске этот адрес можем меняться, а так да, вариант
  • Разработка под Docker. Локальное окружение. Часть 1
    +1
    с mac к сожалению возможности не имел работать, хотя коллеги работают с докером в маке и вроде как не жалуются. В виндовсе действительно проблема со скоростью есть. Симфони могла свой кеш грузить секунды по три, в то время как в линуксе скорость не вызывает нареканий. По сравнению с виндовс симфони там работает в десятки раз быстрее. (миллисекунды против секунд)
  • Разработка под Docker. Локальное окружение. Часть 1
    0
    Представленный вариант это по сути и есть монтирование текущей папки. А при простом монтирование по моему именной volume не создается (может конечно путаю). И я особо никогда не задавался большой целью удаления лишних вольюмов. В конце концов есть команда docker volume prune, которая подчищает неиспользуемые вольюмы.
  • Разработка под Docker. Локальное окружение. Часть 1
    +1
    С 80м портом это довольно известная и типовая проблема. Для ее решения можно использовать реверс-прокси. К примеру, у меня довольно популярен вот этот hub.docker.com/r/jwilder/nginx-proxy. Отдельно запускается данный прокси только у него прокидывается 80 порт и к нему коннектятся отдельные фронты уже без проброса 80го порта.
    Касаемо Mysql, исключительно для нужд приложения проброс портов на хостовую машину вообще не нужен. Я порой пробрасываю кастомные порты, чтобы соединятся с контейнером через PHPSTORM (может быть кто-то из местных подскажет функцию у шторма, чтобы без проброса коннектиться к базе в докере.) Или если использовать например phpmyadmin настроенную через прокси, то можно обойтись и без проброса.
  • Разработка под Docker. Локальное окружение. Часть 1
    +1
    согласен, что технологию сложно назвать новой, да и все что я могу рассказать для знатоков ни в коей мере Америки не откроет, но по своему опыту вижу довольно много разработчиков-староверов, которые даже из подобных статей что-то могут почерпнуть для себя нового)