Przepływ pracy CI/CD z wykorzystaniem 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/CD dla aplikacji wdrożonej w jednym lub kilku środowiskach Kubernetes.

Aby pobrać diagramy architektury w wysokiej rozdzielczości, odwiedź stronę Jumpstart Gems.

Repozytorium kodu aplikacji

Repozytorium aplikacji zawiera kod, nad którym deweloperzy pracują podczas wewnętrznego cyklu. 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ą PR lub potok CI, 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 zewnętrzne mogą być przechowywane w pamięci podręcznej w celach związanych z bezpieczeństwem, przyspieszenia działania i zwiększenia 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ą uzależnione od pomyślnego przejścia procesu weryfikacyjnego związanym z żądaniem ściągnięcia. Ten ciąg uruchamia podstawowe kontrole jakości, w tym analizę statyczną i testy jednostkowe na kodzie aplikacji. Pipeline testuje aplikację i przegląda pliki Dockerfile oraz szablony Helm używane do wdrażania w środowisku Kubernetes. Obrazy Docker powinny być kompilowane i testowane, ale nie przesyłane. Zachowaj czas trwania pipeline stosunkowo krótki, aby umożliwić szybką iterację.

Potok CI

Potok CI aplikacji uruchamia wszystkie kroki potoku PR, rozszerzając testy oraz kontrole wdrażania. Pipeline można uruchomić dla każdego zatwierdzenia do głównej gałęzi lub można go uruchomić w regularnych odstępach z grupą zatwierdzeń.

Na tym etapie można wykonywać testy aplikacji, które są zbyt czasochłonne dla pipeline'u CI/CD, w tym:

• Przesyłanie obrazów do rejestru kontenerów
• Budowanie obrazów, lintowanie i testowanie
• Generowanie szablonów nieprzetworzonych plików YAML

Pod koniec budowania CI generowane są artefakty. Te artefakty mogą być używane przez etap CD w przygotowaniu 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 CD jest automatycznie wyzwalany przez pomyślne kompilacje CI. W tym środowisku pipeline wartości specyficzne dla środowiska są wstawiane do wcześniej opublikowanych szablonów, a nowe żądanie ściągnięcia (pull request) jest zgłaszane do repozytorium GitOps z tymi wartościami. To żądanie ściągnięcia zawiera proponowane zmiany żądanego stanu co najmniej jednego klastra Kubernetes. Administratorzy klastra przejrzą pull request i zatwierdzą scalanie z repozytorium GitOps. Pipeline czeka na scalenie pull request, po czym Flux synchronizuje 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 pull requesty, które są następnie przeglądane i scalane po zatwierdzeniu zmian. Te pull requesty zawierają zmiany w szablonach wdrażania oraz wynikowe, renderowane manifesty 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 wprowadzania zmian do klastra Flux powiadamia łącznik GitOps o każdej zmianie fazy i sprawdzeniu kondycji przeprowadzanym. 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ę sukcesem, czy niepowodzeniem) łącznik powiadamia pipeline CD, aby 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ć zarówno środowisko deweloperskie, jak i QA w różnych przestrzeniach 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, przesyła go do zdalnej gałęzi o nazwie alice w repozytorium aplikacji i otwiera prośbę o połączenie do przeglądu względem gałęzi main.

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

   • Potok przetwarzania pull requestów uruchamia walidację.
   • Po pomyślnym uruchomieniu potoku PR i zatwierdzeniu przez zespół, zmiana zostaje scalona.

3. Następnie potok ciągłej integracji rozpoczyna się, weryfikuje zmianę Alice i pomyślnie się kończy.

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

4. Pomyślne uruchomienie potoku ciągłej integracji wyzwala potok ciągłego wdrażania.

   • Potok CD pobiera artefakty przechowywane przez proces CI Alicji.
   • Potok CD zastępuje szablony wartościami specyficznymi dla środowiska i przygotowuje wszelkie zmiany w odniesieniu do istniejącego stanu klastra w repozytorium GitOps.
   • Pipeline CD tworzy pull request do gałęzi produkcyjnej repozytorium GitOps z żądanymi zmianami stanu klastra.

5. Zespół Alice przegląda i zatwierdza jej pull request.

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

6. W ciągu kilku minut platforma Flux dostrzega zmianę w repozytorium GitOps i pobiera zmianę wprowadzoną przez Alicję.

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

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

   Uwaga / Notatka

   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.

Dalsze kroki

• Zapoznaj się z naszym samouczkiem implementacji CI/CD z GitOps.
• Dowiedz się więcej o tworzeniu połączeń między klastrem i repozytorium Git przy użyciu konfiguracji platformy Flux.