[RFC] Skrypty startowe dla wielu instancji usługi

[Remigiusz Marcinkiewicz]

Witam,

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 - a 
oba dość siermiężne, nienadające się do zastosowania dla niektórych typów 
usług (rozwinę to dalej) i dołatane pod konkretny przypadek. Nic 
uniwersalnego, nic wygodnego w użyciu. Ustaliłem więc następujące założenia, 
które musi spełniać "dobry" (tzn. dobry dla mnie) skrypt tego typu:

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.
b) Oprócz tego musi umieć odpalić, zatrzymać, zrestartować itp. pojedyńczą, 
wskazaną instancję, np. /etc/rc.d/init.d/dupa restart dupa05-debug
c) Jeśli podczas uruchamiania wszystkich instancji naraz któraś nie zechce 
wstać, bo np. jest źle skonfigurowana, musi poprawnie uruchomić pozostałe, 
również następne w kolejności
d) Musi obsługiwać usługi, które nie posiadają nawet własnego pliku 
konfiguracyjnego, o jakimś katalogu z danymi i konfiguracją nie wspominając, 
czyli przyjmujące absolutnie wszystko jako argumenty - tak, jak np. memcached
e) W związku z powyższym powinien oczekiwać konfiguracji w formie plików w 
stylu /etc/dupa.d/dupa05-debug
f) Musi być w stanie uruchomić każdą instancję na na prawach innego 
użytkownika, zgodnie z konfiguracją
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/
h) Ogólnie wszystko ma działać przynajmniej tak dobrze, jak w normalnym 
srypcie startowym

Powyższe wynika z tego, że obecnie dostępne w PLD metody uruchamiania 
memcached, php-fcgi i podobnych usług można sobie o kant dupy rozbić w 
jakimkolwiek poważnym zastosowaniu wymagającym np. obsług wielu użytkowników, 
z których każdy ma mieć swoją instancję czegośtam na swoich uprawnieniach.

Oczywiście samo się nie zrobi, więc skoro było potrzebne, to zrobiłem. Mam 
testowe skrypty startowe dla memcached, tokyotyrant i PHP FastCGI spełniające 
te założenia, używam ich na produkcji już od jakiegoś czasu i wydaje mi się, 
że wyszły na tyle dobrze, żeby się nimi podzielić ze światem, zapytać o zdanie 
i zaproponować dołączenie tego do PLD.

Skrypty nie są jeszcze całkowicie gotowe, w ogóle nie obsługują czegoś 
takiego, jak zgodność wstecz z konfiguracją starego typu dla odpowiednich 
usług i używają /etc/rc.d/init.d/functions które nie jest za bardzo 
przystosowane do sposobu, w jaki traktują pliki pid i lock - działa to 
właściwie trochę przez przypadek. Mogą też zawierać jakieś błędy, których po 
prostu nie wychwyciłem, więc wszelka (najlepiej konstruktywna) krytyka będzie 
mile widziana.

UWAGA: u osób doświadczonych w pisaniu skryptów shellowych mogą wywołać 
drgawki, konwulsje, duszności, emisję dziwnych dźwięków i inne objawy napadów 
gwałtownego śmiechu. sh znam tyle, co mi jest potrzebne do wydłubania czasem 
czegoś na swoje potrzeby, efekty mogą być niekoszerne, niezgodne z takimi czy 
innymi dobrymi praktykami, głupie itp. Tym bardziej krytyka mile widziana.

Jeśli chodzi o wykonanie, skrypty są podzielone na dwie części - metody start, 
stop, list_status (bo status było już zajęte) i get_instances, które we 
wszystkich skryptach są identyczne poza nazwą usługi w komunikatach i 
ścieżkach do plików, oraz właściwe metody instance_start, instance_stop i 
instance_status które robią coś specyficznego dla jednej instancji danej 
usługi. Gdyby to miało zostać wykorzystane w PLD na szerszą skalę, funkcjom z 
tej pierwszej grupy należałoby nadać jakieś sensowne nazwy i dopisać je do 
functions (oraz nieco przerobić parę rzeczy które już tam są), a następnie 
ustalić jakiś wzorzec samego skryptu startowego dla takich usług. Mógłbym to 
zrobić (lub pomóc zrobić, lub zrobić z czyjąś pomocą), być może od razu 
przerabiając skrypty dla MySQLa i PostgreSQLa na "nowe" i kombinując z jakąś 
zgodnością wstecz, żeby przynajmniej nic się nie sypało po upgrade.

Poza tym:
 - pliki lock są zapisywane jako np. /var/lock/dupa-dupa05-debug, czyli 
/var/lock/usługa-instancja
 - pliki PID dla odmiany są zapisywane jako np. /var/run/dupa/dupa05-
debug.pid, żeby za pomocą wspólnej grupy załatwić problem programów tworzących 
pidfile już po zrzuceniu roota/odpalanych przez s-s-d od razu z usera -  s-s-d 
specjalnie po to ma opcję dokładania jednej grupy ekstra do listy grup procesu
 - mogłem coś pomieszać ze statusami wyjściowymi, szczególnie przy 
"częściowym" powodzeniu
 - zakładam, że usługa "ogólnie działa" jeśli działa choć jedna instancja, ale 
nie jest tworzony ogólny /var/lock/subsys/dupa - być może powinien być, jeśli 
coś musiałoby sprawdzić czy działa i nie spodziewałoby się, że ma sprawdzać 
istnienie /var/lock/subsys/dupa-*
 - założyłem sobie, że konfiguracja z o-x jest "wyłączona" - ale to może być 
nadużycie funkcjonalności systemu plików, tzn. powinno być zrealizowane 
zmienną w samym pliku konfiguracyjnym, a poza tym jest wykomentowane bo 
shellowi się nie spodobał warunek, cholera go wie czemu
 - używa /usr/bin/find - ale rc-scripts i tak wymaga findutils ze względu na 
xargs, a w momencie uruchomienia tych skryptów /usr/ zdecydowanie powinno być 
zamontowane, więc chyba to nie problem

Na razie, zgodnie z tematem, to jest RFC - czyli proszę o uwagi, komentarze i 
inne takie.

Pozdrawiam,
-- 
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: fcgi
Type: application/x-shellscript
Size: 3677 bytes
Desc: nie znany
URL: </mailman/pipermail/pld-devel-pl/attachments/20110312/cf5940d9/attachment.bin>
-------------- nast�pna cz��� ---------
A non-text attachment was scrubbed...
Name: memcached
Type: application/x-shellscript
Size: 3739 bytes
Desc: nie znany
URL: </mailman/pipermail/pld-devel-pl/attachments/20110312/cf5940d9/attachment-0001.bin>
-------------- nast�pna cz��� ---------
A non-text attachment was scrubbed...
Name: tokyotyrant
Type: application/x-shellscript
Size: 3825 bytes
Desc: nie znany
URL: </mailman/pipermail/pld-devel-pl/attachments/20110312/cf5940d9/attachment-0002.bin>
-------------- 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/20110312/cf5940d9/attachment.sig>