Generator konfiguracji Supervisor

Generator konfiguracji Supervisor

Supervisor pilnuje procesów, które powinny działać ciągle — kolejek, websocketów, workerów. Gdy proces padnie, Supervisor go uruchamia ponownie. Generator tworzy konfigurację Supervisor dla jednego programu: sekcję [program:nazwa] gotową do zapisania jako /etc/supervisor/conf.d/nazwa.conf, razem z poleceniami supervisorctl do jej wczytania.

Najważniejsze dyrektywy

Zarządzanie

Pod konfiguracją generator podaje komplet poleceń do wykonania po zapisaniu pliku: sudo supervisorctl reread wczytuje nową konfigurację, sudo supervisorctl update uruchamia nowe i zmienione programy, sudo supervisorctl status pokazuje stan procesów, a sudo supervisorctl restart worker:* restartuje wszystkie kopie programu po wdrożeniu nowego kodu.

Gotowe wzorce

Pięć przycisków nad formularzem wypełnia nazwę programu, polecenie, liczbę procesów, katalog roboczy i ścieżkę logu. Pozostałe pola (użytkownik, startsecs, stopwaitsecs, autorestart, environment) zostają bez zmian.

Horizon i scheduler działają w jednej kopii: Horizon sam zarządza swoimi workerami, a dwa procesy schedule:work mogłyby uruchamiać te same zadania dwa razy. Ścieżki /var/www/app i /var/www/node to przykłady, podmień je na katalog swojej aplikacji.

Jak generator składa plik konfiguracyjny

Narzędzie zamienia dane z formularza na plik w formacie ini, który czyta supervisord. Na górze jest komentarz z proponowaną ścieżką, pod nim jedna sekcja [program:nazwa] z dyrektywami. Puste pola directory, user, stdout_logfile i environment są pomijane, a stopasgroup i killasgroup pojawiają się dopiero po zaznaczeniu. Podgląd odświeża się na bieżąco, a kafelki nad kodem pokazują liczbę procesów, liczbę linii, nazwę pliku i zakres nazw procesów. Jeśli potrzebujesz kilku programów, wygeneruj osobny plik dla każdego.

Kluczowa jest dyrektywa numprocs. Nie tworzy ona jednego procesu z wieloma wątkami, ale tyle niezależnych kopii tego samego command, ile wskażesz. Każda kopia dostaje własny numer liczony od zera, wstawiany tam, gdzie w process_name użyjesz znacznika %(process_num)02d. Przy process_name równym %(program_name)s_%(process_num)02d i programie queue-worker z numprocs 4 kopie nazywają się queue-worker_00, queue-worker_01, queue-worker_02 i queue-worker_03. Gdy numprocs jest większe niż 1, a process_name nie zawiera %(process_num), formularz zgłasza błąd, bo Supervisor odrzuciłby taki plik. Dzięki numeracji supervisorctl status pokazuje każdą kopię osobno.

Trzeci element mechanizmu to cykl życia procesu. autostart decyduje, czy supervisord podniesie program razem ze swoim startem, autorestart — czy wznowi go po zakończeniu pracy, startsecs — po ilu sekundach działania start uznaje się za udany, a stopwaitsecs — ile sekund Supervisor czeka po wysłaniu sygnału zatrzymania, zanim wymusi zakończenie. Standardowe wyjście trafia do pliku stdout_logfile, a przy włączonym redirect_stderr także komunikaty błędów. Przy błędnej konfiguracji to właśnie tam najszybciej widać, czego brakuje procesowi do poprawnego startu.

Przykład: queue worker z czterema procesami

1. Klikasz wzorzec Queue worker. Generator ustawia nazwę queue-worker, polecenie php /var/www/app/artisan queue:work --sleep=3 --tries=3, numprocs 4 i log /var/log/supervisor/queue-worker.log.
2. Przy domyślnych pozostałych polach plik ma 14 linii: komentarz ze ścieżką, nagłówek [program:queue-worker] i 12 dyrektyw, w tym process_name, bo procesów jest więcej niż jeden.
3. Kafelek z nazwami pokazuje queue-worker_00 … queue-worker_03. Pod kodem pojawia się ostrzeżenie, że wszystkie cztery procesy zapisują do jednego logu. Zmieniasz ścieżkę na /var/log/supervisor/queue-worker_%(process_num)02d.log i ostrzeżenie znika.
4. Najdłuższe zadanie w kolejce trwa około minuty, więc podnosisz stopwaitsecs z 10 do 90. Przy 10 sekundach Supervisor wysłałby SIGKILL i przerwał zadanie w połowie.
5. Zapisujesz plik jako /etc/supervisor/conf.d/queue-worker.conf, uruchamiasz sudo supervisorctl reread, a następnie sudo supervisorctl update. Status powinien pokazać 4 procesy w stanie RUNNING.
6. Scheduler dodajesz osobno: wzorzec Scheduler daje plik scheduler.conf z numprocs 1 i bez linii process_name, czyli 13 linii. Na serwerze działa wtedy 4 + 1 = 5 procesów z dwóch plików.

Jak używać generatora w praktyce

• Jedna sekcja na jeden program. Queue worker, websocket i scheduler mają osobne cykle życia, więc powinny mieć osobne pliki i osobne nazwy.
• Dobierz stopwaitsecs do charakteru zadania. Worker przetwarzający duże porcje danych powinien dostać więcej czasu, niż trwa najdłuższe zadanie. Po wdrożeniu nowego kodu w Laravelu uruchom php artisan queue:restart, żeby workery wczytały zmiany.
• Logi ustaw od razu. Zostaw włączone redirect_stderr i wskaż stdout_logfile, bo pętla restartów najczęściej wynika z brakującej zależności albo zmiennej środowiskowej, a bez logu nie widać przyczyny.
• Gdy polecenie uruchamia procesy potomne, na przykład skrypt powłoki albo npm start, zaznacz stopasgroup i killasgroup. Bez tego po zatrzymaniu procesu głównego potomne mogą zostać w systemie.

Czego narzędzie nie zrobi

Generator wyłapuje cztery typowe pomyłki i pokazuje je pod kodem: znak % w poleceniu (dosłowny procent trzeba zapisać jako %%, np. date +%%Y), polecenie z nohup lub końcowym &, które Supervisor uznałby za zakończone i restartował w kółko, użytkownika root oraz wspólny plik logu dla kilku procesów. Formularz odrzuca też nazwę programu ze spacjami, polecenie w kilku liniach i numprocs spoza zakresu 1–100. Poza tym:

• Nie sprawdzi, czy polecenie działa. Jeśli ścieżka do interpretera lub pliku jest błędna, dowiesz się o tym dopiero z logu procesu.
• Nie dobierze liczby procesów za Ciebie. numprocs zależy od obciążenia i liczby rdzeni, a narzędzie nie zna zasobów Twojego serwera, więc wartość musisz wybrać sam i zweryfikować obserwacją kolejki.
• Nie generuje całego pliku supervisord.conf. Powstaje konfiguracja programu, natomiast sekcje [unix_http_server], [supervisorctl] i [include] muszą już istnieć w instalacji Supervisora.
• Nie wczyta pliku .env. Supervisor do środowiska odziedziczonego po supervisordzie dokłada tylko zmienne z dyrektywy environment; kilka rozdzielasz przecinkami, np. APP_ENV=production,QUEUE=default. Laravel czyta .env samodzielnie z katalogu aplikacji, ale inne programy mogą potrzebować zmiennych podanych jawnie.
• Nie waliduje ścieżek i uprawnień. Katalogi na logi oraz konto podane w dyrektywie user muszą istnieć i mieć odpowiednie prawa, inaczej proces nie wystartuje mimo poprawnej składni.