Przepływ pracy ciągłej integracji/ciągłego wdrażania przy użyciu usługi GitOps — kubernetes z włączoną usługą Azure Arc

Ważne

Przepływ pracy opisany w tym dokumencie używa metodyki GitOps z platformą Flux w wersji 1. Usługa GitOps z rozwiązaniem Flux v2 jest teraz dostępna dla klastrów Kubernetes i Azure Kubernetes Service (AKS) z obsługą usługi Azure Arc; dowiedz się więcej o przepływie pracy ciągłej integracji/ciągłego wdrażania przy użyciu metodyki GitOps z rozwiązaniem Flux w wersji 2. Zalecamy jak najszybsze przeprowadzenie migracji do wersji Flux v2 .

Obsługa zasobów konfiguracji klastra opartych na platformie Flux w wersji 1 utworzonych przed 1 stycznia 2024 r. zakończy się 24 maja 2025 r. Od 1 stycznia 2024 r. nie będzie można utworzyć nowych zasobów konfiguracji klastra opartego na platformie Flux w wersji 1.

Nowoczesne wdrożenia platformy Kubernetes obsługują 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. Korzystając z typowych narzędzi Git do śledzenia stanu klastra, można zwiększyć odpowiedzialność, ułatwić badanie błędów i umożliwić automatyzację zarządzania środowiskami.

W tym omówieniu koncepcyjnym opisano metodykę GitOps jako rzeczywistość w pełnym cyklu życia zmian aplikacji przy użyciu usług Azure Arc, Azure Repos i Azure Pipelines. Przejdź do przykładu jednej zmiany aplikacji w środowiskach Kubernetes kontrolowanych przez usługę GitOps.

Architektura

Rozważ wdrożenie aplikacji w co najmniej jednym środowisku Kubernetes.

Repozytorium 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. Zmiany w tym repozytorium wywołują potok żądania ściągnięcia lub ciągłej integracji, który rozpoczyna proces wdrażania.

Container Registry

Rejestr kontenerów przechowuje wszystkie obrazy pierwszej i innej firmy używane w środowiskach Kubernetes. Tagowanie obrazów aplikacji pierwszej firmy przy użyciu tagów czytelnych dla człowieka i zatwierdzenia usługi Git użytego do skompilowania obrazu. Buforuj obrazy innych firm w celu zapewnienia bezpieczeństwa, szybkości i odporności. Ustaw plan na potrzeby terminowego testowania i integracji aktualizacji zabezpieczeń. Aby uzyskać więcej informacji, zobacz przewodnik dotyczący korzystania z usługi ACR i obsługi zawartości publicznej, aby zapoznać się z przykładem.

Potok żądania ściągnięcia

Żądania ściągnięcia do repozytorium aplikacji są bramowane po pomyślnym uruchomieniu 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 i rozszerza testy testowania i wdrażania. Potok można uruchomić dla każdego zatwierdzenia lub w regularnym tempie z grupą zatwierdzeń. Na tym etapie przeprowadź testowanie aplikacji, które jest zbyt długie dla potoku żądania ściągnięcia. Wypchnij obrazy platformy Docker do rejestru kontenerów po utworzeniu w ramach przygotowania do wdrożenia. Zastąpiony szablon można utworzyć podszewką z zestawem wartości testowych. Obrazy używane w czasie wykonywania usługi powinny być w tym momencie skompilowane, skompilowane i przetestowane. W szczególności w kompilacji ciągłej integracji artefakty są publikowane dla kroku ciągłego wdrażania do korzystania w ramach przygotowań do wdrożenia.

Flux

Flux to usługa, która działa w każdym klastrze i jest odpowiedzialna za utrzymanie żądanego stanu. Usługa często sonduje repozytorium GitOps pod kątem zmian w klastrze i stosuje je.

Potok ciągłego wdrażania

Potok ciągłego wdrażania jest wyzwalany automatycznie przez pomyślne kompilacje ciągłej integracji. Używa on wcześniej opublikowanych szablonów, zastępuje wartości środowiska i otwiera żądanie ściągnięcia do repozytorium GitOps w celu żądania zmiany żądanego stanu co najmniej jednego klastra Kubernetes. Administratorzy klastra przejrzyj żądanie ściągnięcia zmian stanu i zatwierdź scalanie z repozytorium GitOps. Następnie potok oczekuje na ukończenie żądania ściągnięcia, co umożliwia flux odebranie zmiany stanu.

Repozytorium GitOps

Repozytorium GitOps reprezentuje bieżący żądany stan wszystkich środowisk w klastrach. Każda zmiana tego repozytorium jest pobierana przez usługę Flux w każdym klastrze i wdrożona. Żądania ściągnięcia są tworzone ze zmianami żądanego stanu, przejrzenia i scalenia. Te żądania ściągnięcia zawierają zmiany zarówno w szablonach wdrażania, jak i w wynikowych renderowanych manifestach platformy Kubernetes. Manifesty renderowane na niskim poziomie umożliwiają bardziej ostrożną inspekcję zmian, które zwykle nie są widoczne na poziomie szablonu.

Klastry Kubernetes

Co najmniej jeden klaster Kubernetes z obsługą usługi Azure Arc 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.

Chociaż Alice wie, że aplikacja potrzebuje możliwości uruchamiania w wielu środowiskach, 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 w repozytorium aplikacji i otwiera żądanie ściągnięcia do przeglądu.
2. Alicja prosi jej zespół o przejrzenie zmiany.
   • Potok żądania ściągnięcia uruchamia walidację.
   • Po pomyślnym uruchomieniu potoku zespół wystartuje, a zmiana zostanie scalona.
3. Potok ciągłej integracji weryfikuje zmianę i pomyślnie kończy działanie Alicji.
   • Zmiana jest bezpieczna do wdrożenia w klastrze, a artefakty są zapisywane w przebiegu potoku ciągłej integracji.
4. Zmiana Alicji scala i wyzwala potok ciągłego wdrażania.
   • 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 etapuje wszelkie zmiany względem istniejącego stanu klastra w repozytorium GitOps.
   • Potok ciągłego wdrażania tworzy żądanie ściągnięcia do 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 flux zauważa 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.
7. Alice testuje punkt końcowy aplikacji, aby zweryfikować pomyślne ukończenie wdrożenia.

   Uwaga

   Aby uzyskać więcej ś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

Dowiedz się więcej o tworzeniu połączeń między klastrem a repozytorium Git jako zasobem konfiguracji przy użyciu platformy Kubernetes z obsługą usługi Azure Arc