Docker: Omówienie alternatywy do XAMPP
w Praktyce
4 godz. 33 min · Docker · Full-stack i Programowanie
Wojciech PołowniakSr. Fullstack EngineerCzego się nauczysz
- Krótkie wprowadzenie do instalacji Dockera na Twoim komputerze
- Dogłębne zrozumienie architektury Dockera dla webdeveloperów
- Szybki start - dla tych, którzy chcą poznać najważniesze koncepty w trybie przyśpieszonym
- Przedstawienie interfejsu linii poleceń - czyli praca z konsolą i terminalem
- Stworzenie serwera NodeJS z automatycznym przebudowywaniem zasobów
- Porady dotyczące bezpieczeństwa aplikacji
- Zestaw poleceń i mniej oczywistych narzędzi które zawstydzą niejednego seniora
- Uruchomienie aplikacji na produkcji przy użyciu DigitalOcean
- Szereg dobrych praktyk w pracy z Dockerem
O co tu w ogóle chodzi?
W 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.
Konsola i linia poleceń
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.
3, 2, 1... Szybki start!
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
Wygodne środowisko developerskie
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.
Bezpieczne środowisko produkcyjne
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.
Od teorii, przez praktykę - po Twoją aplikację w internecie!
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.
Dla kogo jest ten kurs?
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.
Cześć! W tej lekcji omówimy alternatywy dla XAMPP
a z jakiegoś pierwszego repozytorium, które znalazłem w internecie, które
reprodukuje nam zarówno serwer HTTP, Apache Server czy interpreter PHP.
No i oczywiście możemy tutaj sobie dodać
też naszą własną bazę MySQL czy nawet czy nawet jakiekolwiek bazy danych.
Oczywiście możemy tutaj użyć.
Więc to co możemy zrobić to albo sklonować to repozytorium.
Ja tego klonować akurat nie będę po prostu pobierał paczkę lipową
z powodów technicznych powiedzmy więc OT pakuję ten plik i po prostu go tutaj
przerzucę do naszego repozytorium w taki sposób.
W razie czego oczywiście możecie po prostu zrobić na Waszych serwerach lokalnych,
tutaj skopiować sobie GitHub like albo po prostu wziąć link gotowy.
Generalnie możecie zrobić git klon na tym
linku do githuba i to też Wam oczywiście zadziała.
Ja pobrałem więc w naszym pliku.
Tutaj mamy następującą strukturę katalogów.
Jest jakaś konfiguracja do paczki?
Jakbyśmy ją sobie na szybko przeczytali to
zobaczymy, że po prostu dodawane są konfiguracje Virtual hostów
w odpowiednim miejscu gdzie Apache się tego spodziewa i to jest ta konfiguracja.
No i widzimy, że domyślnie w tym projekcie jak sobie przesuniemy termin troszkę
dokument to jest miejsce gdzie znajduje się projekt pod chopper public.
Czyli jeżeli mielibyśmy jakiś plik html,
który chcielibyśmy umieścić na tym serwerze www to będziemy go musieli
wrzucić do shape public wewnątrz katalogu www.
Prawdopodobnie.
Oczywiście jest tutaj pełne Redmi.
Możemy zobaczyć jak powinniśmy
zainstalować ten konkretny zestaw Dockera
i widzimy, że tutaj po prostu trzeba najpierw zbudować tego Apacza.
Czyli mamy lokalny obraz Apache, który
bazuje na serwerze HTTP w wersji Alpine robi te dodawanie konfiguracji.
No i oczywiście jest też jakiś PHP owy obraz customowe, który podmienia nam
domyślną konfigurację php.ini na tą, którą mamy zadeklarowaną w naszym repozytorium.
Czyli po prostu będziemy musieli zbudować
te pojedyncze obrazy docker composer update.
Jest tutaj flaga build, która pozwala faktycznie zbudować dany obraz.
Jeżeli on się tutaj nie znajduje przejrzyjmy docker kompozycji
i jak widzimy oprócz tego, że możemy podać po prostu bezpośrednio
obraz jako image, tak jak zrobiliśmy to w poprzedniej lekcji.
Możemy też podać informacje na temat tego,
jak obraz, który będzie użyty ma zostać zbudowany.
Czyli tutaj podajemy kontekst tak jak robiliśmy wcześniej w Docker.
Bilet. Kropka.
Kropka była naszym kontekstem.
W tym wypadku kontekstem jest kropka.
A więc jakbyśmy mieli to przetłumaczyć na
takie polecenia dolarowe, które już znamy, to tak naprawdę byłoby tutaj.
Apache i Dash na Apache i Docker file jako nazwa pliku docelowego.
Ale oczywiście nie będziemy tego robili poprzez komendy docelowe, tylko po prostu
zbudujemy to zgodnie z instrukcją w firmie.
I zastanawiam się, czy będziemy musieli zbudować pojedynczo też tego.
PHP?
Możliwe, że nie, ale zobaczmy jak to wygląda w dokręca pauzie.
I tak jak mówiłem możemy mieć kilka różnych serwisów i kilka
różnych kontenerów, które zostają budowane na podstawie jednego maila.
Rozumiem, że tego PHP też powinniśmy zainstalować
raz, a jak nie będziemy musieli budować, bo jest on po prostu używany
bezpośrednio z rejestru zdalnego, prawdopodobnie
z docker chyba i tutaj nam się to będzie myliło.
Więc w międzyczasie
zobaczmy czy jest tutaj jeszcze jakiś inny obraz do zbudowania.
Budujemy tylko Apache, bo podaliśmy flagę Apache, ale z tego co widzę
Red też się zaciągnął, więc możliwe, że PHP nam się też zbuduje.
Container apache i container credits.
A czy container fp też nam się zainstalował?
Zobaczmy. RPM.
PHP fm.
A tutaj z reguły jest tak, że nazwa
kontenera jest nazwą serwisu, chyba że zadeklaruje tutaj kontener.
Jawnie jest to po prostu FN.
Jeżeli byśmy tego tutaj nie mieli, możemy
to sobie oczywiście komentować skrótem klawiszowym albo haszem.
No to wtedy nazwa serwisu byłaby PHP i tej
nazwy szukałem, ale nie zauważyłem po prostu tutaj tego container.
No i zobaczmy co się stało.
Ten serwer powinien nasłuchiwać na porcie 80.
I jak spróbujemy otworzyć localhost 80.
Pojedyncze 80k.
Widzimy, że serwer stoi, bo nie dostaliśmy
po prostu takiego pustego ekranu, że serwer nie odpowiedział.
Gdybyśmy podali jakiś inny port.
Ciekawe czemu?
Właśnie nie ma takiej wiadomości, to znaczy, że serwer HTTP stoi.
Tylko po prostu nie ma żadnego pliku do
serwowania, bo tak jak sprawdziliśmy tutaj jest wykorzystywany ten
plik i przypominam, że to jest też budowane na etapie tworzenia obrazu.
Tzn.
Nie jest to na wolumen, czyli jeżeli tutaj zrobimy jakąś zmianę
to byśmy musieli zrestartować naszego nawet samego poza, bo wtedy byśmy tylko
zastosowali i wystartowali ponownie kontener.
Musielibyśmy przebudować te obrazy.
Więc po prostu to co ja zrobię, to utworzę ten katalog.
Chopper.
Tworzę katalog public.
I tutaj dodamy ponownie naszą statyczną stronę www, z której ciągle korzystaliśmy.
Jako przykład zapiszemy i teraz jeżeli.
Dobrze wszystko rozumiem to to powinno zadziałać.
Chyba, że to też jest dodawane na etapie na etapie budowania,
ale wydaje mi się, że to powinno być zamontowane poprzez valium, valium www.
VAR www. HTML.
Czyli to powinno już zadziałać, ale możemy zrobić docker composer restart.
Zobaczymy czy to coś zmieni.
Ewentualnie mogą po prostu zrobić
literówkę chopper a chopper, więc to była literówka.
Nie musieliśmy restartować naszego serwera.
Szatan.
No i teraz odświeżyłem i oczywiście jest nasza strona i ona
chodzi już praktycznie na tym samym stacku co XAMPP.
Nie mamy tutaj co prawda bazy danych MySQL, ale mamy np.
Reddita, więc to też jest duży plus.
No i teoretycznie jeżeli byśmy zmienili to na index.php.
I tutaj chcielibyśmy wstawić
po prostu bez żadnego na razie jakby silnika do szablonów nie będziemy.
Tutaj nie mamy żadnego tłumika czy innych alternatyw do template.
Na to możemy po prostu zrobić powiedzmy.
Eko.
I powiedzmy, że parametry pakietowe.
Czyli jeżeli weźmiemy test.
Albo null.
Jestem ciekawy też jaka wersja PHP jest tutaj zainstalowana.
To też możemy zobaczyć oczywiście w PHP.
On buduje się na podstawie.
Do profila 7.2 7.2 powinien mieć już operator.
Forma pakowania.
Jeżeli mamy nulla, więc tutaj to nam
zadziała, to po prostu jest taki flashback w starych wersjach po prostu.
W nowych wersjach też mamy oczywiście podwójny znak zapytania.
Nie pamiętam nawet angielskiej nazwy w tym momencie, ale tutaj po zapisie.
To nam powinno się zaaplikować i zobaczmy czy nic nie dodaliśmy tego parametru.
Więc jeżeli zrobimy sobie test heloł PHP no to faktycznie to nam się dodaje w
jakimś losowym miejscu, ale moglibyśmy to np.
zmienić z testu na check name.
I wyświetlić to sobie zamiast.
Dockera.
Tutaj.
I tutaj możemy dać Docker jako domyślne.
Zapiszemy, wrócimy do Chrome to widzimy, że ten test już nie działa.
Ale jeżeli zrobimy sobie tak name.
I zrobimy Hello, Pippi from! Albo nawet ze spacjami.
Jestem ciekawy, jak to zadziała.
Prawdopodobnie wyskakuje 25 pi.
Prom.
Ale jak najbardziej zadziałało.
Faktycznie widzimy, że parametry zostały zamienione tutaj na 20, bo spacja nie jest
poprawnym znakiem jeżeli chodzi o URL, ale widzimy, że tutaj hello php zadziałało.
Ostatnią rzeczą, którą chciałbym pokazać była.
Oczywiście nie będziemy tutaj instalowali tej bazy danych MySQL.
Nie ma na to przestrzeni po prostu.
Ale jeśli chcielibyśmy zrobić to co
próbowaliśmy robić w poprzednich sekcjach tego kursu w kontekście
kontenerów narzędziowych, to możemy sobie stworzyć tutaj powiedzmy.
NET Tools wykorzystać ten sam obraz, czyli jej rekord.
NET Tools.
Podamy komendę.
Chyba nie musimy jej podawać jako rękę, ale zobaczymy czy to zadziała.
C.
While true do sleep 3 600.
Don pozbędziemy się wszystkich tych
niepotrzebnych wartości, pozbędziemy się natłoku.
Oczywiście możemy jawnie podpinać dane kontenery do tego samego worku, tak jak
robiliśmy to z poziomu Excela poprzez flagę Docker.
Ran Network.
Tutaj widzimy, że mamy podpiętą NASA.
Możemy to zrobić też z tego poziomu.
Chciałam pokazać jeszcze jedną krótką rzecz.
Jeżeli zrobimy sobie docker composer app
SDK to oczywiście te rzeczy, które nie były zainstalowane wcześniej.
One się tutaj do ciągną.
Ciekawe, że LPM i pozostałe nie zostały zainstalowane w pierwszej iteracji.
Prawdopodobnie wynika to z tego, że ten serwis ma tutaj zależność dps on php.
Dlatego przy budowaniu paczki
zbudował się php fsm, a on też miał zależność na reddicie, w
związku z czym te trzy obrazy zbudowały się, gdy próbowaliśmy budować Apache.
Ale pozostałe dwa npm i composer nie zostały zainstalowane.
To co chciałem pokazać to to, że możemy wchodzić na kontenery wewnątrz
Docker Composer w wygodny sposób, tak jak robiliśmy docker docker exec.
Dasz id id kontenera na ich polecenie, to
tutaj możemy po prostu zrobić docker kompost exec stała nazwa tego kontenera
według docker composer czyli nie musimy już tutaj pobierać tych id kontenerów.
Po prostu net tools i nazwa polecenia.
I w tym momencie jesteśmy wewnątrz naszego netto.
I kolejny plus.
Tak jak w kontenerach narzędziowych.
Omawialiśmy przykład, że trzeba było sprawdzić IP np.
Linuksa, żeby go po prostu skorelować.
To tutaj tego też nie musimy robić.
Wystarczy podać nazwę kontenera i zwróćcie
uwagę, że nie jestem podpięty do tej sieci co Composer czy np.
Apache, a i tak będę w stanie dobrać się.
Powinienem być w stanie dobrać się do tego serwisu, chyba że
fakt bycia wpiętym w jakąkolwiek sieć po prostu zmienia domyślne zachowanie poza.
Ale jeżeli byśmy
nie mieli tego network tutaj w całym obozie to mamy tak naprawdę tak czy siak
komunikację między tymi wszystkimi kontenerami po nazwie, nie po IP.
Więc jest to bardzo wygodne.
Tutaj widzimy, że te kontenery się bardzo
długo restartuje, więc nie mają poprawnie obsłużonych sygnałów wejściowych i
ponownie Curl w tym momencie zadziała, bo dodaliśmy go do sieci Network.
Jeżeli byśmy je wszystkie wyrzucili usunęli.
I zapisali dałby dokładnie ten sam efekt.
Więc jak widzicie w bardzo łatwy sposób.
Na tej kilkunasto minutowej lekcji zamieniliśmy cały nasz tekst.
Tak samo na w pełni zlokalizowany system, który jest skalowalny, który jest prostszy
w zarządzaniu i który łatwiej przenieść na dowolną inną maszynę.
Jeżeli np.
będziecie musieli też zmienić komputer w przyszłości.