多数のWordPressサイトを管理している場合、ワークフローはできるだけ簡素化、高速化したいところ。シェルスクリプトとKinsta APIを併用すると、ターミナルでコマンドを実行するだけで、サイト数を問わず全てのバックアップをトリガーすることができます。

この記事では、シェルスクリプトを使って、サイト管理をさらに効率化するカスタムコマンドを設定する方法をご紹介します。

前提条件

これからご紹介する例では、以下が必要になります。

  1. ターミナル：最近のOSにはすべてターミナルが付属しているため別途入手は不要です。
  2. IDEまたはテキストエディター：VS CodeやSublime Text、Nanoのような軽量エディターなど、使い慣れたものを使用してください。
  3. Kinsta APIキー：Kinsta APIとの対話に不可欠です。以下の手順で生成可能です。
    • MyKinstaにログイン
    • 画面右上ユーザー名から「企業の設定」＞「APIキー」に移動
    • 「APIキーを作成」をクリックして保存
  4. curlとjq：APIリクエストとJSONデータの処理に必要になります。インストールされているか確認し、されていない場合はインストールしてください。
  5. プログラミングの基礎知識：高度な知識は不要ですが、プログラミングの基本やシェルスクリプトの構文を理解しているとスムーズです。

基本スクリプトの書き方

Kinsta APIと対話する最初のシェルスクリプトとして、まずはKinstaで管理しているすべてのWordPressサイトをリストアップする簡単なものから始めましょう。

ステップ 1. 環境のセットアップ

はじめに、プロジェクト用のフォルダとスクリプトファイルを作成します。.sh拡張子はシェルスクリプトに使用します。例えば、フォルダを作成して、フォルダ内で以下のコマンドを実行し、VS Codeでスクリプトファイルを作成して開くことができます。

mkdir my-first-shell-scripts
cd my-first-shell-scripts
touch script.sh
code script.sh

ステップ2. 環境変数の定義

APIキーを安全に保つため、スクリプトにハードコードする代わりに、.envファイルに保存します。これにより、.envファイルを.gitignoreに追加し、バージョン管理に反映されるのを防ぐことができます。

.envファイルに以下を追加します。

API_KEY=your_kinsta_api_key

スクリプトの先頭に以下を追加して、.envファイルからAPIキーをスクリプトに取り込みます。

#!/bin/bash
source .env

シバン（shebang）行#!/bin/bashによって、スクリプトがBashを使って実行されることを保証し、source .envは環境変数をインポートします。

ステップ3. APIリクエストの記述

まずは、「企業ID」（MyKinstaのユーザー名から「企業の設定」＞「請求先情報」）を変数に格納します。

COMPANY_ID="<your_company_id>"

続いて、curlコマンドを追加して、/sitesエンドポイントにGETリクエストを行い、クエリパラメータとして企業IDを渡します。jqを使って、読みやすいように出力をフォーマットします。

curl -s -X GET 
  "https://api.kinsta.com/v2/sites?company=$COMPANY_ID" 
  -H "Authorization: Bearer $API_KEY" 
  -H "Content-Type: application/json" | jq

このリクエストは、ID、名前、ステータスなど、企業に紐づくすべてのサイト情報を取得します。

ステップ4. スクリプトを実行可能にする

スクリプトを保存し、実行可能な状態にします。

chmod +x script.sh

ステップ5. スクリプトの実行

スクリプトを実行すると、フォーマットされたサイト一覧が表示されます。

./list_sites.sh

スクリプトを実行すると、以下のようなレスポンスが返されます。

{
  "company": {
    "sites": [
      {
        "id": "a8f39e7e-d9cf-4bb4-9006-ddeda7d8b3af",
        "name": "bitbuckettest",
        "display_name": "bitbucket-test",
        "status": "live",
        "site_labels": []
      },
      {
        "id": "277b92f8-4014-45f7-a4d6-caba8f9f153f",
        "name": "duketest",
        "display_name": "zivas Signature",
        "status": "live",
        "site_labels": []
      }
    ]
  }
}

上のスクリプトは動作はしますが、サイト情報を取得し、読みやすいようにフォーマットする関数を設定することで改良することができます。

ステップ6. 関数でリファクタリング

curlリクエストをサイト一覧の取得と書式設定を行う再利用可能な関数に置き換えます。

list_sites() {
  echo "企業IDの全サイトを取得: $COMPANY_ID..."
  
  RESPONSE=$(curl -s -X GET "https://api.kinsta.com/v2/sites?company=$COMPANY_ID" 
    -H "Authorization: Bearer $API_KEY" 
    -H "Content-Type: application/json")

  # エラーを確認
  if [ -z "$RESPONSE" ]; then
    echo "Error: APIから応答がありません"
    exit 1
  fi

  echo "Company Sites:"
  echo "--------------"
  echo "$RESPONSE" | jq -r '.company.sites[] | "(.display_name) ((.name)) - Status: (.status)"'
}

# 関数を実行
list_sites

スクリプトを再度実行すると、適切にフォーマットされた出力を得ることができます。

Fetching all sites for company ID: b383b4c-****-****-a47f-83999c5d2...
Company Sites:
--------------
bitbucket-test (bitbuckettest) - Status: live
zivas Signature (duketest) - Status: live

以上がシェルスクリプトとKinsta APIの使用方法の基本になります。次のセクションでは、より高度なスクリプトを作成して、より高度な方法でAPIと対話する方法を見ていきます。

使用例1. バックアップを作成する

バックアップはサイト管理に欠かせないタスクです。バックアップを作成することで、予期せぬ問題が発生してもサイトを復元可能です。Kinsta APIとシェルスクリプトを使ってこのタスクを自動化して作業時間を削減することができます。

以下、Kinstaの手動バックアップ制限（1環境あたり5つまで）を考慮しながらバックアップを作成する方法を見ていきます。具体的には、以下のようなプロセスになります。

  • 現在の手動バックアップの数を確認
  • 制限に達している場合は1番古いバックアップを特定して削除
  • 新規バックアップを作成

バックアップのワークフロー

Kinsta APIを使用してバックアップを作成するには、次のエンドポイントを使用します。

POST /sites/environments/{env_id}/manual-backups

これには以下が必要です。

  1. 環境ID：バックアップが作成される環境（ステージングまたは本番）を識別
  2. バックアップタグ：バックアップを識別するためのラベル（任意）

手動で環境IDを取得して、backup <environment ID>のようなコマンドを実行するのは手間がかかるため、サイト名を指定するだけでスクリプトが実行されるスクリプトを作成します。

  1. サイトの環境一覧を取得
  2. バックアップする環境を選択
  3. バックアップ作成プロセスを処理

クリーンコードのための再利用可能関数

スクリプトをモジュール化して再利用可能にするため、特定のタスクのための関数を定義します。

1. ベース変数の設定

最初に作成したスクリプトを削除するか、新たにスクリプトファイルを作成します。土台となるKinsta APIのURLと企業IDをスクリプトで宣言します。

BASE_URL="https://api.kinsta.com/v2"
COMPANY_ID="<your_company_id>"

この変数により、スクリプト全体でAPIエンドポイントを動的に構築できます。

2. すべてのサイトを取得

企業のすべてのサイトをリストアップする関数を定義します。これにより、各サイトの情報を後で取得することができます。

get_sites_list() {
  API_URL="$BASE_URL/sites?company=$COMPANY_ID"

  echo "企業IDの全サイトを取得: $COMPANY_ID..."
  
  RESPONSE=$(curl -s -X GET "$API_URL" 
    -H "Authorization: Bearer $API_KEY" 
    -H "Content-Type: application/json")

  # エラーを確認
  if [ -z "$RESPONSE" ]; then
    echo "Error: APIからの応答がありません"
    exit 1
  fi

  echo "$RESPONSE"
}

この関数は、APIからフォーマットされていないレスポンスを返します。フォーマットされた応答を取得するには、それを処理する別の関数を追加します（このセクションでは割愛）。

list_sites() {
  RESPONSE=$(get_sites_list)

  if [ -z "$RESPONSE" ]; then
    echo "Error: サイトの取得中にAPIからの応答がありません"
    exit 1
  fi

  echo "Company Sites:"
  echo "--------------"
  # jqに渡す前にレスポンスをクリーンアップ
  CLEAN_RESPONSE=$(echo "$RESPONSE" | tr -d 'r' | sed 's/^[^{]*//') # JSONが始まる前に余分な文字を削除

  echo "$CLEAN_RESPONSE" | jq -r '.company.sites[] | "(.display_name) ((.name)) - Status: (.status)"'
}

list_sites関数を呼び出すと、先に示したようにサイトが表示されますが、主な目的は各サイトとそのIDにアクセスし、各サイトの情報を取得することにあります。

3. サイト情報の取得

特定のサイト情報を取得するには、以下の関数を使用します。サイト名に基づいてサイトIDを取得し、環境などの追加情報が返されます。

get_site_details_by_name() {
  SITE_NAME=$1
  if [ -z "$SITE_NAME" ]; then
    echo "Error: サイト名なし Usage: $0 details-name "
    return 1
  fi

  RESPONSE=$(get_sites_list)

  echo "サイト名で検索: $SITE_NAME..."

  # Clean the RESPONSE before parsing
  CLEAN_RESPONSE=$(echo "$RESPONSE" | tr -d 'r' | sed 's/^[^{]*//')

  # 指定されたサイト名のサイトIDを取得
  SITE_ID=$(echo "$CLEAN_RESPONSE" | jq -r --arg SITE_NAME "$SITE_NAME" '.company.sites[] | select(.name == $SITE_NAME) | .id')

  if [ -z "$SITE_ID" ]; then
    echo "Error: SITE_NAME という名前のサイトはありません"
    return 1
  fi

  echo "サイト名 $SITE_NAME に対応するサイトID $SITE_ID が見つかりました"

  # サイトIDを使ってサイトの詳細を取得
  API_URL="$BASE_URL/sites/$SITE_ID"

  SITE_RESPONSE=$(curl -s -X GET "$API_URL" 
    -H "Authorization: Bearer $API_KEY" 
    -H "Content-Type: application/json")

  echo "$SITE_RESPONSE"
}

上の関数は、サイト名を使用してサイトをフィルタリングし、/sites/<site-id>エンドポイントを使用してサイトの追加情報を取得します。これにはバックアップをトリガーするために必要なサイトの環境が含まれます。

バックアップの作成

サイト情報を取得し、環境を一覧表示する再利用可能な関数を一度設定すれば、あとはバックアップの自動化に集中できます。ここでの目標はサイト名だけのシンプルなコマンドを実行して、対話形式でバックアップする環境を選択できるようにすることです。

まずは関数を作成します（ここではtrigger_manual_backupとします）。1つ目はサイト名を入力として受け取り、2つ目はバックアップのデフォルトタグ（default-backup）を設定します。後でカスタムタグを指定しない限りは、このデフォルトタグが適用されます。

trigger_manual_backup() {
  SITE_NAME=$1
  DEFAULT_TAG="default-backup"

  # サイト名が提供されていることを確認
  if [ -z "$SITE_NAME" ]; then
    echo "Error: サイト名は必須です"
    echo "Usage: $0 trigger-backup "
    return 1
  fi

  # ここにコードを追加

}

SITE_NAMEは、管理サイトの識別子です。また、識別子が提供されない場合には、スクリプトがエラーメッセージとともに終了するように条件を設定します。これにより、必要な入力がないままスクリプトが続行されることがなくなり、潜在的なAPIエラーを防止できます。

次に再利用可能なget_site_details_by_name関数を使用して、環境を含むサイト情報を取得します。それから、処理中に発生する可能性のある予期せぬ書式の問題を取り除くために、レスポンスをクリーンアップします。

SITE_RESPONSE=$(get_site_details_by_name "$SITE_NAME")

if [ $? -ne 0 ]; then
  echo "Error: サイト $SITE_NAME の情報の取得に失敗しました"
  return 1
fi

CLEAN_RESPONSE=$(echo "$SITE_RESPONSE" | tr -d 'r' | sed 's/^[^{]*//')

サイトの情報を取得したら、下記のスクリプトが利用可能なすべての環境を抽出し、読みやすいフォーマットで表示します。これはどの環境がサイトに紐づいているのかを視覚化するのに有用です。

続いて、スクリプトが名前で環境を選択するよう促します。この対話形式のステップにより、環境IDを記憶したり入力したりする必要がなくなり、プロセスが簡素化されます。

ENVIRONMENTS=$(echo "$CLEAN_RESPONSE" | jq -r '.site.environments[] | "(.name): (.id)"')

echo "SITE_NAME で利用可能な環境："
echo "$ENVIRONMENTS"

read -p "バックアップする環境名（staging、liveなど）を入力： " ENV_NAME

選択した環境名は、サイト情報から対応する環境IDを検索するために使用されます。このIDはバックアップを作成するAPIリクエストに必要です。

ENV_ID=$(echo "$CLEAN_RESPONSE" | jq -r --arg ENV_NAME "$ENV_NAME" '.site.environments[] | select(.name == $ENV_NAME) | .id')

if [ -z "$ENV_ID" ]; then
  echo "Error: サイト $SITE_NAME に環境 $ENV_NAME はありません"
  return 1
fi

echo "環境名 $ENV_NAME に対応する環境ID $ENV_ID が見つかりました"

上のコードでは、選択した環境名に一致するものがない場合、スクリプトがエラーメッセージとともに終了するように条件が設定されています。

環境IDを取得したら、選択した環境の現在の手動バックアップの数が確認されます。Kinstaの手動バックアップは1環境につき最大5つまでという制限があるため、このステップはエラーを避けるのに非常に便利です。

まずはAPIエンドポイントを使用してバックアップの一覧を取得することから始めましょう。/backups APIエンドポイントを使用します。

API_URL="$BASE_URL/sites/environments/$ENV_ID/backups"
BACKUPS_RESPONSE=$(curl -s -X GET "$API_URL" 
  -H "Authorization: Bearer $API_KEY" 
  -H "Content-Type: application/json")

CLEAN_RESPONSE=$(echo "$BACKUPS_RESPONSE" | tr -d 'r' | sed 's/^[^{]*//')
MANUAL_BACKUPS=$(echo "$CLEAN_RESPONSE" | jq '[.environment.backups[] | select(.type == "manual")]')
BACKUP_COUNT=$(echo "$MANUAL_BACKUPS" | jq 'length')

上のスクリプトは、手動バックアップをフィルタリングしてカウントします。数が上限に達した場合は、既存のバックアップを管理する必要があります。

  if [ "$BACKUP_COUNT" -ge 5 ]; then
    echo "手動バックアップの上限に達しました（5件）"
    
    # 最も古いバックアップを探す
    OLDEST_BACKUP=$(echo "$MANUAL_BACKUPS" | jq -r 'sort_by(.created_at) | .[0]')
    OLDEST_BACKUP_NAME=$(echo "$OLDEST_BACKUP" | jq -r '.note')
    OLDEST_BACKUP_ID=$(echo "$OLDEST_BACKUP" | jq -r '.id')

    echo "最も古い手動バックアップは $OLDEST_BACKUP_NAME"
    read -p "このバックアップを削除して新規バックアップを作成しますか？(はい/いいえ）: " CONFIRM

    if [ "$CONFIRM" != "yes" ]; then
      echo "バックアップの作成を中止"
      return 1
    fi

    # 最も古いバックアップを削除
    DELETE_URL="$BASE_URL/sites/environments/backups/$OLDEST_BACKUP_ID"
    DELETE_RESPONSE=$(curl -s -X DELETE "$DELETE_URL" 
      -H "Authorization: Bearer $API_KEY" 
      -H "Content-Type: application/json")

    echo "Delete Response:"
    echo "$DELETE_RESPONSE" | jq -r '[
      "Operation ID: (.operation_id)",
      "Message: (.message)",
      "Status: (.status)"
    ] | join("n")'
  fi

上の条件では、タイムスタンプcreated_atに基づいて一覧を整理して、最も古いバックアップを特定し、削除するかどうかの確認を促します。

削除に同意すると、スクリプトはそのIDを使って最も古いバッ クアップを削除し、新たなバックアップ用の領域を確保します。これにより、手動でバックアップ数を管理することなく、常にバックアップを作成できるようになります。

スペースができたら、環境のバックアップをトリガーするコードに移りましょう。このコードはスキップしても構いませんが、より良い操作体験のため、カスタムタグの指定を求めるようになっています。タグを指定しない場合は、デフォルトでdefault-backupが使用されます。

read -p "バックアップタグを入力（またはEnterキーを押して $DEFAULT_TAG を使用): " BACKUP_TAG

if [ -z "$BACKUP_TAG" ]; then
  BACKUP_TAG="$DEFAULT_TAG"
fi

echo "バックアップタグを使用: $BACKUP_TAG"

最後に、以下のスクリプトでバックアップを実行します。/manual-backupsエンドポイントに、選択した環境IDとバックアップタグを指定してPOSTリクエストを送信します。リクエストが完了すると、APIがバックアップの作成を確認するレスポンスを返します。

API_URL="$BASE_URL/sites/environments/$ENV_ID/manual-backups"
RESPONSE=$(curl -s -X POST "$API_URL" 
  -H "Authorization: Bearer $API_KEY" 
  -H "Content-Type: application/json" 
  -d "{"tag": "$BACKUP_TAG"}")

if [ -z "$RESPONSE" ]; then
  echo "Error: 手動バックアップをトリガーしている間、APIからの応答がありません"
  return 1
fi

echo "バックアップトリガーのレスポンス:"
echo "$RESPONSE" | jq -r '[
  "Operation ID: (.operation_id)",
  "Message: (.message)",
  "Status: (.status)"
] | join("n")'

以上で完了です。上のリクエストから取得したレスポンスは、わかりやすいようにオペレーションID、メッセージ、ステータスを表示するようにフォーマットされています。この関数を呼び出してスクリプトを実行すると、以下の出力が表示されます。

Available Environments for "example-site":
staging: 12345
live: 67890
バックアップする環境名（staging、liveなど）を入力: live
環境IDが見つかりました： 環境名: 67890: live
手動バックアップの上限に達しました（5件）
最も古い手動バックアップは "staging-backup-2023-12-31"
このバックアップを削除して新規バックアップを作成しますか？(はい/いいえ): はい
最も古いバックアップを削除しました
バックアップタグを入力（またはEnterキーを押して default-backup を使用）：weekly-live-backup
バックアップタグの使用: weekly-live-backup
環境ID 67890 に対して手動バックアップをトリガー中（タグ: weekly-live-backup）...
バックアップトリガーのレスポンス:
オペレーションID: backups:add-manual-abc123
メッセージ: Adding a manual backup to environment in progress.
ステータス: 202

スクリプトのコマンドを作成する

コマンドでスクリプトの使用を簡素化することができます。スクリプトを編集したりコードを手動でコメントアウトしたりする代わりに、以下のような特定のコマンドでスクリプトを実行可能です。

./script.sh list-sites
./script.sh backup

スクリプトの最後（すべての関数の外側） に、スクリプトに渡された引数をチェックする条件ブロックを書きます。

if [ "$1" == "list-sites" ]; then
  list_sites
elif [ "$1" == "backup" ]; then
  SITE_NAME="$2"
  if [ -z "$SITE_NAME" ]; then
    echo "Usage: $0 trigger-backup "
    exit 1
  fi
  trigger_manual_backup "$SITE_NAME"
else
  echo "Usage: $0 {list-sites|trigger-backup }"
  exit 1
fi

変数$1は、スクリプトに渡された最初の引数を表します（例えば./script.sh list-sitesの場合、$1はlist-sites）。スクリプトは$1の値を確認し、list-sites や backup などの特定のコマンドと一致するかチェックします。コマンドが backup だった場合、2つ目の引数（$2）としてサイト名が必要になります。適切なコマンドが指定されなかった場合、スクリプトは使い方（ヘルプ）を表示するようになっています。

これでコマンドを実行することで、特定のサイトの手動バックアップを起動できるようになります。

./script.sh backup

使用例2. 複数のサイトでプラグインを更新する

複数のWordPressサイトでのプラグイン管理は、特に更新作業が面倒になることがあります。Kinstaのお客様は、昨年MyKinstaに導入された一括操作機能を使って、効率的に更新作業を行うことができます。

MyKinstaでプラグインを一括更新
MyKinstaでプラグインを一括更新

ユーザーインターフェースでの操作が好みでない場合、Kinsta APIとシェルスクリプトを使って古くなったプラグインを特定し、複数または単一のサイトで更新する作業を自動化することができます。

ワークフローの分解

1. 古いプラグインを使用するサイトを特定：スクリプトがすべてのサイトと環境を繰り返し、更新可能なプラグインを検索します。以下のエンドポイントを使って、特定のサイト環境のプラグイン一覧を取得します。

GET /sites/environments/{env_id}/plugins

レスポンスから"update": "available"のプラグインをフィルタリングします。

2. ユーザーに更新のオプションを提示：古いプラグインを使用するサイトを表示し、特定の環境またはすべての環境を更新できるようにします。

3.プラグイン更新のトリガー：特定の環境でプラグインを更新するには、スクリプトは以下のエンドポイントを使用します。

PUT /sites/environments/{env_id}/plugins

プラグイン名と更新バージョンがリクエストボディに渡されます。

スクリプト

スクリプトは長くなるため、全貌はGitHubで公開しています。ここでは、複数の環境で古くなったプラグインを特定するためのコアロジックをご紹介します。

スクリプトは、コマンドからプラグイン名を受け取ることから始まります。プラグイン名で更新したいプラグインを指定します。

PLUGIN_NAME=$1

if [ -z "$PLUGIN_NAME" ]; then
  echo "Error: プラグイン名は必須です"
  echo "Usage: $0 update-plugin "
  return 1
fi

続いて、スクリプトが再利用可能なget_sites_list関数（前述したもの）を使って企業内のすべてのサイトを取得します。

echo "企業の全サイトを取得..."

# 企業内の全サイトを取得
SITES_RESPONSE=$(get_sites_list)
if [ $? -ne 0 ]; then
  echo "Error: サイトの取得に失敗しました"
  return 1
fi

# レスポンスをクリーンアップ
CLEAN_SITES_RESPONSE=$(echo "$SITES_RESPONSE" | tr -d 'r' | sed 's/^[^{]*//')

次にスクリプトの核心部分が登場します：サイトのリストをループして、古くなったプラグインをチェックします。すべてのサイトを含むJSONオブジェクトであるCLEAN_SITES_RESPONSEがwhileループに渡され、各サイトに対して1つずつ操作が実行されます。

まずは、サイトID、名前、表示名などの重要なデータを変数に抽出します。

while IFS= read -r SITE; do
  SITE_ID=$(echo "$SITE" | jq -r '.id')
  SITE_NAME=$(echo "$SITE" | jq -r '.name')
  SITE_DISPLAY_NAME=$(echo "$SITE" | jq -r '.display_name')

  echo "サイト $SITE_DISPLAY_NAME の環境を確認中..."

次にサイト名を先に定義したget_site_details_by_name関数と一緒に使用して、すべての環境を含むサイト情報を取得します。

SITE_DETAILS=$(get_site_details_by_name "$SITE_NAME")
CLEAN_SITE_DETAILS=$(echo "$SITE_DETAILS" | tr -d 'r' | sed 's/^[^{]*//')

ENVIRONMENTS=$(echo "$CLEAN_SITE_DETAILS" | jq -r '.site.environments[] | "(.id):(.name):(.display_name)"')

次にID、名前、表示名などの各環境の情報を抽出するため、環境がループされます。

while IFS= read -r ENV; do
  ENV_ID=$(echo "$ENV" | cut -d: -f1)
  ENV_NAME=$(echo "$ENV" | cut -d: -f2)
  ENV_DISPLAY_NAME=$(echo "$ENV" | cut -d: -f3)

  echo "環境 $ENV_DISPLAY_NAME 用プラグインの確認中チェック..."

スクリプトはそれぞれの環境に対して、Kinsta APIを使ってプラグインの一覧を取得します。

PLUGINS_RESPONSE=$(curl -s -X GET "$BASE_URL/sites/environments/$ENV_ID/plugins" 
  -H "Authorization: Bearer $API_KEY" 
  -H "Content-Type: application/json")

CLEAN_PLUGINS_RESPONSE=$(echo "$PLUGINS_RESPONSE" | tr -d 'r' | sed 's/^[^{]*//')

次に、スクリプトが指定されたプラグインが環境に存在し、更新可能であるかどうかを確認します。

OUTDATED_PLUGIN=$(echo "$CLEAN_PLUGINS_RESPONSE" | jq -r --arg PLUGIN_NAME "$PLUGIN_NAME" '.environment.container_info.wp_plugins.data[] | select(.name == $PLUGIN_NAME and .update == "available")')

古くなったプラグインが見つかった場合、スクリプトはその詳細をログに記録し、SITES_WITH_OUTDATED_PLUGIN配列に追加します。

if [ ! -z "$OUTDATED_PLUGIN" ]; then
  CURRENT_VERSION=$(echo "$OUTDATED_PLUGIN" | jq -r '.version')
  UPDATE_VERSION=$(echo "$OUTDATED_PLUGIN" | jq -r '.update_version')

  echo "古いプラグイン $PLUGIN_NAME が $SITE_DISPLAY_NAME に見つかりました (環境: $ENV_DISPLAY_NAME)"
  echo "  現在のバージョン: $CURRENT_VERSION"
  echo "  更新バージョン: $UPDATE_VERSION"

  SITES_WITH_OUTDATED_PLUGIN+=("$SITE_DISPLAY_NAME:$ENV_DISPLAY_NAME:$ENV_ID:$UPDATE_VERSION")
fi

以下がログに記録された古いプラグインの詳細になります。

古いプラグイン example-plugin が Site ABC に見つかりました（環境: Production）
  現在のバージョン: 1.0.0
  更新バージョン: 1.2.0
古いプラグイン example-plugin が Site XYZ に見つかりました（環境: Staging）
  現在のバージョン: 1.3.0
  更新バージョン: 1.4.0

ここから、各プラグインのエンドポイントを使用して、プラグインの更新を実行します。スクリプトの全貌はこちらをご覧ください。

まとめ

Kinsta APIと対話するためのシェルスクリプトの作成方法について取り上げました。

Kinsta APIを活用することで、あらゆる要件に応じたタスクを自動化することができます。他のAPIと統合することで、意思決定と作業の効率化をさらに高めることも可能です。

また、Kinstaでは専用コントロールパネルのMyKinstaを継続的に改善し、サイト管理を簡素化する機能を常に開発しています。Kinstaにご興味がありましたら、ぜひ一度お試しください。

Joel Olawanle Kinsta

Kinstaでテクニカルエディターとして働くフロントエンド開発者。オープンソースをこよなく愛する講師でもあり、JavaScriptとそのフレームワークを中心に200件以上の技術記事を執筆している。