Pierwsze zabawy z Kubernetes – część 1 Docker

    No Comments

    Konteneryzacja aplikacji wykorzystująca Dockera i ich orkiestracja  za pomocą Kubernetes  przebojem zdobywają coraz większą grupę zwolenników. Postanowiłem zmierzyć się z tymi produktami.

    Założyłem, ze wykorzystam jakieś darmowe środowisko, które pozwoli mi na pierwsze zabawy, bez zbędnej instalacji oprogramowania na stacji roboczej.  Powtarzalne operacje zostaną zapisane w plikach na Githubie.

    Niniejszy wpis wykorzystuje https://labs.play-with-k8s.com/ .

    Uruchomienie środowiska wymaga zalogowania się na konto GitHub lub na konto DockerHuba. Wybrałem tę drugą opcję.

    Po podaniu naszych poświadczeń i po naciśnięciu zielonego przycisku Start mamy do dyspozycji uruchomione gotowe środowisko do testów, które zostaje powołane na czas czterech godzin.

    Na początku musimy dodać pierwszą instancję. Po krótkiej chwili mamy już gotowe środowisko z dostępem do shella.

    Pierwsze polecenie uname -a

    Mamy dostęp do schowka
    Shift + insert = kopiuj
    Ctrl + insert = wklej

    Co więcej możemy doinstalować sobie potrzebne pakiety, np. edytor nano, midnight commander i inne cuda…

    Spróbujmy uruchomić prostą aplikację w kontenerze z gotowego publicznego repozytorium Docker Hub.

    Na początku uruchomimy pusta aplikacje www opartą o popularny serwer apache2.

    Polecenie to uruchamia obraz o nazwie httpd w wersji 2.4 z wystawiony portem tcp 80 od strony kontenera, port hosta zostanie zmapowany automatycznie. Za chwile zobaczymy na jaką wartość. Obrazu tego nie było do tej pory lokalnie, stąd komunikat “unable to find image”.  Przed budową zostanie on ściągnięty z repozytorium Docker Huba.

    Otrzymany wynik:

    Sprawdźmy listę naszych obrazów

    Otrzymany wynik:

    Sprawdzamy, które obrazy są uruchomione.

    Otrzymany wynik:

    Port 80 tcp kontenera zostaje zmapowany na port 32768 hosta.

    Pojawia się niebieskie łącze o nazwie wystawionego portu. Po kliknięciu mamy stronę z napisem

    It works!

     

    Wykorzystując gotowe obrazy, które  można traktować jako bazę, mamy możliwość tworzenia na ich podstawie bardziej skomplikowanych funkcjonalnie aplikacji. W tym celu możemy wykorzystać plik konfiguracyjny, tak zwany Dockerfile.

    Przykładowy Dockerfile:

    Uzupełniamy zawartość pustego pliku Dockerfile i budujemy nasz kontener.

    Uruchamiamy nasz kontener

    Jak widać kontener nasłuchuje na porcie 32770 hosta

    Można tę informację pobrać w bardziej elegancji sposób:

    Na górze powinien pojawić się niebieski link z takim numerem portu.
    Po uruchomieniu
    http://ip172-18-0-22-bf4df2mn5ugg00cc6t5g-32770.direct.labs.play-with-k8s.com/

    Mamy widoczną naszą aplikację.

    Warto zapamiętać budowę linku:

    http://ip<hyphen-ip>-<session_jd>-<port>.direct.labs.play-with-k8s.com

    A naszym przypadku był to

    http://ip172-18-0-22-bf4df2mn5ugg00cc6t5g-32770.direct.labs.play-with-k8s.com/

    Warto pamiętać o kilku zasadach, które pomagają budować obrazy kontenerowe w sposób efektywny

    1. Wybieramy obraz, z najbardziej optymalną  funkcjonalnością, czyli np. taki który zawiera tylko potrzebne oprogramowanie i nic więcej.
    2. Instalujemy tylko potrzebne oprogramowanie.
    3. Niepotrzebne pliki tymczasowe, które powstają podczas instalacji oprogramowania powinny zostać usunięte.
    4. Każde polecenie RUN tworzy nowa warstwę w obrazie, eliminujmy ich liczbę. Stad często widoczne jest sklejanie poleceń przez &&.
    5. Każdy projekt powinien mieć własny plik .dockerignore, w którym zawarte są reguły wykluczające pliki i katalogi w procesie budowania.

    Wykonajmy prosty eksperyment.

    Przygotowałem dwie wersje pliku DockerFile,

    jeden to obraz ubuntu:16.04,

    https://github.com/djkormo/ContainersSamples/blob/master/Docker/chess-ai/ubuntu/Dockerfile

    drugi to alpine:3.7.

    https://github.com/djkormo/ContainersSamples/tree/master/Docker/chess-ai/alpine/Dockerfile

    Otrzymany wynik:

    Wchodzimy do podkatalogów

    W podkatalogu mamy trzy wersje plików Dockeffile

    W każdym z podkatalogów budujemy lokalna wersje obrazu, tu dla przykładu dla obrazu pochodzącego z dystrybucji alpine.

    Dla obrazu Ubuntu

    Po zbudowaniu tych dwóch obrazów , możemy porównać ich rozmiar

    Otrzymujemy następujące wartości:

    To co widać od razu, z obrazu bazowego alpine:3.7 o wielkości 4.2MB powstał obraz local/chess-ai-alpine o wielkości 28.3MB. Natomiast z bazowego obrazu ubuntu:16.04 o wielkości 116MB powstał obraz localhost/chess-ai-ubuntu o wielkości 275MB. Funkcjonalność obu aplikacji, czyli prosta gra w szachy napisania w Javascript, jest taka sama, a różnica w wielkości jest dziesięciokrotna.

    Literatura:

    https://medium.com/@marcosnils/introducing-pwk-play-with-k8s-159fcfeb787b

    https://github.com/play-with-docker/play-with-docker/issues/259

    http://phusion.github.io/baseimage-docker/

    http://collabnix.com/kubernetes-hands-on-lab-1-setting-up-5-node-k8s-cluster/

    Categories: konteneryzacja, migawka