The Operations Loop — サーバーのインストールを運用の始まりに

AI_Manager

サーバーを1台インストールすることは、運用の準備の一部に過ぎない。誰がどのような環境に配置したのか、どのようなソフトウェアが実行されているのか、どこに接続すべきか、そして障害をどのように検知し復旧するのかまで繋がって初めて、運用可能なサーバーとなる。

本プロジェクトは、Rocky Linuxサーバーのインストールから初期設定、詳細な資産登録、自動インベントリ更新、実際の監視メトリクスの受信までを連携させるインフラの実習である。Oracle VirtualBox上に中央運用網とPROD・DEV・STG環境を分割し、Zabbix・NetBox・AWX・Git・PXEを一つの運用フローとして構成した。

実習環境は、個人のPC上のVMである。サービスやVMの障害をテストするための環境であり、物理ホストやストレージまで冗長化した運用システムではない。検証結果は、個別の検証プロジェクトのタスクID・時刻・観測値を基準に区別する。

• 1. プロジェクト概要
• 2. 解決しようとする運用の課題
• 3. サーバー構成とネットワーク
• 4. 1台のサーバーが運用に加わるプロセス
• 5. 添付した資産収集YAMLをどのように反映したか
• 6. なぜこのように設計したのか
• 7. 障害シナリオと可用性の境界
• 8. オンライン環境と閉域環境の両方を考慮した運用
• 9. このプロジェクトで示したいスキル
• 10. 関連記事と技術的根拠
• あわせて読みたい記事と構成資料

1. プロジェクト概要

ツールごとのインストール完了ではなく、1台のサーバーの識別子と管理IPが、インストール・資産・自動化・監視を通じて一致しているかを完了基準とした。APIが200を返してもインベントリに対象が存在しないか、Zabbixの最新値が取得できない場合はオンボーディング成功として処理しない。

PROD・DEV・STGの3つの対象に対する実際のオンボーディングを完了した。AWX Workflow 22・30・38で、資産登録・インベントリ更新・最新監視値の確認まで成功した。中央ノードの双方向電源喪失、Proxy転送切断および遅延データの復旧、資産競合の拒否、個別DBの復元もテストした。各成功の条件と未検証の範囲は検証記事に記載している。

2. 解決すべき運用上の課題

OSのインストール、Excelの資産台帳の更新、Ansibleホストの追加、監視への登録を個別に行うと、抜けや不一致が発生する。再インストールしたサーバーが以前の資産に上書きされたり、NATアドレスが管理IPとして登録されたり、監視にホストだけが存在してデータが存在しない状態も発生する。

これを軽減するため、承認済みのホスト名・環境・管理IPを入力基準とし、実際のゲストから読み取ったhostname・machine ID・インターフェースと比較する。NetBoxには文字列のIPだけでなく、VM/Device → Interface → IPAddress → primary_ip4の関係を作成し、AWXはその関係からインベントリを取得する。登録を再実行する際は、既存の識別子と管理主体を確認する。

2つ目の課題は障害範囲の説明である。Zabbix Serverが2台あるという事実だけでDBまでHAになるわけではない。NetBox Webの2台についても、PostgreSQL・Redis・共有メディア・アクセスアドレスが連動して動作してはじめて意味を持つ。各レイヤーの切り替え条件と、残存する単一障害点を個別に示した。

インタラクティブ・アーキテクチャ — 全体構造と運用フロー

3. サーバー構成とネットワーク

実際のPCはWindows 11 Pro、Intel Core Ultra 9 185H（16コア/22論理プロセッサ）、使用可能メモリ約31.4GiB、2TB SSDである。VMには必要な分だけメモリを割り当て、PXEインストール対象は順次実行する。インストール時に4GiBが必要な対象も、インストール後は1GiBに削減する。

ホスト名において、opsは本番サービス、quorumは障害判定、edgeは環境エントリーポイント、provisionはインストール基盤を意味する。オペレーティングシステムが認識するFQDNは호스트명.fullmoon.testである。公開サイトのドメインと実習用DNSを分離している。

環境別のPXE対象にはNATまたはブリッジNICを接続しない。中央から対象サーバーへのSSHは、該当環境のBastionを経由する。環境間の通信は基本ブロックし、必要な送信元・宛先・ポートを明示する。初期パッケージの取り込みに使用した管理用VMのNATと内部サービスの経路は、構築手順の記事内で区別して説明する。

4. 1台のサーバーが本番稼働に参加するプロセス

リモートサーバーにNetBox管理者パスワードを配置しない。リモート収集は必要な範囲で管理者権限により実行し、APIリクエストはAWX Execution Environmentから資格情報を注入されて実行される。SSH秘密鍵はBastionにコピーしない。

AWXのインベントリ自動追加は実装可能な機能である。NetBox公式のAnsible inventory pluginをSCM inventory sourceとして接続し、登録作業が成功した後にWorkflowがinventory syncと検証作業を続けて実行するように構成した。NetBoxトークンは資産書き込みとインベントリ読み取りの用途を分離した。

PXE以降の接続は、中央のインストール完了コントローラーが担当する。承認されたSSH host keyと、インストール完了の目印・hostname・machine IDを確認した後、該当サーバーのWorkflowを開始する。最初のサーバー身元承認は管理者の確認段階として残し、承認後は資産・インベントリ・監視登録を連続して実行する。再インストールによってmachine IDが変わった場合は、自動上書きではなくレビュー対象として残す。

5. 添付資産収集YAMLをどのように反映したか

添付のYAMLは単なるhostname登録機ではない。実行中のLinuxプロセスと /proc 情報を出発点として、OS・CPU・ディスク・ネットワーク・製品・仮想化・バックアップエージェントの痕跡を収集する資産台帳である。この意図を維持し、元のCustom Field 34個に収集状態・時刻・エラー・machine IDの4項目を追加した。

元の現場アドレス・Site・環境判定ルールは、本実習のPROD/DEV/STGと明示的なinventory変数に置き換えた。 primary_ipv4 文字列だけを保存していた部分に、NetBoxネイティブのIPAM関係を追加した。既存の承認済みSite・役割・Platform・ユーザータグは、収集結果で無条件に上書きしない。

すべての商用DB/WASのバージョン検知をインストール検証したわけではない。実行ファイルの所有権・許可リスト・namespaceを確認し、不確実な起動スクリプトをrootで実行しない。確認できなかったバージョンは未確認のまま残す。コンテナ内部の製品収集も、ホスト資産収集とは別の課題として分離する。

6. なぜこのような設計にしたのか

中央の2つのVMに複数のサービスを配置した理由

本番環境では、役割ごとのリソース・セキュリティ・障害の分離を考慮してサーバーを分ける方が有利である。本実習では32GBのPC内でサービス間の連携とフェイルオーバーを検証する必要があるため、中央の2つのVMに役割を集約した。NetBox、Zabbix、データサービスはComposeプロジェクトとボリューム・アカウントで分離し、AWXは公式Operatorのインストール・管理構造に従うようにK3s上に配置した。

ただし、コンテナを分けたからといってVMの障害まで隔離されるわけではない。多数のサービスはhost networkを使用しており、CPU・メモリ・ディスクI/O・カーネル・VM再起動の影響を共有している。メモリ制限とジョブの同時実行数制限は、この条件下でのリソース管理手段である。

Zabbix Server HAとProxyを分けた理由

中央の2つのServerはNative HAによってActive/Standbyの役割を分割し、共通のDBを使用する。環境ごとのActive ProxyはローカルAgentのデータを収集して中央に転送する。中央との接続が切断された場合、Proxyのディスクバッファで収集を継続できるが、Proxy VM自体が停止するとその機能も失われる。AgentからProxy間、およびProxyからServer間はそれぞれPSKで認証する。

NetBox HAをデータ層まで分けた理由

NetBox App・Workerを2つの中央ノードに配置し、PostgreSQLはPatroni、RedisはSentinel、アクセスアドレスはKeepalived/HAProxyで構成した。NetBoxの2つのノードは同じSECRET_KEYとトークンpepperを使用し、メディアは共通のNFSを参照する。3つ目のetcd/Sentinelは、2つの中央ノードのうち1台を失った場合のクォーラムを確保する。

NFS自体は単一ノードである。したがって、この構成におけるNetBox HAの範囲は中央ノード1台の障害を中心に定義する。メディアストレージの障害まで耐える完全なストレージHAとは表現しない。PostgreSQLはsynchronous modeを使用するがstrict modeではないため、すべての障害においてRPO 0を保証するわけではない。

ProxyとBastionを一緒に置いた理由

各環境の監視収集ポイントと自動化のエントリポイントを1つのVMに集約し、小規模な実習のリソース使用量を削減した。Bastionは承認された対象のSSHポートにのみフォワードし、対話型シェル・エージェントフォワードを制限する。この配置には、Proxy/Bastionの1台の障害が監視と新規自動化の双方に影響を与えるというトレードオフがある。実際の運用では、規模やセキュリティ境界に応じて分離することができる。

GitとAWXを置いた理由

プレイブックファイルがあることと、同じ設定を再現できることは別物である。Gitのコミット、AWXのProject sync、Job ID、対象のinventory、Execution Environmentのバージョンを紐付けることで、どのコードで何を変更したのかを追跡できる。NetBoxを実資産の基準として使用しつつ、初期インストールの承認リストは別のbootstrap inventoryとして維持する。

7. 障害シナリオと可用性の境界

この表は設計上の想定範囲である。実際に実施した障害、収集の空白、復旧時刻、データの保持有無は検証記事で個別に判定する。画面上の障害アニメーションは、実際のサーバー状態の照会やコマンドの実行を行わない。

8. オンライン網と閉域網をともに考慮した運用

オンライン網では公式リポジトリから検証済みのバージョンをダウンロードし、イメージダイジェスト・RPM署名・Gitコミットを記録する。閉域網では同バージョンのRPMと依存関係、コンテナイメージ、K3sイメージ、AWX EE、Ansible collection、Git bundle、OSインストールツリーを持ち込む。CA・DNS・NTPも内部で提供する必要がある。

インターネットのない対象サーバーには、内部HTTPリポジトリで署名済みRPMを提供し、APIには実習用CAで検証したHTTPSを使用する。内部RPMリポジトリのHTTP転送とAPIのHTTPS認証は区別する。データ層の内部平文接続は現在の実習の限界であり、本番運用への適用時はTLS・シークレット管理・アクセス監査を強化する必要がある。

9. このプロジェクトで示したい能力

この実習の核心はツールの数ではなく、運用の結果を繋ぎ合わせる能力である。インストール段階の識別子をNetBoxとZabbixまで引き継ぎ、再実行と部分的な失敗を考慮し、正常時だけでなく障害後に何が維持され、何が停止するのかを検証する。

構築中に発見したリポジトリパス、APIスキーマ、トークン方式、AWX実行環境、HAProxyヘルスチェックの問題は、再現条件と修正の根拠をあわせて記録する。VirtualBoxのファームウェア・仮想CPU・インストールメモリの問題は、サービス設計とは切り分けて個別のブログ記事としてまとめる。

将来的に本番環境へ拡張する際は、物理ホストとストレージの冗長化、AWX/Gitの可用性、全区間暗号化、外部シークレットストア、バックアップポリシーと定期的な復元テストを優先する。実際の物理サーバーにおけるUEFI PXE・NICドライバ・RAID・BMC連携は、本VMテストとは個別に検証しなければならない。

10. 関連記事と技術的根拠

構築手順と検証結果は、同一ポートフォリオのプロジェクトシリーズとして統合する。各記事の状態と範囲は実際のテスト記録を基準に更新する。

Zabbix Native HA、Zabbixリリースライフサイクル、NetBoxの必須設定とRedis Sentinel、AWX Operatorのインストール、NetBox Ansible inventory plugin、Rocky Linuxサポートライフサイクル。

あわせて読みたい記事および構成資料

ポートフォリオ原文 · オンライン網・閉域網構築ガイド · 障害シナリオ・検証記録 · VirtualBox構成のトラブルシューティング記録

実習設定・自動化ソースZIP · ZIP SHA-256

公開されているZIPには、構成テンプレートと自動化ソースが含まれています。OS・RPM・コンテナイメージおよび資格情報は含まれていません。自身のIPアドレス、公開CA、承認済みのSSHキー、シークレットストアを設定したうえで適用してください。