(1 из 2)      << | < | 1 | 2 | > | >>

3 декабря 2013 года

Используемые мной технологии программирования (язык программирования Scala, система сборки sbt, веб-фреймворк Play) активно развиваются и новые версии появляются с завидной регулярностью.

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

В момент появления новой версии Play 2.2, я обнаружил, что они изменили свой загрузочный скрипт start и структуру каталогов в target. При развертывании приложения в режиме stage (без использования play на сервере), скрипт был обнаружен в каталоге target/universal/stage/bin и назывался он теперь не start, а по имени приложения в build.sbt или project/Build.scala.

Кроме этого, поменялись параметры вызова этого скрипта и корневым каталогом веб-приложения (Play.application.path) неожиданно стал target/universal/stage. Именно здесь теперь при запуске приложения создавался файл RUNNING_PID и подкаталог logs.

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

Когда же это время появилось, Play уже имел более свежую версию 2.2.1, на которую и были постепенно переведены все веб-приложения, созданные на этих технологиях. Прежде всего, была разработана структура подкаталогов, для разных веб-приложений, запускаемых одним движком:

├── flower
│   ├── root
│   │   ├── config.txt
│   │   ├── favicon.ico
│   │   └── robots.txt
│   ├── RUNNING_PID
│   ├── start
│   └── stop
├── foto
│   ├── root
│   │   ├── config.txt
...
├── target
│   └── universal
│       ├── stage
│       │   ├── bin
│       │   │   ├── app
│       │   │   └── app.bat
│       │   ├── conf
│       │   │   ├── application.conf
│       │   │   └── play.plugins
│       │   ├── lib
...
│       │   ├── logs
│       │   │   └── application.log
...

Сам движок располагается в каталоге target, а все приложения (flower, foto, ...) в соответствующих каталогах того же уровня. Все настройки конкретного приложения находятся в файле root/config.txt, который считывается в момент загрузки приложения. При изменении движка меняется только каталог target.

Пример запускающего скрипта start:

#!/bin/sh
 name=flower
 port=9178
 mem=512
 dir=/srv/server/play/app/$name
 pid=$dir/RUNNING_PID
 cd $dir
 nohup ../target/universal/stage/bin/app -mem $mem -J-server -Dhttp.port=$port -Dpidfile.path=$pid -Dhttp.address=127.0.0.1 & 
 exit 0

При помощи параметра -Dpidfile.path файл RUNNING_PID перемещается в соответствующий каталог приложения. Лог-файл target/universal/stage/logs/application.log ведется общий - возможность его разделять на отдельные файлы для разных приложений пока не обнаружена.

Пример останавливающего скрипта stop:

#!/bin/sh
 name=flower
 dir=/srv/server/play/app/$name
 pf=$dir/RUNNING_PID
 nohup=$dir/nohup.out
 if [ -f $pf ]; then
   pid=`cat $pf` > /dev/null
   rm $pf > /dev/null
   kill -9 $pid > /dev/null
 fi
 if [ -f $nohup ]; then
   rm $nohup > /dev/null
 fi
 exit 0

Эти скрипты используются в задании для cron. Привычка проверять отклик приложения каждые пять минут и, при необходимости, перезагружать его осталась в наследство от нестабильной работы серверов glassfish/tomcat, хотя и не было ни одного случая зависания приложения на Play 2 + netty.

(1 из 2)      << | < | 1 | 2 | > | >>

Комментарии (0)

Автор (*):Город:
Эл.почта:Сайт:
Текст (*):