CI/CDパイプライン：Azure上のデータ処理アプリケーションのためのパート1：コンテナインスタンス

CI/CDパイプライン：Azureでのデータ処理アプリケーションのためのパート1：コンテナインスタンス

The AI Comic Factoryで生成された画像: https://huggingface.co/spaces/jbilcke-hf/ai-comic-factory

GitHub Actionsを使用したDockerコンテナのデプロイのステップバイステップガイド

はじめに

Azureや他のクラウドプロバイダーへのリソースの手動作成とデプロイは比較的簡単で、場合によっては十分だと言えます。しかし、展開されたリソースは通常時間の経過とともに変更が必要となり、それに伴ってリソースのメンテナンスと再デプロイに多くの追加作業が必要となります。これらのタスクを自動化するために、開発者やデータプロフェッショナルはインフラストラクチャとしてのコード（IaC）アプローチを使用して、継続的インテグレーションおよびデプロイ（CI/CD）を行うパイプラインを作成することができます。このアプローチにより、開発者は変更が行われる度にリソースを自動的に定義および再デプロイするコードを記述することができます。

このステップバイステップガイドでは、以下のタスクを実行するためのデータ処理アプリケーションのためのパイプラインを構築します:

コンテナレジストリの作成
Dockerイメージのビルドとレジストリへのプッシュ
データ処理のワークロードを実行するコンテナインスタンスの作成
Azure Key Vaultへの「マネージドアイデンティティ」アクセスの有効化。これにより、アプリケーションはストレージアカウントなどの他のリソースへのアクセスキーを取得することができます。
上記のリソースをテスト環境と本番環境にデプロイするため、パイプラインを実行するための異なるトリガーを有効化する

はじめに

デモンストレーションの目的で、アプリケーション自体は非常にシンプルなRスクリプトで構成されており、データセットをロードし、最初の数行を表示して処理されたデータをストレージアカウントに返します。アプリケーションコードはパイプラインの他の部分には関係ありませんので、独自のコードに簡単に置き換えることができます。

はじめに、Azureアカウントが必要です。また、ローカルシステムにAzure CLIをインストールすることもお勧めします。ただし、Azure CLIコマンドをAzureポータルのクラウドシェルを介して実行することも選択できます。

アプリケーションがAzure Blob Storageとのデータの送受信を行うため、Azure Storage Explorerをインストールすると、ファイルのアップロードやアプリケーションが正しく実行され、処理されたデータが返されるかどうかを確認するのが少し簡単になります。

ステップ1：レポのクローンと静的リソースの設定

最初に、このレポをクローンする必要があります。READMEファイルには、RStudioを使用してこれを行う方法が詳しく説明されていますが、お好みのIDEを使用することもできます。

次に、Azureポータルを使用して以下のリソースを作成します:

他のすべてのリソースを含むリソースグループ
入力ファイル用と出力ファイル用の2つのフォルダを持つブロブコンテナを含むストレージアカウント。この場合、それぞれを「input」と「output」と名付けます。入力コンテナ内に「input_data.csv」という名前のCSVファイルとして小さなデータセットを保存してください。
ストレージアカウントのプライマリアクセスキーを秘密として保存するためのキーバルト

ステップ3では、キーバルトの名前とプライマリアクセスキーが含まれるシークレットの名前が必要になります。

ステップ2：GitHubをAzureにリンクする

Azureリソースを更新するには、GitHubに対してそのパーミッションを付与する必要があります。

まず、Azure CLIを使用してAzureアカウントにログインします。

az login

次に、JSONの出力からidの値をコピーします。これはサブスクリプションIDです。以下のコマンドにサブスクリプションIDを貼り付けて実行します。これにより、GitHub Actionsワークフローを使用してリソースのデプロイや更新を行う際にあなたの代わりに行動するユーザーとしてのロールベースのアクセス制御を持つ「サービスプリンシパル」が作成されます。

az ad sp create-for-rbac \      --name "your-app-name" \      --role Owner \      --scopes /subscriptions/<your-subscription-id>/resourceGroups/<your-resource-group-name> \      --sdk-auth

JSON出力全体をコピーして、GitHubのリポジトリに移動し、設定をクリックしてください。シークレットと変数、アクションをクリックします。

新しいリポジトリシークレットを作成し、AZURE_CREDENTIALSと名前を付けます。上記のコマンドのJSON出力を貼り付けて保存します。

ステップ3：スクリプトの変更

このシナリオでは、あまり多くのことをしないシンプルなRスクリプトをデプロイしています。そのため、Dockerfileも非常にシンプルになっています。これらのファイルは、必要に応じて要件と好きなプログラミング言語に応じて変更する必要があります。ただし、これが初めての場合は、自分のコードを適用する前に、コードをそのまま使用してパイプラインを稼働させることが有益である場合があります。

現在のRスクリプト（script.R）を使用する場合は、次の値を変更する必要があります： {keyvault-name} 、{access-key-name} 、および {storage-account-name} （括弧を省略）。

次に、.github/workflows/ ディレクトリ内の workflow.yml および workflow_release_prod.yml という2つのワークフローファイルの env: の下の次の値を変更します：

env:  RESOURCEGROUP_NAME: my-rg  REGISTRY_NAME: my-cr  SHORT_NAME: mycr  ACI_NAME: my-ci-test  KV_NAME: my-kv  ENVIRONMENT: test  CPU: 1  MEMORY: 1.5

ステップ4：パイプラインとコンテナインスタンスの実行

関連する変更がすべて行われ、 ‘main’ ブランチにプッシュされると、アクションパネルの下でパイプラインが実行されるはずです。このため、ワークフローはブランチトリガーを設定しているため、メインブランチが更新されると実行されます。

エラーが発生しない場合、コンテナインスタンスが10分程度で実行準備が整います。Azureポータルに移動し、新しいコンテナインスタンスを見つけて開始します。ログパネルで、スクリプトがコンソールで実行されるのを見ることができます。完了後、blobコンテナの ‘output’ フォルダに新しいcv-fileと呼ばれるoutput_data.csvが保存されていることを確認してください。

それで終わりです！必要な場合、現在の作業負荷のプロダクション用の同じコンテナインスタンスを作成する2番目のワークフローを手動でトリガーすることができます。

CI/CDパイプラインで何が行われているかを理解するために、以下のセクションをお読みください。

ワークフローのロジックの理解

workflow.ymlファイルでは、テスト環境にリソースをデプロイするパイプラインの5つのステップ、またはジョブが定義されています。

まず、他のステップで必要な環境変数をoutputsとして渡します。

  vars:    runs-on: ubuntu-latest    outputs:      resource_group: ${{ env.RESOURCEGROUP_NAME }}      acr_name: ${{ env.REGISTRY_NAME }}      short_name: ${{ env.SHORT_NAME }}      aci_name: ${{ env.ACI_NAME }}      kv_name: ${{ env.KV_NAME }}      environment: ${{ env.ENVIRONMENT }}      cpu: ${{ env.CPU }}      memory: ${{ env.MEMORY }}    steps:      - run: echo "Exposing env vars"

ステップ2では、コンテナレジストリを作成または更新します。 needsキーは、このステップが前のステップの完了を待つ必要があることを示しています。 usesキーは、このステップで別のファイルが使用されることを示しており、withキーは必要な値を渡すために使用されます。また、リポジトリシークレットも渡す必要があります。

  deploy-acr:    needs: vars    uses: ./.github/workflows/deploy_acr.yml    if: github.ref == 'refs/heads/main'    with:      environment: ${{ needs.vars.outputs.environment }}      resource_group: ${{ needs.vars.outputs.resource_group }}      acr_name: ${{ needs.vars.outputs.acr_name }}    secrets:      azure_credentials: ${{ secrets.AZURE_CREDENTIALS }}

このステップで使用されるdeploy_acr.ymlファイルの先頭部分では、スクリプトがワークフローで呼び出されるたびに実行されることと、workflow.ymlファイルで指定した必須の入力が表示されます。

on:   workflow_call:    inputs:      environment:        required: true        type: string      resource_group:        required: true        type: string      acr_name:        required: true        type: string    secrets:      azure_credentials:        required: true

deploy_acr.ymlの下部では、3つの定義済みアクションを実行するマルチステッププロセスが実行されています。最初のアクションではリポジトリをチェックアウトし、次に作成して保存したサービスプリンシパルの認証情報を使用してAzureにログインします。最後に、azure/arm-deploy@v1というアクションを使用してコンテナレジストリをデプロイします。このステップでは、Azureリソースの構成とデプロイに使用される人気のある言語であるBicepを使用しています。この記事の下部には、Bicepについての追加リソースをいくつか紹介しています。

jobs:  deploy-acr:    name: ACRのデプロイ    runs-on: ubuntu-latest    environment: ${{ inputs.environment }}    steps:      - uses: actions/checkout@v2      - uses: azure/login@v1        with:          creds: ${{ secrets.azure_credentials }}      - name: Bicepのデプロイ        uses: azure/arm-deploy@v1        with:          resourceGroupName: ${{ inputs.resource_group }}          template: bicep/acr.bicep          parameters:            acrName=${{ inputs.acr_name }}            acrSku=Basic          failOnStdErr: false

その後、Dockerイメージは3番目のステップでbuild_push_container.ymlというファイルを使用してレジストリにビルドおよびプッシュされます。このステップでは、Containerレジストリのクレデンシャルを取得するためのAzure CLIコマンドと、Dockerコマンドを使用してDockerイメージをビルドおよびプッシュします。

4番目のステップでは、Dockerイメージに基づいてコンテナインスタンスがプロビジョニングされます。このステップは、deploy_aci.ymlというファイルを使用して実行され、さらに予め定義された「azure/aci-deploy@v1」というアクションを使用します。

最後のステップでは、kv_access.ymlというファイルを使用して、コンテナインスタンスに「マネージドアイデンティティ」を通じたキーボールトへのアクセス許可を付与します。これにより、アクセスキーを使用せずにコンテナがキーボールトから直接シークレットを取得できるようになります。これを実現するために、Azure CLIコマンドaz container createを使用して、デプロイ済みのコンテナインスタンスを更新し、以前に使用したさまざまなパラメーターを指定する必要があります。さらに、次の設定を提供します：

— assign-identity — scope ${{ steps.rg_id_step.outputs.rg_id }}

最後の注意として、workflow.ymlで次の行に気付いたかもしれません：

on:   push:    branches:       - main  workflow_dispatch:

これらの行は、パイプラインがいつどのような条件で実行されるかを示しています。このシナリオでは、パイプラインを「main」ブランチに変更がプッシュされた場合に実行したいとします。さらに、手動で実行できるようにしたい場合、workflow_dispatch:を追加します。ワークフロー_prod_release.ymlで定義された本番パイプラインでは、本番リリースのトリガーは手動のみです。パイプラインの実行トリガーを設定する方法は他にもたくさんあります。たとえば、特定のファイルやフォルダーの変更を無視し、アプリケーションコードの変更だけが新たなデプロイをトリガーするようにすることもできます。