Wprowadzenie

Infrastruktura jako kod (IaC) to praktyka definiowania zasobów w chmurze i zarządzania nimi za pomocą plików konfiguracji z możliwością odczytu maszynowego, a nie za pomocą ręcznego wybierania lub nieplanowanych skryptów w portalu. Zamiast logować się do portalu Azure w celu utworzenia sieci wirtualnej, należy napisać plik opisujący sieć. Następnie narzędzie odczytuje ten plik i tworzy zasób.

Takie podejście ma fundamentalną zmianę sposobu zarządzania infrastrukturą. Zmiany są śledzone w kontroli wersji, wdrożenia są powtarzalne, a środowiska można odtworzyć od podstaw w dowolnym momencie. Jeśli coś się zepsuje, możesz przywrócić poprzedni stan. Jeśli potrzebujesz środowiska przejściowego, które dubluje środowisko produkcyjne, zastosujesz te same pliki z różnymi parametrami.

IaC wprowadza infrastrukturę do tej samej dyscypliny inżynieryjnej, co kod aplikacji. Te same przepływy pracy związane z pull requestami, przeglądy kodu i zautomatyzowane praktyki testowania, które mają zastosowanie do aplikacji, mogą teraz dotyczyć systemów, na których działa Twoja aplikacja.

Bez pomocy sztucznej inteligencji cykl tworzenia infrastruktury jako kodu (IaC) wygląda następująco:

1. Pisanie szablonu
2. Wyszukaj dokumentację
3. Poprawiono składnię
4. Weryfikowanie lokalnie
5. Uruchom analizę warunkową
6. Wdrażanie w środowisku przejściowym
7. Przeglądanie zmian
8. Wdrażanie w środowisku produkcyjnym

Powtórz to samo dla każdego wdrożenia, niezależnie od tego, czy jest to nowe, czy zaktualizowane.

Cele nauczania

Po ukończeniu tego modułu możesz wykonywać następujące czynności:

• Wyjaśnienie, czym jest infrastruktura jako kod i dlaczego ma znaczenie w nowoczesnych operacjach w chmurze
• Opis różnicy między podejściami deklaratywnymi i imperatywnymi do IaC
• Identyfikowanie tradycyjnego przepływu pracy tworzenia IaC i jego punktów problematycznych
• Wyjaśnienie, jak GitHub Copilot zmienia pętlę wewnętrzną IaC
• Opis możliwości GitHub Copilot, które są najbardziej istotne w pracy z infrastrukturą

Wyzwania związane z infrastrukturą jako kodem

Każdy krok ma tarcie. Pisanie szablonu Bicep od podstaw wymaga znajomości typów zasobów, wersji interfejsu API, wymaganych właściwości i konwencji nazewnictwa specyficznych dla Azure. Wyszukiwanie prawidłowej wersji interfejsu API dla Microsoft.Network/virtualNetworks oznacza nawigowanie po dokumentacji lub kopiowanie z poprzednich projektów. Błędy składni są przechwytywane po uruchomieniu polecenia kompilacji. A aktualizowanie szablonów w miarę rozwoju interfejsów API Azure jest ciągłym obciążeniem konserwacyjnym.

Wynikiem jest to, że IaC jest często traktowana jako specjalistyczna umiejętność. Inżynierowie, którzy regularnie nie piszą szablonów, wracają do wyboru portalu, przerywając spójność, którą ma zapewnić IaC.

Podejście deklaratywne a imperatywne

Istnieją dwa podstawowe style IaC. Zrozumienie różnicy pomaga wybrać odpowiednie narzędzie i tworzyć lepsze zapytania dla GitHub Copilot.

Deklaratywność IaC

W podejściu deklaratywnym opisano żądany stan końcowy infrastruktury. Narzędzie ustala, jak się tam dostać.

Chcę mieć jedną sieć VNet z przestrzenią adresową 10.0.0.0/16 i dwiema podsieciami.

Azure Bicep i szablony usługi ARM są deklaratywne. Definiujesz, jakie zasoby powinny istnieć, a Azure Resource Manager obsługuje sekwencjonowanie i tworzenie. Jeśli zasób już istnieje w prawidłowym stanie, nie zostaną zastosowane żadne zmiany. Jeśli nie istnieje, zostanie utworzony. Jeśli jest inna, zostanie zaktualizowana.

Imperatywne IaC

W podejściu imperatywnym opisano kroki wymagane do osiągnięcia żądanego stanu. Piszesz procedurę, a nie deklarację.

"Sprawdź, czy sieć wirtualna istnieje. Jeśli nie, uruchom polecenie az network vnet create...."

skrypty Azure CLI i Azure PowerShell są zwykle imperatywne. Możesz kontrolować przepływ, obsługiwać błędy i zarządzać kolejnością samodzielnie. Zapewnienie większej kontroli, ale także większej odpowiedzialności. Obejmuje to obsługę idempotencji, co oznacza, że skrypt musi być bezpieczny do wielokrotnego uruchamiania.

Którego z nich należy użyć?

Właściwy wybór zależy od scenariusza. Narzędzia deklaratywne, takie jak Bicep, są lepsze do zarządzania długotrwałymi zasobami infrastruktury, ponieważ automatycznie obsługują stan i dryf. Narzędzia imperatywne, takie jak skrypty interfejsu wiersza polecenia, są lepsze w przypadku zadań operacyjnych, jednorazowych kroków konfiguracji lub automatyzacji, które obejmują logikę, warunki i pętle.

W praktyce większość inżynierów chmury używa obu tych rozwiązań. A GitHub Copilot również pomaga w obu tych przypadkach.

Jak GitHub Copilot zmienia proces tworzenia szablonu

GitHub Copilot skraca i upraszcza każdy krok cyklu tworzenia IaC.

W przypadku etapu pisania Copilot generuje pełne definicje zasobów na podstawie opisów języka naturalnego. Zamiast wyszukiwać składnię Bicep dla zasobu Azure, opisujesz, czego potrzebujesz, a Copilot tworzy punkt początkowy w kilka sekund.

W etapie przeglądu Copilot może analizować istniejący szablon i identyfikować luki w zabezpieczeniach, brakujące właściwości lub nieaktualne wzorce. Działa jako drugi zestaw oczu przed wdrożeniem szablonu.

Na etapie przekształcania Copilot może konwertować między Azure CLI a PowerShell, i między Azure Resource Manager JSON i Bicep, lub między Azure Pipelines a GitHub Actions. Zmniejszenie kosztów przełączania narzędzi lub dostosowanie przykładów z dokumentacji.

W fazie dokumentacji Copilot może odczytać ukończony szablon i wygenerować wyjaśnienia zrozumiałe dla człowieka, odwołania do parametrów oraz opisy architektury. Praca, która jest często pomijana całkowicie, ponieważ jest żmudna do wykonania ręcznie.

Przesunięcie nie dotyczy tylko prędkości. Chodzi o obniżenie bariery wejścia. Inżynierowie, którzy nie są specjalistami Bicep, mogą teraz tworzyć poprawne, dobrze ustrukturyzowane szablony, opisując ich intencje w języku prostym.

GitHub Copilot możliwości pracy z infrastrukturą

GitHub Copilot pojawia się na kilka sposobów w VS Code, z których każdy jest odpowiedni dla różnych części przepływu pracy IaC.

Sugestie wbudowane

Podczas wpisywania pliku .bicep.yaml, .ps1 lub .sh, Copilot oferuje ukończenia w czasie rzeczywistym. Jeśli wpiszesz początek definicji zasobu, Copilot przewiduje resztę. Uwzględnianie wymaganych właściwości, wartości domyślnych i typowych wzorców. Akceptujesz za pomocą Tab lub odrzucasz za pomocą Escape.

Sugestie wbudowane działają najlepiej w przypadku ciągłych wzorców, które zostały już ustalone w pliku. Jeśli zdefiniujesz jeden zasób poprawnie, Copilot pobiera strukturę i sugeruje podobne zasoby w tym samym stylu.

Czat Copilot

Copilot czat (Ctrl+Alt+I) to interfejs konwersacji, w którym można zadawać pytania, opisywać, co chcesz skompilować, wkleić istniejący kod do przeglądu lub zażądać wyjaśnień.

Czat jest lepszy niż sugestie wbudowane dla zadań wymagających większego kontekstu. Przykłady, takie jak generowanie całego szablonu od podstaw, refaktoryzacja złożonego pliku lub prośba o wyjaśnienie sposobu działania zasobu.

Copilot z protokołem MCP (Model Context Protocol)

McP umożliwia Copilot nawiązywanie połączenia z zewnętrznymi narzędziami i źródłami danych. Serwer Bicep MCP zapewnia Copilot dostęp do dynamicznych definicji typów Bicep, bieżących wersji interfejsu API i reguł walidacji. Sprawienie, że dane wyjściowe Bicep są bardziej dokładne niż jest w stanie uzyskać wyłącznie z danych treningowych.

Dlaczego usługa IaC jest dobrze odpowiednia do pomocy w zakresie sztucznej inteligencji

Definicje infrastruktury mają cechy, które sprawiają, że są dobrymi kandydatami do generowania wspomaganego przez sztuczną inteligencję:

• Są one wysoce ustrukturyzowane: definicje zasobów są zgodne ze schematami. Właściwości są oparte na znanych typach, prawidłowych wartościach i wymaganych/opcjonalnych oznaczeniach. Ten ustrukturyzowany charakter ułatwia modelowi tworzenie syntaktycznie poprawnych danych wyjściowych.
• Są bogate we wzorce: Większość wdrożeń Azure korzysta ze stosunkowo małego zestawu typowych typów zasobów: sieci wirtualnych, kont magazynowych, zasobów obliczeniowych i usług tożsamości. Wzorce te pojawiają się często w danych treningowych, co oznacza, że Copilot opiera się na wielu przykładach.
• Przeprowadzenie ręcznych badań jest kosztowne: znalezienie poprawnej kombinacji wersji API, wymaganych właściwości i prawidłowych SKU dla nieznanego typu zasobu może zająć dużo czasu. Copilot kompresuje to badanie w propozycję.
• Są one bezpieczne do iterowania: sprawdzasz poprawność przed wdrożeniem. Niewłaściwa sugestia z Copilot jest przechwycona na az bicep build lub what-if przed dotknięciem jakichkolwiek rzeczywistych zasobów. Ta sieć bezpieczeństwa zachęca do eksperymentowania.

Najważniejsze wnioski

• IaC traktuje infrastrukturę jako kod: kontrola wersji, powtarzalne i weryfikowalne.
• Narzędzia deklaratywne, takie jak Bicep, opisują pożądany stan końcowy; narzędzia imperatywne, takie jak CLI, opisują kroki prowadzące do tego celu.
• Tradycyjny przepływ pracy IaC ma znaczne tarcia na każdym etapie. Copilot zmniejsza te trudności.
• GitHub Copilot pomaga za pomocą wbudowanych sugestii, Copilot Chat i kontekstu rozszerzonego MCP.
• Usługa IaC jest dobrze odpowiednia dla pomocy w zakresie sztucznej inteligencji, ponieważ jest ona ustrukturyzowana, bogata w wzorce i bezpieczna do iterowania.