Comments 8
Это конечно мощно. Сам подобным развлекался. Если нужна именно последняя ICU, то remi, наверное, не поможет. Но не проще ли бы нужный проект в контейнер упаковать, где и нужный pho и нужная ICU готовая может быть? cli в контейнере запускать проще, чем вот это всё.
Судя по лайкам, совет полезный, спасибо (а уделенное время в субботний вечер вообще бесценно)! Но я никак не могу его до конца осознать :(
Не проще ли нужный проект упаковать в контейнер
В конкретном случае - нет, не проще. В общем случае - тоже. Чтобы положить проект в контейнер, нужно знать все его реальные зависимости, уметь собирать контейнер, настраивать доступ к внешним ресурсам, а также учитывать риски для стабильной работы прода в процессе такого архитектурного апгрейда. Возможно, это правильнее, но точно не проще.
где и нужный php и нужная ICU готовая может быть
От того, что проект переедет в контейнер, версии php/icu сами по себе не поменяются. Или мы заодно будем обновлять версию php? Но тогда придется обновить и код, фреймворк, вендоры - а это уж точно не проще).
cli в контейнере запускать проще, чем вот это всё
Речь ведь не только о cli. Но даже если о нем, все равно будет выполнятся код проекта, который подразумевает старую версию php.
Если же совет в том, чтобы не рисковать продом, а воспроизвести нужное окружение в докере и уже там выполнять сборку - с этим полностью согласен!
Но я никак не могу его до конца осознать :(
Ну, первое просто. Remi это сторонний репозиторий, в которых собирают свежий софт для старых CentOS и производных. PHP вообще позволяет несколько версий параллельно установить и переключаться какая станет "системной".
В общем случае - тоже. Чтобы положить проект в контейнер, нужно знать все его реальные зависимости, уметь собирать контейнер, настраивать доступ к внешним ресурсам
Нет, конечно. Вы буквально занимались пердолингом с предсказуемым результатом: "Здесь нам сообщается о том, что что-то в новом коде ICU несовместимо с чем-то в старом коде php intl. Невероятно!". Уверен, что раскапывание информации по сборке, компиляция, написание скриптов заняло н-ное время. Скорее всего за то же время можно было бы разобраться как взять образ последнего Ubuntu или php в Ubuntu, сделать на его основе свой контейнер (файл вышел бы короче скриптов) с php cli, php-fpm, доустановленными необходимыми пакетами и вшитыми туда исходникам сайтов.
Затем запускать его через podman run --rm из systemd unit и получить практически аналог стандартного демона php-fpm, только с вашей новой php и новой ICU.
Но даже если о нем, все равно будет выполнятся код проекта, который подразумевает старую версию php.
Если сайт не совместим со старой php, то да, проблема серьёзнее. Хотя по возможности разумнее задуматься об обновлении сайта. Но если это невозможно, опять же, контейнер (для запуска, не для разработки) подходит больше. Почему? Они изолированный. Вы мучались с тем, чтобы собрать ICU отдельно, чтобы не повредить системную библиотеку, потом чтобы параллельно собрать php.
Ну, или можно было взять минималистичную установку Ubuntu или минидистрибутива, вроде Alpine, в которых есть последний gcc и просто собрать ICU и php уже без всяких конфликтов и рисков.
Но самое главное это обслуживание. Вот понадобилась через пол года ещё более новая ICU, что вы будете делать? Читать свою статью на Хабре, качать скрипты с github, старательно проходить все пункты? Или всё это может быть в виде инструкций записано вDockerfile и пересоберётся одной командой.
Ага, понял!
Выходит, контейнер действительно грамотное решение, позволяющее настраивать окружение, не боясь испортить все остальное! Обязательно попробую это на каком-нибудь проекте попроще. Спасибо!
Но в данном случае 99% мучений не в том, как собрать так, чтобы не испортить остальное. А в том, чтобы собрать вообще)
Если проект можно перевести на новую версию php в которой intl с подходящей ICU, то о чем вообще говорить?
Но если проект привязан к конкретной версии php, и для нее не находится intl с нужной ICU, что тогда?
Я действительно потратил кучу времени, чтобы все это раздуплить. Спасибо, что обратили внимание!
Кстати, камень в огород хабро-редактора статей
Хотя еще больше времени ушло на то, чтобы все это описать. В том числе из-за того, что редактор Хабра стал работать просто мерзко, непрерывно портя содержимое статьи, пока работа шла в черновике. Раньше такого не было, техподдержка пока молчит.
Для обслуживания не обязательно каждый раз читать статью (хоть я и не против). В ней приведены скрипты, настроив которые один раз, дальнейшую сборку можно выполнять за пару минут, просто меняя версию ICU и запуская скрипт (проверено на ICU от 72 до 78 с небольшими пропусками).
make install
А в Centos не принято нормальный пакет собрать вместо вот этого вот?
Может и принято, я в этом нубас. А какие преимущества даст нормальный пакет (rpm?), если ICU здесь собирается только для конкретной версии php расширения?
Обслуживание. Вышла новая версия? rpmbuild -bb. Случилась авария и ваш VPS снесли? dnf install. Ну или пол дня на сборку всего вручную.
Звучит логично, спасибо!
Сейчас инфа об этом написана в соответствующем разделе конфлюенса по разворачиванию проекта и установке зависимостей (и добавлен запуск скриптов в Dockerfile для локальной разработки). Но если у кого-то сделано разворачивание по уму через пакеты, то наверняка есть смысл и эту штуку так сделать.
В остальном же расширение прилинковано к ICU крепко, и с сервисом должно действительно случится что-то страшное, чтобы пришлось заново создавать.
Обнови ICU в PHP 7.3 intl на Centos 7, если осмелишься