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

Ważne

W tym samouczku jest używana usługa GitOps z platformą Flux w wersji 1. Usługa GitOps z platformą Flux v2 jest teraz dostępna dla klastrów Kubernetes z obsługą usługi Azure Arc i Azure Kubernetes Service (AKS); przejdź do samouczka, który używa metodyKi GitOps z platformą Flux w wersji 2. W końcu platforma Azure przestanie obsługiwać metodyki GitOps z platformą Flux w wersji 1, dlatego zalecamy przeprowadzenie migracji do platformy Flux w wersji 2 tak szybko, jak to możliwe.

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

  • Utwórz klaster Kubernetes z obsługą usługi Azure Arc.
  • Połącz repozytoria aplikacji i repozytoriów GitOps z Azure Repos.
  • Importowanie potoków ciągłej integracji/ciągłego wdrażania.
  • Połącz Azure Container Registry (ACR) z usługami 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ń 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 w celu Cloud Shell. Zrzut ekranu przedstawiający przykład 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. Zrzut ekranu przedstawiający sposób uruchamiania Cloud Shell w nowym oknie.
Wybierz przycisk Cloud Shell na pasku menu w prawym górnym rogu witryny Azure Portal. Zrzut ekranu przedstawiający przycisk Cloud Shell w 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 Cloud Shell, wybierając klawisze Ctrl+ShiftV 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 Azure Repos

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

Dowiedz się więcej o importowaniu 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 dostosować indywidualnie. Na przykład administrator klastra może nie znaleźć zmian w kodzie aplikacji istotnych 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 ietapowych odpowiadających środowisku wdrażania.

Utworzone połączenie GitOps automatycznie:

  • 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 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/manifeststylko 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 parametrów 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. Określa --https-user użytkownika zamiast tego, na przykład --https-user alice.

  3. Sprawdź stan wdrożenia w 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 usługi GitOps należy zaimportować potoki ciągłej integracji/ciągłego wdrażania, które tworzą manifesty.

Repozytorium aplikacji zawiera folder z potokami, których będziesz używać do ściągnięcia .pipeline , ciągłej integracji i ciągłego wdrażania. Zaimportuj i zmień nazwę trzech potoków podanych 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 ACR

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

Łączenie usługi ACR z usługą 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 usługi 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 z usługą.
  3. Wypełnij parametry połączenia z usługą. Na potrzeby tego samouczka:
    • Nazwij połączenie usługi arc-demo-acr.
    • Wybierz pozycję myResourceGroup jako grupę zasobów.
  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.

Łączenie usługi ACR z platformą Kubernetes

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

Łączenie usługi ACR z istniejącymi klastrami 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 obrazów do przechowywania informacji wymaganych do uwierzytelnienia 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 elementu imagePullSecret dla każdego zasobnika, rozważ dodanie elementu imagePullSecret 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 (Połączenie z usługą platformy Azure, które powinno być arc-demo-acr z wcześniejszej wersji samouczka)
AZURE_VOTE_IMAGE_REPO Pełna ścieżka do repozytorium aplikacji Do głosowania na platformie Azure, na przykład azurearctest.azurecr.io/azvote
ENVIRONMENT_NAME Deweloperskie
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 dla odpowiednich zmiennych są następujące wartości:
Zmienna Wartość
ENVIRONMENT_NAME Etap
TARGET_NAMESPACE stage

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

Przyznawanie większej liczby 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 strony Project settings głównej projektu Usługi Azure DevOps.
  2. Wybierz pozycję Repositories.
  3. Wybierz pozycję <GitOps Repo Name>.
  4. Wybierz pozycję Security.
  5. W przypadku elementu zezwalaj <Project Name> Build Service (<Organization Name>)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 jest dostęp do zmiennej 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.
  • Wykonuje dodatkową walidację, której nie można ukończyć w potoku żądania ściągnięcia.
    • Specyficzny dla metodyki 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łego wdrażania w celu ukończenia procesu wdrażania. Wdrożysz w każdym środowisku przyrostowo.

Porada

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 żądanego stanu. Platforma 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ę do wprowadzenia pewnych zmian 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 obszaru Zatwierdzenia i sprawdź zasób.
  3. Wybierz przycisk Utwórz.
  4. Podaj osoby zatwierdzające i opcjonalny komunikat.
  5. Wybierz ponownie pozycję Utwórz , aby ukończyć dodawanie ręcznego sprawdzania zatwierdzenia.

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 metodyki 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 zmiany aplikacji

W tym zestawie odniesienia 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 znalezione podczas linting zakresu 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ą 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żna wykonać następujące czynności:

  • Śledź przydatne statystyki dotyczące typów błędów.
  • Znajdź pierwsze zatwierdzenie, na którym zostały wykryte.
  • Style śledzenia stosu prowadzą do sekcji kodu, które spowodowały błąd.

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

Porada

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łego wdrażania w celu ukończenia procesu wdrażania. Podobnie jak przy pierwszym uruchomieniu potoku ciągłego wdrażania, wdrożysz je we wszystkich środowiskach 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. Powinien zostać wyświetlony następujący ekran:
    • Zmiany szablonu programu Helm wysokiego poziomu.
    • Manifesty platformy Kubernetes niskiego poziomu, które pokazują podstawowe zmiany żądanego stanu.
  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 i 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 od 1 do 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 procesu tworzenia aplikacji za pośrednictwem wdrożenia. Zmiany w aplikacji automatycznie wyzwalają walidację i wdrażanie, bramowane przez zatwierdzenia ręczne.

Przejdź do naszego artykułu koncepcyjnego, aby dowiedzieć się więcej o metodyce GitOps i konfiguracjach przy użyciu platformy Kubernetes z obsługą usługi Azure Arc.