Wdrażanie w infrastrukturze platformy Azure za pomocą funkcji GitHub Actions

W tym przewodniku omówimy sposób wdrażania ciągłej integracji/ciągłego wdrażania i infrastruktury jako kodu (IaC) na platformie Azure przy użyciu funkcji GitHub Actions w sposób zautomatyzowany i powtarzalny.

Ten artykuł zawiera omówienie architektury i przedstawia ustrukturyzowane rozwiązanie do projektowania aplikacji na platformie Azure, która jest skalowalna, bezpieczna, odporna i wysoce dostępna. Aby zapoznać się z bardziej rzeczywistymi przykładami architektur chmury i pomysłów na rozwiązania, przejrzyj architektury platformy Azure.

Korzyści wynikające z używania architektury IaC i automatyzacji dla wdrożeń

Istnieje wiele sposobów wdrażania na platformie Azure, w tym witryny Azure Portal, interfejsu wiersza polecenia, interfejsu API i nie tylko. W tym przewodniku użyjemy automatyzacji IaC i ciągłej integracji/ciągłego wdrażania. Zalety tego podejścia obejmują:

• Deklaratywne: podczas definiowania infrastruktury i procesu wdrażania w kodzie można go wersję i przejrzeć przy użyciu standardowego cyklu życia tworzenia oprogramowania. Usługa IaC pomaga również zapobiec dryfowi w konfiguracji.

• Spójność: Po procesie IaC zapewnia, że cała organizacja jest zgodna ze standardową, dobrze ugruntowaną metodą wdrażania infrastruktury, która zawiera najlepsze rozwiązania i jest wzmocniona w celu spełnienia wymagań w zakresie zabezpieczeń. Wszelkie ulepszenia wprowadzone w szablonach centralnych można łatwo zastosować w całej organizacji.

• Zabezpieczenia: Centralnie zarządzane szablony mogą być wzmacniane i zatwierdzane przez zespół ds. operacji w chmurze lub zespołu ds. zabezpieczeń w celu spełnienia standardów wewnętrznych.

• Samoobsługa: zespoły mogą być uprawnione do wdrażania własnej infrastruktury przy użyciu centralnie zarządzanych szablonów.

• Większa produktywność: dzięki wykorzystaniu standardowych szablonów zespoły mogą szybko aprowizować nowe środowiska bez konieczności martwienia się o wszystkie szczegóły implementacji.

Dodatkowe informacje można znaleźć w powtarzalnej infrastrukturze w Centrum architektury platformy Azure lub infrastruktury jako kodu w Centrum zasobów DevOps.

Architektura

Przepływ danych

1. Utwórz nową gałąź i zaewidencjonuj wymagane modyfikacje kodu IaC.
2. Utwórz żądanie ściągnięcia (PR) w usłudze GitHub, gdy wszystko będzie gotowe do scalenia zmian w środowisku.
3. Przepływ pracy funkcji GitHub Actions zostanie wyzwolony, aby upewnić się, że kod jest prawidłowo sformatowany, wewnętrznie spójny i tworzy bezpieczną infrastrukturę. Ponadto zostanie uruchomiona analiza warunkowa narzędzia Terraform lub Bicep w celu wygenerowania podglądu zmian, które wystąpią w środowisku platformy Azure.
4. Po odpowiednim przejrzeniu żądanie ściągnięcia można scalić z gałęzią główną.
5. Inny przepływ pracy funkcji GitHub Actions zostanie wyzwolony z gałęzi głównej i wykona zmiany przy użyciu dostawcy IaC.
6. (wyłącznie w programie Terraform) Regularnie zaplanowany przepływ pracy akcji usługi GitHub powinien być również uruchamiany, aby wyszukać wszelkie dryfy konfiguracji w środowisku i utworzyć nowy problem w przypadku wykrycia zmian.

Wymagania wstępne

Korzystanie z Bicep

1. Tworzenie środowisk GitHub

   Przepływy pracy używają środowisk i wpisów tajnych usługi GitHub do przechowywania informacji o tożsamości platformy Azure i konfigurowania procesu zatwierdzania dla wdrożeń. Utwórz środowisko o nazwie production , postępując zgodnie z tymi instrukcjami. production W środowisku skonfiguruj regułę ochrony i dodaj wszystkie wymagane osoby zatwierdzające, które mają być wymagane do zalogowania się we wdrożeniach produkcyjnych. Możesz również ograniczyć środowisko do gałęzi głównej. Szczegółowe instrukcje można znaleźć tutaj.

2. Konfigurowanie tożsamości platformy Azure:

   Aplikacja usługi Azure Active Directory jest wymagana, która ma uprawnienia do wdrożenia w ramach subskrypcji platformy Azure. Utwórz pojedynczą aplikację i nadaj jej odpowiednie uprawnienia do odczytu/zapisu w subskrypcji platformy Azure. Następnie skonfiguruj poświadczenia federacyjne, aby umożliwić usłudze GitHub korzystanie z tożsamości przy użyciu identyfikatora OpenID Połączenie (OIDC). Szczegółowe instrukcje można znaleźć w dokumentacji platformy Azure. Należy dodać trzy poświadczenia federacyjne:

   • Ustaw wartość Typ jednostki na Environment i użyj production nazwy środowiska.
   • Ustaw wartość Typ jednostki na Pull Request.
   • Ustaw wartość Typ jednostki na Branch i użyj main nazwy gałęzi.

3. Dodawanie wpisów tajnych usługi GitHub

   Uwaga

   Chociaż żadne dane dotyczące tożsamości platformy Azure nie zawierają żadnych wpisów tajnych lub poświadczeń, nadal używamy wpisów tajnych usługi GitHub jako wygodnego sposobu sparametryzowania informacji o tożsamości dla danego środowiska.

   Utwórz następujące wpisy tajne w repozytorium przy użyciu tożsamości platformy Azure:

   • AZURE_CLIENT_ID : identyfikator aplikacji (klienta) rejestracji aplikacji na platformie Azure
   • AZURE_TENANT_ID : identyfikator dzierżawy usługi Azure Active Directory, w której zdefiniowano rejestrację aplikacji.
   • AZURE_SUBSCRIPTION_ID : identyfikator subskrypcji, w której zdefiniowano rejestrację aplikacji.

   Instrukcje dotyczące dodawania wpisów tajnych do repozytorium można znaleźć tutaj.

Korzystanie z narzędzia Terraform

1. Konfigurowanie lokalizacji stanu programu Terraform

   Narzędzie Terraform używa pliku stanu do przechowywania informacji o bieżącym stanie infrastruktury zarządzanej i skojarzonej konfiguracji. Ten plik musi być utrwalany między różnymi przebiegami przepływu pracy. Zalecaną metodą jest przechowywanie tego pliku na koncie usługi Azure Storage lub w innym podobnym zdalnym zapleczu. Zwykle ten magazyn będzie aprowizować ręcznie lub za pośrednictwem oddzielnego przepływu pracy. Blok zaplecza programu Terraform będzie wymagał aktualizacji z wybraną lokalizacją magazynu (zobacz tutaj, aby uzyskać dokumentację).

2. Tworzenie środowiska usługi GitHub

   Przepływy pracy używają środowisk i wpisów tajnych usługi GitHub do przechowywania informacji o tożsamości platformy Azure i konfigurowania procesu zatwierdzania dla wdrożeń. Utwórz środowisko o nazwie production , postępując zgodnie z tymi instrukcjami. production W środowisku skonfiguruj regułę ochrony i dodaj wszystkie wymagane osoby zatwierdzające, które mają być wymagane do zalogowania się we wdrożeniach produkcyjnych. Możesz również ograniczyć środowisko do gałęzi głównej. Szczegółowe instrukcje można znaleźć tutaj.

3. Konfigurowanie tożsamości platformy Azure:

   Aplikacja usługi Azure Active Directory jest wymagana, która ma uprawnienia do wdrożenia w ramach subskrypcji platformy Azure. Utwórz oddzielną aplikację dla read-only konta i i read/write i nadaj im odpowiednie uprawnienia w subskrypcji platformy Azure. Ponadto obie role będą również potrzebować co najmniej Reader and Data Access uprawnień do konta magazynu, na którym znajduje się stan narzędzia Terraform z kroku 1. Następnie skonfiguruj poświadczenia federacyjne, aby umożliwić usłudze GitHub korzystanie z tożsamości przy użyciu Połączenie OpenID (OIDC). Szczegółowe instrukcje można znaleźć w dokumentacji platformy Azure.

   W przypadku read/write tożsamości utwórz jedno poświadczenie federacyjne w następujący sposób:

   • Ustaw Entity Type wartość i Environment użyj production nazwy środowiska.

   W przypadku read-only tożsamości utwórz dwa poświadczenia federacyjne w następujący sposób:

   • Ustaw wartość opcji Entity Type na Pull Request.
   • Ustaw Entity Type wartość i Branch użyj main nazwy gałęzi.

4. Dodawanie wpisów tajnych usługi GitHub

   Uwaga

   Chociaż żadne dane dotyczące tożsamości platformy Azure nie zawierają żadnych wpisów tajnych lub poświadczeń, nadal używamy wpisów tajnych usługi GitHub jako wygodnego sposobu sparametryzowania informacji o tożsamości dla danego środowiska.

   Utwórz następujące wpisy tajne w repozytorium przy użyciu read-only tożsamości:

   • AZURE_CLIENT_ID : identyfikator aplikacji (klienta) rejestracji aplikacji na platformie Azure
   • AZURE_TENANT_ID : identyfikator dzierżawy usługi Azure Active Directory, w której zdefiniowano rejestrację aplikacji.
   • AZURE_SUBSCRIPTION_ID : identyfikator subskrypcji, w której zdefiniowano rejestrację aplikacji.

   Instrukcje dotyczące dodawania wpisów tajnych do repozytorium można znaleźć tutaj.

   Utwórz kolejny wpis tajny w production środowisku przy użyciu read-write tożsamości:

   • AZURE_CLIENT_ID : identyfikator aplikacji (klienta) rejestracji aplikacji na platformie Azure

   Instrukcje dotyczące dodawania wpisów tajnych do środowiska można znaleźć tutaj. Wpis tajny środowiska zastąpi wpis tajny repozytorium podczas wykonywania kroku wdrażania w production środowisku, gdy wymagane są podwyższone uprawnienia odczytu/zapisu.

Wdrażanie przy użyciu akcji GitHub

Korzystanie z Bicep

Istnieją dwa główne przepływy pracy zawarte w architekturze referencyjnej:

1. Testy jednostkowe Bicep

   Ten przepływ pracy jest uruchamiany w każdym zatwierdzeniu i składa się z zestawu testów jednostkowych w kodzie infrastruktury. Uruchamia kompilację bicep w celu skompilowania bicepu do szablonu usługi ARM. Zapewnia to brak błędów formatowania. Następnie przeprowadza walidację, aby upewnić się, że szablon można wdrożyć. Na koniec checkov, narzędzie do analizy kodu statycznego typu open source dla IaC, zostanie uruchomione w celu wykrywania problemów z zabezpieczeniami i zgodnością. Jeśli repozytorium korzysta z usługi GitHub Advanced Security (GHAS), wyniki zostaną przekazane do usługi GitHub.

2. Bicep What-If / Deploy

   Ten przepływ pracy jest uruchamiany na każdym żądaniu ściągnięcia i w każdym zatwierdzeniu w gałęzi głównej. Etap analizy co-jeżeli przepływu pracy służy do zrozumienia wpływu zmian IaC w środowisku platformy Azure przez uruchomienie analizy co-jeżeli. Ten raport jest następnie dołączony do żądania ściągnięcia w celu łatwego przeglądu. Etap wdrażania jest uruchamiany po analizie analizy warunkowej po wyzwoleniu przepływu pracy przez wypchnięcie do gałęzi głównej. Ten etap spowoduje wdrożenie szablonu na platformie Azure po zakończeniu ręcznego przeglądu.

Korzystanie z narzędzia Terraform

W architekturze referencyjnej znajdują się trzy główne przepływy pracy:

1. Testy jednostkowe programu Terraform

   Ten przepływ pracy jest uruchamiany w każdym zatwierdzeniu i składa się z zestawu testów jednostkowych w kodzie infrastruktury. Uruchamia narzędzie terraform fmt , aby upewnić się, że kod jest prawidłowo podsyłany i jest zgodny z najlepszymi rozwiązaniami programu terraform. Następnie wykona weryfikację narzędzia terraform, aby sprawdzić, czy kod jest poprawny składniowo i wewnętrznie spójny. Na koniec checkov, narzędzie do analizy kodu statycznego typu open source dla IaC, zostanie uruchomione w celu wykrywania problemów z zabezpieczeniami i zgodnością. Jeśli repozytorium korzysta z usługi GitHub Advanced Security (GHAS), wyniki zostaną przekazane do usługi GitHub.

2. Plan narzędzia Terraform / Zastosuj

   Ten przepływ pracy jest uruchamiany na każdym żądaniu ściągnięcia i w każdym zatwierdzeniu w gałęzi głównej. Etap planu przepływu pracy służy do zrozumienia wpływu zmian IaC w środowisku platformy Azure przez uruchomienie planu terraform. Ten raport jest następnie dołączony do żądania ściągnięcia w celu łatwego przeglądu. Etap stosowania jest uruchamiany po planie, gdy przepływ pracy jest wyzwalany przez wypchnięcie do gałęzi głównej. Ten etap przeprowadzi dokument planu i zastosuje zmiany po zakończeniu ręcznego przeglądu, jeśli istnieją oczekujące zmiany w środowisku.

3. Wykrywanie dryfu narzędzia Terraform

   Ten przepływ pracy jest uruchamiany okresowo w celu skanowania środowiska pod kątem dryfu konfiguracji lub zmian wprowadzonych poza programem Terraform. Jeśli zostanie wykryty dryf, zostanie zgłoszony problem z usługą GitHub, aby powiadomić osoby odpowiedzialne za projekt.

Powiązane zasoby

• Co to jest infrastruktura jako kod
• Powtarzalna infrastruktura
• Porównywanie programu Terraform i Bicep
• Sprawdzanie ikod źródłowy
• Zabezpieczenia zaawansowane w usłudze GitHub