Docker w praktyce - ebook

przedmowa

We wrześniu 2013 r., podczas przeglądania Hacker News, natknąłem się na artykuł w Wired na temat nowej technologii o nazwie „Docker”¹. Czytając go, czułem się podekscytowany, gdyż ­zdałem sobie sprawę z rewolucyjnego potencjału Dockera.

Firma, w której pracowałem przez ponad dziesięć lat, starała się szybko dostarczać oprogramowanie. Tworzenie środowisk było kosztownym, czasochłonnym, manualnym i mało eleganckim zadaniem. Ciągła integracja prawie nie istniała, a konfigurowanie środowisk rozwojowych było ćwiczeniem cierpliwości. Ponieważ mój tytuł zawodowy zawierał słowa „DevOps Manager”, byłem szczególnie zmotywowany do rozwiązania tego typu problemów!

Za pośrednictwem firmowej listy e-mailingowej zatrudniłem kilku zmotywowanych współpracowników (jeden z nich jest teraz moim współautorem) i nasz niezależny zespół pracował nad przekształceniem narzędzia w wersji beta w korzyści biznesowe, zmniejszając wysokie koszty maszyn wirtualnych i tworząc nowe sposoby myślenia o budowaniu i wdrażaniu oprogramowania. Aby zaspokoić potrzeby w zakresie dostaw w naszej organizacji, zbudowaliśmy i udostępniliśmy narzędzie do automatyzacji (ShuIt).

Docker dał nam kompleksowe, zarządzalne narzędzie, które rozwiązało wiele problemów będących nie do przezwyciężenia, gdybyśmy samodzielnie chcieli podjąć się ich rozwiązania. To było najlepsze źródło pozwalające nam podjąć wyzwania przy wykorzystaniu naszego wolnego czasu, przezwyciężające zadłużenie technologiczne i dające codzienne lekcje. Lekcje nie tylko o Dockerze, ale także o ciągłej integracji, ciągłym dostarczaniu, dostarczaniu artefaktów, automatyzacji i tym, jak ludzie reagują na szybkie i destrukcyjne zmiany technologiczne.

Dla nas Docker jest narzędziem dającym szerokie możliwości. Gdziekolwiek uruchamiamy oprogramowanie z użyciem Linuksa, Docker może mieć na to wpływ. To sprawia, że pisanie książki na ten temat jest trudne, ponieważ całe to zagadnienie jest tak szerokie jak samo oprogramowanie. Zadanie to staje się jeszcze bardziej poważne ze względu na niezwykłą szybkość, z jaką ekosystem Dockera tworzy rozwiązania, aby zaspokoić potrzeby wynikające z tak fundamentalnej zmiany w wytwarzaniu oprogramowania. Z biegiem czasu kształt problemów i rozwiązań stał się nam znany, a w tej książce staraliśmy się przekazać te doświadczenia. Umożliwi wam to znalezienie rozwiązań dla waszych konkretnych ograniczeń technicznych i biznesowych.

Biorąc udział w spotkaniach, uderzyło nas to, jak szybko Docker stał się skuteczny w organizacjach, które chciały go zastosować. Ta książka odzwierciedla sposób, w jaki używaliśmy Dockera, począwszy od naszych pulpitów, przez strumień DevOps, aż po całą ścieżkę do produkcji. W związku z tym książka ta jest czasem niekonwencjonalna, ale jako inżynierowie wierzymy, że czystość musi czasem ustępować praktyczności, zwłaszcza jeśli chodzi o oszczędność pieniędzy! Wszystko tu opiera się na rzeczywistych lekcjach i mamy nadzieję, że daje możliwość skorzystania z naszych trudno zdobytych doświadczeń.

Ian Miellpodziękowania

Ta książka nie mogłaby zostać napisana bez wsparcia, poświęcenia i cierpliwości najbliższych. Szczególnie chcielibyśmy wspomnieć Stephena Hazletona, którego nieustanne starania, aby uczynić Dockera użytecznym dla naszych klientów, mocno wpłynęły na zawartość tej książki.

Kilku współpracowników i pracowników Dockera było na tyle życzliwych, aby na różnych etapach przejrzeć książkę i przekazać wiele przydatnych informacji. Należą do nich następujące osoby, które przeczytały książkę w formie manuskryptu: Benoit Benedetti, Burkhard Nestmann, Chad Davis, David Moravec, Ernesto Cardenas Cangahuala, Fernando Rodrigues, Kirk Brat-tkus, Pethuru Raj, Scott Bates, Steven Lembark, Stuart Woodward, Ticean Bennett, Valmiky Arquissandas i Wil Moore III. Jose San Leandro działał jako nasz korektor techniczny i jesteśmy wdzięczni za jego bystre oko.

Wreszcie, książka ta zawdzięcza również wiele redaktorom Manninga, którzy zrobili wszystko, aby zmotywować nas do tego, żeby była ona nie tylko wystarczająco dobra, ale po prostu najlepsza. Mamy nadzieję, że ambicja, którą kierowali się w swojej pracy, przeszła również na nas.

IAN MIELL Sarze, Izaakowi i Rachel za znoszenie: kodowania późnym wieczorem, ojca przyklejonego do ekranu laptopa i wiecznego „Docker to, Docker tamto, Docker bla, bla”, oraz moim rodzicom za zachęcanie mnie już od wczesnych lat do kwestionowania status quo. I za kupienie mi Spectruma.

AIDAN HOBSON SAYERS Monie za wsparcie i zachętę, moim rodzicom za ich mądrość i motywujące słowa, a mojemu współautorowi za ten proroczy e-mail „Czy ktoś próbował tego Dockera?”.o książce

Docker jest prawdopodobnie najszybciej rozwijającym się projektem software’owym w historii. Udostępniony w marcu 2013 r., w 2018 r. uzyskał prawie 50 000 gwiazdek w GitHubie i ponad 14 000 kopii repozytorium. W przypadku Dockera pojawiło się bardzo dużo żądań pobrań, z miejsc takich jak Red Hat, IBM, Microsoft, Google, Cisco i VMWare.

Docker osiągnął tę masę krytyczną, odpowiadając na istotne potrzeby wielu organizacji zajmujących się oprogramowaniem: możliwości budowania oprogramowania w sposób otwarty i elastyczny, a następnie niezawodnego i spójnego wdrażania w różnych kontekstach. Nie musimy uczyć się nowego języka programowania, kupować drogiego sprzętu lub wkładać wiele wysiłku w instalację oraz konfigurację, aby budować, dostarczać i uruchamiać aplikacje w Dockerze.

Docker w praktyce, wydanie drugie, przeprowadza przez rzeczywiste przykłady użycia Dockera przy użyciu technik zastosowanych w różnych kontekstach. Tam, gdzie było to możliwe, staraliśmy się wyjaśnić te techniki bez konieczności wcześniejszej znajomości innych technologii. Założyliśmy, że czytelnicy rozumieją podstawowe techniki i koncepcje programistyczne, takie jak umiejętność tworzenia zestrukturyzowanego kodu, oraz mają świadomość procesów tworzenia i wdrażania oprogramowania. Ponadto przyjęliśmy założenie związane z posiadaniem wiedzy na temat podstawowych idei dotyczących systemów kontroli źródeł oraz podstaw sieci, takich jak TCP/IP, HTTP i porty. Inne rzeczy spoza tego głównego nurtu zostaną wyjaśnione w trakcie kolejnych rozdziałów.

W części I zaczniemy od przeglądu podstaw Dockera, w części II skupimy się na wykorzystaniu Dockera w eksploatacji na pojedynczej maszynie. W części III przejdziemy do używania Dockera w strumieniu DevOps, obejmującym ciągłą integrację, ciągłe dostarczanie i testowanie. Część IV opisuje sposób uruchamiania kontenerów Dockera w sposób skalowalny wraz z orkiestracją. Ostatnia część dotyczy uruchamiania Dockera na produkcji, koncentrując się na możliwościach odnoszących się do standardowych działań produkcyjnych, a także na tym, co może pójść źle i jak sobie z tym poradzić.

Docker jest tak szerokim, elastycznym i dynamicznym narzędziem, że nadążanie za szybko zmieniającym się otoczeniem nie jest dla osób o słabym sercu. Dołożyliśmy starań, aby umożliwić zrozumienie jego najistotniejszych pojęć przez rzeczywiste aplikacje i przykłady w celu umożliwienia pewnej krytycznej oceny przyszłych narzędzi i technologii w ekosystemie Dockera. Staraliśmy się, aby książka była przyjemną podróżą po wielu drogach, które Docker uczynił w naszym życiu łatwiejszymi, a nawet zabawniejszymi. Zagłębienie się w Dockerze zetknęło nas z wieloma interesującymi technikami oprogramowania obejmującymi w stymulujący sposób cały cykl jego życia. Mamy nadzieję, że jest to doświadczenie, którym warto się podzielić.

Mapa drogowa

Książka składa się z 16 rozdziałów podzielonych na pięć części.

Część I stanowi podstawę dla reszty książki, wprowadzając Dockera oraz kilka jego podstawowych poleceń. Rozdział 2 poświęca trochę czasu na zapoznanie z architekturą klient-serwer Dockera i sposobem jej debugowania, co może być przydatne do identyfikowania problemów z niekonwencjonalnymi ustawieniami.

Część II skupia się na zapoznaniu się z Dockerem i jego maksymalnym wykorzystaniu na własnej maszynie. Analogia ze znanym pojęciem maszyn wirtualnych jest używana jako podstawa rozdziału 3, w celu wskazania łatwiejszej drogi do rozpoczęcia korzystania z Dockera. W rozdziałach 4, 5 i 6 wyszczególniono kilka technik Dockera, z których na podstawie naszego doświadczenia najczęściej korzysta się na co dzień do tworzenia i uruchamiania obrazów oraz zarządzania samym Dockerem. Ostatni rozdział w tej części omawia temat budowania obrazów w bardziej szczegółowy sposób, zwracając uwagę na techniki zarządzania konfiguracją.

Część III rozpoczyna przegląd zastosowań Dockera w kontekście DevOps, począwszy od używania go do automatyzacji kompilacji oprogramowania i testów, a skończywszy na przenoszeniu zbudowanego oprogramowania w różne miejsca. Ta część kończy się rozdziałem na temat wirtualnej sieci Dockera, wprowadzając Docker Compose oraz obejmuje kilka bardziej zaawansowanych tematów sieciowych, takich jak symulacja sieci i wtyczki sieciowe Dockera.

Część IV bada temat orkiestracji kontenerów. Zabiera w podróż, począwszy od jednego kontenera na pojedynczym hoście do platformy opartej na Dockerze działającej w „centrum danych jako systemie operacyjnym”. Rozdział 13 to obszerna dyskusja na temat obszarów, które należy wziąć pod uwagę przy wyborze platformy opartej na Dockerze. Stanowi on także przewodnik po tym, na co architekci w organizacji zwracają uwagę podczas wdrażania takich technologii.

Część V obejmuje kilka tematów dotyczących efektywnego korzystania z Dockera w środowis­ku produkcyjnym. Rozdział 14 dotyczy ważnego tematu związanego z bezpieczeństwem, wyjaśniając, jak zablokować procesy uruchomione w kontenerze i jak ograniczyć dostęp do zewnętrznego demona Dockera. Ostatnie dwa rozdziały zawierają szczegółowe informacje na temat kluczowych praktycznych aspektów dotyczących uruchamiania Dockera na produkcji. Rozdział 15 pokazuje, jak zastosować klasyczną wiedzę sysadmina w kontekście kontenerów, w zakresie od rejestrowania do limitowania zasobów, natomiast rozdział 16 analizuje niektóre z możliwych do napotkania problemów oraz wskazuje kilka możliwych kroków w celu ich debugowania i rozwiązywania.

Załączniki zawierają szczegóły dotyczące instalowania, używania i konfigurowania Dockera na różne sposoby, w tym wewnątrz maszyny wirtualnej i w systemie Windows.

O kodzie

Kod źródłowy wszystkich narzędzi, aplikacji i obrazów Dockera stworzonych do wykorzystania w tej książce jest dostępny w GitHubie w organizacji „docker-in-practice”: https://github.com/docker-in-practice/. Obrazy w Docker Hub pod użytkownikiem „dockerinpractice” https://hub.docker.com/u/dockerinpractice/ są zazwyczaj automatycznie zbudowanymi poszczególnymi repozytoriami GitHub. Tam, gdzie czuliśmy, że czytelnik może być zainteresowany dalszym studiowaniem kodu źródłowego, w dyskusji dotyczącej danej techniki dodawaliśmy link do odpowiedniego repozytorium. Kod źródłowy jest również dostępny na stronie wydawcy pod adresem www.manning.com/books/docker-in-practice-second-edition.

Znaczna liczba listingów kodu w książce umożliwia czytelnikowi śledzenie sesji terminalowych, wraz z odpowiednimi wynikami poleceń. W kontekście tych sesji należy zwrócić uwagę na kilka kwestii:

- Długie polecenia terminala mogą używać znaku kontynuacji linii powłoki, (\), aby umożliwić podzielenie polecenia na wiele linii. Chociaż, jeśli zostanie to wpisane w takiej postaci, będzie działało w powłoce, ale można te znaki także pominąć i wprowadzić polecenie w jednym wierszu.
- Jeżeli pewna część wyników nie będzie dostarczać dodatkowych przydatnych informacji do dyskusji, to będziemy ją pomijać, a w ich miejscu zostanie wstawiony symbol wielokropka ().

Forum książki

Zakup Docker w praktyce umożliwia bezpłatny dostęp do prywatnego forum internetowego prowadzonego przez Manning Publications, gdzie można zamieszczać komentarze na temat książki, zadawać pytania techniczne i otrzymywać pomoc od autorów i innych użytkowników. Aby uzys­kać dostęp do forum, należy przejść do strony https://forums.manning.com/forums/docker-in-practice-second-edition. Więcej o forach Manninga i zasadach korzystania można także dowiedzieć się na https://forums.manning.com/forums/about.

Zobowiązanie Manninga względem swoich czytelników polega na zapewnieniu miejsca, w którym może odbywać się konstruktywny dialog między poszczególnymi czytelnikami oraz między czytelnikami a autorami. Nie jest to zobowiązanie do konkretnej formy uczestnictwa ze strony autorów, których wkład na forum pozostaje dobrowolny (i niepłatny). Sugerujemy zadawanie im wielu wymagających pytań, aby dzięki temu mogli zgłębiać temat!o ilustracji na okładcewydania w języku angielskim

Postać na okładce Docker w praktyce jest opisana jako „Man from Selce, Croatia”. Ilustracja pochodzi z reprodukcji albumu chorwackich strojów ludowych z połowy XIX wieku autorstwa Nikoli Arsenovica, albumu opublikowanego przez Muzeum Etnograficzne w Splicie, w Chorwacji, w 2003 r. Ilustrację uzyskano od uczynnego bibliotekarza z Muzeum Etnograficznego w Splicie, które jest położone w rzymskim rdzeniu średniowiecznego centrum miasta: ruinach pałacu cesarza Dioklecjana z około 304 roku. Książka zawiera piękne kolorowe ilustracje przedstawiające postaci z ­różnych regionów Chorwacji, którym towarzyszą opisy kostiumów i codziennego życia.

Zasady ubierania się i styl życia zmieniły się w ciągu ostatnich 200 lat, a różnorodność między regionami, tak bogata w tamtym czasie, zanikła. Trudno jest teraz odróżnić mieszkańców różnych kontynentów, nie mówiąc już o różnych wioskach lub miasteczkach oddzielonych zaledwie kilkoma kilometrami. Być może wymieniliśmy różnorodność kulturową na bardziej zróżnicowane życie osobiste – a w szczególności na bardziej zróżnicowane i szybsze życie technologiczne.

Manning łączy pomysłowość i inicjatywę biznesu komputerowego z okładkami opartymi na bogatej różnorodności życia regionalnego sprzed dwóch wieków, przywróconych do życia dzięki ilustracjom ze starych książek i kolekcji takich jak ta.Część I. Podstawy Dockera

Część I tej książki składa się z rozdziałów 1 i 2, które umożliwiają rozpoczęcie korzystania z Dockera oraz omawiają jego podstawy.

Rozdział 1 wyjaśnia pochodzenie Dockera, a także jego podstawowe pojęcia, takie jak obrazy, kontenery i warstwy. Na koniec będzie można zakasać rękawy, tworząc swój pierwszy obraz z użyciem Dockerfile.

Rozdział 2 wprowadza kilka przydatnych technik, które pozwolą lepiej zrozumieć architekturę Dockera. Biorąc po kolei każdy główny komponent, omówimy relację między demonem Dockera a jego klientem, rejestrem Dockera oraz Docker Hub.

Pod koniec pierwszej części będziemy czuć się komfortowo z podstawowymi koncepcjami Dockera, a także będziemy w stanie zademonstrować kilka użytecznych technik, co położy solidny fundament pod resztę książki.1. Odkrywanie Dockera

Niniejszy rozdział dotyczy:

- tego, czym jest Docker,
- używania Dockera oraz tego, jak dzięki niemu można zaoszczędzić czas i pieniądze,
- różnic między kontenerami a obrazami,
- warstw Dockera,
- budowania i uruchamiania konkretnych aplikacji za pomocą Dockera.

Docker to platforma, która pozwala „budować, wysyłać i uruchamiać dowolną aplikację w dowolnym miejscu”. Przeszła długą drogę w niewiarygodnie krótkim czasie i jest obecnie uznawana za standardowy sposób rozwiązania jednego z najdroższych aspektów oprogramowania: wdrażania.

Zanim pojawił się Docker, strumień rozwoju zazwyczaj obejmował kombinacje różnych technologii do zarządzania ruchem oprogramowania, takich jak maszyny wirtualne, narzędzia do zarządzania konfiguracją, systemy zarządzania pakietami i złożone sieci zależności bibliotek. Wszystkie te narzędzia musiały być zarządzane i utrzymywane przez wyspecjalizowanych inżynierów, a ­większość z nich stosowała swoje unikalne sposoby konfiguracji.

Docker zmienił to wszystko, umożliwiając różnym inżynierom zaangażowanym w ten proces efektywne mówienie jednym językiem, co sprawia, że współpraca jest prostsza. Teraz wszystko przechodzi przez wspólny strumień do pojedynczego wyjścia, które może być użyte w dowolnym celu – nie ma już potrzeby dalszego utrzymywania oszałamiającej tablicy konfiguracyjnej narzędzi, jak pokazano na rysunku 1.1.

Rysunek 1.1. Jak Docker zmniejszył obciążenia związane z utrzymaniem narzędzi

Równocześnie nie ma potrzeby rezygnowania z istniejącego stosu oprogramowania, jeśli sprawdza się on do naszych potrzeb – możemy zapakować go w kontener Dockera w takiej postaci, w jakiej będą używać go inni. Jako bonus możemy zobaczyć, jak został zbudowany ten kontener, zatem jeśli będziemy chcieli zagłębić się w szczegóły, to istnieje taka możliwość.

Niniejsza książka jest skierowana do średnio zaawansowanych programistów z pewną wiedzą na temat Dockera. Jeśli znamy podstawy, to można przejść do kolejnych rozdziałów. Celem tej lektury jest ukazanie rzeczywistych wyzwań, jakie niesie ze sobą Docker, oraz pokazanie, jak można je pokonać. Ale najpierw szybko odświeżymy samego Dockera. Aby bardziej poznać jego podstawy, polecamy Docker in Action autorstwa Jeffa Nickoloffa (Manning, 2016).

W rozdziale 2 wejdziemy głębiej w architekturę Dockera, wykorzystując pewne techniki, które pokażą jego moc. Dowiemy się, czym jest Docker, zobaczymy, dlaczego jest on ważny, i zaczniemy z niego korzystać.

1.1. Co i dlaczego, jeśli chodzi o Dockera

Zanim zabierzemy się do działania, nieco omówimy Dockera, aby zrozumieć jego kontekst, skąd pochodzi nazwa „Docker” i dlaczego go w ogóle używamy!

1.1.1. Czym jest Docker?

Aby zrozumieć, czym jest Docker, łatwiej jest zacząć od metafory niż technicznego wyjaśnienia, a metafora Dockera jest potężna. Doker był robotnikiem, który przenosił towary do i ze statków, gdy cumowały one w portach. Wśród nich były skrzynki i przedmioty o różnych rozmiarach i kształtach, a doświadczeni dokerzy byli cenieni za swoją zdolność do ręcznego, efektywnego kosztowo dopasowywania towarów do statków (patrz rys. 1.2). Zatrudnianie ludzi do przenoszenia towarów nie było tanie, ale nie istniała alternatywa.

Rysunek 1.2. Załadunek przed wprowadzeniem i po wprowadzeniu zestandaryzowanych kontenerów

Powinno to brzmieć znajomo dla każdego, kto pracuje z oprogramowaniem. Dużo czasu i intelektualnej energii poświęca się na tworzenie metaforycznie dziwnie ukształtowanego oprogramowania dla metaforycznych statków o różnej wielkości, pełnych innych dziwacznych programów, dzięki czemu można je sprzedawać użytkownikom lub firmom w innym miejscu.

Rysunek 1.3 pokazuje, jak można zaoszczędzić czas i pieniądze dzięki koncepcji Dockera. Przed Dockerem wdrożenie oprogramowania w różnych środowiskach wymagało znacznego wysiłku. Nawet jeśli nie korzystaliśmy z ręcznych skryptów do wrzucania oprogramowania na różne maszyny (a wiele osób dokładnie tak robi), wciąż musieliśmy zmagać się z narzędziami do zarządzania konfiguracją, które zarządzały stanem coraz szybciej zmieniających się środowisk i ich zapotrzebowania na zasoby. Nawet gdy te wysiłki dotyczyły maszyn wirtualnych, wiele czasu poświęcano na zarządzanie ich wdrażaniem, oczekiwanie na ich uruchomienie i zarządzanie wykorzystanymi przez nie zasobami.

Rysunek 1.3. Dostarczanie oprogramowania przed i z Dockerem

Dzięki Dockerowi wysiłek konfiguracyjny jest oddzielony od zarządzania zasobami, wysiłek wdrożeniowy zaś jest trywialny: wpisujemy docker run, pobierany jest wtedy gotowy do uruchomienia obraz środowiska zużywający mniej zasobów i umieszczony tak, aby nie kolidował z innymi środowiskami.

Nie musimy martwić się o to, czy nasz kontener zostanie wysłany na maszynę z Red Hatem, z Ubuntu czy do obrazu CentOSa; tak długo, jak będzie znajdował się na niej Docker, będzie to działać.

1.1.2. Do czego służy Docker?

Mogą pojawić się kluczowe praktyczne pytania: dlaczego mielibyśmy używać Dockera i do czego? Krótka odpowiedź na pytanie „dlaczego” brzmi, że przy odrobinie wysiłku Docker może szybko pomóc zaoszczędzić firmie dużo pieniędzy. Niektóre ze sposobów użycia (ale nie wszystkie) zostały omówione poniżej. Wszystkie te zalety widzieliśmy osobiście w rzeczywistych zastosowaniach.

Zastępowanie maszyn wirtualnych

W wielu sytuacjach Docker może być używany do zastępowania maszyn wirtualnych. Jeśli zależy nam tylko na aplikacji, a nie na systemie operacyjnym, Docker może zastąpić maszynę wirtualną i możemy zostawić martwienie się o system operacyjny komuś innemu. Docker jest nie tylko szybszy niż maszyna wirtualna, ale także lżejszy, a dzięki warstwowemu systemowi plików można łatwiej i szybciej udostępniać zmiany innym. Jest również silnie związany z linią poleceń oraz idealnie nadaje się do tworzenia skryptów.

Prototypowanie oprogramowania

Jeśli chcemy szybko eksperymentować z oprogramowaniem bez zakłócania istniejącej konfiguracji lub przechodzić przez kłopoty związane z postawieniem maszyny wirtualnej, Docker może dać nam izolowane środowisko w ciągu milisekund. Ten piorunujący efekt jest trudny do uchwycenia dopóty, dopóki samemu się tego nie doświadczy.

Pakowanie oprogramowania

Ponieważ dla użytkownika Linuksa obraz Dockera nie ma żadnych zależności, to jest to świetny sposób na pakowanie oprogramowania. Możemy zbudować nasz obraz i mieć pewność, że będzie on działał na dowolnym współczesnym komputerze z Linuksem – pomyślmy o tym jak o Javie, ale bez potrzeby używania JVM.

Ułatwienie dla architektury mikrousługowej

Docker ułatwia dekompozycję złożonego systemu na serię możliwych do złożenia części, co pozwala traktować swoje usługi w bardziej dyskretny sposób. Dzięki temu można restrukturyzować oprogramowanie, aby jego części były łatwiejsze w zarządzaniu i aby można było je wymieniać bez wpływu na całość.

Modelowanie sieci

Dzięki temu, że można połączyć setki (a nawet tysiące) pojedynczych kontenerów na jednej maszynie, modelowanie sieci jest proste. Może to być doskonałe do testowania rzeczywistych scenariuszy bez rozbijania banku.

Produktywność całego stosu nawet w trybie offline

Ponieważ możliwe jest spakowanie wszystkich części systemu do kontenerów Dockera, możemy je orkiestrować, aby działały na laptopie, nawet w trybie offline.

Redukowanie nakładów związanych z debugowaniem

Złożone negocjacje między różnymi zespołami na temat dostarczanego oprogramowania są w branży typowe. Osobiście doświadczyliśmy niezliczonych dyskusji na temat uszkodzonych bibliotek; problematycznych zależności; nieprawidłowo, w niewłaściwej kolejności lub nawet w ogóle niezastosowanych aktualizacji; nieodtwarzalnych błędów i tak dalej. Prawdopodobnie wszyscy z tym się spotykamy. Docker pozwala na wyraźne określenie (nawet w formie skryptu) kroków w celu debugowania problemu w systemie o znanych właściwościach, co sprawia, że reprodukcja błędów i środowiska jest znacznie prostsza oraz jest oddzielona od udostępnionego środowiska hosta.

Dokumentowanie zależności oprogramowania oraz punktów styczności

Tworząc obrazy w uporządkowany sposób, gotowe do przeniesienia do różnych środowisk, Docker zmusza nas do dokumentowania zależności oprogramowania, począwszy od podstawowego punktu startowego. Nawet jeśli nie zdecydujemy się używać Dockera wszędzie, ta dokumentacja pomoże nam instalować oprogramowanie w innych miejscach.

Umożliwienie ciągłego dostarczania

Ciągłe dostarczanie (continuous delivery, CD) to paradygmat dostarczania oprogramowania, przez bazowanie na strumieniu, który przebudowuje system przy każdej zmianie, a następnie dostarcza go na produkcję (lub do środowiska „rzeczywistego”) za pomocą zautomatyzowanego (lub częściowo zautomatyzowanego) procesu.

Ponieważ można dokładniej kontrolować stan środowiska, w którym odbywa się budowanie, kompilacje w Dockerze są bardziej odtwarzalne i powtarzalne niż tradycyjne metody budowania oprogramowania. To znacznie ułatwia implementację CD. Standardowe techniki CD, takie jak wdrożenia Blue/Green (gdzie „rzeczywiste” i „poprzednie” wdrożenia są utrzymywane przy życiu) oraz wdrożenia Phoenix (gdzie po każdym wydaniu są przebudowywane całe systemy), stają się trywialne dzięki implementacji procesów budowania skoncentrowanych na Dockerze.

Teraz trochę już wiemy na temat tego, jak Docker może nam pomóc. Zanim zajmiemy się ­prawdziwym przykładem, przejdźmy przez kilka podstawowych pojęć.

1.1.3. Kluczowe pojęcia

W tej części omówimy kilka kluczowych pojęć Dockera przedstawionych na rysunku 1.4.

Rysunek 1.4. Podstawowe pojęcia Dockera

Przed rozpoczęciem uruchamiania poleceń Dockera warto dobrze rozumieć koncepcję ­obrazów, kontenerów i warstw. W skrócie, kontenery są działającymi systemami zdefiniowanymi przez obrazy. Obrazy te składają się z jednej lub więcej warstw (lub zestawów różnic) oraz pewnych metadanych Dockera.

Spójrzmy teraz na niektóre z podstawowych poleceń Dockera. Przekształcimy obrazy w kontenery, zmodyfikujemy je i dodamy warstwy do nowych obrazów, które zatwierdzimy. Nie trzeba się martwić, jeśli na razie jest to dezorientujące. Pod koniec rozdziału wszystko będzie o wiele jaśniejsze.

Kluczowe polecenia Dockera

Główną funkcją Dockera jest budowanie, dostarczanie i uruchamianie oprogramowania w dowolnym miejscu, w którym jest on dostępny. Dla użytkownika końcowego Docker to program, którego uruchamia się z linii poleceń. Podobnie jak git (lub dowolne narzędzie kontroli źródeł), ten program ma wiele podpoleceń wykonujących różne operacje. Główne podpolecenia Dockera, których będziemy używać na naszym hoście, zostały wymienione w tabeli 1.1.

Tabela 1.1. Podpolecenia Dockera

--------------- ------------------------------------------
Polecenie Cel
docker build Buduje dockerowy obraz
docker run Uruchamia dockerowy obraz jako kontener
docker commit Zatwierdza dockerowy kontener jako obraz
docker tag Dodaje tag do dockerowego obrazu
--------------- ------------------------------------------

Obrazy i kontenery

Przy braku znajomości Dockera może to być pierwszy raz, gdy w tym kontekście trafimy na słowa „kontener” i „obraz”. Prawdopodobnie są to najważniejsze pojęcia w Dockerze, warto więc poświęcić trochę czasu, aby upewnić się, że różnica jest jasna. Na rysunku 1.5 znajduje się ilustracja tych koncepcji, z trzema kontenerami uruchomionymi z jednego podstawowego obrazu.

Rysunek 1.5. Obrazy i kontenery Dockera

Jednym ze sposobów patrzenia na obrazy i kontenery jest postrzeganie ich analogicznie do programów i procesów. W ten sposób proces może być postrzegany jako „wykonywana aplikacja”, kontener Dockera może być zaś traktowany jako wykonywany dockerowy obraz.

Znając zasady programowania obiektowego, innym sposobem patrzenia na obrazy i kontenery jest traktowanie obrazów jako klas, a kontenerów jako obiektów. Podobnie jak obiekty są konkretnymi instancjami klas, kontenery są instancjami obrazów. Możemy utworzyć wiele kontenerów z jednego obrazu i wszystkie będą od siebie odizolowane w ten sam sposób, w jaki są obiekty. Cokolwiek zmienimy w obiekcie, nie wpłynie to na definicję klasy – są to zasadniczo różne rzeczy.

1.2. Budowanie dockerowej aplikacji

Przejdziemy teraz do działania, budując za pomocą Dockera prosty obraz aplikacji to-do (todoapp). W ten sposób zobaczymy kilka kluczowych właściwości Dockera, takich jak Dockerfile, ponowne użycie obrazów, wystawianie portów i automatyzacja budowania. Oto, czego dowiemy się w ciągu najbliższych 10 minut:

- Jak utworzyć dockerowy obraz przy użyciu Dockerfile.
- Jak tagować dockerowy obraz dla łatwej identyfikacji.
- Jak uruchomić nowy dockerowy obraz.

Aplikacja to-do charakteryzuje się tym, że pomaga śledzić rzeczy, które chcemy zrobić. Stworzona przez nas aplikacja będzie przechowywać i wyświetlać krótkie ciągi informacji, które mogą być oznaczone jako wykonane, i będą przedstawiane w prostym interfejsie webowym. Rysunek 1.6 pokazuje, co w ten sposób osiągniemy.

Rysunek 1.6. Budowanie dockerowej aplikacji

Szczegóły aplikacji są nieistotne. Pokażemy, że z pojedynczego krótkiego pliku Dockerfile, który udostępniamy, możemy niezawodnie budować, uruchamiać, zatrzymywać i wznawiać aplikację w ten sam sposób zarówno na naszym, jak i twoim hoście, bez potrzeby martwienia się o instalację aplikacji lub jej zależności. Jest to kluczowa część tego, co oferuje Docker – niezawodnie odtwarzane i łatwe do zarządzania oraz współdzielone środowiska programistyczne. Oznacza to, że nie trzeba wykonywać skomplikowanych lub niejednoznacznych instrukcji instalacyjnych, w których potencjalnie można się zgubić.

UWAGA Ta aplikacja to-do będzie używana kilkakrotnie w całej książce oraz jest całkiem przydatna do zabawy i demonstrowania, zatem warto się z nią zapoznać.

1.2.1. Sposoby tworzenia nowego obrazu Dockera

Istnieją cztery standardowe sposoby tworzenia dockerowych obrazów. Tabela 1.2 przedstawia te metody.

Tabela 1.2. Możliwości tworzenia dockerowych obrazów

--------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- --------------------------
Metoda Opis Omówienie
Dockerowe polecenia / „manualnie” Uruchamianie kontenera za pomocą docker run oraz tworzenie obrazu za pomocą komend wprowadzanych w wierszu poleceń. Tworzenie nowego obrazu za pomocą docker commit Patrz technika 15
Dockerfile Budowanie ze znanego obrazu podstawowego oraz specyfikowanie budowania za pomocą ograniczonego zestawu prostych poleceń Omówione w punkcie 1.2.2
Dockerfile oraz narzędzie zarządzania konfiguracją (CM) Tak samo jak Dockerfile, ale przekazujemy kontrolę nad kompilacją bardziej zaawansowanemu narzędziu CM Patrz technika 55
Obraz scratch^(*) oraz import zbioru plików Do pustego obrazu importujemy plik TAR z wymaganymi plikami Patrz technika 11
--------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- --------------------------

^(*) Zarezerwowany, minimalny dockerowy obraz używany jako punkt wyjścia do budowy kontenerów – przyp. tłum.

Pierwsza, „manualna” opcja jest odpowiednia, jeśli wykonujemy testy koncepcji, aby sprawdzić, czy nasz proces instalacji działa. Jednocześnie powinniśmy pamiętać o podjętych krokach, abyśmy, jeśli zajdzie taka potrzeba, mogli powrócić do tego samego punktu.

W pewnym momencie będziemy chcieli określić kroki do stworzenia obrazu. To jest opcja z użyciem Dockerfile (i ta, której tutaj użyjemy).

W przypadku bardziej złożonego budowania możemy wybrać trzecią opcję, zwłaszcza gdy funkcjonalności pliku Dockerfile nie są wystarczająco wyrafinowane, aby zaspokoić potrzeby naszego obrazu.

Ostatnia opcja polega na budowaniu na bazie pustego obrazu przez nałożenie zestawu plików wymaganych do uruchomienia nowego obrazu. Jest to przydatne, jeśli chcemy zaimportować zestaw niezależnych plików utworzonych gdzie indziej, chociaż ta metoda jest rzadko spotykana w powszechnym użyciu.

Przyjrzymy się teraz metodzie z użyciem Dockerfile; pozostałe metody zostaną omówione w ­dalszej części książki.

1.2.2. Tworzenie Dockerfile

Dockerfile to plik tekstowy zawierający serię poleceń. Listing 1.1 to Dockerfile, którego będziemy używać jako przykładu. Utwórzmy nowy folder, przejdźmy do niego i utwórzmy plik o nazwie „Dockerfile” z poniższą zawartością.

Listing 1.1. Dockerfile dla todoapp

FROM node

Definicja bazowego obrazu

LABEL maintainer [email protected]

Informacja o opiekunie obrazu

RUN git clone -q https://github.com/docker-in-practice/todo.git

Klonowanie kodu todoapp

WORKDIR todo

Przejście do nowego, sklonowanego katalogu

RUN npm install > /dev/null

Uruchomienie polecenia install z managera pakietów (npm)

EXPOSE 8000

Określenie, że kontenery ze zbudowanego obrazu powinny nasłuchiwać na tym porcie

CMD

Określenie, które polecenia będą wykonywane podczas uruchamiania

Dockerfile rozpoczynamy od zdefiniowania obrazu podstawowego za pomocą polecenia FROM. Ten przykład używa obrazu Node.js, zatem będziemy mieć dostęp do plików binarnych Node.js. Oficjalny obraz Node.js jest nazwany node.

Następnie deklarujemy opiekuna obrazu za pomocą polecenia LABEL. W tym przypadku używamy jednego z naszych adresów e-mailowych, ale możesz go zastąpić własnym odwołaniem, ponieważ jest to teraz twój plik Dockerfile. Ta linia nie jest wymagana do utworzenia działającego dockerowego obrazu, ale włączenie tego jest dobrą praktyką. W tym momencie budowanie odziedziczyło stan bazowego kontenera i jesteśmy gotowi do pracy nad nim.

Następnie za pomocą komendy RUN klonujemy kod todoapp. Do pobrania kodu aplikacji ­używamy konkretnego polecenia, uruchamiając git w kontenerze. W tym przypadku Git był zainstalowany wewnątrz obrazu podstawowego, ale nie możemy uznawać tego za rzecz oczywistą.

Teraz za pomocą komendy WORKDIR przechodzimy do nowego sklonowanego katalogu. W budowanym kontekście zmienia to nie tylko katalogi, bo ostatnie polecenie WORKDIR określa, w którym katalogu domyślnie się znajdziemy, gdy uruchomimy swój kontener ze zbudowanego obrazu.

Następnie uruchamiamy polecenie install z managera pakietów (npm). Spowoduje to skonfigurowanie zależności dla aplikacji. W tym przykładzie nie interesuje nas wynik, zatem przekierowujemy go do /dev/null.

Ponieważ aplikacja wykorzystuje port 8000, używamy polecenia EXPOSE, aby powiedzieć Dockerowi, że kontenery ze zbudowanego obrazu powinny nasłuchiwać na tym porcie.

Na koniec używamy polecenia CMD, aby powiedzieć Dockerowi, które polecenia mają zostać wykonane po uruchomieniu kontenera.

Ten prosty przykład ilustruje kilka kluczowych cech Dockera i Dockerfile. Plik Dockerfile to prosta sekwencja ograniczonego zestawu poleceń uruchamianych w ścisłej kolejności. Wpływa ona na pliki i metadane obrazu wynikowego. Polecenie RUN wpływa w tym przypadku na system plików, pobierając i instalując aplikację, a polecenia EXPOSE, CMD i WORKDIR wpływają na metadane obrazu.

1.2.3. Budowanie dockerowego obrazu

Zdefiniowaliśmy kroki budowania w pliku Dockerfile. Teraz spróbujemy zbudować dockerowy obraz, wpisując polecenie z rysunku 1.7. Wynik będzie wyglądał podobnie do tego:

Rysunek 1.7. Dockerowa komenda build

Sending build context to Docker daemon 2.048kB

Docker umieszcza pliki i katalogi w ścieżce podanej dla polecenia build

Step 1/7 : FROM node

Każdy krok budowania jest numerowany sekwencyjnie, począwszy od 1, oraz jest wyświetlany razem z wykonywanym poleceniem

Każde polecenie powoduje utworzenie nowego obrazu i uzyskanie jego identyfikatora

---> 2ca756a6578b

Step 2/7 : LABEL maintainer [email protected]

---> Running in bf73f87c88d6

---> 5383857304fc

Removing intermediate container bf73f87c88d6

Aby zaoszczędzić miejsce, przed kontynuacją jest usuwany każdy pośredni kontener

Step 3/7 : RUN git clone -q https://github.com/docker-in-practice/todo.git

---> Running in 761baf524cc1

---> 4350cb1c977c

Removing intermediate container 761baf524cc1

Step 4/7 : WORKDIR todo

---> a1b24710f458

Removing intermediate container 0f8cd22fbe83

Step 5/7 : RUN npm install > /dev/null

---> Running in 92a8f9ba530a

npm info it worked if it ends with ok

Tutaj jest wyświetlany podgląd budowania (został usunięty z tego listingu)

npm info ok

---> 6ee4d7bba544

Removing intermediate container 92a8f9ba530a

Step 6/7 : EXPOSE8000

---> Running in 8e33c1ded161

---> 3ea44544f13c

Removing intermediate container 8e33c1ded161

Step 7/7 : CMD npm start

---> Running in ccc076ee38fe

---> 66c76cea05bb

Removing intermediate container ccc076ee38fe

Successfully built 66c76cea05bb

Końcowy identyfikator obrazu dla tego budowania, gotowy do otagowania

Mamy teraz dockerowy obraz z identyfikatorem („66c76cea05bb” w poprzednim przykładzie, ale twój identyfikator będzie inny). Korzystanie z tego identyfikatora może być kłopotliwe, zatem w celu łatwiejszego odwoływania się do niego można go oznaczyć, co pokazano na rysunku 1.8.

Rysunek 1.8. Dockerowa podkomenda tag

Wpiszmy powyższe polecenie, zastępując 66c76cea05bb identyfikatorem obrazu wygenerowanym przez ciebie.

Możemy teraz zbudować własną kopię dockerowego obrazu na podstawie Dockerfile, odtwarzając środowisko zdefiniowane przez kogoś innego!

1.2.4. Uruchamianie dockerowego kontenera

Zbudowaliśmy i otagowaliśmy nasz dockerowy obraz. Teraz możemy uruchomić go jako kontener:

Listing 1.2. Rezultat docker run dla todoapp

$ docker run -i -t -p 8000:8000 --name example1 todoapp

Podkomenda docker run uruchamia kontener, -p mapuje port 8000 kontenera na port 8000 maszyny hosta, --name nadaje kontenerowi unikalną nazwę, a ostatnim argumentem jest nazwa obrazu

npm install

npm info it worked if it ends with ok

npm info using [email protected]

npm info using [email protected]

npm info prestart [email protected]

> [email protected] prestart /todo

Dane wyjściowe procesu uruchamiania kontenera są wysyłane na terminal

> make all

npm install

npm info it worked if it ends with ok

npm info using [email protected]

npm info using [email protected]

npm WARN package.json [email protected] No repository field.

npm WARN package.json [email protected] license should be a valid SPDX

➥ license expression

npm info preinstall [email protected]

npm info package.json [email protected] license should be a valid SPDX license

➥ expression

npm info package.json [email protected] No license field.

npm info package.json [email protected] No license field.

npm info package.json node

[email protected] license should be a valid SPDX license expression

npm info package.json [email protected] No license field.

npm info build/todo

npm info linkStuff [email protected]

npm info install [email protected]

npm info post install [email protected]

npm info prepublish [email protected]

npm info ok

if ; then mkdir dist; fi

cp node_modules/react/dist/react.min.js dist/react.min.js

LocalTodo App.js:9: // TODO: default english version

LocalTodoApp.js:84: fwdList = this.host.get('/TodoList#'+listId);

// TODO fn+id sig

TodoApp.js:117: // TODO scroll into view

TodoApp.js:176: if (i>=list.length()) { i=list.length()-1; } // TODO

➥ .length

local.html:30 :

model/TodoList.js:29: // TODO one op - repeated spec? long spec?

view/Footer.jsx:61: // TODO: show the entry's metadata

view/Footer.jsx:80: todoList.addObject(new TodoItem()); // TODO

➥ create default

view/Header.jsx:25: // TODO list some meaningful header (apart from the

➥ id)

npm info start [email protected]

> todo [email protected] start/todo

> node TodoAppServer.js

Swarm server started port 8000

^Cshutting down http-server...

Aby tutaj zakończyć proces i kontener, należy nacisnąć Ctrl-C

closing swarm host...

swarm host closed

npm info lifecycle [email protected]~poststart: [email protected]

npm info ok

$ docker ps -a

Aby zobaczyć kontenery wraz z identyfikatorem i statusem (jak dla procesu), które zostały uruchomione i usunięte, należy uruchomić tę komendę

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

b9db5ada0461 todoapp "npmstart" 2 minutes ago Exited (0) 2 minutes ago

➥ example1

$ docker start example1

Ponowne uruchomienie kontenera, tym razem w tle

example1

$ docker ps

CONTAINER ID IMAGE COMMAND CREATED STATUS

➥ PORTS NAMES

b9db5ada0461 todoapp "npm start" 8 minutes ago Up 10 seconds

➥ 0.0.0.0:8000->8000/tcp example1

Ponowne uruchomienie polecenia ps, aby zobaczyć zmieniony status

$ docker diff example1

Podkomenda docker diff pokazuje, jakie pliki zostały zmodyfikowane, od momentu gdy z obrazu został utworzony kontener

C /root

C /root/.npm

C /root/.npm/_locks

C/root/.npm/anonymous-cli-metrics.json

C /todo

Został zmieniony katalog /todo (C – changed)

A /todo/.swarm

Został dodany katalog /todo/.swarm (A – added)

A /todo/.swarm/_log

A /todo/dist

A /todo/dist/LocalTodoApp.app.js

A /todo/dist/TodoApp.app.js

A /todo/dist/react.min.js

C /todo/node_modules

Podkomenda docker run uruchamia kontener. Flaga -p mapuje port 8000 kontenera na port 8000 maszyny hosta, zatem powinniśmy być teraz w stanie za pomocą przeglądarki przejść do adresu http://localhost:8000, aby wyświetlić aplikację. Flaga --name nadaje kontenerowi ­unikalną nazwę, do której można się później wygodnie odwoływać. Ostatnim argumentem jest nazwa obrazu.

Po uruchomieniu kontenera możemy nacisnąć Ctrl-C, aby zakończyć proces i kontener. Możemy wykonać polecenie ps, aby zobaczyć kontenery, które zostały uruchomione, ale nie są usunięte. Zauważmy, że każdy kontener ma swój własny identyfikator i status, analogicznie jak proces. Jego status to Exited, natomiast możemy go ponownie uruchomić. Po wykonaniu tej czynności zwróćmy uwagę, że status zmienił się na Up i teraz wyświetlane jest mapowanie portów kontenera na maszynę hosta.

Podkomenda docker diff pokazuje, które pliki zostały zmodyfikowane, od momentu gdy z obrazu został utworzony kontener. W tym przypadku zmieniono katalog todo (C) oraz zostały dodane pozostałe wylistowane pliki (A). Żadne pliki nie zostały usunięte (D), co jest ostatnią możliwością.

Jak widzimy, fakt, że Docker „zawiera” nasze środowisko, oznacza, że możemy traktować go jako jednostkę, na której można przewidywalnie wykonywać działania. To pokazuje moc Dockera – możemy wpływać na cykl życia oprogramowania od etapu projektowania po produkcję i utrzymanie. Te zmiany będą tematem tej książki, pokazując w praktyce, co można zrobić za pomocą Dockera.

Teraz dowiemy się o warstwach, kolejnej kluczowej koncepcji Dockera.

1.2.5. Warstwy w Dockerze

Warstwy Dockera pomagają radzić sobie z problemami, które pojawiają się podczas używania kontenerów na dużą skalę. Wyobraźmy sobie, co by się stało, gdybyśmy uruchomili setki, a nawet tysiące aplikacji to-do, a każda z nich wymagałaby, aby kopie plików były gdzieś ­przechowywane.

Jak można sobie wyobrazić, miejsce na dysku skończyłoby się dość szybko! Domyślnie Docker wewnętrznie korzysta z mechanizmu kopiowania przy zapisie, aby zmniejszyć ilość wymaganego miejsca na dysku (patrz rys. 1.9). Za każdym razem, gdy działający kontener musi zapisać coś do pliku, jest rejestrowana zmiana, przez skopiowanie elementu do nowego obszaru dysku. Gdy wykonywane jest dockerowe zatwierdzenie, ten nowy obszar dysku jest zamrażany i zapisywany jako warstwa z własnym identyfikatorem.

Rysunek 1.9. Warstwy systemu plików Dockera

To częściowo wyjaśnia, w jaki sposób kontenery Dockera mogą się uruchamiać tak szybko – nie mają nic do skopiowania, ponieważ wszystkie dane zostały już zapisane jako obraz.

WSKAZÓWKA Kopiowanie przy zapisie to standardowa strategia optymalizacji wykorzystywana w komputerach. Kiedy tworzymy nowy obiekt (dowolnego typu) z szablonu, zamiast kopiować cały wymagany zestaw danych, kopiujemy dane tylko wtedy, gdy ulegają zmianie. W zależności od przypadku użycia może to zaoszczędzić znaczne zasoby.

Rysunek 1.10 pokazuje, że zbudowana aplikacja to-do ma trzy warstwy, które nas interesują. Warstwy są statyczne, zatem jeśli chcemy zmienić cokolwiek w wyższej warstwie, możemy po ­prostu to zbudować na górze obrazu, który przyjęliśmy za punkt odniesienia. Aplikację to-do zbudowaliśmy na bazie publicznie dostępnego obrazu node i warstw ze zmianami powyżej.

Rysunek 1.10. Warstwowy system plików todoapp w Dockerze

Wszystkie trzy warstwy mogą być współużytkowane przez wiele działających kontenerów, podobnie jak wspólna biblioteka może być współdzielona w pamięci przez wiele działających procesów. Jest to istotna cecha sposobu działania, pozwalająca na uruchamianie wielu kontenerów opartych na różnych obrazach na maszynach hostów, przy zmniejszeniu ryzyka wyczerpania miejsca na dysku.

Wyobraźmy sobie, że uruchamiamy aplikację to-do jako rzeczywistą dla opłacających usługę klientów. Możemy skalować naszą ofertę dla dużej liczby użytkowników. Jeśli jesteśmy w trakcie tworzenia, możemy jednocześnie uruchomić wiele różnych środowisk na komputerze lokalnym. Jeśli przeprowadzamy testy, możemy uruchomić ich jednocześnie o wiele więcej i znacznie ­szybciej niż do tej pory. Wszystkie te czynności są możliwe dzięki warstwowaniu.

Budując i uruchamiając aplikację za pomocą Dockera, zaczęliśmy dostrzegać siłę, jaką może on wnieść do naszego przepływu pracy. Reprodukcja i udostępnianie specyficznych środowisk oraz możliwość umieszczania ich w różnych miejscach daje zarówno elastyczność, jak i kontrolę nad rozwojem.

Podsumowanie

- Docker to próba zrobienia dla oprogramowania tego, co konteneryzacja zrobiła dla branży żeglugowej: zredukowanie kosztów lokalnych różnic przez standaryzację.
- Niektóre z zastosowań Dockera obejmują prototypowanie oprogramowania, pakowanie oprogramowania, redukowanie kosztów środowisk testowania i debugowania oraz umożliwienie praktyk DevOps, takich jak ciągłe dostarczanie.
- Aplikację Dockera na podstawie Dockerfile możemy zbudować i uruchomić za pomocą poleceń docker build oraz docker run.
- Dockerowy obraz jest szablonem do uruchamiania kontenerów. Jest to podobne do różnicy między wykonywalnym programem a uruchomionym procesem.
- Zmiany w uruchomionych kontenerach można zatwierdzać i tagować jako nowe obrazy.
- Obrazy są tworzone z warstwowego systemu plików, co zmniejsza przestrzeń używaną przez dockerowe obrazy na naszym hoście.