1. サーバーワークス サポートセンター
  2. Cloud Automator
  3. Cloud Automator Tips

コマンドラインツールを使ってジョブを別の Cloud Automator 組織に移行する

概要

このマニュアルでは Cloud Automator のコマンドラインツールを使用して、ジョブを別の Cloud Automator 組織に一括移行する作業手順を記載します。

 

移行手順

  1. Cloud Automator CLI をインストールする

    ご利用のプラットフォーム毎に、以下のリンクに記載されている手順で Cloud Automator CLI をインストールします。

    ・Windows
    ・Linux/macOS

     

  2. jq をインストールする

    Windows のインストール方法

    1. jq の 公式サイトからZIPパッケージをダウンロードします
    2. ダウンロードしたパッケージを解凍します
    3. スタートメニューを開いて「環境変数」を検索、「システム環境変数の編集」をクリックします
    4. 「環境変数」ボタンをクリックします
    5. 「<ユーザー名> のユーザー環境変数」ボックス内の Path をクリックして選択、「編集」ボタンをクリックします
    6. 「新規」ボタンをクリックして、解凍したフォルダのパスを指定します

    詳細なインストール手順についてはこちらのブログをご覧ください。

    MacOS のインストール方法

    Homebrewを使ってインストールします

    $ brew install jq
    $ jq --version
    jq-1.7.1

  3. 移行元の Cloud Automator 組織と移行先の Cloud Automator 組織にそれぞれログインして API キーを取得する

    以下のURLから移行元の Cloud Automator 組織 (以降、組織Aと記載します) にログインします。

    https://manager.cloudautomator.com/signin

    以下のURLで、ユーザー設定画面に移動します。

    https://manager.cloudautomator.com/user/account

    「キーを表示」ボタンをクリックして、APIキーをコピーします。

    ここで取得した API キーは以降の手順で利用するため、どこかに保管してください。

    同じように、移行先の Cloud Autoamtor 組織 (以降、組織Bと記載します) にログインして、同じく API キーを取得して保管してください。

  4. 組織Aに存在するジョブの情報をファイルに出力する

    組織Aに存在する全てのジョブの情報を Cloud Automator CLI を使ってファイルに出力します。



    まず、先ほどの手順で取得した組織Aの API キーを環境変数として設定します。

    $ export CLOUDAUTOMATOR_API_KEY=組織AのAPIキー

    組織Aに存在する全てのジョブ情報をファイル (export_job.json) に出力します。

    $ ca jobs > export_job.json

    export_job.json の中身を確認すると、ジョブの情報が JSON 形式で出力されていることが分かります。

  5. 移行対象のジョブを絞り込む

    export_job.json には組織A内に存在する全てのジョブの情報が出力されているため、jq コマンドを使って移行対象のジョブを絞り込み、import_job.json ファイルに出力します。

    以降の手順では「組織AのグループIDが 111 かつ、AWSアカウントIDが 222 のジョブを組織Bに移行する」パターンを例に説明します。



    以下の jq コマンドを実行すると、export_job.json に記載されているジョブの中から「グループIDが 111 かつ、AWSアカウントIDが 222 のジョブ」のみを抽出して import_job.json ファイルに出力します。

    $ jq '[
    .[] |
    select(.group_id == 111 and .aws_account_id == 222)
    ]' export_job.json > import_job.json

  6. 後処理を移行する

    移行対象のジョブに後処理を設定している場合、後処理も組織Bへ移行する必要があります。
    (組織をまたいで同じ後処理IDをジョブに設定することはできないため)



    「移行対象のジョブに後処理を設定しているかどうか」については、export_job.json を対象に以下の jq コマンドを使って調べることができます。

    $ jq "
    [
      .[].failed_post_process_id[],
      .[].completed_post_process_id[]
    ] | unique
    " export_job.json

    [
      100,
      200
    ]

    上記コマンドの実行例では「ID が 100 と 200 の2つの後処理を移行する必要がある」ということが分かるので、この2つの後処理を組織Bへ移行するパターンを例にして説明します。

    まず、組織Aに存在する全ての後処理の情報をファイル (export_post_process.json) に出力します。


    以下のコマンドを実行します。

    $ ca post-processes export > export_post_process.json

    続いて、export_post_process.json ファイルから、移行対象の後処理のみ (ID が 100 と 200 の後処理) を抽出して、import_post_process.json ファイルに出力します。


    以下のコマンドを実行します。

    $ jq '[
    .[] |
    select(.id == 100 or .id == 200)
    ]' export_post_process.json > import_post_process.json


    (3) の手順で取得した組織Bの API キーを環境変数で設定します。

    $ export CLOUDAUTOMATOR_API_KEY=組織Bの API キー


    以下の import コマンドを実行して、後処理を組織Bへインポートします。
    Importコマンドでは「インポートする組織と後処理」の確認画面が出るので、正しければyを入力してEnterを入力してください。
    Importが行われるとImport IDが表示されます。


    $ ca post-processes import import_post_process.json

    インポートする組織：組織B

    インポートする後処理
    - post-process-a
    - post-process-b

    上記の内容で後処理を作成して良いですか？ [y/n] 
    Import ID: 123456


    上記コマンドで出力された Import ID を元に、インポート結果を確認します。

    $ ca post-processes import-results -i 123456

    +------------+-------------------+---------------------------------+------------+
    | Source ID  | Destination ID  |   Post Process Name          |   Status    |
    +------------+-------------------+---------------------------------+------------+
    | 100          | 1000                 | post-process-a                    | Created   |
    +------------+-------------------+---------------------------------+------------+
    | 200           | 2000                | post-process-b                    | Created   |
    +------------+-------------------+---------------------------------+------------+

    Organization: 組織B
    Import ID: 123456 
    Import Status: Completed 
    Start Time: 2024-05-16 12:15:10 +0900 
    Finish Time: 2024-05-16 12:15:10 +0900

    上記のインポート結果の例では、

    ・組織Aの ID: 100 の後処理を、組織Bの ID: 1000 の後処理としてインポート (作成) した
    ・組織Aの ID: 200 の後処理を、組織Bの ID: 2000 の後処理としてインポート (作成) した

    ということが分かります。

    これで、後処理のインポートが完了しました。

  7. ジョブを移行する

    続けて、ジョブを組織Bに移行します。

    ジョブも同じく、組織をまたいで同じグループIDやAWSアカウントIDをジョブに設定することはできません。



    そのためインポートを実行する前に、組織Aのジョブとして紐づいていたグループIDとAWSアカウントIDを「組織BのジョブとしてどのグループIDとAWSアカウントIDを紐づけるのか」を事前に決める必要があります。

    以降の手順では上記画像のように、組織AではグループIDが 111、AWSアカウントIDが 222 と紐づいていたジョブを、組織BのジョブではグループIDが 333、AWSアカウントIDが 444 と紐づけるようにする、という前提で記載します。


    まず、(5) の手順で作成済みの import_job.json 内に記載されているジョブのグループIDやAWSアカウントIDを、組織BのグループIDとAWSアカウントIDにそれぞれ書き換えます。

    shapes-1718097698036.png

    以下のコマンドを実行すると、上記画像のようにグループID 111 を 333 に、AWSアカウントID 222 を 444 に置換して、import.json ファイルに出力します。

    $ jq '[
    .[] |
    select(.group_id == 111 and .aws_account_id == 222) |
    .group_id = 333 |
    .aws_account_id = 444
    ]' import_job.json > import.json

    その他の書き換えが必要なケースについては、こちらのマニュアルをご参照ください。

    続けて、ジョブを組織Bにインポートします。

    $ ca jobs import import.json

    インポートする組織：組織B

    インポートするジョブ
    - job-a
    - job-c

    上記の内容で後処理を作成して良いですか？ [y/n] 
    Import ID: 123456

    上記コマンドで出力された Import ID を元に、インポート結果を確認します。

    $ ca jobs import-result -i 123456

    +------------+------------------+----------------+--------------+
    | Source ID | Destination ID |   Job Name    |     Status    |
    +------------+------------------+----------------+--------------+
    | 1               | 2                       |  job-a             |  Created     |
    +------------+------------------+----------------+--------------+
    | 3               | 4                       |  job-c             |  Created     |
    +------------+------------------+----------------+--------------+

    Organization: 組織B
    Import ID: 88 
    Import Status: Completed 
    Start Time: 2024-05-16 12:15:10 +0900 
    Finish Time: 2024-05-16 12:15:10 +0900

    上記のインポート結果の例では、

    ・組織Aの ID: 1 のジョブを、組織Bの ID: 2 のジョブとしてインポート (作成) した
    ・組織Aの ID: 3 のジョブを、組織Bの ID: 4 のジョブとしてインポート (作成) した

    ということが分かります。


    Import Status が Failed と表示されている場合、何らかの理由によってジョブのインポートが失敗しています。

    +------------+------------------+---------------+--------------+
| Source ID | Destination ID |   Job Name  |     Status     |
+------------+------------------+---------------+--------------+
|  1              |                          |  job-a            |  Cancelled  |
+------------+-----------------+----------------+--------------+

+------------+------------------+---------------+--------------+-----------------------------------+
| Source ID | Destination ID |  Job Name   |     Status     |             Error Messages          |
+------------+------------------+---------------+--------------+-----------------------------------+
|  3              |                          |  job-c            |  Failed        |  更新権限がありません              |
+------------+------------------+---------------+--------------+-----------------------------------+

The import process was canceled because some jobs failed to import.
Check the error message from the failed job, modify the import file, and then run the import command again.
                                             
  Organization:   組織B                  
  Import ID:      123456                         
  Import Status:  Failed
  Start Time:     2024-05-16 12:15:06 +0900  
  Finish Time:    2024-05-16 12:15:06 +0900

    インポートに失敗したジョブ毎に Error Message に失敗した理由が表示されます。
    表示されたエラーメッセージメッセージを確認して、import_job.json ファイルを修正してください。

    これで、ジョブのインポートが完了しました。

 

注意事項

  • 組織Aのジョブを組織Bへ移行する際に、移行するジョブに紐づいているジョブログは移行されません
  • ジョブの世代管理情報は移行先の組織に引き継ぐことはできません
    • 例えば「EC2: AMIを作成」アクションで7世代の世代管理をしている組織Aのジョブを組織Bに移行した場合、組織Bでの初回実行時には1世代目として新しいAMIが作成されます
この記事は役に立ちましたか？
0人中0人がこの記事が役に立ったと言っています
他にご質問がございましたら、リクエストを送信してください

関連記事

このセクションの記事

もっと見る