0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@simonTokyo(シモンさん)inIBM

TerraformでIBM BobにPlaywright MCP環境を自動設定させる

0
Posted at

はじめに

IBM Bob IDEなどのMCP（Model Context Protocol）対応ツールで使用するPlaywright環境を、Terraformで自動構築するスクリプトを作りました。Windows、macOS、Linuxの3つのプラットフォームで動作し、Node.jsのインストールからPlaywrightのセットアップ、MCP設定ファイルの生成までを自動化しています。

リポジトリ

詳細な実装やスクリプトの全文は、GitHubリポジトリをご覧ください：
terraform-ibmbob-playwright-mcp

プロジェクト概要

使い方

terraform init
terraform apply

リポジトリーをチェックアウト後、上記コマンドを実行すると、以下がすべて自動的に完了します：

  1. OS自動検出 - Windows/macOS/Linuxを判別
  2. Node.js v24.15.0のインストール - 各OSに最適な方法で
  3. Playwright Chromeブラウザのインストール
  4. MCP設定ファイルの生成 - IBM Bob IDE用

image.png

処理フローの特徴

┌─────────────────────────────────────────┐
│         Terraform Main Config           │
│  (OS検出 + リソース管理 + 再現性保証)    │
└─────────────────────────────────────────┘
                    │
        ┌───────────┴───────────┐
        ▼                       ▼
┌───────────────┐       ┌───────────────┐
│   Windows     │       │  macOS/Linux  │
│  PowerShell   │       │     Bash      │
│   Scripts     │       │   Scripts     │
└───────────────┘       └───────────────┘
        │                       │
        ▼                       ▼
┌───────────────┐       ┌───────────────┐
│  Chocolatey   │       │      nvm      │
│   Node.js     │       │   Node.js     │
└───────────────┘       └───────────────┘
        │                       │
        └───────────┬───────────┘
                    ▼
            ┌───────────────┐
            │  Playwright   │
            │    Chrome     │
            └───────────────┘
                    │
                    ▼
            ┌───────────────┐
            │  MCP Config   │
            │     File      │
            └───────────────┘

テストで気づいた小さな課題

課題1: 新しいシェルセッションでのPATH問題

問題: Node.jsをインストールしても、次のTerraform provisioner実行時にNode.jsが見つからない

Error: node: command not found

原因:

  • Terraformの各local-exec provisionerは新しいシェルセッションで実行される
  • インストール時にPATHが更新されても、新しいセッションには反映されない

解決策: 複数のパスを直接チェックする検証ロジック

# Windows版（main.tf）
command = "$nodePaths = @(
  'C:\\Program Files\\nodejs\\node.exe',
  'C:\\Program Files (x86)\\nodejs\\node.exe',
  \"$env:ProgramData\\chocolatey\\bin\\node.exe\"
); 
foreach ($path in $nodePaths) {
  if (Test-Path $path) {
    $version = & $path --version;
    Write-Host \"Node.js found at $path : $version\";
    exit 0
  }
}"

# Unix版（main.tf）
# 標準PATH → nvm → Homebrew の順でチェック
if command -v node >/dev/null 2>&1; then
  echo "Node.js found: $(node --version)"
  exit 0
fi

# nvmをロードして再チェック
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"

if command -v node >/dev/null 2>&1; then
  echo "Node.js found via nvm: $(node --version)"
  exit 0
fi

課題2: チェックスクリプトがインストールをブロック

問題: Node.jsが見つからない時、チェックスクリプトがexit 1で終了し、Terraformが停止

Error: local-exec provisioner error
exit status 1

原因: チェックスクリプトがエラーとして扱われ、後続のインストール処理が実行されない

解決策: 非ブロッキング設計 - チェックは情報提供のみ

# scripts/check_nodejs.sh（修正後）
if ! command -v node &> /dev/null; then
    log "INFO" "Node.js is not installed - will proceed with installation"
    exit 0  # エラーではなく正常終了
fi

# バージョンチェックも同様
if [ "$comparison" = "-1" ]; then
    log "INFO" "Node.js version v$installed_version is older than required - will proceed with installation"
    exit 0  # エラーではなく正常終了
fi

課題3: Unix環境でのツール依存性

問題: Ubuntu環境でcurlがインストールされておらず、nvmのダウンロードに失敗

curl: command not found
Failed to download nvm

解決策: curl/wgetの自動検出とフォールバック

# scripts/install_nodejs_unix.sh
install_nvm() {
    # curlまたはwgetを自動検出
    local download_cmd=""
    if command -v curl &> /dev/null; then
        download_cmd="curl -o-"
    elif command -v wget &> /dev/null; then
        download_cmd="wget -qO-"
    else
        log "ERROR" "Neither curl nor wget is installed."
        log "ERROR" "Ubuntu/Debian: sudo apt-get install curl"
        return 1
    fi
    
    # 検出したツールでダウンロード
    $download_cmd "https://raw.githubusercontent.com/nvm-sh/nvm/$NVM_VERSION/install.sh" | bash
}

リカバリー機能の実装

失敗しても再実行で自動的に修復される仕組みを実装しました。

タイムスタンプトリガーによる再現性

resource "null_resource" "install_nodejs" {
  triggers = {
    force_reinstall = var.force_reinstall
    script_hash     = filemd5(local.nodejs_install_script)
    always_check    = timestamp()  # 毎回チェックを強制
  }
  
  provisioner "local-exec" {
    command = local.is_windows ? 
      "PowerShell -ExecutionPolicy Bypass -File ${local.nodejs_install_script}" :
      "bash ${local.nodejs_install_script}"
  }
}

処理フロー

terraform apply
    │
    ├─→ OS検出
    │
    ├─→ Node.jsチェック（非ブロッキング）
    │   └─→ 見つからない → インストール実行
    │   └─→ 見つかった → スキップ
    │
    ├─→ Node.js検証（複数パスチェック）
    │   └─→ 失敗 → エラー表示（ユーザーに再実行を促す）
    │
    ├─→ Playwrightインストール
    │   └─→ nvmロード → Node.js確認 → インストール
    │
    └─→ MCP設定ファイル生成

プラットフォーム別の実装工夫

Windows: Chocolateyの活用

# scripts/install_nodejs_windows.ps1
# Chocolateyがなければインストール
if (-not (Get-Command choco -ErrorAction SilentlyContinue)) {
    Set-ExecutionPolicy Bypass -Scope Process -Force
    [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072
    iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))
}

# Node.jsインストール
choco install nodejs --version=$NODE_VERSION -y --force

macOS/Linux: nvmによる管理

# scripts/install_nodejs_unix.sh
# nvmインストール
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash

# nvmロード
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

# Node.jsインストール
nvm install 24.15.0
nvm use 24.15.0
nvm alias default 24.15.0

Playwrightスクリプトでのnvm対応

# scripts/install_playwright.sh
main() {
    # 新しいシェルセッションでもnvmを利用可能にする
    export NVM_DIR="$HOME/.nvm"
    [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
    
    # Node.js確認
    if ! command -v node &> /dev/null; then
        log "ERROR" "Node.js not found. Please restart your terminal."
        exit 1
    fi
    
    # Playwrightインストール
    npx playwright install chrome --with-deps
}

まとめ

Terraformを使ったクロスプラットフォーム対応しました：

  1. ✅ 各プラットフォームの特性を理解する

    • パッケージマネージャー、シェル、パス構造の違い

  2. ✅ 新しいシェルセッションを意識する

    • 環境変数の引き継ぎ、PATHの更新タイミング

  3. ✅ エラーを想定した設計

    • フォールバック、非ブロッキング、明確なメッセージ

  4. ✅ 再現性とリカバリー

    • 何度実行しても安全、失敗しても再実行で修復

参考リンク

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?