to nasze narzędzie GitOps CLI typu open source do tworzenia i dostarczania aplikacji do Kubernetes. Jak obiecano, zapoczątkował dodawanie nowych funkcji do wewer i rewizję tradycyjnych podejść. Teraz mamy przyjemność zaprezentować wersję v1.1, która jest dużym krokiem w rozwoju i fundamentem na przyszłość kolektor werf. Wersja jest obecnie dostępna w .
Podstawą wydania jest nowa architektura magazynu scenicznego i optymalizacja pracy obu kolektorów (dla Stapel i Dockerfile). Nowa architektura pamięci masowej otwiera możliwość wdrażania rozproszonych zestawów z wielu hostów i zestawów równoległych na tym samym hoście.
Optymalizacja pracy polega na pozbyciu się zbędnych obliczeń na etapie obliczania sygnatur etapów i zmianie mechanizmów obliczania sum kontrolnych plików na bardziej wydajne. Ta optymalizacja skraca średni czas kompilacji projektu przy użyciu werf. I bezczynne kompilacje, gdy wszystkie etapy istnieją w pamięci podręcznej etapy-przechowywanie, są teraz naprawdę szybkie. W większości przypadków ponowne uruchomienie kompilacji zajmie mniej niż 1 sekundę! Dotyczy to również procedur weryfikacji etapów procesu pracy zespołów. werf deploy и werf run.
Również w tym wydaniu pojawiła się strategia oznaczania obrazów według treści - tagowanie oparte na treści, która jest teraz domyślnie włączona i jedyna zalecana.
Przyjrzyjmy się bliżej kluczowym innowacjom w werf v1.1, a jednocześnie opowiedzmy o planach na przyszłość.
Co się zmieniło w werf v1.1?
Nowy format nazewnictwa etapów i algorytm wybierania etapów z pamięci podręcznej
Nowa zasada generowania pseudonimów. Teraz każda kompilacja etapu generuje unikalną nazwę etapu, która składa się z 2 części: podpisu (tak jak to było w wersji 1.0) oraz unikalnego identyfikatora tymczasowego.
Na przykład pełna nazwa obrazu scenicznego może wyglądać następująco:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
...lub ogólnie:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Tutaj:
-
SIGNATUREjest sygnaturą etapu, która reprezentuje identyfikator zawartości etapu i zależy od historii edycji w Git, które doprowadziły do tej treści; -
TIMESTAMP_MILLISECto gwarantowany unikalny identyfikator obrazu, który jest generowany w momencie tworzenia nowego obrazu.
Algorytm wybierania etapów z pamięci podręcznej opiera się na sprawdzaniu relacji zatwierdzeń Git:
- Werf oblicza sygnaturę określonego etapu.
- В etapy-przechowywanie Dla danego podpisu może być kilka etapów. Werf wybiera wszystkie etapy pasujące do podpisu.
- Jeśli bieżący etap jest połączony z Git (archiwum git, etap niestandardowy z poprawkami Git:
install,beforeSetup,setup; lub git-latest-patch), wówczas werf wybiera tylko te etapy, które są powiązane z zatwierdzeniem będącym przodkiem bieżącego zatwierdzenia (dla którego wywoływana jest kompilacja). - Z pozostałych odpowiednich etapów wybierany jest jeden – najstarszy według daty powstania.
Scena dla różnych gałęzi Git może mieć ten sam podpis. Ale werf zapobiegnie używaniu pamięci podręcznej powiązanej z różnymi gałęziami między tymi gałęziami, nawet jeśli podpisy się zgadzają.
.
Nowy algorytm tworzenia i zapisywania etapów w magazynie scen
Jeżeli podczas wybierania etapów z pamięci podręcznej werf nie znajdzie odpowiedniego etapu, wówczas inicjowany jest proces składania nowego etapu.
Należy pamiętać, że wiele procesów (na jednym lub większej liczbie hostów) może rozpocząć tworzenie tego samego etapu mniej więcej w tym samym czasie. Werf wykorzystuje optymistyczny algorytm blokowania etapy-przechowywanie w momencie zapisywania świeżo zebranego obrazu w etapy-przechowywanie. W ten sposób, gdy nowa konstrukcja sceny będzie gotowa, werf blokuje etapy-przechowywanie i zapisuje tam świeżo zebrany obraz tylko wtedy, gdy odpowiedni obraz już tam nie istnieje (według sygnatury i innych parametrów - zobacz nowy algorytm wybierania etapów z pamięci podręcznej).
Gwarantujemy, że świeżo złożony obraz będzie miał unikalny identyfikator TIMESTAMP_MILLISEC (zobacz nowy format nazewnictwa scenicznego). W przypadku w etapy-przechowywanie zostanie znaleziony odpowiedni obraz, werf odrzuci świeżo skompilowany obraz i użyje obrazu z pamięci podręcznej.
Innymi słowy: proces, który jako pierwszy zakończy budowanie obrazu (najszybszy) uzyska prawo do przechowywania go w stage-storage (i wtedy to właśnie ten pojedynczy obraz będzie używany do wszystkich buildów). Powolny proces kompilacji nigdy nie przeszkodzi szybszemu procesowi w zapisaniu wyników kompilacji z bieżącego etapu i przejściu do następnej kompilacji.
.
Poprawiona wydajność narzędzia do tworzenia plików Dockerfile
W tej chwili potok etapów obrazu zbudowanego z pliku Dockerfile składa się z jednego etapu - dockerfile. Przy obliczaniu podpisu obliczana jest suma kontrolna plików context, które będą wykorzystywane podczas montażu. Przed tym ulepszeniem werf rekurencyjnie przeglądał wszystkie pliki i uzyskiwał sumę kontrolną, sumując kontekst i tryb każdego pliku. Począwszy od wersji 1.1, werf może używać obliczonych sum kontrolnych przechowywanych w repozytorium Git.
Algorytm opiera się na . Algorytm uwzględnia rekordy w .dockerignore i rekurencyjnie przegląda drzewo plików tylko wtedy, gdy jest to konieczne. W ten sposób oddzielono nas od czytania systemu plików i zależności algorytmu od rozmiaru context nie jest znaczące.
Algorytm sprawdza również pliki nieśledzone i w razie potrzeby uwzględnia je w sumie kontrolnej.
Poprawiona wydajność podczas importowania plików
Wersje werf v1.1 używają serwera rsync, gdy . Poprzednio importowanie odbywało się w dwóch etapach przy użyciu montowania katalogu z systemu hosta.
Wydajność importu w systemie macOS nie jest już ograniczona woluminami platformy Docker, a import odbywa się w tym samym czasie, co w systemach Linux i Windows.
Tagowanie oparte na treści
Werf v1.1 obsługuje tzw. tagowanie według zawartości obrazu - tagowanie oparte na treści. Tagi wynikowych obrazów platformy Docker zależą od zawartości tych obrazów.
Podczas uruchamiania polecenia werf publish --tags-by-stages-signature lub werf ci-env --tagging-strategy=stages-signature opublikowane zdjęcia tzw podpis sceniczny obraz. Każdy obraz jest oznaczony własną sygnaturą etapów tego obrazu, która jest obliczana według tych samych zasad, co zwykła sygnatura każdego etapu z osobna, ale stanowi ogólny identyfikator obrazu.
Podpis etapów obrazu zależy od:
- zawartość tego obrazu;
- historie zmian w Gicie, które doprowadziły do powstania tej treści.
Repozytorium Git zawsze zawiera fikcyjne zatwierdzenia, które nie zmieniają zawartości plików obrazów. Na przykład zatwierdzenia zawierające tylko komentarze lub zatwierdzenia scalone, lub zatwierdzenia zmieniające te pliki w Git, które nie zostaną zaimportowane do obrazu.
W przypadku korzystania z tagowania opartego na treści rozwiązywane są problemy niepotrzebnego restartowania podów aplikacji w Kubernetesie na skutek zmian w nazwie obrazu, nawet jeśli zawartość obrazu nie uległa zmianie. Swoją drogą jest to jeden z powodów, który uniemożliwia przechowywanie wielu mikroserwisów jednej aplikacji w jednym repozytorium Git.
Ponadto tagowanie oparte na treści jest bardziej niezawodną metodą tagowania niż tagowanie w gałęziach Git, ponieważ zawartość wynikowych obrazów nie zależy od kolejności wykonywania potoków w systemie CI w celu złożenia wielu zatwierdzeń tej samej gałęzi.
To jest ważne: zaczynając od teraz podpis sceniczny - jest jedyna zalecana strategia tagowania. Będzie on domyślnie używany w poleceniu werf ci-env (chyba że wyraźnie określisz inny schemat tagowania).
. Tej funkcji poświęcona będzie także osobna publikacja. ZAKTUALIZOWANO (3 kwietnia): Artykuł ze szczegółami .
Poziomy rejestrowania
Użytkownik ma teraz możliwość kontrolowania wyników, ustawiania poziomu rejestrowania i pracy z informacjami debugowania. Dodano opcje --log-quiet, --log-verbose, --log-debug.
Domyślnie dane wyjściowe zawierają minimum informacji:
Podczas korzystania z pełnych danych wyjściowych (--log-verbose) możesz zobaczyć jak działa werf:
Szczegółowe dane wyjściowe (--log-debug), oprócz informacji o debugowaniu werf, zawiera także logi używanych bibliotek. Możesz na przykład zobaczyć, jak zachodzi interakcja z rejestrem Docker, a także zapisać miejsca, w których spędza się znaczną ilość czasu:
Dalsze plany
Ostrzeżenie! Opisane poniżej opcje są zaznaczone v1.1 będą dostępne w tej wersji, wiele z nich w najbliższej przyszłości. Aktualizacje będą przychodzić poprzez automatyczne aktualizacje . Funkcje te nie wpływają na stabilną część funkcji wersji 1.1, ich wygląd nie będzie wymagał ręcznej interwencji użytkownika w istniejących konfiguracjach.
Pełne wsparcie dla różnych implementacji rejestru Docker (NOWOŚĆ)
- Wersja: v1.1
- Daty: marzec
Celem jest, aby użytkownik mógł używać niestandardowej implementacji bez ograniczeń podczas korzystania z werf.
Obecnie zidentyfikowaliśmy następujący zestaw rozwiązań, dla których gwarantujemy pełne wsparcie:
- Domyślny (biblioteka/rejestr)*,
- AWS ECR
- Lazur*,
- Centrum Dockera
- GCR*,
- Pakiety GitHuba
- Rejestr GitLab*,
- Port*,
- Nadbrzeże.
Rozwiązania, które są obecnie w pełni obsługiwane przez werf, są oznaczone gwiazdką. Dla innych istnieje wsparcie, ale z ograniczeniami.
Można wyróżnić dwa główne problemy:
- Niektóre rozwiązania nie obsługują usuwania tagów przy użyciu interfejsu Docker Registry API, co uniemożliwia użytkownikom korzystanie z automatycznego czyszczenia werf. Dotyczy to pakietów AWS ECR, Docker Hub i GitHub.
- Niektóre rozwiązania nie obsługują tzw. repozytoriów zagnieżdżonych (Docker Hub, GitHub Packages i Quay) lub obsługują, ale użytkownik musi je utworzyć ręcznie za pomocą interfejsu użytkownika lub API (AWS ECR).
Te i inne problemy będziemy rozwiązywać wykorzystując natywne API rozwiązań. Zadanie to obejmuje również pokrycie pełnego cyklu pracy werf testami dla każdego z nich.
Rozproszona kompilacja obrazu (↑)
- Wersja: v1.2 v1.1 (zwiększono priorytet wdrożenia tej funkcji)
- Terminy: marzec-kwiecień marzec
W tej chwili werf v1.0 i v1.1 można używać tylko na jednym dedykowanym hoście do operacji budowania i publikowania obrazów oraz wdrażania aplikacji na Kubernetesie.
Aby otworzyć możliwości rozproszonej pracy werf, gdy budowanie i wdrażanie aplikacji w Kubernetesie jest uruchamiane na kilku dowolnych hostach i hosty te nie zapisują swojego stanu pomiędzy kompilacjami (tymczasowe programy uruchamiające), werf musi zaimplementować możliwość wykorzystania Rejestr Docker jako magazyn sceniczny.
Wcześniej, gdy projekt werf nazywał się jeszcze dapp, miał taką możliwość. Napotkaliśmy jednak szereg problemów, które należy wziąć pod uwagę przy wdrażaniu tej funkcjonalności w werf.
Operacja. Ta funkcja nie wymaga, aby moduł zbierający działał w zasobnikach Kubernetes, ponieważ Aby to zrobić należy pozbyć się zależności od lokalnego serwera Dockera (w podu Kubernetes nie ma dostępu do lokalnego serwera Dockera, gdyż sam proces przebiega w kontenerze, a werf nie obsługuje i nie będzie obsługiwał praca z serwerem Docker przez sieć). Wsparcie dla uruchamiania Kubernetesa zostanie zaimplementowane osobno.
Oficjalne wsparcie dla GitHub Actions (NOWOŚĆ)
- Wersja: v1.1
- Daty: marzec
Zawiera dokumentację werf (sekcje odniesienie и poprowadzi), a także oficjalna akcja GitHub dotycząca pracy z werf.
Dodatkowo pozwoli Werfowi pracować nad efemerycznymi biegaczami.
Mechanika interakcji użytkownika z systemem CI będzie opierać się na umieszczaniu etykiet na żądaniach ściągnięcia w celu zainicjowania określonych działań w celu zbudowania/wdrożenia aplikacji.
Lokalny rozwój i wdrażanie aplikacji z werf (↓)
- Wersja: v1.1
- Daty: styczeń-luty kwiecień
Głównym celem jest osiągnięcie jednej, ujednoliconej konfiguracji do wdrażania aplikacji zarówno lokalnie, jak i w środowisku produkcyjnym, bez skomplikowanych działań, od razu po wyjęciu z pudełka.
werf musi również posiadać tryb działania, w którym wygodnie będzie edytować kod aplikacji i natychmiast otrzymywać informacje zwrotne od działającej aplikacji w celu debugowania.
Nowy algorytm czyszczenia (NOWOŚĆ)
- Wersja: v1.1
- Daty: kwiecień
W aktualnej wersji werf v1.1 w procedurze cleanup Nie ma możliwości czyszczenia obrazów w ramach schematu tagowania opartego na treści – obrazy te będą kumulowane.
Ponadto aktualna wersja werf (v1.0 i v1.1) wykorzystuje różne zasady czyszczenia obrazów publikowanych w ramach schematów tagowania: gałąź Git, tag Git lub zatwierdzenie Git.
Wynaleziono nowy algorytm czyszczenia obrazów oparty na historii zatwierdzeń w Git, ujednolicony dla wszystkich schematów tagowania:
- Zachowaj nie więcej niż N1 obrazów powiązanych z N2 najnowszymi zatwierdzeniami dla każdej git HEAD (gałęzi i znaczników).
- Przechowuj nie więcej niż obrazy etapu N1 powiązane z najnowszymi zatwierdzeniami N2 dla każdego git HEAD (gałęzie i znaczniki).
- Przechowuj wszystkie obrazy używane w zasobach klastra Kubernetes (skanowane są wszystkie konteksty kube pliku konfiguracyjnego i przestrzenie nazw; możesz ograniczyć to zachowanie za pomocą specjalnych opcji).
- Przechowuj wszystkie obrazy używane w manifestach konfiguracji zasobów zapisanych w wersjach Helm.
- Obraz można usunąć, jeśli nie jest powiązany z żadnym HEAD z git (na przykład, ponieważ sam odpowiedni HEAD został usunięty) i nie jest używany w żadnych manifestach w klastrze Kubernetes ani w wydaniach Helma.
Równoległe budowanie wizerunku (↓)
- Wersja: v1.1
- Terminy: styczeń-luty kwiecień*
Aktualna wersja werf gromadzi obrazy i artefakty opisane w werf.yaml, sekwencyjnie. Konieczne jest zrównoleglenie procesu składania niezależnych etapów obrazów i artefaktów, a także zapewnienie wygodnego i informacyjnego wyniku.
*Uwaga: termin został przesunięty ze względu na zwiększony priorytet wdrożenia rozproszonego montażu, co doda więcej możliwości skalowania w poziomie, a także wykorzystanie werf z GitHub Actions. Montaż równoległy to kolejny krok optymalizacji, zapewniający skalowalność pionową przy składaniu jednego projektu.
Przejście do Helmu 3 (↓)
- Wersja: v1.2
- Terminy: luty-marzec maj*
Obejmuje migrację do nowej bazy kodu oraz sprawdzony i wygodny sposób migracji istniejących instalacji.
* Uwaga: przejście na Helm 3 nie doda znaczących funkcji do werf, ponieważ wszystkie kluczowe funkcje Helma 3 (łączenie trójstronne i brak rumpla) są już zaimplementowane w werf. Co więcej, Werf ma oprócz wskazanych. Jednak to przejście pozostaje w naszych planach i zostanie wdrożone.
Jsonnet do opisu konfiguracji Kubernetes (↓)
- Wersja: v1.2
- Daty: styczeń-luty kwiecień-maj
Werf będzie obsługiwał opisy konfiguracji dla Kubernetes w formacie Jsonnet. Jednocześnie werf pozostanie kompatybilny z Helmem i będzie możliwość wyboru formatu opisu.
Powodem jest to, że według wielu osób szablony Go mają wysoką barierę wejścia, przez co ucierpi także zrozumiałość kodu tych szablonów.
Rozważana jest także możliwość wprowadzenia innych systemów opisu konfiguracji Kubernetesa (np. Kustomize).
Praca w Kubernetesie (↓)
- Wersja: v1.2
- Terminy: kwiecień-maj maj-czerwiec
Cel: Upewnij się, że obrazy są zbudowane, a aplikacja jest dostarczana przy użyciu modułów biegaczy w Kubernetes. Te. Nowe obrazy można tworzyć, publikować, czyścić i wdrażać bezpośrednio z podów Kubernetes.
Aby zaimplementować tę funkcję, musisz najpierw mieć możliwość tworzenia rozproszonych obrazów (patrz punkt powyżej).
Wymaga również obsługi trybu działania konstruktora bez serwera Docker (tj. Kompilacja podobna do Kaniko lub kompilacja w przestrzeni użytkownika).
Werf będzie wspierać budowanie na Kubernetesie nie tylko za pomocą Dockerfile, ale także za pomocą kreatora Stapel z przebudową przyrostową i Ansible.
Krok w kierunku otwartego rozwoju
Kochamy naszą społeczność (, ) i chcemy, aby coraz więcej osób pomagało ulepszać Werf, rozumieć kierunek, w jakim zmierzamy i uczestniczyć w rozwoju.
Całkiem niedawno zdecydowano się na zmianę w celu ukazania procesu pracy naszego zespołu. Teraz możesz zobaczyć najbliższe plany, a także bieżące prace w następujących obszarach:
- ;
- ;
- ;
- .
Wiele pracy włożono w następujących kwestiach:
- Usunięto te nieistotne.
- Istniejące są sprowadzone do jednego formatu, z wystarczającą liczbą szczegółów i szczegółów.
- Dodano nowe zagadnienia z pomysłami i sugestiami.
Jak włączyć wersję v1.1
Wersja jest obecnie dostępna w (w kanałach stabilny и twardy jak skała publikacje pojawią się jednak, gdy nastąpi stabilizacja ea sam w sobie jest już wystarczająco stabilny do użycia, ponieważ przeszedł po kanałach alfa и beta). Aktywowany w następujący sposób:
source $(multiwerf use 1.1 ea)
werf COMMAND ...wniosek
Nowa architektura pamięci masowej Stage i optymalizacje konstruktorów dla konstruktorów Stapel i Dockerfile otwierają możliwość wdrażania rozproszonych i równoległych kompilacji w werf. Funkcje te pojawią się wkrótce w tej samej wersji v1.1 i staną się automatycznie dostępne poprzez mechanizm automatycznej aktualizacji (dla użytkowników ).
W tej wersji dodano strategię tagowania opartą na zawartości obrazu - tagowanie oparte na treści, która stała się strategią domyślną. Główny dziennik poleceń również został przerobiony: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Następnym znaczącym krokiem jest dodanie rozproszonych zestawów. Od wersji 1.0 kompilacje rozproszone stały się wyższym priorytetem niż kompilacje równoległe, ponieważ dodają większą wartość do werf: pionowe skalowanie kreatorów i obsługa efemerycznych kreatorów w różnych systemach CI/CD, a także możliwość oficjalnego wsparcia dla GitHub Actions . W związku z tym przesunięto terminy realizacji zgromadzeń równoległych. Pracujemy jednak nad jak najszybszym wdrożeniem obu możliwości.
Śledź wiadomości! I nie zapomnij odwiedzić nas o godz stworzyć problem, znaleźć istniejący i dodać plusa, stworzyć PR lub po prostu obserwować rozwój projektu.
PS
Przeczytaj także na naszym blogu:
- «»
- «";
- Seria notatek na temat innowacji w werfie:
- «";
- «";
- «";
- «".
Źródło: www.habr.com