Komendy Docker-a, które należy znać będąc programistą

Kolejny wpis o komendach, które należy znać tym razem dla Docker-a. (wcześniej było dla po GIT-a https://blogprogramisty.net/komendy-git-a-ktore-nalezy-znac/) Dlaczego warto? No cóż jako, że każdy programista powinien chcieć być dobrym programistą warto znać narzędzia, które towarzyszą programowaniu i umieć jakoś minimalnie się w nich poruszać aby, gdy przyjedzie okazja nie błądzić po omacku po Internecie. To nie jest kurs, to nie tutorial to spis i opis komend, które pozwolą zbudować, uruchomić i wrzucać do repozytorium obraz. Zapraszam serdecznie.

Wstęp

To nie żaden tutorial, jeśli nie masz wiedzy ogólnej o tym czy jest konteryzacja to nie jest to jeszcze dobry wpis dla Ciebie. Jeśli jednak wiesz i chcesz się dowiedzieć sprawnie jak możesz zbudować, uruchomić, jak wejść w kontener i koniecznie jak go wysłać do repozytorium (obraz) to jesteś we właściwym miejscu. Kolejność jest ważna i pozwala zbudować i wysłać obraz do zdalnego repo.

Na początku

Wszystko zaczyna się od tego, że na swojej maszynie musimy mieć dockera. Dla windows używam Docker Desktop for Windows (https://docs.docker.com/desktop/windows/install/). Używam raczej kontenerów z hostem linuxa więc i Windows Subsystem for Linux (WSL 2) też trzeba mieć zainstalowany.

Docker – komendy

Wszystko zaczyna się tam, gdzie jest plik dockerimage. Visual Studio, gdy użyje się opcji użyj Dockera sam tworzy taki plik i konfiguruje wszystko pod to aby odpalić i debugować obraz w kontenerze.

Wszystkie komendy należy odpalać tam gdzie jest dockerimage.

docker build -t dowolnaNazwa:tag .

Budujemy obraz. Jesteśmy w katalogu z plikiem docker image. Najpierw budujemy obraz (build). Dodajemy tag (-t) do nazwy (dowolnaNazwa) naszego obrazu. Oraz „kropka nienawiści” czyli kontekst (.). Ten kontekst to jak by miejsce skąd Docker będzie kopiował pliki do obrazu (bardzo ważne).

Przykład: docker build -t myApp:latest .

dokcer image ls

Ta komenda wyświetli nam wszystkie zbudowane obrazy wraz z ich nazwami i id. Docelowo komenda powyżej powinna zbudować obraz i komenda images ls pokaże go na liście obrazów.

docker run -d -p portHosta:portKontenera nazwa:tag

Możemy też odpalić sobie nasz obraz (który zbudowaliśmy w poprzednim krok) (nazwa:tag). Aby to zrobić podajemy opcje -d (obraz odpali się w tle i wyświetli ID kontenera), potem -p czyli mapowanie portów. Najpierw port hosta (czy ten port, przez który będziemy się komunikować z kontenerem) i potem port w obrazie czyli ten port, który oficjalnie wystawiamy (czyli port, pod którym będzie działać nasza aplikacja).

Przykład: docker run -d -p 1080:80 myApp:latest (do aplikacji będzie się łączyć na porcie 1080)

docker container ps

To komenda wyświetli nam odpalone kontenery, które chodzą w tle.

Rejestry (jak wystawić obraz do rejestru).

W tej sekcji opiszę jak to zrobić, aby wystawić swój obraz do rejestru czyli takiego zdalnego repozytorium (git push tak jak by). Jesteśmy teraz w miejscu, gdzie skończyliśmy poprzednie kroki. Odpaliliśmy kontener. Komenda docker container ps pokazuje nam chodzący kontener i zaczynamy.

docker image tag nazwa:latest url_do_zdalnego_repo:tag

Ta komenda nadaje kolejny tag do obrazu o tagu nazwa:latest w formie url_do_zdalnego_repo:tag. W Docker jeden obraz może być otagowany kilka razy. Czyli jeden tag może wskazywać na kilka obrazów. Te url_do_zdalnego_repo to nic innego jak adres do zdalnego repo, dzięki temu Docker będzie wiedział gdzie i co ma wysłać.

Przykład: docker image tag myApp:latest myService.service30.net/apps/app:v2

docker login url_do_zdalnego_repo

Ta komenda pozwala na zalogowaniu się i zapamiętaniu danych autoryzacyjnych do zdalnego repo (url_do_zdalnego_repo). O tyle jest to ważne, że bez tego nie będzie można wysłać nic na zdalne repozytorium.

Przykład: docker login localhost:8080

docker image push url_do_zdalnego_repo:tag

I w końcu wysłanie obrazu do zdalnego repozytorium.

Przykład: docker image push app:latest myService.service30.net/apps/app:v2

Koniec?

Na razie tak. Czy programista musi coś więcej wiedzieć. Nie wiem czy musi ale może. Zawsze jest granica, gdzie to zaczyna ocierać się o dev ops. W większości firm nawet te kroki nie są potrzebne, jednak gdy pracujemy lokalnie czasem warto umieć sobie poradzić szybko i przyjemnie z podstawowymi komendami. A Wy jak używacie Dockera w swoich : ) firmach?