てくなべ (tekunabe)

ansible / network automation / 学習メモ

セイコーソリューションズさん主催「Smart友の会」に参加してきました

はじめに

2025/04/11 に、セイコーソリューションズさんの東京本社で「Smart友の会」が開催されました。

コンソールサーバー SmartCS や、アクセス管理ソフトウェア SmartJumperのユーザー向けのイベントで、今回が初開催だったそうです。

今回はお誘いいただいて参加させていただきました。

方向音痴にありがたい

簡単ですが、当日の様子や感想などをまとめます。

Smart友の会 について

はじめに、セイコーグループの紹介、各プロダクトの紹介、Smart友の会の説明がありました。

SmartCS の生い立ちをを知って、歴史が長いのだなと思いました。

SmartJumpoer は、ログイン先を間違える、ログの取り忘れなどのオペミスなどの解消するためのソフト。新しい製品ですが、SmartGS が前身です。

ちらっと紹介されていた、去年テレビで放送された「知られざるガリバー」での特集も当時拝見しました。

www.seiko-sol.co.jp

事例ユーザーセッション

会場にいらっしゃった様々なユーザーさんによるセッションのパートでした。

SmartCS 導入した経緯、どのように使っているか、今後の要望などが、楽しい雰囲気で語られました。

触れていいのか迷う内容もありますので伏せますが、一つ取り上げますと、みなさんが口を揃えておっしゃっていたのは「SmartCS はなかなか壊れない」という点です。

コンソールサーバーは非常時に使う命綱的な側面もあるため、信頼性が髙い製品は、価値が高いのだろうなと感じました。

SmartJumper の成長プラン 

未定な情報も含まれるため詳細は伏せますが、今後も様々な機能強化が期待できそうなお話が聞けました。

懇親会

私自身の立場としては日ごろから SmartCS を利用している訳ではないんですが、ユーザーの話や、製品開発サイドのお話もきけて楽しかったです。

ひさびさに、ネットワークの話をしたような気がします。

感想

これまでも、各ユーザーさんに直接個別にフィードバックをもらうような取り組みはされていたと思います。

それに加えて、このようにユーザーが一同に集まると、誰かの意見に触発されて他の人の意見も出てきたり、いい化学反応が起きる場だなと思いました。

陸上競技で見かける風の時計や、SmartJumper のマスコット Junga(ジャンガ)くんのぬいぐるみ(かわいい)をいただきました。SmartJumper の momonga で Junga、とどこからか聞こえました。

いい時計

Junga(ジャンガ)くん(かわいい)

ありがとうございました!

show int さんも後日取り上げるそうです!

[2025/05/05 追記] 動画が公開されました!

www.youtube.com

システムアーキテクト試験を受験してきました(不合格確定)

はじめに

2024年の秋に、データベーススペシャリスト試験を受験(不合格)して、運良く午前Ⅰの免除が得られたので、この春もなにか受けようと思っていました。

今回は、システムアーキテクト試験(SA)を受けてきました。

確実に不合格なので、勉強方法の参考になりませんが、記録として少しまとめておます。

なぜ確実に不合格なのかというと、夕方に行きたいライブがあってそれを優先して、午後Ⅱを受けないという暴挙に出たためです。ライブはとても良かったです。

午後Ⅱの論文試験も到底無理だと思っています。

その計画でも当日会場に向かったのは、受かるためではなく、自分の現在位置や弱点を知るためでした。

準備

今回は準備らしい準備ができませんでした。

一冊参考書を買って午前Ⅱの範囲の解説は一度読んだのですが、そこか集中力が続かなくて、過去問対策はできませんでした。

午後Ⅰ、午後Ⅱはもっと対策できませんでした。

自分の現在位置を知るためには、「試験対策」しないのがあってますね。

怠惰の言い訳になったり、負け癖がついてしまうかもしれませんが・・・

当日

会場入口

午前Ⅰ が免除されるのはやはり、準備の心のゆとりと当日の朝のゆとりができますね。ありがたかったです。

午前Ⅱは少し時間が余りました。

ひとつ取り上げますと「コンテナ型仮想化におけるオーケストレーションの説明」の問題を間違えました。。「自律的」という言葉に引っ張られてしまいました。

午後Ⅰ は時間が余りませんでした。文章読むのと理解するのに時間がかかってしまいまい、空欄が目立つ状態でした。

前述どおり、午後Ⅱ は受けずに退出してしまいました・・。

なお、問題(と午前の解答)は、すでに公開されてます。

www.ipa.go.jp

感想

午後Ⅰ の時点でかなり課題を感じました。

なにか特別なことを知ってないと解けないという問題ではなく、与えられた情報と、持っているというより能力を活かして解くタイプの問題のように見えました。

能力が問われるので、試験対策としてちょっと知識を入れても、私には太刀打ちできないように感じました。

必要と感じた能力は以下の通りです。

  • 問題を読む能力
  • 理解する能力
  • 文章にする能力

まず、昼食後にある程度まとまった文章を読むのが難しかったです。

いろいろと課題がみつかりました。

おわりに

午前Ⅰ 免除は 2026年春期まで続くので、またなにか受けてみたいと思います。

直近は DB のリベンジするかどうか・・

[Ansible/AAP] Execution Environment(EE)のライフサイクルや含まれる ansible-core のバージョンをまとめた公式ページがある

はじめに

Red Hat Ansible Platform(AAP)には、各段階のサポート期限を示す Red Hat Ansible Automation Platform Life Cycle というページがあります。

Automation Controller において Playbook を実行するコンテナイメージである Execution Environment(EE、実行環境)にもライフサイクルを示すページがあることを、最近知りました。

EE に含まれる anisble-core のバージョンなどがまとまった表もあって便利なページでした。

access.redhat.com

上記ページに載っている各表についてご紹介します。

表: Ansible Automation Execution Environment Life Cycle

EE のライフサイクルは以下のような表になっていました。

Ansible Automation Execution Environment Life Cycle 抜粋(2025/03/28 現在)

例えば現状、最新の ansible-automation-platform-25 (内のイメージ、という意味。おそらく)の Full support ends は 2025/09/30 となっています。

表: Ansible-core Life Cycle

Ansible-core についてもライフサイクルが載っていました。Red Hat Ansible Automation Platform Life Cycle の方には載っていない情報です。

Ansible-core Life Cycle 抜粋(2025/03/28 現在)

ansible-core の 2.xx という単位でのリリースは、現状 5月と 11月にあります。このリリースのタイミングで前のバージョンがの「Maintenance Support 1 ends」を迎えるというサイクルのようです。

表: Ansible Automation Execution Environments and ansible-core versions

各 EE の ansible-core のバージョンなどが載っていました。

Ansible Automation Execution Environments and ansible-core versions(2025/03/28 現在))

例えば、EE ansible-automation-platform-25/ee-supported-rhel9 の Minimum Included Ansible-core version は ansible-core 2.16 とあります。

見出しの「Minumum」というのがたぶんちょっとしたポイントかなと思います。Red Hat Ansible Automation Platform Life Cycle の方でも、各 AAP のバージョンに含まれる Automation Controller のバージョンは「Minimum Automation controller」という見出しで示されていました。たとえば、AAP 2.4 の Minimum Automation controller は 4.4 で、実際は AAPP 2.4 の途中のパッチリリースで Automation controller 4.5 が含まれるようになています。なので、Minimum Included Ansible-core versionというも途中のリリースで ansible-core 2.17 にもなり得ることを指しているのではないかと思います。正確なところは不明です。

ただ、ansible-core 2.17 に限っていえば、マネージドノードの Python 2 のサポートが無くなったので、仮に ansible-automation-platform-25/ee-supported-rhel9 の中が ansible-core 2.17 になったら、Target Python の値(現状は Python 2.7 を含む)の見方を変える必要がありそうです。表の値が変わる可能性もあります。

おわりに

EE の中身を見ればかる情報もありますが、公式でまとまってるのは助かりますね。

[Ansible/AAP] 各プロダクトへの API による ping や status をまとめて確認できる /api/gateway/v1/status/

はじめに

Automation Controller には /api/v2/ping/ という API エンドポイントがあり、簡単な情報が得られます。この記事では API ping と呼ぶことにします。

Automation Controller の /api/v2/ping/ リファレンスから

以下のページ(Ansible Tower 時代)でも /api/v2/ping/ が紹介されています。

rheb.hatenablog.com

これに加え、以前の記事でもちらっと紹介しましたが、/api/gateway/v1/status/ というエンドポイントもあります。Platform GatewayAPI 経由で、配下の Automation Controller の API Ping や Automation Hub などの status が確認できます。ただし認証が必要です。Platform Gateway 経由なので AAP 2.5 で対応しています。

改めて見ると便利だなと思ったので、レスポンスのサンプルをいくつか掲載します。

  • 検証環境
    • AAP 2.5 2024/12/28 パッチリリース(コンテナベース)
      • Automation Controller 4.6.3
      • Automation Hub 4.10.1
      • EDA Controller 1.1.3
      • ホスト 192.168.1.5 にすべてのコンテナを配置

/api/gateway/v1/status/ のサンプル

すべて正常の場合

{
    "time": "2025-03-19T12:40:28.764471",
    "status": "good",
    "services": {
        "controller": {
            "status": "good",
            "nodes": {
                "192.168.1.5:8443": {
                    "url": "https://192.168.1.5:8443/api/v2/ping/",
                    "status": "good",
                    "response": {
                        "ha": false,
                        "version": "4.6.3",
                        "active_node": "192.168.1.5",
                        "install_uuid": "2e33d634-acac-43a0-9114-621f86ad9b21",
                        "instances": [
                            {
                                "node": "192.168.1.5",
                                "node_type": "hybrid",
                                "uuid": "65884d56-0636-8b8d-4343-eb43413873ac",
                                "heartbeat": "2025-03-19T12:39:53.949236Z",
                                "capacity": 136,
                                "version": "4.6.3"
                            }
                        ],
                        "instance_groups": [
                            {
                                "name": "controlplane",
                                "capacity": 136,
                                "instances": [
                                    "192.168.1.5"
                                ]
                            },
                            {
                                "name": "default",
                                "capacity": 136,
                                "instances": [
                                    "192.168.1.5"
                                ]
                            }
                        ]
                    }
                }
            }
        },
        "hub": {
            "status": "good",
            "nodes": {
                "192.168.1.5:8444": {
                    "url": "https://192.168.1.5:8444/pulp/api/v3/status/",
                    "status": "good",
                    // ...(略)...
                }
            }
        },
        "eda": {
            "status": "good",
            "nodes": {
                "192.168.1.5:8445": {
                    "url": "https://192.168.1.5:8445/api/eda/v1/status/",
                    "status": "good",
                    "response": {
                        "status": "OK"
                    }
                }
            }
        },
        "redis": {
            "mode": "standalone",
            "status": "good",
            "ping": true
        }
    }
}

Automation Controller が停止している場合

コンテナ automation-controller-websystemctl stop automation-controller-web.service --user で停止させた状態での場合のレスポンスです。

この場合でも レスポンスコードは 200 である点は注意です。

controllerstatusfailedで、hubedastatusgood です。

{
    "time": "2025-03-19T12:18:04.346283",
    "status": "failed",
    "services": {
        "controller": {
            "status": "failed",
            "nodes": {
                "192.168.1.5:8443": {
                    "url": "https://192.168.1.5:8443/api/v2/ping/",
                    "status": "failed",
                    "exception": "HTTPSConnectionPool(host='192.168.1.5', port=8443): Max retries exceeded with url: /api/v2/ping/ (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f155848aed0>: Failed to establish a new connection: [Errno 111] Connection refused'))"
                }
            }
        },
        "hub": {
            "status": "good",
            "nodes": {
                "192.168.1.5:8444": {
                    "url": "https://192.168.1.5:8444/pulp/api/v3/status/",
                    "status": "good",
                    "response": {
                    // ...(略)...
                    }
                }
            }
        },
        "eda": {
            "status": "good",
            "nodes": {
                "192.168.1.5:8445": {
                    "url": "https://192.168.1.5:8445/api/eda/v1/status/",
                    "status": "good",
                    "response": {
                        "status": "OK"
                    }
                }
            }
        },
        "redis": {
            "mode": "standalone",
            "status": "good",
            "ping": true
        }
    }
}

なお、この際 /api/controller/ 配下の API エンドポイントはエラーになります。

(比較用) 個別の API ping サンプル

比較、参考のため、同じ環境を利用して各プロダクト個別の API ping の例も2つ掲載します。

Platform Gateway への API ping

GET /api/gateway/v1/ping/

{
    "version": "2.5",
    "pong": "2025-03-19 09:12:33.928346",
    "status": "good",
    "db_connected": true,
    "proxy_connected": true
}

Automation Controller への API ping

GET /api/controller/v2/ping/

{
    "ha": false,
    "version": "4.6.3",
    "active_node": "192.168.1.5",
    "install_uuid": "2e33d634-acac-43a0-9114-621f86ad9b21",
    "instances": [
        {
            "node": "192.168.1.5",
            "node_type": "hybrid",
            "uuid": "65884d56-0636-8b8d-4343-eb43413873ac",
            "heartbeat": "2025-03-19T09:13:14.048393Z",
            "capacity": 136,
            "version": "4.6.3"
        }
    ],
    "instance_groups": [
        {
            "name": "controlplane",
            "capacity": 136,
            "instances": [
                "192.168.1.5"
            ]
        },
        {
            "name": "default",
            "capacity": 136,
            "instances": [
                "192.168.1.5"
            ]
        }
    ]
}

おわりに

AAP 2.5 の各プロダクトへの API ping や status を、Platform Gateway 経由でまとめて確認できるエンドポイント /api/gateway/v1/status/ のご紹介をしました。

認証が必要ではありますが、まとめて確認できるのは便利だなと思いました。

ネットワーク自動化システムにおけるネットワーク機器のコンフィグをデータストアと捉えて考える

はじめに

自動化自動化、と言いますが、見方次第では、ITインフラの作業を効率化する、一種の業務システムだと捉えています。

そのため、自動化システムのことを考えるときは、一般的(とは・・?ですが)なシステム設計、開発での考え方を参照して当てはめることがあります。

システムにおけるデータベースと、ネットワーク機器のコンフィグを重ねて考えたことがあったので、簡単ですがまとめます。

コンフィグをデータストアと考える

ネットワーク機器は、コンフィグ(Configuration)と呼ばれる設定情報を持っています。そのコンフィグを手動なり、自動化なりで変更して、設定を変更します。

ある時、コンフィグを持つ領域って、ある意味データストアかも、と考えました。

データベースに対して SQL で insert、update、delete する操作が、ネットワーク機器に CLIAPI で設定変更する操作と重なりました。

どう当てはめて考えるか

コンフィグはデータストアかも、という考えが、一番リンクしたのは、書籍「単体テストの考え方/使い方」を読んだときです。

book.mynavi.jp

「第10章 データベースに対するテスト」内の「10.3 テスト・データのライフ・サイクル」に、統合テストにける不要なデータの後始末の考え方が書かれています。

後始末の方法が4つ書かれていて、4つめの「テスト・ケースの実行前にデータの後始末を行う」がもっとも優れている、としています(P350)。もしテスト・ケース実行後に後始末だと、テスト・ケースを中断した場合に後始末がされず、それが別のテスト・ケースに影響を与えてしまうから、などが「実行 始末」がいいとする理由です。

非常に既視感があります。以前、ネットワーク機器への設定変更の Ansible の Playbook のテストを組んだとき、最初は実行後にコンフィグを後始末していました。が、やはりテストに失敗するとその残骸の影響で次のテストを意図通り実行できないことがありました。なので、「実行 始末」に変更しました。

こんな経験を通じて、ネットワーク機器のコンフィグの領域はデータストアとして扱うと、設計のヒントになるのではと考えるようになりました。

そもそも仮想のネットワーク機器をテストのたびに作り直せて、それが素早くできればベストですが。

そういえば

RFC 8342 や、RFC 8345 には「configuration datastore」という言葉がでてきます。

なので、そんな突飛な話でもないかなと思いました。

おわりに

最初の話にもどりますが、「自動化」はITインフラの作業を効率化するの業務システム、と捉えるとまだ色々とヒントが得られるのではないかと考えています。

[Ansible/AAP] AAP 2.5 のサブスクリプションの期限が切れた時の様子と再適用の作業ログ(Red Hat Developer Subscription for Individuals の場合)

はじめに

自宅の検証用の AAP では、無料のサブスクリプションである Red Hat Developer Subscription for Individuals をありがたく利用させていただいています。このサブスクリプションの有効期限は1年です。有効期限が切れても再度取得できます。

今回、有効期限が切れてから再取得、AAP 2.5 への再適用という一連の作業を行いました。そんな頻繁にすることではないので、せっかくなのでブログとして記録しておきます。

なお、あくまで私の環境でこの状況でこうやったらこうなった、という作業ログでしかありません。あらゆる状況での挙動、仕様を示すものではありませんのでご了承ください。

  • 検証環境
    • AAP 2.5 2024/12/18 パッチリリース

主な流れ

日付 やったこと
2024/12/28 サブスクリプションの期限切れ
2024/12/28 サブスクリプションの申請(AAPには未反映)
2025/01/28 頃 猶予期限切れ
2025/03/17 サブスクリプションの AAP への適用

上記のように期限には2種類あります。本記事では、通常の期限を単に「期限」、それを超えてからの猶予(画面上は grace period)は「猶予期限」と表記します。

2024/12/28 旧サブスクリプションの期限切れの様子

サブスクリプションの期限切れた時に確認したことです。

有効期限が切れたてのタイミングでは、以下のようなサブスクリプション設定画面になりました。

期限切れ

残りホスト(Host remaining)はまだ余裕がありますが、期限が 2024/12/28 に切れ、ステータスが「Out of compliance」となっていることが分かります。

加えて、猶予期限が 30日あることのメッセージが画面上部に表示されました。

カスタマーポータルでサブスクリプション一覧を確認すると「Red Hat Developer Subscription for individuals」が表示されなくなっていました(少なくともデフォルトでは)。

Red Hat Developer Subscription for individuals はアクティブなサブスクリプションとして表示されない

Red Hat Hybrid Cloud Console のサブスクリプション一覧には「Red Hat Developer Subscription for individuals」が表示されていて、クリックすると有効期限が切れたものが確認できました。

切れたサブスクリプションがか確認できる

この日(2024/12/28)、 Demo Job Template を実行してみると、実行自体はできていたようでした。対象ホストは localhost です。

期限が切れたが猶予期限内のジョブテンプレートの実行

2024/12/28 新サブスクリプションの申請(AAPには未反映)

引き続き 2024/12/28 に、https://developers.redhat.com/d4i-renewal から「Red Hat Developer Subscription for individuals」の更新作業をしました。

renewed!

更新後、カスタマーポータルでサブスクリプション一覧を確認すると期限が 2025/12/18 の「Red Hat Developer Subscription for individuals」が新しいものが確認できました。

新しいサブスクリプションが表示された

Red Hat Hybrid Cloud Console のサブスクリプション一覧でも期限が 2025/12/28 になったものが確認できました。

新しいサブスクリプションが表示された

AAP には新しいサブスクリプションをまだ反映していない状態で、API /api/controller/v2/config/ を GET すると以下のレスポンスが返ってきました。一部マスクしたり説明(画面などの情報と合わせての推察を含みます)を付加したりしています。

{
    "time_zone": "UTC",
    "license_info": {
        "instance_count": 16,
        "license_date": 1735361999,    // 2024/12/28 13:59:59 (JST)
        "license_type": "developer",
        "sku": "RH00798",
        "usage": "Development/Test",
        "pool_id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx_1",
        "satellite": null,
        "valid_key": true,
        "product_name": "Red Hat Ansible Automation Platform",
        "support_level": "Self-Support",
        "account_number": "xxxxxxx",
        "subscription_id": "xxxxxx_1",
        "subscription_name": "Red Hat Developer Subscription for Individuals",
        "deleted_instances": 0,
        "reactivated_instances": 0,
        "current_instances": 1,
        "automated_instances": 1,
        "automated_since": 1735395115,
        "free_instances": 15,
        "time_remaining": -34244,  // 期限がマイナスなので期限切れ
        "trial": false,
        "grace_period_remaining": 2557756,  // 猶予期限の残り 約29日
        "compliant": false,   // 有効ではない状態
        "date_warning": true,
        "date_expired": true    // 期限が切れ
    },
    "version": "4.6.3",
    // ....(略)....

2024/12/29 期限切れ翌日

期限が切れたサブスクリプションのままの状態で AAP のサブスクリプション設定画面を見ると、ちゃんと猶予期限の残り日数が 29日に減っていました。

猶予期限の残り日数が減った

2025/03/17 新サブスクリプションの AAP への適用

猶予期限が切れた時の画面を確認するために、あえて放置していたのですが、だいぶ経ってしまいました・・

適用前確認

これから新しいサブスクリプションを AAP に適用しますが、まずは表示の確認です。猶予期間はとっくに過ぎていて、Days remaining は「-80」ですが、画面上部の赤いところは「0 days」でした。

猶予期限も過ぎた後

Demo Job Template も実行してみたところ正常なようにも見えますが、猶予期限も過ぎている状態のため、あてにしないほうが無難かと思います。

実行結果

適用と事後確認

いよいよ新しいサブスクリプションの適用です。サブスクリプション設定画面では期限が 2025/12/28 の新しいサブスクリプションが選択できるようになっていたので選択します。

新しいサブスクリプションの適用

EULA を確認して進めると、無事に適用できました。ステータス Compliant になり、心が穏やかになりました。

無事適用

事後確認の一環として、念のためまた、API /api/controller/v2/config/ を GET すると以下のレスポンスが返ってきました。

{
    "time_zone": "UTC",
    "license_info": {
        "instance_count": 16,
        "license_date": 1766897999,    // 2025/12/28 13:59:59 (JST)
        "license_type": "developer",
        "sku": "RH00798",
        "usage": "Development/Test",
        "pool_id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx_2",   // 変わった
        "satellite": null,
        "valid_key": true,
        "product_name": "Red Hat Ansible Automation Platform",
        "support_level": "Self-Support",
        "account_number": "xxxxxxx",
        "subscription_id": "xxxxxx_2",   // 変わった
        "subscription_name": "Red Hat Developer Subscription for Individuals",
        "deleted_instances": 0,
        "reactivated_instances": 0,
        "current_instances": 1,
        "automated_instances": 2,  // ホスト追加など試したため増えた(更新とは無関係)
        "automated_since": 1735395115,
        "free_instances": 14,
        "time_remaining": 24704810,   // 期限の残り 約286日
        "trial": false,
        "grace_period_remaining": 27296810,    // 猶予期限の残り 約316日
        "compliant": true,  // 準拠(有効な状態)
        "date_warning": false,
        "date_expired": false   // 期限内
    },
    "version": "4.6.3",

もちろん、Demo Job Template の実行も問題なくできました。

無事実行できた

おわりに

AAP 2.5 に適用していたサブスクリプションRed Hat Developer Subscription for Individuals」の期限と猶予期限がきれた時の様子と、再適用した時の様子をまとめました。

[Ansible/AAP] インストール済み AAP 2.5 環境のパッチリリース日付(おそらく)を確認する

はじめに

Red Hat Ansible Automation Platform (AAP) のバージョンを指し示すときに、以前より少し迷うようになりました。特に AAP 2.5 から導入された Platform Gateway のバージョン確認方法が分からず困っていました。

Platform Gateway のバージョンそのものは見つけられなかったのですが、API のレスポンスヘッダーを見るとパッチリリース日らしき値が含まれていることに気が付きました。これで区別できるかなと思いました。

確認したことをまとめます。

  • 検証環境
    • AAP 2.5 2024/12/18 パッチリリース時点

経緯

AAP 2.3 からバージョン管理方法が変更され、2.2.1 のようなセマンティックバージョニングではなくなりました

たとえば、2.5 系であればバージョンは 2.5 のみ(2.5.02.5.1 はない)です。その代わり、パッチリリースの日付で区別されるようになりました。

例: Ansible Automation Platform patch release March 12, 2025

インストーラーのファイル名としては ansible-automation-platform-setup-2.5-9.tar.gz のように、バージョン番号-連番 になっています。同じリリース日でもコンテナ版だと ansible-automation-platform-containerized-setup-2.5-11.tar.gz のように連番部分が異なります。

さらに AAP 2.5 では、従来のプロダクトに加え Platform Gatewayという統合UIが仲間に加わりました。

こんな経緯もあって「このバージョンだと XX という現象が起きるんだけど」のように、バージョンを指し示すとき少し迷うようになりました。

特に UI 固有の現象であれば、Platform Gateway のバージョンを示したいのですが、画面右上の「?」 > 「情報」を表示しても、Platform Gateway 自体のバージョンは表示されません。

Platform Gateway 自体のバージョンは表示されない

表示されてる他の各プロダクトのバージョンから求めることもできそうですが、やや手間に感じました。

API レスポンスを見てみる

どこかにバージョンを特定できるヒントはないかなと探していたのですが、API のレスポンスヘッダーの値に、パッチリリース日らしき値が含まれていました。この値をもって Platform Gateway のバージョンも間接的に特定できるかなと思いました。

/api/ 配下ならどこでもいいのですが、ここでは /api/gateway/v1/ping/ にします。

x-api-product-version: 2.5.20241218 のように 2.5 の後に日付 YYYYMMDD らしき数値が並んでいます。ここが 2024/12/18 というパッチリリースの日付と一致していました。

$ curl -k -i https://<Platform Gateway のアドレス>/api/gateway/v1/ping/ -u admin
Enter host password for user 'admin':  # パスワードを入力
HTTP/1.1 200 OK
....(略)...
x-api-product-version: 2.5.20241218
x-api-product-name: AAP gateway
....(略)...

{"version":"2.5","pong":"2025-03-13 08:28:13.362361","status":"good","db_connected":true,"proxy_connected":true}

2024年10月にインストールしたときは X-API-Product-Version: 2.5.0.dev1 となっていました。YYYYMMDD の値が含まれるようになったのは、どこかのタイミングだったようです。

なお、/api/gateway/v1/ping/ 自体は、認証情報不要なエンドポイントですが、認証情報を指定しないと、X-API-Product-Version レスポンスヘッダーは含まれませんでした。

[2025/04/03 追記]

2025/03/26 パッチリリースの Ansible Automation Platform 2.5 Containerized Setup インストーラansible-automation-platform-containerized-setup-2.5-11.tar.gz でインストールした環境では、X-API-Product-Version: 2.5.20250326 でした。

おわりに

以前と比べると、同じバージョン(例えば 2.5 内)のリリースサイクルが早くなっていること自体はありがたいです。なので、バージョン管理方法の変更のメリットは享受できていると思います。

できれば、画面右上の「?」 > 「情報」からパッチリリースの日付、または Platform Gateway 自体のバージョンが確認できるといいなと思いました。