Jak skonfigurować Docker CI/CD w mniej niż 10 minut?

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.

Analogicznie dodajemy DOCKER_PASSWORD

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

2. Dodanie akcji

Przechodzimy następnie do repozytorium do sekcji Actions.

Następnie wybieram „Set up a workflow yourself”

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/[email protected]
      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:

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

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

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/[email protected]
      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.