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.
Cześć!
W tej lekcji opowiem o bardzo ważnej rzeczy, czyli ignorowaniu niepotrzebnych
plików, gdy tworzymy nasze aplikacje do Chrome.
Więc to co ja tutaj zrobię, to stworzę prostą aplikację modową.
Zrobimy npm i dowolna nazwa to jest wersja nieważna.
Lecimy dalej i to nam stworzy plik pakiet i do tego pliku pakiet Daisy.
Możemy teraz coś zainstalować.
Oczywiście ja to robię tutaj na moim hoście.
To znaczy, że mam zainstalowanego noda na moim komputerze poza doktorem.
Jeżeli ktoś nie ma tego zainstalowanego to
oczywiście można po prostu wejść do obrazu, do niego podpiąć sobie valium i w
taki sposób zainstalować jakieś pliki na hoście jeżeli mam taką potrzebę.
No i zainstalujemy sobie tutaj powiedzmy
Express, a tak naprawdę nie ma to znaczenia co zainstalujemy.
I po prostu wpiszemy tutaj jakąś konfigurację naszej aplikacji
powiedzmy const expres to będzie require express i jakaś tam prosta.
Aplikacja.
Na porcie 80.
APT get.
Powiedzmy, że na każdym request do naszego serwera.
Po prostu będziemy wysyłali jakąś informację.
Hello! Zapiszemy.
Na razie nie będziemy tego nawet uruchamiać z poziomu Dockera.
Po prostu zrobię sobie indeks.
Czy jest.
Apple samo.
Port zapiszemy.
I teraz oczywiście aplikacja się nie zawiesi, więc na porcie 8080.
Nasza aplikacja chodzi poza Dockera.
No i tutaj na gacie powinno być. Heloł!
Konsolę loga zrobiłem a nie reset.
Zrobiłem sobie press send.
Heloł!
Jeszcze raz.
Jak widzicie muszę to wszystko restartować pojedynczo, ale teraz za każdym razem,
nieważne na jaką ścieżkę wejdę, mam tutaj to.
Hello!
To jest jakaś prosta aplikacja, którą
oczywiście możemy skądś narysować, więc chcemy to skąd analizować.
To co ja tutaj sobie zrobię, to stworzenie nowego filmu, bo chcę stworzyć nowy obraz.
Zdrowie forum.
Na 17, 16, powiedzmy 17 16.
Taka składnia.
No i chciałbym dodać nasze tutaj pliki, albo może nawet zrobić to Alpina.
Nie ma to znaczenia.
Weźmy sobie 17 16.
18 Alpine.
Mam nadzieję, że będzie taki obraz.
Tak jest, więc dodamy cały nasz obecny katalog.
Cały kontekst do ścieżki AP.
Nie ma znaczenia.
I.
Teraz zrobimy to.
Kropka.
Tak, Docker.
Heavy powiedzmy latest.
To widzimy, że tutaj ten build zaczyna się działać.
Pobieramy najpierw naszego Alpina 17, więc to może chwilkę potrwać.
Natomiast następnym krokiem będzie dodanie całego naszego katalogu do AB.
Jak widzicie ja tutaj mam Note models od
razu w moim Kitek Ignore, który jest w całym repozytorium tej lekcji tego kursu.
Ale jeśli wejdziemy teraz na ten obraz powiedzmy docker.
Rano.
IT, ram, docker heavy latest bash.
Mam nadzieję, że to wystarczy.
Find your bash ok, bo nie mamy tutaj basha.
Jesteśmy west.
Zrobimy LS a przejdziemy do AB
i zobaczcie, że mamy tutaj całe nasze autobusy.
No i oczywiście ten odchodzący mogą ważyć różnie.
Czy są jakieś tutaj informacje o wadze, wadze tej zależności?
Generalnie całe te zależności, które
zostały zainstalowane na naszym hoście one zostały dodane do obrazu.
Czy to dobrze, czy to źle, można tutaj dywagować.
W każdym razie raczej w momencie, kiedy
mamy jakieś pliki dodawane z hosta do naszego kontenera, to
zależności nie chcemy przenosić do samego kontenera, ponieważ wersja obrazu, który
tutaj jest uruchamiany Docker 17 Alpine może się różnić i prawdopodobnie się różni
od wersji, którą ja tutaj mam zainstalowaną lokalnie.
Version.
Jak widzicie ja używam 12 12 w tym momencie na moim hoście.
W związku z czym mogą tu się zrobić różne
problemy i to co można byłoby tutaj zrobić to oczywiście po prostu nie dodawać całego
kontekstu, całej kropki całej aplikacji, tylko na przykład przenieść nasze pliki do
Forth i wtedy cały sort przenieść do aplikacji.
Ale w prawdziwych scenariuszach jest to po prostu czasem ciężkie do osiągnięcia,
bo chcemy czasami zatrzymać naszego Jacksona, jakieś konfiguracje Interu czy
inne tego typu rzeczy i z reguły się dodaje po prostu całe repozytorium.
Ale z drugiej strony nie chcemy dodawać
całej zależności i prawdopodobnie kodu źródłowego na gicie.
No bo też jakbyśmy mieli tutaj repo gotowe
to byłoby git katalog, który został by tam dodany.
Więc to co się robi
aby tego uniknąć to jest tworzenie tak samo jak mamy git docker.
Ignorant.
Jak widzicie tutaj od razu się podłapał obrazek Dockera.
To znaczy, że jest to faktycznie.
Poprawna nazwa pliku, to też można w taki
sposób się upewnić, że dobrze myślimy, że nie ma żadnej literówki.
Jak sobie dodamy tutaj nasze not yours?
No właśnie chciałem dlatego zainstalować ten Alpine żeby pokazać wam.
Wagę tego obrazu.
Czyli Docker heavy ma 170 MB,
a jeżeli pobierzemy sobie samego alpina docker pull.
Jak widzicie tutaj bardziej jest używany
do debugowania niż do faktycznego developmentu.
Przynajmniej w moim przypadku.
17 Alpine.
Tutaj oczywiście był wypróbowany w kraju i powinien być 17 Alpine.
Po 17, ale jest w sumie całkiem.
Całkiem ciężkim Alpine.
Bardzo ciekawe.
W każdym razie widzimy, że jest tutaj ta różnica w wadze.
2 MB więcej.
Przeznaczona od modelu, gdzie nasza aplikacja ma zaledwie 7 linijek kodu,
więc to co możemy zrobić to po prostu dodać to do naszego ignore.
Tak samo możemy dodać gita do naszego docker ignore i w momencie gdy np.
zrobimy docker image remote.
Do Heavy.
I zrobiłem ponownie to.
Na noc są heavy, czyli nie aż taki ciężki.
To widzimy, że tutaj oczywiście
to przeszło z kesza, więc jestem ciekawy czy.
Faktycznie ta zmiana w rozmiarze jest
zaaplikowane jest zapakowana jak 2 MB mniej wagi, czyli tak naprawdę waży
praktycznie tyle samo co surowy Alpine, więc docker ignore też.
Warto go mieć po prostu w waszych
repozytoriach tam gdzie wykonujecie Wasze polecenia, zwłaszcza z bindowania.
W ten sposób unikniecie sytuacji, gdzie bardzo ciężkie zależności będą dodawane do
Waszych obrazów, niepotrzebnie wydłużając proces budowania
i potencjalnie zwiększając koszty uruchomienia aplikacji na produkcji.
.dockerignore · 7 min
node_modules
.git