Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

 
Reply to this topicStart new topic
> Organizacja projektu z Dockerem
athabus
post 29.12.2018, 20:46:10
Post #1





Grupa: Zarejestrowani
Postów: 898
Pomógł: 48
Dołączył: 2.11.2005
Skąd: Poznań

Ostrzeżenie: (0%)
-----


Hej chciałbym z mojego projektu stworzyć paczkę do instalacji przez composera i zastanawiam się jak powinienem ją zorganizować. W projekcie mam między innymi konfigurację Dockera i nie wiem czy to powinienem wykluczyć z paczki?
Co z plikiem composer.lock?

Ogólnie struktura mojego projektu wygląda tak jak na obrazku:


Wolałbym trzymać te wszystkie pliki w repozytorium, ale nigdy nie robiłem jeszcze paczek do composera i chciałbym uniknąć jakiegoś przypału, gdyby ktoś przypadkiem postanowił użyć mojej biblioteki ;-)

Poradzicie coś?
Go to the top of the page
+Quote Post
Janusz1200
post 30.12.2018, 12:40:50
Post #2





Grupa: Zarejestrowani
Postów: 110
Pomógł: 6
Dołączył: 19.12.2010
Skąd: Krzyżanowice

Ostrzeżenie: (0%)
-----


Nie wiem, czy przegapiłeś to w dokumentacji composer:
You should commit the composer.lock file to your project repo so that all people working on the project are locked to the same versions of dependencies (more below).


Ten post edytował Janusz1200 30.12.2018, 17:52:50
Go to the top of the page
+Quote Post
Pyton_000
post 30.12.2018, 13:08:20
Post #3





Grupa: Zarejestrowani
Postów: 8 068
Pomógł: 1414
Dołączył: 26.10.2005

Ostrzeżenie: (0%)
-----


Dockera możesz wywalić bo jest zbędny. Jak go dołączysz to nic się wielkiego nie stanie. lock jak wyżej napisał kolega musi być.

Dobra faktycznie @pyro ma rację ad .lock smile.gif

Ten post edytował Pyton_000 30.12.2018, 16:01:56
Go to the top of the page
+Quote Post
pyro
post 30.12.2018, 15:45:45
Post #4





Grupa: Zarejestrowani
Postów: 2 148
Pomógł: 230
Dołączył: 26.03.2008

Ostrzeżenie: (0%)
-----


Dwa powyższe komentarze trochę bezrefleksyjne :-)

W przypadku, gdy tworzy się paczkę, którą ktoś może następnie pobrać np. z Packagista, wtedy NIE NALEŻY commitować `composer.lock`

// EDIT

Z tego co widzę vendor nie jest ignorowany? A powinien być

Przy okazji jak robisz paczkę, z którą mają korzystać inni, to dobrze żeby była przynajmniej w miarę pokryta testami

Ten post edytował pyro 30.12.2018, 15:41:31


--------------------
ET LINGUA EIUS LOQUETUR IUDICIUM
Go to the top of the page
+Quote Post
athabus
post 30.12.2018, 15:50:22
Post #5





Grupa: Zarejestrowani
Postów: 898
Pomógł: 48
Dołączył: 2.11.2005
Skąd: Poznań

Ostrzeżenie: (0%)
-----


Ok czyli dockera zostawiam dla własnej wygody. Z composer.lock to już chyba będzie wyższa szkoła jazdy. Wczoraj wysłałem pierwszą wersję projektu do gitlaba z wykluczonym composer.lock i już na wstępie wywalił mi budowanie projektu, bo ten plik jest wymagany (testów jeszcze nie mam i nie wiem czy w tym projekcie będą, ale wynika z tego, że w samym repo na gitlabie warto trzymać composer.lock).
Z drugiej strony też mi się wydaje, że dla paczek composerowych nie powinno być. Czyli wynika z tego, że po drodze repo -> packagist trzeba jakoś ten plik wykluczyć. Jeszcze nie badałem tematu (nigdy nie tworzyłem paczek), ale pewnie jest na to jakiś automatyczny sposób, skoro w repo powinno się trzymać ten plik a w paczce już nie.
Go to the top of the page
+Quote Post
pyro
post 30.12.2018, 16:00:42
Post #6





Grupa: Zarejestrowani
Postów: 2 148
Pomógł: 230
Dołączył: 26.03.2008

Ostrzeżenie: (0%)
-----


Dockera u siebie możesz zostawić dla wygody, jednak nie powinieneś go commitować (.git/info/exclude). Istnieją (z reguły rzadkie) przypadki, gdzie komponent może być dodany jako biblioteka do projektu jak i istnieć jako samodzielny serwis i wtedy może być commitowany, jednak patrząc po strukturze katalogów nic nie wskazuje na to żeby w tym przypadku miało tak być. Swoją drogą zastanawiam się po co Ci tutaj w ogóle ten docker, skoro nie widać nawet punktów wejścia. Jego użycie tutaj mija się z celem, zastanawiam się w jaki sposób to developowałeś biggrin.gif

Jeżeli przy braku composer.lock wysypuje Ci się build, to oznacza kwestię nieprawidłowej konfiguracji builda / CI, a nie braku tego pliku.

Ten post edytował pyro 30.12.2018, 16:01:36


--------------------
ET LINGUA EIUS LOQUETUR IUDICIUM
Go to the top of the page
+Quote Post
athabus
post 30.12.2018, 17:14:36
Post #7





Grupa: Zarejestrowani
Postów: 898
Pomógł: 48
Dołączył: 2.11.2005
Skąd: Poznań

Ostrzeżenie: (0%)
-----


To jest biblioteka, która służy do tworzenia i cachowania inlinowych preview obrazów, czyli w skrócie tworzy z dowolnego obrazka według zadanych filtrów preview i inlinuje go za pomocą base64 - to plus info o prawdziwmy obrazku zapisuje do cachu (u mnie redis, ale można też zrobić wersję plikową czy db).
Zamysł jest taki aby potem wykorzystywać to z jakąś biblioteką js do deferowania łądowania obrazów below the fold.
Tutaj taki przykład jak załadować stronę z 1.6mb obrazów w ~30ms: http://vps510947.ovh.net/inliner/deferred/index.html

Co do developmentu, to docker jest tak skonfigurowany aby root_dir miał w folderze examples, gdzie dałem różne sposoby użycia - na nich sobie developuje.

Zresztą tutaj jest samo repo: https://gitlab.com/hadwao/image-inliner

PS. Kod jeszcze nie jest skończony, na razie taki bardziej proof of concept, ale chce tą przekształcić w paczkę composera, aby wykorzystać testowo w jednym projekcie.

Ten post edytował athabus 30.12.2018, 17:17:10
Go to the top of the page
+Quote Post
by_ikar
post 30.12.2018, 21:55:24
Post #8





Grupa: Zarejestrowani
Postów: 1 798
Pomógł: 307
Dołączył: 13.05.2009
Skąd: Gubin/Wrocław

Ostrzeżenie: (0%)
-----


https://gitlab.com/hadwao/image-inliner/blo.../Dockerfile#L23

Kod
RUN service apache2 restart


to kompletnie nie ma sensu. Wszystko co jest w Dockerfile z wyjątkiem komendy CMD/ENTRYPOINT jest wykonywane tylko podczas budowania, restartowanie serwisu kompletnie nie ma sensu. Zwłaszcza że obraz powinien wystawiać np proces który będzie kontrolowany za pomocą samego dockera (czy innego narzędzia), a nie jakiegoś dodatkowego systemu init (systemd, upstart, runit etc), to nie jest obraz maszyny wirtualnej, czy konfiguracja vagranta. Dlatego też apache działa tam jako foreground: https://github.com/docker-library/php/blob/...Dockerfile#L259

Co do samego tematu: jeżeli masz tylko jedną definicje Dockefile, nie używasz żadnych dodatkowych skryptów do inicializacji twojej aplikacji, to moim zdaniem najlepiej jakby był w root, zamiast ukrywania go gdzieś bezsensu.

Ten post edytował by_ikar 30.12.2018, 21:58:27
Go to the top of the page
+Quote Post
pyro
post 31.12.2018, 00:45:39
Post #9





Grupa: Zarejestrowani
Postów: 2 148
Pomógł: 230
Dołączył: 26.03.2008

Ostrzeżenie: (0%)
-----


Swoją drogą czemu PHP 7.0, który już nawet nie jest utrzymywany, zamiast 7.2 lub 7.3?

Ten post edytował pyro 31.12.2018, 00:52:03


--------------------
ET LINGUA EIUS LOQUETUR IUDICIUM
Go to the top of the page
+Quote Post
athabus
post 31.12.2018, 08:07:40
Post #10





Grupa: Zarejestrowani
Postów: 898
Pomógł: 48
Dołączył: 2.11.2005
Skąd: Poznań

Ostrzeżenie: (0%)
-----


@by_ikar - dzięki za rozjaśnienie tematu z restartem. W Dockerze dopiero raczkuję i efekty osiagam głównie na zasadzie copy&paste. Wiem, że to nie najlepsza metoda, ale od czegoś trzeba zacząć ;-) To "ukrywanie" wynika z tego, że nigdy nie wiadomo jak się projekt potoczy i co jeszcze będzie potrzebne, więc o prostu trzymam się takiego standardu. Ale tak jak pisałem, dopiero zaczynam zabawę z Dockerem, więc nie wiem czy działam optymalnie.

@pyro - potrzebuję tej biblioteki do serwisu, który działa pod 7.0 i raczej nie zanosi się aby był upgradowany w najbliższych 2-3 latach.
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 29.03.2024 - 01:13