Co to jest i jaką pełni rolę? Dlaczego czasami jest wykorzystywany, a czasami nie – oraz w jakich przypadkach warto wiedzieć, o co w tym wszystkim chodzi?

TLDR;

Chcąc ująć to w jednym zdaniu: „Jest to Unix Socket, na którym domyślnie nasłuchuje Docker Daemon.”

Wystarczy zerknąć na powyższy diagram i w zasadzie wszystko powinno być już jasne ; -)

Dzięki podmontowaniu pliku /var/run/docker.sock (znajdującego się na hoście), kontener może komunikować się z Docker Deamonem – czyli jednym z komponentów wchodzących w skład architektury Dockera. Docker Daemon odpowiada za przyjmowanie „rozkazów” i przekazanie ich w dół, do warstwy OCI (container runtime).

Porównując to do architektury klient-serwer, kontener może stać się klientem, a Docker Deamon – serwerem.

Docker API

Jeżeli kiedykolwiek wpisałeś w terminalu docker container run (bądź też docker run) to na 99% „pod spodem” wykorzystałeś Docker Daemon Socket.

Jest to domyślny typ komunikacji pomiędzy Docker CLI a Docker Daemonem. Domyślny nie oznacza, że nie można go zmienić, ale tym za chwilę.

Gdy korzystamy z Docker CLI, np. docker image ls – automatycznie (w tle) dorzucany jest parametr -H unix:///var/run/docker.sock.

Parametr -H to informacja dla Docker CLI, z jakim Docker Daemonem ma się skomunikować. Inaczej mówiąc, gdzie polecenie ma zostać wykonane.

Warto podkreślić, że do parametru -H można przekazać również inną wartość. Na przykład adres hosta i port TCP lub inny unix socket.

WAŻNE: Jeżeli chcemy by Docker CLI komunikował się z Docker Daemonem po protokole TCP – zamiast Unix Sockets, należy pamiętać by najpierw „włączyć” ten typ komunikacji w ustawieniach Docker Daemon’a.

Jeżeli to, co do tej pory przeczytałeś odnośnie komunikacji na lini Docker CLI => Docker Daemon – nie jest dla Ciebie do końca zrozumiałe, to koniecznie zerknij TUTAJ, gdzie jakiś czasu temu opisywałem, w jaki sposób komunikować się ze zdalnym Docker Hostem z wykorzystaniem Docker Contexts.

Portainer – pierwszy przykład zastosowania

Wykorzystanie pliku /var/run/docker.sock możemy spotkać na przykład przy uruchamianiu Portainera – narzędzia do zarządzania Dockerem z poziomu przeglądarki.

$ docker container run -d \
  -p 9000:9000 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  portainer/portainer

Portainer to aplikacja webowa, która umożliwia zarządzanie poszczególnymi obiektami w Dockerze (obrazy, kontenery, volumeny itd.)

Zamiast wpisywania docker container stop <moj_kontener> czy też innych poleceń – możesz to „wyklikać”. Ale nie o tym dzisiaj.

Dzięki podmontowaniu pliku /var/run/docker.sock – Portainer uruchomiony w kontenerze może komunikować się z Docker Daemonem. Inaczej mówiąc, kontener Portainera otrzymuje dostęp do głównego Dockera, na którym został uruchomiony.

Szukasz wiedzy z zakresu konteneryzacji?

Sprawdź koniecznie mój autorski program DOCKER MAESTRO

* minimum 13 godzin materiału (nowe materiału w produkcji)
* dożywotni dostęp do materiałów & aktualizacji
* certyfikat Docker Maestro
* gwarancja satysfakcji 
(masz 14 dni na zwrot kasy, licząc od dnia zakupu, jeśli COKOLWIEK Ci się nie spodoba)

Portainer & Docker API – jak to działa?

Najczęściej stosowanym typem komunikacji po HTTP jest protokoł TCP.

W przypadku Portainera – żądania HTTP do Docker Daemona nie są jednak wysyłane po TCP, ale właśnie przez Unix Socket.

Jeżeli wyklikamy w Portainerze utworzenie kontenera na podstawie obrazu wordpress, to pod spodem zostanie wykonane zbliżone polecenie:

curl -XPOST --unix-socket /var/run/docker.sock -d '{"Image":"wordpress"}' \
-H 'Content-Type: application/json' http://localhost/containers/create

{"Id":"fcb65c6147efb862d5ea3a2ef20e793c52f0fafa3eb04e4292cb4784c5777d65","Warnings":null}

Istnieje możliwość skonfigurowania Docker Daemona tak, by oprócz Unix Socket, dodatkowo nasłuchiwał po protokole TCP.

Z perspektywy bezpieczeństwa jest to jednak niezalecane.

Trzeba wiedzieć co się robi, i jak to działa. W przeciwnym wypadku – może to zostać wykorzystane przeciwko nam (przez osoby trzecie). Przykład takiego „włamania” do Docker Daemona można znaleźć TUTAJ.

Narzędzia do CI/CD w kontenerze (Gitlab, Jenkins)

Od dłuższego czasu, narzędzia takie jak GitLab czy Jenkins możemy uruchomić z poziomu Dockera. Obydwa narzędzia mogą być z powodzeniem wykorzystane do skonfigurowania procesów automatycznego budowania i publikowania obrazów w Docker Registry.

Swego czasu w takich zastosowaniach modne było podejście Docker-in-Docker. To podejście miało jednak sporo wad i szybko zostały uznane jako „anti-pattern”.

Aby mieć możliwość dostępu do „głównego” Dockera, bądź też – aby móc budować obrazy w skonteneryzowanym Gitlabie czy Jenkinsie – wystarczy podmontować Docker Socket.

Przykład – Gitlab Runner

Jak wspominałem wcześniej, istnieje możliwość uruchomienia lokalnej instancji GitLaba z poziomu Dockera. Gdy już to zrobimy, chcemy mieć możliwość automatycznego budowania obrazów.

Aby zbudować docker image, kontener gitlab-runner potrzebuje działającej instancji Dockera. (pamiętajmy, że kontener Gitlab Runnera to tak naprawdę tylko linuxowy proces!)

version: '3.5'

services:

  gitlab:
    image: gitlab/gitlab-ce:latest
    container_name: gitlab
    restart: always
    ...
    ...
 
  gitlab-runner:
    image: gitlab/gitlab-runner:alpine
    container_name: gitlab-runner
    restart: always
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /srv/gitlab-runner/config:/etc/gitlab-runner
    depends_on:
      - gitlab

Obecnie rekomendowanym podejściem jest podmontowanie /var/run/docker.sock:/var/run/docker.sock – dzięki czemu budowanie obrazów odbywa się na „głównym” Dockerze (pomimo tego, że cały GitLab jest uruchomionyjako kontener).

Benefitem tego rozwiązania jest przede wszystkim pełne wykorzystanie cache podczas budowania obrazów — gdyż cały proces wykonywany jest ZAWSZE na tej samej (i jedynej) instancji Dockera.

Podsumowanie

Mam nadzieję, że ten post pozwolił Ci na zrozumienie, w jakim celu wykorzystywany jest Docker Socket.

Podmontowanie pliku /var/run/docker.sock może pozwalać na zarządzanie Dockerem z poziomu kontenera. Daje nam to ogrom możliwości i może mieć zastosowanie w narzędziach integrujących się z Dockerem, czy procesach CI/CD.

PS. Jeżeli ten wpis był dla Ciebie wartościowy – będę BARDZO wdzięczny jeśli udostępnisz go/podzielisz się nim ze znajomym.

Artykuł Docker Socket – czyli /var/run/docker.sock pochodzi z serwisu Szkoła Dockera.

Testy jednostkowe – po co to komu?

Tak samo jak tworzymy testy jednostkowe podczas programowania aplikacji, podobnie też, możemy tworzyć testy jednostkowe dla obrazów Dockera.

W przypadku pisania testów jednostkowych dla aplikacji, ich ideą jest sprawdzenie, czy pojedyncza funkcja większego systemu działa tak, jak sobie założyliśmy. Może to być zachowanie pojedynczej metody, czy też klasy. W momencie gdy dana funkcjonalność jest rozbudowana, testy pilnują tego czy całość działa poprawnie.

To tyle tytułem wstępu. Przechodzimy do konkretów.

Testy jednostkowe obrazów

W przypadku obrazów dockerowych, skupiamy się na testowaniu pojedynczych plików lub funkcjonalności znajdujących się w obrazie.

Dla przykładu możemy testować:

• istnienie i zawartość plików
• wartości zmiennych środowiskowych
• poprawność działania narzędzi
• dystrybucję systemu operacyjnego

Najpierw testy – później kontener

W przypadku „standardowych” testów jednostkowych (dla aplikacji), zasadą TDD (Test Driven Development) w bardzo ogólnym skrócie brzmi: „Najpierw testy – później kod”.

W naszym przypadku (Docker), możemy przełożyć to na następujące stwierdzenie: „Najpierw testy – później kontener”. Rozwijając ten skrót – najpierw tworzymy testy dla obrazu by upewnić się, że działa tak jak to sobie założyliśmy, a dopiero poźniej tworzymy kontener na podstawie tego obrazu.

Wydaje się proste? Zachęcam do oglądania oraz zasubskrybowania kanału!

Kiedy warto tworzyć testy jednostkowe dla obrazów?

Szczególnie poleciłbym tworzenie testów jednostkowych podczas pracy w zespole. Ze swojego doświadczenia wiem, że w większym zespole takie testy często weryfikują przypadkowe błędy. Przede wszystkim mam tutaj na myśli wszelkiego rodzaju literówki oraz błędy spowodowane nieznajomością wiedzy na temat tworzenia plików Dockerfile…

Innym powodem dla którego warto to robić, jest auto-dokumentacja naszych założeń. Przeglądając takie testy, możemy szybko przypomnieć sobie jakie były początkowe zamiary co do obrazu naszej aplikacji.

Przykładowo:

• plik A powinien znajdować się w obrazie w katalogu X
• plik A powinien mieć prawa dostępu 775
• plik A powinien zawierać frazę o nazwie „ConnectionString”
• framework niezbędny do działania naszej aplikacji powinien być w wersji X
• w obrazie powinno znajdować się narzędzie curl

PS. Narzędzie, które wykorzystuję do tworzenia testów to Container Structure Test. Jest to kolejne narzędzie ze stajni Google’a.

Artykuł Jak tworzyć testy jednostkowe dla obrazów dockerowych? pochodzi z serwisu Szkoła Dockera.

Często posługujemy się dodatkowymi narzędziami takimi jak statyczne analizatory kodu czy lintery, aby nasz kod był jak najlepszy.

Dobrą praktyka jest również, umieszczenia takiej weryfikacji jako krok w pipelinie CI/CD. Szczególnie w przypadku języków interpretowanych takich jak Python czy Javascript.

Linting Dockerfile

Tak samo jak pliki języków programowania, statyczne pliki, o określonej składni, również mogą być „lintowane”.

Dlaczego więc nie weryfikować Dockerfile?

Na szczęście nie jestem pierwszym, który wpadł na ten pomysł. Ostatnio wpadłem na kilka ciekawych linterów, którymi chciałbym się z Tobą podzielić.

Pierwsza ciekawa opcja to aplikacja webowa

https://www.fromlatest.io/

Zero instalowania, zero konfigurowania.

Otwierasz -> wklejasz twój Dockerfile i widzisz potencjalne zagrożenia/optymalizacje.

Tutaj przykład

Porównując jednak to narzędzie z innymi dostępnymi na rynku, stwierdzam że nie jest idealne. Dodatkowo, ciężko o możliwość integracji z procesem CI/CD.

Natomiast, jego zaletą jest dostępność oraz natychmiastowo zwracany rezultat.

Jak zacząć korzystać z Docker Lintera na codzień?

Po pierwsze potrzebujemy jakiegoś narzędzia. Obecnie najpopularniejszym i oferującym możliwość integracji z CI/CD jest Hadolint.

Najszybszym sposobem na przetestowanie go lokalnie będzie użycie… Dockera

$ docker run --rm -i hadolint/hadolint < Dockerfile

Jeżeli Hadolint nie wykryje żadnych błędów w Twoim Dockerfile, nie zobaczymy żadnych błędów i zostanie zwrócony exit code 0.

Przykład

Mamy następujący Dockerfile

FROM centos:latest

RUN yum -y update && yum -y install \
httpd \
gcc

ADD httpd.conf /etc/httpd/conf/httpd.conf

EXPOSE 80

ENV HOME /root

WORKDIR /root

ENTRYPOINT ["ping"]

CMD ["google.com"]

Pomimo, że build przechodzi bezproblemowo:

Sending build context to Docker daemon  3.072kB                          
Step 1/8 : FROM centos:latest                                            
 ---> 0f3e07c0138f                                                       
Step 2/8 : RUN yum -y update && yum -y install httpd                     
 ---> Using cache                                                        
 ---> eeb8e1b687e1                                                       
Step 3/8 : ADD httpd.conf /etc/httpd/conf/httpd.conf                     
 ---> aa871e319cb2                                                       
Step 4/8 : EXPOSE 80                                                     
 ---> Running in df4c0ed6e26d                                            
Removing intermediate container df4c0ed6e26d                             
 ---> 97c001aba66b                                                       
Step 5/8 : ENV HOME /root                                                
 ---> Running in 84cf5b1b3187                                            
Removing intermediate container 84cf5b1b3187                             
 ---> 09382102ca4f                                                       
Step 6/8 : WORKDIR /root                                                 
 ---> Running in f26cf3622ae7                                            
Removing intermediate container f26cf3622ae7                             
 ---> a85e7876b391                                                       
Step 7/8 : ENTRYPOINT ["ping"]                                           
 ---> Running in 2e0b6bf24e74                                            
Removing intermediate container 2e0b6bf24e74                             
 ---> d8eb3ea955bf                                                       
Step 8/8 : CMD ["google.com"]                                            
 ---> Running in 6e4692726a8c                                            
Removing intermediate container 6e4692726a8c                             
 ---> 94f165a7e99d                                                       
Successfully built 94f165a7e99d                                          
Successfully tagged hadolint-example:latest 

Hadolint wykrył dwa miejsca do poprawy.

damian@szkoladockera:~/halint-example$ docker run --rm -i hadolint/hadolint < Dockerfile
/dev/stdin:1 DL3007 Using latest is prone to errors if the image will ever update. Pin the version explicitly to a release tag
/dev/stdin:5 DL3020 Use COPY instead of ADD for files and folders

Każdy wykryty błąd reprezentowany jest jako klucz DL (błąd Hadolinta) lub SC (błąd ShellCheck).

Dokumentację najczęstszych błędów można znaleźć: https://github.com/hadolint/hadolint#rules

Wtyczka do Visual Studio Code

Obecnie Visual Studio Code bije rekordy popularności. Jak wynika z ankiety przeprowadzonej przez Stack Overflow, na rok 2019, ponad 50% badanych wykorzystuje to narzędzie do codziennej pracy. W przypadku Web Developerów jest to aż 55.6 %.

Dlatego też, nie mogło się obejść bez wtyczki do Hadolinta

UWAGA 1:
Oprócz zainstalowania wtyczki w VS Code, potrzebujesz mieć fizycznie na dysku plik wykonywalny Hadolinta w katalogu, który jest dodany zmiennej $PATH. Można go pobrać TUTAJ.

UWAGA 2:  
W przypadku Windowsa, po pobraniu pliku „hadolint-Windows-x86_64.exe” należy zmienić nazwę na „hadolint.exe„. Inaczej wtyczka nie będzie działać.

Czy warto dodawać Docker Linter do pipelinu CI/CD?

Zdecydowanie TAK.

Tak samo, jak uruchamiamy testy jednostkowe, testy integracyjne, by sprawdzić czy nowo wprowadzona zmiana, nie zepsuła czegoś po drodze, tak samo walidowanie Dockerfile w procesie CI/CD zweryfikuje nam, czy postępujemy zgodnie z najlepszymi praktykami lub czy nie popełniliśmy błędu.

Dodatkowo, gdy pracujemy w zespole, zmiana wprowadzona przez Juniora, (nie mam nic do juniorów) czy osobę początkująca w świecie konteneryzacji, może być od razu zweryfikowana.
Dobrym rozwiązaniem może byc skonfigurowanie procesu CI/CD, by otrzymywać powiadomienia, w momencie gdy Hadolint coś wykryje.

Nawet jeśli jesteśmy już doświadczeni, to przecież nikt nie jest nieomylny. Warto to zrobić, nawet gdy w pojedynkę pracujemy nad projektem.

Jak zintegrować Hadolint z popularnymi narzędziami CI/CD?

1. GitLab

Dodaj następujący krok do pliku .gitlab-ci.yml

lint_dockerfile:
  image: hadolint/hadolint:latest-debian
  script:
    - hadolint Dockerfile

2. Jenkins

Możesz dodać krok podczas procesu CI/CD w następujący sposób

stage ("lint dockerfile") {
    agent {
        docker {
            image 'hadolint/hadolint:latest-debian'
        }
    }
    steps {
        sh 'hadolint dockerfiles/* | tee -a hadolint_lint.txt'
    }
    post {
        always {
            archiveArtifacts 'hadolint_lint.txt'
        }
    }
}

3. Bitbucket Pipelines

Utwórz plik konfiguracyjny bitbucket-pipelines.yml:

pipelines:
  default:
    - step:
        image: hadolint/hadolint:latest-debian
        script:
          - hadolint Dockerfile

Wszystkie dostępne integracje Hadolinta znajdziesz TUTAJ.

Gorąco zachęcam by korzystać z Hadolinta, czy tez innego dowolnego Docker Lintera na co dzień. Zarówno lokalnie np. wykorzystując wtyczkę do Visual Studio Code oraz jako krok w procesie CI/CD.

Jeżeli uważasz, że istnieje jakieś lepsze narzędzie niz Hadolint, koniecznie podziel się nim w komentarzu!

Dziękuje!

Artykuł Czym jest Docker Linter oraz jak walidować Dockerfile w procesie CI/CD pochodzi z serwisu Szkoła Dockera.

Publikuję trzecie video z serii „Docker Dla Zaawansowanych”.

Jeżeli nie widziałeś dwóch poprzednich filmów – gorąco zachęcam

Jak zbudowany jest Docker Image – wprowadzenie TUTAJ
Docker Image oraz Docker Registry TUTAJ

W tym video tłumaczę w jaki sposób obrazy oraz kontenery są przechowywane na dysku.

Dodatkowo dowiesz się o:

? przechowywaniu danych tymczasowych kontenera
? przechowywaniu warstw obrazu na dysku
? CO TO jest storage driver i PO CO?
? SZCZEGÓŁOWE omówienie storage drivera – OVERLAY2.

Artykuł Jak warstwy i pliki są przechowywane na dysku? Docker Storage Drivers pochodzi z serwisu Szkoła Dockera.

Część pierwszą możesz obejrzeć TUTAJ

Czego dowiesz się oglądając to wideo?

• Krótkie omówienie Docker Registry
• Co to jest FAT Manifest i po co?
• Dlaczego warstwy Docker Image są hashowane?
• Zalety hashowania warstw
• Content Hashes vs Distribution Hashes

Artykuł Docker Image – część druga [VIDEO] pochodzi z serwisu Szkoła Dockera.

Na YouTube pojawiło się pierwsze wideo, w którym opowiadam jak zbudowany jest Docker Image. Jest to początek pewnej serii , jaką planuję. Zachęcam zatem do zasubskrybowania kanału

Ogladając to wideo, dowiesz się:

• Z czego składa się Docker Image
• Czy Docker image to jeden plik
• Co to jest i do czego służy plik Manifest
• Co dalej

W kolejnym odcinku planuje poruszyć następujące kwestie.

• Co to jest i do czego służy FAT Manifest
• W jaki sposób poszczególne warstwy są zapisywane na dysku
• Korelacje na dysku pomiędzy warstwami
• Co dzieje się w momencie pobierania obrazu z Docker Hub

Stay tuned!

Artykuł Docker Image – część pierwsza [VIDEO] pochodzi z serwisu Szkoła Dockera.