Docker part one

Zaczynamy zabawę z Docker.

W poprzednim moim wpisie poruszyliśmy temat chmury i wirtualizacji. Zaprezentowałem wam jak zainstalować proste środowisko w którym, można tworzyć wirtualne instancje. Maszyny utworzone w takim środowisku jak najbardziej mogą być pełno prawnymi komputerami / systemami operacyjnymi. Wpis blogowy znajdziecie tu: DevStack, OpenStack i OpenStack z Kolla na kontenerach.

Jednak łatwo nam sobie wyobrazić, że nie dysponujemy wirtualizacją a jednak chcielibyśmy mieć wydzielony system / środowisko które, mogłoby istnieć niezależnie od obecnego. Niezależność rozumiem po przez odrębne biblioteki, czy też środowisko systemowe. Idealnym rozwiązaniem może okazać się Docker, czyli konteneryzacja która, daje nam pewną swobodę i wolność w dyspozycji zasobami nawet przy braku wirtualizacji. Zdecydowaną przewagą Docker’a nad wirtualizacją jest możliwość uruchomienia aplikacji w wydzielonym kontenerze, ale bez konieczności emulowania całej warstwy sprzętowej i systemu operacyjnego.

W takich kontenerach uruchamiane są procesy aplikacji a dzięki temu zabiegowi otrzymujemy większą efektywność wykorzystania zasobów sprzętowych. Każdy kontener posiada wydzielony obszar pamięci, odrębny interfejs sieciowy z własnym prywatnym adresem IP oraz wydzielony obszar dyskowy na którym znajduje się zainstalowany obraz systemu operacyjnego wraz z zależnościami. Czyli taki kontener (z Ubuntu na przykład) posiada jedynie zainstalowane niezbędne biblioteki które, pozwalają uruchomić taki system. Wraz z głównym procesem aplikacji który, jest uruchomiony w takim systemie. Żeby uruchamiać kontenery z Linuksem na pokładzie nasz system też musi bazować na Linuksie. W windows musimy posiłkować się dodatkową wirtualizacją by mieć środowisko do uruchamiania kontenerów. Istnieje możliwość w kontenerze uruchamianie systemu Windows. Jednak nie to jest tematem mojego wpisu. Wróćmy do naszych procesów uruchamianych w kontenerze. Naszym procesem może być wszystko od serwera MySQL, po Demona Grafany czy nawet sam dostęp do terminala bash. Jednak zobaczmy jak to wygląda w praktyce, zacznijmy więc od ...

Instalacji naszego kontenerowca.

Instalacja Docker w naszym systemie (W Windows też :) choć skupiać się będę wyłącznie na Linuxach) sprowadza się do instalacji z repo po dodaniu informacji o lokalizacji repozytoriów, z paczki deb, lub ze skryptu który, cały proces nam automatyzuje i sprowadza do wykonania dwóch poleceń w terminalu.

Ja uwielbiam korzystać z trzeciej metody ponieważ jest najłatwiejsza i umożliwia szybką zabawę z Docker.

$ curl -fsSL get.docker.com -o get-docker.sh
$ sudo sh get-docker.sh

Wywołanie powyższych dwóch komend zainstaluje nam w parę sekund środowisko Docker. Oczywiście to nie żadna magia i sposoby instalacji znajdziecie na oficjalnej stronie projektu. Oczywiście nic nie stoi na przeszkodzie by spróbować inny sposób instalacji.

Pierwsze uruchomienie

Dodajmy naszego użytkownika do grupy docker by uniknąć potrzeby podnoszenia swoich uprawnień by wydać polecenia związane z kontenerami. Pamiętamy o prze logowaniu aktywnej sesji bash by uprawnienia zaczęły działać.

sudo usermod -aG docker <your-user>

Teraz pobierzmy nasz obraz systemu i stwórzmy nasz pierwszy kontener. Tylko skąd je pobrać?

Docker Hub to tu znajdują się wszystkie obrazy z których, budowane są nasze kontenery. Jest to publiczny rejestr gdzie przechowywane są oficjalne obrazy wspierane przez opiekunów projektu. Znajdziesz tu oficjalne obrazy na przykład gotowego serwera MySQL, czy serwera www, lub kombinacje tych usług. Przechowywane są tutaj też obrazy udostępnione publiczne przez społeczność którą, możesz tworzyć nawet ty. Wystarczy stworzyć tu konto. W ramach darmowego konta będziesz mógł stworzyć jedno prywatne repo zabezpieczone hasłem i dostępne tylko dla Ciebie i osób którym, ty zdecydujesz je udostępnić. Publiczne repo docker hub możesz tworzyć nie zliczoną ilość. Należy tylko pamiętać, że do publicznego rejestru mają dostęp wszyscy. Prywatne repo można w ramach darmowej subskrypcji utworzyć jedno w ramach konta. Oczywiście by zacząć zabawę z docker i pobrać obraz nie musisz mieć tu konta - jednak warto je założyć.

Zakładanie konta jest proste. Pozwól, że proces rejestracji pominę i przeje już do konta i ustawień własnych rejestrów. Rejestr ten będzie dostępny publicznie i przechowywany zdalnie na docker hub. Tworzenie własnych lokalnych rejestrów omówimy niece później.

Po prawidłowym zalogowaniu otrzymamy dostęp do naszego konta. Nowe repozytorium docker hub zakładamy po przez Create Repository... ale po kolei, wróćmy do naszej konsoli.

Nasz pierwszy kontener uruchomimy po przez komendę docker run hello-world:

docker run hello-world

Powinniśmy zobaczyć taki komunikat:

Gdybyśmy jednak otrzymali taki komunikat:

To prawdopodobnie zapomniałeś o prze logowaniu aktywnej sesji bash w terminalu. W ramach aktywnej sesji jeszcze nie jesteś w grupie docker. W takim razie przełącz się raz jeszcze na swojego użytkownika, lub wyloguj i zaloguj się ponownie.

su - <nazwa_uzytkownika>

Wróćmy jednak do naszego hello-world. I po kolei omówmy co się stało linijka po linijce :)

Polecenie docker run jak już pewnie się domyślasz uruchamia nasz kontener. Pewnie zadasz pytanie jaki kontener. No i tu odpowiedź jest prosta kontener hello-world.

kolejna linia:

Unable to find image 'hello-world:latest' locally

Informuje nas że demon, usługa, polecenie docker nie mógł odnaleźć lokalnie szukanego image (obrazu) na podstawie którego, zbuduje nasz kontener hello-world. Domyślnie docker szuka czy już nie ma przypadkiem zapisanego tego obrazu lokalnie.

komunikat:

latest: Pulling from library/hello-world

Informuje nas o tym, że brakujący obraz zostanie pobrany. Kolejna linia to już informacje o id obrazu, sumie kontrolnej oraz statusie:

9bb5a5d4561a: Pull complete
Digest: sha256:f5233545e43561214ca4891fd1157e1c3c563316ed8e237750d59bde73361e77
Status: Downloaded newer image for hello-world:latest

Wszystko poniżej to już jest to co robi ten kontener - w tym przypadku jego zadanie jest proste. Po utworzeniu kontenera wyświetl wiadomość:

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/engine/userguide/

I co to wszystko? - mógłbyś zadać takie pytanie. I moja odpowiedź będzie, TAK TO WSZYSTKO :).

Zadaniem tego kontenera jest własnie wyświetlenie takiej wiadomości, a po jej wyświetleniu kończy swoje zadanie / proces i kontener przestaje działać.

Jeżeli chcemy zobaczyć działające kontenery możemy użyć komendy docker ps

docker ps

Jeżeli wydasz w swoim środowisku tą komendę to zobaczysz najprawdopodobniej taki wynik:

Który informuje Cię o tym że żaden kontener nie działa. Pewnie jesteś trochę zdziwiony tym, że uruchomienie kontenera po przez polecenie docker run nie powoduje ciągłej pracy kontenera. Ciągła praca kontenera zależna jest od procesu jaki działa w kontenerze. W przypadku naszego kontenera hello-word proces odpowiedzialny za wyświetlenie wiadomości po jej wyświetleniu zakończył swoje zadanie. Jak zakończył zadanie przestał istnieć. A że w kontenerze hello-world nie było żadnego innego procesu to sam kontener nie był już dłużej potrzeby i został zamknięty. Docker nie usuwa automatycznie kontenerów po tym jak zakończą swoje działanie (a w zasadzie proces w tym kontenerze).

Możemy zobaczyć jakie kontenery mamy rozszerzając nasze polecenie o opcję -a:

docker ps -a

Wtedy tak naprawdę zobaczymy, że nasz kontener stworzony przed chwilą jest. Tylko że jego status jest Exited (0) About ...

Ponowne wydanie komendy docker run hello-world tez zbytnio nie pomoże. W prawdzie otrzymamy znów wiadomość powitalna z kontenera:

Jednak to nie będzie wiadomość z naszego już stworzonego kontenera. To będzie wiadomość z drugiego kontenera.

To jest własnie to co daje taką przewagę kontenerom nad wirtualizacją.

Teraz stwórzmy kontener który, da nam troszeczkę więcej interakcji niż tylko wiadomość w oknie konsoli.

Pójdźmy za radą komunikatu:

docker run -ti ubuntu bash

Tym razem uruchomiliśmy kontener z podstawową wersją ubuntu. Przyjrzyjmy się temu co otrzymaliśmy w konsoli:

Pierwsza linia to nasze polecenie docker run -ti ubuntu bash. Nowością w tej linii jest opcja -ti oraz ostatnie słowo bash. Ubuntu w tym poleceniu to nazwa naszego obrazu. Tak jak to miało miejsce w przypadku hello-world. Zatem opcja -ti to opcja polecenia docker run i znaczy po prostu "Terminal Interactive" - interakcja z terminalem. Słowo bash po nazwie naszego obrazu to nazwa procesu jaki ma zostać uruchomiony w naszym kontenerze. W tym przypadku będzie to proces bash.

Tak samo jak poprzednio docker nie mógł lokalnie odnaleźć naszego obrazu więc pobrał go z docker hub. W tym przypadku mamy więcej komunikatów pull complete, a wiąże się to z warstwami które, składają się na wybudowanie naszego kontenera. O warstwach w obrazie opowiem nieco później.

Ostatnia linia to interakcja z naszym kontenerem. Jesteśmy w kontenerze, jego id w tym przypadku (moim przypadku) to 5b1c4871348b i możemy posługiwać się nim wykonując operacja na kontenerze lub po nazwie. Nazwę naszego kontenera możemy podejrzeć korzystając już z naszego dobrze znanego polecenia docker ps.

Z kontenera możemy wyjść na klika sposobów. Po przez zakończenie procesu czyli komendę exit lub kombinację klawiszy Ctrl+p, Ctrl+q. Wyjście po przez exit spowoduję, że proces bash w kontenerze zostanie zakończony a tym samym nasz kontener zostanie zatrzymany. Wyjdźmy zatem z naszego kontenera za pomocą polecenia exit.

Jak możemy zaobserwować na obrazku powyżej oraz w waszych środowiskach, po wpisaniu polecenia exit zostajemy przeniesieni z powłoki interaktywnej kontenera do powłoki naszego macierzystego systemu. Jak widzimy gdy wydamy polecenie docker ps nie zobaczymy żadnego aktywnego kontenera. Polecenie docker ps -a zdradza wiecej informacji i widzimy, że na liście kontenerów pojawił się trzeci element nasz kontener z ubuntu.

Oprócz informacji o aktywnych lub nie aktywnych kontenerach to polecenie zdradza nam jeszcze pare istotnych informacji o naszych kontenerach. Wspomniany już CONTAINER ID, możemy sobie zobaczyć że jest identyczny z numerem który widniał w powłoce interaktywnej. Dalej patrząc w prawo may IMAGE - to informacja o użytym obrazie do zbudowania kontenera (będzie tu jeszcze trochę informacji ale o tym później).

COMMAND to nasze komendy użyte jako główny proces kontenera - w przypadku ubuntu jest to proces i polecenia bash. CREATED informacja o tym kiedy został on stworzony, nasz kontener. STATUS - Tu widzimy że zgadza się z tym jak zakończyliśmy pracę z naszym kontenerem (Exited = exit). Sam kod (0) oznacza, że proces w kontenerze zakończył się prawidłowo. Tak samo jak w bash (status 0 z ostatniego polecania to OK a inny niż zero coś poszło nie tak). Materiały o bash mojego autorstwa znajdziecie w serii bash(ujący) w zbożu cz.1, cz.2, cz.3

Kolumna ports to informacja o otwartych, dostępnych portach w naszym kontenerze. O portach wspomnę nieco później. Ostatnia kolumna NAMES to nazwy naszego kontenera, gdy jej nie nadamy sami to jest generowana dynamicznie.

OK, Postawmy na nogi nasz kontener z Ubuntu. Pamiętamy, że ustawiliśmy interakcje z procesem bash. Kontener do życia przywracamy poleceniem:

docker start <ID_kontenera_lub_NAZWA>

Pojawienie się nazwy naszego kontenera po wydaniu polecenia jest informacją że wszystko przebiegło poprawnie. Sprawdzić możemy po przez polecenie docker ps.

Możemy zobaczyć, że mamy teraz działający kontener w tle, informuje nas o tym STATUS Up...

By wejść w interakcje z naszym kontenerem zastosuję polecenie które, podpina się do głównego procesu:

docker attach <ID_kontenera_lub_NAZWA>

I jesteśmy z powrotem w naszym kontenerze. Teraz wydajmy kombinacje wspomnianych wyżej klawiszy, pamiętasz je jeszcze :).

Widzicie już tą różnice? Zastosowanie kombinacji Ctrl + p i Ctrl + q pozwoliło nam opuścić kontener bez zamykania / zabijania głównego procesu. Dzięki czemu kontener nasz wciąż jest uruchomiony. Możemy się znów do niego połączyć po przez docker attach lub docker exec.

docker exec -ti <ID_kontenera_lub_NAZWA> bash

I znów jesteśmy w naszym kontenerze :) (mam nadzieję, że równomiernie ze mną tworzysz własne kontenery i się po nich poruszasz). Teraz ja wydam jedno polecenie które, pokaże Ci dopiero jak wyjdziemy z naszego kontenera :). Ok wyjdźmy z naszego kontenera poleceniem exit.

Wydajmy polecenie docker ps i zróbmy przez chwilę zakłady. Czy nasz kontener będzie dalej działał i miał status UP. Na zgłoszenia czekam do koca tygodnia, a dla szczęśliwca który, poprawnie wytypuję naszą odpowiedź w drodze losowania czeka nagroda. Nagroda ta to opiekacz do lodów... :)

Oczywiście nasz kontener będzie działał dalej

I nie jest to wykonane i umieszczone wcześniej zdjęcie.

Na zrzucie powyżej możemy zauważyć, że przed wyjściem wywołałem polencie ps -aux które, pokazało wszystkie działające procesy w kontenerze. Pewnie pamiętasz, że PID o wartości 1 to główny proces w systemie Linux od którego, wszystko się zaczyna. I tak samo jest tutaj. Proces o PID 1 to proces główny wywołany jako proces macierzysty kontenera przy jego tworzeniu. My wydając polecenie docker exec ... w prawdzie połączyliśmy się do naszego kontenera, ale tworząc nowy proces bash o PID 9. I wydając polecenie exit, zamknęliśmy tak naprawdę proces PID 9. Proces PID 1 działał dalej o czym świadczy polecenie docker ps.

Jednak gdy zakończymy proces główny PID 1 to nie ma znaczenia, że inny proces działa. Cały kontener przejdzie w status Exited.

Widać to na obrazku powyżej oraz możecie sami to sprawdzić podłączając się w drugim terminalu do tego samego kontenera.

Co było pierwsze obraz czy kontener?

Wyczyśćmy sobie trochę nasze środowisko. Użyjmy do tego poleceń:

docker rm $(docker ps -qa)
docker rmi $(docker images -q)
docker ps -a
docker images

Dzięki zagnieżdżeniu poleceń usuniemy wszystkie kontenery (oczywiście muszą one być zatrzymane, jeżeli masz jakieś działające kontenery to polecenie docker stop będzie rozwiązaniem). Tak samo robimy przy usuwaniu obrazów służy do tego polecenie docker rmi. Na koniec wystarczy sprawdzić czy nie mamy kontenerów aktywnych jak i nie aktywnych oraz sprawdzić czy nie mamy obrazów. Ok Pusto a zatem zabierzmy się za obrazy.

Obrazy możemy pobrać też bez konieczności uruchamiania kontenera. Służy do tego polecenie docker pull. Jednak najpierw wyszukajmy coś nim cokolwiek pobierzemy.

docker search <NAZWA_SZUKANEGO_OBRAZU>

Można do tego wykorzystać wyszukiwanie w cli po przez polecenie docker search lub na platformie docker hub. Jedno i drugie wyszukanie korzysta z tego samego źródła. W CLI jak i na stronie mamy taką informację jak STARS. Mówi nam ona o popularności danego repo. Dodatkowo mamy informacje czy jest to obraz z oficjalnego źródła. Zbiór tych informacji daje nam gwarancje, że dany obraz nie zawiera złośliwego kodu czy procesu. W tyle głowy musimy mieć świadomość, że to publiczne repo i każdy może tam wrzucić wszystko.

Idąc dalej, wyszukajmy jakąś dystrybucję, na przykład CentOS. Pobierzmy też tą dystrybucję.

docker pull centos

Możemy teraz sprawdzić nasz obraz:

docker images
docker image ls

Polecenie docker images pokazuje nam nasze obrazy. Z charakterystycznym podziałem jak w przypadku kontenerów, tylko tu mamy inne kolumny: REPOSITORY, TAG, IMAGE ID, CREATED, SIZE.

Kolumna REPOSITORY to nazwa repo z którego pobierzemy obraz. Repo z którego pobieramy obraz CentOS nazywa się o ironio centos. W przypadku naszych obrazów też nazwa naszego repo pokaże się w tej kolumnie. Kolumna TAG to inny obraz z repo. Zobaczmy jak to wygląda w przypadku centos na docker hub.

Możemy zauważyć, że do centos7 przypisanych jest kilka tagów latest, centos7 i 7. Zobaczmy zatem jak to będzie wyglądało w cli.

Pobierzmy zatem obraz centos:7

docker pull centos:7
docker image ls

Możemy zobaczyć, że w naszym lokalnym zbiorze obrazów są teraz dwa obrazy które, wskazują na ten sam IMAGE ID. Zatem te tagi wskazują na ten sam obraz, a przynajmniej nie mam miedzy nimi żadnej różnicy oprócz tagu. Możemy zatem zauważyć też że gdy nie podamy tagu tak jak to zrobiliśmy na początku. Nasz obraz domyślnie przyjmie wartość tagu latest. Tak samo będzie gdy pobierzemy obraz ubuntu.

docker pull ubuntu

Idąc jednak dalej kolumna CREATED informuje nas o tym kiedy został stworzony i udostępniony obraz na stronie docker hub. Im data krótsza tym lepiej dla nas. Wiemy wtedy, że biblioteki w takim obrazie są jak najbardziej aktualne. Oczywiście przed pobraniem obrazu i wdrożeniem go jako pełnoprawny kontener należy pamiętać, że im starszy obraz tym może zawierać więcej dziur i krytycznych luk. Zajrzyjmy na stronę docker hub i zakładkę tag.

Po kliknięciu w dany tag możemy zobaczyć jakie zagrożenia na nas czekają w danym obrazie. Wystarczy po przejściu w link najechać na kolorowy kwadracik.

Ostatnia kolumną jest kolumna SIZE jej przeznaczenie jest nad wyraz oczywiste i informuje nas o rozmiarze naszego image. Oczywiście wiąże się to też z rozmiarem naszego kontenera którego, utworzymy na podstawie takiego obrazu.

Nasze kontenery też możemy tworzyć podając id naszego obrazu. Wtedy będziemy mieli pewność, że kontener powstanie na podstawie lokalnego obrazu.

user@piotrskoska1:~$ docker pull hello-world
user@piotrskoska1:~$ docker image ls
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
ubuntu              latest              113a43faa138        3 weeks ago         81.2MB
centos              7                   49f7960eb7e4        3 weeks ago         200MB
centos              latest              49f7960eb7e4        3 weeks ago         200MB
hello-world         latest              e38bc07ac18e        2 months ago        1.85kB
user@piotrskoska1:~$ docker run --rm e38bc07ac18e

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/engine/userguide/

user@piotrskoska1:~$ docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
user@piotrskoska1:~$

Uruchomienie naszego kontenera z opcja -‑rm powoduje, że po zakończeniu procesu nasz kontener przestanie istnieć - dosłownie. Takie uruchomienie kontenera hello-world jest bardziej sensowne. Po co trzymać kontener który, tylko wyświetla nam wiadomość.

Coś bardziej praktycznego.

Powoli pewnie zaczynamy widzieć siłę oraz zalety tworzenia kontenerów w porównaniu do tworzenia maszyn wirtualnych. Zatem zróbmy cos bardziej praktycznego by zrozumieć jeszcze bardziej zalety kontenerów. Załóżmy, że chcemy uruchomić stronę z WordPress-em.

Możemy skorzystać z płatnej opcji i kupić gdzieś hosting - :( . Zainstalować lokalnie interpreter PHP, serwer www i bazę MySQL potem doinstalować WordPress, wszystko ładnie skonfigurować :| . Trochę zaśmieci to nam system i pytanie czy za każdym razem potrzebujemy by wraz ze startem systemu uruchamiał się demon naszego serwera.

Ok skomplikujmy trochę sytuację. Załóżmy, że Potrzebujemy przetestować rożne wersje Aplikacji WordPress na rożnych ustawieniach PHP. Hmmm... na jednym komputerze będzie to trudne. Zabawa z wirtualnymi systemami może i jest rozwiązaniem ale dość kłopotliwym. Instalacja systemu, konfiguracja, potem klonowanie i instalacja innej wersji PHP itp.

Własnie dlatego w tym przypadku powinniśmy użyć dockera i całe środowisko uruchomić w kontenerach. Ok zobaczmy jak to będzie wyglądało w naszym przypadku.

Wiemy, że do pracy z WordPressem będzie potrzebna nam baza danych. Wykorzystam do tego celu bazę danych MySQL. Skonfigurujmy nasz kontener z bazą danych.

docker run --name mysql-db -e MYSQL_ROOT_PASSWORD=mysql -d mysql:5.7.22

Trochę nowości w poleceniu docker run. Ale po kolei. Parametr -‑name daje nam możliwość nadania nazwy naszemu kontenerowi. Pamiętasz śmieszne nazwy nadawane dla poprzednich kontenerów. Ten parametr daje nam kontrole nad nimi a zatem nasz kontener będzie miał nazwę mysql-db. Kolejny parametr to parametr -e który, pozwala ustawić zmienne środowiskowe w kontenerze. Naszą zmienną MYSQL_ROOT_PASSWORD możemy zdefiniować hasło do naszej bazy danych dla użytkownika root. Dzięki parametrowi -d uruchomimy nasz kontener w tle. Będzie on działał bez wchodzenie z nim w interakcje.

Kolejnym kontenerem który, wybudujemy na naszej platformie to kontener z nasza aplikacją WordPress.

docker run --name wordpress --link mysql-db:mysql -p 8080:80 -d wordpress

Nowością w tym poleceniu to parametr -‑link oraz -p. Pierwszy pozwala na podlinkowanie innego kontenera i jego zmiennych, nazwa po dwukropku to swoisty alias. Parametr -p pozwala na wyeksponowany port wewnątrz kontenera udostępnić na zewnątrz. W tym przypadku port wewnątrz kontenera jest udostępniany na zewnątrz pod postacią portu 8080.

Jeżeli jeszcze tego nie zrobiłeś uruchom oba kontenery i spójrzmy co zwróci komenda docker ps.

user@piotrskoska1:~$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                  NAMES
edb3432afb3a        wordpress           "docker-entrypoint.s…"   9 minutes ago       Up 9 minutes        0.0.0.0:8080->80/tcp   wordpress
96d2d93ad06f        mysql:5.7.22        "docker-entrypoint.s…"   13 minutes ago      Up 13 minutes       3306/tcp               mysql-db

Możemy zobaczyć, że w kolumnie PORTS dla naszego kontenera o nazwie wordpress wartość ta nieco rożni się od tej udostępnionej w kontenerze poniżej o nazwie mysql-db. Widzimy, że kontener wordpress udostępnia port 80 tcp który, jest mapowany z portem 8080 w lokalnym komputerze oraz dostępny jest z każdego hosta w dowolnej sieci. Stąd zapis 0.0.0.0. Natomiast port w kontenerze mysql-db jest udostępniony lecz nie ma mapowania w naszym systemie.

Nasze środowisko jest już gotowe. Jeżeli masz bezpośredni dostęp do swojego hosta na którym, uruchomiłeś kontenery. To po wpisaniu adresu IP:8080 powinieneś mieć dostęp do naszej aplikacji. Ja wykorzystam tunelowanie w MobaXterm.

Po przekierowaniu i zalogowaniu się po http://localhost:8080 ukarze się:

Wstępna konfiguracja naszego środowiska wordpress. Wystarczy wybrać język podać hasło i gotowe.

I w pare sekund mamy uruchomione nasze środowisko. Nie problemem będzie teraz stworzyć kilka takich kontenerów by przetestować rożne wersje aplikacji. Prawda, że wygodny i szybki sposób?

W kolejnym odcinku...

W tym wpisie to koniec zabawy z kontenerami. W kolejnym zajmiemy się kolejnymi aspektami związanymi z docker :) Zapraszam ponownie wkrótce.

Do tego czasu o docker po polsku możecie dowiedzieć się więcej ze strony strefy kursów i kursu mojego autorstwa Docker - środowiska developerskie lub ze strony projektu Docker