Ubuntu, VPS i Docker: jak przygotować bezpieczne wdrożenie aplikacji

Dla VPS i serwera dedykowanego przygotuj konto administratora z kluczem SSH oraz dostęp awaryjny z panelu dostawcy. Sprawdź logowanie w drugim oknie, zanim ograniczysz dotychczasową metodę dostępu. Pozostaw aktywną sesję do chwili potwierdzenia nowego połączenia.

Zmiany OpenSSH można umieszczać w plikach w katalogu sshd_config.d. Sprawdź efektywną konfigurację: w Ubuntu wcześniejsza wartość dyrektywy może mieć pierwszeństwo przed wpisem dodanym później. Przed przeładowaniem usługi użyj testu składni sudo sshd -t. Nie zmieniaj jednocześnie portu, uwierzytelniania i zapory bez kolejnych prób dostępu.

Zwykle do internetu wystawiasz reverse proxy z HTTPS, a aplikację, bazę danych i kolejkę łączysz wewnętrzną siecią. Publikowanie portu PostgreSQL na wszystkich interfejsach często nie jest potrzebne. Jeżeli proxy działa na hoście, można udostępnić port aplikacji tylko na adresie pętli zwrotnej.

Dokumentacja Docker zwraca uwagę, że ruch do publikowanych portów może zostać przekierowany przed regułami UFW. Sam komunikat o aktywnej zaporze nie dowodzi, że kontener jest niedostępny z zewnątrz. Zweryfikuj reguły Docker, ustawienia sieciowe i faktyczną dostępność portów z innego urządzenia.

Przygotuj obraz z konkretną wersją aplikacji i zależności. Nie opieraj wdrożenia na przypadkowo zmienianym katalogu kodu montowanym z laptopa. Oddziel ustawienia środowiska produkcyjnego, sekrety, logi oraz dane trwałe. Włącz politykę restartu i mechanizm sprawdzania gotowości usługi.

Dane PostgreSQL, przesłane pliki i inne trwałe zasoby nie powinny znikać po zastąpieniu kontenera. Wolumen rozwiązuje trwałość względem cyklu życia kontenera, ale nie zastępuje kopii zapasowej. Testuj jego uprawnienia i ścieżkę odtworzenia. Dostęp do środowiska administracyjnego Docker przydzielaj tylko osobom, które mają zarządzać hostem.

Skontroluj konfigurację unattended-upgrades, źródła pakietów i raportowanie błędów. Dodanie zewnętrznego repozytorium nie oznacza automatycznie, że narzędzie będzie aktualizować pochodzące z niego pakiety. Ustal także zasady restartowania usług i całego systemu po aktualizacji.

Aktualizacja hosta nie aktualizuje automatycznie bibliotek znajdujących się wewnątrz obrazu aplikacji. Nowy obraz zbuduj, przetestuj i wdroż w kontrolowany sposób. Zachowaj poprzednią wersję oraz kopię danych sprzed migracji schematu. Sam powrót do starszego obrazu może nie wystarczyć, jeżeli zmieniono strukturę bazy.

Najpierw wdroż identyczny obraz na środowisko testowe z osobnymi danymi. Sprawdź logowanie, zapis rekordu, działanie zadania w tle i przywrócenie kopii. Następnie przygotuj kopię produkcji, wykonaj migrację według planu i przełącz ruch na nowe wydanie.

Po publikacji kontroluj odpowiedź HTTPS oraz faktyczny proces użytkownika. Ustal progi alarmów dla błędów, braku miejsca, nieudanych kopii i wygasających certyfikatów. Serwer wymaga opiekuna, który wie, jak zareagować na alarm — sam panel monitoringu tego nie zapewnia.

• Sprawdź z zewnątrz dostępność wyłącznie zaplanowanych usług.
• Uruchom serwer ponownie na etapie testów i sprawdź powrót aplikacji.
• Odtwórz dane na oddzielnym środowisku i zmierz czas przywrócenia.
• Przećwicz powrót do poprzedniej wersji z uwzględnieniem migracji bazy.