この記事は、 「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」 の第58回です。
第6章では、Python・SSH・Ansible・REST APIなどを使った ネットワーク自動化と、運用を効率化するための管理手法を学びます。
Gitによる設定管理｜ネットワーク機器のコンフィグを履歴・差分管理する方法
ネットワーク機器の設定変更では、 「いつ、誰が、どの設定を、なぜ変更したのか」を追跡できることが重要です。 Gitを利用すると、設定ファイルの変更履歴や差分を記録し、 過去の状態と比較しながら安全に変更管理できるようになります。
ネットワーク機器のコンフィグを、 「router01_最新.txt」「router01_最新2.txt」「router01_作業前.txt」 のようなファイル名だけで管理していないでしょうか。
ファイルをコピーするだけでもバックアップはできますが、 変更箇所や変更理由が増えてくると管理が難しくなります。
Gitを使うと、 設定ファイルの変更を履歴として積み重ね、必要なときに差分や過去の状態を確認できます。
この記事を読み終えるとできること
- Gitを設定管理に使う理由を説明できる
- repository・commit・branchの役割を説明できる
- git status・diff・add・commitを使える
- ネットワーク設定の変更差分を確認できる
- 過去の設定ファイルを確認・復元できる
- Gitを使った変更管理の流れを設計できる
Gitによる設定管理とは
Gitによる設定管理とは、 ネットワーク機器の設定ファイルをバージョン管理し、 変更履歴・差分・変更理由・過去の状態を追跡できるようにすることです。
Gitはソフトウェア開発で広く使われるバージョン管理システムですが、 管理対象はプログラムだけではありません。
テキストとして保存できるネットワーク機器のコンフィグや、 AnsibleのPlaybook、インベントリ、Jinja2テンプレート、 YAMLやJSON形式の定義ファイルなどもGitで管理できます。
従来のファイル管理
ファイルが増えるほど、 「どれが正しいのか」「何が変わったのか」が分かりにくくなります。
Gitによる管理
変更を履歴として積み重ねるため、 過去と現在を比較できます。
Gitの価値は「ファイルを保存すること」だけではありません。
「どの変更によって、設定がどのように変わったのか」を 追跡しやすくすることが重要です。
なぜネットワーク設定をGitで管理するのか
1．変更箇所を確認できる
数千行あるコンフィグを2つ並べて、 人の目だけで違いを探すのは大変です。
Gitでは変更前と変更後の差分を表示できるため、 追加・削除された設定を確認しやすくなります。
2．変更履歴を残せる
コミットごとにメッセージを付けることで、 「何のための変更だったのか」を記録できます。
3．過去の設定と比較できる
障害発生時に、 「先週と現在で何が変わったのか」を確認できます。
変更直後に障害が発生した場合は、 Gitの履歴が原因調査の手掛かりになります。
4．レビューしやすくなる
実機へ投入する前に設定変更をGit上で管理すれば、 レビュアーは変更対象だけを確認できます。
5．自動化と組み合わせやすい
Python、Ansible、SSH、REST APIなどで取得した設定を Gitリポジトリへ保存することで、 設定収集と履歴管理を組み合わせられます。
Gitはネットワーク機器そのものをバックアップする仕組みではありません。
設定ファイルを履歴管理する仕組みとして利用し、 実際の機器バックアップ、リポジトリのバックアップ、 復旧手順などは別途設計する必要があります。
Gitで最初に理解する5つの概念
| 用語 | 意味 | ネットワーク設定管理でのイメージ |
|---|---|---|
| Repository | Gitで履歴を管理する場所 | ネットワーク設定管理用フォルダー |
| Working Tree | 現在編集しているファイル | 編集中のrouter01.cfgなど |
| Staging Area | 次のコミットへ含める変更を準備する場所 | 今回記録したい設定変更 |
| Commit | ある時点の状態を履歴として記録する単位 | 「VLAN 200追加」などの変更履歴 |
| Branch | 変更履歴を分岐させる仕組み | 本番とは分けて変更案を作る |
Gitで変更を記録する基本的な流れ
ネットワーク設定管理の全体像
実務では、Gitだけを見るのではなく、 ネットワーク機器から設定を取得して履歴化するまで を一連の流れとして考えます。
ネットワーク設定をGitで管理する例
さらにチームで管理する場合は、 GitHub、GitLab、社内Gitサーバーなどの リモートリポジトリを利用する構成も考えられます。
Gitリポジトリを作成する
ここからは、ネットワーク設定を保存する簡単なリポジトリを作ります。
フォルダーを作成する
Git管理を開始する
これで現在のフォルダーがGitリポジトリになります。
設定ファイルを配置する
ネットワーク機器が増える場合は、 拠点や役割ごとにディレクトリを分ける方法もあります。
Gitの基本コマンドを使う
git status：現在の状態を確認する
変更されたファイルや、 まだGitで追跡していないファイルなどを確認します。
Git操作で迷ったら、まず git status を確認する習慣を付けるとよいでしょう。
git add：コミット対象へ追加する
すべての変更をまとめて追加することもできます。
実務では、内容を確認せずに git add . を実行すると、不要なファイルや機密情報まで含める可能性があります。
git status と git diff を確認してから追加する 習慣を付けましょう。
git commit：履歴へ記録する
コミットメッセージには、 「何を変更したのか」が分かる内容を記載します。
git log：履歴を確認する
例えば、次のような履歴を確認できます。
git show：特定のコミットを見る
コミット時の変更内容を詳しく確認できます。
設定変更の差分を確認する
Gitをネットワーク設定管理で利用するとき、 特に重要なコマンドが git diff です。
変更前の設定
VLAN 200のネットワークを追加
変更後に次を実行します。
イメージとして、次のような差分を確認できます。
作業前レビューでは「完成後のコンフィグ全体」だけでなく、 差分を見ることが重要です。
変更対象以外の行まで意図せず変わっていないかを確認できます。
ステージング後の差分を見る
これにより、 次のコミットへ実際に含まれる変更 を確認できます。
ブランチを使って変更を分離する
ブランチを使うと、 現在の正式な設定管理ラインとは別に、 変更作業用の履歴を作成できます。
変更用ブランチを作成する
このブランチ上で設定を変更します。
レビューが完了したら、正式なブランチへ統合します。
実際の運用では、GitHubやGitLabなどのPull Request / Merge Requestを利用し、 作成者と承認者を分離する 方法もあります。
ブランチを利用した変更管理
過去の設定を確認・復元する
Gitでは過去のコミットを指定して、 その時点のファイル内容を確認できます。
履歴を確認する
過去のファイルを確認する
ファイルそのものを書き換えずに、 過去の内容を確認できます。
過去の内容を作業ツリーへ戻す
その後、差分を確認します。
Git上のファイルを戻しただけでは、 ネットワーク機器の設定は戻りません。
復元した設定を実機へ反映するには、 別途、変更手順・影響確認・承認・投入・試験が必要です。
公開済みの変更を取り消す場合
チームで共有している履歴では、 既存履歴を書き換えるのではなく、 変更を打ち消す新しいコミットを作る運用もあります。
Gitの操作とネットワーク機器の切り戻しは分けて考え、 実機作業では必ず切り戻し手順を準備します。
自動取得したコンフィグをGitで管理する
Gitによる設定管理は、 第54回で学んだSSHによる情報取得や、 第55回のAnsibleと組み合わせるとさらに効果的です。
-
ネットワーク機器へ接続する
SSHやREST APIなどで機器へアクセスします。 -
現在の設定を取得する
running configurationなどを取得します。 -
機器ごとのファイルへ保存する
router01.cfg、switch01.cfgなどの名前で保存します。 -
Gitで差分を確認する
前回取得時から設定が変化しているか確認します。 -
変更がある場合のみ履歴化する
変更内容を確認し、必要に応じてコミットします。
設定バックアップ自動化の考え方
自動取得した設定には、 時刻やセッション情報など、 取得するたびに変化する情報が含まれる場合があります。
そのまま保存すると毎回不要な差分が発生するため、 履歴管理する対象を整理することも重要です。
Gitで管理してはいけない情報
ネットワーク設定をGitへ保存するときに、 最も注意したいのが機密情報です。
次の情報を不用意にGitへ保存しないでください。
- 平文パスワード
- APIトークン
- 秘密鍵
- VPNのPre-Shared Key
- SNMP Communityなどの認証情報
- クラウドサービスのアクセスキー
- 機器管理用の秘密情報
.gitignoreを利用する
Gitで管理したくないファイルは、
.gitignore
に指定できます。
ただし、すでにGitで追跡を開始したファイルは、 後から.gitignoreへ記載しただけでは履歴から消えません。
「Gitへコミットしてから消す」のではなく、 最初から秘密情報を分離する設計 が重要です。
実務で決めておきたいGit運用ルール
Gitを導入するだけで、 設定管理が自動的に安全になるわけではありません。
チーム内で「どのように使うのか」を決める必要があります。
| 項目 | ルール例 |
|---|---|
| 管理対象 | 本番ネットワーク機器の設定ファイルを対象とする |
| ファイル名 | hostname.cfgで統一する |
| ディレクトリ | 拠点・用途・環境ごとに整理する |
| コミット単位 | 1つの目的につき1コミットを基本とする |
| コミットメッセージ | 変更内容・作業番号・目的を記載する |
| レビュー | 本番反映前に別担当者が差分を確認する |
| 機密情報 | 認証情報はリポジトリへ保存しない |
| 正式版 | mainブランチには承認済み設定のみを保存する |
コミットメッセージの例
数か月後に履歴を読んだ人でも、 変更目的を理解できる書き方を意識します。
Git設定管理でよくある失敗
パスワードや秘密鍵をコミットすると、 ファイルを後から削除しても履歴に残っている可能性があります。
意図していない設定変更まで履歴へ含める可能性があります。
VLAN変更、NTP変更、ACL変更などを一度にまとめると、 後から変更理由を追跡しにくくなります。
Gitに保存されている設定と、 実際にネットワーク機器で動いている設定が一致しているとは限りません。
自動収集などを利用して実機設定を取得し、 管理している設定との差分を検出できる仕組みを作ると、 設定ドリフトの発見につながります。
顧客・上司へGit導入を説明する方法
Gitの導入を説明するときに、 「Gitは便利なツールです」だけでは十分ではありません。
ネットワーク運用上の課題と結び付けて説明します。
技術者向けの説明
「設定ファイルをGit管理することで、 作業前後のdiffを確認でき、過去のコミットとの比較や 変更履歴の追跡が可能になります。」
管理者・顧客向けの説明
「設定変更の履歴と差分を記録することで、 障害発生時に直前の変更を確認しやすくし、 変更作業のレビューや原因調査を効率化します。」
技術 → 運用上のメリットへ翻訳する
Gitを説明するときは、 commitやbranchという機能そのものより、 「変更追跡」「レビュー」「原因調査」「復旧判断」に どう役立つかを伝えると理解されやすくなります。
Git・設定管理で使われる英語表現
| 英語 | 意味 | 実務でのイメージ |
|---|---|---|
| Version Control | バージョン管理 | ファイルの変更履歴を管理する |
| Repository | リポジトリ | Gitで管理するファイルと履歴 |
| Commit | 変更を履歴へ記録する | VLAN追加などを記録 |
| Diff | 差分 | 変更前後の違い |
| Branch | 履歴の分岐 | 変更作業を別ラインで管理 |
| Merge | 統合 | 変更ブランチを正式版へ取り込む |
| Restore | 復元 | 過去のファイル内容を戻す |
| Revert | 変更を打ち消す | 過去の変更を取り消す新しい履歴を作る |
| Configuration Drift | 設定ドリフト | 管理上の設定と実機設定がずれること |
英語のコミットメッセージ例
コミットメッセージでは、 Add / Update / Change / Remove / Fix などの動詞から始めると、 何を行ったのかを簡潔に表現できます。
理解度チェック
記事の内容を確認するため、次の5問に答えてください。
問題1．Gitをネットワーク設定管理に利用する主な目的として、 最も適切なものはどれですか。
- ネットワーク機器のCPU使用率を監視する
- 設定ファイルの変更履歴や差分を管理する
- ルーティングプロトコルを自動選択する
- LANケーブルの障害を検出する
解答を見る
Gitでは設定ファイルの変更履歴や差分を管理できます。
問題2．現在変更されているファイルの状態を確認するコマンドはどれですか。
- git status
- git delete
- git start
- git network
解答を見る
問題3．変更前後の差分を確認する基本コマンドはどれですか。
- git log
- git diff
- git branch
- git init
解答を見る
問題4．次のうちGitリポジトリへ不用意に保存すべきでないものを2つ挙げてください。
解答例を見る
APIトークン、秘密鍵、平文パスワード、 VPNのPre-Shared Keyなどが該当します。
問題5．Git上で過去の設定へ戻せば、 ネットワーク機器の実機設定も自動的に戻りますか。
解答を見る
Gitで復元されるのは管理しているファイルです。 実機へ反映するには、別途コンフィグ投入などの作業が必要です。
実践演習：ネットワーク設定をGitで履歴管理する
Router01の設定変更を想定して、 Gitによる変更管理を行ってみましょう。
演習1．初期設定をGitへ登録する
次のファイルを作成します。
内容は次のとおりです。
次のコマンドで初期状態を登録してください。
解答例を見る
演習2．OSPF設定を追加する
次の1行をrouter01.cfgへ追加してください。
追加後、コミットする前に どのコマンドを使って差分を確認すべきでしょうか。
解答を見る
演習3．変更をコミットする
差分が正しいことを確認したあと、 変更を履歴へ登録してください。
解答例を見る
演習4．変更履歴を確認する
これまでのコミットを1行ずつ表示してください。
解答を見る
演習5．運用ルールを考える
あなたが10人のネットワークチームでGitを導入するとします。 次の内容を決めてください。
- どのファイルをGitで管理するか
- 誰がmainブランチへ反映できるか
- レビューを必須にするか
- コミットメッセージの形式
- 秘密情報をどのように分離するか
- 実機設定とGitの差分をいつ確認するか
自分の言葉で説明する課題
上司から、 「コンフィグは共有フォルダーへバックアップしているのに、 なぜGitまで必要なのですか？」 と聞かれました。
技術用語を使いすぎず、1分程度で説明してください。
説明例を見る
共有フォルダーへの保存でもバックアップはできますが、 Gitを利用すると、変更前後の差分や変更履歴を確認しやすくなります。 そのため、設定変更のレビューや、 障害発生時に「直前に何が変わったのか」を調べる作業を効率化できます。 バックアップを置き換えるというより、 設定変更を追跡しやすくするために利用します。
まとめ
- Gitを使うとネットワーク設定ファイルの変更履歴を管理できる
- git statusで現在の状態を確認できる
- git diffで変更前後の差分を確認できる
- git addで変更をステージングし、git commitで履歴へ記録する
- git logやgit showを使うと過去の変更を確認できる
- branchを使うと本番用の履歴と変更作業を分離できる
- Git上でファイルを戻しても実機設定が自動的に戻るわけではない
- パスワード、秘密鍵、トークンなどの機密情報はGitへ不用意に保存しない
- SSH・Python・Ansible・APIと組み合わせることで、 コンフィグ取得から履歴管理まで自動化できる
Gitは「設定ファイルを保存する場所」ではなく、 ネットワーク変更の履歴と差分を追跡するための仕組みとして使うことが重要です。
第6章では、Python・SSH・Ansible・REST API・Git・テレメトリーなどを使い、 ネットワーク運用を自動化・効率化するための技術を学びます。
コメント