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

Ważne

Przepływ pracy opisany w tym dokumencie używa metodyki GitOps z rozwiązaniem Flux v1. Metodyka 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 v2. Zalecamy jak najszybszą migrację do platformy Flux w wersji 2 .

Obsługa zasobów konfiguracji klastra opartego na platformie Flux w wersji 1 utworzonego przed 1 maja 2023 r. zakończy się 24 maja 2025 r. Od 1 maja 2023 r. nie będzie można utworzyć nowych zasobów konfiguracji klastra opartych 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. Śledzenie stanu klastra przy użyciu typowych narzędzi Usługi Git pozwala 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 całym cyklu życia zmian aplikacji przy użyciu usług Azure Arc, Azure Repos i Azure Pipelines. Przejdź do przykładu pojedynczej zmiany aplikacji w środowiskach Kubernetes kontrolowanych przez metodykę GitOps.

Architektura

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

Architektura ciągłej integracji/ciągłego wdrażania usługi GitOps

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 firmowych przy użyciu tagów możliwych do odczytania przez człowieka i zatwierdzenia usługi Git użytego do skompilowania obrazu. Buforowanie obrazów 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 wdrożenia 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 rozwija 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 skonspilowania w ramach przygotowania do wdrożenia. Zastąpiony szablon można utworzyć z użyciem zestawu wartości testowych. Obrazy używane w środowisku uruchomieniowym usługi powinny być w tym momencie podszewkami, skompilowane i przetestowane. W szczególności w kompilacji ciągłej integracji artefakty są publikowane dla kroku ciągłego wdrażania do użytku w ramach przygotowania 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 zażądania zmiany żądanego stanu co najmniej jednego klastra Kubernetes. Administratorzy klastra przeglądają żądanie ściągnięcia zmian stanu i zatwierdzają scalanie z repozytorium GitOps. Następnie potok czeka 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 wdrażana. Żądania ściągnięcia są tworzone ze zmianami żądanego stanu, przejrzenia i scalenia. Te żądania ściągnięcia zawierają zmiany zarówno szablonów wdrożenia, jak i wynikowe renderowane manifesty platformy Kubernetes. Manifesty renderowane na niskim poziomie umożliwiają bardziej staranną inspekcję zmian, które zwykle nie są widoczne na poziomie szablonu.

Klastry Kubernetes

Co najmniej jeden klaster Kubernetes z włączoną usługą 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 Alice 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. Alice prosi jej zespół o przejrzenie zmiany.
    • Potok żądania ściągnięcia uruchamia walidację.
    • Po pomyślnym uruchomieniu potoku zespół wygasnie, a zmiana zostanie scalona.
  3. Potok ciągłej integracji weryfikuje zmianę Alicji i kończy się pomyślnie.
    • 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ż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.
  7. Alicja testuje punkt końcowy aplikacji, aby zweryfikować pomyślne ukończenie wdrożenia.

    Uwaga

    W przypadku większej liczby środowisk przeznaczonych do wdrożenia potok ciągłego wdrażania iteruje przez utworzenie żądania ściągnięcia dla następnego środowiska i powtarza kroki 4–7. Proces wielu wymaga dodatkowego zatwierdzenia w przypadku 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 włączoną usługą Azure Arc