gunicorn automatycznie ładuje się po zmianie źródła

113

W końcu przeprowadziłem migrację środowiska deweloperskiego z runicorn / nginx do gunicorn / nginx.

Wygodne byłoby replikowanie funkcji automatycznego przeładowywania serwera uruchomieniowego do gunicorn, aby serwer automatycznie uruchamiał się ponownie po zmianie źródła. W przeciwnym razie muszę ręcznie zrestartować serwer za pomocą kill -HUP.

Jakiś sposób, aby uniknąć ręcznego ponownego uruchomienia?

— Paolo
źródło

Errata: w moim środowisku gunicorn jest zarządzany / monitorowany przez supervisora, więc tak naprawdę nie używałbym kill -HUPPID procesu, ale zamiast tego używałbym supervisorctl. Nie myśl jednak, że to się bardzo zmienia.

— Paolo,

3

github.com/benoitc/gunicorn/issues/154 ma kilka rozwiązań

— KZ

232

Chociaż jest to stare pytanie, tylko dla spójności - od wersji 19.0 gunicorn ma --reloadopcję. Dlatego żadne narzędzia innych firm nie potrzebują więcej.

— Dmitry Ziolkovskiy
źródło

5

Zgoda. Inne odpowiedzi mogą działać, ale jest to zdecydowanie najprostsze i nie stanowi obejścia. Dokładnie tego chciał OP.

— J-bob,

1

Nie wierzę, że w gunicorn jest wbudowana opcja --reload. Gdzie to znalazłeś? Ich doktorzy mówią, aby przeładować konfigurację, wysłać HUP ( killall -HUP procnamebędzie działać dobrze), aby nowi pracownicy uruchomili, a stare bezpiecznie zamkną.

— łagodnie

3

Dzięki @Guandalino, musiałem to przegapić. Warto jednak zauważyć, że mówią: „To ustawienie jest przeznaczone do programowania”. W niektórych przypadkach oczywiście sprawdziłoby się to w produkcji, ale w wielu innych mogłoby być problematyczne. Tak, zauważyłem poniżej, że pozornie nie jesteś zainteresowany produkcją / wdrażaniem.

— łagodnie

Jak to zrobić w prosty sposób na serwerach produkcyjnych?

— juan Isaza

@juanIsaza, nigdy nie powinieneś używać takiej funkcjonalności w produkcji. Jeśli uważasz, że tego potrzebujesz - musisz przemyśleć swoje podejście do tworzenia lub wdrażania.

— Dmitry Ziolkovskiy

20

Jedną z opcji byłoby użycie --max-requestów, aby ograniczyć każdy powstały proces do obsługi tylko jednego żądania poprzez dodanie --max-requests 1do opcji uruchamiania. Każdy nowo utworzony proces powinien widzieć zmiany w kodzie, aw środowisku programistycznym dodatkowy czas uruchamiania na żądanie powinien być znikomy.

— Dave Forgac
źródło

1

Niezła, elegancka sztuczka dla deweloperów. Nie można używać na prod ... ale i tak możesz nie chcieć automatycznego ponownego ładowania na prod, chyba że wykonujesz „ciągłe wdrażanie”. Jeśli tak, Bryan Helmig za podejście jest lepsze, mimo że wymaga pippakiet stanie, watchdog.

— płyty kuchenne

2

Uruchomienie nowego pracownika zajmie około 3 sekund, co jest dla mnie za wolne. (połowa 2009 MBP)

— Blaise

11

Bryan Helmig wymyślił to i zmodyfikowałem go do używania run_gunicornzamiast gunicornbezpośredniego uruchamiania , aby umożliwić po prostu wycięcie i wklejenie tych 3 poleceń do powłoki w folderze głównym projektu django (z aktywowanym virtualenv):

pip install watchdog -U
watchmedo shell-command --patterns="*.py;*.html;*.css;*.js" --recursive --command='echo "${watch_src_path}" && kill -HUP `cat gunicorn.pid`' . &
python manage.py run_gunicorn 127.0.0.1:80 --pid=gunicorn.pid

— płyty
źródło

Po prostu użyłem go na Fedorze 15 z Django 1.5.4, gunicorn 18.0, watchdog 0.6, bash 4.2.

— płyty grzewcze

W 127.0.0.1:80razie potrzeby nie zapomnij podać swojego adresu IP lub FQDN i portu .

— płyty grzejne

1

@Guandalino, szczęście? Już od kilku tygodni działa dobrze. Tylko czas muszę restart ręcznie jest przy zmianie settings.py, models.py(wymagane migracji), lub kod źródłowy jakiejś zewnętrznej aplikacji nie w moich watchmedowzorów.

— płyty grzejne

Dzięki za przypomnienie. Ale nie chcę głosować na sukcesy innych. Po co ten (niepotrzebny) pośpiech? Czy naruszam jakąś regułę StackOverflow? Jeśli tak, daj mi znać, jak to naprawić.

— Paolo

1

Bez obaw. Zdecydowanie nie narusza zasady SO, po prostu rozważne / troskliwe / przemyślane włożenie wysiłku / priorytetu w ocenę pomocnych odpowiedzi. Wygląda na to, że Dave i ja nie spieszyliśmy się, pomagając ci (wiele miesięcy), więc moje poczucie pilności, abyś zweryfikował nasze rozwiązania, jest nieproporcjonalne - jestem zbyt chętny, aby wiedzieć, czy są ukryte wady w sposobie, w jaki Skonfigurowałem mój serwer i czy powinienem przełączyć się na podejście Dave'a . Wesołych Świąt!

— płyty grzewcze

5

Używam git push do wdrażania w środowisku produkcyjnym i konfigurowania haków git do uruchamiania skryptu. Zaletą tego podejścia jest to, że możesz jednocześnie przeprowadzić migrację i instalację pakietu. https://mikeeverhart.net/2013/01/using-git-to-deploy-code/

mkdir -p /home/git/project_name.git
cd /home/git/project_name.git
git init --bare

Następnie utwórz skrypt /home/git/project_name.git/hooks/post-receive.

#!/bin/bash
GIT_WORK_TREE=/path/to/project git checkout -f
source /path/to/virtualenv/activate
pip install -r /path/to/project/requirements.txt
python /path/to/project/manage.py migrate
sudo supervisorctl restart project_name

Upewnij się chmod u+x post-receivei dodaj użytkownika do sudoers. Pozwól mu działać sudo supervisorctlbez hasła. https://www.cyberciti.biz/faq/linux-unix-running-sudo-command-without-a-password/

Skonfigurowałem z mojego serwera lokalnego / deweloperskiego, git remotektóry umożliwia mi wypychanie na serwer produkcyjny

git remote add production ssh://user_name@production-server/home/git/project_name.git

# initial push
git push production +master:refs/heads/master

# subsequent push
git push production master

Jako bonus, zobaczysz wszystkie monity podczas działania skryptu. Dzięki temu zobaczysz, czy występuje problem z migracją / instalacją pakietu / restartem nadzorcy.

— user3628119
źródło

uwaga, aby używać shebang, #!/bin/bashjak wspomniano powyżej, zamiast tego, #!/bin/shco post-receivemiał przykład Git !

— curtisp