Wprowadzenie

Na tym blogu, pojawiały się już wpisy na temat Terraforma, ale jeszcze nie mieliśmy okazji porozmawiać o Azure Bicep. Czyli rozwiązaniu, które ma zastąpić ARMy oraz konkurować ze wspomnianym już Terraformem. Dzisiaj spojrzymy na możliwości tworzenia modułów oraz odwoływania się do nich w Bicep’ie. Jeżeli temat cię interesuje to zapinamy pasy, siadamy głęboko w fotelach i startujemy.

Azure Bicep

Zacznijmy od tego czym w ogóle jest główny temat naszego wpisu. Azure Bicep jest językiem pozwalającym na deklaratywne tworzenie zasobów w Azure za pomocą kodu.  W pliku w standardzie Bicep, opisujemy infrastrukturę, która powinna zostać stworzona w Azure, a następnie możemy taki plik zintegrować z cyklem życia aplikacji, aby w sposób w pełni zautomatyzowany tworzyć wymaganą infrastrukturę.  W tle, wdrożenie pliku .bicep wymaga przetłumaczenia go na dobrze już nam znaną ARM template(JSON), a następnie wykorzystanie tego ARM’a do stworzenia infrastruktury. Zmienia się tak naprawdę syntax, który w ARM’ie nie był najprzyjemniejszą sprawą, w przypadku Bicep’a dostajemy naprawdę przyjemny produkt, który pozwala tworzyć przejrzyste wzory wdrożeń. W tym przypadku przypomina on bardzo Terraforma i osoby, które pracowały z Terraformem będą miały dużo łatwiej, aby przesiąść się na Bicep’a niż ARM’a.

Moduły w Azure Bicep

Moduły są ważnym aspektem podczas tworzenia infrastruktury z poziomu kodu, po pierwsze zwiększają czytelność kodu, a po drugie pozwalają na tworzenie kawałków kodu, które będą ponownie wykorzystywane w organizacji czy projekcie. Dodatkowo dzięki podejściu modułowym możemy zapewnić, że takie wdrożenie będzie zgodne z naszymi zasadami bezpieczeństwa czy standardami z zakresu nazewnictwa, rozmiaru zasobów i tym podobne. W przypadku ARM Template mieliśmy możliwość wykorzystania „nested templates” które były swego rodzaju modułami, a w przypadku Terraform’a mamy pełnoprawne moduły. Azure Bicep nie pozostaje tutaj bierny i również wprowadza możliwość tworzenia oraz wykorzystywania modułów.

Jak pracować z modułami

Moduły tworzymy w taki sam sposób jak najzwyklejszy plik .Bicep, jedyna różnica, że powinniśmy już tutaj mieć z tyłu głowy, że moduł najprawdopodobniej będzie wykorzystywany wielokrotnie więc jego struktura powinna to odzwierciedlać, oraz pozwalać na modyfikację koniecznych właściwości wdrożenia. Przykładowy kod modułu możemy znaleźć poniżej:

 

//PARAMETERS
@description(’Lokacja w której ma znaleźć się resource group’a’)
param Location string
@description(’Nazwa Resource Group’y’)
param ResourceGroupName string
// SCOPE
targetScope = 'subscription’
// RESOURCES
resource ResourceGroup 'Microsoft.Resources/resourceGroups@2021-04-01′ = {
location: Location
name: ResourceGroupName
}
// OUTPUTS
output ResourceGroupId string = ResourceGroup.id

 

Jak widzimy nasz powyższy moduł składa się z czterech swego rodzaju bloków, w których deklarujemy inne właściwości. Zaczynamy od bloku „Parameters”, w którym deklarujemy nasze parametry, które następnie zostaną wykorzystane przez nasz docelowy kod. Parametry są podawane podczas wykonywania kodu modułu, dzięki czemu osoba korzystająca z modułu jest w stanie za ich pomocą modyfikować wdrożenie. Kolejnym blokiem jest „Scope”, w którym określamy obszar, w którym wdrożenie zostanie uruchomione. Akurat nasz moduł jest specyficzny, ponieważ tworzymy resource group’e, takie wdrożenie musi zostać wykonane na poziomie subskrypcji, jednakże większość wdrożeń za pomocą Azure Bicep’a wykonujemy na poziomie konkretnej Resource Group’y. Najważniejszym punktem naszego modułu jest deklaracja zasobów, to tutaj deklarujemy zasoby, które powinny zostać wdrożone, w naszym przypadku jest to resource group’a, w której wykorzystujemy dwa zadeklarowane parametry-lokacje oraz jej nazwę. Ostatnim blokiem naszego modułu jest kod odpowiedzialny za deklaracje danych wyjściowych, to tutaj deklarujemy, jakie wartości powinny zostać zwrócone z modułu do dalszej pracy. Możemy w taki sposób na przykład przekazać nazwę ID resource group’y, w której następnie będziemy wdrażać kolejne zasoby-co zostanie zaprezentowane w dalszym etapie wpisu.
Z takiego modułu możemy korzystać na wiele sposobów, najprostszym sposobem jest odwoływanie się do modułu lokalnie. Czyli taki moduł musi się znaleźć na lokalnym źródle — przykładowo konkretnym repozytorium czy komputerze. Na daną chwilę Azure Bicep nie wspiera odwoływania się do modułów utrzymanych w innym repozytorium, co utrudnia korzystanie z modułów w większym zakresie niż pojedynczej aplikacji. Aby móc pracować z modułami oraz współdzielić je przykładowo z całą organizacją warto rozważyć poniższe rozwiązania:

 

Publiczny rejestr modułów
Publiczny rejestr modułów Microsoft’u, zawiera moduły, które są stworzone lub zaakceptowane przez Microsoft. Obecnie moduły w tym rejestrze są stworzone tylko i wyłącznie przez pracowników MS’a. Na ten moment w tym rejestrze nie znajduje się wiele modułów, oraz nie istnieje możliwość dodawania zawartości, przez co użyteczność tego rozwiązania na daną chwilę wydaję się wątpliwa. Listę modułów, ich kod oraz repozytorium można znaleźć wchodząc w poniższy odnośnik.

 

Prywatny rejestr modułów
Przechodzimy do drugiego rozwiązania oraz głównego tematu naszego wpisu, czyli prywatnego rejestru modułów, który możemy sami stworzyć oraz nim zarządzać. Taki rejestr bazuje na usłudze „Azure Container Registry” i to właśnie tam utrzymane zostaną moduły oraz zadeklarowane zostaną zasady bezpieczeństwa, oraz uprawnień.
Więcej na ten temat możesz znaleźć w poniższym linku: Create private registry for Bicep module – Azure Resource Manager | Microsoft Docs

 

Wzór utrzymany w Azure
Ostatnią możliwością jest udostępnienie pliku .bicep jako zasobu w Azure. Podobnie jak było to możliwe z ARM Template, jesteśmy w stanie udostępnić nasz plik jako wzór w Azure, a następnie wykorzystać ten plik do wdrożenia. Wdrożenie może odbyć się za pomocą wizualnej formy w portalu albo również za pomocą odwołania się do tego pliku czy to z innego pliku Bicep’a czy np. PowerShell’a.

 

Demo – Azure Container Registry

W dzisiejszym wpisie zajmiemy się rejestrem prywatnym utrzymanym w usłudze Azure Container Registry.

  1. Zaczynamy od stworzenia takiego modułu, my wykorzystamy ten, który omówiliśmy we wcześniejszej części wpisu.
  2. Tworzymy główny plik .Bicep, który wywoła nasz moduł (obecnie, dzieje się to lokalnie).

3. Przetestujmy działanie naszego modułu oraz głównego pliku. Uruchamiamy deployment korzystając z komendy „az deployment sub create –location westeurope –template-file main.bicep –parameters main.param.json”. Po paru chwilach możemy zobaczyć w portalu, że nasze wdrożenie zostało wykonane poprawnie.

4. Teraz zajmijmy się naszym rejestrem. Aby zacząć, musimy stworzyć w Azure zasób Azure Container Registry.

5. Gdy już mamy nasz zasób, będziemy potrzebować odnośnik, który jest powiązany z tym zasobem. Możemy go zlokalizować wyszukując zasób w Azure, w naszym przypadku będzie to: bicepregistrymp.azurecr.io

6. Teraz należy opublikować nasz moduł, robimy to za pomocą komendy „az bicep publish –file example.bicep –target br:exampleregistry.azurecr.io/bicep/modules/name:<tag>”. W naszym przypadku komenda prezentuje się następująco „az bicep publish –file modules/RG.bicep –target br:bicepregistrymp.azurecr.io/bicep/modules/resourcegroup:stable”

7. W momencie, gdy moduł zostanie opublikowany, możemy potwierdzić z poziomu portalu czy faktycznie jest widoczny. Znajdziemy taką informację wchodząc w nasz zasób, a następnie wybierając zakładkę repositories.

8. Pozostaje nam już tylko odwołać się do naszego modułu oraz przetestować działanie. Odwołujemy się za pomocą poniższej struktury:

module name 'br:<registry-name>.azurecr.io/bicep/modules/resourcegroup:stable’

 

 

 

AzureAzure BicepDevOpsIaC
By AZ-104, Azure, Azure Bicep, DevOps2 komentarze do Azure Bicep – Prywatne rejestry modułów

2 Replies to “Azure Bicep – Prywatne rejestry modułów”

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.