Rails3 Archives - Page 26 of 35

Czasem potrzebujemy uruchomić zadanie Rake'owe niezależnie od katalogu w którym się znajdujemy. Powodem tego może być np potrzeba wrzucenia rake'owego taska do Crona, żeby odpalał się np. co 5 minut. Jak tego dokonać?

Pierwszą rzeczą jest dowiedzenie się gdzie leży Rake:

# Komenda:
which rake
# Wynik:
/usr/local/bin/rake

Jeśli z jakiegoś powodu nie mamy uprawnień do używania which, po prostu musimy strzelać. Jest duża szansa że rake będzie dokładnie tam, gdzie w powyższym przykładzie (chyba że korzystamy z RVM i nie jest to wersja --system).

Mając już rake'a, możemy przystąpić do działania. Załóżmy że chcemy odpalać go co 5 minut. W tym celu definiujemy następującą regułę:

*/5 * * * * env -i KOD_DO_ODPALENIA

Zagwarantuje nam to, że deamon systemowy, uruchomi nasz KOD_DO_ODPALENIA, co 5 minut. Następnie musimy dopisać kod który mamy uruchomić. Aby to zrobić, musimy powiązać przejście do katalogu aplikacji z odpaleniem jej. Robimy to operatorem &&. Najpierw mówimy deamonowi gdzie chcemy być:

cd /home/nazwa_konta/rails/apka/

następnie co chcemy uruchomić i w jakim środowisku:

/usr/local/bin/rake cron:all  RAILS_ENV=production

i łączymy to w jedną regułę:

*/5 * * * * env -i cd /home/nazwa_konta/rails/apka/ &&  /usr/local/bin/rake cron:all  RAILS_ENV=production

jeśli tamto nie zadziała, można w ten sposób:

*/5 * * * * env -i bash -c 'cd /home/nazwa_konta/rails/apka/; /usr/local/bin/rake cron:all RAILS_ENV=production'

Wersja dla Crona który nie ma tych samych zmiennych środowiskowych co shell:

 */5 * * * * source $HOME/.serv && cd /home/nazwa_konta/rails/apka && rake cron:all RAILS_ENV=production

Jeśli chcecie stracić 2 godziny z życia, to mam dla Was świetny sposób. Róbcie migracje pod 1.8.7 a testujcie i odpalajcie serwer pod 1.9.2 ;)

Wczoraj pracowałem nad pewnym kawałkiem kodu, dla którego dużo łatwiej jest robić:

rake db:migrate VERSION=0

niż tworzyć nowe migracje.

Z tego względu, jak nietrudno zauważyć, często zmieniały mi się takie dane jak np hash dla hasła. Nie byłoby w tym nic specjalnego, gdyby nie to, że mam dość mocno "zakorzeniony" w Rubym sposób generowania hasha. Był on zależny od pewnych metod w Rubym, w taki sposób, że po zmanie sposobu obsługi charów i stringów w 1.9.2, także on uległ zmianie. Skutkiem tego było to, że wynikowy hash generowany przez tą samą metodę w drzewie 1.8 i 1.9 różnił się znacząco.

Ta różnica, skutkowała tym, że nie dało się zalogować na konto usera. Oczywiście zanim dotarłem do przyczyny, minęły wyżej wspomniane 2 godziny.

Nie radzę Wam, bawić się jednocześnie 1.8.7 i 1.9.2, a jeśli już musicie i coś przestanie działać, to w pierwszej kolejności odpalcie wszystko tylko pod jedną z tych dwóch wersji.

Tag: Rails3

Uruchamianie zadań Rake z poziomu innych katalogów (nie z katalogu projektu)

RVM + naprzemienne korzystanie z 1.8.7 i 1.9.2 – czyli jak stracić 2 godziny z życia