Udostępnij za pomocą

Poradnik: Implementacja CI/CD z GitOps (Flux 2)

W tym samouczku skonfigurujesz rozwiązanie ciągłej integracji/ciągłego wdrażania z wykorzystaniem GitOps z Flux w wersji 2 oraz klastrami włączonymi do Azure Arc lub zarządzanymi przez usługę Azure Kubernetes Service (AKS). Korzystając z przykładowej aplikacji Azure Vote, możesz wykonywać następujące czynności:

  • Łączenie aplikacji i repozytoriów GitOps z usługą Azure Devops (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 tajne informacje.
  • dev Wdrażanie środowisk istage.
  • Przetestuj środowiska aplikacji.

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

Wymagania wstępne

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

  • Poznaj korzyści i architekturę tej funkcji.

  • Sprawdź, czy masz:

  • Zainstaluj najnowsze wersje tych rozszerzeń CLI dla Kubernetes z włączoną usługą Azure Arc oraz Kubernetes Configuration.

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

  • Lub 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

Utwórz sekretny klucz pobierania obrazu

Aby połączyć klastry inne niż AKS i lokalne z usługą Azure Container Registry, utwórz sekret do pobierania obrazu. Platforma Kubernetes używa tajnych danych pobierania obrazów do przechowywania informacji potrzebnych do uwierzytelnienia w rejestrze.

Utwórz sekret pobierania obrazu za pomocą polecenia kubectl. Powtórz zarówno dla przestrzeni nazw dev, jak 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 tajnego klucza pobierania obrazu dla każdego Podu, rozważ dodanie tego klucza do konta usługi w dev namespace i stage. Aby uzyskać więcej informacji, zobacz samouczek dotyczący platformy Kubernetes.

W zależności od preferowanego koordynatora CI/CD, możesz postępować zgodnie z wytycznymi 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ść aplikacji oraz repozytoriów GitOps można dostosować 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łącz repozytorium GitOps

Aby stale wdrażać aplikację, połącz repozytorium GitOps z klastrem przy użyciu metodyki GitOps. Repozytorium GitOps arc-cicd-demo-gitops zawiera podstawowe zasoby do uruchomienia aplikacji na 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 automatycznie synchronizuje manifesty w katalogu manifestu i aktualizuje stan klastra.

Przepływ pracy CI/CD uzupełnia katalog manifestu o dodatkowe manifesty 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.

    • Jeśli się uda, zobaczysz w swoim klastrze utworzone zarówno przestrzenie nazw dev, jak i stage.
    • Możesz również potwierdzić, że na stronie portalu Azure twojego klastra zostanie utworzona konfiguracja cluster-config na karcie GitOps.

Importowanie potoków CI/CD

Po zsynchronizowaniu połączenia GitOps należy zaimportować potoki CI/CD, które generują manifesty.

Repozytorium aplikacji zawiera .pipeline folder z potokami używanymi do wniosków o wciągnięcie (PR), ciągłej integracji (CI) i ciągłego wdrażania (CD). Zaimportuj i zmień nazwę trzech potoków dostępnych w przykładowym repozytorium:

Nazwa pliku przepływu opis
.pipelines/az-vote-pr-pipeline.yaml Potok PR aplikacji o nazwie arc-cicd-demo-src PR
.pipelines/az-vote-ci-pipeline.yaml Potok CI 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 wdrażasz swoje kontenery aplikacji do rejestru. 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 opcję „Udziel uprawnienia dostępu do wszystkich potoków”.
    • Ta opcja autoryzuje pliki potoków YAML dla połączeń usług.
  5. Wybierz pozycję Zapisz , aby utworzyć połączenie.

Skonfiguruj połączenie z usługą żądań ściągnięcia

Potok ciągłego wdrażania manipuluje żądaniami ściągnięcia w repozytorium GitOps, co wymaga połączenia 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 + Nowe połączenie usługowe 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 opcję „Udziel uprawnienia dostępu do wszystkich potoków”.
    • Ta opcja autoryzuje pliki potoków YAML dla połączeń usług.
  5. Wybierz pozycję Zapisz , 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/v1beta2
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/v1beta2
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, zobacz 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ą Azure, które powinno być ustawione na arc-demo-acr z wcześniejszej części 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 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 podano odpowiednie wartości odpowiadające zmiennym.

    Zmienna Wartość
    ENVIRONMENT_NAME Etap
    TARGET_NAMESPACE stage

Teraz jesteś gotowy do wdrożenia w środowiskach dev i stage.

Tworzenie środowisk

W projekcie usługi Azure DevOps utwórz Dev środowiska i Stage . Aby uzyskać szczegółowe informacje, zobacz Tworzenie i kierowanie środowiskami.

Nadaj więcej uprawnień usłudze kompilacji

Pipeline CD używa tokenu zabezpieczającego kompilacji w trakcie działania do uwierzytelniania w repozytorium GitOps. Do utworzenia nowej gałęzi, wypychania zmian i tworzenia żądania ściągnięcia potrzebnych jest więcej uprawnień do potoku. Aby włączyć te uprawnienia:

  1. W Azure DevOps otwórz ustawienia projektu.
  2. Wybierz Repozytoria w obszarze Repos.
  3. Kliknij Zabezpieczenia.
  4. Znajdź <Project Name> Build Service (<Organization Name>) i Project Collection Build Service (<Organization Name>) (użyj wyszukiwania, jeśli ich nie widzisz), i zezwól na współpraca, współpraca przy żądaniach ściągnięcia, i tworzenie gałęzi.
  5. W sekcji Potoki wybierz Ustawienia.
  6. Wyłącz opcję Chroń dostęp do repozytoriów w potokach YAML.

Aby uzyskać więcej informacji, zobacz Udzielanie uprawnień kontroli wersji do usługi kompilacji i Zarządzanie uprawnieniami konta usługi kompilacji.

Wdrażanie środowiska deweloperskiego po raz pierwszy

Po utworzeniu potoków CI i CD, uruchom potok CI, aby po raz pierwszy wdrożyć aplikację.

Potok CI

Podczas początkowego uruchomienia potoku CI, jeśli zobaczysz błąd autoryzacji zasobów, gdy odczytujesz nazwę połączenia z usługą, wykonaj następujące czynności:

  1. Zweryfikuj, czy zmienna, do której uzyskiwany jest dostęp, to AZURE_SUBSCRIPTION.
  2. Autoryzowanie użycia.
  3. Uruchom ponownie ciąg przetwarzania.

Potok CI:

  • 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 przesyłany.

Potok ciągłego wdrażania

Podczas pierwszego uruchomienia potoku CD należy udostępnić potokowi dostęp do repozytorium GitOps. Kiedy pojawi się monit, że potok potrzebuje uprawnień do dostępu do zasobu, wybierz Wyświetl. Następnie wybierz pozycję Zezwól, aby udzielić uprawnień do używania repozytorium GitOps dla bieżących i przyszłych uruchomień przepływu.

Pomyślne uruchomienie potoku ciągłej integracji (CI) wyzwala potok ciągłego wdrażania (CD) w celu ukończenia procesu wdrażania. Wdrażasz do każdego środowiska stopniowo.

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

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ź PR utworzony przez pipeline w repozytorium GitOps.

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

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

  3. Jeśli wszystko wygląda dobrze, zatwierdź i ukończ prośbę o pobranie.

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

  5. git commit Monitoruj stan na karcie Historii zatwierdzeń. Gdy osiągnie odpowiedni poziom, potok CD rozpocznie 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 wprowadzać zmiany w kodzie lub szablonach, ale można również przypadkowo umieścić klaster w złym stanie.

Jeśli środowisko deweloperskie ujawni usterkę po wdrożeniu, włączenie zatwierdzeń środowiska pomaga zapobiegać rozprzestrzenianiu się problemu do dalszych środowisk.

  1. W projekcie usługi Azure DevOps przejdź do środowiska, które musi być chronione.
  2. Przejdź do Zatwierdzenia i Kontrole dla zasobu.
  3. Wybierz pozycję Utwórz.
  4. Podaj osoby zatwierdzające i opcjonalny komunikat.
  5. Wybierz ponownie pozycję Utwórz, aby zakończyć dodawanie sprawdzania ręcznej akceptacji.

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

Przy następnym uruchomieniu potoku CD, zostanie on wstrzymany po utworzeniu żądania ściągnięcia GitOps. Sprawdź, czy zmiana została prawidłowo zsynchronizowana i spełnia 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 należy wprowadzić 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. Oto typowy przepływ pracy programisty, który rozpoczyna cykl życia CI/CD.

Potok weryfikacji żądania ściągnięcia

Potok PR 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 wykryte podczas lintingu obejmują od niepoprawnie sformatowanych plików YAML po sugestie najlepszych praktyk, takie jak ustawianie limitów 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ą dość podobne do wartości, które będą używane 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ź commit, w którym zostały wykryte po raz pierwszy.
  • Styl śledzenia stosu łączy się z sekcjami kodu, które spowodowały błąd.

Przebieg potoku kończy się, potwierdzając jakość kodu aplikacji i szablon, który ją wdraża. Teraz możesz zatwierdzić i ukończyć pull request. CI uruchamia się ponownie, generując na nowo szablony i manifesty, zanim zainicjuje potok CD.

Napiwek

W rzeczywistym środowisku należy ustawić zasady gałęzi, aby zapewnić, że pull request przejdzie odpowiadające testy jakości. Aby uzyskać więcej informacji, zobacz Zasady i ustawienia gałęzi.

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

Pomyślne uruchomienie potoku ciągłej integracji wyzwala potok ciągłego wdrażania, aby zakończyć proces wdrażania. Tym razem ciąg wymaga zatwierdzenia każdego wdrożenia w środowisku.

  1. Zatwierdź wdrożenie w środowisku dev.
  2. Po wygenerowaniu zmian w szablonie i manifeście do repozytorium GitOps, pipeline CD tworzy commit, wypycha go i tworzy pull request (PR) do zatwierdzenia.
  3. Sprawdź zmiany w repozytorium GitOps. Powinieneś zobaczyć:
    • Zmiany szablonu programu Helm wysokiego poziomu.
    • Manifesty Kubernetes niskopoziomowe, które pokazują podstawowe zmiany w stanie docelowym.
  4. Jeśli wszystko wygląda dobrze, zatwierdź i ukończ prośbę o pobranie.
  5. Zaczekaj na zakończenie wdrażania.
  6. Jako podstawowy test dymny przejdź do strony aplikacji i sprawdź, czy aplikacja do głosowania wyświetla Tabs vs Spaces.
    • 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/CD wykorzystywanych w tym samouczku, zobacz diagram Azure DevOps GitOps Flow.

Implementuj CI/CD w GitHub

Ten samouczek zakłada znajomość GitHub i GitHub Actions.

Rozwidlenie aplikacji i repozytoriów GitOps

Zrób forka repozytorium aplikacji oraz repozytorium GitOps. Na potrzeby tego samouczka użyj następujących przykładowych repozytoriów:

Połącz 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 do uruchomienia aplikacji na klastrze arc-cicd-cluster.

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

Połączenie GitOps tworzone automatycznie:

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

Przepływ pracy CI/CD uzupełnia katalog manifestu o dodatkowe manifesty w celu wdrożenia aplikacji.

  1. Utwórz nowe połączenie GitOps z nowo sforkowanym 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.

    • Jeśli się uda, zobaczysz w swoim klastrze utworzone zarówno przestrzenie nazw dev, jak i stage.

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/v1beta2
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/v1beta2
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

Następnym krokiem jest utworzenie repozytorium GitHub i tajemnic środowiska.

Tworzenie wpisów tajnych repozytorium GitHub

Użyj następujących wartości dla 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 AKS. Wymagane do testowania automatycznego.
AKS_NAME Nazwa usługi AKS. Wymagane do testowania automatycznego.
PAT Token PAT usługi GitHub z uprawnieniem do PR do repozytorium GitOps

Tworzenie sekretów środowiska GitHub

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

Teraz jesteś gotowy do wdrożenia w środowiskach dev i stage.

Przepływ pracy CI/CD

Aby uruchomić przepływ pracy CI/CD, 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/CD

  • 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 przesyłany.
  • Publikuje artefakty (tagi obrazów Docker, szablony manifestu, narzędzia), które są używane przez następujące etapy CD.
  • Wdraża aplikację w środowisku deweloperskim.
    • Generuje manifesty w repozytorium GitOps.
    • Tworzy żądanie ściągnięcia do repozytorium GitOps do zatwierdzenia.

Po wykonaniu tych kroków:

  1. Znajdź PR utworzony przez pipeline w repozytorium GitOps.

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

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

  3. Jeśli wszystko wygląda dobrze, zatwierdź i ukończ prośbę o pobranie.

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

  5. Monitoruj stan na karcie Historia zatwierdzeń. Gdy będzie git commit, zostanie uruchomiony przepływ pracy succeeded.

  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 (CD Stage):

  • Uruchamia testy podstawowego działania aplikacji w środowisku developerskim
  • Wdraża aplikację w środowisku etapowym.
    • Generuje manifesty w repozytorium GitOps
    • Tworzy pull request do repozytorium GitOps do zatwierdzenia

Po scaleniu manifestów w żądaniu ściągnięcia do środowiska Stage i pomyślnym wprowadzeniu wszystkich zmian przez Flux, stan zatwierdzenia 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/CD, używanych w tym samouczku, zobacz diagram przepływu GitOps na platformie 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 GitOps w 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 skonfigurujesz pełny przepływ pracy CI/CD, który implementuje metodykę DevOps od tworzenia aplikacji aż do 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 CD z GitOpsPrzykładowa implementacja: eksploracja przepływu CI/CD z użyciem GitOps

  • Last updated on