Co chcę osiągnąć? Zbudować projekt od a do z, czyli: napisać kod (php), wykorzystać dockera i zrobić pełne CI/CD (testy, budowanie obrazu, deploy na vpsa itd.)
Stack php, mysql, nginx
Struktura - src - public --index.php -Dockerfile -docker-compose.yml
1. Co powinien zawierać ten Dockerfile? a) tylko interpreter PHP i skopiowany kod b) wszystko potrzebne do działającej apki, czyli kod php, interpreter php, nginx, mysql?
W poprzednim wpisie powiedzieliście żeby na VPSie zrobić docker-compose up -d bo można przez docker-compose.yml zarządzać konternerami. OK, rozumiem, w takim razie....
2. Po co budować obraz aplikacji i zamiast zrobić docker run -p 80:80 -e..... to koniec końców, na vpsie leżą pliki i wykorzystywany jest docker-compose ? Przecież to samo można byłoby osiągnąć (nawet przez Github Actions) przez upload plików na serwer i tyle.
3. Jak powinien w takim wypadku wyglądać docker-compose.yml? Przykład link https://pastebin.com/ZuAama4Z lub poniżej:
@annotate nie kwestionuję, tylko zadaje pytania żeby to zrozumieć. Jeśli 1a, to czy docker-compose nie powinien wyglądać inaczej? Kontener php, powiniennodwolywac się do mojego customowego (zbudowanego) obrazu? Czy wystarczy ten build context z kropka?
Przecież to samo można byłoby osiągnąć (nawet przez Github Actions) przez upload plików na serwer i tyle.
@mirunek: no i ja tak właśnie robię. Pchanie obrazu przez docker huba wydaje mi się, że ma sens jak korzystasz z jakichś rozwiązań do deploy jak kubernetes.
To co jest tu trochę bez sensu, to że za każdym razem budujemy obraz, ściągamy biblioteki composera itd. podczas gdy można zbudować swój obraz (nawet codziennie) i go używać, kopiując tylko pliki.
2. Ja akurat używam docker-compose jedynie lokalnie, ale jak
@mirunek: Obrazu PHP nie buduj lokalnie a zewnetrznie w CI/DI, podziel go na multi stage, jeden jako target produkcyjny drugi jako developerski, deployment w CI/DI to zbudowanie obrazu i kontenera (z kodem, cache warm up itp itd) a pozniej wyslanie gotowej calosci na VPS, nie rob pod zadnym pozorem jak kolega wyzej 2 serwisow w jednym.
@Szubrawski jasne, nie zamierzałem tego robić lokalnie ale dzięki za radę. Mówiąc "wysłanie gotowej całości na vps" masz na myśli wrzucenie (przez CI/CD) plików projektu i odpalenie docker-compose up -d ?
@mirunek: Możliwych podejść jest wiele. Najłatwiej i chyba najczyściej to Dockerfile wrzucasz cały proces budowania swojej apki a potem wykorzystujesz go w docker-compose do postawienia apka + pozostałe rzeczy. Wyobraź sobie, że wykorzystujesz docker-compose do lokalnego odpalenia bazy danych, ngixa itd. a potem uruchamiasz apkę w IDE i konfigurujesz ją w taki sposób żeby łączyła się z obrazami odpalonymi przez docker-compose. I teraz jak chcesz żeby wszystko działało bez wykorzystania IDE
Mam pytania związane z #docker #devops z perspektywy #php #symfony (dla mnie jako backendowca). Moje pytania są kontynuacją https://www.wykop.pl/wpis/69825103/siema-programowanie-php-symfony-docker-jak-robicie/. Bardzo możliwe, że źle zrozumiałem to co zostało poprzednio napisane, ale to pewnie przez to, że słabo nakreśliłem sytuację i odpowiedzi dotyczyły czegoś innego.
Co chcę osiągnąć?
Zbudować projekt od a do z, czyli: napisać kod (php), wykorzystać dockera i zrobić pełne CI/CD (testy, budowanie obrazu, deploy na vpsa itd.)
Stack
php, mysql, nginx
Struktura
- src
- public
--index.php
-Dockerfile
-docker-compose.yml
1. Co powinien zawierać ten Dockerfile?
a) tylko interpreter PHP i skopiowany kod
b) wszystko potrzebne do działającej apki, czyli kod php, interpreter php, nginx, mysql?
W poprzednim wpisie powiedzieliście żeby na VPSie zrobić
docker-compose up -dbo można przez docker-compose.yml zarządzać konternerami. OK, rozumiem, w takim razie....2. Po co budować obraz aplikacji i zamiast zrobić docker run -p 80:80 -e..... to koniec końców, na vpsie leżą pliki i wykorzystywany jest docker-compose ?
Przecież to samo można byłoby osiągnąć (nawet przez Github Actions) przez upload plików na serwer i tyle.
3. Jak powinien w takim wypadku wyglądać docker-compose.yml?
Przykład link https://pastebin.com/ZuAama4Z lub poniżej:
version: "3.9"
services:
php:
build:
context: .
restart: unless-stopped
volumes:
- ./:/srv/app/
environment:
DATABASE_URL: mysql://app:password@mariadb:3306/app?serverVersion=5.7&charset=utf8mb4
depends_on:
- database
nginx:
image: nginx:1.23
ports:
- "80:80"
depends_on:
- php
- database
restart: unless-stopped
volumes:
- ./:/srv/app/
database:
image: mysql:5.7
environment:
MYSQL_DATABASE: app
MYSQL_PASSWORD: password
MYSQL_USER: app
MYSQL_RANDOM_ROOT_PASSWORD: "yes"
volumes:
- db-data:/var/lib/mysql:rw
ports:
- "3306:3306"
volumes:
db-data:
@mirunek: najpierw chcesz docker a potem sam go kwestionujesz. Nie chcesz dockera bo uważasz że nic nie wnosi to nie używaj. To na serio takie proste.
Oczywiście odpowiedź 1a. Pozostałe komponenty walnij w docker compose.
@mirunek: no i ja tak właśnie robię. Pchanie obrazu przez docker huba wydaje mi się, że ma sens jak korzystasz z jakichś rozwiązań do deploy jak kubernetes.
1. Bez dockera też używam nginx, ale zamiast mieć 2 kontenery, lub supervisord na jednym, używam php:-apache z oficjalnego obrazu PHP https://hub.docker.com/_/php.
Tak mniej więcej wygląda mój Dockerfile https://pastebin.com/t94i97aY
To co jest tu trochę bez sensu, to że za każdym razem budujemy obraz, ściągamy biblioteki composera itd. podczas gdy można zbudować swój obraz (nawet codziennie) i go używać, kopiując tylko pliki.
2. Ja akurat używam docker-compose jedynie lokalnie, ale jak