Udostępnij za pośrednictwem

Samouczek: implementowanie ciągłej integracji/ciągłego wdrażania za pomocą funkcji GitOps (Flux w wersji 2)

  • Artykuł

W tym samouczku skonfigurujesz rozwiązanie ciągłej integracji/ciągłego wdrażania przy użyciu usługi GitOps z platformą Flux w wersji 2 i z włączoną usługą Azure Arc platformą Kubernetes lub klastrami usługi Azure Kubernetes Service (AKS). Korzystając z przykładowej aplikacji Azure Vote, wykonasz następujące elementy:

  • Utwórz klaster Kubernetes lub AKS z włączoną usługą Azure Arc.
  • Łączenie aplikacji i repozytoriów GitOps z usługą Azure Repos lub GitHub.
  • Zaimplementuj przepływ ciągłej integracji/ciągłego wdrażania za pomocą usługi Azure Pipelines lub GitHub.
  • Połącz usługę Azure Container Registry z usługami Azure DevOps i Kubernetes.
  • Utwórz grupy zmiennych środowiskowych lub wpisy tajne.
  • 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. Zrzut ekranu przedstawiający przykład narzędzia Try It dla usługi Azure Cloud Shell.
Przejdź do witryny https://shell.azure.com lub wybierz przycisk Uruchom Cloud Shell, aby otworzyć środowisko Cloud Shell w przeglądarce. Przycisk uruchamiania usługi Azure Cloud Shell.
Wybierz przycisk Cloud Shell na pasku menu w prawym górnym rogu witryny Azure Portal. Zrzut ekranu przedstawiający przycisk usługi Cloud Shell w witrynie 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 Ctrl+Shift V w systemach Windows i Linux lub wybierając pozycję Cmd+Shift++V w systemie macOS.

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

Wymagania wstępne

  • Ukończ poprzedni samouczek, aby dowiedzieć się, jak wdrożyć metodyę GitOps dla środowiska ciągłej integracji/ciągłego wdrażania.

  • Poznaj korzyści i architekturę tej funkcji.

  • Sprawdź, czy masz:

    • Połączony klaster Kubernetes z obsługą usługi Azure Arc o nazwie arc-cicd-cluster.
    • Połączona usługa Azure Container Registry z integracją usługi AKS lub uwierzytelnianiem klastra innego niż AKS.

  • Zainstaluj najnowsze wersje tych rozszerzeń interfejsu wiersza polecenia interfejsu wiersza polecenia platformy Kubernetes z włączoną usługą Azure Arc i platformy Kubernetes:

    az extension add --name connectedk8s
az extension add --name k8s-configuration

    • Aby zaktualizować te rozszerzenia do najnowszej wersji, uruchom następujące polecenia:

      az extension update --name connectedk8s
az extension update --name k8s-configuration

Łączenie usługi Azure Container Registry z platformą Kubernetes

Włącz klaster Kubernetes w celu ściągnięcia obrazów z usługi Azure Container Registry. Jeśli jest to prywatne, wymagane jest uwierzytelnianie.

Łączenie usługi Azure Container Registry z istniejącymi klastrami usługi AKS

Zintegruj istniejącą usługę Azure Container Registry 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ą Azure Container Registry, 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.

W zależności od preferowanego koordynatora ciągłej integracji/ciągłego wdrażania możesz postępować zgodnie z instrukcjami dotyczącymi usługi Azure DevOps lub GitHub.

Implementowanie ciągłej integracji/ciągłego wdrażania za pomocą usługi Azure DevOps

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

Najpierw wykonaj następujące kroki:

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:

  • arc-cicd-demo-src application repository

  • arc-cicd-demo-gitops repozytorium GitOps

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 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.

Łą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łnia 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 flux create \
   --name cluster-config \
   --cluster-name arc-cicd-cluster \
   --namespace flux-system \
   --resource-group myResourceGroup \
   -u 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 \
   --branch master \
   --kustomization name=cluster-config prune=true path=arc-cicd-cluster/manifests

    Napiwek

    W przypadku klastra usługi AKS (a nie klastra z obsługą usługi Arc) użyj polecenia -cluster-type managedClusters.

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

    • W przypadku powodzenia zobaczysz zarówno przestrzenie nazw, jak dev i stage utworzone w klastrze.
    • Możesz również potwierdzić, że na stronie witryny Azure Portal klastra na karcie fGitOps zostanie utworzona konfiguracjacluster-config.

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 używanymi dla żądania ściągnięcia, ciągłej integracji i ciągłego wdrażania. Zaimportuj i zmień nazwę trzech potoków dostępnych w przykładowym repozytorium:

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

Łączenie usługi Azure Container Registry z usługą Azure DevOps

Podczas procesu ciągłej integracji kontenery aplikacji są wdrażane 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.

Konfigurowanie połączenia usługi ŻĄDANIA ściągnięcia

Potok ciągłego wdrażania manipuluje żądaniami ściągnięcia w repozytorium GitOps. W tym celu potrzebne jest połączenie z usługą. Aby skonfigurować to połączenie:

  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 Generic typ.
  3. Wypełnij parametry połączenia z usługą. Na potrzeby tego samouczka:
    • Adres URL serwera https://dev.azure.com/<Your organization>/<Your project>/_apis/git/repositories/arc-cicd-demo-gitops
    • Pozostaw pole Nazwa użytkownika i Hasło puste.
    • Nadaj połączeniu usługi nazwę azdo-pr-connection.
  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.

Instalowanie łącznika GitOps

  1. Dodaj repozytorium łącznika GitOps do repozytoriów programu Helm:

       helm repo add gitops-connector https://azure.github.io/gitops-connector/

  2. Zainstaluj łącznik w klastrze:

       helm upgrade -i gitops-connector gitops-connector/gitops-connector \
      --namespace flux-system \
      --set gitRepositoryType=AZDO \
      --set ciCdOrchestratorType=AZDO \
      --set gitOpsOperatorType=FLUX \
      --set azdoGitOpsRepoName=arc-cicd-demo-gitops \
      --set azdoOrgUrl=https://dev.azure.com/<Your organization>/<Your project> \
      --set gitOpsAppURL=https://dev.azure.com/<Your organization>/<Your project>/_git/arc-cicd-demo-gitops \
      --set orchestratorPAT=<Azure Repos PAT token>

    Uwaga

    Azure Repos PAT token powinien mieć Build: Read & execute uprawnienia i Code: Full .

  3. Skonfiguruj platformę Flux do wysyłania powiadomień do łącznika GitOps:

    cat <<EOF | kubectl apply -f -
apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Alert
metadata:
  name: gitops-connector
  namespace: flux-system
spec:
  eventSeverity: info
  eventSources:
  - kind: GitRepository
    name: cluster-config
  - kind: Kustomization
    name: cluster-config-cluster-config 
  providerRef:
    name: gitops-connector
---
apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Provider
metadata:
  name: gitops-connector
  namespace: flux-system
spec:
  type: generic
  address: http://gitops-connector:8080/gitopsphase
EOF

Aby uzyskać szczegółowe informacje na temat instalacji, zapoznaj się z repozytorium łącznika GitOps.

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ść
AZURE_SUBSCRIPTION (Połączenie z usługą platformy Azure, które powinno być arc-demo-acr z wcześniejszej wersji samouczka)
AZ_ACR_NAME Nazwa usługi Azure ACR, na przykład arc-demo-acr
ENVIRONMENT_NAME Deweloper
MANIFESTS_BRANCH master
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
VOTE_APP_TITLE Aplikacja do głosowania
AKS_RESOURCE_GROUP Grupa zasobów usługi AKS. Wymagane do testowania automatycznego.
AKS_NAME Nazwa usługi AKS. Wymagane do testowania automatycznego.

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 .

Tworzenie środowisk

W projekcie usługi Azure DevOps utwórz Dev środowiska i Stage . Aby uzyskać szczegółowe informacje, zobacz Create and target an environment (Tworzenie i określanie celu środowiska).

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ę Repos/Repositories.
  3. Wybierz opcję Security.
  4. <Project Name> Build Service (<Organization Name>) W polu i Project Collection Build Service (<Organization Name>) (wpisz w polu wyszukiwania, jeśli nie zostanie ono wyświetlone), zezwól na Contributewartości , Contribute to pull requestsi Create branch.
  5. Przejdź do strony Pipelines/Settings
  6. Wyłącz Protect access to repositories in YAML pipelines opcję

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 należy udzielić 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 tworzy zatwierdzenie, wypycha je i tworzy żądanie ściągnięcia do zatwierdzenia.

  1. Znajdź żądanie ściągnięcia utworzone przez potok w repozytorium GitOps.

  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. Monitoruj stan zatwierdzenia usługi Git na karcie Historia zatwierdzń. Po utworzeniu succeededpotoku ciągłego wdrażania rozpocznie się automatyczne testowanie.

  6. 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

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

  8. 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 pozycji 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. Ta sekwencja kroków to typowy przepływ dewelopera, który rozpoczyna 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 określania zakresu lintingu pochodzą z niepoprawnie sformatowanych plików YAML do sugestii dotyczących najlepszych rozwiązań, takich 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 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. 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 tworzy zatwierdzenie, wypycha je i tworzy żądanie ściągnięcia do zatwierdzenia.
  3. 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.
  4. Jeśli wszystko wygląda dobrze, zatwierdź i ukończ żądanie ściągnięcia.
  5. Zaczekaj na zakończenie wdrażania.
  6. 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.
  7. Powtórz kroki 1–7 dla stage środowiska.

Wdrożenie zostało ukończone.

Aby zapoznać się ze szczegółowym omówieniem wszystkich kroków i technik wdrożonych w przepływach pracy ciągłej integracji/ciągłego wdrażania używanych w tym samouczku, zobacz diagram przepływu usługi GitOps usługi Azure DevOps.

Implementowanie ciągłej integracji/ciągłego wdrażania za pomocą usługi GitHub

W tym samouczku założono, że znasz usługę GitHub, funkcję GitHub Actions.

Rozwidlenie aplikacji i repozytoriów GitOps

Tworzenie rozwidlenia repozytorium aplikacji i repozytorium GitOps. Na potrzeby tego samouczka użyj następujących przykładowych repozytoriów:

Łą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łnia katalog manifestu dodatkowymi manifestami w celu wdrożenia aplikacji.

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

    az k8s-configuration flux create \
   --name cluster-config \
   --cluster-name arc-cicd-cluster \
   --namespace cluster-config \
   --resource-group myResourceGroup \
   -u  https://github.com/<Your organization>/arc-cicd-demo-gitops.git \
   --https-user <Azure Repos username> \
   --https-key <Azure Repos PAT token> \
   --scope cluster \
   --cluster-type connectedClusters \
   --branch master \
   --kustomization name=cluster-config prune=true path=arc-cicd-cluster/manifests

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

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

Instalowanie łącznika GitOps

  1. Dodaj repozytorium łącznika GitOps do repozytoriów programu Helm:

       helm repo add gitops-connector https://azure.github.io/gitops-connector/

  2. Zainstaluj łącznik w klastrze:

       helm upgrade -i gitops-connector gitops-connector/gitops-connector \
      --namespace flux-system \
      --set gitRepositoryType=GITHUB \
      --set ciCdOrchestratorType=GITHUB \
      --set gitOpsOperatorType=FLUX \
      --set gitHubGitOpsRepoName=arc-cicd-demo-src \
      --set gitHubGitOpsManifestsRepoName=arc-cicd-demo-gitops \
      --set gitHubOrgUrl=https://api.github.com/repos/<Your organization> \
      --set gitOpsAppURL=https://github.com/<Your organization>/arc-cicd-demo-gitops/commit \
      --set orchestratorPAT=<GitHub PAT token>

  3. Skonfiguruj platformę Flux do wysyłania powiadomień do łącznika GitOps:

    cat <<EOF | kubectl apply -f -
apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Alert
metadata:
  name: gitops-connector
  namespace: flux-system
spec:
  eventSeverity: info
  eventSources:
  - kind: GitRepository
    name: cluster-config
  - kind: Kustomization
    name: cluster-config-cluster-config
  providerRef:
    name: gitops-connector
---
apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Provider
metadata:
  name: gitops-connector
  namespace: flux-system
spec:
  type: generic
  address: http://gitops-connector:8080/gitopsphase
EOF

Aby uzyskać szczegółowe informacje na temat instalacji, zapoznaj się z repozytorium łącznika GitOps.

Tworzenie wpisów tajnych usługi GitHub

Tworzenie wpisów tajnych repozytorium GitHub

Klucz tajny Wartość
AZURE_CREDENTIALS Poświadczenia platformy Azure w następującym formacie {"clientId":"GUID","clientSecret":"GUID","subscriptionId":"GUID","tenantId":"GUID"}
AZ_ACR_NAME Nazwa usługi Azure ACR, na przykład arc-demo-acr
MANIFESTS_BRANCH master
MANIFESTS_FOLDER arc-cicd-cluster
MANIFESTS_REPO https://github.com/your-organization/arc-cicd-demo-gitops
VOTE_APP_TITLE Aplikacja do głosowania
AKS_RESOURCE_GROUP Grupa zasobów usługi AKS. Wymagane do testowania automatycznego.
AKS_NAME Nazwa usługi AKS. Wymagane do testowania automatycznego.
Osobisty token dostępu Token PAT usługi GitHub z uprawnieniem do żądania ściągnięcia do repozytorium GitOps

Tworzenie wpisów tajnych środowiska GitHub

  1. Utwórz az-vote-app-dev środowisko z następującymi wpisami tajnymi:
Klucz tajny Wartość
ENVIRONMENT_NAME Deweloper
TARGET_NAMESPACE dev
  1. Utwórz az-vote-app-stage środowisko z następującymi wpisami tajnymi:
Klucz tajny Wartość
ENVIRONMENT_NAME Etap
TARGET_NAMESPACE stage

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

Przepływ pracy ciągłej integracji/ciągłego wdrażania

Aby uruchomić przepływ pracy ciągłej integracji/ciągłego wdrażania, zmień kod źródłowy. W repozytorium aplikacji zaktualizuj wartości w .azure-vote/src/azure-vote-front/config_file.cfg pliku i wypchnij zmiany do repozytorium.

Przepływ pracy ciągłej integracji/ciągłego wdrażania:

  • 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.
  • Sprawdza, czy obraz platformy Docker został zmieniony, a nowy obraz jest wypychany.
  • Publikuje artefakty (tagi obrazów platformy Docker, szablony manifestu, narzędzia), które będą używane przez następujące etapy ciągłego wdrażania.
  • Wdraża aplikację w środowisku deweloperskim.
    • Generuje manifesty w repozytorium GitOps.
    • Tworzy żądanie ściągnięcia do repozytorium GitOps do zatwierdzenia.

  1. Znajdź żądanie ściągnięcia utworzone przez potok w repozytorium GitOps.

  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. Monitoruj stan zatwierdzenia usługi Git na karcie Historia zatwierdzń. Po jego utworzeniu succeededCD Stage przepływ pracy zostanie uruchomiony.

  6. 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

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

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

Przepływ pracy etapu ciągłego wdrażania

Przepływ pracy etapu ciągłego wdrażania jest uruchamiany automatycznie po pomyślnym wdrożeniu aplikacji w środowisku deweloperskim i powiadomi o akcjach usługi GitHub za pośrednictwem łącznika GitOps Connector.

Przepływ pracy etapu ciągłego wdrażania:

  • Uruchamia testy weryfikacyjne kompilacji aplikacji w środowisku deweloperskim
  • Wdraża aplikację w środowisku etapowym.
    • Generuje manifesty w repozytorium GitOps
    • Tworzy żądanie ściągnięcia do repozytorium GitOps na potrzeby zatwierdzenia

Po scaleniu manifestów żądania ściągnięcia ze środowiskiem etapu i pomyślnym wprowadzeniu wszystkich zmian stan zatwierdzenia usługi Git zostanie zaktualizowany w repozytorium GitOps. Wdrożenie zostało ukończone.

Aby zapoznać się ze szczegółowym omówieniem wszystkich kroków i technik wdrożonych w przepływach pracy ciągłej integracji/ciągłego wdrażania używanych w tym samouczku, zobacz diagram przepływu usługi GitOps w usłudze GitHub.

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 flux delete \
      --name cluster-config \
      --cluster-name arc-cicd-cluster \
      --resource-group myResourceGroup \
      -t connectedClusters --yes

  2. Usuń łącznik GitOps:

    helm uninstall gitops-connector -n flux-system
kubectl delete alerts.notification.toolkit.fluxcd.io gitops-connector -n flux-system
kubectl delete providers.notification.toolkit.fluxcd.io  gitops-connector -n flux-system

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.

Koncepcja: proces ciągłego wdrażania za pomocą przykładowej implementacji gitOps: eksplorowanie przepływu ciągłej integracji/ciągłego wdrażania za pomocą metodyki GitOps