Возвращаясь к теме серверов приложений. В прошлый раз я писал, что в alpine linux нету модуля psgi в сервере приложений uwsgi. И это проблема, так как мне нравится идея, что у меня для приложения есть собственно инстанс сервера приложений и ничего больше. Здесь же запускается master, router кто-то ещё и собственно экземпляры серверов приложений. Да можно держать целый пул приложений, причём динамический пул. Можно на одном сервере приложений держать целый зоопарк приложений. Но мне это всё не нужно. В моём случае прекрасно работает 1 экземпляр приложения. Но другого нам не дали, придётся обходиться тем что есть. Да, кстати, если приложение не запускается под unit-ом, то иногда понять почему оно так делает бывает не просто - unit не всегда пишет, что мешает приложению взлететь в отличие от uwsgi, который, если перл что-то скажет, обязательно запишет это в лог.
Итак, задачка стоит сконфигурять unit под psgi-приложения. Первое, на что мы нарываемся - вестимо занятный способ конфигурирования и, вероятно, баг в парсере unit-а. То есть, в версии 1.12 получается сохранить конфиг для контекста http://localhost, но не получаестя его загрузить. Самое интересное, что для контекста http://localhost/config конфигурация сохраняется хорошо и также хорошо вгружается обратно. На данном этапе развития непосредственно у localhost-а других контекстов, кроме config-а нету, поэтому можно смело брать его за базовый. Соответственно, это означает что надо произвести правку init-скрипта nginx-а. Мерж-реквест мэйнтэйнерам я сделал, думаю, что они его примут в ближайшее никогда, поэтому, делаем правки локально, на системе.
В нашем случае задача стоит так: у нас есть 3 приложения, хотим запускать каждое из них в своём сервере приложений. Конкретно для unit-а есть возможность запускать несколько инстансов этого сервера приложений "штатными средствами" дистрибутива - симлинки в /etc/init.d и конфиги в /etc/conf.d. Эта часть задачи тривиальна и рассматривать её тут я не буду.
Переходим сразу к приложениям. Первое - joyproxy и, как ни странно, это веб-приложение, то есть в него можно зайти по http, значит нам понадобится некоторый листенер. Особо разграничивать роутинг по запросам смысла нет, поэтому фигачим всё в приложение с дефолтными настройками роутера. У нас получается
{
"access_log" : "/var/log/access.log",
"applications" : {
"joyproxy" : {
"processes" : {
"idle_timeout" : 20,
"max" : 3,
"spare" : 1
},
"script" : "/var/lib/myapi/joyproxy.psgi",
"type" : "perl",
"working_directory" : "/var/lib/myapi/"
}
},
"listeners" : {
"0.0.0.0:80" : {
"pass" : "applications/joyproxy"
}
}
}И заталкиваем это дело в nginx unit, в нужный нам инстанс. Unit тутже поднимает инстанс приложения и готов к работе.
Далее, у меня есть бот для телеги и бот для джаббера и это приложения, которые по крайней мере пока что не имеют возможности что-то принимать по http. То есть нам для них не понадобится listener. И у нас получается более лаконичный конфиг
{
"access_log" : "/var/log/access.log",
"applications" : {
"myapitelegrambot" : {
"processes" : 1,
"script" : "/var/lib/myapi/myapi-telegram-bot.psgi",
"type" : "perl",
"working_directory" : "/var/lib/myapi/"
}
}
}Собственно, на этом и заканчивается конфигурирование сервера приложений. Ясное дело, что в голом виде наружу их никто выставлять не будет, они будут за nginx-ом.