Czym jest infrastruktura jako kod?
Poproszono Cię o ocenę, czy infrastruktura jako kod może być cenną metodą aprowizacji zasobów w firmie. Przeglądasz dostępne opcje wdrażania, w tym:
- Azure Portal
- Interfejs wiersza polecenia platformy Azure
- Azure PowerShell
- Szablony usługi Azure Resource Manager (JSON i Bicep)
Szukasz powtarzalnej opcji i musisz zdecydować, której technologii użyć do wdrożenia infrastruktury platformy Azure.
W tej lekcji dowiesz się, jak i dlaczego infrastruktura jako kod może pomóc w wdrożeniu infrastruktury platformy Azure w zautomatyzowany i powtarzalny sposób.
Polecenia interfejsu wiersza polecenia platformy Azure służą do zilustrowania pojęć. Dowiedz się więcej na temat używania poleceń do wdrażania zasobów w innych modułach ścieżki szkoleniowej Bicep.
Definiowanie infrastruktury jako kodu
Twoja firma projektuje nowe zabawki do wydania na rynek, a większość nowych zabawek wymaga pewnego montażu po zakupie. Zespół projektowy firmy tworzy instrukcje obsługi dołączane do każdej toki. Każdy podręcznik zawiera szczegółowe informacje na temat prawidłowego montażu toy.
Możesz traktować infrastrukturę jako kod jako instrukcję obsługi dla infrastruktury. Instrukcje ręczne zawierają szczegółowe informacje na temat końcowej konfiguracji zasobów i sposobu uzyskiwania dostępu do tego stanu konfiguracji.
Infrastruktura jako kod to proces automatyzacji aprowizacji infrastruktury. Używa on opisowego języka kodowania i systemu przechowywania wersji, który jest podobny do tego, co jest używane w kodzie źródłowym. Podczas tworzenia aplikacji kod źródłowy generuje ten sam wynik za każdym razem, gdy ją skompilujesz. W podobny sposób wdrożenia infrastruktury jako kodu są zautomatyzowane, spójne i powtarzalne. Infrastruktura jako kod umożliwia zautomatyzowanie wdrożeń zasobów infrastruktury, takich jak sieci wirtualne, maszyny wirtualne, aplikacje i magazyn.
Jeśli pamiętasz podręcznik obsługi dla nowej toy, istnieje wiele sposobów na napisanie instrukcji ręcznej. Jedną z opcji jest wyszczególnienie każdego kroku procesu kompilacji. Kolejną opcją jest pokazanie eksplodowanego widoku elementów i części potrzebnych do montażu toy. W dalszej części tej lekcji dowiesz się więcej o różnicach między kodem imperatywnego i deklaratywnego oraz o tym, jak odnoszą się one do podręczników obsługi firmy.
Dlaczego warto używać infrastruktury jako kodu?
Wdrożenie infrastruktury jako podejścia kodu zapewnia wiele korzyści związanych z aprowizowaniem zasobów. Infrastruktura jako kod umożliwia:
- Zwiększ zaufanie do wdrożeń.
- Zarządzanie wieloma środowiskami.
- Lepiej zrozumieć zasoby w chmurze.
Zwiększ pewność
Jedną z zalet korzystania z infrastruktury jako kodu jest poziom pewności, który zyskujesz we wdrożeniach, od ulepszeń spójności i zabezpieczeń.
Integracja z bieżącymi procesami: jeśli twoja organizacja korzysta już ze standardowych praktyk programistycznych, możesz wdrożyć te same procesy dla wdrożeń infrastruktury. Na przykład przeglądy równorzędne mogą pomóc w wykrywaniu problemów w konfiguracjach, które mogą być trudne do wykrycia podczas wprowadzania zmian ręcznych.
Spójność: wdrożenie infrastruktury jako podejścia do kodu pomaga zespołowi śledzić dobrze ugruntowane procesy wdrażania infrastruktury. Postępując zgodnie z tymi procesami, odpowiedzialność przechodzi od małej grupy osób do procesu automatyzacji i narzędzi. Infrastruktura jako kod pomaga zmniejszyć błąd człowieka w aprowizacji zasobów i zapewnić spójne wdrożenia.
Automatyczne skanowanie: konfiguracje infrastruktury jako kodu można skanować za pomocą zautomatyzowanych narzędzi, które mogą sprawdzać błędy w kodzie. Zautomatyzowane narzędzia mogą również przeglądać proponowane zmiany w celu zapewnienia, że są przestrzegane praktyki w zakresie zabezpieczeń i wydajności.
Zarządzanie wpisami tajnymi: wiele rozwiązań wymaga wpisów tajnych, takich jak parametry połączenia, klucze szyfrowania, wpisy tajne klienta i certyfikaty. Na platformie Azure usługa Azure Key Vault to usługa używana do bezpiecznego przechowywania tych wpisów tajnych. Wiele narzędzi infrastruktury jako kodu można zintegrować z usługą Key Vault, aby bezpiecznie uzyskiwać dostęp do tych wpisów tajnych podczas wdrażania.
Kontrola dostępu: W przypadku wdrożeń infrastruktury jako kodu masz możliwość używania tożsamości zarządzanych lub kont usług do automatyzowania aprowizacji zasobów. Ten proces gwarantuje, że tylko te tożsamości mogą modyfikować zasoby w chmurze. Pomaga również zapobiegać nieprawidłowym konfiguracjom wdrożonym w środowisku produkcyjnym. W razie potrzeby można przesłonić ten proces przy użyciu konta dostępu awaryjnego (często nazywanego kontem typu break glass) lub za pomocą funkcji Microsoft Entra ID Privileged Identity Management.
Unikaj dryfu konfiguracji: Idempotence jest terminem często skojarzonym z infrastrukturą jako kodem. Gdy operacja jest idempotentna, oznacza to, że zapewnia ten sam wynik przy każdym uruchomieniu. Jeśli wybierzesz narzędzia korzystające z operacji idempotentnych, możesz uniknąć dryfu konfiguracji.
Jako przykład idempotencji rozważ następujące polecenie interfejsu wiersza polecenia platformy Azure. Polecenie tworzy grupę zasobów platformy Azure o nazwie storage-resource-group
w regionie Wschodnie stany USA.
az group create \
--name storage-resource-group \
--location eastus
Jeśli uruchomisz to polecenie po raz drugi, otrzymasz dokładnie te same dane wyjściowe, ponieważ to polecenie interfejsu wiersza polecenia platformy Azure zostało zaprojektowane tak, aby było idempotentne. Nie występuje błąd ani zduplikowana grupa zasobów.
Gdy używasz infrastruktury jako kodu, możesz ponownie wdrożyć środowisko w każdej wersji rozwiązania. Te wersje mogą zawierać niewielkie zmiany konfiguracji, a nawet istotne aktualizacje. Ten proces pomaga uniknąć dryfu konfiguracji. Jeśli w zasobie zostanie wprowadzona przypadkowa zmiana, można ją poprawić przez ponowne wdrożenie konfiguracji. Korzystając z tego podejścia, dokumentujesz środowisko przy użyciu kodu.
Zarządzanie wieloma środowiskami
Wiele organizacji utrzymuje wiele środowisk aplikacji. Deweloperzy w firmie z toy mogą mieć wiele wersji kodu aplikacji przygotowanego w repozytorium do wydania w różnych środowiskach. Środowiska mogą obejmować programowanie, testowanie i produkcję. Niektóre organizacje obsługują wiele środowisk produkcyjnych dla aplikacji, które są dystrybuowane globalnie. Inne organizacje, takie jak niezależni dostawcy oprogramowania (ISV), obsługują wiele środowisk dzierżawy dla swoich klientów.
Poniżej przedstawiono niektóre kluczowe sposoby infrastruktury jako kodu, które mogą pomóc w zarządzaniu środowiskami:
Aprowizuj nowe środowiska: Jedną z głównych zalet przetwarzania w chmurze jest możliwość skalowania. Infrastruktura jako kod może pomóc w skalowaniu do wielu wystąpień aplikacji. Te wystąpienia mogą pomóc w czasie zwiększonego obciążenia lub wdrożyć je dla użytkowników w innych obszarach świata. Ta elastyczność może być również przydatna podczas testowania aplikacji, na przykład podczas testowania penetracyjnego, testowania obciążenia i testowania błędów. Dzięki dobrze zdefiniowanej bazie kodu można dynamicznie aprowizować te nowe środowiska w spójny sposób.
Środowiska nieprodukcyjne: Typowe problemy napotykane przez organizacje różnią się między środowiskami produkcyjnymi i nieprodukcyjnymi. W przypadku ręcznego aprowizowania zasobów w osobnych środowiskach możliwe jest, że konfiguracje końcowe nie są zgodne. Przykładem jest wdrożenie nowej funkcji w środowisku nieprodukcyjnym, które różni się od środowiska produkcyjnego. Istnieje możliwość, że nowa funkcja nie działa zgodnie z oczekiwaniami w środowisku produkcyjnym z powodu różnic między dwoma środowiskami. Użycie infrastruktury jako kodu może pomóc zminimalizować te problemy. Możesz użyć tych samych plików konfiguracji dla każdego środowiska, ale podać różne parametry wejściowe, aby utworzyć unikatowość.
Odzyskiwanie po awarii: w niektórych sytuacjach infrastruktura jako kod może być używana jako część planu odzyskiwania po awarii organizacji. Na przykład może być konieczne ponowne utworzenie środowiska w innym regionie z powodu awarii usługi. Korzystając z infrastruktury jako kodu, można szybko aprowizować nowe wystąpienie w trybie failover zamiast ręcznie wdrażać i ponownie konfigurować wszystko.
Lepsze zrozumienie zasobów w chmurze
Infrastruktura jako kod może pomóc lepiej zrozumieć stan zasobów w chmurze:
Dziennik inspekcji: zmiany konfiguracji infrastruktury jako kodu są kontrolowane w taki sam sposób, jak kod źródłowy aplikacji. Te zmiany są śledzone w narzędziu, na przykład w historii wersji usługi Git. Ten dziennik inspekcji oznacza, że można przejrzeć szczegóły każdej zmiany, która dokonała zmiany i kiedy została wprowadzona zmiana.
Dokumentacja: do dodawania metadanych, takich jak komentarze, które opisują przeznaczenie kodu w konfiguracji, można użyć wielu konfiguracji infrastruktury jako kodu. Jeśli Twoja organizacja jest już zgodna z procesem dokumentacji kodu, rozważ wdrożenie tych samych procedur z kodem infrastruktury.
Ujednolicony system: wiele razy, gdy deweloper pracuje nad nową funkcją, musi wprowadzić zmiany w kodzie aplikacji i kodzie infrastruktury. W przypadku korzystania z wspólnego systemu organizacja może lepiej zrozumieć relację między aplikacjami a infrastrukturą.
Lepsze zrozumienie infrastruktury chmury: jeśli używasz witryny Azure Portal do aprowizacji zasobów, wiele procesów jest abstrahowanych od widoku. Infrastruktura jako kod może pomóc w lepszym zrozumieniu sposobu działania platformy Azure i rozwiązywania problemów, które mogą wystąpić. Na przykład podczas tworzenia maszyny wirtualnej przy użyciu witryny Azure Portal niektóre utworzone zasoby są abstrakcje z widoku. Dyski zarządzane i karty interfejsu sieciowego są wdrażane w tle. Podczas wdrażania tej samej maszyny wirtualnej przy użyciu infrastruktury jako kodu masz pełną kontrolę nad wszystkimi utworzonymi zasobami.
Kod imperatywny i deklaratywny
Instrukcje dotyczące nowego zestawu toy można napisać na różne sposoby. Podczas automatyzowania wdrażania usług i infrastruktury można podjąć dwa podejścia: imperatywne i deklaratywne.
Za pomocą kodu imperatywnego należy wykonać sekwencję poleceń w określonej kolejności, aby osiągnąć konfigurację końcową. Ten proces definiuje, co powinien wykonać kod, i definiuje sposób wykonywania zadania. Podejście imperatywne jest podobne do instrukcji krok po kroku.
W przypadku kodu deklaratywnego należy określić tylko konfigurację końcową. Kod nie definiuje sposobu wykonywania zadania. Podejście deklaratywne jest podobne do instrukcji obsługi eksplodowanej widoku.
W przypadku wyboru między użyciem podejścia imperatywnego a deklaratywnym podejściem do aprowizacji zasobów należy wziąć pod uwagę narzędzia, które mogą już być używane w organizacji. Należy również rozważyć, które podejście może być zgodne z własnymi umiejętnościami.
Kod imperatywny
Na platformie Azure podejście kodu imperatywnego jest realizowane programowo przy użyciu języka skryptowego, takiego jak Bash lub Azure PowerShell. Skrypty wykonują serię kroków, aby utworzyć, zmodyfikować, a nawet usunąć zasoby.
W tym przykładzie przedstawiono dwa polecenia interfejsu wiersza polecenia platformy Azure, które tworzą grupę zasobów i konto magazynu.
#!/usr/bin/env bash
az group create \
--name storage-resource-group \
--location eastus
az storage account create \
--name mystorageaccount \
--resource-group storage-resource-group \
--location eastus \
--sku Standard_LRS \
--kind StorageV2 \
--access-tier Hot \
--https-only true
Pierwsze polecenie tworzy grupę zasobów o nazwie storage-resource-group
w regionie Wschodnie stany USA. Drugie polecenie tworzy konto magazynu o nazwie mystorageaccount
w storage-resource-group
grupie zasobów utworzonej w pierwszym poleceniu. Drugie polecenie konfiguruje również niektóre właściwości konta magazynu, w tym rodzaj konta magazynu i jego warstwę dostępu.
Możesz użyć podejścia imperatywnego, aby w pełni zautomatyzować aprowizację zasobów, ale podejście ma pewne wady. W miarę dojrzewania architektury skrypty mogą stać się złożone do zarządzania. Polecenia mogą być aktualizowane lub przestarzałe, co wymaga przeglądów istniejących skryptów.
Kod deklaratywny
Na platformie Azure podejście do kodu deklaratywnego odbywa się przy użyciu szablonów. Dostępnych jest wiele typów szablonów, w tym:
- JSON
- Bicep
- Ansible, autor: RedHat
- Terraform, autor: HashiCorp
Uwaga
Ten moduł koncentruje się na używaniu szablonów Bicep.
Zapoznaj się z poniższym przykładem szablonu Bicep, który konfiguruje konto magazynu. Konfiguracja konta magazynu jest zgodna z przykładem interfejsu wiersza polecenia platformy Azure.
resource storageAccount 'Microsoft.Storage/storageAccounts@2203-05-01' = {
name: 'mystorageaccount'
location: 'eastus'
sku: {
name: 'Standard_LRS'
}
kind: 'StorageV2'
properties: {
accessTier: 'Hot'
supportsHttpsTrafficOnly: true
}
}
Sekcja zasobów definiuje konfigurację konta magazynu. Ta sekcja zawiera nazwę, lokalizację i właściwości konta magazynu, w tym jego jednostkę SKU i rodzaj konta.
Możesz zauważyć, że szablon Bicep nie określa sposobu wdrażania konta magazynu. Określa tylko to, jak musi wyglądać konto magazynu. Rzeczywiste kroki wykonywane w tle w celu utworzenia tego konta magazynu lub zaktualizowania go w celu dopasowania do specyfikacji pozostawiono, aby platforma Azure zdecydowała.