Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Docker - Deploy apek w PHP
Forum PHP.pl > Inne > Hydepark
Pyton_000
Siemka.

Szukam jakiegoś arta, tutka albo pomysłu jak zrobić deploy kilku apek w PHP na serwer. Chodzi mi o to jak to zkontemeryzować. Jaki schemat przyjąć żeby było elastycznie.
by_ikar
Jest kilka sposobów, począwszy od tworzenia kontenerów wraz z wszystkimi zależnościami, po podpinanie kontenera do wolumenów hosta. Jeżeli jest to wiele instancji, najlepszą opcją będzie wrzucenie wszystkich zależności do kontenera podczas jego budowania i późniejsze rolling updates gdzie można sobie ustawić żeby w jakimś odstępie czasowy jakaś ilość tych kontenerów się aktualizowała. Opisz mniej więcej co robi twoja apka, jaką ma architekturę, z czym się łączy itp itd.
Pyton_000
Takie typowe aplikacjie jak blogi, stronki itd. Stack nginx, php, mydql
Myślałem nad postawieniem wspólnego Nginx, php-fpm wg. potrzeby projektu, mysql wspólny.

Tylko teraz gdzie trzymać apkę. Tylko gdzie trzymać aplikację. Czy budować php-fpm wraz z apką, czy fpm oddzielnie i tylko zbudować kontener z aplikacją?

by_ikar
Jeżeli to wszystko będzie na jednym serwerze, to można iść na łatwiznę i wszystko postawić na zasadzie wolumenów i aktualizować poprzez gita (jakbyś to robił normalnie). Z doświadczenia wiem że najlepiej kiedy kontener jest per aplikacja. Np jeden kontener z nginx, jeden z php-fpm, jeden z mysql. Nie duplikujesz wówczas rzeczy które już masz w systemie (inity), lepsze zarządzanie logami, łatwiejsze upgrade konkretnych wersji danego kontenera.

Bawiłeś się już coś dockerem? Jeżeli jakąś konfiguracje już masz, to pokaż. Z dockerem jest taki myk, że jeżeli chcesz tworzysz kontenery z pełną aplikacją, to musisz postawić swojego registry (coś na zasadzie hub.docker.com) żeby nie płacić za trzymanie prywatnych obrazów, chyba że to nie jest dla ciebie problem - wówczas wiele rzeczy staje się łatwiejsze. Nie mniej, dla jednego hosta polecam host volumes, wówczas łatwiejsza będzie tego aktualizacja a usługi będą dostępne bez przerw.
vokiel
Jako, że ostatnio bawię się co raz więcej Dockerem to dorzucę swoje 2 gr.

Po pierwsze - najważniejsze, założeniem kontenerów jest separacja aplikacji od siebie. Perfekcyjnie by było, żeby jeden obraz miał tylko jedną aplikację (poza minimum systemowym). Czyli w Twoim przypadku minimum 3 kontenery - po jedym dla nginx, php, mysql. Ja w swojej konfiguracji dodaję jeszcze kontener tylko na dane - który jest współdzielony przez php i nginx/apache. Wszystko spinasz razem za pomocą
Kod
docker-compose
.

Druga kwestia - czy trzymać aplikację wewnątrz kontenera i podpinać wolumen z serwera. Oba rozwiązania mają swoje plusy i minusy. Kilka najistotniejszych:
Wszystko w kontenerze
- Potrzeba własnego repo na kontenery lub korzystanie z płatnych rozwiazań - bo zawierasz kod aplikacji wewnątrz kontenera.
- Przygotowanie obrazu trwa dłużej - dołączenie plików aplikacji.
- Każda nowa wersja aplikacji wymaga utworzenia nowego projektu.
- Deploy jest ciut większy - bo jest wraz z plikami projektu.
- Podniesienie tego na serwerze jest szybsze - uruchomienie kontenera, ubicie starego - gotowe.

Kontener bez plików aplikacji
- Nie trzeba tworzyć nowego orbazu przy każdym upgrade aplikacji.
- Może być dostępny w publicznym hubie.
- Mniejszy rozmiar obrazu.
- Deploy wymaga zaciągnięcia plików projektu i dopiero potem obrazu i jego uruchomienie.

Jeśli często powstają nowe wersje aplikacji, to robienie pełnych obrazó po każdej aktualizacji trzeba zautomatyzować, bo inaczej będzie przy tym sporo pracy (CI powinien o to zadbać). Natomiast przy rozwiązaniu z host volumes można aktualizować tylko pliki aplikacji - nawet jakimś hookiem z gita, czy z CI. Wtedy kontener będzie działał cały czas, nawet nie trzeba go restartować.

Przenosiny na nowy serwer są łatwiejsze jeśli cały projekt jest w obrazie, nie trzeba wtedy oddzielnie pobierac plików projektu (chociaż to też można zautomatyzować skryptem - ale jednak kilka kroków więcej).
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.