[kefas_safek]

mirki od #php i #docker mam taka rozkmine, w sumie ona tez bedzie dotyczyla #nodejs i wszystkiego, co zaciaga zaleznosci. Otoz powiedzmy, ze robie sobie dockera z phpowa czy nodowa aplikacja. Jakie jest tzw "best practices" zeby poradzic sobie z instalacja zaleznosci?
Bo na razie wyobrazam sobie tak, ze docker-compose ma:
- kontener z phpem
- kontener z np nginxem
- opcjonalnie z baza (chociaz baza bedzie na zewnatrz, bardziej dewelopersko)
No i teraz jak sobie zrobie docker-compose up -d to mi postawi phpca, nginxa, wszystko git, a co z instalacja pakietow? to trzeba recznie? Ale przeciez nie mam phpa xD. No chyba, ze w kontenerze z phpem jest composer, wchdze tam przez konsole i odpalam "z reki" aczkolwiek chcialbym to zautomatyzowac. Tak wiec mistrzowie: jak to sie robi? Podrzuce jeszcze #javascript to moze ktos z node sie zlapie, #docker dla zasiegu :)

[croppz]

@kefas_safek: ja zawsze w cmd phpowego kontenera wstawiam composer install ; php-fpm. Chwilę dłużej przez to wstaje, ale nie trzeba się zastanawiać czy w międzyczasie ktoś czegoś nie doinstalował. Czy powinno się tak robić? Nie wiem, u mnie działa. ¯\_(ツ)_/¯

Jeszcze można dodać odpalanie migracji bazy, wygodna sprawa.

[kefas_safek]

@croppz: a jak dojdzie w miedzyczasie jakas zaleznosc to wtedy z palca donstalowujesz czy robisz recreate obrazu? :)

[y.....l]

@kefas_safek: Na produkcji robię multi stage build i instaluje wszystkie zależności.

W docker compose robię sobie tak, że po odpaleniu sobie instaluje, mam do tego pęgę skryptów.

[orkin2913]

@kefas_safek: ogólnie zasada jest taka by obraz produkcyjny miał już pobrane zależności i przekompilowany kod - powinieneś to dorzucić do Dockerfile.
Taka praktyka ma dwa plusy: deploy obrazu to kilka sekund a nie kilka minut, nigdy nie zostaniesz zaskoczony jakąś nową niekompatybilną wersją jakiejś zależności. Każda zmiana wersji pakietu, którą pchasz na proda powinna być robiona umyślnie a nie przypadkiem. Natomiast w developerskim obrazie rób jak Ci wygodnie. Najczęściej robi się

[croppz]

@kefas_safek: w którym międzyczasie? Jeżeli chcę coś dodać to normalnie composer require, jeżeli dociągam zmiany z repo to docker-compose down i up.

No i oczywiście mówię tutaj o środowisku developerskim z podpiętym volume, na produkcji tak jak mirek wyżej napisał.

[kefas_safek]

@orkin2913: @croppz: to moze podpowiedzcie jak z produkcja bo dewelopersko to faktycznie nawet i db mozna sobie postawic i volume podpiac. W jaki sposob przygotowujecie paczke pod deploy? Caly kod jest zipowany i deployowany jakims nie wiem, octopusem czy innym narzedziem?

[orkin2913]

@kefas_safek: najpopularniejszym rozwiązaniem są przeróżne CI dostępne na Githubie (GitHub Actions), Gitlabie (gitlab-ci), zewnętrzne CI jak np Travis lub CircleCI (darmowe dla projektów OpenSource), ale również np selfhosted Jenkins. Wszystkie te rozwiązania wyłapują commity na repozytorium GITa, klonują projekt, budują obraz i pchają go np na Kubernetesa. Wszystko zależy jak sobie to skonfigurujesz

[kefas_safek]

@orkin2913: zadnego z nich nie moge niestety uzyc, bo korpoprocedury... Mam do wyboru teamcity + octopus (obu nie znam za bardzo), nie chce robic kubernetesa tylko zrobic jakis etap przejsciowy i np przejsc pod samego dockera na razie. I jeszcze jedno - nie chce robic continues delivery tylko tak jakby na żądanie - czyli nei wiem, klikne "zrob deploy" to wezmie ostatni commit / ostatniego taga i go wrzuci. Zrabialne czy

[bmLq]

@kefas_safek:
Tak książkowo powinieneś w Dockerfile zrobić wszelkie composer install itp. Tak że twój gotowy obraz wystarczy odpalić. Potem taki obraz #!$%@? do repo (np. dockerhub) i na serwerze odpalasz. Jeżeli masz zamiar wrzucić nginx i php fizycznie na różne serwery to poszedł bym w tą stronę w przeciwnym wypadku opcja 2 jest równie atrakcyjna. To podejście też stosuje się z wszelkimi automatami typu aws beanstalk itp.

Opcja 2 teoretycznie mniej

[dnaprawa]

@bmLq: nie siedzę w php, ale domyślam się że Composer przywraca zależności. Dlaczego nie multi-stage build oraz przywrócenie zależności w Dockerfile'u?

[bmLq]

@dnaprawa: przy opcji 1 można a nawet wypada tak zrobić jak najbardziej

[bmLq]

@dnaprawa: w sumie przy produkcyji z docker compose też można tak zrobić. Nie pomyślałem o tym bo docker compose zazwyczaj używam przy devie a tam potrzebujesz zależności na hoście w podmontowanym katalogu i przy buildzie nie ma opcji żeby skopiować pliki spowrotem na hosta

[dnaprawa]

@bmLq: do developerki możesz sobie zrobić osobny Stage, a w docker-compose wskazać ten stage przy sekcji 'build'. W ten sposób możesz jeden Dockerfile wykorzystać zarówno na produkcję jak i do developerki

[bmLq]

@dnaprawa: nie do końca. Do deva potrzebuje np. Zainstalować xdebu do proda potrzebuje skopiować pliki i composer install na nich (upraszczam).
To jaka ma być kolejność? Dev nie może być pierwszy bo na prodzie musiałbym odinstalować xdebuga co byłoby bez sensu. Teoretycznie jak najpierw zrobię proda i potem z tego deva to z.adziała ale dla deva będzie niepotrzebnie kopiować pliki i robić composer install bo potem to zostanie i tak nadpisane

[dnaprawa]

@kefas_safek: nie musisz nic "odinstalowywać". W budowaniu obrazu produkcyjnego, brany pod uwagę jest tylko OSTATNI stage. Na development możesz zrobić osobny Stage i tylko jego odpalać lokalnie tak jak mówiłem wcześniej.

[dnaprawa]

@kefas_safek: opcja 3 Dockerfile to zło. Uwierz mi. Rozwiązaniem większości Twoich problemów będzie multi-stage build.

Jeżeli masz ochotę, to zajrzyj na https://szkoladockera.pl (jestem autorem) - po inne Dockerowe rzeczy.

[kefas_safek]

@dnaprawa: a co nie jest złem?

[dnaprawa]

@kefas_safek: wszystko - oprócz wielu Dockerfilów