[mirunek]

Mircy, zajmuję się #programowanie ale coraz częściej spoglądam w stronę #devops #docker. Zastanawiam się jakie są dobre praktyki związane z tworzeniem aplikacji #php #symfony z perspektywy właśnie devopsa czy (bardziej doświadczonego) developera.

Co mam na myśli?
Założmy, że mam aplikację która potrzebuje: serwer www (nginx, apache, etc.), php, mysql, rabbitmq, redis.
Obraz aplikacji będzie zawierał naturalnie kod php, ale tu pojawia się pytanie o resztę. O ile mysql, rabbitmq, nie powinien być w produkcyjnym obrazie (kontenerze bo jeśli kontener padnie, ubijemy dockera to tracimy dane), to co z nginxem?

a) Czy na VPSie instaluję tylko dockera, a obraz aplikacji zawiera też serwer www? I wtedy jedyne co robimy to odpalamy obraz i aplikacja sama wstaje?
b) Czy może VPS zawiera dockera, nginxa (który nie jest kontenerem), i wtedy przekierowujemy jakoś ruch z nginxa na uruchomiony obraz aplikacji?

Devopsowanie nie jest moim celem, ale chce poznać dobre praktyki, chcę zrozumieć proces, chcę umieć postawić małą apkę od A do Z (pisanie kodu, budowanie obrazu, deploy, CI/CD).

[tylko_na_dole]

@mirunek: ja w projekcie miałem tak: docker-compose dla każdego środowiska (local, dev, prod) i te obrazy były uruchamiane na serwerze na którym był zainstalowany docker.

Na serwerze było wiele projektów, a każdy miał swój obraz kontenera php, mysql, nginx

[mirunek]

@tylko_na_dole: o ile wiem, docker-compose jest tylko po to żeby uruchamiać środowiska lokalnie (czy to prod, czy dev), zgadza się? A jeśli chodzi o Dockerfile to tam trzymamy info o obrazie dla poszczególnych środowisk, tak?

Czy "swój" mysql oznaczał, że obraz zawierał już mysql produkcyjnie? Czy mysql, rabbitmq nie powinien być wystawiony gdzieś na zewnątrz, jako zewnętrzna usługa?

[mutencath]

@mirunek:

kontenerze bo jeśli kontener padnie, ubijemy dockera to tracimy dane),

Doczytaj o pv

[tylko_na_dole]

@mirunek: z tego pierwszego wpisu to u mnie była odpowiedź a).

o ile wiem, docker-compose jest tylko po to żeby uruchamiać środowiska lokalnie

no własnie nie, jego się uruchamia na serwerze produkcyjnym

A jeśli chodzi o Dockerfile to tam trzymamy info o obrazie dla poszczególnych środowisk, tak?

u mnie Dockerfile był oddzielnie do każdego docker-compose. Było w sumie 3 Dockerfile dla php-fpm

Czy "swój" mysql oznaczał, że obraz zawierał już mysql

[tylko_na_dole]

kontenerze bo jeśli kontener padnie, ubijemy dockera to tracimy dane

@mutencath: ustawiasz "volumes:" na ścieżkę i tam są trzymane dane, tak jak w konfigu tej bazy

[mirunek]

@tylko_na_dole: czyli to znaczy, że mariadb jest zainstalowana na serwerze i jako kontener dockerowy, tak? I to znaczy, że dane są "share'owane"?

[tylko_na_dole]

@tylko_na_dole: to znaczy że pliki mariadb zostały przekopiowane to folderu w projecie w 'data/db'. Mariadb nie jest zainstalowana na serwerze. Jest kontener który ma mariadb.

Dodatkowo w .gitignore dodajesz data/ tak aby nie skomitować ich na lokalu i tak żeby nie wyrzucić ich na serwerze.

[tylko_na_dole]

e dane są "share'owane"

@mirunek: chyba tak, nie wiem w sumie jak działają volumes ;)

[rippie]

@mirunek Docker compose służy do odpalania kilku kontenerów za pomocą jednego configu. Do każdego serwisu (kontenera) w compose file możesz podpiąć dockerfile na podstawie którego ma powstać ten kontener lub użyć gotowego obrazu z rejestru. Potrzebujesz więc dockerfile ze swoją aplikacja PHP, a resztę serwisów (rabbitmq, Redis, DB, nginx) zasysasz z neta jako gotowce i podajesz im w compose file odpowiedni konfig, żeby wszystko ze sobą gadało.

[rippie]

@mirunek @tylko_na_dole volume w dockerze mapuje odpowiedni folder w kontenerze, do folderu na hoscie. Cokolwiek zapiszesz w tym folderze w kontenerze zostanie także zapisane na hoscie dockera. Jeśli kontener padnie i postawisz nowy, config powie mu skąd ma ciągnąć dane.

[mirunek]

@rippie super. Dzięki za wyjaśnienie. Czyli tak czy siak, na hoście muszę mieć zainstalowane uugi typu mysql, nginx i muszę mapować dane. W takim razie, po co docker? Tylko do lokalnego developmentu i ewentualne zarządzanie tylko kontenerem, a nie bezpośrednio hostem?

[rippie]

@mirunek Nie musisz instalować na hoscie nic oprócz dockera i docker-compose (w nowszych wersjach dockera, compose jest opcją dockera). Za pomocą compose file tworzysz manifest, który tworzy za pomocą dockera takie mini wirtualne maszyny działające w wyizolowanym środowisku. Kontenery są łatwe w zarządzaniu i skalowaniu, dlatego używa się ich powszechnie, głównie na środowiskach produkcyjnych za pomocą np. Kubernetesa.

[mirunek]

@rippie ok teraz rozumiem.. Czyli na hoście zapisane są tylko pliki, a cała robotę robią kontenery, którym nadajemy prawa do zapisu na dysku. Kontener padnie, ale dane zostają. Dzięki

[S.....i]

docker-compose jest tylko po to żeby uruchamiać środowiska lokalnie

@mirunek: Nie tylko, rowniez do testow po za localhost i produkcyjnie przy mniejszych projektach np na VPS, przy wiekszych projektach juz K8s, plus nie zawsze wszystkie uslugi trzymasz na swojej infrastrukturze.