アプリケーション > Pulumiタスク > アプリケーションテンプレートでのCI/CDのセットアップ

アプリケーションテンプレートでのCI/CDのセットアップ¶

スクリプト、アドホックコマンド、またはUIを介してカスタムアプリケーションを手動で管理することは、すぐに煩雑でエラーが発生しやすい作業となりかねません。各デプロイでは、多くの場合、ミスを避けるために、慎重な調整、手順の繰り返し、および継続的なダブルチェックが必要です。このような手作業によるプロセスは、時間の経過とともに、人為的ミスや一貫性のない環境、偶発的なダウンタイムのリスクを増大させる可能性があります。

アプリケーションテンプレートの目的は、独自のアプリケーションを構築するためのブループリントを提供することです。これらのブループリントは「すぐに使える状態」の出発点を提供し、そこからワークフローをカスタマイズし拡張することが可能です。 Codespaceで作業すると、アプリケーションテンプレートの使用を簡単に開始できます。実験段階が進んでいくと、変更内容を基に本番環境レベルのDevOpsを構築することになります。

このチュートリアルでは、2つのソース管理プラットフォーム（GitLab CI/CDパイプラインを備えたGitLabと、GitHub Actionsを備えたGitHub）における継続的インテグレーションおよび継続的デリバリー（CI/CD）の設定方法について説明します。

このチュートリアルの目的は以下のとおりです。

マージリクエストまたはプルリクエストのチェックを有効にし、テスト、静的コード解析、およびリンティングを実施します。
「レビューアプリケーション」を有効にします。これにより、開発者が提案された変更を検証および実証できるよう、ブランチから完全なスタックが専用の名前でデプロイされます。
継続的に更新される共有アプリケーションデプロイへのマージ時に、継続的デリバリーを有効にします。
使用している環境に関係なく、クラウド対応のPulumiのState管理を活用して、共有された安全なPulumiスタック追跡を行う方法を説明します。
CI/CDプラットフォームのシークレットと可変ストレージシステムをアプリケーションテンプレートと統合して、資格情報を安全に管理する方法を紹介します。

このチュートリアルでは、データと会話するエージェントのアプリケーションテンプレートのフォークをベースとして、各プラットフォームでこれらの目標に取り組む方法を説明します。 For Azure DevOps, see Azure DevOps.

GitLabでのマージリクエストのテストとリンターを設定する¶

コードの例

GitLabでのマージリクエストのすべてのコードとライブサンプルは、こちらから入手できます。

CIのテストをローカル開発と同じにするため、Taskを使ってプロセスを単純化します。 Taskは、シンプルな定義を用いたタスク実行のための、互換性があり軽量のツールです。データと会話するエージェントには、Reactフロントエンド向けにPythonとTypeScriptの両方のコンポーネントがあります。Taskにより、環境のセットアップが簡素化され、1つのスペースからアプリケーションテンプレートのすべてを実行できるようになります。

このチュートリアルでは、ルートのTaskfileとReact/Typescript Taskfileを提供します。これらは相互に組み込まれ、.gitlab-ci.ymlで簡単に参照できます。

ルートのTaskfile.ymlにある以下のコードスニペットは、マージリクエストごとの迅速かつ安価なテストとリンティングの概要を示しています。

version: '3'
dotenv:
  - .env
includes:
  react:
    taskfile: ./frontend_react/react_src/Taskfile.yaml
    dir: ./frontend_react/react_src/
tasks:
...
  python-lint:
    desc: 🧹 Lint Python code
    cmds:
        - ruff format .
        - ruff check . --fix
        - mypy --pretty .
  python-lint-check:
    desc: 🧹 Lint Python code with fixes
    cmds:
        - ruff format --check .
        - ruff check .
        - mypy --pretty .
  lint:
    deps:
      - react:lint
      - python-lint
    desc: 🧹 Lint all code
  lint-check:
    deps:
      - react:lint-check
      - python-lint-check
    desc: 🧹 Lint all code

上記のスニペットには、React/Typescript Taskfileが含まれており、そのタスクを取り込み、リンティングのためのPythonタスクを定義します。これで、以下の.gitlab-ci.ymlに示すように、Taskfileからこれらのタスクを使用して、GitLabでリンターを実行するために必要なものを定義できます。

image: cimg/python:3.11-node

before_script:
  - pip install go-task-bin
  - task install
  - source .venv/bin/activate

lint:
  stage: check
  script:
    - task lint-check
  only:
    - merge_requests

上記のスニペットでは、Taskをプリインストールし、before_scriptを使用してアプリテンプレートの依存関係をインストールし、リンティングを設定します。その後、同じパターンに従ってテストできます。

test:
  stage: check
  script:
    - task test
  only:
    - merge_requests

上記のスニペットでは、テストとリンティングの両方に同じcheckステージを使用しています。これにより両方が並行して実行されて、マージリクエストのチェックが高速化され、より迅速なフィードバックが提供されます。

デプロイの確認¶

merge_requestsのテストを設定したら、「レビューアプリ」のサポートを追加できます。このセクションを使用して、PRに表示される「手動」手順を追加します。

このタスク/パイプラインにより、開発者はボタンをクリックするだけで、データと会話するエージェントのスタック全体を起動し、同僚と共有したり、自分で検証したりすることが可能になります。

以下のコード例は、.gitlab-ci.ymlから抜粋したものです。 .env-templateに必要な変数を定義する必要があります。

variables:
  DATAROBOT_ENDPOINT: https://app.datarobot.com/api/v2
  FRONTEND_TYPE: react
  # The following variables are set on the GitLab CI/CD settings page:
  # DATAROBOT_API_TOKEN: "$DATAROBOT_API_TOKEN"
  # PULUMI_CONFIG_PASSPHRASE: "$PULUMI_CONFIG_PASSPHRASE"
  # OPENAI_API_VERSION: "$OPENAI_API_VERSION"
  # OPENAI_API_BASE: "$OPENAI_API_BASE"
  # OPENAI_API_DEPLOYMENT_ID: "$OPENAI_API_DEPLOYMENT_ID"
  # OPENAI_API_KEY: "$OPENAI_API_KEY"
  # # Used for the Pulumi DIY backend bucket: https://www.pulumi.com/docs/iac/concepts/state-and-backends/#azure-blob-storage
  # AZURE_STORAGE_ACCOUNT: "$AZURE_STORAGE_ACCOUNT"
  # AZURE_STORAGE_KEY: "$AZURE_STORAGE_KEY"
  # GITLAB_API_TOKEN: "$GITLAB_API_TOKEN"

GitLabでは、プロジェクトのci_cd variables設定でこれらの変数を定義します。

これらの変数はCIとCDの両方に再利用し、Pulumiとアプリケーションに必要な情報をカバーします（たとえば、LLMキーなどの必要なデータ接続情報）。

DATAROBOT_API_TOKENには、個人のユーザーログインではなく、専用のサービスアカウントのAPIキーを使用します。サービスアカウントとは、自動化専用に作成されたDataRobotユーザーのことです。DataRobotの管理者にアカウントの作成を依頼してください（例：ci-bot@your-org.com）。その後、そのアカウントでDataRobotのUIから開発者ツール → APIのキーとツールを選択し、APIキーを生成します（詳細については、APIのキーとツールを参照してください）。

そのアカウントにアプリ管理者ロールを割り当ててください。これにより、カスタムアプリケーション、デプロイ、および関連リソースの作成や更新に必要な権限が付与されます。これにより、チームメンバーに変更があってもパイプラインが動作し続けることが保証され、個々のユーザーとは無関係にCI/CDへのアクセス権を監査したり取り消したりすることが容易になります。

変数が設定されたら、手作業の段階に進みます。

review_app:
  stage: review
  script:
  # Installs a "MR review app" for the branch being merged into main
    - curl -fsSL https://get.pulumi.com | sh
    - export PATH="~/.pulumi/bin:$PATH"
    - pulumi login --cloud-url "azblob://dr-ai-apps-pulumi"
    - pulumi stack select --create gitlab-mr-$CI_MERGE_REQUEST_IID
    - pulumi up --yes --stack gitlab-mr-$CI_MERGE_REQUEST_IID
    - echo "Deploying review app for branch gitlab-mr-$CI_MERGE_REQUEST_IID"
    - STACK_OUTPUT="<br><br>$(pulumi stack output --shell)"
    - STACK_OUTPUT="${STACK_OUTPUT//$'\n'/<br>}"
    - |
      curl --header "PRIVATE-TOKEN: $GITLAB_API_TOKEN" \
         --data "body=Review Deployment: $STACK_OUTPUT" \
         "$CI_API_V4_URL/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/notes"
  only:
    - merge_requests
  when: manual

このスニペットでは、when:manualパイプラインステージを作成して、リソースの保存をオプションにします。これは、開発者がリソースの節約が必要と判断した場合にのみ行ってください。このスニペットは、Pulumiをインストールし、マージリクエスト番号に関連付けられたスタックを作成して一意性を確保し、スタックを立ち上げます。その後、アプリケーションをレビューするためのリンクとともに、リクエストについてコメントします。このライブの実行例については、MR #5を参照してください。

開発者がマージリクエストを更新すると、このステージを再実行することで、Pulumi IaCおよびDataRobotの宣言型APIのべき等性に依存するアプリケーションテンプレートが更新されます。

スタックを破棄するために、マージリクエスト内および事後のクリーンアップ用に、手動で実行可能なジョブが用意されています。下記のスニペットでは、マージリクエスト番号を手動変数として使用し、その後pulumi destroyおよびpulumi stack rmによってこれを破棄します。それにより、一元管理されたPulumiバックエンドをクリーンな状態に保ち、リソース使用量を最小限に抑えることができます。

destroy_review_app:
  stage: cleanup
  script:
    - curl -fsSL https://get.pulumi.com | sh
    - export PATH="~/.pulumi/bin:$PATH"
    - pulumi login --cloud-url "azblob://dr-ai-apps-pulumi"
    - pulumi destroy --yes --stack gitlab-mr-$CI_MERGE_REQUEST_IID
    - pulumi stack rm gitlab-mr-$CI_MERGE_REQUEST_IID --yes
    - echo "Destroyed review app stack for MR gitlab-mr-$CI_MERGE_REQUEST_IID"
  only:
    - merge_requests
    - main
  when: manual
  needs:
    - job: review_app
      optional: true

継続的デリバリー¶

継続的デリバリーの設定は、レビューアプリの設定と似ていますが、マージ時に実行される点と、破棄メカニズムがない点が異なります。すべての変更がマージされるため、永続的に維持されます。

以下の関連するパイプラインのyamlを確認してください。

deploy_ci:
  stage: deploy
  script:
    - curl -fsSL https://get.pulumi.com | sh
    - export PATH="~/.pulumi/bin:$PATH"
    - pulumi login --cloud-url "azblob://dr-ai-apps-pulumi"
    - pulumi stack select ci
    - pulumi up --yes --stack ci
    - echo "Deployed CI stack"
  only:
    - main
  when: on_success

パイプラインは、スタック名が固定されているため、レビューアプリよりも簡単です。また、この例では、スタックを永続的に保存するためにAzure Blob Storageを使用しています。また、実行例を確認することもできます。

GitHub Actions¶

GitHub Actionsは、GitLabのパイプラインとよく似ています。この例を参考に、異なるPulumiバックエンドやGitHub ActionsのCI/CD設定を使用しても、同様の結果を得ることができます。

name: Pulumi Deployment
on:
  pull_request:
    types: [opened, synchronize, reopened]
env:
  PULUMI_STACK_NAME: github-pr-${{ github.event.repository.name }}-${{ github.event.number }}
jobs:
  update:
    name: pulumi-update-stack
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Decrypt Secrets
        run: gpg --quiet --batch --yes --decrypt --passphrase="$LARGE_SECRET_PASSPHRASE" --output .env .env.gpg
        env:
          # https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions
          LARGE_SECRET_PASSPHRASE: ${{  secrets.LARGE_SECRET_PASSPHRASE }}
      - uses: actions/setup-python@v5
        with:
          python-version: 3.12
      - name: Install Pulumi
        run: |
          curl -fsSL https://get.pulumi.com | sh
          echo "$HOME/.pulumi/bin" >> $GITHUB_PATH
      - name: Setup Project Dependencies
        run: |
          command -v uv >/dev/null 2>&1 || curl -LsSf https://astral.sh/uv/install.sh | sh
          uv venv .venv
          source .venv/bin/activate
          uv pip install -r requirements.txt
      - name: Plan Pulumi Update
        id: plan_pulumi_update
        run: |
          source .venv/bin/activate
          export $(grep -v '^#' .env | xargs)
          pulumi stack select --create $PULUMI_STACK_NAME
          pulumi up --yes
          # Store JSON output once and parse it for all values
          PULUMI_OUTPUT=$(pulumi stack output --json)
          APPLICATION_URL=$(echo "$PULUMI_OUTPUT" | jq -r 'to_entries[] | select(.key | startswith("Data Analyst Application")) | .value')
          DEPLOYMENT_URL=$(echo "$PULUMI_OUTPUT" | jq -r 'to_entries[] | select(.key | startswith("Generative Analyst Deployment")) | .value')
          APP_ID=$(echo "$PULUMI_OUTPUT" | jq -r '.DATAROBOT_APPLICATION_ID // empty')
          LLM_ID=$(echo "$PULUMI_OUTPUT" | jq -r '.LLM_DEPLOYMENT_ID // empty')
          echo "application_url=${APPLICATION_URL}" >> $GITHUB_OUTPUT
          echo "deployment_url=${DEPLOYMENT_URL}" >> $GITHUB_OUTPUT
          echo "app_id=${APP_ID}" >> $GITHUB_OUTPUT
          echo "llm_id=${LLM_ID}" >> $GITHUB_OUTPUT
        env:
          PULUMI_ACCESS_TOKEN: ${{  secrets.PULUMI_ACCESS_TOKEN }}
      - name: Comment PR with App URL
        uses: peter-evans/create-or-update-comment@v4
        with:
          token: ${{  secrets.GITHUB_TOKEN }}
          issue-number: ${{  github.event.number }}
          body: |
            # 🚀 Your application is ready!
            ## Application Info
            - **Application URL:** [${{  steps.plan_pulumi_update.outputs.application_url }}](${{  steps.plan_pulumi_update.outputs.application_url }})
            - **Application ID:** `${{  steps.plan_pulumi_update.outputs.app_id }}`
            ## LLM Deployment
            - **Deployment URL:** [${{  steps.plan_pulumi_update.outputs.deployment_url }}](${{  steps.plan_pulumi_update.outputs.deployment_url }})
            - **Deployment ID:** `${{  steps.plan_pulumi_update.outputs.llm_id }}`
            ### Pulumi Stack
            - **Stack Name:** `${{  env.PULUMI_STACK_NAME }}`

これで、すべてのプルリクエストでpulumi upが実行され、Pulumiスタックがクラウドにバックアップされるようになりました。これにより、コミット間の追跡が可能になります。 Pulumiが変更を完了すると、アプリに関する情報が表示されます。実際のワークフローの動作を確認するには、このGitHubプルリクエストを参照してください。

追加の設定が必要な注意事項があります。これらは以下のセクションで説明します。

Pulumi¶

Pulumiをローカルに設定する最も簡単でわかりやすい方法は、Pulumiをインストールし、Pulumiクラウドバックエンドにログインすることです。これにより、ローカルのPulumiスタックがクラウドバックアップと同期され、他のエッジノード（GitHub Actionsなど）からスタックにアクセスできるようになります。 GitHubのリポジトリシークレットにPULUMI_ACCESS_TOKENシークレットを追加するだけです。環境変数としてPULUMI_ACCESS_TOKENが設定されている場合、Pulumiは自動的にPulumi Cloudに対して認証を行うため、CIでは対話型のpulumi loginステップは必要ありません。

それがセキュリティ上の懸念である場合、またはデフォルトのPulumi Cloudアプローチを使用しない他の理由（使用環境からのネットワークアクセス、コスト、企業ポリシーなど）がある場合は、DIY Pulumiバックエンドを利用できます。たとえば、GitLabチュートリアルでは、Azure DIYバックエンドを使っていますが（このセクションのコード例の11行目）、GitHubではAzureやAWSのバックエンドを使うことができます。

GitHub CI/CDでは、インフラストラクチャの変更については、推奨されているPulumiベースの方法を重視していますが、S3や他のPulumi Stateプロバイダーを利用したい場合は、たとえばAzureを利用してGitLab DIYの方法に従うことができます。

GitHub Actionsのシークレット¶

APIキー、データベースの資格情報、クラウドプロバイダートークンなどの機密データを管理する場合、GitHub Actionsにはシークレットを処理するための組み込みの方法が用意されています。最も簡単な方法は、各シークレットをGitHubに個別に保存し、環境変数としてワークフローに組み込むことです。この方法は、シークレットの数が増えるにつれて、煩雑でミスが起こりやすくなる可能性があります。変数の設定を誤ったり、ログに値が漏れたり、実際に使用されている内容を把握できなくなったりすることはよくあります。

GitHub自体で推奨しているより堅牢な代替手段は、シークレットをファイル（.envなど）にまとめ、GPGで暗号化して、暗号化されたバージョンのみをリポジトリに保存することです。こうすることで、必要な復号キーはGitHub Secretsに1つだけとなり、残りのシークレットはワークフローファイルに分散することなく、厳重に管理およびバージョニングされます。これは、リスクを軽減し、規模に応じて管理を簡素化する、クリーンで監査可能なアプローチです。

どちらのアプローチを選択する場合でも、DATAROBOT_API_TOKENが個人のユーザーログインではなく、専用のサービスアカウントから取得されるようにします。最初にパイプラインを設定したエンジニアがチームを離れる場合は、個人トークンをローテーションし、すべてのダウンストリームシークレットを更新する必要があります。サービスアカウントトークンは、個別に取り消して置き換えることができます。 DataRobotの管理者に、専用の自動化ユーザーを作成してもらい、そのユーザーにアプリ管理者ロールを割り当て、そのアカウントで開発者ツール → APIキーからAPIキーを生成します。

以下の手順では、その方法の概要を説明します。

gpg --symmetric --cipher-algo AES256 .envを実行します。パスフレーズの入力を求められます。パスフレーズを値として使用する新しいシークレットをGitHubで作成する必要があるため、パスフレーズを覚えておいてください。
パスフレーズを含む新しいシークレットをGitHubリポジトリに作成します。たとえば、LARGE_SECRET_PASSPHRASEという名前で新しいシークレットを作成し、シークレットの値を前の手順で使用したパスフレーズに設定します。
暗号化されたファイルをリポジトリ内のパスにコピーし、コミットします。この例では、暗号化されたファイルは.env.gpgです。

git add .env.gpg
git commit -m "Add new GPG encrypted secret file"
git push

GitHub Actionsでリソースを破棄する¶

このセクションでは、実際のアプリケーションを含むすべてのベースリソースを使用してユースケースを正常に作成した後、そのユースケースを削除する方法について説明します。 GitHub Actionsを使って、手動トリガーによるワークフローを作成します。

前回のpulumi upの例ではGPGで暗号化されたシークレットを使っていましたが、今回の手動ワークフローではGitHubの環境変数を直接使います。ワークフローには、入力としてスタック名が必要です。 GitHubシークレットのPULUMI_ACCESS_TOKENを使って、Pulumi Cloudで認証します。

name: Pulumi Stack Destroy
on:
  workflow_dispatch:
    inputs:
      stack_name:
        description: 'Stack name to destroy (e.g. github-pr-foobar-42)'
        required: true
        type: string

env:
  PULUMI_STACK_NAME: github-pr-${{  github.event.repository.name }}-${{  github.event.number }}
  PULUMI_ACCESS_TOKEN: ${{  secrets.PULUMI_ACCESS_TOKEN }}

jobs:
  destroy:
    name: pulumi-destroy-stack
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: 3.12
      - name: Install Pulumi
        run: |
          curl -fsSL https://get.pulumi.com | sh
          echo "$HOME/.pulumi/bin" >> $GITHUB_PATH
      - name: Setup Project Dependencies
        run: |
          command -v uv >/dev/null 2>&1 || curl -LsSf https://astral.sh/uv/install.sh | sh
          uv venv .venv
          source .venv/bin/activate
          uv pip install -r requirements.txt
      - name: Destroy Pulumi Stack
        run: |
          source .venv/bin/activate
          pulumi stack select ${{  github.event.inputs.stack_name }}
          pulumi destroy --yes
          pulumi stack rm --yes ${{  github.event.inputs.stack_name }}

PRで受け取ったスタック名でフローをトリガーするだけで、ユースケースに関連付けられたすべてのリソースを安全に破棄できます。

Azure DevOps¶

Azure DevOps Services runs the same pattern with two ready-made pipelines from the DataRobot Azure DevOps examples repository. A pull request prints the plan. A merge to main waits for an approval, deploys, and runs a smoke test.

The following table compares the two pipelines.

Pipeline folder	Deploys	Use it when
`templates/azure-devops-workload`	A container as a DataRobot Workload, with `dr workload up`.	The DataRobot release has Workloads.
`templates/azure-devops-custom-app`	A container as a custom application, with Pulumi and the state in Azure Blob Storage.	The release has no Workloads, or custom applications already run.

Each folder is the root of its own repository. Copy its contents into an Azure Repos repository and follow its README.md. Both pipelines need three settings that live in Azure DevOps and not in the repository:

A variable group named datarobot-deploy with DATAROBOT_ENDPOINT and DATAROBOT_API_TOKEN, marked secret. Use the API key of a service account, as described in Review deployments. The custom application pipeline also needs AZURE_STORAGE_ACCOUNT, AZURE_STORAGE_KEY, and PULUMI_CONFIG_PASSPHRASE, for the Azure Blob Storage backend described in Pulumi.
An environment named prod with an Approval check and an Exclusive lock check.
A build validation policy on main that runs the pipeline, so a pull request prints the plan.

The examples target Azure DevOps Services with Microsoft-hosted agents and multi-tenant SaaS. They don't cover self-hosted agents, Azure DevOps Server, Terraform, or Pulumi projects with many resources. Each README marks its unverified steps.

PulumiのState管理¶

一元化されたPulumi Stateバックエンドを使用することをお勧めします。主な理由の1つは、プロビジョニングしたリソースを見失うことなく、マシン間、CI/CDプラットフォーム間、およびCodespaceの内外でPulumiを使用できることです。

共有ストレージのPulumiバックエンドを使用すると、DataRobotアプリケーションで新しいCodespaceを独自のコードでスピンアップして、新しいエクスペリメントを作成したり、既存のスタックを更新したりすることができます。その方法は、必要なコードのクローンを作成し、pulumi login <backend>を実行した後、以下のスニペットを使用するだけです。

 pulumi stack ls -a

次のような結果になります。 NAME LAST UPDATE RESOURCE COUNT organization/agent_sre/sredev1 2 months ago 0 organization/talk-to-my-docs/x-dev0 2 days ago 12 dev0 2 weeks ago 13 ci 6 days ago 13

その後、以下の簡単なコマンドを実行します。

pulumi stack select ci

このコードによって、そのスタックに直接アクセスし、簡単なpulumi upで変更を同期できます。

ここに挙げた例を参考に、この方法でレビューアプリの管理や更新ができます。

成果¶

開発者と組織にとって、AIアプリケーションにDevOpsのベストプラクティスを導入することは、AIの可能性を最大限に引き出す上で不可欠です。最新のCI/CDパイプライン、レビューアプリフロー、インフラストラクチャ・アズ・コードをPulumiと統合することで、組織がAI搭載ソリューションを構築、テスト、提供する方法が変わります。

DataRobotを中核とするこれらのDevOpsパターンにより、AIアプリに対するすべての変更が、本番環境に到達するはるか前に、実環境で自動的に検証され、安全にデプロイされ、簡単にレビューされるようになります。レビューアプリを使用すると、シームレスでリスクのないコラボレーションが可能になります。また、クラウドベースのPulumi Stateとセキュリティで保護されたシークレット管理により、インフラストラクチャの安全性と管理性が大規模に維持されます。

これらのアプローチを採用することで、AIアプリケーションを迅速かつ確実に進化させることができ、すべてのチームメンバーが貢献と革新を行うことができます。これらのパターンを繰り返し適用するうちに、AI向けの本番環境レベルのDevOpsが実現可能であるだけでなく、ユーザーに真の価値を安全かつ自信を持って、現代のビジネスのスピードで提供するための起爆剤にもなることがわかります。