Lint a ověření kódu Bicep

  • 5 min

Teď, když víte, jaké úlohy pracovního postupu jsou, zvažme první sadu ověřovacích kroků, které můžete přidat do pracovního postupu nasazení Bicep. V této lekci se dozvíte o ověřování šablon Bicep. Dozvíte se také o dvou aktivitách ověřování, které se běžně používají: lintování a předběžné ověření.

Co je platný soubor Bicep?

Platný soubor Bicep neobsahuje žádné chyby syntaxe. Definice prostředků Azure, které plánujete nasadit, jsou také platné. A když se nasadí prostředky definované v souboru, zůstanou v rámci kvót a omezení, které existují ve vašem předplatném Azure.

Některé kontroly se v souboru Bicep provádějí izolovaně, například kontroly chyb syntaxe, platné definice prostředků Azure a kvalitu kódu. Tyto kroky jsou součástí procesu označovaného jako lintování. Pokud chcete zkontrolovat další problémy, musíte požádat, aby služba Azure Resource Manager vaši šablonu ověřila a zohlednila vaše prostředí Azure.

Platná šablona Bicep má větší šanci na úspěšné nasazení. Zpětnou vazbu získáte bez skutečného nasazení šablony Bicep. Ověření je dobrým postupem, protože pokud nasadíte soubor Bicep, který není platný, Azure může nasadit nebo změnit jenom podmnožinu prostředků popsaných v šabloně. Částečné nasazení může znamenat, že stav vašeho prostředí je nekonzistentní a nemusí se chovat očekávaným způsobem.

Sestavování a lintování kódu Bicep

Když nasadíte soubor Bicep, nástroje Bicep nejprve spustí některé základní kroky ověření. Tyto kroky jsou stejné, které se spouštějí při úpravě souboru pomocí editoru Visual Studio Code. Zkontrolují, jestli jste správně použili klíčová slova jazyka Bicep a že jste definovali prostředky Azure podle požadavků pro jednotlivé typy prostředků.

Kromě toho Bicep spustí linter přes vaše soubory. Linting je proces kontroly kódu proti sadě doporučení. Linter Bicep se podívá na váš soubor a ověří, že jste postupovali podle osvědčených postupů pro zachování, správnost, flexibilitu a rozšiřitelnost.

Linter obsahuje předdefinovanou sadu pravidel pro každou z těchto kategorií. Mezi příklady pravidel linteru patří:

  • Nepoužité parametry Linter vyhledá všechny parametry, které se nepoužívají nikde v souboru Bicep. Odstraněním nepoužívaných parametrů usnadníte nasazení šablony, protože nemusíte zadávat nepotřebné hodnoty. Můžete také omezit nejasnosti, když se někdo pokusí pracovat s vaším souborem Bicep.
  • Interpolace řetězců Linter zkontroluje, jestli váš soubor místo interpolace řetězců Bicep používá concat() funkci. Interpolace řetězců usnadňuje čtení souborů Bicep.
  • Výchozí hodnoty pro zabezpečené parametry Linter vás upozorní, pokud nastavíte výchozí hodnoty pro parametry označené dekorátorem @secure() . Nastavení výchozích hodnot pro zabezpečené parametry je špatným postupem, protože poskytuje zabezpečený parametr hodnotu čitelnou pro člověka a uživatelé ho nemusí před nasazením změnit.

Linter Bicep se spustí automaticky při použití nástrojů Bicep. Pokaždé, když sestavíte soubor Bicep, linter zkontroluje jeho osvědčené postupy. K této kontrole dochází automaticky při nasazení souboru Bicep do Azure.

V pracovním postupu ale obvykle chcete před nasazením souboru spustit ověřovací a lintovací kroky. Bicep můžete říct, aby soubor ověřil ručním sestavením souboru Bicep prostřednictvím rozhraní příkazového řádku Bicep:

az bicep build --file main.bicep

bicep build main.bicep

Poznámka:

Když spustíte build příkaz, Bicep také transpiluje kód Bicep do šablony ARM JSON. Obecně nepotřebujete soubor, který výstupuje, takže ho můžete ignorovat.

Vzhledem k tomu, že chcete, aby se šablony Bicep lintovaly při každém vrácení kódu do úložiště, můžete do pracovního postupu přidat úlohu lint:

Diagram znázorňující pracovní postup s úlohou lint obsahující jedinou úlohu, která spouští linter v souboru

Tento doplněk vyjadřujete v souboru YAML pracovního postupu takto:

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - script: |
        az bicep build --file deploy/main.bicep

Upozornění a chyby linteru

Ve výchozím nastavení linter vygeneruje upozornění, když zjistí, že soubor Bicep porušuje pravidlo. Upozornění, že se linter Bicep nechovají jako chyby, takže nezastaví spuštění pracovního postupu ani nezastaví spuštění následných úloh.

Toto chování můžete změnit tak, že nakonfigurujete Bicep tak, aby zacházeli s porušením pravidel linteru jako s chybami místo upozornění. Tuto konfiguraci provedete přidáním souboru bicepconfig.json do složky, která obsahuje váš soubor Bicep. Můžete se rozhodnout, které problémy s linterem by se měly považovat za chyby a které by měly zůstat jako upozornění. Linter nakonfigurujete později v tomto modulu.

Tip

Soubor bicepconfig.json také řídí, jak Visual Studio Code zobrazuje chyby a upozornění v editoru. Zobrazí červenou a žlutou vlnovku pod chybně nakonfigurovanými částmi v šabloně Bicep. Tyto indikátory poskytují ještě rychlejší zpětnou vazbu při psaní kódu Bicep, což dále snižuje pravděpodobnost chyby.

Jakmile překonfigurujete linter tak, aby vygenerovávala chyby, zastaví se váš pracovní postup při každém zjištění problému a následné úlohy se nespustí. Tato konfigurace pomáhá zajistit, že problematický kód Bicep není nasazený.

Předběžné ověření

Měli byste také zkontrolovat, jestli se vaše šablona Bicep pravděpodobně úspěšně nasadí do vašeho prostředí Azure. Tento proces se nazývá předběžné ověření a spouští kontroly, které vyžadují Azure k poskytnutí informací. Mezi tyto druhy kontrol patří:

  • Jsou názvy, které jste zadali pro vaše prostředky Bicep, platné?
  • Jsou názvy, které jste zadali pro vaše prostředky Bicep, už pořízené?
  • Jsou oblasti, na které nasazujete prostředky, platné?

Předběžné ověření vyžaduje komunikaci s Azure, ale ve skutečnosti nenasazuje žádné prostředky.

Diagram znázorňující pracovní postup s lint a ověřením úloh, z nichž každý obsahuje jednu úlohu Ověřená úloha komunikuje s Azure.

Pokud chcete odeslat soubor Bicep k předběžnému ověření, použijte arm-deploy akci a nastavte deploymentMode na :Validate

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - uses: azure/arm-deploy@v1
      name: Run preflight validation
      with:
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        deploymentMode: Validate

Můžete také použít příkaz Azure CLI az deployment group validate .

Předběžné ověření je podobné normálnímu nasazení, ale ve skutečnosti nenasazuje žádné prostředky. Provádí dodatečné kontroly prostředků používaných v šabloně.

Předpokládejme například, že váš soubor Bicep obsahuje účet úložiště. Předběžné ověření zkontroluje, jestli už jiný účet úložiště vzal název, který jste zvolili. Zkontroluje také, jestli název, který jste zvolili pro účet úložiště, splňuje zásady vytváření názvů.

Příkaz předběžného ověření spustí také linter Bicep. Je ale obvykle vhodné spustit linter samostatně. Pokud dojde k nějakým chybám linteru, zjistíte je rychle místo čekání na dokončení procesu ověření. Ověření trvá déle.

Důležité

Když spustíte předběžné ověření, každý z poskytovatelů prostředků Azure provede vlastní kontroly. Někteří poskytovatelé prostředků nespouštějí mnoho kontrol, zatímco jiní provádějí. Proto se nemůžete spolehnout na předběžné ověření, abyste měli jistotu, že je váš soubor platný. Je to ale užitečný nástroj, který stojí za to zahrnout do pracovního postupu.

Přidáním ověřovacích úloh do pracovního postupu pro spuštění linteru a provedením předběžného ověření získáte větší jistotu před nasazením souboru Bicep.