🥇Możesz teraz tworzyć obrazy Dockera w werfie, używając zwykłego pliku Dockerfile

Lepiej późno niż wcale. Albo o tym, jak prawie popełniliśmy poważny błąd, nie obsługując zwykłych plików Dockerfile do tworzenia obrazów aplikacji.

Porozmawiamy o werf — Narzędzie GitOps, które integruje się z dowolnym systemem CI/CD i zapewnia zarządzanie całym cyklem życia aplikacji, umożliwiając:

zbierać i publikować obrazy,
wdrażaj aplikacje w Kubernetes,
usuń nieużywane obrazy, korzystając ze specjalnych zasad.

Filozofia projektu polega na zebraniu narzędzi niskiego poziomu w jeden ujednolicony system, który daje inżynierom DevOps kontrolę nad aplikacjami. Jeśli to możliwe, należy użyć istniejących narzędzi (takich jak Helm i Docker). Jeśli nie ma rozwiązania problemu, możemy stworzyć i wesprzeć wszystko, co jest do tego potrzebne.

Tło: Twój własny kolekcjoner obrazów

Tak właśnie stało się z modułem zbierającym obrazy w werfie: zwykły plik Dockerfile nie był dla nas wystarczający. Jeśli rzucić okiem na historię projektu, problem ten pojawiał się już w pierwszych wersjach werf (wtedy jeszcze znany jako dapp).

Tworząc narzędzie do budowania aplikacji w obrazach Dockera, szybko zdaliśmy sobie sprawę, że Dockerfile nie jest dla nas odpowiedni do niektórych bardzo specyficznych zadań:

Konieczność budowania typowych małych aplikacji internetowych według następującego standardowego schematu:
- zainstaluj ogólnosystemowe zależności aplikacji,
- zainstaluj pakiet bibliotek zależności aplikacji,
- gromadzić aktywa,
- i co najważniejsze, szybko i skutecznie zaktualizuj kod na obrazie.
Po wprowadzeniu zmian w plikach projektu konstruktor musi szybko utworzyć nową warstwę, nakładając łatkę na zmienione pliki.
Jeśli niektóre pliki uległy zmianie, konieczne jest odbudowanie odpowiedniego etapu zależnego.

Dziś nasz kolekcjoner ma wiele innych możliwości, ale takie były początkowe pragnienia i popędy.

Ogólnie rzecz biorąc, nie zastanawiając się dwa razy, uzbroiliśmy się w język programowania, którego używaliśmy (patrz poniżej) i ruszaj w drogę do wdrożenia własny DSL! Zgodnie z założeniami zamierzano opisać proces montażu etapowo oraz określić zależności tych etapów na plikach. I uzupełnił własny kolekcjoner, co zamieniło DSL w ostateczny cel - zmontowany obraz. Początkowo DSL był w Ruby, ale jako przejście do Golangu — zaczęto opisywać konfigurację naszego kolektora w pliku YAML.

Stara konfiguracja dapp w Ruby

Bieżąca konfiguracja dla werf na YAML

Z biegiem czasu zmieniał się także mechanizm kolektora. Na początku po prostu wygenerowaliśmy na bieżąco tymczasowy plik Dockerfile z naszej konfiguracji, a następnie zaczęliśmy uruchamiać instrukcje asemblowania w tymczasowych kontenerach i zatwierdzać.

NB: W tej chwili nasz kolektor, który działa z własną konfiguracją (w YAML) i nazywa się kolektorem Stapel, rozwinął się już w dość potężne narzędzie. Jego szczegółowy opis zasługuje na osobny artykuł, a podstawowe szczegóły można znaleźć m.in dokumentacja.

Świadomość problemu

Ale nie od razu zdaliśmy sobie sprawę, że popełniliśmy jeden błąd: nie dodaliśmy tej umiejętności buduj obrazy za pomocą standardowego pliku Dockerfile i zintegrować je z tą samą kompleksową infrastrukturą zarządzania aplikacjami (tj. zbierać obrazy, wdrażać je i czyścić). Jak mogłoby być możliwe stworzenie narzędzia do wdrożenia w Kubernetesie i nie zaimplementowanie obsługi Dockerfile, tj. standardowy sposób opisywania obrazów w większości projektów?..

Zamiast odpowiadać na to pytanie, proponujemy rozwiązanie. Co się stanie, jeśli masz już plik Dockerfile (lub zestaw plików Dockerfile) i chcesz użyć werf?

NB: Swoją drogą, dlaczego w ogóle chcesz używać werf? Główne cechy sprowadzają się do następujących kwestii:

pełny cykl zarządzania aplikacją, w tym czyszczenie obrazu;
możliwość zarządzania montażem kilku obrazów jednocześnie z jednej konfiguracji;
Ulepszony proces wdrażania wykresów zgodnych z Helm.

Pełniejszą ich listę można znaleźć na stronie strona projektu.

Jeśli więc wcześniej zaproponowalibyśmy przepisanie pliku Dockerfile w naszej konfiguracji, teraz z radością powiemy: „Pozwól werfowi zbudować Twoje pliki Dockerfile!”

Jak korzystać?

Pełna implementacja tej funkcji pojawiła się w wydaniu werf v1.0.3-beta.1. Ogólna zasada jest prosta: użytkownik określa ścieżkę do istniejącego pliku Dockerfile w konfiguracji werf, a następnie uruchamia polecenie werf build... i tyle - werf zmontuje obraz. Spójrzmy na abstrakcyjny przykład.

Ogłaszamy kolejny Dockerfile w katalogu głównym projektu:

FROM ubuntu:18.04
RUN echo Building ...

I ogłosimy werf.yamlktóry tego używa Dockerfile:

configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile

Wszystko! Lewy biegać werf build:

Ponadto możesz zadeklarować następujące informacje werf.yaml aby zbudować kilka obrazów z różnych plików Dockerfile jednocześnie:

configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend

Wreszcie obsługuje także przekazywanie dodatkowych parametrów kompilacji, takich jak --build-arg и --add-host - poprzez konfigurację werf. Pełny opis konfiguracji obrazu Dockerfile jest dostępny pod adresem strona dokumentacji.

Jak to działa?

Podczas procesu kompilacji działa standardowa pamięć podręczna warstw lokalnych w Dockerze. Jednak ważne jest to, że werf też integruje konfigurację Dockerfile ze swoją infrastrukturą. Co to znaczy?

Każdy obraz zbudowany z pliku Dockerfile składa się z jednego etapu zwanego dockerfile (możesz przeczytać więcej o tym, jakie etapy są w werf tutaj).
Na scenę dockerfile werf oblicza podpis zależny od zawartości konfiguracji Dockerfile. Gdy zmienia się konfiguracja pliku Dockerfile, zmienia się podpis stołu montażowego dockerfile i werf inicjuje przebudowę tego etapu z nową konfiguracją Dockerfile. Jeśli podpis się nie zmieni, werf pobierze obraz z pamięci podręcznej (więcej szczegółów na temat stosowania podpisów w werfie opisano w ten raport).
Następnie zebrane obrazy można opublikować za pomocą polecenia werf publish (or werf build-and-publish) i użyj go do wdrożenia w Kubernetes. Opublikowane obrazy w rejestrze Docker zostaną oczyszczone przy użyciu standardowych narzędzi do czyszczenia Werf, tj. Stare obrazy (starsze niż N dni), obrazy powiązane z nieistniejącymi gałęziami Git i inne zasady zostaną automatycznie oczyszczone.

Więcej szczegółów na temat opisanych tutaj punktów można znaleźć w dokumentacji:

Uwagi i środki ostrożności

1. Zewnętrzny adres URL nie jest obsługiwany w ADD

Obecnie nie jest obsługiwane używanie zewnętrznego adresu URL w dyrektywie ADD. Werf nie zainicjuje przebudowy, gdy zasób pod określonym adresem URL ulegnie zmianie. Planujemy wkrótce dodać tę funkcję.

2. Nie możesz dodać .git do obrazu

Ogólnie rzecz biorąc, dodanie katalogu .git na obrazku - okropna zła praktyka i oto dlaczego:

jeśli .git pozostaje na ostatecznym obrazie, narusza to zasady Aplikacja 12-czynnikowa: Ponieważ ostateczny obraz musi być powiązany z pojedynczym zatwierdzeniem, nie powinno być to możliwe git checkout dowolne zatwierdzenie.
.git zwiększa rozmiar obrazu (repozytorium może być duże ze względu na to, że raz dodano do niego duże pliki, a następnie je usunięto). Rozmiar drzewa roboczego powiązanego tylko z konkretnym zatwierdzeniem nie będzie zależał od historii operacji w Git. W tym przypadku dodawanie i późniejsze usuwanie .git z finalnego obrazu nie będzie działać: obraz i tak zyska dodatkową warstwę – tak działa Docker.
Docker może zainicjować niepotrzebną przebudowę, nawet jeśli budowane jest to samo zatwierdzenie, ale z różnych drzew roboczych. Na przykład GitLab tworzy osobne sklonowane katalogi w /home/gitlab-runner/builds/HASH/[0-N]/yourproject gdy włączony jest montaż równoległy. Dodatkowy ponowny montaż będzie wynikał z faktu, że katalog .git jest inny w różnych sklonowanych wersjach tego samego repozytorium, nawet jeśli zbudowane jest to samo zatwierdzenie.

Ostatni punkt ma również konsekwencje podczas używania werf. Werf wymaga obecności wbudowanej pamięci podręcznej podczas uruchamiania niektórych poleceń (np. werf deploy). Po uruchomieniu tych poleceń werf oblicza podpisy etapów dla obrazów określonych w werf.yamli muszą znajdować się w pamięci podręcznej zestawów - w przeciwnym razie polecenie nie będzie mogło kontynuować działania. Jeśli podpis sceniczny zależy od treści .git, wówczas otrzymamy pamięć podręczną niestabilną na zmiany w nieistotnych plikach, a werf nie będzie w stanie wybaczyć takiego przeoczenia (więcej szczegółów zob. dokumentacja).

Ogólnie dodając tylko niektóre niezbędne pliki poprzez instrukcje ADD w każdym razie zwiększa efektywność i wiarygodność tekstu pisanego Dockerfile, a także poprawia stabilność zebranej w tym celu pamięci podręcznej Dockerfile, do nieistotnych zmian w Git.

Łączny

Nasza początkowa droga do napisania własnego kreatora dla konkretnych potrzeb była trudna, uczciwa i prosta: zamiast używać kul na standardowym pliku Dockerfile, napisaliśmy nasze rozwiązanie z niestandardową składnią. A to miało swoje zalety: kolektor Stapel doskonale radzi sobie ze swoim zadaniem.

Jednak w trakcie pisania własnego kreatora straciliśmy z pola widzenia obsługę istniejących plików Dockerfile. Ta usterka została już naprawiona i w przyszłości planujemy rozwijać obsługę Dockerfile wraz z naszym niestandardowym kreatorem Stapel do montażu rozproszonego i montażu przy użyciu Kubernetesa (tj. montażu na prowadnicach wewnątrz Kubernetesa, tak jak dzieje się to w kaniko).

Tak więc, jeśli nagle masz kilka plików Dockerfile... spróbuj werf!

PS Lista dokumentacji na ten temat

Przeczytaj także na naszym blogu: „werf - nasze narzędzie do CI/CD w Kubernetes (przegląd i relacja wideo)".

Źródło: www.habr.com

Możesz teraz tworzyć obrazy Dockera w werf przy użyciu zwykłego pliku Dockerfile