Bezproblemowa instalacja Django na pojedynczym serwerze

Question

Mam nową witrynę zbudowaną na Django i Pythonie 2.6, które wdrożyłem w chmurze (zgodność z buzzword I instancja Amazon micro EC2 jest darmowa!).
Oto moje szczegółowe notatki: https://docs.google.com/document/d/1qcZ_SqxNcFlGKNyp-CXqcFxXXsKs26Avv3mytXGCedA/edit?hl=en_US

Ponieważ jest to nowa strona (i chce grać w najnowsze i najlepsze) użyłem Nginx i Gunicorn na szczycie Inspektora.
Wszystkie oprogramowanie instalowane z bagażnika przy użyciu YUM/easy_install.
Moja baza danych to Sqlite (na razie - nie jestem pewien, gdzie pójść dalej, ale to nie jest pytanie). Również na liście zadań: virtualenv + pip.
Jak dotąd tak dobrze.
Mój kod w SVN. Napisałem prosty plik fabfile do wdrożenia - sprawdza najnowszy kod i restartuje Gunicorn przez Supervisora. Podłączyłem moją nazwę DNS do Elastic IP.
Działa.

Moje pytanie brzmi: jak zaktualizować witrynę bez zakłóceń w działaniu usługi? Użytkownicy witryny otrzymują 404s/500s, gdy uruchamiam mój mały skrypt aktualizacji.

Czy można to zrobić bez dodawania kolejnego serwera (cena jest kluczowa)?

Chciałbym mieć system pomostowy (na innym porcie?) I płynne przełączanie między etapami i produkcją. Na tym samym (bezpłatnym) serwerze. Via Fabric.
Jak to zrobić? Czy to samo Nginx działa na obu stronach? Czy mogę ulepszyć etapy bez ranienia produkcji? Jak wyglądałaby fabfile? Jak wyglądałoby drzewo katalogów?

Dzięki!

Tal.

pokrewne:

• Seamless deployment in Rails
-

Answer 1

Nginx umożliwia skonfigurowanie przełączania awaryjnego dla odwrotnych serwerów proxy, w których można umieścić jedną instancję Gunicorn jako podstawową i dopóki działa ta wersja, nigdy nie będzie patrzyła na przełączanie awaryjne.

Po skonfigurowaniu witryny tak, aby nowa wersja znajdowała się w instancji przełączania awaryjnego, wystarczy napisać plik fab, aby zaktualizować wystąpienie niepowodzenia nową wersją witryny, a następnie, gdy jest to gotowe, wyłączyć instancję podstawową. Nginx bezproblemowo przełączy się na drugą instancję i uruchomi nową wersję bez przestojów.

Następnie można zaktualizować wersję podstawową, a następnie włączyć ją ponownie, a urządzenie główne jest teraz aktywne. W tym momencie można na wszelki wypadek uruchomić instancję przełączania awaryjnego lub ją wyłączyć.

Kilka rzeczy do rozważenia. Musisz być ostrożny z bazami danych, jeśli używasz sqllite upewnij się, że obie instancje gunicorn mogą uzyskać dostęp do pliku sqllite.

Jeśli masz normalną bazę danych, jest to mniejszy problem, wystarczy upewnić się, że zastosujesz wszystkie migracje bazy danych, których potrzebuje nowa wersja, zanim się do niej przełączysz.

Jeśli są to zmiany kompatybilne wstecznie, to nie jest wielka sprawa. Jeśli nie są kompatybilne wstecz, to bądź ostrożny, możesz złamać starą wersję strony, zanim przejdziesz do nowej wersji.

Aby było łatwiej, uruchomiłem wersje w różnych środowiskach wirtualnych.

Jeśli używasz nadzorcy do kontrolowania gunicorn, możesz użyć poleceń superwizycji do ponownego załadowania/ponownego uruchomienia, którekolwiek wystąpienie chcesz wdrożyć bez wpływu na inne.

nadzieję, że pomoże

Oto przykład i konfiguracji nginx (nie pełny plik konfiguracyjny, usunęła nieistotnych części)

Zakłada podstawowym instancji gunicorn działa na porcie 9005, a druga jest działa na porcie 9006

upstream service-backend { 
    server localhost:9005;  # primary 
    server localhost:9006 backup; # only used when primary is down 
} 

server { 
    listen 80; 
    root /opt/htdocs; 
    server_name localhost; 

    access_log /var/logs/nginx/access.log; 
    error_log /var/logs/nginx/error.log; 

    location/{ 
     proxy_pass http://service-backend; 
    } 
} 

Answer 2

Brzmi jak trzeba dowiedzieć się, jak powiedzieć gunicorn do gracefully restart. Wygląda na to, że wszystko, co musisz zrobić, to wysłać HUP do procesu gunicorn kiedy powiadomić, aby ponownie załadować aplikację. Jak opisano w linku na temat, gunicorn docs wyjaśnić, jak to zrobić.