Обновление Docker с Composer и XDebug

После серии эпизодов про React возвращаемся к разработке аукциона. В предыдущем эпизоде мы научились обновлять зависимости в ритме Continuous Integration. За время нашего отсутствия вышли мажорные версии Composer, Xdebug, Psalm и Cucumber. Также обновились базовые Docker-образы Nginx, NodeJS и PostgreSQL. Так что сейчас самое время перейти на свежий софт:

  • 00:02:16 - Переход на Composer 2
  • 00:03:16 - Форсирование pull для build
  • 00:06:03 - Исправление интерактивности миграций
  • 00:07:40 - Фиксирование версии Xdebug
  • 00:11:17 - Смена версий NginX и NodeJS
  • 00:13:13 - Ручное и автоматические обновление PostgreSQL
  • 00:17:02 - Обновление wait-for-it
  • 00:17:17 - Переход на Xdebug 3
  • 00:21:28 - Исправления для Psalm
  • 00:29:19 - Изменение схемы PHPUnit
  • 00:32:47 - Обновление Sentry с зависимостями
  • 00:34:34 - Обновление Guzzle
  • 00:35:21 - Переход на Psalm 4
  • 00:36:42 - Включение кэширования в Psalm
  • 00:41:32 - Обновление пакетов фронтенда
  • 00:45:01 - Обновление Cucumber
  • 00:55:36 - Обзор результата
  • 00:57:36 - Новые функции PhpStorm

А дальше займёмся интеграцией PHPUnit, CodeSniffer и Psalm в PhpStorm для более удобной разработки.

Скрытый контент
Комментарии (31)
Arunas

Спасибо.

Ответить
Александр

Спасибо, очень полезный урок. Не лучше ли использовать code sniffer не на прямую, а через библиотеку https://github.com/symplify/easy-coding-standard ? По-моему она гораздо удобнее.

Ответить
Дмитрий Елисеев

Не так уж и гораздо. А так да, помимо проверки форматирования можно подключить ещё и CS Fixer для более сложных проверок.

Ответить
Александр

Ну как гораздо ) Там фиксер и снифер под капотом, и один конфиг для этих инструментов, в форманте php, сразу готовые пресеты.

Ответить
Дмитрий Елисеев

Если брать CS Fixer, то тогда отдельный Code_Sniffer не нужен. Вопрос именно в том, зачем использовать их оба.

Ответить
Александр

Можно как-то запретить docker-compose удалять волюм з БД, такая проблема что не всегда но бывает что при очередном docker-compose down удаляет. Использую именованый том по типу app-postgres:/var/lib/postgresql/data . В чем может быть дело ? Возможно лучше использовать docker-compose stop ?

Ответить
ХОРХОЙ

гм.. Ну вроде как, есть рекомендации не гонять БД в docker в проде. например читал я про убитые БД mySql, убитые начисто(без возвозможности восстановления) при обычной остановке контейнера. Docker это прекрасная штука для разработки, но в проде он только для read-only (например для запуска программного продукта со всеми зависимостями. Но не для хранения данных. Если вам так принципиально иметь надежный сервер БД, то я бы на вашем месте поставил бы его локально, или на виртуалке/удаленном сервере. Просто закоментируйте в docker-compose, строки касательно сервера БД и в .env пропишите адрес и учетные данные нового сервера. И тогда любые действия с docker никак не будут влиять на вашу БД.

Ответить
Александр

тогда получается что базу нужно отдельно настраивать и таскать, вне конфигурации докер файлов, не очень удобно, но выход, спасибо

Ответить
Дмитрий Елисеев

Про убитые БД было немного статей помимо одного старого обсуждения. А так да, в продакшене можно ставить и отдельно, особенно если используются готовые сервисы вроде Amazon RDS для баз данных. Но если на продакшене сделать репликацию, то падение одного вольюма не удалит все данные.

Ответить
Александр

Правильно ли понимаю, самый надежный вариант это - для продакшн сборки - образы postgresql не включать, ставить postgresql прямо на сервер (например непосредственно через ansible), и прокидывать доступы на эту бд в контейнеры (php-fpm, php-cli) ?

Ответить
Дмитрий Елисеев

Если для какого-либо софта нужен прямой доступ к железу без прослойки в виде файловой системы вольюмов или если боитесь потенциальных багов в ней, то да, производительнее и надёжнее ставить прямо на сервер и потом у php-fpm указывать IP-адрес этой внешней БД. Но всё равно 100% надёжности это не даст, так как также может сломаться и простой сервер.

Ответить
Александр

А что если использовать просто монтирование папки, так даже новая версия субд не должна убить базу ? Какие есть плюсы и минусы в монтировании папки и использовании волюма ?

Ответить
Дмитрий Елисеев

Так мы и сравниваем эти два варианта:

  • Запускать Postgres в Docker, монтируя том.
  • Устанавливать и запускать Postgres на сервер как обычно без Docker.

Люди боятся именно поломок примонтированного вольюма из-за возможных багов докеровского драйвера, через который производится монтирование.

Ответить
Александр

Я имел введу способы:

  • ./data:/data - просто прокидывать папку
  • data:/var/lib/docker/pgdata- через волюм.

Или это почти одно и тоже ?

Ответить
Дмитрий Елисеев

Технически это одно и то же. Просто разные папки монтируются.

Ответить
Александр

ага, понятно, спасибо за ответ.

Ответить
fedot

Дмитрий, а мы будем смотреть репликацию баз данных и в идеале статики? Раз мы выбрали докер, нужно заботится о сохранности важных данных, какие есть методики? В аукционе мы вроде как, вообще всё прокидываем в контейнеры?

Ответить
Дмитрий Елисеев

Здесь не будем. А так в идеале можно взять образы bitnami/postgresql с готовой репликацией.

Ответить
fedot

Ясно, спасибо, попробую разобраться может.

Ответить
Дмитрий Елисеев

У меня удаляет только по down -v, так что проблем с этим не встречал. А stop не удаляет контейнер.

Ответить
Антон

при обновлении xdebug столкнулся с тем, что отвалился PhpUnit в phpstorm. Похоже, еще рано xdebug обновлять

Ответить
Андрей

У меня связка PhpStorm 2020.3 и XDebug 3.0.1 работает нормально.

Ответить
Андрей

Добрый день, Дмитрий!

Предлагаю при следующем обновлении проекта перейти на Docker 20.10, в котором, наконец-то, добавлена долгожданная поддержка host.docker.internal для GNU/Linux, что позволит нам избавиться от костылей - скрипта entrypoint.sh, добавляющего host.docker.internal в /etc/hosts при каждом запуске api-php-fpm.

Ответить
Дмитрий Елисеев

Да, спасибо! Там много нового в Changelog.

Ответить
Андрей

Небольшое тестирование показало, что Psalm 4, как и Psalm 3, все ещё имеет какие-то проблемы с кэшированием. По команде api-analyze-diff обновленный Psalm 4.3.1 не всегда понимает, что файлы были изменены и ошибки исправлены, в то время, как api-analyze всегда отрабатывает корректно.

Ответить
Дмитрий Елисеев

Да, это и имел в виду. Когда обновляем что-то в одном файле, проверки в зависящем от него порой не перезапускаются. Поэтому сделал две команды с кешированием и без.

Ответить
Александр

Поделитесь информацией, пожалуйста, кто может. Как кто работает на маке с докером, а то боль какая-то, docker for Mac - очень медленно, пробовал docker+mutagen - быстрее - но не стабильно, кэши время от времени отваливаются, плюс доп конфигурация, docker-sync - дополнительная конфигурация, неудобно. Более менее адекватный вариант нашел, с помощью вагранта. Запускаю виртуалку которая стартует make up - тоже дополнительная конфиграция (в виде описи виртаалки) но работает стабильно, но непонятно как Xdebug настроить...

Ответить
fedot

Да вроде работает норм аукцион на маке, апро Xdebug серия есть отдельная, тоже завелось. Но это Димина сборка, помню постгри надо было определенной версии, взял образ и исплевался, да еще кучу времени убил, думал скрипт не работает, а оказалось просто записи в базе через год появляются. Но аукцион сейчас почти пустой, а если под нагрузкой, то тоже неизвестно, что на маке будет. Потому для себя я вряд ли его буду использовать ну или для каких то не содержащих данных сервисов, например сдохло или встало на ручник, да и фиг с ним, перезапустил контейнер или виртуалку слепил, все настройки есть в исходниках. А как что делать, тоже более менее теперь понятно, за это Диме спасибо ещё раз.

Ответить
fedot

мохава операционка

Ответить
Андрей

На 33:33 два раза подряд воспроизводится кусок про --direct

Ответить
Юлия Елисеева

Спасибо! Исправила и перезалила :)

Ответить
Зарегистрируйтесь или войдите чтобы оставить комментарий

Или войти через:

Google
GitHub
Yandex
MailRu