удаленный запуск скрипта php
Как запускать долгоживущие скрипты на удаленном сервере
Давайте подключимся по ssh к нашему серваку. После подключения сразу создадим новый скрин:
После этого мы оказываемся в новом терминале без какой-либо истории. Давайте выполним теперь в этом терминале какую-нибудь команду. К примеру:
После чего можно попробовать отключиться от терминала. Для этого нужно сначала нажать сочетание клавиш CRTL + A, а затем нажать клавишу D.
В терминале, из которого мы запускали скрин, мы увидим уведомление о том, что мы отключились от скрина: 
Теперь давайте снова подключимся к этому скрину. Для этого воспользуемся той же командой:
Вжух! И мы вернулись в тот же терминал, с тем же контекстом, от которого отключались. 
Давайте теперь для имитации долгоиграющей команды напишем вот такой простецкий PHP-скрипт:
И запустим его в нашем скрине: 
После чего отключимся от скрина сочетанием CTRL+A, затем D.
Затем снова подключимся:
И увидим текущий статус выполнения скрипта. 
Можете также отключиться от сервера и снова подключиться к нему по ssh, проверить, что всё работает.
Чтобы завершить скрин, нужно нажать сочетание клавиш CTRL+D. В таком случае мы получим сообщение о завершении, а не об отключении от терминала:
Смотрите, не перепутайте сочетания клавиш =) Теперь если снова запустить
будет снова создан новый терминал.
Если нужно иметь полный лог происходящего, то лучше писать вывод команды в лог-файл. Например, запустив в скрине команду:
Следить за изменениями в логе можно с помощью команды:
Всё, теперь никакие разрывы соединений нам не страшны. Всем успешных миграций 😉
Script-server. WebUI для удалённого запуска ваших скриптов
Всем привет. В данной статье я бы хотел рассказать про свой домашний проект. Если коротко: Script server является веб-сервером для предоставления пользователям доступа к вашим скриптам через web-интерфейс. Сервер и скрипты запускаются локально, а параметризуются и показываются удалённо.
Предыстория
На новом месте работы, первые мои задачи были весьма рутинны и однообразны. Схематично они выглядели так:
Надо сказать, что к определённому моменту подобные задачи уже перестали на меня назначать и у созданных скриптов без необходимой адаптации было очень призрачное будущее.
Поэтому я решил создать инструмент, который позволит удалённо запускать мои скрипты другим людям, без необходимости создавать необходимое окружение и в более удобной форме настраивать их запуск.
На пути создания
Схема работы
Администратор сервера (т.е. я) создаёт файлы конфигурации для каждого скрипта, в которых описывает предназначение скрипта, путь запуска и требуемые параметры. Эти файлы конфигурации используются сервером для предоставления данных о скриптах пользователю, а также для их запуска. Информация на страницу пользователя передаётся Ajax запросами.
Пользователь заполняет параметры и запускает скрипт на сервере, где его выполнение передаётся специальному обработчику. Обработчик в асинхронном режиме принимает input и предоставляет output, а также следит за процессом выполнения скрипта.
Веб сервер служит прослойкой между этим обработчиком и страницей, и через веб-сокеты осуществляет обмен данными.
Выбор инструментов
В то время я учил Python и для разработки решил использовать именно его, как неплохую практику. Для проекта был выбран Python 3, без поддержки 2й версии, поскольку необходимости в этом нет, а тратить лишнее время не хотелось.
В начале разработки для сервера я использовал Flask, но не смог сделать (читай разобраться) с асинхронностью и отслеживанием подключения/отключения клиентов, поэтому довольно быстро перевёл все на Tornado.
Касаемо web разработки: Web-разработчик из меня никакой, поэтому здесь я тоже решил немного попрактиковаться в синтаксисе и основах. В связи с этим не было использовано почти никаких фреймворков и библиотек, за исключением materializecss для более-менее приличного оформления.
Web страница представляет собой «одностраничное приложение» с минимумом HTML и созданием контента в JS по Ajax запросам.
Первая эксплуатация и улучшения
Примерно через месяц у меня получился сервер, который худо-бедно можно было использовать и я поделился им с коллегами-разработчиками, которым тоже приходилось выполнять эти рутинные задачи (которые как назло в этот период почти закончились).
В процессе эксплуатации были обнаружены как баги, так и явно недостающие элементы, над которыми я потихоньку работал и улучшал. В то же время были добавлены мелкие улучшения, такие как типы параметров, логгирование всех запусков и т.п.
Интересный момент: для некоторых мелких задач (связанных с работой в консоли и со скриптами) я также перестал пользоваться консолью, а перешёл на этот UI. Т.е. у меня заведено несколько конфигураций скриптов, которые я использую чаще, чем другие люди.
Эксплуатация реальным пользователем
Спустя некоторое время локального тестирования (мною и другими разработчиками), инструмент был наконец предоставлен руководителю проекта, который начал потихоньку им пользоваться. И надо отметить, что он очень доволен, т.к. это экономит в том числе и его время. Процесс «внедрения» и обучения пользователя занял примерно 5 минут.
Из-за особенностей процессов и ограничений, Script server используется в основном для тестового окружения. Но некоторые его части уже стали использоваться и для Production (в той части, где это безопасно).
Основные камни
Ниже приведён список проблем и моих личных открытий, которые мне больше всего запомнились.
Передача выходных данных из процесса выполнения скрипта на страницу в асинхронном режиме. Тут сказалось отсутствие опыта как во Flask, так и в вебе: как лучше организовать такую передачу. В итоге реализовал на вебсокетах передачу данных в виде событий (тип и данные). Также в событиях можно отправлять и другие команды во время выполнения, но пока это не используется.
Передача ввода пользователя в исполняемый скрипт. Пытался сделать запрос на ввод только при ожидании такового в скрипте, но не нашёл способа. Поэтому пользователи во время выполнения скрипта могут вводить столько информации, сколько хотят (обычный терминал ведет себя так же). Данные отправляются через тот же вебсокет.
Отслеживание отключения пользователей. Именно из-за этой проблемы отказался от Flask: в тот момент я делал не на вебсокетах, а на SSE (ну почти). Однако позже я все же перевёл передачу input/output скрипта на вебсокеты, так что возможно и Flask бы подошёл. В Торнадо же просто можно подписаться на закрытие вебсокета.
Output скриптов в (не)терминальном режиме. Честно говоря для меня это было открытием: output скриптов может отличаться если запускать их в терминале или вне. Например тот же…
… показывает input_prompt только в терминальном режиме. Не очень хорошо чего-либо ждать от пользователей, не показывая им чего именно. Пришлось разбираться с pty, чтобы обманывать запускаемые скрипты. По этой причине у меня сейчас два типа обёрток для запуска скриптов: с поддержкой терминала и без. Первый включается по-умолчанию, второй можно включить с помощью конфигурации (оставил его на всякий случай, если терминальный режим будет сбоить).
Автоскролл выходных данных скрипта. С одной стороны это решается довольно просто, с другой стороны были проблемы с настройкой автоматического отключения этого (если пользователь скроллит вручную или выделяет текст), а также с тенью, вводом пользователя и т.п. Ничего экстраординаорного, но несколько часов потратить пришлось.
Настройка панели с выходными данными скрипта таким образом, чтобы она занимала всё доступное место, но при этом никогда не выходила за границы окна. Таким образом страница всегда умещается в окно и единственный скролл добавляется именно внутри output панели. Для меня это было особенно важно, т.к. я категорично не люблю скроллы в скроллах.
Производительность страницы при очень большом количестве выходных данных скрипта. Тут со мною злую шутку сыграл следующий код:
Дело в том, что получение innerText это сама по себе довольно ресурсоёмкая операция, которая пытается представить входящий html как строку, даже если это просто текст. Если вызывать эту операцию пару сотен раз и для тысячи символов, то эффект не заметен, но в моем случае данных было гораздо больше и браузер просто зависал на несколько минут от такой нагрузки. Решилось изменением кода на следующий:
Висящие процессы, т.е. никто ничего не выполняет, но в процессах висит выполняемый скрипт. Причины были разные, например: пользователь закрыл страницу, а сервер не обрабатывает это. Или не закрытый дескриптор файла. Или незакрытые дочерние процессы. И это не считая других очевидных багов. Но устранялось все гуглёнием, изучение и исправлением.
Безопасность
Её нет, совсем. Данный инструмент рассчитан на локальный запуск и работу в локальной сети с доверенными пользователями. Поскольку зачастую скрипты тоже пишутся для себя, они также не являются особо защищёнными. Соответственно прежде чем запускать такой сервер, нужно быть на 100% уверенным в фаерволле и пользователях.
С точки зрения скрытия данных, в Script server на текущий момент также ничего нет. Включать пароли в качестве параметров или в конфигурацию крайне не рекомендуется, поскольку они будут логироваться и храниться в чистом виде.
Примеры и скриншоты
Для отладки в проекте я завёл тестовые конфигурации, которые можно использовать для тестирования и демонстрации. В данном разделе все предоставленные скриншоты будут основываться на них.
Конфигурация скриптов
Относительно стандартный баш скрипт с параметрами, вводом пользователя во время работы и печатью: Write file.
Простой питон-скрипт, который выводит стену текста, разбивая его на абзацы и запрашивая input пользователя: Destroy world. Эта конфигурация используется для отладки пользовательского интерфейса при отображении параметров. Содержит все возможные типы параметров: Parameterized
Скриншоты
Полный экран
Слева область выбора скриптов, справа информация по текущему открытому скрипту:
Панель параметров
В этом хаосе можно увидеть семейство разных типов параметров: обязательные, списки, числа, булеаны. Скриншот создан на основе конфигурации Parameterized
Панель input/output
Сверху кнопки запуска и остановки. Поскольку скрипт запущен, активна только последняя. Ниже панель выходных данных скрипта, в самом низу поле для ввода входных данных. Панель выходных данных сжата по высоте для демо-цели, в обычном окне она гораздо выше.
Дальнейшие шаги
На данный момент разработка не ведётся, т.к. в текущем виде Script server полностью покрывает возложенные на него задачи. Что-либо оптимизировать в текущем интерфейсе я также не вижу необходимости. Таким образом мы с ним оба находимся в ожидании новых вызовов и проблем.
В частности, я был бы крайне рад, если бы данный инструмент так же пригодился кому-либо из хабрасообщества и у меня бы появилась необходимость в новых улучшениях.
Список используемых библиотек/фрейворков/благодарностей:
petukhovsky.com
В предыдущей статье о WebSocket-ах для самых начинающих я рассказывал больше о том, как настроить Денвер и убедиться в том, что всё работает, лишь чуть-чуть уделив время реализации простого ws echo сервера. Но если вы скачали архивы исходников, то, уверен, вы с лёгкостью разобрались в получении и отправке сообщений, чего вполне достаточно для использования технологии.
Рад тому, что в моём пока не раскрученном блоге пошла реакция и это побудило к тому, чтобы написать продолжение и раскрыть вопрос о том, как всё же заставить PHP скрипт ws сервера работать на хостинге, как следить за тем, что процесс запущен и PHP скрипт выполняется и не был закрыт по таймауту или при перезагрузке Apache, как избежать запуска дублирующего процесса PHP и ответы на другие необходимые вопросы, чтобы получить гарантированно работающий ws сервер. Обязательно создам Интернет ws echo сервер с функцией чата и размещу его на своём посредственном хостинге. Далее в этой статье PHP скрипт, который непрерывно выполняется на сервере и обеспечивает работу с ws я буду называть ws сервер, хотя фактически это процесс на стороне сервера. И самое важное, дам готовое решение даже для тех у кого нет SSH доступа к консоли хостингового сервера или виртуальной машины.
Сегодня будет много работы
Размещение и запуск веб-сокет сервера на хостинге
Простота состоит в том, что именно с запуском никаких проблем нет. Вы можете взять PHP скрипт echows.php из прошлой статьи, совершенно ничего в нём не меняя, закачать на хостинг и обратиться к файлу из браузера, единственным отличием от выполнения в Денвере может быть то, что настройки Apache и кэширующих механизмов хостинга запрещают выводить информацию незавершенного PHP скрипта, в таком случае вы не увидите никакой информации в окне браузера, а страница продолжит грузиться в браузере. Но если попробуете подключиться к ws серверу из нашего ws клиента, то вы увидите что подключение прошло успешно и на ws echo сервер отвечает на все передаваемые запросы. В качестве адреса ws сервера в ws клиенте, естественно, нужно указать ws://yourdomain.com:8889. Как видите, всё в порядке. Единственная проблема с которой вы можете столкнуться это настройки файрволлов хостинга и занятость портов другими сервисами. Если у вас несколько доменов на одном IP адресе, то вы можете обращаться к ws серверу по адресу этого домена ws://anotheromain.com:8889 что, согласитесь не очень хорошо, особенно для хостинга где сотни веб-сайтов висят на одном домене, теоретически кто-то может использовать те же порты что и вы и это может привести к неработоспособности ws сервера, поэтому еще раз настоятельно рекомендую аккуратно выбирать порты и следить за тем, чтобы по прекращению работы ws сервер всегда закрывал все соединения и корректно закрывал сокеты. Теперь что касается самого PHP скрипта, как вы могли заметить, наш PHP скрипт живет только 100 секунд, после чего при попытке подключения или отправке сообщения, он закрывает все соединения и завершает своё выполнение. Как сделать так, чтобы он жил «вечно»? Есть достаточное количество методов. Но проблема не в том, что PHP скрипт должен выполняться бесконечно, а проблема в том, как обеспечить корректное завершение работы скрипта в различных ситуациях и затем коректно возобновлять его работу. Например, при выключении сервера и последующем его включении PHP скрипт сам не запустится, а отслеживать работает ли ws сервер и если не работает в ручную его запускать, очень плохая идея.
Метод бесконечного выполнения PHP скрипта запуск из браузера
Первое что нужно сделать, это в самом скрипте указать безлимитное время жизни PHP сценария set_time_limit(0); и игнорирование отключения браузера ignore_user_abort(true); чтобы PHP скрипт выполнялся после того, как вы закроете окно браузера. Когда вы произвели необходимые действия можете запускать его из браузера. Проблема в том, что запустив его однажды, мы не сможем проверить, всё ли в порядке с процессом, не возникло ли ошибок по ходу выполнения, а продолжает ли скрипт работу или нет можно убедиться только подключившись к нему ws клиентом. Конечно, можно добавить в этот скрипт функционал ведения лог-файла, в котором будут зафиксирована история его работы. Также при перезагрузке Apache на хостинге процесс со скриптом 100% будет выключен. Этот способ может подойти только в случае, когда мы закачиваем на сервер гарантированно работающий отлаженный ws сервер PHP скрипт и нам важно чтобы он работал только короткое обозримое время в зависимости от надежности хостинг провайдера, но этот метод совершенно не применим для работы полноценного промышленного ws сервера из-за своей крайней ненадёжности и невозможности отключения в тот момент когда нам это нужно. Представьте ситуацию, что администратор хостинг сервера решил перезагрузить Apache с целью обновления, а вы не проверяете постоянно работает ваш ws сервер или нет, а пользователи тем временем допустим сидят в вашем чате, и внезапно всё ложится, пользователи негодуют. Опять же, можно применить пару костылей, прежде чем ws клиент будет подключаться к ws серверу по протоколу ws, заставить ws клиент обращаться к другому серверному PHP скрипту по XMLHttpRequest(), и требовать от проверку запущенности ws сервера. Метод немного костылеватый, но имеет место в непромышленных решениях вроде небольшого чата или маленькой игрушки. Именно его я и использую в своих небольших проектах.
На всякий случай провел эксперимент, запустил ws сервер на хостинге предварительно внеся в PHP скрипт механизм закрытия всех соединений и прерывание процесса при получении сообщения «OFF» от клиента. Не трогал несколько дней, периодически отправляя разные сообщения и проверяя живучесть, отправил команду «OFF» спустя приблизительно два дня ws удачно завершил свою работу, время жизни процесса ws сервера оказалось 183 403 секунды (2 с небольшим суток) и думаю что он мог бы проработать еще дольше без всяких проблем.
Метод бесконечного выполнения PHP процесса запуск из консоли
PHP может быть использован для запуска PHP-скриптов в абсолютной независимости от Apache, но у меня нет уверенности что без Apache будет работать механизм сокетов, я не пробовал запускать без Apache — мне это показалось не к чему. Запуск через консоль считается более правильным нежели через веб-браузер, но он также как и запуск через браузер не способен решить ряд проблем. Возможно такой запуск и избавит нас от прекращения работы скрипта при перезапуске Apache и то это маловероятно, но что делать, если весь веб-сервер или виртуальная машина будет перезагружена. Вам придётся в ручную лезть на сервер и запускать скрипт, конечно если у вас большой игровой проект и есть выделенные системные администраторы которые мониторят состояние процессов на сервере и есть скрипты инициализации и загрузки ws сервера вместе с Apache и всем остальным, в таком случае это единственно правильный вариант, но мы говорим о бытовом удобном способе реализации ws сервера на PHP для небольших проектов. Также иногда встречается проблема при запуске PHP скрипта из консоли, которая прекращает выполнение PHP скрипта одновременно с тем когда вы выходите из консили, это связано с тем что выполнение PHP скрипта было привязано к вашей сессии как к клиенту. По идее это должно залечиваться использованием в PHP скрипте строки ignore_user_abort(true);, но это помогает не всегда в связи с разными настройками PHP. В таком случае используют трюк, давая PHP скрипту поток /dev/null, который он будет считать клиентом и не прекратит работу при вашем выходе из консоли.
Амперсанд в конце обязателен, чтобы вы могли нажать Ctrl+C и вернуться в консоль а процесс остался в памяти. Или можно воспользоваться утилитой nohup.
В добавок, будет полезно знать, что и на windows-платформе можно запускать выполнение скрипта из консоли
Если всё делать правильно, то лучше воспользоваться утилитой Supervisor: A Process Control System она следит за работой процесса, в случае необходимости запускает его, осуществляет регистрацию падений. Отличная правильная вещь, когда вы делаете серьезный проект и в вашем распоряжении выделенный сервер или хотя бы VDS.
ws сервер управление процессом PHP из браузера
В результате изучения способов запуска PHP скриптов у меня родилась очень простая идея — реализовать на стороне ws клиента перед подключением к ws серверу запрос XMLHttpRequest() к PHP скрипту который проверяет статус процесса ws сервера и если он не запущен запускает. Также возникла идея реализовать что-то вроде страницы администратора ws сервера, на которой будет доступен лог последних событий: о том когда был запущен, почему упал, кто инициировал последующий запуск и др., с которой можно будет дать команду ws серверу перезапуститься, выключиться, закрыть все соединения и др.
Какой должен быть интерфейс для ws клиента:
Какой должен быть интерфейс для ws администратора:
В итоге я немного модифицировал код PHP скрипта ws echo сервера вместив в него код переключения потоков ввода/вывода STDIN, STDOUT, STDERR и, тем самым, упростил запуск ws сервера из консоли:
Получил хорошо работающий демон echows.php (архив с клиентом, версия без мониторинга) и без использования pcntl_fork. Он запускается через консоль, отвязывается от консоли и всё замечательно отвечает на все запросы пользователей по адресу ws://yourdomain.com:8889, и корректно закрывается при отправлении сообщения «OFF». Но вот незадача, не удаётся проверить запущен ли демон или нет и тем самым избежать дублирующего запуска демона. Да, при запуске создаётся файл pid_file.pid, который хранит process id (уникальный номер процесса в системе OS *nix) нашего демона а при корректном завершении работы демона, например, при получении сообщения «OFF», этот файл удаляется. При запуске можно конечно проверять наличие этого файла, и если файл есть, то сообщать о том что демон уже запущен и таким образом избегать дублирующего запуска, но что делать если демон завершил свою работу некорректно и не удалил файл pid_file.pid, в таком случае наш демон никогда больше не запустится. Опять же на хабре удалось найти отличную функцию проверки наличия демона.
И опять проблема в том, что функция posix_kill($pid,0) оказалась не работоспособной по той же причине что и pcntl_fork. Я не смог с этим мириться и опять разработал «хитрое» решение. Т.к. я всё равно задумал реализовывать функционал показывающий состояние ws сервера, то мне так или иначе потребуется функция которая показывает статус процесса в ОС. Для реализации этой функции воспользуемся командой exec() которая позволяет выполнять любые команды консоли. И если мы выполним
Таким образом получили реально работающие функции без posix_kill, которые проверяют запущен ли демон и выдают данные о нём соответственно.
Upd 2017.08.14: В примере выше используется BSD синтаксис команды ps. Для большинства *nix систем он будет отличным, а эта команда будет выводить все процессы вместо одного с идентификатором pid. Начиная с версии ws server admin panel v.0.4. и выше используется классический синтаксис, корректно работающий в большинстве *nix систем.
Браузерная панель управления ws сервером
Разработаю простую систему управления и мониторинга демона. Она очень проста и состоит из нескольких файлов echowsadmin.html (панель администратора), echowsadmin.js (логика панели администратора), echowsadmin.php (логика управления ws echo сервером). Разработать эту систему оказалось на удивление просто, я потратил не более 1го часа своего времени.
Для того, чтобы любой пользователь не мог выключить демона командой OFF, я убрал этот функционал из PHP кода ws echo сервера. Соответственно, реализовав функцию выключения из системы управления демоном. Реализация не самая изящная, вместо сигналов я использую файл off_file.pid, но зато гарантированно не требуется никаких дополнительных библиотек и выключение происходит корректно. Т.к. на ws сервере цикл while повисает в моментах слушания сообщений сокета, то после создания off_file.pid нужно соединиться с ws сервером чтобы он дошел до конца цикла и проверил наличие off_file.pid, для этого делаю небольшую хитрость, имитирую подключение по сокету из echowsadmin.php и ввожу некоторую задержку чтобы всё сработало и скрипт сообщил о благополучном завершении работы. Скачайте архив разработанной системы управления, ws сервера и клиента (устаревший архив, более новый в Downloads), не забудьте указать адрес расположения файла echowsadmin.php на вашем хостинге в echowsadmin.js в строке 10, адрес echowsstart.php в socket.js и адрес ws сервера в echowsadmin.php (вернее не адрес, а порт, т.к. файл должен находиться на сервере то адрес всегда будет 127.0.0.1), куда будет пытаться подключиться наш одноклеточный мини клиент при выключенном ws echo сервере. Кнопку перезапуска ws echo сервера я делать не стал, так как понятно, что для этого нужно нажать stop, а затем start и необходимость этого действия в одной кнопке практически отсутствует. Вся эта система управления работает только под управлением *nix операционных систем, т.е. на хостинге. А вот так она выглядит.
Панель управления демоном
Очевидно, что можно много чего улучшить:
Но, в моём случае стояла задача сделать себе простенький инструмент мониторинга состояния демона через веб. Кстати, эту штуку слегка модифицировав можно использовать для мониторинга любого демона, а не только ws.
А что касается реализации для ОС Windows, то все места где pid можно обходить проверкой и таким образом обеспечиь запускаемость.
А запущен демон или нет достаточно проверять просто наличием pid файла.
Пока я был на выходных, забыл выключить ws echo сервер, в итоге время его жизни составило 233774 секунд, т.е. где-то около 3х суток, занимаемая память так и осталась около 0.1%, что говорит о том, что решение имеет право на жизнь.
Отзывы, комментарии всегда приветствуются. Продолжу развивать тему и в следующей статье реализую простенький чат как и обещал.