[SPEC, RFC] tokyotyrant.spec, rcskrypt dla wielu instancji

[Remigiusz 'Enleth' Marcinkiewicz]

Witam,

[uwaga, wyszło długie]

przygotowałem speca dla Tokyo Tyrant, interfejsu sieciowego bazy Tokyo 
Cabinet, ale jest jeden haczyk: żeby tego się w ogóle dało używać, musiałem 
napisać skrypt startowy obsługujący wiele instancji usługi. Nie jest jeszcze 
gotowy, a uwagi pewnie będą też do części które już są, stąd ułamkowy rel w 
specu i RFC w temacie.

TT jest specyficzną usługą, która nie ma żadych plików konfiguracyjnych ani 
katalogu roboczego i przyjmuje całą konfigurację w argumentach podczas 
uruchamiania. Na dodatek jedna instancja obsługuje dokładnie jedną tabelę 
(która wcale nie musi być istniejącym plikiem, może być w pamięci), więc w 
normalnych warunkach na serwerze działa wiele procesów TT, każdy na prawach 
konkretnego usera który go używa, względnie jako nobody. Czegoś takiego jak 
systemowy TT po prostu nie ma. Skrypty startowe PLD takiej sytuacji generalnie 
nie przewidują, więc musiałem coś wymyślić.

Z istniejących już w PLD skryptów startowych najbliżej tego, co chciałem 
osiągnąć są MySQL, PostgreSQL i memached. Problem w tym, że dwa pierwsze mają 
katalogi robocze dla każdej instancji - skrypt startowy nie przejmuje się 
konfiguracją i ma wygodne miejsce na pidfile dla każdego procesu - a ostatni 
rozróżnia instancje tylko po IP i porcie, każdej wmuszając tę samą 
konfigurację, więc może wszystko pobierać z jednego pliku w /etc/sysconfig/.

tokyotyrant.init w załączniku to mieszakna powyższych z moimi własnymi 
pomysłami. Sposób uruchamiania i przechowywania plików pid podebrałem z 
memached, przy czym implementacja przewiduje działanie procesów TT na prawach 
róşnych uşytkowników i grup. Wspólna grupa tokyotyrant jest ustawiana przez 
start-stop-daemon jako dodatkowa dla procesu, nie główna. Usera pakiet nie 
dodaje bo wydaje mi się, że byłby bezużyteczny. TT pracujący z plikiem 
powinien działać jako właściciel pliku, pracujący na pamięci (np. jako 
zamiennik memached) spokojnie moĹźe jako nobody.

Obsługa konfiguracji to z kolei własny wynalazek - pliki konfiguracyjne są 
trzymane w /etc/tokyotyrant.d/ i są po prostu skryptami shellowymi 
ustawiającymi odpowiednie zmienne. W ten sposób uniknąłem ręcznego rzeźbienia 
jakiegoś nowego, zupełnie niepotrzebnego formatu konfiguracji (jak np. w 
autossh) i ułatwiłem sobie zarządzanie dużą ilością procesów. Włączanie i 
wyłączanie konfiguracji odbywa się przez chmod +x/-x. Nie wiem, czy to dobry 
pomysł - być może lepiej jest zdefiniować w samym pliku zmienną mówiącą, czy 
dany konfig ma zostać uruchomiony. Zmienię to, jeśli komentarze będą na to 
wskazywać. Przykładowa konfiguracja instalowana do /etc/tokyotyrant.d/example 
jest standardowo wyłączona, ale jeśli się ją włączy, proces TT wystartuje na 
każdym systemie, z bazą hash w pamięci.

Zupełną nowością jest opcjonalne wybieranie konkretnych instancji do 
uruchomienia lub zatrzymania, jako drugi po akcji argument skryptu - po nazwie 
pliku z kofnfiguracją w /etc/tokyotyrant.d/. Bez niego skrypt działa jak te od 
baz danych, startując lub zatrzymując, odpowiednio, wszystkie które jeszcze 
nie są włączone a mogłyby być, lub wszystkie które jeszcze działają. Na 
potrzeby statusu uznaje, że usługa działa jeśli działa choć jedna instancja. 
Jeśli podczas startu część nie ruszy, tym działającym pozwoli pracować dalej, 
ale syngalizuje problem komunikatem. Po co to wszystko? Bo uznałem, że to 
debilizm, restartować wszystkie procesy (potencjalnie wysypując np. działające 
aktualnie żądania dla PHP które coś biorą z TT), jeśli zmieniam tylko jedną 
konfigurację.

Jeszcze nie ma obsługi polecenia "status" - nie jest mi potrzebna, ale jeśli 
skrypt dostanie szansę na wrzucenie do CVSa, uzupełnię to razem z innymi 
sugerowanym poprawkami. Mogą być w kodzie rzeczy zrobione źle lub 
nieelegancko, nie jestem mistrzem programowania w shellu. Starałem się 
patrzeć, jak inni zrobili podobne rzeczy w innych skryptach. Może brakować 
czegoś, czego braku nawet nie zauważyłem. Krytyka jest oczywiście bardzo 
wskazana.

W praktyce to działa dobrze od ładnych paru miesięcy, jest wygodne i z 
pewnością znacznie łatwiejsze w zarządzaniu, niż gdyby konfiguracja miała być 
przechowywana w jakimś pojedyńczym pliku. Bardzo podobnego skryptu używam też 
od jeszcze dłuższego czasu do obsługi FastCGI i tak samo sprawdza się 
doskonale. Skrypt do TT wysyłam na listę jako pierwszy, bo jest prostszy - 
łatwiej go przeanalizować i skomentować, czy jest dobry, czy nie. Wszelkie 
sugestie do TT zastosuję też do skryptu FastCGI zanim go udostępnię.

Spec jest przepuszczony przez adapter, wszystko się buduje, instaluje i 
odinstalowuje poprawnie. Zależności chyba kompletne.

Pozdrawiam,
-- 
Remigiusz "Enleth" Marcinkiewicz, enleth w enleth.com
WWW http://enleth.com http://heroes.net.pl
JID enleth w jabster.pl
-------------- następna część ---------
Załącznik, który nie był tekstem został usunięty...
Name: tokyotyrant.init
Type: application/x-shellscript
Size: 3760 bytes
Desc: nie znany
Url : /mailman/pipermail/pld-devel-pl/attachments/20100527/5a6b7d46/attachment.bin 
-------------- następna część ---------
Załącznik, który nie był tekstem został usunięty...
Name: tokyotyrant.spec
Type: text/x-rpm-spec
Size: 3849 bytes
Desc: nie znany
Url : /mailman/pipermail/pld-devel-pl/attachments/20100527/5a6b7d46/attachment-0001.bin 
-------------- następna część ---------
TT_DATABASE="*"
TT_ADDR="/tmp/tt-example.sock"
TT_PORT=0
TT_UID=nobody:nobody
TT_MASK="copy,restore,repl,slave"
TT_PID="/tmp/tt-example.pid"
-------------- następna część ---------
Załącznik, który nie był tekstem został usunięty...
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/20100527/5a6b7d46/attachment.sig