Edytuj

Infrastruktura przedsiębiorstwa jako kod przy użyciu Bicep i usługi Azure Container Registry

Azure Container Registry
Azure DevOps
Azure Kubernetes Service (AKS)
Azure Resource Manager
Azure Policy

Modułyzacja zarządzania szablonami usługi Azure Resource Manager (szablonami usługi ARM) umożliwia zmniejszenie powtarzania, najlepszych rozwiązań dotyczących modelu w zakresie opracowywania infrastruktury i spójnych wdrożeń standardowych.

Przykładem przypadku użycia implementacji tego rodzaju modułyzacji jest wdrożenie maszyn wirtualnych przy użyciu metafory rozmiarów koszulek. Załóżmy, że wdrożono dziesiątki lub setki maszyn wirtualnych. Te wdrożenia używają wersji 1.0.0 szablonów i mają standardowy średni rozmiar starszej serii. Przejście do nowej serii może wymagać krótkiej przerwy w działaniu usługi, jeśli po prostu wdrożono nowe szablony. Jednak tworząc wersję 1.5.0 i korzystając z modułyzacji, można wdrożyć nową infrastrukturę ze zaktualizowanym standardem przy zachowaniu starej infrastruktury w stanie możliwy do wdrożenia. Mając dostępne stare wersje infrastruktury, zespoły ds. produktów i aplikacji mają znaną dobrą konfigurację, na której należy polegać podczas uaktualniania do nowej wersji, gdy mają czas.

Ciasto warstwowe repozytoriów: przykład dla przedsiębiorstw

Jeśli chodzi o to, dlaczego warto mieć silną preferencję dotyczącą tego, gdzie idą szablony, sposobu ich aktualizowania i tak dalej, istnieją dwa podstawowe zagadnienia: rozgałęzianie i wewnętrzne.

  • Rozgałęzienia. Ten przykładowy scenariusz ułatwia modelowanie rozgałęziania git, które obsługują przepływ Gitflow i GitHub. Aby uzyskać więcej informacji na temat usługi Gitflow, zobacz Używanie przepływu git-flow do automatyzowania przepływu pracy rozgałęziania git, wpis w blogu Jeff Kreeftmeijer. Aby uzyskać więcej informacji na temat przepływu usługi GitHub, zobacz Przepływ usługi GitHub w dokumentacji usługi GitHub.

  • Wewnętrznaourcing. Drugi to wewnętrzna architektura, która przynosi wspólne praktyki tworzenia oprogramowania typu open source do programowania wewnętrznych. W takim scenariuszu można bezpieczniej udostępniać różne szablony i kod źródłowy modułu bez konieczności martwienia się o uprawnienia dla samych modeli wdrażania. Aby uzyskać więcej informacji na temat opracowywania zasobów wewnętrznych, zobacz Wprowadzenie do źródła wewnętrznego w usłudze GitHub,

Bicep to język deklaratywny do wdrażania zasobów platformy Azure. Kod wielokrotnego użytku Bicep może używać usługi Azure Container Registry jako rejestru prywatnego do hostowania w wersji szablonów usługi ARM. Korzystając z usługi Container Registry w ten sposób, przedsiębiorstwo może mieć proces ciągłej integracji i ciągłego dostarczania (CI/CD) dla infrastruktury. W ramach procesu ciągłej integracji można uruchamiać testy integracyjne i jednostkowe, a rejestr kontenerów może odbierać moduły po pomyślnym skompilowania. Zespoły aplikacji mogą nadal używać starszych wersji, dopóki nie będą gotowe do uaktualnienia lub będą mogły aktualizować, aby korzystać z funkcji w nowszych wersjach szablonów.

Oprócz tego użycia usługi Container Registry można połączyć ten model z czymś takim jak moduły zweryfikowane platformy Azure. Implementacja może korzystać z rejestru publicznego, a najlepiej monitorować repozytoria publiczne i pobierać zmiany do rejestru prywatnego w celu dalszego użycia. Ściąganie zmian do własnego rejestru kontenerów umożliwia uruchamianie testów względem modułów publicznych przy jednoczesnym zapewnieniu, że nie są one używane w środowisku produkcyjnym, dopóki nie zostaną włączone rozwiązania dotyczące jakości i zabezpieczeń.

Warstwy

Model proponowany w tym przykładowym scenariuszu jest modelem, który stosy. Warstwy w pobliżu górnej części stosu mają częstsze wdrożenia i wdrożenia, które są bardziej na zamówienie. Kod Bicep zapewnia spójne wdrożenia. Zespoły programistyczne, pracujące w warstwach na potrzeby ich współtworzenia, kompilują się na podstawie usług i infrastruktury, które znajdują się w poniższych warstwach. Nic w niższej warstwie nie powinno polegać na zasobach w powyższej warstwie. Od warstwy 0 do 3 to biblioteka globalna, globalna infrastruktura (globalnie udostępnione usługi), platforma produktów (usługi udostępnione) i aplikacje.

Diagram that shows the layers of development, ordered by development frequency.

Ten model tworzy autonomię z wyrównaniem, co oznacza, że:

  • Typowe narzędzia ułatwiające przedsiębiorstwa. Na przykład wszyscy używają narzędzia git do kontroli źródła, a wszyscy używają funkcji GitHub Actions do ciągłej integracji/ciągłego wdrażania. Jednak nie przesadzujemy. Na przykład nie nakazujemy, aby wszystkie zespoły używały Bicep; mogą używać narzędzia Terraform, szablonów usługi ARM i innych narzędzi.

  • Możliwość udostępniania najlepszych rozwiązań. Mogą one mieć postać szablonów usługi ARM, złotych obrazów lub fragmentów kodu. Najlepsze rozwiązania mogą być również dokumentacją określonych technik. Na przykład jak obracać klucze w środowisku i jak testować kod.

  • Niektóre usługi poruszają się w dół w stosie. Na przykład zespół aplikacji może początkowo opracować szablon na potrzeby wdrażania klastra Kubernetes, który później jest ściągany na platformę produktu jako usługę udostępnioną. Ten szablon staje się tak przydatny, że jest on pobierany do biblioteki przykładów.

Warstwa 0 — biblioteka globalna

Warstwa dolna to biblioteka globalna, która jest repozytorium przydatnych tidbitów, które nie są wdrażane w środowisku produkcyjnym. Z punktu widzenia kontroli dostępu dostęp do odczytu powinien być udostępniany każdemu, kto go żąda. W przypadku zmian, sugestii i tak dalej, Centrum doskonałości w chmurze (CCoE) zatwierdza żądania ściągnięcia i zarządzaj listą prac tak, jakby był to jakikolwiek inny produkt.

Screen shot of the folder structure of layer 0, global infrastructure library, with the 'arm' folder selected.

Warstwa 0 nie powinna zawierać:

  • Szablony wdrażane w środowisku produkcyjnym.
  • Wpisy tajne lub konfiguracje specyficzne dla środowiska.

Warstwa 0 powinna zawierać :

  • Fragmenty kodu (w języku Python, C#i tak dalej).
  • Przykłady usługi Azure Policy.
  • Szablony usługi ARM, szablony Bicep lub pliki Programu Terraform, których można używać jako przykładów.

Przykładem jest przykładowa architektura dotycząca sposobu, w jaki firma będzie pisać wdrożenie dla aplikacji trójwarstwowej bez żadnych informacji specyficznych dla środowiska. Ta przykładowa architektura może obejmować tagi, sieci, sieciowe grupy zabezpieczeń itd. Pomijanie konkretnych informacji dla środowiska jest przydatne, ponieważ nie wszystko może być lub trzeba umieścić w module. Próba wykonania tej czynności może spowodować nadmierne parametryzację.

Ponadto warstwa 0 może łączyć się z innymi znanymi dobrymi źródłami przykładowego kodu, takimi jak terraform registry lub moduły zasobów platformy Azure). Jeśli Organizacja przyjmuje kod lub wzorzec z jednego z tych źródeł, zalecamy ściąganie kodu lub wzorca do własnej warstwy 0 zamiast ściągania bezpośrednio ze źródeł publicznych. Korzystając z warstwy 0, możesz pisać własne testy, poprawki i konfiguracje zabezpieczeń. Nie opierając się na źródłach publicznych, zmniejszasz ryzyko polegania na czymś, co może zostać nieoczekiwanie usunięte.

Aby uznać za dobry przykładowy kod, szablony i moduły powinny przestrzegać dobrych praktyk programistycznych, w tym weryfikacji danych wejściowych pod kątem zabezpieczeń i wymagań organizacji. Aby zachować ten poziom rygoru, należy dodać zasady do głównej gałęzi, aby wymagać żądań ściągnięcia (PRS) i przeglądów kodu dla proponowanych zmian, które mogłyby spowodować zmiany przepływające do głównego rejestru kontenerów w przypadku scalenia.

Warstwa 0 jest dostarczana do usługi Azure Pipelines lub GitHub Actions w celu automatycznego tworzenia artefaktów w wersji w usłudze Azure Container Registry. Automatyzację można utworzyć dla komunikatów zatwierdzeń usługi Git w celu zaimplementowania semantycznej obsługi wersji artefaktów. Aby to działało poprawnie, musisz mieć standard nazewnictwa deterministycznego, taki jak <service.bicep>, aby automatyzacja mogła być utrzymywana wraz z upływem czasu. Przy użyciu odpowiednich zasad gałęzi można również dodać testy integracji jako wymaganie wstępne dla przeglądów kodu. Można to instrumentować za pomocą narzędzi takich jak Pester.

Dzięki takim zasadom i ochronie rejestr kontenerów może być źródłem prawdy dla wszystkich modułów infrastruktury w przedsiębiorstwie, które są gotowe do użycia. Należy rozważyć standaryzację dzienników zmian, a także indeksy dostępnych przykładów kodu, aby umożliwić odnajdywanie tego kodu. Nieznany kod jest nieużywany!

Warstwa 1 — globalna infrastruktura: usługi współużytkowane globalnie

Warstwa 1 to repozytorium konstrukcji strefy docelowej platformy Azure. Podczas gdy firma Microsoft dostarcza szablony na potrzeby wdrażania stref docelowych platformy Azure, należy zmodyfikować niektóre składniki i podać plik parametrów. Jest to analogiczne do sposobu ściągania publicznych rejestrów i repozytoriów modułów do warstwy 0, zgodnie z wcześniejszym opisem.

Screen shot of the contents of the 'infrastructure' and 'policy' folders in layer 1, global infrastructure (globally shared services).

Usługa Azure Container Registry jest krytyczną częścią tej architektury. Nawet jeśli firma nie planuje używania kontenerów, musisz wdrożyć usługę Container Registry, aby pomyślnie wersjonować szablony Bicep. Usługa Container Registry zapewnia znaczną elastyczność i możliwość ponownego obsługi modułów, zapewniając jednocześnie bezpieczeństwo i kontrolę dostępu klasy korporacyjnej.

Warstwa 1 powinna zawierać:

  • Przypisania zasad i definicje, które są stosowane na poziomie grupy zarządzania lub subskrypcji. Te zasady powinny być zgodne z wymaganiami dotyczącymi ładu korporacyjnego.
  • Szablony infrastruktury sieci podstawowej, takie jak ExpressRoute, sieci VPN, wirtualna sieć WAN i sieci wirtualne (udostępnione lub koncentrator).
  • DNS.
  • Podstawowe monitorowanie (analiza dzienników).
  • Rejestr kontenerów przedsiębiorstwa.

Należy skonfigurować ochronę gałęzi, aby ograniczyć możliwość wypychania zmian do tego repozytorium. Ogranicz zatwierdzanie żądania ściągnięcia od innych deweloperów do członków CCoE lub Cloud Governance. Współautorzy tej warstwy są przede wszystkim członkami grup, które są historycznie skojarzone ze składnikami w tej warstwie. Na przykład zespół ds. sieci tworzy szablony dla sieci, zespół operacyjny konfiguruje monitorowanie itd. Należy jednak udzielić dostępu tylko do odczytu osobom, które tego żądają, ponieważ chcesz umożliwić deweloperom z innych grup sugerowanie zmian w podstawowej infrastrukturze. Mogą one przyczynić się do ulepszeń, chociaż nie zezwolisz na scalanie ich zmian bez zatwierdzania i testowania.

Te pliki powinny używać modułów w rejestrze kontenerów dla standardowych składników. Jednak będziesz mieć również plik Bicep lub serię plików Bicep, które są dostosowane do implementacji stref docelowych platformy Azure w przedsiębiorstwie lub podobnej struktury ładu.

Warstwa 2 — platforma produktu: usługi udostępnione

Możesz rozważyć warstwę 2, platformę produktu jako usługi udostępnione dla określonej linii produktu lub jednostki biznesowej. Te składniki nie są uniwersalne w całej organizacji, ale mają odpowiadać konkretnym potrzebom biznesowym. Byłaby to odpowiednia warstwa dla sieci wirtualnej, która jest elementem równorzędnym z koncentratorem w warstwie 1, globalnej infrastruktury. Magazyn kluczy to inny przykładowy składnik dla tej warstwy. Magazyn kluczy może przechowywać wspólne wpisy tajne na koncie magazynu lub bazie danych udostępnionej przez różne aplikacje na tej platformie.

Screen shot of the contents of the 'infrastructure' and 'platform-code' folders in layer 2, product platform (shared services).

Warstwa 2 powinna zawierać:

  • Przypisania zasad, które są stosowane w subskrypcji lub grupie zasobów w celu dopasowania do wymagań specyficznych dla produktu.
  • Szablony usługi ARM dla magazynów kluczy, analizy dzienników, bazy danych SQL (jeśli różne aplikacje w produkcie korzystają z bazy danych) i azure Kubernetes Service.

Należy zaimplementować uprawnienia ograniczające możliwość wypychania zmian do tego repozytorium. Podobnie jak w przypadku innych warstw, należy użyć ochrony gałęzi, aby upewnić się, że główny lub właściciel produktu może zatwierdzić żądania ściągnięcia od innych deweloperów. Nie ma stałych reguł dostępu do odczytu do platformy produktu, ale co najmniej deweloperzy z dowolnego zespołu aplikacji powinni mieć dostęp do odczytu, aby móc sugerować zmiany. Ponieważ warstwa 2 może zawierać zastrzeżoną architekturę lub podobne informacje, możesz ograniczyć dostęp do tych w organizacji, którzy korzystają z platformy. Jeśli jednak tak się stanie, należy upewnić się, że utworzysz proces zbierania dobrych rozwiązań i fragmentów kodu z tego repozytorium, aby udostępnić bibliotekę globalną Warstwy 0.

Warstwa 3 — aplikacja

Warstwa 3, warstwa aplikacji, zawiera składniki, które są oparte na platformie produktu. Te składniki dostarczają funkcje, które żądają firmy. Na przykład w przypadku platformy przesyłania strumieniowego jedna aplikacja może udostępnić funkcję wyszukiwania, podczas gdy inna aplikacja udostępnia zalecenia.

Screen shot of the contents of the 'app' and 'infrastructure' folders in layer 3, applications.

Warstwa 3 powinna zawierać:

  • Kod aplikacji w języku C#, Python itd.
  • Infrastruktura dla poszczególnych składników (używanych tylko w tej aplikacji): funkcje, Azure Container Instances, Event Hubs.

Uprawnienia są ograniczone do możliwości wypychania zmian do tego repozytorium. Należy użyć ochrony gałęzi, aby umożliwić członkom zespołu tej aplikacji zatwierdzenie żądania ściągnięcia przez innego członka zespołu. Członkowie zespołu nie powinni być mogli zatwierdzać własnych zmian. Ponieważ ta warstwa może zawierać zastrzeżoną architekturę, logikę biznesową lub podobne informacje, możesz ograniczyć dostęp do tych w organizacji, którzy tworzą tę aplikację. Jeśli jednak tak jest, należy również utworzyć proces zbierania dobrych rozwiązań i fragmentów kodu z tej warstwy w celu udostępnienia jej w bibliotece globalnej Warstwy 0.

Typowe cechy między warstwami

Chociaż w tym artykule opisano pewne szczegółowe informacje dotyczące każdej warstwy, istnieją również pewne cechy dla wszystkich warstw, które należy wziąć pod uwagę.

Infrastruktura powinna działać tak, jakby była to aplikacja. Oznacza to, że należy mieć proces ciągłej integracji, w którym nowe funkcje są w pełni testowane, z testami jednostkowymi, testami weryfikacyjnymi kompilacji i testami integracji. Należy scalić tylko kod, który przechodzi te testy do głównej gałęzi wydania.

Należy również upewnić się, że obowiązują zasady gałęzi, aby uniemożliwić osobom obejście tego procesu, nawet w celu przyspieszenia. Jeśli proces ciągłej integracji jest postrzegany jako przeszkoda, oznacza to, że ponosisz dług techniczny, który musi być traktowany. Nie oznacza to, że musisz usunąć zasady i zabezpieczenia.

Na koniec, choć może nie istnieć indeks wszystkich repozytoriów i kodu w nich, organizacja powinna opracować proces dla użytkowników indywidualnych w celu żądania dostępu do repozytoriów. Niektóre reguły mogą być w pełni zautomatyzowane. Można na przykład zaimplementować regułę, która udziela dostępu do odczytu bez przeglądu współautorowi, który jest członkiem zespołu produktu dla dowolnej aplikacji w ramach tego produktu. Takie reguły mogą być często implementowane przy użyciu członkostw opartych na grupach i przypisań ról opartych na grupach w środowiskach. Skonfigurowanie tego rodzaju dostępu powinno pomóc w ułatwieniu wewnętrznego określania źródła i wiedzy organizacyjnej.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Autorzy zabezpieczeń:

Inni współautorzy:

Następne kroki