Ćwiczenie — publikowanie specyfikacji szablonu

4 min

Twój zespół utworzył pewne pliki Bicep ze wzmocnionymi zabezpieczeniami, które są zgodne z nowym modelem zapewniania ładu w firmie. Jeden z wzmocnionych plików Bicep wdraża aplikację usługi aplikacja systemu Azure Service opartą na systemie Linux. W tym ćwiczeniu użyjesz przepływu pracy wdrażania, aby opublikować plik Bicep jako specyfikację szablonu.

Podczas tego procesu wykonasz następujące czynności:

Dodaj zadanie lint do przepływu pracy.
Dodaj zadanie przepływu pracy, aby opublikować specyfikację szablonu.
Ręcznie uruchom przepływ pracy i sprawdź, czy został pomyślnie zakończony.
Sprawdź opublikowaną specyfikację szablonu na platformie Azure.

Dodawanie zadania lint do przepływu pracy

Repozytorium zawiera wersję roboczą przepływu pracy, którego można użyć jako punktu początkowego.

W programie Visual Studio Code rozwiń folder .github/workflows w katalogu głównym repozytorium.
Otwórz plik template-spec-linux-app-service.yml.

Definicja przepływu pracy zawiera dwa wyzwalacze. W tym ćwiczeniu nie zmodyfikujesz pliku Bicep dla specyfikacji szablonu, więc push wyzwalacz nigdy nie zostanie wyzwolony. Aby wypróbować przepływ pracy, należy go ręcznie wywołać przy użyciu workflow_dispatch wyzwalacza.
W dolnej części pliku zobaczysz komentarz z # To be addedkomunikatem , dodaj następującą definicję zadania lint:
```
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Run Bicep linter
      run: az bicep build --file ${{ env.TEMPLATE_SPEC_FILE_PATH }}
```
Repozytorium zawiera plik bicepconfig.json , który konfiguruje linter tak, aby emitował błędy zamiast ostrzeżeń. Wszelkie błędy podczas zadania lint spowodują niepowodzenie przepływu pracy.

Napiwek

Pliki YAML są wrażliwe na wcięcia. Bez względu na to, czy wpiszesz, czy wklejasz ten kod, upewnij się, że wcięcie jest poprawne. W dalszej części tego ćwiczenia zobaczysz kompletną definicję przepływu pracy YAML, aby sprawdzić, czy plik jest zgodny.

Dodawanie zadania publikowania do przepływu pracy

Teraz możesz dodać drugie zadanie, aby opublikować specyfikację szablonu na platformie Azure.

Dodaj następujący kod na końcu pliku template-spec-linux-app-service.yml :

publish:
  runs-on: ubuntu-latest
  needs: [ lint ]
  steps:
  - uses: actions/checkout@v3
  - uses: azure/login@v1
    name: Sign in to Azure
    with:
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
  - uses: azure/cli@v1
    name: Publish template spec
    with:
      inlineScript: |
        az ts create \
          --resource-group ${{ env.AZURE_RESOURCEGROUP_NAME }} \
          --name ${{ env.TEMPLATE_SPEC_NAME }} \
          --version ${{ github.run_number }} \
          --template-file ${{ env.TEMPLATE_SPEC_FILE_PATH }} \
          --location ${{ env.AZURE_REGION }} \
          --yes

To zadanie sprawdza kod z repozytorium i loguje się do platformy Azure przy użyciu utworzonych wpisów tajnych usługi GitHub. Następnie uruchamia az ts create polecenie , aby opublikować specyfikację szablonu na platformie Azure.

Napiwek

Aby zachować prostotę, przepływ pracy używa numeru przebiegu przepływu pracy jako numeru wersji specyfikacji szablonu. W następnej lekcji dowiesz się więcej o bardziej złożonym schemacie przechowywania wersji.

Zapisz zmiany w pliku.

Weryfikowanie i zatwierdzanie definicji przepływu pracy

Sprawdź, czy plik template-spec-linux-app-service.yml wygląda następująco:

name: template-spec-linux-app-service
concurrency: template-spec-linux-app-service

on:
  workflow_dispatch:
  push:
    branches:
      - main
    paths:
      - 'template-specs/linux-app-service/**'

permissions:
  id-token: write
  contents: read

env:
  AZURE_RESOURCEGROUP_NAME: ToyReusable
  AZURE_REGION: westus3
  TEMPLATE_SPEC_NAME: linux-app-service
  TEMPLATE_SPEC_FILE_PATH: template-specs/linux-app-service/main.bicep

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Run Bicep linter
      run: az bicep build --file ${{ env.TEMPLATE_SPEC_FILE_PATH }}

  publish:
    runs-on: ubuntu-latest
    needs: [ lint ]
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      name: Sign in to Azure
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - uses: azure/cli@v1
      name: Publish template spec
      with:
        inlineScript: |
          az ts create \
            --resource-group ${{ env.AZURE_RESOURCEGROUP_NAME }} \
            --name ${{ env.TEMPLATE_SPEC_NAME }} \
            --version ${{ github.run_number }} \
            --template-file ${{ env.TEMPLATE_SPEC_FILE_PATH }} \
            --location ${{ env.AZURE_REGION }} \
            --yes

Jeśli tak nie jest, zaktualizuj go tak, aby był zgodny z tym przykładem, a następnie zapisz go.

Zatwierdź i wypchnij zmiany do repozytorium Git, uruchamiając następujące polecenia w terminalu programu Visual Studio Code:
```
git add .
git commit -m "Add lint and publish jobs to Linux App Service template spec workflow"
git push
```
Jest to pierwsze wypchnięcie do tego repozytorium, więc może zostać wyświetlony monit o zalogowanie się.

W systemie Windows wpisz 1 , aby uwierzytelnić się przy użyciu przeglądarki internetowej, a następnie wybierz Enter.

W systemie macOS wybierz pozycję Autoryzuj.
Pojawi się okno przeglądarki. Może być konieczne ponowne zalogowanie się do usługi GitHub. Wybierz pozycję Autoryzuj.

Wyzwalanie przepływu pracy

W przeglądarce wybierz kartę Akcje .

Przebiegi przepływu pracy, które zakończyły się niepowodzeniem, są już wymienione, ale nie musisz się nimi martwić. Przebiegi nie powiodły się, ponieważ definicje przepływu pracy nie zostały jeszcze ukończone podczas tworzenia repozytorium.
Wybierz przepływ pracy template-spec-linux-app-service, wybierz przycisk Uruchom przepływ pracy, a następnie wybierz pozycję Uruchom przepływ pracy.

Usługa GitHub uruchamia nowy przebieg przepływu pracy. Może być konieczne odświeżenie okna przeglądarki, aby zobaczyć, że zostanie wyświetlony przebieg.
Wybierz najnowszy przebieg na liście.

Poczekaj na zakończenie przebiegu przepływu pracy. Gdy tak się stanie, specyfikacja szablonu zostanie opublikowana na platformie Azure.
Zwróć uwagę na numer przebiegu przepływu pracy, który prawdopodobnie wynosi 2.

Przeglądanie specyfikacji szablonu na platformie Azure

Możesz również wyświetlić opublikowaną specyfikację szablonu w witrynie Azure Portal.

W przeglądarce przejdź do witryny Azure Portal.
Przejdź do grupy zasobów ToyReusable i wybierz specyfikację szablonu linux-app-service .
Sprawdź szczegóły specyfikacji szablonu.

Zwróć uwagę, że numer najnowszej wersji i wersji jest taki sam jak numer uruchomienia przepływu pracy. Przepływ pracy używa numeru przebiegu dla numeru wersji specyfikacji szablonu.