После серии эпизодов про 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 для более удобной разработки.
Скрытый контент (код, слайды, ...) для подписчиков.
Открыть →Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram
Спасибо.
Спасибо, очень полезный урок. Не лучше ли использовать 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% надёжности это не даст, так как также может сломаться и простой сервер.
А что если использовать просто монтирование папки, так даже новая версия субд не должна убить базу ? Какие есть плюсы и минусы в монтировании папки и использовании волюма ?
Так мы и сравниваем эти два варианта:
Люди боятся именно поломок примонтированного вольюма из-за возможных багов докеровского драйвера, через который производится монтирование.
Я имел введу способы:
./data:/data
- просто прокидывать папкуdata:/var/lib/docker/pgdata
- через волюм.Или это почти одно и тоже ?
Технически это одно и то же. Просто разные папки монтируются.
ага, понятно, спасибо за ответ.
Дмитрий, а мы будем смотреть репликацию баз данных и в идеале статики? Раз мы выбрали докер, нужно заботится о сохранности важных данных, какие есть методики? В аукционе мы вроде как, вообще всё прокидываем в контейнеры?
Здесь не будем. А так в идеале можно взять образы bitnami/postgresql с готовой репликацией.
Ясно, спасибо, попробую разобраться может.
У меня удаляет только по
down -v
, так что проблем с этим не встречал. Аstop
не удаляет контейнер.при обновлении xdebug столкнулся с тем, что отвалился PhpUnit в phpstorm. Похоже, еще рано xdebug обновлять
У меня связка PhpStorm 2020.3 и XDebug 3.0.1 работает нормально.
Интересует как именно работает в связке с PHPUnit, так как у меня тоже отпал PHPUnit при версии XDebug 3.0.2
Напишите где именно возникает проблема. Я попробую у себя настройки посмотреть.
Добрый день, Дмитрий!
Предлагаю при следующем обновлении проекта перейти на 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 настроить...
Да вроде работает норм аукцион на маке, апро Xdebug серия есть отдельная, тоже завелось. Но это Димина сборка, помню постгри надо было определенной версии, взял образ и исплевался, да еще кучу времени убил, думал скрипт не работает, а оказалось просто записи в базе через год появляются. Но аукцион сейчас почти пустой, а если под нагрузкой, то тоже неизвестно, что на маке будет. Потому для себя я вряд ли его буду использовать ну или для каких то не содержащих данных сервисов, например сдохло или встало на ручник, да и фиг с ним, перезапустил контейнер или виртуалку слепил, все настройки есть в исходниках. А как что делать, тоже более менее теперь понятно, за это Диме спасибо ещё раз.
мохава операционка
На 33:33 два раза подряд воспроизводится кусок про --direct
Спасибо! Исправила и перезалила :)
Здравствуйте Дмитрий!
Решил обновить пакеты и получил такую ошибку. До этого все прекрасно обновлялось и работало, это не первое обновление. Запускалась команда docker-compose run --rm api-php-cli composer update или install.
Ошибка следующая:
так же
и еще ряд подобных ошибок!
Пинг на api.github.com идет, но и повторюсь в настройках каких то глобальных ничего не менялось. Этот пакет composer/package-versions-deprecated зависимость какого то другого пакета и как исправить такую ошибку опыта нет и в сети тоже ничего о подобной проблеме не нашел! Подскажите пожалуйста как лучше действовать в таких случаях (удаление папки vendor и перезапуск composer install не помогает, так как пакеты не догружаются и проект не собирается). Спасибо!
Где-то в вашей сети проблемы с DNS-кэшем.
Доброе утро, Дмитрий.
Подключил xdebug к проекту на Symfony 5.3. Пользовался этим уроком и уроком № 8.
Вроде бы всё заработало.
Если, например, взять файл public/index.php, то xdebug нормально работает.
Но если взять консольную команду RoleCommand и запустить xdebug через контекстное меню "Debug RoleCommand.php (PHP Script)", то всё заканчивается ошибкой Error: 255
Я что-то не так делаю или в чём причина?
Причина в том, что просто при запуске файла
RoleCommand.php
не инклюдитсяvendor/autoload.php
и автозагрузка классов не срабатывает.Отлаживать консольные команды нужно запуском bin/app.php через "Debug app.php (PHP Script)" с указанием аргумента
user:role
, как мы делали в 8 эпизоде с девятой минуты.То есть, в моём проекте нужно создать подобный файл?
Нельзя использовать node нечетной версии, там много экспериментальных функций, только четные: 12, 14, 16 )
Это да. Но у нас node не запускается в продакшене, а используется только для дев-сервера и для сборки React-приложения. Так что нам не страшно.
Или войти через: