Docker pozwala nam na naprawdę sporą swobodę pracy, więc w tej części już będzie samo mięso, czyli uruchomimy swój pierwszy kontener. Na cel obrałem sobie już gotową aplikację, gdzie wykorzystamy kilka podstawowych mechanizmów.
Jeśli jeszcze nie zainstalowałeś Dockera, albo nie wiesz, do czego on służy, to zapraszam do zapoznania się z poprzednimi częściami poradnika tutaj.
Docker CLI — scyzoryk do obsługi kontenerów
Docker jest narzędziem, które potencjał swój wykorzysta tylko w postaci linii komend. Niezależnie od istniejących „wrapperów”, które dają klikalny interfejs, nigdy nie będą tak dobrze jak dobrze zrobione CLI.
Podstawowe komendy opisałem już w artykule dostępnym na blogu, więc nie będę się powtarzać i zapraszam do poznania podstawowych narzędzi.
Uruchomimy kontener!
Jak dobrze wiemy, w repozytorium obrazów posiadamy już gotowe obrazy. Na początek przestrzegę, by weryfikować je przed wykorzystaniem, gdyż nigdy nie wiesz, co autor chciał zrobić, np.: czy przypadkiem nie kopie kryptowalut, albo nie chce wykorzystać Cię do udziału w botnecie.
Ja wybrałem na potrzeby poradnika obraz Wiki.js — jest to aplikacja typu wiki, gdzie będziemy mogli zbierać swoją wiedzę i myślę, że jest to dobra aplikacja na start, gdyż jest banalnie prosta, a także może się Wam przydać do zapisywania swojej nowo zdobytej wiedzy.
Jak uruchomić kontener Dockera?
Celem uruchomienia kontenera, wykorzystamy komendę: docker run
docker run requarks/wiki
Zgodnie z tym co zobaczyć można na poniższym nagraniu (można kopiować tekst również), skrypt wymagał poprawek do działania. Na nagraniu widać parametr --rm, który wykorzystałem tylko po to, by kontener po wyłączeniu został usunięty.
Na początku widzimy próbę uruchomienia aplikacji. Jako że nie udało się znaleźć lokalnie obrazu, został on pierw pobrany (można to też zrobić osobno przy pomocy docker pull). Po pobraniu nastąpiła próba uruchomienia obrazu, która zakończyła się błędem. Powodem tego stanu rzeczy jest fakt, że aplikacja wymaga od nas podania zmiennych — jest to sytuacja zależna od aplikacji. Zmienne środowiskowe podajemy przy pomocy parametru -e, co widać również na nagraniu.
Zdefiniowano tam dwa parametry. Pierwszy to DB_TYPE, który definiował wykorzystaną przez nas bazę SQLite3. Dodatkowo drugi parametr DB_PATH, czyli ścieżka do pliku bazy. Po podaniu aplikacja się uruchomiła, ale nie była możliwa do przeglądania. Powodem tego stanu rzeczy jest fakt, że kontener nie może z reguły ingerować w system hosta (czyli nasz komputer), więc musimy mu pozwolić na to, by był dostępny „z zewnątrz”. W tym celu definiujemy port parametrem -p, dodatkowo go mapując. Aplikacja standardowo korzysta z portu 3000, więc gdybyśmy chcieli np.: uruchomić 10 takich aplikacji, gdzie każdy korzystałaby z tego samego portu — nie byłoby to możliwe. Dlatego przemapowaliśmy port 3000 na 8080, dzięki czemu w przeglądarce pod adresem https://localhost:8080/ pojawiła się nasza Wiki.js, która działa w kontenerze na porcie 3000.
Jak uruchomić kontener Dockera „w tle”?
No dobra, ale aplikacja jest wciąż „widoczna”, więc jak zamkniemy konsolę, to ona będzie działać. Trzeba to poprawić.
Na nagraniu widać, że dodaliśmy parametr -d, czyli --detach, który uruchamia nam kontener w tle. Dzięki temu nie musimy mieć włączone konsoli cały czas. Po wykonaniu docker ps widzimy, że jakieś kontenery działają, niestety nazwa naszego nowego kontenera to hopeful_swartz – poprawimy to poprzez wykorzystanie parametru --name i nazwiemy nasz kontener tak, jak tego chcemy. Przy dużej ilości kontenerów warto nazywać je, by wiedzieć, który odpowiada za co. Na koniec zamykamy kontener.
Docker -zabezpieczenie przed awarią aplikacji — jak ją automatycznie restartować?
No dobrze, a co się stanie, jak nasza aplikacja z jakiegoś powodu będzie miała błąd i „się wysypie”? No to kontener zostanie wyłączony, albo usunięty (jeśli wykorzystano parametry --rm). W tym celu trzeba się zabezpieczyć!
Podmieniłem --rm na --restart. W sytuacji, gdy aplikacja przestanie działać z różnych powodów, kontener nie zostanie wyłączony, a zostanie na nowo uruchomiony. Posiadamy kilka wartości, np.: always (zawsze) lub unless-stopped (do momentu, aż sami wyłączymy). Jest jeszcze wartośc on-failure oraz on-failure:XYZ, gdzie, zamiast XYZ możemy podać cyfrę — dzięki temu kontener będzie restartował się, ale tylko wyznaczoną liczbę razy (np.: przydatne przy skryptach, by w ramach niepowodzenia w końcu się poddawały). Standardowo jest też parametr no – czyli nie restartuj.
Co nasz kontener robi? Czyli docker exec!
Na koniec spójrzmy jeszcze co w ogóle działa w kontenerze! W tym celu wejdziemy do niego!
Poprzez docker exec możemy wykonywać najróżniejsze komendy. Na początek chciałem uruchomić bash, jednak nie chciał się uruchomić. To dlatego, że nie włączyliśmy wsparcia sesji interaktywnej (czyli moglibyśmy klikać 🙂 ). W tym celu użyliśmy -i oraz -t jako parametry. Pierwszy oznacza, że możemy „reagować” z kontenerem, a drugi włączał wsparcie pseudo-terminala (TTY) w celu uzyskiwania standardowych wejść i wyjść. Jednak nie każda aplikacja tego wymaga, w tym celu uruchomiłem również ps. Co ciekawe, jak spojrzymy, kontener jest bardzo oszczędny, gdyż posiada uruchomione TYLKO aplikacje, co korzysta. Nie posiada systemu init (jak np.: LXC), ani dodatkowej warstwy sprzętowej (jak np.: wirtualizacja). Tanio, czysto i w środowisku izolowanym.
Podsumowanie
Jak widać, zwykłe uruchomienie programu może być możliwe na dziesiątki sposobów, z różnym zachowaniem, dostępnością. To był dopiero wstęp do całkowitych podstaw jak uruchomić najprostszą aplikację, bez szczególnych wymogów. Następie podepniemy aplikację do bazy danych, co już będzie nie lada zabawą, by zrobić to dobrze i bezpiecznie!
