W mojej aplikacji Ruby on Rails używam gema Sunspot, który to używa RSolr do komunikacji z serwerem Solr. Solr to serwer bazujący na indeksie Lucene, który świetnie nadaje się do wyszukiwania pełnotekstowego.
Domyślna instalacja Sunspot posiada kopię Solr'a, którą można uruchomić na jetty. Jetty domyślnie uruchamia się na porcie 8983 i można podglądnąć sobie panel administracyjny Solr'a wchodząc na adres: http://localhost:8983/solr/admin/
Wszystko fajnie gdy pracuje się na localhost, jednak na serwerze produkcyjnym nie jest mile widziane aby każdy miał dostęp do wspomnianego panelu.
Najpierw próbowałem zabezpieczyć port 8983 dla ruchu z poza mojego serwera, chciałem użyć do tego ufw niestety moje zdolności administratorskie nie są na tyle dobre aby to poprawnie skonfigurować.
Następnie zastanawiałem się czy jest możliwość konfiguracji jetty, aby odpowiadała tylko dla zapytań z konkretnego hosta. Okazało się, że można to skonfigurować, oto instrukcja:
1. w pliku konfiguracyjnym jetty jetty.xml - w moim przypadku ścieżka to:
odnaleźć fragment:
2. dodać następującą linię
przed linią
3. zrestartować serwer jetty i nasz panel solr powinien już być zabezpieczony.
sobota, 18 czerwca 2011
piątek, 17 czerwca 2011
whenever - zarządzaj crontab za pomocą Ruby
Zgodnie z obietnicą opiszę jak skonfigurować crontab za pomocą gem'a whenever.
W poprzednim poście mowa była jak utworzyć backup bazy MySql za pomocą gem'a backup i wysłać go do Amazon S3.
Przydałoby się zautomatyzować ten proces aby wykonywał się przynajmniej raz dziennie.
Oto jak można to zrobić za pomocą gem'a whenever.
Pominę proces instalacji, gdyż jest to bardzo dobrze opisane na stronie projektu.
Po komendzie wheneverize . został utworzony plik config/schedule.rb, w tym pliku należy wpisać własne zadania, które chcemy wykonać na naszym serwerze.
Moim celem było utworzenie taska, który będzie wykonywał się codziennie i który będzie wywoływał komendę:
Po wrzuceniu tego na serwer okazało się, że cron nie rozumie polecenia backup. Trzeba było odpowiednio ustawić zmienną PATH, poniżej jeszcze raz plik schedule.rb wraz z dodatkowymi ustawieniami:
Cron po każdym uruchomieniu taska wyśle podsumowanie na adres email, który został ustawiony w zmiennej :MAILTO.
To wszystko. Cron działa, backup się wykonuje. Bardzo podoba mi się, to, że taski cron są zdefiniowane wraz z projektem Rails. Jeśli używa się capistrano do deployment'u to warto dodać do pliku deploy.rb task, który będzie aktualizował crontab po każdym wypuszczeniu nowej wersji aplikacji:
W poprzednim poście mowa była jak utworzyć backup bazy MySql za pomocą gem'a backup i wysłać go do Amazon S3.
Przydałoby się zautomatyzować ten proces aby wykonywał się przynajmniej raz dziennie.
Oto jak można to zrobić za pomocą gem'a whenever.
Pominę proces instalacji, gdyż jest to bardzo dobrze opisane na stronie projektu.
Po komendzie wheneverize . został utworzony plik config/schedule.rb, w tym pliku należy wpisać własne zadania, które chcemy wykonać na naszym serwerze.
Moim celem było utworzenie taska, który będzie wykonywał się codziennie i który będzie wywoływał komendę:
Po wrzuceniu tego na serwer okazało się, że cron nie rozumie polecenia backup. Trzeba było odpowiednio ustawić zmienną PATH, poniżej jeszcze raz plik schedule.rb wraz z dodatkowymi ustawieniami:
Cron po każdym uruchomieniu taska wyśle podsumowanie na adres email, który został ustawiony w zmiennej :MAILTO.
To wszystko. Cron działa, backup się wykonuje. Bardzo podoba mi się, to, że taski cron są zdefiniowane wraz z projektem Rails. Jeśli używa się capistrano do deployment'u to warto dodać do pliku deploy.rb task, który będzie aktualizował crontab po każdym wypuszczeniu nowej wersji aplikacji:
Subskrybuj:
Posty (Atom)