【ITニュース解説】Build an Interactive Bash CLI for DevOps Reports

システム運用では、サーバーやアプリケーションの状態を常に把握することが重要だ。特に、ソフトウェアの開発と運用を一体的に進める「DevOps」という考え方においては、システムの健康状態を迅速にチェックし、問題があればすぐに対応できる仕組みが求められる。しかし、多くの現場では、特定のシステム（例えばKubernetesクラスター）の健康状態をチェックするために、様々なエンジニアがそれぞれ異なるシェルスクリプトを個別に作成・使用している場合がある。これでは、確認作業の手順が統一されず、インシデント発生時の対応に時間がかかったり、属人化が進んだりといった問題が生じる。この記事で解説されているのは、このような課題を解決し、クラスターの状態報告を標準化・効率化するための「インタラクティブなBashコマンドラインインターフェース（CLI）ツール」の構築方法である。

このツールは「opsreport」と名付けられ、Kubernetesクラスター内で問題のある「Pod」（アプリケーションの最小単位）や「Ready状態ではないNode」（サーバー）を報告する機能を持つ。opsreportには三つの主要な動作モードがある。一つ目は、人間が操作しやすいようにメニュー形式で選択肢を表示する「インタラクティブメニューモード」。二つ目は、一定間隔で情報を自動更新し続ける「ライブリフレッシュビューモード」。そして三つ目は、自動化された処理、例えばCI/CDパイプライン（ソフトウェア開発・デプロイの自動化工程）などから実行されることを想定した「非インタラクティブモード」だ。この非インタラクティブモードでは、整形されていない「TSV」（タブ区切り値）形式でデータを出力し、スクリプトの実行結果を「終了コード」として通知することで、他のプログラムが結果を容易に判断できるようにしている。この設計パターンは、Kubernetesだけでなく、AWS CLIやDocker、Terraformなど、様々なコマンドラインツールが出力するデータを処理する際にも応用できる。

なぜBashというシェルスクリプト言語がこのツールの開発に選ばれたのか。それは、多くの運用ツールがJSON形式で情報を出力することが多く、Bashはそのようなデータをフィルタリング・加工するのに非常に適しているからだ。さらに、このツールはWebダッシュボードやデータベース、特定のプログラミング言語の実行環境を必要とせず、既存のジャンプホスト（踏み台サーバー）に通常インストールされているBash環境だけで動作するため、導入が非常に容易というメリットがある。しかし、Bashにも限界がある。もし、過去の履歴を永続的に保存したい、データをグラフで可視化したい、あるいは複数ユーザーが同時にアクセスするような複雑な機能が必要な場合は、Grafanaのようなより高度な専用ツールを検討すべきだ。Bashはあくまで、データの取得、フィルタリング、フォーマット、そして簡単な条件判断に特化したツールとして活用するのが最も効果的である。

opsreportを動作させるには、いくつかの前提条件がある。Bashのバージョンは4.4以降が必要で、特にmacOSの標準Bashは古い場合があるため、Homebrewなどのパッケージマネージャーで新しいバージョンをインストールする必要がある。データ収集にはKubernetesクラスターを操作する「kubectl」と、JSONデータを処理する「jq」のバージョン1.6以降、そして表形式を整形する「column」コマンドが必要となる。スクリプトの品質を保つため、「shellcheck」という静的解析ツールで潜在的なエラーをチェックすることも強く推奨されている。

このスクリプトの重要な設計原則は、「ターミナルが接続されているか否か」で挙動を変えることだ。ターミナル接続がある場合（人間が直接操作している場合）は、メニュー、色付け、画面クリアといった「インタラクティブ」な機能を提供する。一方、ターミナル接続がない場合（CI/CDパイプラインなどの自動処理）は、ログに記録しやすい「プレーンで安定した出力」に切り替わる。この切り替えはスクリプトの冒頭でBashのテスト (-t 0 && -t 1は標準入力と標準出力がターミナルに接続されているかを判定する) を使って行われる。また、NO_COLORという環境変数が設定されていれば、色付けを無効にするという一般的な慣習にも対応している。

スクリプトの中心となるのは、実際のデータを集めてくる「コレクター関数」だ。例えば、「unhealthy_pods」関数はkubectl get podsコマンドでKubernetesのPod情報をJSON形式で取得し、それをjqでフィルタリングして、問題のあるPod（完了していないPodや、Running状態だがコンテナがReadyではないPod）を抽出する。そして、それらの情報を「名前空間」「Pod名」「状態」というTSV形式で出力する。同様に、「notready_nodes」関数はkubectl get nodesコマンドでノード情報を取得し、jqで「Ready状態ではない」ノードを抽出し、TSV形式で出力する。これらのコレクター関数は、データの収集に徹し、色付けや整形といった表示に関する処理は一切行わない。これにより、データの再利用性が高まり、スクリプトのテストも容易になる。

コレクター関数が集めた生データを、人間が見やすい形に整形して表示するのが「render」関数の役割である。この関数は、ターミナル接続がある場合のみ、ヘッダーを付け、columnコマンドで表の列を揃え、問題の有無に応じて色付きのメッセージ（赤や緑）を表示する。ターミナル接続がない場合は、ヘッダーも色付けもなく、純粋なTSVデータをそのまま出力する。render関数は、データの有無やコレクターの成否によって異なる「終了コード」を返す点が非常に重要だ。データが見つからなかった場合は「0」（問題なし）、データが見つかった場合は「1」（問題あり）、そしてデータ収集自体が失敗した場合は「3」（コレクター失敗）を返す。この明確な終了コードの契約により、CI/CDパイプラインはスクリプトの実行結果を確実に判断し、適切な次のアクションを実行できる。

opsreportのインタラクティブな操作を実現するために、「run_menu」関数ではBashの組み込みコマンドである「select」を使って番号付きのメニューを表示する。ユーザーは数字を入力することで、必要なレポートを選択できる。「run_watch」関数は、画面をクリアしてから最新のレポートを表示し、指定された時間（INTERVAL）だけ待機することを繰り返すことで、ライブビューを提供する。待機中にはread -tコマンドでキー入力を監視し、ユーザーが「q」キーを押すとライブビューが終了する仕組みだ。また、このライブビューでは、tput civisコマンドで一時的にカーソルを非表示にし、tput cnormで復元するといった細かな配慮がされている。予期せぬスクリプト中断（例えばCtrl-C）時にもカーソルが正しく復元されるよう、「trap」コマンドで終了時の処理を定義している。

作成したスクリプトの品質を確保するため、徹底した検証とテストが不可欠だ。まず「shellcheck」を使ってコードの静的解析を行い、未引用の変数など、潜在的な問題を修正する。次に、非インタラクティブモードでの終了コードの動作をテストする。例えば、問題のあるKubernetes状態を模倣したダミーデータを用意し、スクリプトが正しく「1」（問題あり）や「0」（クリーン）、あるいは「3」（コレクター失敗）や「2」（使用エラー）を返すかを確認する。インタラクティブモードでは、メニュー選択やライブビューでの終了動作、Ctrl-C後のカーソル復元が正しく機能するかを検証する。色なし出力が正しく行われるかを確認するため、「NO_COLOR=1」環境変数を設定してテストすることも重要だ。より体系的なテストには、「Bats」のようなシェルスクリプト向けのテストフレームワークの利用も検討できる。さらに、実際の運用環境での「RBAC」（Role-Based Access Control、権限管理）がkubectlの動作に与える影響を確認することも必要だ。例えば、kubectlが情報取得に失敗した場合、opsreportが正しく「3」の終了コードを返すかを確認することは、誤ったレポートを防ぐ上で重要となる。

opsreportの設計パターンは非常に汎用性が高く、様々な運用レポートに応用できる。例えば、AWS CodeDeployのデプロイ失敗、Dockerコンテナの繰り返し再起動、Terraformの構成と実際のインフラの差異（ドリフト）などを監視するコレクター関数を追加することで、多様な運用監視ツールに拡張できる。もしメニューの選択肢が増えすぎた場合は、「fzf」や「gum」といったツールを使って、より高度な「ファジー選択」（曖昧なキーワードでの絞り込み）機能を導入することも可能だ。ただし、これらは追加の依存関係となるため、シンプルなBash環境で動かす必要がある場合は注意が必要だ。このスクリプトは、一目で全体を把握できる程度の規模に保つのが理想的であり、もしロジックが複雑になりBashでは管理しきれなくなった場合は、GoやPythonのようなより本格的なプログラミング言語でのツール開発を検討すべきだろう。