Docker Maestro → Dołącz już dziś! »»

Dzisiejszy wpis porusza kwestie automatyzacji, a dokładniej skonfigurowanie procesu budowania obrazów dockerowych (Docker CI/CD) przy wykorzystaniu nowo wprowadzonej funkcjonalności — Docker Github Action. Dodatkowo dowiesz się o planach rozwoju Dockera na rok 2020.


Road Mapa Dockera na rok 2020

Jeśli zaglądasz regularnie na tego bloga (jeśli nie to czas to zmienić :P), to już pewnie wiesz, że kilka tygodni temu, Docker ogłosił roadmapę na rok 2020. Znajdziesz w niej całą masę usprawnień i feature’ów, które zostaną zaimplementowane w najbliższej przyszłości.

W 2019 roku Docker (jako firma) przeszedł dość sporą rewolucję. Kluczowym momentem była sprzedaż rozwiązania Docker Enterprise firmie Mirantis. Od tej pory Docker skupia się na rozwiązaniach dla developerów, co potwierdza wcześniej wymieniona roadmapa.

Jednym z nowych elementów było stworzenie Docker Github Action, która miała posłużyć do automatyzacji procesów CI/CD i finalnie przyjęła nazwę „build-push-action”.


Dlaczego CI/CD na Githubie?

Pojawia się pytanie. Dlaczego Github, a nie Gitlab, Bitbucket czy Jenkins?

Bez wątpienia Github jest najpopularniejszym miejscem w internecie dla projektów open source. Github posiada też opcję prywatnych repozytoriów, które przez dłuższy czas były dostępne tylko za odpowiednią opłatą.

Od niedawna ta opłata została zniesiona. Dzięki temu, jeżeli nie chcemy udostępniać kodu publicznie (przykładowo pracujemy nad swoim tajnym projektem / produktem) możemy skorzystać z GitHuba za darmo.

W dzisiejszych czasach stosowanie automatycznego budowania, czy automatycznego wdrażania aplikacji na różne środowiska jest standardem. Nawet dla własnych projektów, z czasem warto skonfigurować sobie taki proces.

Czas to najcenniejsze co mamy w życiu. Po co więc tracić go na rzeczy, które możemy zautomatyzować.


Jak działa Docker Github Action?

Do tej pory, chcąc skonfigurować automatycznie budowanie obrazu, taggowanie oraz wypchnięcie go do Docker Registry musieliśmy posługiwać się skryptami pomocniczymi, których na dodatek nie można było przetestować lokalnie. Problem ten został rozwiązany za pomocą przeznaczonej do tego akcji, którą możemy dodać jako krok w procesie ciągłej integracji (Docker CI/CD) bezpośrednio Github Marketplace.

Głównym założeniem tego rozwiązania jest po pierwsze zbudowanie obrazu, przypisanie mu odpowiedniego taga (np. nazwę branch’a czy też SHA danego commit’a), logowanie do prywatnego Docker Registry oraz wsparcie dla typowych poleceń Docker CLI takich jak określenie build context’u, czy nazwy Dockerfile’a.

Reasumując, nowo wprowadzoną akcja pozwala na:

  • Nadawanie obrazom tagów na podstawie referencji gitowych (pull requesty, branche, tagi)
  • Nadawanie obrazom tagów na podstawie commitów (SHA) mogących przydać się w bardziej złożonych procesach CI/CD.
  • Przekazywanie argumentów do Dockerfile (--build-arg)
  • Uwierzytelnianie do prywatnych Docker Registry
  • Warunkowe wypychanie obrazów do Docker Registry.
    Przykładowo, chcemy by obraz został wypchnięty do Docker Registry tylko po dodaniu nowego taga w repozytorium gita.


Docker CI/CD na Githubie – Przykład

Aby móc skorzystać z benefitów oferowanych przez tę akcję, potrzebujemy:

Po pierwsze: aplikacji dostępnej na Githubie, zawierającej w repozytorium plik Dockerfile.
Po drugie: Docker Registry, aby móc wypchnąć tam zbudowany obraz

Do skonfigurowania automatyzacji posłużę się jest prostym WebAPI, dostępnym na moim Githubie — oo TUTAJ.

Jako Docker Registry, skorzystam z rozwiązania oferowanego na platformie Microsoft Azure (Azure Container Registry). Utworzone Docker Registry dostępne jest pod adresem  dnaprawa.azurecr.io

Niestety nie jest to darmowe rozwiązanie i wymaga to posiadania subskrypcji.  Jeśli chodzi o darmowe Docker Registry, można skorzystać z TreeScale lub Canister. Ostatnio testowałem to ostanie (Canister) i póki co nie wykryłem żadnych problemów 😉

To tyle jeśli chodzi o wymagania wstępne. Zaczynamy ; )


1. Sekrety do prywatnego Docker Registry

Ideą prywatnych Docker Registry jest zabezpieczenie przed nieautoryzowanym dostępem do dodawania i pobierania obrazów.

Aby umożliwić komunikacje na lini Github-Registry, dodajemy sekrety DOCKER_USERNAME oraz DOCKER_PASSWORD zawierające dane do uwierzytelniania do Docker Registry.

Tworzenie sekretów dla Docker Regsitry na Githubie

Analogicznie dodajemy DOCKER_PASSWORD

Po dodaniu obu sekretów, powinniśmy otrzymać zbliżony efekt.

Tworzenie sekretów dla Docker Regsitry na Githubie

2. Dodanie akcji

Przechodzimy następnie do repozytorium do sekcji Actions.

Dodanie Docker Github Action

Następnie wybieram „Set up a workflow yourself”

Docker CI/CD

W tym miejscu dodaję akcję, jako osobny krok w definicji procesu. W moim przypadku wygląda to następująco:

    - name: Build and push Docker images
      uses: docker/build-push-action@v1.0.1
      with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}
          registry: dnaprawa.azurecr.io
          repository: currency-viewer
          tags: v1
          # Set build context as current (root) directory
          path: .

Krótko mówiąc, wystarczy wskazać dane do uwierzytelniania na podstawie sekretów zdefiniowanych w poprzednim kroku oraz dodać nazwę Docker Registry i repozytorium, do którego ma trafić zbudowany obraz. Oczywiście, potrzebujemy również tag, który u mnie testowo przybrał nazwę v1. Na koniec, określamy build context. Jako że plik Dockerfile znajduje się w głównym katalogu wewnątrz repozytorium gita, ustawiam build context na bieżący katalog za pomocą path: .


3. Zatwierdzenie zmian

Przed zatwierdzeniem zmian, całość wyglądała następująco:

Docker CI/CD - konfiguracja

Wystarczy teraz zatwierdzić zmiany (Start commit), co spowoduje utworzenie nowego pliku w katalogu ~/.github/workflows, a następnie uruchomi procesu budowania.

Docker CI/CD - konfiguracja

Proces budowania przeszedł poprawnie. Oznacza to, że obraz został zbudowany i wypchnięty do Docker Registry

Docker CI/CD - budowanie obrazów

Cała definicja, której użyłem wygląda następująco:

# This is a basic workflow to help you get started with Actions

name: CI

# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
    # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
    - uses: actions/checkout@v2

    - name: Build and push Docker images
      uses: docker/build-push-action@v1.0.1
      with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}
          registry: dnaprawa.azurecr.io
          repository: currency-viewer
          tags: v1
          # Set build context as current (root) directory
          path: .

4. Weryfikacja Docker Registry

Chcąc upewnić się, że obraz został przesłany do repozytorium, należy przejść do portalu Azure:

Widzimy, że zostało stworzone repozytorium o nazwie currency-viewer (tak jak podaliśmy w definicji) oraz został dodany obraz z tagiem v1

Na potrzeby testów, tag v1 został przypisany na stałe. Jak już wcześniej wspominałem, jako tag możemy użyć numeru commit’a czy też nazwę brancha, na podstawie którego budujemy obraz.


Podsumowanie

Jak widzimy, wystarczy tylko chwila czasu (i chęci), by zautomatyzować proces budowania obrazów dockerowych. Jeżeli pracujesz nad swoim projektem „po godzinach” to koniecznie rozważ skonfigurowanie takiego procesu. Wybranie któregoś z darmowych Docker Registry sprawi, że nie będzie to Cię nic kosztować. Mając zbudowany obraz aplikacji, możesz łatwo go udostępnić — komukolwiek zechcesz. Wystarczy, by ta osoba miała zainstalowanego Dockera.

Często firmy w swoich zadaniach rekrutacyjnych proszą, aby udostępnić kod na GitHubie. Zaskocz ich pozytywnie i powiedz, że oprócz zadania, dodałeś integrację z Dockerem i skonfigurowałeś automatyczne budowania obrazów.


Dołącz do newslettera

Już ponad 850 osób zapisało się na mój newsletter (zero spamu! - tylko informacje o nowych artykułach oraz ciekawe nowinki ze świata konteneryzacji).

Zapisując się, jako bonus prześlę Ci "21 Praktycznych Przykładów Użycia Dockera Dla Developerów" oraz zbiór "10 Najlepszych Praktyk Tworzenia Dockerfile"



Damian Naprawa

Praktykujący pasjonat konteneryzacji. Lubi dzielić się wiedzą, prowadząc warsztaty i szkolenia. Chętnie występuje również w roli prelegenta na meetupach i konferencjach. Uczestnik globalnego programu partnerskiego Docker Enablement. Pracuje z Dockerem na co dzień od kilku lat. Odpowiedzialny za tworzenie i utrzymanie systemów działających w oparciu o kontenery. Fan automatyzacji oraz podejścia "As a Code".

2 Komentarze

Krzysiek · 16 kwietnia 2020 o 20 h 19 min

Super – oby takich wincyj 😎
Może coś więcej opowiesz o bezpłatnych Registry? Chętnie bym się dowiedział opinii eksperta 😊

    Damian Naprawa · 17 kwietnia 2020 o 7 h 54 min

    Hej Krzysiek! Dzięki za komentarz 🙂

    Co konkretnie by Cię interesowało jeśli chodzi o darmowe Docker Registry?

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *