[RFC] Skrypty startowe dla wielu instancji usługi

[Remigiusz Marcinkiewicz]

On Sunday 13 March 2011 00:48:49 Pawel Golaszewski wrote:
> On Sat, 12 Mar 2011, Remigiusz Marcinkiewicz wrote:
> > jakiś czas temu okazało się, że potrzebuję czegoś takiego, jak
> > uruchamianie wielu instancji jednej usługi, z mniej lub bardziej różną
> > konfiguracją na instancję i pełnym wsparciem ze strony skryptów
> > startowych. Istniejących rozwiązań tego typu doliczyłem się w PLD sztuk
> > dwa - MySQL i PostgreSQL
> 
> Do głowy mi przychodzi jeszcze socat i mrtg.

Fakt, o tych nie wiedziałem. Z tego socat działa nawet podobnie do tego, co 
sam zrobiłem, chociaż nie spełnia założenia b), które dla mnie było kluczowe. 
Poza tym wykonanie całkiem podobne, czyli ktoś już miał zbliżone pomysły.

Zapomniałem też o memcached, ale to był skrypt typu "odczytaj listę par 
IP:port i uruchom memcached dla każdej z wszystkimi innymi opcjami 
identycznymi", zupełnie nie ta kategoria.

> > a oba dość siermiężne, nienadające się do zastosowania dla niektórych
> > typów usług
> 
> Bo potrzeba nam ogólnego "framework" dla takich sytuacji. Nie ma jakiegoś
> schematu postępowania, a w zasadzie wszystkie usługi potrzebują takiej
> konfiguracji.

I dlatego zacząłem ten wątek i dołączyłem swoje wynalazki. Może z działającym 
punktem wyjścia powstanie coś sensownego.

> Choćby apache uruchomiony w różnych konfiguracjach, zależnie
> od potrzeb...

Sam chcę to dostosować jeszcze do lighttpd - na zewnętrznym :80 i tak mam 
haproxy robiące za dispatcher HTTP w warstwie 7. żeby część wywołań 
(filtrowanych po ścieżce, dla ominięcia zabezpieczenia XSS w przeglądarkach) 
szła do serwerów Tornado zamiast do lighttpd postawionego na 127.0.0.1 na 
wysokim porcie. Rozbicie tego, co teraz obsługuje jedna instancja na kilka to 
kwestia paru dodatkowych reguł haproxy, a będzie trochę korzyści.

Oczywiście, lighttpd używa całych katalogów na konfiguację, nie pojedyńczych 
plików, więc główne funkcje skryptu będą wymagały drobnych modyfikacji żeby 
obsłużyć taki przypadek. Podzielę się efektami jak tylko zrobię.

> > a) Wywoływany normalnie (/etc/rc.d/init.d/dupa start itp.) ma działać
> > normalnie - odpalać, zatrzymywać, odpytywać itp. wszystkie (jeszcze nie
> > uruchomione/nadal działające/...) instancje, realizować najbardziej
> > ogólny przypadek.
> 
> plus możliwość w włączenia/wyłączenia w konfiguracji którejś instancji.

To chciałem robić bitem x na pliku, ale wspomniałem, że to może być nadużycie. 
Równie dobrze można zrobić jakąś zmienną w stylu INSTANCE_ENABLED i sprawdzać 
z is_yes. Pewnie coś takiego wprowadzę w następnej wersji.

> > f) Musi być w stanie uruchomić każdą instancję na na prawach innego
> > użytkownika, zgodnie z konfiguracją
> 
> To może być problematyczne, bo niektórym usługom to my w plikach
> startowych ustawiamy użytkownika.
> Ale fakt, to musi być w każdym przypadku możliwe.

"Być w stanie" to nie to samo, co "robić tak za każdym razem". Założenia miały 
być możliwie ogólne, ale konkretny skrypt nie musi wykorzystywać wszystkich 
możliwości które ma.

> > g) Mimo powyższego, musi dopilnować, żeby pliki pid i lock nadal były
> > tam, gdzie być powinny, czyli w /var/run/ i /var/lock/subsys/
> 
> Nie, w tej sytuacji każda usługa chyba powinna tworzyć katalog ze swoimi
> pid-ami. Łatwiej statusy i zatrzymywanie by się obsługiwało raczej.
> Choć... to ma średnie znaczenie.

Pidy są w podkatalogach, podałem przykład. Pliki lock nie muszą być, bo 
właściwe usługi ich nie ruszają i nie trzeba kombinować z uprawnieniami, ale 
oczywiście mogą. Nie zrobiłem tak głównie dlatego, że nikt przede mną takiej 
konwencji nie wprowadził (podkatalogi w /var/run są stosowane od dawna), a 
/etc/rc.d/init.d/functions w obecnej postaci chyba sobie z tym nie poradzi. 
Potrzebowałem przede wszystkim czegoś, co działa.

Jakieś komentarze na temat samych skryptów?

-- 
Remigiusz "Enleth" Marcinkiewicz, enleth w enleth.com
WWW http://enleth.com http://heroes.net.pl
JID enleth w jabster.pl
-------------- nast�pna cz��� ---------
A non-text attachment was scrubbed...
Name: nie znany
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </mailman/pipermail/pld-devel-pl/attachments/20110313/d26a6a5d/attachment.sig>