Przepływ pracy ciągłej integracji/ciągłego wdrażania przy użyciu metodyki GitOps (Flux v2)

Nowoczesne wdrożenia kubernetes zawierają wiele aplikacji, klastrów i środowisk. Za pomocą metodyki GitOps można łatwiej zarządzać tymi złożonymi konfiguracjami, śledząc żądany stan środowisk Kubernetes deklaratywnie za pomocą usługi Git. Za pomocą typowych narzędzi Git do deklarowania stanu klastra można zwiększyć odpowiedzialność, ułatwić badanie błędów i włączyć automatyzację do zarządzania środowiskami.

W tym artykule opisano sposób dopasowania metodyki GitOps do pełnego cyklu życia zmian aplikacji przy użyciu usług Azure Arc, Azure Repos i Azure Pipelines. Zawiera również przykład jednej zmiany aplikacji w środowiskach Kubernetes kontrolowanych przez usługę GitOps.

Architektura

Ten diagram przedstawia przepływ pracy ciągłej integracji/ciągłego wdrażania dla aplikacji wdrożonej w co najmniej jednym środowisku Kubernetes.

Repozytorium kodu aplikacji

Repozytorium aplikacji zawiera kod aplikacji, nad którym deweloperzy pracują podczas ich wewnętrznej pętli. Szablony wdrażania aplikacji działają w tym repozytorium w postaci ogólnej, takiej jak Helm lub Kustomize. Wartości specyficzne dla środowiska nie są przechowywane w repozytorium.

Zmiany w tym repozytorium wywołują potok żądania ściągnięcia lub ciągłej integracji, który rozpoczyna proces wdrażania.

Rejestr kontenerów

Rejestr kontenerów przechowuje wszystkie obrazy pierwszej i innej firmy używane w środowiskach Kubernetes. Obrazy aplikacji innych firm są oznaczane tagami czytelnymi dla człowieka i zatwierdzeniem usługi Git używanym do kompilowania obrazu. Obrazy innych firm mogą być buforowane w celu ułatwienia bezpieczeństwa, szybkości i odporności. Ustaw plan na potrzeby terminowego testowania i integracji aktualizacji zabezpieczeń.

Aby uzyskać więcej informacji, zobacz How to consume and maintain public content with Azure Container Registry Tasks (Jak używać i obsługiwać zawartość publiczną za pomocą zadań usługi Azure Container Registry).

Potok żądania ściągnięcia

Żądania ściągnięcia od deweloperów wysyłane do repozytorium aplikacji są kierowane do pomyślnego uruchomienia potoku żądania ściągnięcia. Ten potok uruchamia podstawowe bramy jakości, takie jak linting i testy jednostkowe w kodzie aplikacji. Potok testuje aplikację i lints Dockerfiles i szablony helm używane do wdrażania w środowisku Kubernetes. Obrazy platformy Docker powinny być kompilowane i testowane, ale nie wypychane. Zachowaj czas trwania potoku stosunkowo krótki, aby umożliwić szybką iterację.

Potok ciągłej integracji

Potok ciągłej integracji aplikacji uruchamia wszystkie kroki potoku żądania ściągnięcia, rozszerzając testy testowania i wdrażania. Potok można uruchomić dla każdego zatwierdzenia głównego lub można go uruchomić w regularnym tempie z grupą zatwierdzeń.

Na tym etapie można wykonywać testy aplikacji, które są zbyt czasochłonne dla potoku żądania ściągnięcia, w tym:

• Wypychanie obrazów do rejestru kontenerów
• Kompilowanie obrazów, podszewka i testowanie
• Generowanie szablonów nieprzetworzonych plików YAML

Po zakończeniu kompilacji ciągłej integracji są generowane artefakty. Te artefakty mogą być używane przez krok ciągłego wdrażania do użycia w ramach przygotowań do wdrożenia.

Rozszerzenie klastra Flux

Flux to agent, który działa w każdym klastrze jako rozszerzenie klastra. To rozszerzenie klastra Flux jest odpowiedzialne za utrzymanie żądanego stanu. Agent sonduje repozytorium GitOps w interwale zdefiniowanym przez użytkownika, a następnie uzgadnia stan klastra ze stanem zadeklarowanym w repozytorium Git.

Aby uzyskać więcej informacji, zobacz Samouczek: wdrażanie aplikacji przy użyciu metodyki GitOps z platformą Flux w wersji 2.

Potok ciągłego wdrażania

Potok ciągłego wdrażania jest wyzwalany automatycznie przez pomyślne kompilacje ciągłej integracji. W tym środowisku potoku wartości specyficzne dla środowiska są zastępowane wcześniej opublikowanymi szablonami, a nowe żądanie ściągnięcia jest wywoływane względem repozytorium GitOps z tymi wartościami. To żądanie ściągnięcia zawiera proponowane zmiany żądanego stanu co najmniej jednego klastra Kubernetes. Administratorzy klastra przejrzyj żądanie ściągnięcia i zatwierdź scalanie z repozytorium GitOps. Potok czeka na scalenie żądania ściągnięcia, po którym platforma Flux synchronizuje się i stosuje zmiany stanu.

Repozytorium GitOps

Repozytorium GitOps reprezentuje bieżący żądany stan wszystkich środowisk w klastrach. Każda zmiana w tym repozytorium jest pobierana przez usługę Flux w każdym klastrze i wdrożona. Zmiany żądanego stanu klastrów są prezentowane jako żądania ściągnięcia, które są następnie przeglądane, a następnie scalane po zatwierdzeniu zmian. Te żądania ściągnięcia zawierają zmiany w szablonach wdrażania i wynikowe renderowane manifesty platformy Kubernetes. Manifesty renderowane na niskim poziomie umożliwiają bardziej ostrożną inspekcję zmian, które zwykle nie są widoczne na poziomie szablonu.

Łącznik GitOps

Łącznik GitOps tworzy połączenie między agentem Flux i potokiem GitOps Repository/CD. Podczas stosowania zmian do klastra usługa Flux powiadamia łącznik GitOps o każdej zmianie fazy i sprawdzeniu kondycji. Ten składnik służy jako adapter. Rozumie on, jak komunikować się z repozytorium Git i aktualizuje stan zatwierdzenia Git, aby postęp synchronizacji był widoczny w repozytorium GitOps. Po zakończeniu wdrażania (niezależnie od tego, czy zakończy się powodzeniem, czy niepowodzeniem), łącznik powiadamia potok ciągłego wdrażania, aby potok mógł wykonywać działania po wdrożeniu, takie jak testowanie integracji.

Klastry Kubernetes

Co najmniej jeden klaster Kubernetes z obsługą usługi Azure Arc lub Azure Kubernetes Service (AKS) obsługuje różne środowiska wymagane przez aplikację. Na przykład pojedynczy klaster może obsługiwać środowisko deweloperskie i qa za pośrednictwem różnych przestrzeni nazw. Drugi klaster może zapewnić łatwiejsze rozdzielenie środowisk i bardziej szczegółową kontrolę.

Przykładowy przepływ pracy

Jako deweloper aplikacji Alice:

• Zapisuje kod aplikacji.
• Określa sposób uruchamiania aplikacji w kontenerze platformy Docker.
• Definiuje szablony, które uruchamiają kontener i usługi zależne w klastrze Kubernetes.

Alicja chce upewnić się, że aplikacja ma możliwość uruchamiania w wielu środowiskach, ale nie zna określonych ustawień dla każdego środowiska.

Załóżmy, że Alicja chce wprowadzić zmianę aplikacji, która zmienia obraz platformy Docker używany w szablonie wdrażania aplikacji.

1. Alicja zmienia szablon wdrożenia, wypycha go do gałęzi zdalnej o nazwie alice w repozytorium aplikacji i otwiera żądanie ściągnięcia do przeglądu względem main gałęzi.

2. Alicja prosi jej zespół o przejrzenie zmiany.

   • Potok żądania ściągnięcia uruchamia walidację.
   • Po pomyślnym uruchomieniu potoku żądania ściągnięcia i zatwierdzeniu przez zespół zmiany zostaną scalone.

3. Następnie potok ciągłej integracji rozpoczyna się i weryfikuje zmianę i pomyślne zakończenie alice.

   • Zmiana jest bezpieczna do wdrożenia w klastrze, a artefakty są zapisywane w przebiegu potoku ciągłej integracji.

4. Pomyślne uruchomienie potoku ciągłej integracji wyzwala potok ciągłej integracji.

   • Potok ciągłego wdrażania pobiera artefakty przechowywane przez przebieg potoku ciągłej integracji Alicji.
   • Potok ciągłego wdrażania zastępuje szablony wartościami specyficznymi dla środowiska i etapami wszelkich zmian w istniejącym stanie klastra w repozytorium GitOps.
   • Potok ciągłego wdrażania tworzy żądanie ściągnięcia względem gałęzi produkcyjnej repozytorium GitOps z żądanymi zmianami stanu klastra.

5. Zespół Alice przegląda i zatwierdza jej żądanie ściągnięcia.

   • Zmiana jest scalona z gałęzią docelową odpowiadającą środowisku.

6. W ciągu kilku minut platforma Flux zauważy zmianę w repozytorium GitOps i ściąga zmianę Alicji.

   • Ze względu na zmianę obrazu platformy Docker zasobnik aplikacji wymaga aktualizacji.
   • Flux stosuje zmianę do klastra.
   • Platforma Flux zgłasza stan wdrożenia z powrotem do repozytorium GitOps za pośrednictwem łącznika GitOps.

7. Potok ciągłego wdrażania uruchamia testy automatyczne, aby sprawdzić, czy nowe wdrożenie zostało pomyślnie ukończone i działa zgodnie z oczekiwaniami.

   Uwaga

   W przypadku dodatkowych środowisk przeznaczonych do wdrożenia potok ciągłego wdrażania iteruje, tworząc żądanie ściągnięcia dla następnego środowiska i powtarza kroki 4–7. Proces wielu wymaga dodatkowego zatwierdzenia dla bardziej ryzykownych wdrożeń lub środowisk, takich jak zmiana związana z zabezpieczeniami lub środowisko produkcyjne.

8. Po pomyślnym wdrożeniu wszystkich środowisk potok zostanie ukończony.

Następne kroki

• Zapoznaj się z naszym samouczkiem, aby zaimplementować ciągłą integrację/ciągłe wdrażanie za pomocą metodyki GitOps.
• Dowiedz się więcej o tworzeniu połączeń między klastrem i repozytorium Git przy użyciu konfiguracji platformy Flux.