Борис Сёмов

Веста, в варианте Nginx+PHP-FPM, из коробки, фактически не работоспособна, из-за своих кривых и малочисленных шаблонов.

Ну и она, из коробки, не умеет делать конфиги пулов для нескольких версий php, так что даже написание дополнительных шаблонов тут не поможет.

Т.е. ваша задача просто не решается без переписывания логики генерации шаблонов пула php-fpm в панельке.

nginx -v покажите свой. Вероятно этот модуль у вас уже есть.
То, что появилась поддержка подключаемых модулей, не говорит о том, что все модули взяли и выпилили из основного исполняемого файла и сделали распространяемыми отдельно...

По поводу скачать - а откуда вы его ставите, и как. Ваш пакетный менеджер должен, собственно этим заниматься. И для дополнительных модулей есть, обычно, дополнительные пакеты.

Просто прописать нужный root в локейшене /admin, и все остальные локейшены для обработки php, статики laravel и.т.п. сделать вложенными по отношению к этому локейшену...
Ну и надо понимать, что ваш пример конфига, крайне не полон - там нет обработчика php, нет редиректа запросов на точку входа приложения и.т.п.

Есть масса вариантов работы рельсов под nginx, в большинстве из них используется какой-нибудь внешний сервер приложений(unicorn, thin), и проксирование запросов к нему директивой proxy_pass.

Вероятно, вам стоит просто погуглить по rails + nginx и выбрать один из множества вариантов, подходящий именно вам.

Если у вас сайт там же, то зачем вам вообще двойное проксирование? Принимайте сразу запросы на тот server{} который во втором фрагменте.

В чём проблема во втором случае, из вопроса вообще не понятно. Вы терминируете ssl на nginx, и проксируете дальше на бекэнд http запросы, всё правильно.

Можно сделать что-то типа такого: \.\w{1,4}$ (это url оканчивающиеся на точку и от одного до 4 символов). Но почему-то мне кажется, что вы не с той стороны подходите к решению задачи просто.

Это не эквивалентные варианты. Как можно сказать, какой предпочтительнее? Выбирайте тот, что нужен именно вам.

Первый вариант сработает на все uri, которые заканчиваются на .php
Во втором uri должен начинаться со слеша, и заканчиваться на .php или .php/всё что угодно.

nginx -t или лог ошибок, даст вполне конкретный ответ на этот вопрос...

А проблема не в слое кеширования приложения?

Для получения потока, вам не нужен какой-либо модуль. Этим и занимается http-mp4. Его можно будет просмотреть каким-нибудь плеером на сайте, или любым плеером поддерживающим http псевдостримминг.

Вероятно, в дополнение к этому, необходима будет обработка файлов одной из программ, которые переносят метаданные в начало файла. Это весьма не сложно можно сделать скриптом по крону, например.

Для получания отдельного кадра, вы можете написать скрипт на любом языке, который будет обрабатывать такие запросы, и дёргать нужный кадр из видео при помощи ffmpeg, например, а потом отдавать его клиенту, и возможно, сохранять кадр, чтобы потом не делать обработку на такой же запрос.

Есть более правильное решение - выполнять долгие процессы не в контексте веб сервера, разделяя интерфейс постановки задачи и её выполнения.
Например, ставить задачи через веб интерфейс, а выполнять в скрипте запускаемом кроном.

Если надо получать обратную связь, можно периодически записывать процесс выполнения в какое-нибудь хранилище (файл, база, key-value), и отображать его на стороне клиента, делая периодические ajax запросы.

Ещё к вышесказанному:
Для большей изоляции можно загонять каждого пользоватея(каждый пулл) в chroot, это также умеет делать php-fpm.
Главное неудобство — необходимо создавать минимальное окружение для каждого пользователя и поддерживать его в актуальном состоянии, но для этого есть немало готовых скриптов.

Сильно от приложения зависит, конечно, но чаще всего, использование такой связки совершенно не оправдано. Да и использование varnish вообще где не попадя часто плохая идея, хотя бы из-за довольно странного использования им памяти.

Довольно разумным решением будет не отказываться от Apache вовсе, поставив при этом перед ним nginx как reverse proxy, и заодно, используя нужные вам фишки Nginx.
Оверхед, по памяти, в сравнении с fastcgi незначительный, быстродействие часто даже выше. Плюс более широкие возможности мониторинга, за счёт Apache что бывает весьма полезно.

Решаются сразу две проблемы — нет необходимости бодаться с админами из-за репозиториев, и при этом вы вполне можете использовать необходимые вам возможности Nginx.

Настроить proxy_cache для статики. И она начнёт отдаваться со второго запроса с фронтэнда, без дополнительных ухищрений.