Комментарии 106
В PHP меня расстраивает только один факт: я не могу писать на нем все-все-все, как на NodeJS. А так, я бы с удовольствием пилил на нем и мобильные приложения, и десктоп, и cli утилиты. Но, к сожалению, я не нашел популярного способа хотя бы упаковать PHP код в бинарник, чтобы его можно было распространять как есть, без необходимости ставить рантайм.
Ну можно сделать велосипед с архивом, куда придётся ложить ещё и интепритатор. Компиляция в бинарь была бы мега пушка, можно было бы хотя бы простые консольные штуки пилить, с ui сложнее
Да всё это было. Просто с ростом культуры кода забылось.
Могу поделиться упакованными екзешниками php 4.4 под винду, которые весят от 635кб до 1434кб (в зависимости от комплектации). При запуске выполняют рядом лежащий index.php (зловонный Index.php с демонстрацией окошек прилагаю)
https://yadi.sk/d/oZmQ9bQGgXawjQ
Естественно, можно было бы весь код упаковать в 1 файл, но тут весь смысл в переносе компилятора на любую машину с возможностью в блокноте написать нужный код. В армии это особенно принесло пользу — надо было написать скрипт по умному переименованию сотен-тысяч mp3-файлов (убрать префиксы и прочий мусор из названий). Накидал код в блокноте и готово.
php5 упаковывать уже накладно (выходит более 5мб), поэтому лучше dll класть в папочку и таскать с собой. Решения есть и под php7. Странно, что под php8 пока всё выглядит немного уныло даже с ffi уже в комплекте. Но это вопрос времени, как мне кажется.
Так в ноде насколько я знаю тоже нет варианта упаковать все в один бинарь.
Есть — https://www.npmjs.com/package/pkg
Правда под виндой у меня бинарник выходил больше 40мб точно
выучить библиотеку для написания чего-то нового по времени и трудозатратам ничем не меньше, чем выучить новый подходящий для этого язык.
Стоит учитывать, что библиотеки основные фишки языка сохраняют, а вот языки, особенно не мейнстримные, могут весьма значительно различаться
Но, к сожалению, я не нашел популярного способа хотя бы упаковать PHP код в бинарник
Было что-то лет пятнадцать назад, но особо не взлетело.
В PHP меня расстраивает только один факт: я не могу писать на нем все-все-все, как на NodeJS.
Можете. На чистом PHP без каких-либо дополнительных экстеншенов, которые идут через pecl. У меня пока не возникало такой задачи, где бы на пыхе это нельзя было реализовать.
Разве что сталкивался с проблемами uint64_t, в OpenGL, но оно обходилось явным выделением памяти под этот тип, а оверфлоу будет только при касте к пыховскому инту (который не unsigned).
А так, я бы с удовольствием пилил на нем и мобильные приложения, и десктоп, и cli утилиты.
И кто мешает? С мобилой сложнее, нужно через terminus запускать, а не паковать в apk. Но в теории можно придумать и нормальный запуск. Не копал в этом направлении от слова "вообще", но раз на сишке можно писать под мобилу, значит и на пыхе можно, просто чуть иначе перепаковать бинарь.
Но, к сожалению, я не нашел популярного способа хотя бы упаковать PHP код в бинарник, чтобы его можно было распространять как есть, без необходимости ставить рантайм.
Тут или шашечки, или ехать. Java, JS или любой другой платформонезависимый код поставляется с рантаймом. Никто не мешает поставлять в своей сборке и бинарь рантайма, как это делается, например, в случае с IDEA. С точки зрения реюзабельности — это самый профитный вариант.
Короче, я веду к тому, что вам не так уж это и нужно, раз не нашли способа. Благо уже более года на чистом пыхе можно хоть голый ассемблер исполнять.
Про джаву не совсем правда-она вполне успешно компилируется в бинарь, хотя немогу сказать что это распространенная практика-чаще если пакуют то кладут рядом JVM.
После доклада Дмитрия Стогова о JIT на PHPFest 2020 был вопрос:
Планируется ли версия PHP, которая будет компилировать код в бинарник (по аналогии с C или Go)
Дмитрий ответил:
Нет, не планируется, хотя в принципе я не вижу ничего сложного — для этого всё уже есть… Если вы хотите распространять close source проекты и зарабатывать деньги, тогда пожалуйста, сами делайте
А разве
Нет, не планируется
Не ответ на ТОТ вопрос?
Мотивация создания бинарников не понята, наверное. А потому ответ может быть не на ТОТ вопрос.
Лично мне она нужна для удобства инхаус разработки и эксплуатации )Это если говорить именно об исполнимом бинаринике/ Ещё хотелось бы аналог .pyc файлов в python
Неа. Он содержит только php код. Если бы ещё, например, расширения вкладывались то частично бы подошёл
Мне это нужно, чтобы упростить ежедневную работу, а не усложнить ) Коробочным решением с удовольствием бы пользовался — в гоу понравилось когда его немного пробовал, а что-то костылять плохо стандартизированное… Лучше уж докер-контейнерами доставлять — стандарт де-факто уже можно сказать. Если админы-девопсы есть, то им даже специфика ПХП особо не нужна
Я ж так и написал. Более того, вот вчера сделал пайплайн:
На билд-сервере:
- чекаут репы
- сборка образа
- пуш образа
Идём на прод: - пулл образа
- создаем контейнер
- копируем из него файлы на хост )
- удаляем контейнер, так и не запустив
Просто аналог зип-архива, например
В PHP меня расстраивает только один факт: я не могу писать на нем все-все-все, как на NodeJS.Вы и на ноде не можете. Просто php-разработчики обычно не испытывают иллюзий по поводу границ применимости своего языка.
Здесь должна быть шутка про «Один пацан писал все на JavaScript...»
Есть babel-preset-php, который синтаксис PHP7, кроме деструкторов, ссылок, die(), суперглобальных массивов с данными запроса и еще некоторых моментов транспилирует в JS, который можно обернуть в Cordova/PhoneGap и получить десктопное или мобильное приложение.
Реальных проектов не видел.
На данный момент jit можно включать, но это экспериментальная фича и возможности сборки нативных приложений нет. Но движение в этом направлении есть.
разработчики обещают, что скоро возможность создания приложений появится. Мол, язык уже давно вырос, окреп, и в своей серверной нише ему тесновато.
Ээээ… Эти утверждения вы придумали только что? Дима тыщу раз повторял, что этого ничего не будет. А, мол, если надо — пилите сами, благо не сложно (с) почти цитата
Ну т.е. откуда эта информация?
Важно разделять понятия «построение нативных приложений» и «компиляция в закрытый бинарник». Это не совсем одно и то же. Особенно когда речь идет о JIt-компиляции.
Стогов против второго, но ничего не имеет против первого.
Стогов против второго, но ничего не имеет против первого.
А с чего ему иметь? Я кажется тоже самое написал: "Хотите делать — делайте".
И попросил пруфов на тему того, цитата: "разработчики обещают, что скоро возможность создания приложений появится". Но при этом никто никогда не обещал, что "вы сможете билдить полноценные и самодостаточные бинари".
Или вы имели ввиду возможность создания их в целом своими силами? Если в целом, то она ещё в PHP 4 была (или когда там появился embedded sapi?). Тот же мёртвый нынче Devel Studio работал так, брал и подрубался к API PHP через Delphi, а потом это всё в бинарь один собиралось. Делайте, никто не запрещает.
Это, конечно, все хорошо но мне что-то подсказывает, что написание своего статического анализатора и ORM потому, что «других нормальных нету» — это не совсем то, что ожидают от полноценной экосистемы абстрактного языка в вакууме
А кто мешает? Я писал такое ещё на PHP3. Открываем сокет слушаем обрабтывае. Да, синхронно, да однопоточно, да память текла во всю тогда… Сейчас со многим лучше. Генераторы вон можно прикрутить
А ничего, что в ноду многопоточность только недавно завезли (и то не факт, что прикрутили к эвентлупу, тут надо жсников спрашивать), а раньше как бы никого это и не волновало особо? В чём отличия-то?
Автомасштабирование в кубере или ещ' где настраиваем — полушутка
habr.com/ru/post/451916
5minphp.ru/episode49
Хотелось бы все-таки, чтобы -S годился для прода просто как запускальщик index.php условного для микросервисов
За второй не скажу, но с первым в докерах или типа того постоянно нюансы: их в один контейнер помещать с супервизор или системд или в разные. Чистую статику из пхп-фрейма как веб-серверу давать. Пользовательскую.
Да и вообще, два компонента обычно сложнее в разработке, разворачивание поддержке чем один.
Я знаю эту философию, поэтому и вопрос вечно этот возникает, каждый раз когда в контейнер пытаешься пхп-фпм положить — в расшаривание файлов между контейнерами много нюансов.
P.S. Облачные сервисы не рассматриваем по ряду причин, кроме как базу для подъёма виртуалок и сетей между ними. И то, обычные хостеры предпочтительней, особенно если АПИ дают по цене обычного ВДС хостинга. А так на текущем проекте обычные дедики
Так про всё можно сказать, что «есть много нюансов» :)
Есть нюансы типа "Пошарить файлы между контейнерами можно или через том, или через биндинг папки хоста. В том файлы из образа копируются только при первом монтировании тома, в папку хоста вообще не копируются"
Ту, что решается по ссылке на 5-м шаге с помощью --volumes-from, который если не deprecated ещё в самом docker, то точно к лучшим практикам не относится.
Задача в целом такая: папка в одном контейнере должна быть примонтирована в другой. На практике: есть контейнер с приложением в /app/public/ которого лежат какие-то статические файлы, нужно это папку примонтировать в /var/www/html контейнера с nginx или apache. Усложнённый вариант: первый образ не просто содержит в папке файлы из билд-тайма, но и активно создаёт их сам в рантайме.
Обычный кейс: контейнер с пхп /app/public которого нужно смотнтировать в /var/www/html контейнера с nginx. Докер 20.10.
Если что я не про глюки или ещё что, а про документированное поведение, но его нужно знать наизусть, чтобы не принимать документированное поведение последней стабильной версии за "артефакты или докер пятилетней давности"
php:
...
volumes:
- /var/www/public:/app/public
nginx:
...
volumes:
- /var/www/public:/var/www/html
Там же пусто будет! Или вы при каждом деплое на проде будете из CD делать что-то вроде:
docker build -t app:$tag .
docker create -name app-$tag app:$tag
docker cp app-$tag:/app/public /tmp/app-$tag-public
rsync /tmp/app-$tag-public/ production:/var/www/public/
?
Есть две практики:
— докер содержит вселенную, код монтируется отдельно. Это характерно для дев- и стейдж-сред, и мой вариант отлично подойдет — мы подмонтируем папку с кодом, код управляется отдельно через CI/CD, ansible и т.д.
— докер-образ уже содержит код. Это фиксированная среда, допустим для прода. Тогда я не понимаю, зачем нам монтировать вольюм, когда мы можем положить код в каждый образ через мультистейдж-сборку. Рантаймы же, если они нужны — снова-таки через общий хостовый вольюм, если они по архитектуре лежат внутри папок с кодом — окей, унесем симлинками.
Речь в целом не про код, а про данные, но ладно. А вы только подтверждаете мои слова про "есть нюансы":
- код/данные откуда-то должны взяться — деплой через git pull?
- CI/CD ансибль нужны
- дублирование данных по контейнерам (а их там сотни мегабайт может быть легко), усложнение и увелечине времени сборки (а мог бы быть базовый nginx прямо с хаба, ладно докерфайл с одним копированием конфига)
Я ещё вариантов решения могу набросать:
- волюм полноценный, ентрипоинт копирует в него из контейнера при старте перед запуском основного процесса
- вообще на сервере эти даные не храним — хоть с3, хоть гитхаб пэйджес
У каждого варианта есть плюсы и минусы, с разным весом в разных ситуациях. И заведомо они могут быть неизвестны, например какой трафик будет и соответственно какой счет выставит амазон
И это всё нюансы простой задачи расшарить папку между контейнерами. Часто проще плюнуть на идеологию докера и запихать два процесса в контейнер плюс супервизор
Со своей стороны хочу добавить — что это вообще не мешает жить :)
С одной стороны, да, не особо мешает: выбрал какой-то способ (для меня по дефолту — мультистейджинг, как требующий вовлечения минимума лишних сущностей), настроил раз, пускай и кучу времени потратив, и забыл.
С другой, рано или поздно вылезают какие-то траблы и понимаешь, что надо всё переделывать
Философия докера: один контейнер — один процесс.
Ну вот и получается что микросервис на php невозможно задеплоить менее чем в двух контейнерах. Является ли это достоинством?
посмотрите на nginx unit
Ну вот и получается что микросервис на php невозможно задеплоить менее чем в двух контейнерах.
Простите, а этот тезис с потолка взят? Или для вас нормально в прод (раз уж про деплой заговорили) выкатывать сервисы без супервизора, балансеров, взрослых серверов и прочего "баловства"?
Нормально один nginx на N php-fpm пулов или даже процессов (разные версии пхп например) на одном сервере под управлением системного systemd. С докером же это не очень нормально получается — выходит 1+N процессов nginx чтоб более-менее удобно деплоить отдельные приложения/сервисы
Для начала стоит определиться с тем, что используется:
1) nginx — это внешний сервер.
2) fpm — это супервизор для php с fcgi гейтом.
3) systemd — это ещё один супервизор (и крон в т.ч.) под всё остальное.
Два из этих сервиса (fpm + systemd) — это супервизоры, а значит должны быть непосредственно прибиты к контейнеру, в котором они там что-то менеджерят. Ну или делать это снаружи (например systemd может мониторить докер контейнер), так?
Получается, что у нас только один контейнер с fpm, который открывает наружу порт к которому nginx уже коннектится через fcgi.
А если подобная ситуация не нравится по какой-либо причине, то они выкидываются, а nginx разворачивается как реверс прокси и/или балансер напрямую на пыховский сервер (благо их туча: amp, react, swoole, PEAR, etc).
Ну или я что-то не понимаю… По два-три раза прочитал комментарий что этот, что ранее аналогичный, но так до конца и не уверен, что понял проблему полностью.
P.S. А ещё вместо fpm можно взять roadrunner, он выполняет примерно ту же роль процесс менеджера, что и сабж. И вместо контейнера с fpm надо будет стартовать уже rr. Остальные телодвижения примерно те же самые.
Типичный (для меня и вообще на просторах мануалов и туториалов) сетап сервера для нескольких пхп приложений (на примере убунту по памяти)
- nginx c конфигами для статики и fastcgi_pass в /etc/nginx/sites-enabled/* для каждого приложения
- php-fpm c конфигами в /etc/php/7.4/fpm/pool.d/* для каждого приложения со своим портом/файл-сокетом
- всё это systemd держит
На докере обычно получается, что приложение — это два контейнера в связке с конфигами для выделенного nginx и php-fpm. Или запихнуты в один плюс, обычно, supervisor. Плюс общесистемный nginx или haproxy (trаefik вроде тоже) как http reverse proxy в качестве чисто http роутера/"ингресса"
Хотелось бы чтобы php приложение было в одном процессе, слушало http, эффективно раздавало статику из публичного каталога приложени, ну и обслуживало динамику. И всё это гибко, очень гибко, настраиваемо на уровне билда или старта контейнера/ Как рабочий функционирующий пример: apache2+libphp или вон в комментах узнал про nGinx Unit.
Так понятнее? )
Блин, это мне целую простыню текста придётся писать, что б пояснить своё мнение развёрнуто. Но постараюсь...
В общем, есть БД для небольших приложений под небольшую загрузку, которые не требуют оркестарции — sqlite. Это вполне себе production-ready решение, но для определённого круга задач. Когда из мелкого сервиса оно превращается в большой — возможностей sqlite уже не хватает и народ переезжает на полноценное ПО, которое предоставляет больше возможностей — pgsql/mssql/etc, так?
С серверами всё точно так же. Если не нужно ничего особо крутого, то в node достаточно использовать express, в ruby webrick, а в php перечисленные мною выше в заминусованном комментарии. Они вполне эффективно (и местами эффективнее, нежели nginx), отдают и статику, и гибкие, и настраиваются в билде и вообще всё, что вы перечислили, просто потому что написаны на том же PHP. И не надо ничего ставить кроме самого PHP. Но при масштабировании требуется уже больше возможностей, поэтому ставят специально заточенное под это дело внешнее ПО.
В вашем случае — вы изначально воспользовались крутыми сторонними решениями, предназначенными для масштабирования, высокой нагрузки и поддержки всего, что есть в вебе. Но что мешало, если не нужно такого — не стрелять из пушки по воробьям, а воспользоваться более простыми аналогами, написанными на том же PHP?
Ну как-то так…
Когда из мелкого сервиса оно превращается в большой — возможностей sqlite уже не хватает и народ переезжает на полноценное ПО, которое предоставляет больше возможностей — pgsql/mssql/etc, так?
В мире PHP обычно всё же по умолчанию mysql, за сотни собеседований от трейни до лида второй команды только пару человек вообще пробовали с ним работать.
Так и с остальным, наверное. Раньше apache+modphp стандартом де-факто для самого простого хелловорда были, потом nginx+php-fpm, сейчас — они же в докере (с кмпозом в качестве оркестратор), хорошо если не кубер поднимают для бложика на вордпресе. При этом вопрос масштабирования/отказоустойчивости если и поднимается при выборе этой части инфраструктуры, то только горизонтального и бэкапов. В крайнем случае в уме держат реплику мускула для отчётов и тех же бэкапов.
Думаю, популярность этого связана с простой, если не самих средств, то их разворачивания и минимального конфигурирования путем копипасты нескольких готовых конфигов. Да даже ещё раньше, со времён массовой популярности апачи виртхостингов, где вообще свой софт установить или свой cli php процесс запустить нельзя было. Это всё досатточно простое чтобы стать, скорее всего, самым массовым способом создать работающее веб-приложение. При этом с большим запасом "прочности" когда задачи становятся сложнее. Тепрь туда добавился докер и идёт кубер. И, не дай бог, сделают лямбды на авс нативные )
Swoole (на С написан скорее всего) и ко для тех, кто вырос на LAMP и продолжателях, сложнее по факту. Скорее рассматривается как "вот понадобится масштабироваться, работать асинхронно и т. п. — у нас есть такие варианты в запасе чтоб не переписывать всю кодовую базу на Go/Kotlin"
P.S. плюсиков добавил — интересный диалог
Не, ну понятное дело что cgi удобнее демона по части забивания болтов на утечки памяти, отсюда и любовь к "классическим связкам". Но с другой стороны тут претензии были выше от mayorovp к тому, что PHP не умеет вообще никак иначе.
Ну и, думаю, довольно странно при таком количестве технологий закрывать на это глаза и рефлексом ставить "sudo apt install php-fpm". Для какого-нибудь хоумпейджа никто не запрещает поэкспериментировать с другими технологиями, которые могут вполне оказаться и удобнее в оркестарии и стабильнее.
P.S. Для бложиков я уже поднимал sqlite и могу сказать, что разницы с mysql вообще не заметно (при такой-то нагрузке, которой особо и нет). А это значит, что на VPS можно вполне минуснуть пол гига оперативы и кусок места на харде, просто избавившись от mysql в пользу локальной sqlite.
Тоже касается и React + Swoole (другое не проверял). Полёт вполне себе нормальный. Так что уже начинаю воспринимать не как "модную шняжку", а как вполне себе рабочее решение, которое можно и на чуть более серьёзных проектах использовать.
Бывает же. Первый раз вчера за 8 месяцев работы прилетела задачка оценить разработку почти стороннего для основной системы демо-сайт, даже без технической интеграции любой, чисто брендовость общая. Прочитал ваш комент в 2 часа ночи и до 7 утра экспериментировал со Swoole. Поднял в докере http/ws сервер. чатик в памяти — вроде работает. Впечатление двойственное: давно такое низкоуровневое и, я бы сказал, процедурное чуть ли не PHP3, и без поддержки в IDE нормальной не писал (ide-helper помогает, но не сильно — они сами признают, что он минимальный, но развивать нет ресурсов особо). И документация какая-то специфичная для таких проектов.
А с другой стороны работает, правда нагрузки не делал пока. В любом случае спасибо, что так вовремя "заставили" попробовать.
У меня примерно схожие впечатления были, когда с ним игрался. Вебсокеты почти самому приходится писать. Плюс ещё он периодически работал совершенно неочевидно, то ли баговался, то ли у меня руки из одного места.
Так что лично я бы выбрал лучше React (если о качестве исходников говорить) или Amp (если об удобстве использования).
в node достаточно использовать express, в ruby webrick, а в php перечисленные мною выше в заминусованном комментарии
Я бы не надеялся на качественную и эффективную обработку https и раздачу статики в стандартных языковых библиотеках. Точнее, она наверняка сильно уступает таковой в nginx и его конкурентах.
И забудете о всех межпроцессорных штуках
Нужно пообщаться между скриптами — memcached, реббит, редис
Это не легаси-код, это PHP