Produkcyjna konteneryzacja aplikacji

[ad-m]

Obecnie aplikacja jest przystosowana do pracy w środowisku deweloperskim w kontenerach. Nie jest to jednak poprawne rozwiązanie dla potrzeb wykorzystania kontenerów w środowisku produkcyjnym. Wymagane jest zachowanie wygodnego wdrażania lokalnego.

Dostrzegalne zmiany:

• przechowywanie kodu aplikacji w obrazie, zamiast podmontowania z hosta,
• wdrożenie pushowania na quay.io
• budowanie front-endu podczas budowania aplikacji (uwaga: nie możemy iść z tym dalej do czasu z Brak autocomplete w liście porad #729)

Uwagi obecnie na temat produkcji:

• aplikacja działa na hoście w virtualenv (playbooki https://github.com/watchdogpolska/infra/tree/master/ansible/roles/watchdogpolska.django.deploy , https://github.com/watchdogpolska/infra/tree/master/ansible/roles/watchdogpolska.django.setup )
• serwer aplikacyjny to gunicorn,
• serwer bazodanowy jest na osobnym hoście (współdzielony dla wielu aplikacji - docelowo http://www.hyperone.com/services/storage/database/ ),
• serwer pocztowy to lokalny na hoście postfix, który działa jako smart-host, który wysyła wiadomości wiadomości do e-maillabs (lokalny bufor),
• przed hostem z serwerem aplikacyjnym jest HAProxy, który dodaje m. in. CSP i terminuje SSL
• wsparcie dla zadań cron ( https://github.com/watchdogpolska/infra/blob/master/ansible/vars/instance/porady/vars.yml#L25-L74 ), albo wprowadzenia rozsądnego schedulera jako daemona,

Mile widziane:

• wsparcie dla xsendfile lub alternatywnych technologii pomijania serwowania plików przez Python, chyba że syscall snedfile problem rozwiązuje
• aktualizacja dokumentacji na temat wdrażania aplikacji,
• jeżeli to ułatwi, możemy pierw pomyśleć o zmianie storage na wykorzystaniu storage obiektowego (lokalny Minio, docelowo usługa HyperOne), ale ktoś to będzie musiał zaimplementować

[AgnieszkaZdanowicz]

@ad-m nie wiem, czy to aktualne?

[ad-m]

Tak.

[AgnieszkaZdanowicz]

@mrbojko @PiotrIw nie wiem, co to - pozostawiam Wam do oceny, czy to do zamknięcia