w Praktyce
4 godz. 33 min · Docker · Full-stack i Programowanie
Wojciech PołowniakSr. Fullstack EngineerW początkowych sekcjach kursu, zrozumiesz czym jest Docker i jakie ma zalety wobec rozwiązań oferujących pracę z serwerami lokalnymi, np. XAMPP - poznasz jego architekturę, założenia oraz najważniejsze pojęcia, których nieznajomość często spędza sen z powiek nawet doświadczonym programistom.
Jako że Docker jest to narzędzie dla programistów i administratorów systemów operacyjnych, lwia część pracy z tym narzędziem odbywa się w konsoli. Przedstawię Ci najważniejsze polecenia powiązane z tą technologią oraz zestaw dobrych praktyk i protipów które zawstydzą niejednego inżyniera oprogramowania.
W tej sekcji tego kursu przejdziemy przez najważniejsze punkty tworzenia skonteneryzowanych aplikacji z perspektywy programisty aplikacji internetowych - jeśli chcesz szybko rozpocząć swoją przygodę z Dockerem, ponieważ znasz już podstawy teorii i czujesz się wystarczająco pewnie - możesz zacząć z tego miejsca! A jeśli tempo będzie zbyt szybkie - zawsze możesz wrócić do części teoretycznej pracy z Dockerem
Przebudowywanie zasobów na żywo, dynamiczne odczytywanie zawartości plików... To podstawowe koncepty które współcześni programiści sieci web biorą za pewnik. Przy nieznajomości Dockera, łatwo jest strzelić sobie w stopę i utrudnić swoją pracę, zabierając sobie możliwość korzystania z powyższych funkcjonalności. W tym kursie, pokażę Ci jak wygodnie pracować z Dockerem w środowisku developerskim.
Jedną z wielu zalet Dockera jest niewątpliwie proste przenoszenie zmian konfiguracji i infrastruktury ze środowiska developerskiego na produkcyjne. W tym kursie, poza przyswojeniem podstawowej wiedzy na temat Dockera poznasz szereg dobrych praktyk w kontekście bezpieczeństwa oraz przygotowywania Twoich aplikacji pod środowisko, na którym będzie uruchomiona Twoja aplikacja gdy uznasz że jest gotowa by ujrzeć światło dzienne.
Ten kurs to zestaw kompleksowej wiedzy dzięki której dowiesz się jak od zera, na żywo, stworzyć aplikację na Twoim lokalnym środowisku - i jakie kroki należy podjąć, aby móc zobaczyć ją w internecie - wszystko w kontekście Dockera, wysokiej skalowalności i bezpieczeństwa. W jednej z ostatnich lekcji kursu zobaczysz jak robię deploy na serwery DigitalOcean by uzyskać link do swojej nowo zbudowanej aplikacji internetowej.
Ten kurs jest kierowany do webdeveloperów, bądź zaawansowanych programistów którzy nie pracowali jeszcze z Dockerem. Przydatne może być zrozumienie interfejsu linii poleceń czyli tzw. konsoli, oraz podstawowa wiedza na temat web developmentu czy systemów operacyjnych. Jeśli potrafisz korzystać z systemu kontroli wersji git, na pewno ułatwi to Tobie zrozumienie konceptu pracy z poleceniami dockera. Niemniej, każde zagadnienie staram się tłumaczyć na bieżąco.
W tej lekcji opowiem o tym, jak
rozwiązywać problemy z portami zarówno na hoście, jak i wewnątrz Dockera.
Jeżeli przeszedłeś zgodnie z chronologią tego kursu od początku do końca
przez sekcję o szybkim starcie, wtedy wiesz jak tworzyć i wystawiać porty
wewnątrz Dockera i mniej więcej o tym jak porty działają.
To, co często się zdarza,
niezależnie od tego czy pracujemy na hoście czy na ten problem akurat jest
uniwersalne po prostu z natury tego jak działają aplikacje internetowe.
To, że porty ze sobą kolidują i jest to całkiem prosto przedstawić na
zasadzie stworzenia przykładowego serwera HTTP na naszym hoście.
Czyli jeśli na przykład mamy
jakiś serwer lokalny, który jest uruchomiony powiedzmy na porcie
000 to jest nasz broadcast, aby był dostępny zewsząd
na porcie 7 7.7, to w tym momencie ten port 7 7.7 jest zajęty przez ten proces.
Jeśli stworzymy sobie drugi.
Taki proces.
Czyli będziemy chcieli jeszcze raz uruchomić jakiś inny serwer
na tym samym porcie, to otrzymamy tutaj informację, że
na tym adresie, na tym porcie, ponieważ jest on od razu jest już w użyciu.
I tak samo jeżeli jakaś inna aplikacja
próbowała wystartować na tym porcie no to często jest tak, że trzeba najpierw
ten program, który używa tego portu po prostu wyłączyć.
No i jak to zrobić?
Można do tego wykorzystać polecenie ls off.
Oczywiście w zależności od systemu operacyjnego
i generalnie preferencji użytkownika możecie użyć dowolnego polecenia.
Ja po prostu znam i lubię ls i składnia jest po prostu taka, że mamy ls off.
Podajemy jako i nazwę interfejsu port 7 7.7 i tutaj otrzymujemy nazwę procesu
numer procesu, który właśnie nasłuchuje na tym porcie.
I to co teraz możemy zrobić to jest już typowo systemowo administracyjne.
Po prostu polecenie kill żadnego docker kill.
Tu chodzi o faktyczne procesy na naszym systemie operacyjnym, na naszym hoście.
Minus 9 jako sygnał dziewiąty.
O nim też już mówiliśmy w poprzednich częściach tego kursu.
No i podajemy adres procesu, który chcemy zabić.
No i ponownie. PS.
Jak wpiszemy sobie, to oczywiście tych procesów tutaj będzie dużo.
Możemy wpisać po prostu ls
i 7, 7, 7 i ponownie tutaj będzie po prostu pusta lista.
Czyli jakbyśmy chcieli teraz wystartować kolejny serwer PHP.
A zresztą możemy wrócić do poprzedniej zakładki z terminala i zobaczyć, że
on tutaj po prostu napisze nam, że został zabity z sygnałem 9 i możemy znowu go
tutaj sobie uruchomić i nie będzie z tym problemu.
Czyli jeśli chcielibyśmy uruchomić jakąś
inną aplikację na tym porcie, możemy to teraz zrobić?
A jeżeli znowu jakiś inny port by
kolidował, no to możemy wykorzystać LS off i i numer portu, aby znaleźć te porty,
które są zajęte przez aplikację na naszym hoście.
To jest część hosta.
Mamy jeszcze część kontenera, czyli jakbyśmy tutaj wyszli z tego basha i
chcieli uruchomić to znowu znowu next jest fajne
i chcielibyśmy wystawić powiedzmy tą aplikację na porcie 80, 80, 80, 80.
Tylko że na Linuksie to jest port 80, więc tutaj musimy dać 85 88.
Uruchomimy.
I teraz możemy spróbować wejść na 8080 i widzimy ekran powitalny.
Powiedzmy, że będziemy chcieli tutaj uruchomić.
Nie wiem co jeszcze, ale
w tej chwili czyli Apache i ponownie chcemy to zrobić na porcie 80 80.
Zobaczmy co się stanie.
On oczywiście spróbuje nam pobrać ten obraz.
I o ile gdy jest uruchomiony na porcie 80 domyślnie, to wtedy przy
samym uruchamianiu tego kontenera otrzymamy błąd.
Oczywiście na etapie polowania błędu nie ma, bo musimy najpierw go pobrać.
No i oczywiście widzimy, że jest tutaj informacja Bind for 80 80V port located.
Najprościej jest to znaleźć po prostu poprzez docker ps
i tutaj widzimy wszystkie porty, które dany kontener wystawia.
I rozwiązaniem tego problemu jest po prostu pozbycie się tego kontenera.
Czyli docker kill już będziemy bezpośredni.
Po prostu zabijamy
i w tym momencie będziemy w stanie uruchomić serwer serwer i zobaczmy.
Po odświeżeniu mamy Networks, czyli standardowe Apache ekran powitalny.
Więc tak wygląda rozwiązywanie problemów z portami.
Po prostu trzeba znaleźć źródło problemu, czyli
który proces korzysta z danego portu albo który kontener w przypadku Dockera.
No i go wyłączyć, bo to też oczywiście może być tak, że chcecie uruchomić jakąś
aplikację na Waszym hoście, ale docelowy kontener zajmuje Wam ten port, więc o tym
trzeba pamiętać i jest to też bardzo przydatne w web development.
No bo oczywiście często mamy taką
sytuację, że musimy mieć uruchomione zarówno jakieś API
jak i serwer plików statycznych powiedzmy i na tym samym porcie.
Jakoś trzeba to rozwiązać, jeśli chcielibyśmy to rozwiązać na takiej
zasadzie, że chcemy mieć zarówno Apache i engine CSA uruchamianego
równolegle, to po prostu zmieniamy tutaj port na hoście z 87 81 W.
Nie ma z tym najmniejszego problemu.
Czyli tutaj mamy na 80 Apache.
Na 81 też uruchomiłem Apache.
Możemy zrobić engine CSA.
Na osiemdziesiątce dwójka.
Jak widzicie, tych serwerów lokalnych
możemy sobie uruchomić naprawdę w ciągu minuty
20, gdzie w przypadku rozwiązań takich jak XAMPP mamy po prostu jeden
statyczny serwer, z którym ciężko jest jakoś głowę skalować w górę.
To wszystko w tej lekcji.
W następnej lekcji przejdziemy do wspominanego wcześniej Docker,
czyli tworzenia nowego obrazu na podstawie zmian naniesionych na dany kontener.