Комментарии 26
Существует бэкенд на php, есть задача уведомить клиентское приложение о наступлении некоего события. Можно делать много запросов из клиента на бэк. А можно сделать, как в данном примере. Это не образец передового архитектурного решения, это выход из сложившейся ситуации
Обычный Ratchet не устраивает?
Ну или уж https://github.com/walkor/phpsocket.io
Зачем создавать винегрет?
Действительно, надо было взять centrifugo и не париться.
p.s. Ratchet еще живой?
Как-то пульс слабый.
p.s. 2 года назад я делал проект с активным использованием Ratchet. И делать больше так не буду. Ваш же довод про винегрет для меня лично кажется странным.
Как-то пульс слабый.
А вы желаете видеть каждый год новую версию молотка?
Теперь уже с истинно перламутровыми пуговицами?
Ваше право.
Но поддерживать единый стек технологий в команде 2-20 человек намного проще и эффективнее, чем иметь кашу в виде nodejs, go, haskel, php, ruby, python. Банально даже из-за кривой обучения и объема памяти конкретного человека
Ваше право.
Я помню что у ratchet (и reactphp) были определенные проблемы, и больше не хочу с ним связываться. Если уж WS на php — можно посмотреть в сторону ayres. Но это для любителей пописать велосипеды.
Но поддерживать единый стек технологий
Вы видимо меня не правильно поняли. Я ратую за то что бы вообще ничего не писать. Возьмем centrifugo. Он не требует от вашей команды знаний go. Это конечный продукт который просто интегрируется в проект. Вам не надо ничего писать. Более того, у него все хорошо и с масштабированием и со стабильностью. Единственное ограничение — в него слать на сервер ничего нельзя (ну как нельзя, не рекомендуется, не предназначен он для этого).
Или вы скажите что такой подход не эффективнее?
Да и потом. помимо этого варианта существуют и другие, которые не требуют наличия демонов на php (я не то что бы против демонов на php, сам их активно пишу, но это я и мои проекты, а большинству в этом плане я не особо доверяю). Например один из интересных вариантов — pushpin
В любом случае нам будет выгодно реализовать логику как сабскайберы, а не вшивать ее в сервер. Websocket сервер же оставить максимально тупым. И без разницы на ratchet у нас сервер или на haskell в этом плане.
И не надо преувеличивать про объем памяти конкретного человека. Просто не надо запоминать несущественные вещи вроде сингатур методов, синтаксиса и т.д.
include fastcgi.conf; Если только не требуется что-то нестандартное.Спасибо за замечание. Порты наружу открыл в демонстрационных целях. Собственно, сервер и клиент открыты через nginx. Socket.io тоже получается нужно открывать наружу, иначе клиентский браузер к нему не достучится.
Про fastcgi согласен. Конфигурация у nginx далеко не образцовая. Цель была продемонстрировать возможность
Возможно, мы по разному трактуем термины. Было бы проще, если были бы конкретные примеры этих решений. Эти решения можно использовать в связке с SPA, например на Angular?
Слабенький пример докеризации. Большими жирными буквами надо написать "чисто для ознакомительных целей, не делать так в продакшене".
Навскидку:
- конфиги типа nginx если и монтировать, то в только дев-режиме, вообще они должны быть включены в образ.
- зависимости npm должны устанавливаться при билде образа
- исходные файлы (php, js, html) должны копироваться в образ
Тестовость данного проекта очевидна. Все контейнеры сложены в один только в демонстрационных целях. Чтобы можно было одной командой развернуть и попробовать.
А с замечанием полностью согласен.
Чтобы образ можно было запустить на любой машине, например на продакшен сервере.
Не считаю истинно правильным копировать исходные файлы (php, html, js, etc) в образ. Часто использую docker контейнер для одинакового окружения (настроенная версия php, nginx, mysql), а в отдельном репозитории с git'ом хранить команды для запуска сборка образа (как правило docker-compose) и весь исходный код. Все доступы в .env файле, которые не выкладываются нигде.
Тут почему никто не говорит, что если вы сохраните данные в образе, то при выполнении команды down для контейнеров, образ вернется на стадию "упакования".
В общем, по моему скромному мнению:
- в docker хранится образ окружения (несколько контейнеров, которые выполняют свою роль)
- исходный код (ваши php файлы, html, css, js) хранятся в отдельном репозитории и подключаются монтированием к образу (подробнее прочитайте про volume)
- база данных (к примеру) — подключается также монтированием папки с базой
Я не понимаю, зачем вам хранить данные в образе. Если вы запустите образ с данными на другой машине, то там данные будут не актуальны. Куда правильнее использовать репликацию и так далее, но это уже совсем другая история. Разве что видел интересный кейс c копированием верстки на react/angular в образ, но там смысл есть.
Тут почему никто не говорит, что если вы сохраните данные в образе, то при выполнении команды down для контейнеров, образ вернется на стадию "упакования".
Это подразумевается по умолчанию, предполагается, что люди читали документацию по докеру: "When a container is removed, any changes to its state that are not stored in persistent storage disappear."
Я не понимаю, зачем вам хранить данные в образе.
Кто говорит про данные? Речь про код и конфиги. Данные, состояние хранится либо в volume, либо вообще вне контейнера или даже вне докера.
Как вы будете деплоить свое приложение на продакшен сервер? Особенно, если всё, что на нём есть — это ядро ОС и сам docker. Вот реально больше ничего, ни ssh, ни ftp, ни даже хоть какой-то консоли физической. Докер не умеет заливать файлы на удаленную машину, только в контейнер. Да, вы можете в образе или при удаленном запуске контейнера сделать volume (хотя не обязательно), а потом с локальной машины или деплой-сервера через docker cp скопировать файлы приложения на удаленный сервер. Можете даже разделить запуск на создание и старт: создать конейнер, скопировать в него код приложения, запустить, чтобы не получить ситуацию когда сервер работает, но кода нет.
Можете, но зачем, если их можно сразу включить в образ, сразу одной командой docker run с любой машины, включая те, где исходников нет, хоть с телефона, получить работающий сервер на удаленной машине, где ничего кроме ядра и докера нет.
Докер предназначен для упаковки и запуска приложений в контейнерах. Ваш сценарий — это сценарий упаковки и запуска приложений nginx, php-fpml и т. д., которые как данные получают ваш код. Но обычно цель не запустить эти приложения, скормив им какие-то данные с локальной машины, а запустить ваше приложение, которое где-то под капотом будет использовать эти приложения.
В целом volume, примонтированный на локальный каталог с исходниками или результатами билда — это хак, для упрощения локальной разработки, чтобы не билдить образ на каждый чих и не перезапускать. Ни докер в целом, ни его фича volume для этого не создавались. Докер создавался, чтобы всё приложение упаковать в образ, который можно без проблем запускать на разных машинах, в том числе удаленно, лишь бы там был запущен сервер докера. Функциональность volume создавалась, чтобы разделять данные (не код) между контейнерами, прежде всего между контейнерами из одного образа. Монтирование volume на конкретный каталог в локальной ФС — в целом противоречит идеологии докера, хотя без него в некоторых ситуациях сложно обойтись.
Если данные не скопировать в образ и попытаться запустить его например на AWS, то некрасиво получится, так как они (данные) в этом случае будут недоступны.
Публикации
Докеризируем Socket.io, redis и php