bash Archives - Page 6 of 8

Sometimes we get software where all (or most of) settings are passed into application server via environment variables. But Passenger is not executed directly. So how do we pass ENV variables into it?

We need to create a little "wrapper" around Ruby, so it will be executed with our environment variables. Here's a little example (ruby_wrapper.sh):

#!/bin/sh
export  MONGODB_HOST=172.20.20.45 \
export  MONGODB_PORT=27017 \
export MONGODB_DBNAME=openaudit \
export REDIS_HOST=172.20.20.45 \
export REDIS_PORT=6379 \
export REDIS_DB=10 \

exec "/usr/local/bin/ruby" "$@"

Script must be executable with chmod +x and should be placed in /usr/local/bin/ dir.

There is one more thing to do: tell Passenger where the wrapper is (vhost example):

    <VirtualHost *:3001>
      ServerName 127.0.0.1
      RackEnv production
      PassengerMaxPoolSize 30
      PassengerUseGlobalQueue on
      PassengerRuby /usr/local/bin/ruby-wrapper
      DocumentRoot /home/smhtng/app/current/public/
      PassengerUser openaudit   
      <Directory /home/smhtng/app/current/public/>
         AllowOverride all             
         Options -MultiViews            
      </Directory>
   </VirtualHost>

The "magic" happens here:

 PassengerRuby /usr/local/bin/ruby-wrapper

Trafiają się nam projekty, w których wymagane jest uruchamianie kilku (kilkunastu) usług zanim będziemy mogli pracować. Odpalanie tego (i zarządzanie) w kilku oknach jest delikatnie mówiąc niewygodne.

Aby sobie to ułatwić, wystarczy napisać prosty skrypt w Bashu, który dane serwery będzie odpalał bezpośrednio w screenie. Ostatni z odpalanych serwerów pozostawimy "na wierzchu", dopisując kod który w momencie naciśnięcia na nim Ctrl+C (zamknij), wyłączy wszystkie pozostałe serwery. W ten sposób będziemy mogli łatwo i wygodnie zarządzać uruchamianiem i zamykaniem całego projektu. Dodamy sobie także alias tak, aby móc wygodnie wywoływać nasz skrypt.

Załóżmy, że nasz projekt nazywa się Kotowari. Wszystkie tworzone (później) screeny będą zawierać w sobie tę nazwę. Dzięki temu, będziemy mogli je zabić pozostawiając inne pracujące screeny (nie związane z projektem). Zdefiniujemy sobie także pułapkę na Ctrl+C:

trap close_screens INT

function close_screens() {
	kill -9 `ps aux  | awk '/Kotowari/{print $2}'`
	screen -wipe
}

Teraz pora na odpalanie kolejnych serwerów. Serwery które odpalamy przez init.d lub takie które nie potrzebują do pracy konsoli (nie "zostają" w niej), możemy odpalać bezpośrednio czyli:

sudo /etc/init.d/apache2 start;
sudo /etc/init.d/mysql start;

Warto zwrócic uwagę, że nie zostaną one zabite podczas zamykania projektu. Dlaczego to tak zostawiam? Tego typu procesy i tak zazwyczaj chodzą niezależnie od danego projektu i są współdzielone (zazwyczaj są też włączane przy boocie systemu - próbujemy je włączyć tak dla pewności). Oczywiście nic nie stoi na przeszkodzie aby je zamykać w napisanej powyżej funkcji close_screens().

Teraz pora na procesy dedykowane naszej aplikacji i zamknięcie całości:

screen -d -S "Kotowari Proc 1" -m "/sciezka/do/naszego/procesu1"
screen -d -S "Kotowari Proc 2" -m "/sciezka/do/naszego/procesu2"

"/sciezka/do/naszego/procesu3"

close_screens

Ostatni proces nie jest uruchamiany w screenie, ponieważ on ma nam zostać "na" konsoli. Jego zamknięcie zainicjuje funkcję close_screens która zamknie resztę z procesów ukrytych w screenach.

Jeszcze tylko alias:

alias nasz_projekt="/sciezka/do/naszego/skryptu.sh"

Całość:

trap close_screens INT

function close_screens() {
	kill -9 `ps aux  | awk '/Kotowari/{print $2}'`
	screen -wipe
}

sudo /etc/init.d/apache2 start;
sudo /etc/init.d/mysql start;

screen -d -S "Kotowari Proc 1" -m "/sciezka/do/naszego/procesu1"
screen -d -S "Kotowari Proc 2" -m "/sciezka/do/naszego/procesu2"

"/sciezka/do/naszego/procesu3"

close_screens

Tag: bash

Phusion Passenger and environment variables with Ruby (Rake) applications

Odpalanie wielu serwerów z pomocą jednego polecenia