【ITニュース解説】Cisco Config Backups with Ansible: ios_config vs ios_command

システムエンジニアとしてネットワーク機器の運用に関わる際、Ciscoルーターやスイッチなどの設定情報（コンフィグ）のバックアップは非常に重要な業務の一つだ。もし機器が故障した場合、最新の設定情報があれば迅速に復旧でき、サービス停止時間を最小限に抑えられる。しかし、このバックアップ作業を手動で行っていると、ファイルが古くなったり、更新が途絶えたりといった問題が起こりがちだ。このような課題を解決するために、Ansibleという自動化ツールが非常に役立つ。

Ansibleは、ネットワーク機器やサーバーの設定を自動化するためのツールで、複雑な手順を「プレイブック」という設定ファイルに記述することで、手作業なしに繰り返し実行できる。Cisco機器のコンフィグバックアップをAnsibleで自動化する際には、主に二つの異なるアプローチがある。これらのアプローチは、単にバックアップを取るだけでなく、その後のファイルの管理方法や、どれくらいのノイズ（設定変更とは関係のない情報）を許容するかによって、どちらを選ぶべきかが変わってくる。

選択のポイントは大きく三つの質問で決まる。一つ目は、バックアップしたファイルをその後にどう利用するか、という点だ。単にタイムスタンプ付きのコピーとしてアーカイブするだけなのか、それともGitのようなバージョン管理システムに保存して、設定の変更履歴を追跡し、意図しない変更（ドリフト）を検知したいのかで、求められるファイルの形式が変わる。二つ目は、取得したコンフィグの生出力にどれくらいのノイズが含まれるかだ。Cisco機器のコンフィグには、設定そのものとは関係なく、機器の状態によって自動的に変化する情報（例えば、現在のコンフィグのバイト数、最終更新日時、ntp clock-periodなど）が含まれることがある。これらがバックアップファイルに含まれていると、設定が全く変わっていなくても、Git上では「変更があった」と表示され、本当に重要な変更を見落とす原因になる。三つ目は、Ansibleのプレイブックを誰が保守するかだ。一つのモジュール（Ansibleの機能単位）を呼び出すだけのシンプルなプレイブックなら、誰にでも引き継ぎやすいが、複雑なテキスト処理を含む場合は、専門的な知識とテストが必要になり、特定の担当者が継続的に管理する必要がある。

どちらのアプローチも、Ansibleのcisco.iosコレクションという、Cisco機器を操作するための専用の機能群を利用する。このコレクションをインストールし、接続するCisco機器の情報をgroup_vars/cisco_switches.ymlというファイルで定義しておく。ここで、ansible_connectionでネットワーク接続方式を、ansible_network_osでOSの種類を、ansible_userやansible_passwordで認証情報を指定する。機密性の高い認証情報は、Ansible Vaultという機能を使って暗号化し、安全に管理することが強く推奨される。また、機器で特権モード（enableモード）に移行するために、ansible_become: trueとansible_become_method: enableを設定することも一般的だ。

最初のアプローチは、「ios_configモジュールのbackup: trueオプションを利用する方法」である。 この方法は非常にシンプルだ。cisco.ios.ios_configモジュールには、backup: trueというパラメータがあり、これを設定するだけで、対象のCisco機器から実行中の設定（running-config）を取得し、Ansibleを実行しているコントローラー（制御ホスト）に保存してくれる。このモジュールは、linesやsrcといった設定変更を行うためのパラメータが指定されていない限り、機器の設定には何も変更を加えない。 この方法のメリットは、まずコードが最小限で済むことだ。数行の記述でバックアップが完了し、プレイブックを読めば何をしているかが一目瞭然であるため、保守が非常に容易だ。backup_optionsを指定しなければ、デフォルトでプレイブックと同じディレクトリにタイムスタンプ付きのファイルとして保存されるため、簡単なアーカイブ用途には追加の作業なしで対応できる。また、誤った正規表現やテンプレート処理のミスによってバックアップファイルが破損するリスクも低い。 一方でデメリットもある。取得される設定ファイルは、モジュールから返されるそのままの形式であるため、先述したようなノイズ（例えば、変動するヘッダー行やntp clock-periodなど）が含まれる可能性がある。これにより、Gitで差分（diff）を確認する際に、設定が実質的に変更されていなくても「変更あり」と表示されてしまう場合がある。また、この方法で取得できるのは基本的に実行中の設定のみであり、起動時の設定（startup-config）やVLANデータベースなど、他の種類の情報をバックアップするには別のタスクが必要になる。さらに、バックアップファイルにはハッシュ化されたパスワードやSNMPコミュニティ文字列などの機密情報が含まれる可能性があるため、保存先のディレクトリのアクセス権限を厳しく制限し、リポジトリ自体も機密情報として扱う必要がある。

二つ目のアプローチは、「ios_commandモジュールでコマンドを実行し、その結果を自分でファイル処理する方法」である。 この方法では、cisco.ios.ios_commandモジュールを使って、Cisco機器に直接show running-configといったコマンドを実行させる。コマンドの実行結果はAnsibleの変数に保存されるので、その結果をAnsibleのansible.builtin.copyモジュールなどを使って、自分でコントローラーのディスクに書き出す。このアプローチの最大の利点は、ディスクに書き出す前に、取得したテキストの内容を自由に加工できる点にある。例えば、Pythonの正規表現というテキストパターン認識の機能を使って、ノイズとなる行（例: Building configuration、Current configuration、最終更新日時、ntp clock-periodなど）を削除し、本当に設定変更があった部分だけが残るように正規化できる。これにより、Gitの履歴がよりクリーンになり、意図しない変更がすぐわかるようになる。また、バックアップファイルを保存するディレクトリが存在しない場合、ansible.builtin.fileモジュールを使って先にディレクトリを作成するタスクを追加する必要がある。 この方法のメリットは、出力内容、ファイルモード（権限）、ファイル名、そして実行するコマンドを完全に制御できることだ。show startup-configやshow versionなど、他の情報も取得したい場合は、commandsリストにコマンドを追加し、対応する結果を処理するタスクを追加するだけでよい。正規化されたクリーンな出力は、Gitの履歴を非常に有用にし、ドリフト検知のアラートも精度が高まる。また、このパターンはCisco以外のさまざまなベンダーの機器にも応用しやすい。 しかし、デメリットも存在する。正規表現の記述と保守は、全て自分で行う必要がある。Cisco IOSやIOS XEのバージョンやプラットフォームによって、ノイズとなるヘッダー行のフォーマットが異なる場合があるため、実際の機器の出力で十分にテストし、信頼できるものを作成しなければならない。また、ansible.builtin.copyモジュールを使用する際には、delegate_to: localhostという設定を必ず行う必要がある。これを忘れると、copyモジュールがネットワーク経由でCisco機器に対して実行されてしまい、意図しない動作やエラーを引き起こす可能性がある。さらに、正規化を過度に行うと、本当に重要な設定変更まで削除してしまい、問題を見逃すリスクもあるため、正規化パターンは慎重に、かつ狭い範囲で適用することが重要だ。OSのアップグレードなどで出力フォーマットが変わると、正規化パターンが機能しなくなる可能性もあるので、定期的な見直しも欠かせない。

結局のところ、どちらのアプローチを選ぶかは、現在の状況と要件によって変わる。単純にバックアップファイルをアーカイブしておけば良いという小規模な環境であれば、シンプルで保守しやすいios_configモジュールを使う方法（アプローチA）が最適である。しかし、Gitで詳細な変更履歴を追跡し、ドリフトを検知したい場合や、起動時の設定など、実行中の設定以外の情報もバックアップしたい場合、あるいは厳密なファイル権限や命名規則が必要な場合は、ios_commandモジュールと独自のファイル処理を組み合わせる方法（アプローチB）がより適している。チームのスキルレベルも考慮し、保守が容易な方を選ぶのが賢明だ。

どのような設計を選ぶにしても、いくつかの重要な事前確認事項がある。バックアップファイルの保存先ディレクトリがAnsibleのプレイブックリポジトリの外にあるか、または暗号化されているか。ファイル権限は0600（所有者のみ読み書き可）になっているか。異なるプラットフォームの機器でサンプルを二回実行し、設定変更がない場合に差分がないことを確認したか。変動するヘッダー行が適切に除去されているか。認証情報はAnsible Vaultなどの安全な方法で管理されているか。そして、バックアップジョブが定期的にスケジュールされ、失敗時に通知される仕組みがあるか、などを確認する必要がある。

結論として、まずは「ios_configモジュールを利用するシンプルな方法」（アプローチA）から始めることを強く推奨する。この方法は、コードが少なく、ドキュメント化された標準的な振る舞いであり、何よりも「バックアップが全く取られていない」という根本的な問題を迅速に解決できる。この方法で定期的なバックアップをスケジュールし、アクセス制御された場所に保存し、実際に復元できることを確認することが最初のステップだ。 その後、Gitでノイズの多い差分が表示される、実行中の設定以外の情報も取得したい、あるいはモジュールだけでは対応できない特定のファイル処理ルールがあるなど、具体的な問題が発生した場合にのみ、「ios_commandモジュールと独自のファイル処理を組み合わせる方法」（アプローチB）への移行を検討すべきである。柔軟性があるからといって最初からアプローチBを選ぶのは避けるべきだ。なぜなら、独自の正規表現は全て保守コストとなり、OSのアップグレードなどで正規化パターンが機能しなくなるリスクがあるからだ。 両方のアプローチを組み合わせたハイブリッドな運用も有効である。例えば、アプローチAで毎日完全なバックアップアーカイブを取り、それとは別にアプローチBで正規化されたファイルをGitリポジトリにコミットするという方法だ。こうすることで、もし正規化処理が誤って何かを隠してしまったとしても、オリジナルのバックアップファイルがディスク上に残るため、安心感がある。 いずれの方法を選ぶにしても、利用するcisco.iosコレクションのバージョンによって、モジュールやパラメータのデフォルト動作やオプションの振る舞いが変わる可能性があるため、常に公式ドキュメントで最新の情報を確認することが重要である。