Docker i środowisko do developmentu

Docker i środowisko do developmentu
W1
  • Rejestracja:ponad 3 lata
  • Ostatnio:9 miesięcy
  • Postów:29
0

Zacząłem poznawać Dockera i podoba mi się idea uruchamiania aplikacji w izolowanych kontenerach. To wygodne rozwiązanie, ponieważ nie ma konieczności instalowania wszystkiego ręcznie na hoście z Windows 10 by np. uruchomić bazę MySQL. Wystarczy pobrać image, odpalić, wejść do kontenera z terminala i mogę bawić się MySQL.

Do developmentu aplikacji w PHP używałem kiedyś programu XAMPP a od pewnego czasu Laragon, ale chciałbym w całości przenieść się na Dockera. Chcę uzyskać efekt zbliżony do Laragon czyli taki, że mógłbym instalować różne wersje PHP, różne frameworki webowe (głównie Symfony) oraz mieć środowisko do developmentu bez używania programów typu XAMPP/Laragon i instalacji wszystkiego na hoście, czyli Windowsie 10.

Czy Docker pozwala na coś takiego i jeśli tak, to jak to zrobić?

serek
  • Rejestracja:około 11 lat
  • Ostatnio:około 2 godziny
  • Postów:1475
2

No tworzysz se dla każdej apki nowe środowisko, nowy docker-compose. I potem uruchamiasz ten, co potrzebujesz. Ewentualnie jeśli chcesz mieć kilka różnych apek w tym samym czasie odpalonych, to musisz pamiętać, by mieć różne porty używane, bo inaczej będą konflikty.

edytowany 1x, ostatnio: serek
HA
Ogólnie się zgadzam, poza tymi portami. Znacznie lepszym rozwiązaniem jest jakiś reverse proxy dla kontenerów typu Traefik - wtedy możesz mieć to ogarnięte za pomocą klasycznych domen i jednocześnie odpalać wiele kontenerów.
CH
porty sa lepsze i szybsze bez kombinowania. poza tym rev proxy i tak wymaga roznych portow
HA
Pozwolę się nie zgodzić. Z czystej wygody użytkowania lepiej mieć domeny jak biały człowiek, a nie gdzieś tam pamiętać, że jakiś mikroserwis jest na localhost:8081, a kolejny na 8082. Jak pracujesz w zespole to już w ogóle jest kosmos, bo ktoś sobie postawi projekt na 8085, a u Ciebie akurat inny projekt już używa tego portu i masz problem jak chcesz oba odpalić równocześnie. Jak Masz usługę typu Treafik, to po prostu ogarniasz temat dodając odpowiednie labele i wszystko z portu 80 leci przez Traefik, który serwuje odpowiedni kontener pod daną domeną.
CH
no nie ma znaczenia na jakim porcie ktos sobei postawi bo pliki ENV masz swoje i nie sa one dodawane do repo. Jednemu pasuje robic domeny inny woli portami leciec.
MA
  • Rejestracja:prawie 17 lat
  • Ostatnio:17 dni
  • Postów:644
0

Pozwala, od tego jest Docker.

Zacznij od - https://docs.docker.com/get-started/

Tutaj masz jakiś gotowiec jak nie lubisz czytać i wolisz się uczyć metodą prób i błędów - https://github.com/dunglas/symfony-docker
Ogólnie szukaj pod frazą "php symfony docker template/example"

Tutaj prosty przykład z samym PHP bez frameworka - https://github.com/mfieldhouse/docker-php-helloworld

Tutaj oficjalne info z docs symfony - https://symfony.com/doc/current/setup/symfony_server.html#docker-integration

edytowany 2x, ostatnio: Markuz
lyrog
  • Rejestracja:około 7 lat
  • Ostatnio:10 miesięcy
  • Postów:6
0

Zapoznaj się z http://devilbox.org/ .
Pełne rozwiązanie wykorzystujące dockera dla środowiska PHP. Możliwość konfiguracji dowolnej wersji PHP i baz danych MySQL czy Postgres dla dowolnej liczby aplikacji.

W1
  • Rejestracja:ponad 3 lata
  • Ostatnio:9 miesięcy
  • Postów:29
0

Czyli wszystko sprowadza się do tego, aby stworzyć co najmniej 3 kontenery za pomocą docker-compose?

Dla pierwszego kontenera tworzę Dockerfile bazując na jakimś obrazie PHP np. php:8.0.13-alpine, instaluję wszystkie niezbędne pakiety, Composera i wybrany framework. Następnie muszę wejść do środka kontenera, wygenerować nowy projekt za pomocą Composera i uruchomić aplikację. Drugi kontener dla bazy a trzeci dla nginx. Dobrze myślę?

jurek1980
  • Rejestracja:ponad 8 lat
  • Ostatnio:około 5 godzin
  • Postów:3510
3

W pliku docker-compose łączysz sobie potrzebne kontenery jak webserwer, PHP, baza czy testowo mailhog czy tam inne.
Tak stworzoną grupę kontenerów używasz per projekt. Wtedy łatwo uruchamiasz wszystko i masz gwarancję izolacji między aplikacjami.

edytowany 1x, ostatnio: jurek1980
HA
  • Rejestracja:ponad 6 lat
  • Ostatnio:około 7 godzin
  • Postów:1007
4

Ogólnie ludzie przechodzący na dockery robią kilka błędów. Jednym z nich jest odwzorowywanie schematów z tradycyjnych setupów i na przykład stawianie 1 kontenera php per wersja i odpalanie za jego pomocą wielu projektów.

Ideą dockera jest hermetyzacja projektu i dostosowanie do niego środowiska (w idealnym świecie tego samego setupu używasz na produkcji).

To co robisz to odpalasz docker-compose i w nim "wpinasz" wszystkie kontenery jakie potrzebujesz. Na początek polecam stosowanie obrazów zawierających apache/nginx. Wtedy w takim docker compose masz zazwyczaj:

  • php z apachem
  • jakaś baza danych
  • dodatkowe kontenery np. adminer (do zarządzania bazą danych), mailhog do testowania maili, elasticsearch, i co tam jeszcze dusza zapragnie.

To co uzyskujesz to po prostu zamknięte środowisko. Jak chcesz odpalić kolejny projekt to po prostu robisz drugi dokcer-compose i budujesz wszelkie potrzebne obrazy.

To przed czym muszę Cię przestrzec, to na początku napotkasz sporo problemów typu prawa do plików, walka z sieciami - jak na przykład zrobisz bazę w sieci wewnętrznej i nie udostępnisz portu to nie połączysz się z nią łatwo za pomocą jakiegoś panelu do baz danych, będziesz miał kłopot aby jednocześnie odpalić 2 projekty (kolizje portów), albo będziesz miał kolizje portów między usługami na hoście i tymi odpalonymi z kontenerów. Ogólnie jest sporo takich "pułapek", z którymi musisz sobie poradzić. Z czasem jednak zdobyta wiedz procentuje, bo otwiera kolejne możliwości typu ogarnianie procesów CI/CD. Z dockerem pracuję już od kilku lat, obecnie robię już całkiem zaawansowane konstrukcje, gdzie mikroserwisy komunikują się między sobą, automatycznie stawiające się środowiska developerskie, zabawy w CI/CD czy nawet Docker na produkcji i nadal mi się zdarza mieć niezłe WTF, ale nie wyobrażam sobie powrotu do tradycyjnych metod.

Jak zaczynałem to trudno było o materiały, ale teraz widzę, że jest tego sporo na sieci. Osobiście zainwestowałbym te 30-40zł i kupił taki kurs: https://www.udemy.com/course/docker-for-php-the-complete-course/ - pewnie w 3 godziny zdobędziesz wiedzę, jaką kiedyś się gromadziło tygodniami. Jak już ogarniesz podstawy stawiania środowisk, to potem już idzie z górki bo to tylko dodawanie kolejnych zabawek do arsenału.

Jak już się trochę wciągniesz to polecam zainteresować się: https://doc.traefik.io/traefik/providers/docker/

Dzięki temu można fajnie ogarnąć bardziej złożone struktury typu wiele serwisów komunikujących się ze sobą po API czy proste używanie dockerów na produkcji, ale na początek sobie tym głowy nie zawracaj.

W1
  • Rejestracja:ponad 3 lata
  • Ostatnio:9 miesięcy
  • Postów:29
0

Zrobiłem przykładowy projekt na podstawie tutoriala, który porusza wymienioną w tym wątku tematyką i wygląda to całkiem nieźle. Ponadto w połączeniu z VS Code i rozszerzeniem Remote - Containers można tworzyć odrębne konfiguracje edytora dla różnych kontenerów.

W skrócie nie miałbym się do czego przyczepić, gdyby nie to, że sama aplikacja w moim odczuciu wolno reaguje na dokonane zmiany w kodzie lub np. odświeżenie widoku. Często trzeba czekać kilka a nawet kilkanaście sekund zanim wykona się żądanie HTTP. Można ten proces przyspieszyć?

HA
  • Rejestracja:ponad 6 lat
  • Ostatnio:około 7 godzin
  • Postów:1007
2

Na jakim systemie stawiasz projekt? Co do zasady na Linux raczej nie powinno być zauważalnej różnicy wydajności (mówimy tu o narzucie rzędu sub 1%). W przypadku Windowsa/Maka za wiele nie powiem, bo tylko raz miałem (nie)przyjemność pracować z Dokerami na Windows. Przy użyciu WSL jako tako to śmigało, ale było trochę zabawy z konfiguracją - o ile pamiętam, główny trik polegał na tym aby dane trzymać w WSL, a nie udostępniać pliki projektu z poziomu Windowsa i trzeba było jakoś mapować PHP storma aby "łaczył" się z projektem w WSL. Ogólnie z konfiguracją Windowsa trzeba trochę powalczyć aby to śmigało. Z drugiej strony sporo ludzie pracuje z Dokerami na Windowsie więc się da. To czego doświadczasz na pewno nie nie jest normalne i ma jakąś przyczynę, którą się da wyeliminować.

serek
Nie musisz korzystać z WSLa w przypadku Windowsa, wtedy nie trzeba nic mapować itp, po prostu normalnie sharujesz volumes.
HA
Ale wtedy podobno ogólnie wydajność jest taka sobie. Piszę podobno bo mam prawie zerowe doświadczenie z Windowsem. Pamiętam, że koledzy pracujący na Windowsie robili jakieś sztuczki typu kopiowanie vendorow do kontenera aby ograniczyć ilość plików w montowanuch wolumenach. Przy WSL podobno juz tego nie trzeba robić.
serek
Ja tak pracuję i szczerze wydajność nie jest zła. Ale może po prostu nie robię nic bardziej zaawansowanego.
W1
Przerzucenie kodu do WSL rzeczywiście pomogło.
jurek1980
  • Rejestracja:ponad 8 lat
  • Ostatnio:około 5 godzin
  • Postów:3510
4

Sądząc z pierwszego postu to masz Windows 10.
Pliki projektu trzymaj w WSLu jak już napisał @hadwao .
Ścieżka z poziomu windows do katalogów to:
'\wsl$` i to wszytko. Zamiast w edytorze podawać ścieżke do projektu C:\aaa\bb podajesz tą z WSLa. Będzie działać, nie zauważysz różnicy w działaniu.

edytowany 1x, ostatnio: jurek1980
W1
Przerzucenie kodu do WSL rzeczywiście pomogło.

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.