Docker: Architektura dockera

0:00Cześć!

0:00Z tej lekcji opowiem o architekturze Dockera, czyli o tym jak Docker zarządza

0:04wewnętrznie kontenerami i innymi mechanizmami, które ma w zanadrzu.

0:10No i cały proces tego

0:13co się dzieje w momencie wysyłania polecenia przez nas w naszym terminalu.

0:18Do tego aż tworzone jest kontener.

0:21Oczywiście nie będziemy tego omawiali w bardzo szczegółowym aspekcie,

0:25ponieważ nie jesteśmy tutaj developerami Dockera, tylko po prostu chcemy zrozumieć

0:29jak on działa, ale myślę, że to będzie po prostu przydatna część do omówienia.

0:33Czyli jeśli założymy sobie.

0:37Że z pewnego miejsca dowolnego może to być mój komputer.

0:42To znaczy mój osobisty laptop.

0:44Może to być serwer gdzieś w internecie.

0:46Mamy dostęp do sieci.

0:49Czyli do tego naszego.

0:50Tych poleceń, które są wywoływane z poziomu terminala i z tego serwera.

0:55A my tworzymy np.

0:56polecenie docker run it engines.

1:02Bash to jest to polecenie, które wywołaliśmy w poprzedniej lekcji.

1:06I w momencie kiedy to polecenie jest

1:08wywoływane to docker spróbuje tutaj wysłać to polecenie do innego.

1:18Mechanizmu i tym mechanizmem czy sekcją aplikacji jest host.

1:23Czyli w naszym przykładzie gdzie my pracujemy na lokalnej instalacji Dockera.

1:29Nasze ALA jest zawarte w hoście, ale

1:31możemy wywołać też polecenia na zewnętrzny hosta.

1:34Czyli Docker może być zainstalowany gdzieś w internecie.

1:37Nie możemy za pomocą

1:39interfejsu linii poleceń wywoływać te polecenia dla zewnętrznych maszyn.

1:44To Docker będzie miał dostęp do swoich

1:46lokalnych obrazów lokalnych kontenerów, ale będzie nimi zarządzał poprzez tzw.

1:51docker demona.

1:52Czyli jeśli tutaj sobie zainstalujemy powiedzmy docker daemon, to jest to taki

1:57program, który faktycznie zarządza tłumaczeniem tych poleceń na wewnętrzne

2:01API Dockera, ponieważ Docker jest tak naprawdę API.

2:05Te polecenia, które wywołał wywołujemy.

2:07On tworzy po prostu odpowiednie IDE, które jest w stanie zinterpretować i

2:12zrozumieć co my jako użytkownicy Dockera chcieliśmy osiągnąć.

2:16Czyli on spróbuje poszukać obrazu Engines albo w swoim wewnętrznym rejestrze.

2:22Czyli jeżeli tutaj nie mieliśmy zainstalowanego Linuxa powiedzmy, że nie

2:26mieliśmy, to od razu poleci nam do jakiegoś zewnętrznego rejestru.

2:33I tym rejestrem jest np. Docker hub.

2:35Jest to bardzo analogiczna sytuacja do

2:37tego jak pracujecie z gettem, że w momencie kiedy robicie np.

2:40git clone to wasz lokalny system

2:44operacyjny wasz git robi zapytanie do jakiegoś rejestru w

2:48internecie, aby pobrać informacje o to o co prosiliście.

2:52Czyli jeżeli chcielibyście pobrać kod źródłowy np.

2:54Web Paka to dostaniecie zwrotkę z kodem

2:58źródłowym poprzez polecenie git pull web repozytorium kolwiek jest tam link.

3:05Czyli tutaj odwołujemy się do jakiegoś rejestru.

3:08Oczywiście możemy mieć własne registry, ale w naszym przykładzie w naszym

3:11przypadku będzie to po prostu docker, bo też po prostu będziemy z niego

3:15korzystali w dalszych częściach tego kursu.

3:19I jeżeli nie znalazł sobie docker

3:21linuxa tutaj u nas lokalnie to on go poszuka na docker hubie.

3:26Domyślnie jest to do crab.

3:27Może to być też inne repozytorium.

3:29Tutaj założymy, że ten indeks jest.

3:31Więc jeżeli on wykrył tego engine CSA to registry odpowie naszemu hosta

3:37z informacjami na temat tego obrazu i zainstaluje go lokalnie.

3:42Czyli w tym momencie gdy uruchamiamy Docker it and next.

3:46W poprzedniej lekcji była taka informacja, że cena time and next latest to ok.

3:51I właśnie to się wydarzyło, czyli w momencie gdy nasz host otrzymał

3:55informację, że powinien uruchomić obraz next on się na naszym systemie operacyjnym

3:59nie znajdował, to wtedy docker daemon zlecił pobranie obrazu

4:04z zewnętrznego rejestru i wtedy tam się te takie paski postępu z informacją o

4:11plik images layers, czyli zaciąganie obrazów czy zaciąganie warstw.

4:18Tutaj tak naprawdę ta sekcja była widoczna

4:22w momencie kiedy te paski postępu były widoczne.

4:25No i tutaj jeżeli sobie wpiszemy

4:27next, bo już zostało to pobrane, wtedy docker daemon będzie mógł przejść do

4:32następnej części interpretacji naszego zapytania.

4:35Jak już znalazł obraz end next no to jest w stanie uruchomić ten obraz, czyli

4:41stworzyć kontener na podstawie tego obrazu.

4:44I to właśnie dzieje się na tym etapie.

4:47Tutaj tworzony jest pojedynczy obraz albo kontener.

4:52Możemy napisać.

4:53Czyli jeśli byśmy to podpisali, to tutaj są nasze kontenery.

4:58Tutaj mamy nasze obrazy.

5:02Docker demon, czyli taki interpreter naszych zapytań, a to może być

5:07nasz terminal, z którego uruchamiamy polecenia.

5:11No i oczywiście jeżeli byśmy stworzyli jakieś inne polecenie np.

5:14docker ram entity wtedy.

5:17Czyli obraz, który instaluje nam Apache.

5:21To sytuacja byłaby analogiczna.

5:24Tutaj byłoby docker.

5:26IT activity bash docker.

5:29Spróbowałby znaleźć ten obraz lokalnie.

5:32Jeśliby go nie znalazł, spróbowałby go pobrać z danego rejestru.

5:36Jeżeli by go znaleźć, to by go pobrał do naszego systemu operacyjnego i dopiero z

5:39niego stworzył pojedynczy kontener, na który możemy wejść i na którym możemy

5:43zobaczyć, że mamy inne komendy i pliki do dyspozycji.

5:48Oczywiście jeżeli by go nie znalazł.

5:50To.

5:52W takiej sytuacji po prostu powie nam o błędzie, że nie mógł znaleźć

5:56tego obrazu i po prostu zakończy swoją pracę z błędem.

6:02Jak go rozwiążemy, to już zależy od nas.

6:04Możemy zbudować taki obraz lokalnie.

6:06Jeżeli mamy chwilę,

6:08czyli właśnie ten plik źródłowy, z którego obrazy są budowane, albo możemy dodać inny

6:12rejestr, z którego chcemy pobrać dany obraz.

6:15Więc właśnie w ten sposób wygląda cała nasza architektura Dockera.

6:21I tak naprawdę to będzie chyba jedna z ostatnich takich ściśle teoretycznych

6:24lekcji i przejdziemy po prostu do pracy z kontenerami, z obrazami i z tworzeniem

6:30naszych pierwszych aplikacji internetowych, które będą uruchamiane na.