GitOps to model operacyjny dla aplikacji natywnych dla chmury, który przechowuje kod aplikacji i deklaratywnej infrastruktury w usłudze Git, który ma być używany jako źródło prawdy do automatycznego ciągłego dostarczania. Za pomocą metodyki GitOps opisano żądany stan całego systemu w repozytorium git, a operator GitOps wdraża go w środowisku, który jest często klastrem Kubernetes. Aby uzyskać więcej informacji na temat metodyki GitOps dla platformy Kubernetes na platformie Azure, odwiedź stronę GitOps for Azure Kubernetes Service lub ci/CD and GitOps disciplines with Azure Arc-enabled Kubernetes (Metodyka GitOps dla usługi Azure Kubernetes lubciągłej integracji/ciągłego wdrażania i usługi GitOps z włączoną usługą Azure Arc).
Przykładowy scenariusz w tym artykule dotyczy firm, które chcą zmodernizować kompleksowe tworzenie aplikacji przy użyciu kontenerów, ciągłej integracji (CI) na potrzeby kompilacji i usługi GitOps na potrzeby ciągłego wdrażania (CD). W tym scenariuszu aplikacja Platformy Flask jest używana jako przykład. Ta aplikacja internetowa składa się z frontonu napisanego przy użyciu języka Python i platformy Flask.
Architektura
Poniższe opcje eksplorują podejścia oparte na wypychaniu i ciągłej integracji/ciągłego wdrażania oparte na ściąganiu.
Opcja 1. Wypychana ciągła integracja/ciągłe wdrażanie
Architektura oparta na wypychanie za pomocą funkcji GitHub Actions dla ciągłej integracji i ciągłego wdrażania.
Pobierz plik programu Visio z tą architekturą.
Przepływ danych
W tym scenariuszu opisano potok DevOps oparty na wypychanie dla dwuwarstwowej aplikacji internetowej ze składnikiem frontonu internetowego i zapleczem korzystającym z usługi Redis. Ten potok używa funkcji GitHub Actions do kompilowania i wdrażania. Dane przepływa przez scenariusz w następujący sposób:
- Kod aplikacji jest opracowywany.
- Kod aplikacji jest zatwierdzany w repozytorium GitHub git.
- Funkcja GitHub Actions tworzy obraz kontenera z kodu aplikacji i wypycha obraz kontenera do usługi Azure Container Registry.
- Zadanie funkcji GitHub Actions wdraża lub wypycha aplikację zgodnie z opisem w plikach manifestu do klastra usługi Azure Kubernetes Service (AKS) przy użyciu narzędzia kubectl lub akcji Wdróż w klastrze Kubernetes.
Opcja 2. Ciągła integracja/ciągłe wdrażanie oparte na ściąganiu (GitOps)
Architektura oparta na ściąganiu za pomocą funkcji GitHub Actions dla ciągłej integracji i ciągłego wdrażania Argo na potrzeby ciągłego wdrażania.
Pobierz plik programu Visio z tą architekturą.
Przepływ danych
W tym scenariuszu opisano potok DevOps oparty na ściąganiu dla dwuwarstwowej aplikacji internetowej z składnikiem frontonu internetowego i zapleczem korzystającym z usługi Redis. Ten potok używa funkcji GitHub Actions do kompilacji. W przypadku wdrożenia używa argo CD jako operatora GitOps do ściągania/synchronizowania aplikacji. Dane przepływa przez scenariusz w następujący sposób:
- Kod aplikacji jest opracowywany.
- Kod aplikacji jest zatwierdzany w repozytorium GitHub.
- Funkcja GitHub Actions tworzy obraz kontenera z kodu aplikacji i wypycha obraz kontenera do usługi Azure Container Registry.
- Funkcja GitHub Actions aktualizuje plik wdrożenia manifestu kubernetes z bieżącą wersją obrazu na podstawie numeru wersji obrazu kontenera w usłudze Azure Container Registry.
- Argo CD synchronizuje się z repozytorium Git lub ściąga z repozytorium Git.
- Usługa Argo CD wdraża aplikację w klastrze usługi AKS.
Elementy
- GitHub Actions to rozwiązanie automatyzacji, które może integrować się z usługami platformy Azure na potrzeby ciągłej integracji. W tym scenariuszu funkcja GitHub Actions organizuje tworzenie nowych obrazów kontenerów na podstawie zatwierdzeń kontroli źródła, wypycha te obrazy do usługi Azure Container Registry, a następnie aktualizuje pliki manifestu Kubernetes w repozytorium GitHub.
- Usługa Azure Kubernetes Service (AKS) to zarządzana platforma Kubernetes, która umożliwia wdrażanie konteneryzowanych aplikacji i zarządzanie nimi bez wiedzy na temat orkiestracji kontenerów. Jako hostowana usługa Kubernetes, platforma Azure obsługuje krytyczne zadania, takie jak monitorowanie kondycji i konserwacja.
- Usługa Azure Container Registry przechowuje obrazy kontenerów używane przez klaster usługi AKS i zarządza nimi. Obrazy są bezpiecznie przechowywane i mogą być replikowane do innych regionów przez platformę Azure, aby przyspieszyć czas wdrażania.
- GitHub to internetowy system kontroli źródła, który działa w usłudze Git i jest używany przez deweloperów do przechowywania i wersji kodu aplikacji. W tym scenariuszu usługa GitHub służy do przechowywania kodu źródłowego w repozytorium Git, a następnie funkcja GitHub Actions służy do wykonywania kompilacji i wypychania obrazu kontenera do usługi Azure Container Registry w podejściu opartym na wypychaniach.
- Argo CD to operator gitops typu open source, który integruje się z usługami GitHub i AKS. Argo CD obsługuje ciągłe wdrażanie (CD). Flux mógł być używany w tym celu, ale Argo CD pokazuje, jak zespół aplikacji może wybrać oddzielne narzędzie dla konkretnych problemów związanych z cyklem życia aplikacji, w porównaniu z użyciem tego samego narzędzia, które operatorzy klastrów używają do zarządzania klastrem.
- Usługa Azure Monitor pomaga śledzić wydajność, utrzymywać bezpieczeństwo i identyfikować trendy. Metryki uzyskane przez usługę Azure Monitor mogą być używane przez inne zasoby i narzędzia, takie jak Grafana.
Alternatywy
- Usługa Azure Pipelines ułatwia implementowanie ciągłej integracji/ciągłego wdrażania i potoku testowania dla dowolnej aplikacji.
- Jenkins to serwer automatyzacji typu open source, który może integrować się z usługami platformy Azure na potrzeby ciągłej integracji/ciągłego wdrażania.
- Flux może być używany jako operator GitOps. Może wykonywać te same zadania co argo CD i działa w taki sam sposób, jak w przypadku usługi AKS.
Szczegóły scenariusza
W tym scenariuszu zautomatyzowana kompilacja i wdrażanie aplikacji korzysta z kilku technologii. Kod jest opracowywany w programie VS Code i przechowywany w repozytorium GitHub. Funkcja GitHub Actions służy do kompilowania aplikacji jako kontenera, a następnie wypychania obrazu kontenera do usługi Azure Container Registry. Funkcja GitHub Actions służy do aktualizowania niezbędnego pliku wdrożenia manifestu kubernetes, przechowywanego również w repozytorium Git, podczas gdy operator Usługi GitOps Argo CD pobiera pliki manifestu Kubernetes z tego miejsca i wdraża aplikację w klastrze usługi AKS.
Inne przykłady obejmują udostępnianie zautomatyzowanego środowiska deweloperskiego, weryfikowanie nowych zatwierdzeń kodu i wypychanie nowych wdrożeń do środowisk przejściowych lub produkcyjnych. Tradycyjnie firmy musiały ręcznie kompilować i kompilować aplikacje i aktualizacje oraz obsługiwać dużą bazę kodu monolitycznego. Dzięki nowoczesnemu podejściu do tworzenia aplikacji korzystających z ciągłej integracji i metodyki GitOps na potrzeby ciągłego wdrażania można szybko tworzyć, testować i wdrażać usługi. To nowoczesne podejście umożliwia szybsze wydawanie aplikacji i aktualizacji klientom oraz reagowanie na zmieniające się wymagania biznesowe w bardziej elastyczny sposób.
Korzystając z usług azure i GitHub, takich jak AKS, Container Registry, GitHub i GitHub Actions, firmy mogą korzystać z najnowszych technik i narzędzi do tworzenia aplikacji, aby uprościć proces implementowania wysokiej dostępności. Ponadto dzięki zastosowaniu technologii open source, takich jak Flux lub Argo CD dla usługi GitOps, firmy upraszczają wdrażanie i wymuszają żądany stan aplikacji.
Potencjalne przypadki użycia
Inne istotne przypadki użycia to:
- Modernizowanie praktyk tworzenia aplikacji przez wdrożenie mikrousługi opartej na kontenerach.
- Przyspiesz tworzenie aplikacji i cykle życia wdrażania.
- Automatyzowanie wdrożeń w środowiskach testowych lub akceptacyjnych na potrzeby walidacji.
- Upewnij się, że konfiguracje i żądany stan aplikacji.
- Automatyzowanie zarządzania cyklem życia klastra.
Opcje ciągłej integracji/ciągłego wdrażania
W tym dokumencie przedstawiono użycie metodyki GitOps do nowoczesnego podejścia do obsługi ciągłego wdrażania w potoku ciągłej integracji/ciągłego wdrażania. Jednak każda organizacja jest inna. Podczas wdrażania aplikacji w klastrach Kubernetes za pomocą zautomatyzowanych potoków dostarczania ważne jest, aby zrozumieć różne sposoby ich wykonania.
Dwie najbardziej typowe opcje ciągłej integracji/ciągłego wdrażania aplikacji w klastrze usługi AKS to oparte na wypychanie i ściąganie. Opcja wypychania korzysta z funkcji GitHub Actions do ciągłego wdrażania, a opcja ściągania korzysta z metodyki GitOps na potrzeby ciągłego wdrażania.
Opcja 1. Architektura oparta na wypychanie za pomocą funkcji GitHub Actions dla ciągłej integracji i ciągłego wdrażania
W tym podejściu kod rozpoczyna się od części ciągłej integracji potoku, która działa w taki sposób, aby zmiany były wypychane jako wdrożenia do klastra Kubernetes. Wdrożenia są oparte na wyzwalaczu. Istnieją różne wyzwalacze, które mogą uruchamiać wdrożenie, na przykład zatwierdzenia do repozytorium lub wyzwalacza z innego potoku ciągłej integracji. Dzięki temu system potoku ma dostęp do klastra Kubernetes. Moduł oparty na wypychaniu jest obecnie najczęściej używanym modelem używanym przez narzędzia ciągłej integracji/ciągłego wdrażania.
Powody korzystania z podejścia opartego na wypychaniach:
Elastyczność: większość operatorów GitOps jest obecnie uruchamiana tylko w rozwiązaniu Kubernetes. Jeśli Organizacja chce wdrożyć aplikacje w niczym innym niż Kubernetes, musisz wypchnąć aplikację do tego środowiska za pomocą innych narzędzi ciągłej integracji/ciągłego wdrażania, takich jak gitHub Actions.
Wydajność: Standardowe podejście do wdrażania aplikacji natywnych dla chmury i tradycyjnych jest bardziej wydajne. Obecnie usługa GitOps najlepiej nadaje się do aplikacji natywnych dla chmury, które działają na platformie Kubernetes.
Prostota: Ciągła integracja/ciągłe wdrażanie oparte na wypychaniu jest dobrze znana wśród najszerszego zestawu inżynierów w wielu organizacjach. Podejście oparte na wypychaniu może być prostsze niż kombinacja metod ciągłej integracji/ciągłego wdrażania opartych na wypychaniach i ściągania.
Struktura: Bieżąca struktura repozytorium używana dla aplikacji może nie być odpowiednia dla metodyki GitOps, co oznacza, że konieczne będzie przeprowadzenie znaczącego planowania i restrukturyzacji w przypadku metodyki GitOps.
Opcja 2. Architektura oparta na ściąganiu za pomocą funkcji GitHub Actions dla ciągłej integracji i operatora GitOps Argo CD dla ciągłego wdrażania
To podejście koncentruje się wokół stosowania wszelkich zmian z wewnątrz klastra Kubernetes. Klaster Kubernetes zawiera operator, który skanuje repozytorium git pod kątem żądanego stanu klastra, odbierając i stosując wszelkie zmiany, które należy wprowadzić. W tym modelu żaden klient zewnętrzny nie ma poświadczeń na poziomie administratora w klastrze Kubernetes. Model ściągania nie jest nowy, ale nie był powszechnie używany przez narzędzia ciągłej integracji/ciągłego wdrażania. Ostatnio wraz z wprowadzeniem metodyki GitOps model ściągania zyskuje na wdrożeniu. Wiele organizacji korzysta z metodyki GitOps, aby ułatwić ciągłe wdrażanie w potokach ciągłego wdrażania/ciągłego wdrażania.
Powody korzystania z podejścia opartego na ściąganiu:
Spójność: W przypadku metodyki GitOps operator porównuje stan klastrów Kubernetes z żądanym stanem konfiguracji i aplikacji w repozytorium git. Jeśli istnieje dryf do konfiguracji lub aplikacji, operator GitOps automatycznie przywraca klaster Kubernetes do żądanego stanu.
Zabezpieczenia: podejście oparte na ściąganiu do ciągłej integracji/ciągłego wdrażania za pomocą metodyki GitOps umożliwia przeniesienie poświadczeń zabezpieczeń do klastra Kubernetes, co zmniejsza bezpieczeństwo i ryzyko, usuwając poświadczenia z przechowywania w zewnętrznym narzędziu ciągłej integracji. Będziesz również mieć możliwość zmniejszenia dozwolonych połączeń przychodzących i ograniczenia dostępu na poziomie administratora do klastrów Kubernetes.
Przechowywanie wersji: ponieważ usługa GitOps korzysta z repozytorium git jako źródła prawdy, ciągłe wdrażanie z natury ma możliwości przechowywania wersji, wycofywania i inspekcji.
Obsługa wielu dzierżaw: podejście oparte na ściąganiu za pomocą metodyki GitOps jest odpowiednie dla zespołów rozproszonych i wielu dzierżaw. Za pomocą metodyki GitOps można korzystać z oddzielnych repozytoriów git, oddzielnych praw dostępu i dystrybuować wdrożenia w różnych przestrzeniach nazw.
Natywny dla chmury: więcej aplikacji jest modernizowanych lub tworzonych jako natywne dla chmury. W przypadku każdej organizacji, która ma większość swoich aplikacji działających na platformie Kubernetes, użycie operatora GitOps na potrzeby ciągłego wdrażania jest prostsze i bardziej wydajne niż tradycyjne podejście oparte na wypychaniu do ciągłej integracji/ciągłego wdrażania.
Kwestie wymagające rozważenia
Te zagadnienia implementują filary struktury Azure Well-Architected Framework, która jest zestawem wytycznych, które mogą służyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Microsoft Azure Well-Architected Framework.
Niezawodność
Niezawodność zapewnia, że aplikacja może spełnić zobowiązania podjęte przez klientów. Aby uzyskać więcej informacji, zobacz Omówienie filaru niezawodności.
Aby monitorować wydajność aplikacji i zgłaszać problemy, ten scenariusz korzysta z usługi Azure Monitor. Umożliwia ona monitorowanie i rozwiązywanie problemów z wydajnością, które mogą wymagać aktualizacji kodu, które można następnie wdrożyć za pomocą potoku ciągłej integracji/ciągłego wdrażania.
W ramach klastra usługi AKS moduł równoważenia obciążenia dystrybuuje ruch aplikacji do co najmniej jednego kontenera lub zasobników, które uruchamiają aplikację. Takie podejście do uruchamiania konteneryzowanych aplikacji na platformie Kubernetes zapewnia klientom infrastrukturę o wysokiej dostępności.
Uwaga
Ten artykuł nie dotyczy bezpośrednio wysokiej dostępności potoku ciągłej integracji/ciągłego wdrażania. Aby uzyskać więcej informacji, odwiedź stronę Wysoka dostępność dla funkcji GitHub Actions i Deklaratywny dysk CD usługi GitOps argo CD dla platformy Kubernetes.
Składniki odporności są wbudowane w platformę Kubernetes. Te składniki monitorują i uruchamiają ponownie kontenery lub zasobniki, jeśli wystąpi problem. Po połączeniu wielu węzłów Kubernetes aplikacja może tolerować niedostępność zasobnika lub węzła.
Aby uzyskać ogólne wskazówki dotyczące projektowania odpornych rozwiązań, zobacz Projektowanie niezawodnych aplikacji platformy Azure.
Zabezpieczenia
Zabezpieczenia zapewniają ochronę przed celowymi atakami i nadużyciami cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Omówienie filaru zabezpieczeń.
W przypadku rozdzielenia poświadczeń i uprawnień w tym scenariuszu jest używana dedykowana jednostka usługi Microsoft Entra. Poświadczenia dla tej jednostki usługi są przechowywane jako bezpieczny obiekt poświadczeń w usłudze GitHub, jako wpisy tajne funkcji GitHub Actions, dzięki czemu nie są bezpośrednio widoczne i widoczne w skryptach ani w potoku kompilacji.
Aby uzyskać ogólne wskazówki dotyczące zabezpieczania aplikacji w klastrach usługi AKS, zobacz Pojęcia dotyczące zabezpieczeń aplikacji i klastrów w usłudze AKS.
W przypadku rozdzielenia problemów wskazówki polegają na oddzieleniu obliczeń, które uruchamiają aplikację biznesową od agentów ciągłego wdrażania lub operatora GitOps, uruchamiając aplikację biznesową i operator GitOps w oddzielnych przestrzeniach nazw w klastrze Kubernetes. W celu dalszego rozdzielenia problemów operator GitOps może być uruchamiany w klastrze Kubernetes przeznaczonym dla wystąpienia usługi GitOps niezależnie od produkcyjnego klastra Kubernetes, który uruchamia aplikację biznesową.
Uwaga
W tym artykule nie opisano bezpośrednio sposobu zabezpieczania potoku ciągłej integracji/ciągłego wdrażania.
Efektywność wydajności
Efektywność wydajności to możliwość skalowania obciążenia w celu zaspokojenia zapotrzebowania użytkowników w wydajny sposób. Aby uzyskać więcej informacji, zobacz Omówienie filaru wydajności.
Usługa AKS umożliwia skalowanie liczby węzłów klastra w celu spełnienia wymagań aplikacji. W miarę zwiększania się aplikacji można skalować w górę liczbę węzłów Kubernetes, które uruchamiają usługę.
Dzięki funkcji GitHub Actions dostawca usług w chmurze automatycznie skaluje liczbę modułów uruchamiaczy. Jeśli są używane własne moduły uruchamiającego, host modułu uruchamiającego będzie odpowiedzialny za skalowanie ich zgodnie z potrzebami.
Aby zapoznać się z innymi tematami dotyczącymi skalowalności, zobacz listę kontrolną wydajności wydajności.
Wdrażanie tego scenariusza
Wykonaj kroki opisane w implementacji referencyjnej automatyzacji punktu odniesienia usługi AKS, aby wdrożyć scenariusz. Repozytorium implementacji referencyjnej zawiera przewodniki z przewodnikiem dotyczące scenariusza ciągłej integracji/ciągłego wdrażania opartego na wypychaniu oraz scenariusza ciągłej integracji/ciągłego wdrażania (GitOps).
Współautorzy
Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.
Autorzy zabezpieczeń:
- Steve Buchanan | Główny menedżer programu
Inni współautorzy:
- Ayobami Ayodeji | Starszy menedżer programu
- Bahram Rushenas | Starszy architekt
Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.
Następne kroki
W tym scenariuszu użyto usługi Azure Container Registry i usługi AKS do przechowywania i uruchamiania aplikacji opartej na kontenerze. Usługi Azure Container Apps lub Azure Container Instances mogą być również używane do uruchamiania aplikacji opartych na kontenerach bez konieczności aprowizowania żadnych składników aranżacji. Aby uzyskać więcej informacji, zobacz Omówienie usługi Azure Container Instances i Omówienie usługi Azure Container Apps.
Dokumentacja produktu:
- Azure Kubernetes Service
- Omówienie usługi Azure Monitor
- Maszyny wirtualne z systemem Linux na platformie Azure
- Prywatne rejestry kontenerów platformy Docker na platformie Azure
- Pojęcia dotyczące zabezpieczeń aplikacji i klastrów w usłudze AKS
- Akcelerator strefy docelowej usługi AKS
Moduły microsoft Learn:
- Tworzenie konteneryzowanej aplikacji internetowej przy użyciu platformy Docker
- Wdrażanie konteneryzowanej aplikacji w usłudze Azure Kubernetes Service
- Implementowanie usługi Azure Kubernetes Service (AKS)
- Monitorowanie użycia, wydajności i dostępności zasobów za pomocą usługi Azure Monitor
Powiązane zasoby
- Architektura linii bazowej dla klastra usługi AKS
- Strategia GitOps dla usługi Azure Kubernetes Service
- Ciągła integracja/ciągłe wdrażanie dla architektur mikrousług
- Potok ciągłej integracji/ciągłego wdrażania dla obciążeń opartych na kontenerach
- Tworzenie potoku ciągłej integracji/ciągłego wdrażania dla mikrousług w usłudze Kubernetes
- Zaawansowana architektura mikrousług usługi AKS