Repliki, skalowanie i zmiana planu aplikacji
Jak dodawać i usuwać repliki aplikacji, zmieniać plan replik bez utraty danych i kiedy używać wymiany repliki.
Aplikacja działa na jednej lub kilku replikach — osobnych maszynach, na których uruchamiamy cały Twój stack z compose. Repliki rozkładamy na różne hosty. Możesz zmieniać ich liczbę (skalowanie poziome) i plan (skalowanie pionowe).
Jedna replika czy kilka
- 1 replika — aplikacja ma publiczny adres IP, bez load balancera. To najprostszy wariant, ale bez redundancji. Liczby replik nie zmienisz później — aby mieć kilka replik, utwórz nową aplikację z co najmniej dwiema (najprościej przyciskiem Klonuj w Przeglądzie).
- 2 i więcej replik — ruch rozkłada load balancer z health-checkiem, a wdrożenia przechodzą replika po replice bez przerwy. Liczbę replik zmienisz w dowolnym momencie.
- Worker — nie ma load balancera, ale liczbę replik też możesz zmieniać.
Zmiana liczby replik
- Otwórz aplikację w https://cloud.hostava.pl, zakładkę Przegląd.
- Pod tabelą Repliki użyj przycisków − i + przy napisie Repliki:.
Nowa replika powstaje z aktualnej konfiguracji, dostaje wdrożenie i dopiero wtedy trafia do load balancera. Przy zmniejszaniu usuwamy repliki z końca listy. Maksymalnie aplikacja może mieć 10 replik. Każda replika jest rozliczana według planu, godzinowo.
Zmiana planu replik
Gdy aplikacji brakuje CPU lub pamięci, zmień plan — repliki dostaną więcej zasobów na tych samych maszynach.
- Otwórz zakładkę Ustawienia.
- W sekcji Plan replik wybierz Nowy plan z listy.
- Kliknij Zmień plan i potwierdź.
Co się dzieje:
- Repliki są zmieniane po kolei: wyłączenie, nowe zasoby, start i chwila na uruchomienie kontenerów. Dopiero potem kolejna replika.
- Przy 2+ replikach aplikacja działa w tym czasie na pozostałych. Przy jednej replice będzie niedostępna przez ok. 1–2 minuty.
- Dane zostają, także w wolumenach Dockera — to te same maszyny.
- Dysku nie da się zmniejszyć. Lista pokazuje tylko plany z dyskiem nie mniejszym niż obecny.
- Postęp (np. „zmiana planu na …: 1/3”) zobaczysz w komunikacie na stronie aplikacji.
Uwaga: Przejście na droższy plan wymaga środków na koncie na co najmniej godzinę pracy wszystkich replik w nowym planie.
Wymiana repliki
Przy aplikacji z load balancerem (oraz przy workerze z co najmniej dwiema replikami) każdy wiersz w tabeli Repliki ma przycisk Wymień. Wymiana:
- tworzy nową replikę z obrazu i definicji Compose,
- wdraża na niej aplikację i dodaje ją do load balancera,
- dopiero po udanym wdrożeniu usuwa starą replikę.
Aplikacja działa w tym czasie na pozostałych replikach, a liczba replik się nie zmienia. Jeśli wdrożenie nowej repliki się nie uda, stara zostaje. Wymiana przydaje się, gdy jedna replika zachowuje się nieprawidłowo, a ponowne wdrożenie nie pomaga. Potwierdzasz ją, wpisując nazwę repliki.
Uwaga: Dane zapisane tylko na starej replice — w wolumenach Dockera, np. baza uruchomiona jako kontener — przepadną przy wymianie. Zmiana planu ich nie usuwa, wymiana tak.
Gdzie trzymać dane
Każda replika ma własny dysk. Wolumen Dockera na jednej replice nie jest widoczny na pozostałych, a load balancer kieruje użytkowników na różne repliki. Dlatego:
- bazę danych trzymaj w zarządzanej bazie danych — ma kopie zapasowe i opcjonalną replikę z automatycznym przełączaniem,
- pliki użytkowników (zdjęcia, załączniki) zapisuj w magazynie S3,
- sesje i cache trzymaj w bazie lub Redisie, a nie w pamięci jednej repliki.
Baza i repliki w tym samym projekcie łączą się przez sieć prywatną projektu.
Wskazówka: Kopie w zakładce Kopie obejmują tylko konfigurację (compose,
.env, pliki, ustawienia), nie dane z wolumenów.
Samonaprawa
Repliki są usługą zarządzaną. Na każdej replice co minutę sprawdzamy health-check aplikacji (a przy workerze stan kontenerów). Po kilku kolejnych błędach kontenery są uruchamiane ponownie. Zatrzymaną replikę platforma sama uruchamia ponownie.
Powiązane: Aplikacja z pliku Docker Compose, Wdrożenia z CI.