Samouczek: implementowanie ciągłej integracji/ciągłego wdrażania za pomocą usługi GitOps przy użyciu klastrów Kubernetes z obsługą usługi Azure Arc

  • Artykuł

Ważne

W tym samouczku jest używana usługa GitOps z rozwiązaniem 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; Przejdź do samouczka korzystającego z 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.

W tym samouczku skonfigurujesz rozwiązanie ciągłej integracji/ciągłego wdrażania przy użyciu metodyki GitOps z klastrami Kubernetes z włączoną usługą Azure Arc. Korzystając z przykładowej aplikacji Azure Vote, wykonasz następujące elementy:

  • Utwórz klaster Kubernetes z włączoną usługą Azure Arc.
  • Połączenie repozytoriów aplikacji i repozytoriów GitOps do usługi Azure Repos.
  • Zaimportuj potoki ciągłej integracji/ciągłego wdrażania.
  • Połączenie usługi Azure Container Registry (ACR) do usług Azure DevOps i Kubernetes.
  • Utwórz grupy zmiennych środowiskowych.
  • dev Wdrażanie środowisk istage.
  • Przetestuj środowiska aplikacji.

Jeśli nie masz subskrypcji platformy Azure, przed rozpoczęciem utwórz bezpłatne konto.

Azure Cloud Shell

Na platforma Azure hostowane jest Azure Cloud Shell, interaktywne środowisko powłoki, z którego można korzystać w przeglądarce. Do pracy z usługami platformy Azure można używać programu Bash lub PowerShell w środowisku Cloud Shell. Aby uruchomić kod w tym artykule, możesz użyć wstępnie zainstalowanych poleceń usługi Cloud Shell bez konieczności instalowania niczego w środowisku lokalnym.

Aby uruchomić środowisko Azure Cloud Shell:

Opcja Przykład/link
Wybierz pozycję Wypróbuj w prawym górnym rogu bloku kodu lub polecenia. Wybranie pozycji Wypróbuj nie powoduje automatycznego skopiowania kodu lub polecenia do usługi Cloud Shell. Screenshot that shows an example of Try It for Azure Cloud Shell.
Przejdź do witryny https://shell.azure.com lub wybierz przycisk Uruchom Cloud Shell, aby otworzyć środowisko Cloud Shell w przeglądarce. Button to launch Azure Cloud Shell.
Wybierz przycisk Cloud Shell na pasku menu w prawym górnym rogu witryny Azure Portal. Screenshot that shows the Cloud Shell button in the Azure portal

Aby użyć usługi Azure Cloud Shell:

  1. Uruchom usługę Cloud Shell.

  2. Wybierz przycisk Kopiuj w bloku kodu (lub bloku poleceń), aby skopiować kod lub polecenie.

  3. Wklej kod lub polecenie do sesji usługi Cloud Shell, wybierając klawisze Ctrl+Shift V w systemach Windows i Linux lub wybierając pozycję Cmd+Shift++V w systemie macOS.

  4. Wybierz klawisz Enter, aby uruchomić kod lub polecenie.

Zanim rozpoczniesz

W tym samouczku założono, że znajomość usług Azure DevOps, Azure Repos i Pipelines oraz interfejsu wiersza polecenia platformy Azure.

Importowanie repozytoriów aplikacji i repozytoriów GitOps do usługi Azure Repos

Zaimportuj repozytorium aplikacji i repozytorium GitOps do usługi Azure Repos. Na potrzeby tego samouczka użyj następujących przykładowych repozytoriów:

Dowiedz się więcej na temat importowania repozytoriów Git.

Uwaga

Importowanie i używanie dwóch oddzielnych repozytoriów dla repozytoriów aplikacji i repozytoriów GitOps może poprawić bezpieczeństwo i prostotę. Uprawnienia i widoczność repozytoriów GitOps aplikacji i repozytoriów GitOps można dostroić indywidualnie. Na przykład administrator klastra może nie znaleźć zmian w kodzie aplikacji odpowiednich dla żądanego stanu klastra. Z drugiej strony deweloper aplikacji nie musi znać określonych parametrów dla każdego środowiska — zestaw wartości testowych zapewniających pokrycie parametrów może być wystarczający.

Połączenie repozytorium GitOps

Aby stale wdrażać aplikację, połącz repozytorium aplikacji z klastrem przy użyciu metodyki GitOps. Repozytorium GitOps arc-cicd-demo-gitops zawiera podstawowe zasoby, które umożliwiają uruchomienie aplikacji w klastrze arc-cicd-cluster .

Początkowe repozytorium GitOps zawiera tylko manifest , który tworzy przestrzenie nazw deweloperskich i etapowych odpowiadających środowisku wdrażania.

Utworzone połączenie GitOps spowoduje automatyczne:

  • Zsynchronizuj manifesty w katalogu manifestu.
  • Zaktualizuj stan klastra.

Przepływ pracy ciągłej integracji/ciągłego wdrażania wypełni katalog manifestu dodatkowymi manifestami w celu wdrożenia aplikacji.

  1. Utwórz nowe połączenie GitOps z nowo zaimportowanym repozytorium arc-cicd-demo-gitops w usłudze Azure Repos.

    az k8s-configuration create \
   --name cluster-config \
   --cluster-name arc-cicd-cluster \
   --resource-group myResourceGroup \
   --operator-instance-name cluster-config \
   --operator-namespace cluster-config \
   --repository-url https://dev.azure.com/<Your organization>/<Your project>/_git/arc-cicd-demo-gitops \
   --https-user <Azure Repos username> \
   --https-key <Azure Repos PAT token> \
   --scope cluster \
   --cluster-type connectedClusters \
   --operator-params='--git-readonly --git-path=arc-cicd-cluster/manifests'

  2. Upewnij się, że platforma Flux używa arc-cicd-cluster/manifests tylko katalogu jako ścieżki podstawowej. Zdefiniuj ścieżkę przy użyciu następującego parametru operatora:

    --git-path=arc-cicd-cluster/manifests

    Uwaga

    Jeśli używasz parametry połączenia HTTPS i masz problemy z połączeniem, upewnij się, że pominięto prefiks nazwy użytkownika w adresie URL. Na przykład https://alice@dev.azure.com/contoso/project/_git/arc-cicd-demo-gitops musi zostać alice@ usunięty. Parametr --https-user określa użytkownika, na przykład --https-user alice.

  3. Sprawdź stan wdrożenia w witrynie Azure Portal.

    • W przypadku powodzenia zobaczysz zarówno przestrzenie nazw, jak dev i stage utworzone w klastrze.

Importowanie potoków ciągłej integracji/ciągłego wdrażania

Po zsynchronizowaniu połączenia GitOps należy zaimportować potoki ciągłej integracji/ciągłego wdrażania, które tworzą manifesty.

Repozytorium aplikacji zawiera .pipeline folder z potokami, których będziesz używać w przypadku żądania ściągnięcia, ciągłej integracji i ciągłego wdrażania. Zaimportuj i zmień nazwę trzech potoków dostępnych w repozytorium przykładowym:

Nazwa pliku potoku opis
.pipelines/az-vote-pr-pipeline.yaml Potok żądania ściągnięcia aplikacji o nazwie arc-cicd-demo-src PR
.pipelines/az-vote-ci-pipeline.yaml Potok ciągłej integracji aplikacji o nazwie arc-cicd-demo-src CI
.pipelines/az-vote-cd-pipeline.yaml Potok ciągłego wdrażania aplikacji o nazwie arc-cicd-demo-src CD

Połączenie usługi ACR

Zarówno potoki, jak i klaster będą używać usługi ACR do przechowywania i pobierania obrazów platformy Docker.

Połączenie usługi ACR do usługi Azure DevOps

Podczas procesu ciągłej integracji wdrożysz kontenery aplikacji w rejestrze. Zacznij od utworzenia połączenia z usługą platformy Azure:

  1. W usłudze Azure DevOps otwórz stronę Połączenia z usługą na stronie ustawień projektu. W programie TFS otwórz stronę Usługi z ikony ustawień na górnym pasku menu.
  2. Wybierz pozycję + Nowe połączenie z usługą i wybierz typ potrzebnego połączenia usługi.
  3. Wypełnij parametry połączenia z usługą. Na potrzeby tego samouczka:
    • Nadaj połączeniu usługi nazwę arc-demo-acr.
    • Wybierz grupę zasobów myResourceGroup .
  4. Wybierz uprawnienie Udziel dostępu do wszystkich potoków.
    • Ta opcja autoryzuje pliki potoków YAML dla połączeń usług.
  5. Wybierz przycisk OK , aby utworzyć połączenie.

Połączenie ACR do platformy Kubernetes

Włącz klaster Kubernetes w celu ściągania obrazów z usługi ACR. Jeśli jest to prywatne, wymagane będzie uwierzytelnianie.

Połączenie usługi ACR do istniejących klastrów usługi AKS

Zintegruj istniejącą usługę ACR z istniejącymi klastrami usługi AKS przy użyciu następującego polecenia:

az aks update -n arc-cicd-cluster -g myResourceGroup --attach-acr arc-demo-acr

Tworzenie wpisu tajnego ściągania obrazu

Aby połączyć klastry inne niż AKS i lokalne z usługą ACR, utwórz wpis tajny ściągania obrazu. Platforma Kubernetes używa wpisów tajnych ściągania obrazu do przechowywania informacji potrzebnych do uwierzytelniania rejestru.

Utwórz wpis tajny ściągania obrazu za pomocą następującego kubectl polecenia. Powtórz zarówno dla przestrzeni nazw, jak dev i stage .

kubectl create secret docker-registry <secret-name> \
    --namespace <namespace> \
    --docker-server=<container-registry-name>.azurecr.io \
    --docker-username=<service-principal-ID> \
    --docker-password=<service-principal-password>

Aby uniknąć konieczności ustawiania obrazuPullSecret dla każdego zasobnika, rozważ dodanie obrazuPullSecret do konta usługi w dev przestrzeniach nazw i stage . Aby uzyskać więcej informacji, zobacz samouczek dotyczący platformy Kubernetes.

Tworzenie grup zmiennych środowiskowych

Grupa zmiennych repozytorium aplikacji

Utwórz grupę zmiennych o nazwie az-vote-app-dev. Ustaw następujące wartości:

Zmienna Wartość
AZ_ACR_NAME (twoje wystąpienie usługi ACR, na przykład azurearctest.azurecr.io)
AZURE_SUBSCRIPTION (twoja Połączenie usługi platformy Azure, która powinna być arc-demo-acr z wcześniejszej wersji samouczka)
AZURE_VOTE_IMAGE_REPO Pełna ścieżka do repozytorium aplikacji Azure Vote App, na przykład azurearctest.azurecr.io/azvote
ENVIRONMENT_NAME Deweloper
MANIFESTS_BRANCH master
MANIFESTS_FOLDER azure-vote-manifests
MANIFESTS_REPO arc-cicd-demo-gitops
ORGANIZATION_NAME Nazwa organizacji usługi Azure DevOps
PROJECT_NAME Nazwa projektu GitOps w usłudze Azure DevOps
REPO_URL Pełny adres URL repozytorium GitOps
SRC_FOLDER azure-vote
TARGET_CLUSTER arc-cicd-cluster
TARGET_NAMESPACE dev

Etap grupy zmiennych środowiskowych

  1. Sklonuj grupę zmiennych az-vote-app-dev .
  2. Zmień nazwę na az-vote-app-stage.
  3. Upewnij się, że następujące wartości dla odpowiednich zmiennych:
Zmienna Wartość
ENVIRONMENT_NAME Etap
TARGET_NAMESPACE stage

Teraz możesz przystąpić do wdrażania w dev środowiskach i stage .

Nadaj więcej uprawnień usłudze kompilacji

Potok ciągłego wdrażania używa tokenu zabezpieczającego uruchomionej kompilacji do uwierzytelniania w repozytorium GitOps. Do utworzenia nowej gałęzi, wypychania zmian i tworzenia żądań ściągnięcia potrzebnych jest więcej uprawnień potoku.

  1. Przejdź do Project settings strony głównej projektu DevOps platformy Azure.
  2. Wybierz opcję Repositories.
  3. Wybierz opcję <GitOps Repo Name>.
  4. Wybierz opcję Security.
  5. W przypadku elementu <Project Name> Build Service (<Organization Name>)zezwalaj na Contributewartości , i Contribute to pull requestsCreate branch.

Aby uzyskać więcej informacji, zobacz:

Wdrażanie środowiska deweloperskiego po raz pierwszy

Po utworzeniu potoków ciągłej integracji i ciągłego wdrażania uruchom potok ciągłej integracji, aby wdrożyć aplikację po raz pierwszy.

Potok ciągłej integracji

Podczas początkowego uruchomienia potoku ciągłej integracji może wystąpić błąd autoryzacji zasobów podczas odczytywania nazwy połączenia z usługą.

  1. Sprawdź, czy uzyskiwany dostęp do zmiennej jest AZURE_SUBSCRIPTION.
  2. Autoryzowanie użycia.
  3. Uruchom ponownie potok.

Potok ciągłej integracji:

  • Zapewnia, że zmiana aplikacji przechodzi wszystkie zautomatyzowane kontrole jakości wdrożenia.
  • Czy nie można ukończyć dodatkowej weryfikacji w potoku żądania ściągnięcia.
    • Specyficzny dla usługi GitOps potok publikuje również artefakty dla zatwierdzenia, które zostaną wdrożone przez potok ciągłego wdrażania.
  • Sprawdza, czy obraz platformy Docker został zmieniony, a nowy obraz jest wypychany.

Potok ciągłego wdrażania

Podczas początkowego uruchomienia potoku ciągłego wdrażania zostanie wyświetlony monit o udzielenie potokowi dostępu do repozytorium GitOps. Po wyświetleniu monitu wybierz pozycję Wyświetl, aby potok potrzebował uprawnień dostępu do zasobu. Następnie wybierz pozycję Zezwól, aby udzielić uprawnień do używania repozytorium GitOps dla bieżących i przyszłych uruchomień potoku.

Pomyślne uruchomienie potoku ciągłej integracji wyzwala potok ciągłej integracji w celu ukończenia procesu wdrażania. Wdrożysz w każdym środowisku przyrostowo.

Napiwek

Jeśli potok ciągłego wdrażania nie jest wyzwalany automatycznie:

  1. Sprawdź, czy nazwa jest zgodna z wyzwalaczem gałęzi w .pipelines/az-vote-cd-pipeline.yaml
    • Powinna ona mieć wartość arc-cicd-demo-src CI.
  2. Uruchom ponownie potok ciągłej integracji.

Po wygenerowaniu szablonu i manifestu w repozytorium GitOps potok ciągłego wdrażania utworzy zatwierdzenie, wypchnie je i utworzy żądanie ściągnięcia do zatwierdzenia.

  1. Otwórz link żądania ściągnięcia podany w danych wyjściowych Create PR zadania.

  2. Sprawdź zmiany w repozytorium GitOps. Powinien zostać wyświetlony następujący ekran:

    • Zmiany szablonu programu Helm wysokiego poziomu.
    • Manifesty platformy Kubernetes niskiego poziomu, które pokazują podstawowe zmiany w żądanym stanie. Flux wdraża te manifesty.

  3. Jeśli wszystko wygląda dobrze, zatwierdź i ukończ żądanie ściągnięcia.

  4. Po kilku minutach platforma Flux pobiera zmianę i uruchamia wdrożenie.

  5. Przekaż port lokalnie przy użyciu polecenia kubectl i upewnij się, że aplikacja działa prawidłowo przy użyciu:

    kubectl port-forward -n dev svc/azure-vote-front 8080:80

  6. Wyświetl aplikację Azure Vote w przeglądarce pod adresem http://localhost:8080/.

  7. Zagłosuj na ulubione i przygotuj się, aby wprowadzić pewne zmiany w aplikacji.

Konfigurowanie zatwierdzeń środowiska

Podczas wdrażania aplikacji można nie tylko wprowadzać zmiany w kodzie lub szablonach, ale także przypadkowo umieścić klaster w złym stanie.

Jeśli środowisko deweloperskie ujawni przerwę po wdrożeniu, należy zachować możliwość przechodzenia do późniejszych środowisk przy użyciu zatwierdzeń środowiska.

  1. W projekcie usługi Azure DevOps przejdź do środowiska, które musi być chronione.
  2. Przejdź do Zatwierdzenia i sprawdź, czy zasób jest sprawdzany.
  3. Wybierz pozycję Utwórz.
  4. Podaj osoby zatwierdzające i opcjonalny komunikat.
  5. Wybierz ponownie pozycję Utwórz , aby ukończyć dodawanie sprawdzania ręcznego zatwierdzania.

Aby uzyskać więcej informacji, zobacz samouczek Definiowanie zatwierdzenia i sprawdzania .

Przy następnym uruchomieniu potoku ciągłego wdrażania potok zostanie wstrzymany po utworzeniu żądania ściągnięcia usługi GitOps. Sprawdź, czy zmiana została prawidłowo zsynchronizowana i przekazuje podstawowe funkcje. Zatwierdź sprawdzanie z potoku, aby umożliwić zmianę przepływu do następnego środowiska.

Wprowadzanie zmian w aplikacji

W przypadku tego zestawu szablonów i manifestów reprezentujących stan klastra wprowadzisz niewielką zmianę w aplikacji.

  1. W repozytorium arc-cicd-demo-src edytuj azure-vote/src/azure-vote-front/config_file.cfg plik.

  2. Ponieważ "Koty vs Psy" nie otrzymuje wystarczającej liczby głosów, zmień ją na "Tabs vs Spaces", aby zwiększyć liczbę głosów.

  3. Zatwierdź zmianę w nowej gałęzi, wypchnij ją i utwórz żądanie ściągnięcia.

    • Jest to typowy przepływ dewelopera, który rozpocznie cykl życia ciągłej integracji/ciągłego wdrażania.

Potok weryfikacji żądania ściągnięcia

Potok żądania ściągnięcia jest pierwszą linią obrony przed wadliwą zmianą. Zwykłe kontrole jakości kodu aplikacji obejmują linting i analizę statyczną. Z perspektywy metodyki GitOps należy również zapewnić tę samą jakość dla wynikowej infrastruktury, która ma zostać wdrożona.

Wykresy Dockerfile i Helm aplikacji mogą używać lintingu w podobny sposób do aplikacji.

Błędy występujące podczas lintingu wahają się od:

  • Niepoprawnie sformatowane pliki YAML do
  • Sugestie dotyczące najlepszych rozwiązań, takie jak ustawianie limitów procesora CPU i pamięci dla aplikacji.

Uwaga

Aby uzyskać najlepsze pokrycie z linting programu Helm w rzeczywistej aplikacji, należy zastąpić wartości, które są w rozsądnie podobne do tych używanych w rzeczywistym środowisku.

Błędy znalezione podczas wykonywania potoku są wyświetlane w sekcji wyników testu przebiegu. W tym miejscu możesz:

  • Śledź przydatne statystyki dotyczące typów błędów.
  • Znajdź pierwsze zatwierdzenie, na którym zostały wykryte.
  • Styl śledzenia stosu łączy się z sekcjami kodu, które spowodowały błąd.

Po zakończeniu przebiegu potoku masz pewność, że jakość kodu aplikacji i szablonu, który go wdroży. Teraz możesz zatwierdzić i ukończyć żądanie ściągnięcia. Ciągła integracja zostanie uruchomiona ponownie, ponownie wygenerując szablony i manifesty przed wyzwoleniem potoku ciągłego wdrażania.

Napiwek

W rzeczywistym środowisku nie zapomnij ustawić zasad gałęzi w celu zapewnienia, że żądanie ściągnięcia przejdzie testy jakości. Aby uzyskać więcej informacji, zobacz artykuł Ustawianie zasad gałęzi.

Zatwierdzenia procesów ciągłego wdrażania

Pomyślne uruchomienie potoku ciągłej integracji wyzwala potok ciągłej integracji w celu ukończenia procesu wdrażania. Podobnie jak w przypadku pierwszego potoku ciągłego wdrażania, wdrożysz je w każdym środowisku przyrostowo. Tym razem potok wymaga zatwierdzenia każdego środowiska wdrażania.

  1. Zatwierdź wdrożenie w dev środowisku.
  2. Po wygenerowaniu szablonu i manifestu w repozytorium GitOps potok ciągłego wdrażania utworzy zatwierdzenie, wypchnie je i utworzy żądanie ściągnięcia do zatwierdzenia.
  3. Otwórz link żądania ściągnięcia podany w zadaniu.
  4. Sprawdź zmiany w repozytorium GitOps. Powinny zostać wyświetlone następujące informacje:
    • Zmiany szablonu programu Helm wysokiego poziomu.
    • Manifesty platformy Kubernetes niskiego poziomu, które pokazują podstawowe zmiany w żądanym stanie.
  5. Jeśli wszystko wygląda dobrze, zatwierdź i ukończ żądanie ściągnięcia.
  6. Zaczekaj na zakończenie wdrażania.
  7. Jako podstawowy test weryfikacyjny kompilacji przejdź do strony aplikacji i sprawdź, czy aplikacja do głosowania wyświetla teraz karty a miejsca.
    • Przekaż port lokalnie przy użyciu polecenia kubectl i upewnij się, że aplikacja działa prawidłowo przy użyciu: kubectl port-forward -n dev svc/azure-vote-front 8080:80
    • Wyświetl aplikację Azure Vote w przeglądarce pod adresem http://localhost:8080/ i sprawdź, czy opcje głosowania zostały zmienione na karty a miejsca.
  8. Powtórz kroki 1–7 dla stage środowiska.

Wdrożenie zostało ukończone. Spowoduje to zakończenie przepływu pracy ciągłej integracji/ciągłego wdrażania.

Czyszczenie zasobów

Jeśli nie zamierzasz nadal korzystać z tej aplikacji, usuń wszystkie zasoby, wykonując następujące czynności:

  1. Usuń połączenie konfiguracji usługi GitOps usługi Azure Arc:

    az k8s-configuration delete \
--name cluster-config \
--cluster-name arc-cicd-cluster \
--resource-group myResourceGroup \
--cluster-type connectedClusters

  2. dev Usuń przestrzeń nazw:

    • kubectl delete namespace dev

  3. stage Usuń przestrzeń nazw:

    • kubectl delete namespace stage

Następne kroki

W tym samouczku skonfigurowaliśmy pełny przepływ pracy ciągłej integracji/ciągłego wdrażania, który implementuje metodykę DevOps z tworzenia aplikacji za pośrednictwem wdrożenia. Zmiany w aplikacji automatycznie wyzwalają walidację i wdrażanie, za pomocą ręcznych zatwierdzeń.

Przejdź do naszego artykułu koncepcyjnego, aby dowiedzieć się więcej na temat metodyki GitOps i konfiguracji za pomocą platformy Kubernetes z obsługą usługi Azure Arc.

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