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, [email protected] WWW http://enleth.com http://heroes.net.pl JID [email protected]
fcgi
Description: application/shellscript
memcached
Description: application/shellscript
tokyotyrant
Description: application/shellscript
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
