演習 - モジュールをレジストリに発行する

完了

あなたが勤めている玩具会社では、Bicep モジュールをレジストリに発行しています。 発行プロセスは、自分のコンピューターから手動で実行しています。 現在、発行プロセスを処理するパイプラインを作成したいと考えています。

この演習では、以下のことを行います。

  • Bicep モジュール用のコンテナー レジストリを作成します。
  • ワークフローに lint ジョブを追加します。
  • モジュールをレジストリに発行するワークフロー ジョブを追加します。
  • ワークフローが正常に実行されることを確認します。
  • レジストリで発行されたモジュールを確認します。

コンテナー レジストリを作成する

モジュールを発行する前に、組織で使用するレジストリを作成する必要があります。 ここでは、Azure portal を使用してレジストリを作成します。

  1. ブラウザーで、Azure portal 内に新しいコンテナー レジストリを作成します

  2. [基本] タブで、対象のサブスクリプションと前に作成した ToyReusable リソース グループを選択します。

  3. レジストリの名前と近くの場所を入力します。

    重要

    レジストリの名前は Azure 内で一意にする必要があり、英数字で 5 ~ 50 文字にする必要があります。 レジストリ名の横のチェック マークは、選択した名前が使用可能であることを示します。

  4. [SKU] で、 [Basic] を選択します。

    他の構成設定は既定値のままにします。

  5. [Review + create](レビュー + 作成) を選択します。

    Screenshot of the Azure portal that shows the container registry creation page.

  6. "検証に成功しました" という設定の表示を確認し、[作成] を選びます。

    デプロイが完了するまで待ちます。通常は 1 - 2 分かかります。

  7. [デプロイメントに成功しました] というメッセージが表示されたら、[リソースに移動] を選択してコンテナー レジストリを開きます。

    Screenshot of the Azure portal that shows the container registry deployment, with the button for going to a resource highlighted.

  8. コンテナー レジストリの [概要] 領域で、[ログイン サーバー] 設定の値をメモします。 名前は yourregistryname.azurecr.io のような値です。

    Screenshot of the Azure portal that shows the container registry's details, with the login server highlighted.

    この値は、このあとすぐに必要になります。

モジュールのメタデータ ファイルを追加する

前のユニットでは、モジュールのバージョン管理戦略を持つことの重要性について学習しました。 また、モジュールのメタデータ ファイルを使用して、ワークフロー内のモジュールのメジャー バージョン番号とマイナー バージョン番号を指定する方法についても学習しました。 ここでは、ストレージ アカウント モジュールのメタデータ ファイルを追加します。

  1. Visual Studio Code で、リポジトリのルートにある modules/storage-account フォルダーを展開します。

  2. metadata.json という名前の新しいファイルを作成します。

    Screenshot of Visual Studio Code that shows the location of the metadata dot J S O N file.

  3. 次の内容をファイルに追加します。

    {
      "version": {
        "major": 1,
        "minor": 2
      }
    }
    

    メタデータ ファイルでは、メジャー バージョン番号とマイナー バージョン番号を個別に定義していることに注意してください。 ワークフローでは、ワークフローが実行されるたびに、これらの番号とワークフローの実行番号が完全なバージョン番号に結合されます。

  4. ファイルに加えた変更を保存します。

ワークフロー定義を更新して lint ジョブを追加する

リポジトリには、出発点として使用できるワークフローのドラフトが含まれています。

  1. Visual Studio Code で、リポジトリのルートにある .github/workflows フォルダーを展開します。

  2. module-storage-account.yml ファイルを開きます。

    Screenshot of Visual Studio Code that shows the location of the workflow definition file.

  3. 環境変数 MODULE_REGISTRY_SERVER の値をコンテナー レジストリのサーバー名に更新します。 その名前は、この演習の前のほうでコピーしました。

    たとえば、レジストリのログイン サーバーが yourregistryname.azurecr.io の場合、コードは次の例のようになります。

    env:
      MODULE_NAME: storage-account
      MODULE_REGISTRY_SERVER: yourregistryname.azurecr.io
      MODULE_FILE_PATH: modules/storage-account/main.bicep
      MODULE_METADATA_FILE_PATH: modules/storage-account/metadata.json
    
  4. ファイルの下部にある To be added というコメントの場所に、次の lint ジョブの定義を追加します。

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

ワークフローに発行ジョブを追加する

これで、モジュールをコンテナー レジストリに発行する 2 番目のジョブを追加できます。

  1. module-storage-account.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 }}
    

    このステップでは、リポジトリからコードをチェックアウトし、Azure にサインインします。

  2. 追加したコードの下に、モジュールの metadata.json ファイルからバージョン番号を読み取り、環境変数として設定するステップを追加します。

    - name: Get module version number
      run: |
        majorMinorVersionNumber=$(jq '(.version.major | tostring) + "." + (.version.minor | tostring)' ${{ env.MODULE_METADATA_FILE_PATH }} -r )
        versionNumber="$majorMinorVersionNumber.${{ github.run_number }}"
        echo "MODULE_VERSION=$versionNumber" >> $GITHUB_ENV
    

    このステップでは、jq コマンドライン アプリケーションを使用して JSON ファイルを解析するスクリプトを実行します。

  3. 作成したステップの後に、モジュールをレジストリに発行するステップを追加します。

    - uses: azure/cli@v1
      name: Publish module
      with:
        inlineScript: |
          az bicep publish \
            --target 'br:${{ env.MODULE_REGISTRY_SERVER }}/${{ env.MODULE_NAME }}:${{ env.MODULE_VERSION }}' \
            --file ${{ env.MODULE_FILE_PATH }}
    

    このステップでは、--target 引数の値が動的に生成されます。 レジストリ サーバーの値、モジュール名、バージョン番号が組み合わされます。

  4. ファイルに加えた変更を保存します。

ワークフロー定義を検証してコミットする

  1. module-storage-account.yml ファイルが、次の例のようになっていることを確認します。

    name: module-storage-account
    concurrency: module-storage-account
    
    on:
      workflow_dispatch:
      push:
        branches:
          - main
        paths:
          - 'modules/storage-account/**'
    
    permissions:
      id-token: write
      contents: read
    
    env:
      MODULE_NAME: storage-account
      MODULE_REGISTRY_SERVER: yourregistryname.azurecr.io
      MODULE_FILE_PATH: modules/storage-account/main.bicep
      MODULE_METADATA_FILE_PATH: modules/storage-account/metadata.json
    
    jobs:
      lint:
        runs-on: ubuntu-latest
        steps:
        - uses: actions/checkout@v3
        - name: Run Bicep linter
          run: az bicep build --file ${{ env.MODULE_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 }}
        - name: Get module version number
          run: |
            majorMinorVersionNumber=$(jq '(.version.major | tostring) + "." + (.version.minor | tostring)' ${{ env.MODULE_METADATA_FILE_PATH }} -r )
            versionNumber="$majorMinorVersionNumber.${{ github.run_number }}"
            echo "MODULE_VERSION=$versionNumber" >> $GITHUB_ENV
        - uses: azure/cli@v1
          name: Publish module
          with:
            inlineScript: |
              az bicep publish \
                --target 'br:${{ env.MODULE_REGISTRY_SERVER }}/${{ env.MODULE_NAME }}:${{ env.MODULE_VERSION }}' \
                --file ${{ env.MODULE_FILE_PATH }}
    

    そのようになっていない場合は、この例に一致するように更新してから保存してください。

  2. Visual Studio Code ターミナルで次のコマンドを実行し、変更をコミットして Git リポジトリにプッシュします。

    git add .
    git commit -m "Add lint and publish jobs to storage account module workflow"
    git push
    

ワークフローをトリガーする

  1. ブラウザーで、GitHub リポジトリに移動し、[アクション] タブを選択します。

  2. [module-storage-account] ワークフローを選択します。

    ワークフローの実行が既に進行中であることに注意してください。 モジュールのフォルダー内の metadata.json ファイルを変更したためにプッシュ トリガーが発生しました。

  3. 一覧で最新の実行を選択します。

    Screenshot of GitHub that highlights the latest run of the module's workflow.

    ワークフロー実行が完了するまで待ちます。 Bicep モジュールがコンテナー レジストリに発行されます。

    ワークフローの実行番号 (おそらく 3) をメモします。

レジストリ内のモジュールを確認する

発行されたモジュールは、Azure portal で表示することもできます。

  1. ブラウザーで、Azure portal に移動します。

  2. ToyReusable リソース グループに移動します。

  3. 前に作成したコンテナー レジストリを選択します。

  4. メニューから [リポジトリ] ペインを選択します。 次に、ワークフローで発行されたモジュールを表す [modules\storage-account] リポジトリを選択します。

    Screenshot of the Azure portal that shows a Bicep module in the container registry.

    ワークフローで発行されたモジュールのバージョン番号と一致する 1 つの "タグ"があることに注意してください。 メジャー バージョン (1) とマイナー バージョン (2) は、 metadata.json ファイルで定義したバージョン番号と一致します。 リビジョン番号 (3) は、ワークフローの実行番号と一致します。

リソースのクリーンアップ

これで演習が完了したので、課金されないようにリソースを削除しましょう。

Visual Studio Code ターミナルで、次のコマンドを実行します。

az group delete --resource-group ToyReusable --yes --no-wait

バックグラウンドでリソース グループが削除されます。

Remove-AzResourceGroup -Name ToyReusable -Force

また、GitHub のシークレットとリポジトリ、Azure ワークロード ID を削除することもできます。

  • GitHub シークレット

    1. GitHub リポジトリから、[設定]>[シークレットと変数]>[アクション] の順に移動します。
    2. 各リポジトリ シークレットの [シークレットの削除] を選択し、プロンプトに従います。
  • GitHub リポジトリ

    1. [設定]>[全般] に移動します
    2. [このリポジトリを削除する] を選択し、プロンプトに従います。
  • Azure アプリ登録のフェデレーション資格情報とサービス プリンシパル。

    1. ポータルのホーム ページで、Azure Active Directory を検索し、[サービス] の一覧からそれを選択します。
    2. [管理]>[アプリの登録] に移動します。
    3. [所有しているアプリケーション]toy-reusable を選びます。
    4. [削除] を選択し、プロンプトに従います。
    5. [削除されたアプリケーション] を選択して、アプリの登録を完全に削除します。

    重要

    アプリ登録とサービス プリンシパル名が重複している可能性があります。 アプリケーション ID を確認して、正しいリソースを削除していることを確認することをお勧めします。