てくなべ (tekunabe)

ansible / network automation / 学習メモ / 思考メモ

「構成管理」が分からない

構成管理 分からない

はじめに

「構成管理ツール」と聞いたら、どのようなツールを思い浮かべますか？

本ブログでよくとりあげる Ansible も「構成管理」ツールと呼ばれることがあります。最近は自動化ツールのような呼ばれる方（私も）が多い印象ですが（リポジトリ上は IT automation system。

一方、いわゆる CMDB（Configuration Management Database）もCMのところが「構成管理」ですが、Ansible とはまた別のジャンルな気がします。

もちろん、そもそも Ansible は処理が中心のツールで、CMDB は箱物という違いがあります。それにしても、同じ「構成管理」という言葉が指している対象（何を扱うか）が別なような気がしています。

Ansible でも YAML で構成を定義してそれを Playbook の処理に適用できるじゃんという論もあると思うのですが、定義がスキーマレスすぎます。なので、やはりTHE スキーマ、THE 箱物の CMDB とは別物に感じています。

・・・ということで以前から、「構成管理」という言葉がとても難しく感じています。分からないになりに考えてみます。

※本記事記事は明確な基準を指し示すものではなく、思考メモのようなものです。話が広がりすぎないようにネットワークに絞ってます。

言葉を分解して考える

「構成管理」を「構成」と「管理」という2つに分け、それぞれどんなバリエーションがあるかを考えてみます。

構成は「何を」、管理は「どうする」という構図です。

「構成」とは

「何を」に該当する部分として捉えます。

何を？

何を管理するものでしょうか。ざっと以下のようなものが思い浮かびました。

  • 機器のコンフィグファイル（設定、show run 結果）そのもの
    • 「構成」= configuration = いわゆるコンフィグファイル、と解釈する場合
  • 機器自身の設定や仕様に基づく情報
    • 機器のホスト名、物理インターフェース、論理インターフェース、IPアドレス、ラッキング場所など
    • コンフィグそのもの（show run 結果）ではない
  • 機器の状態に基づく情報
    • 設定ではなく状態
    • インターフェースが「実際に」アップしているかダウンしているか、など
  • 管理上必要な情報
    • 機器の資産管理番号、サポート期限や連絡先、など
    • 機器自身の設定には直接関係ない

コンフィグやコンフィギュレーション（configuration）という言葉自体も結構扱いが難しいなと思っています。書籍「ネットワーク自動化とプログラマビリティ」の翻訳者としても苦労されたそうです。

なお、ここで引き合いに出すのが正しいか分かりませんが、RFC 8342 - Network Management Datastore Architecture (NMDA) の用語定義では「configuration」は、以下のように定義されています。いわゆる show running-config や show startup-config などで表示される「コンフィグ」のことでしょうか。

Data that is required to get a device from its initial default state into a desired operational state. This data is modeled in YANG using "config true" nodes. Configuration can originate from different sources.

どのように？

ところで「何を」以外にも「どのように」それを格納しておくのか、という観点もありそうです。大きく分けると以下のようなところでしょうか。

  • 専用のデータベースに格納
    • Web UI から、用意されたフィールドに入力するようなイメージ
    • 例: NetBox
  • YAML などのテキストフォーマット
    • 冒頭で「スキーマレス」と表現していたもの（もちろん自前で JSON Schema を定義してチェックするなどの方法もあるかと思いますが）
    • 例: Ansible の変数定義ファイル

SSoT か？

SSoT（Single Source of Truth: 信頼できる唯一の情報源）として扱うかどうかです。

たとえば、コンフィグを保存するものだとしたとき、実機と構成管理ツールにあるものは「どっちが神様とするか？」みたいな話です。

  • SSoT として扱う
  • SSoT として扱わない

構成管理ツール側を神様としてたのに、実機を臨時で設定変更して反映をし忘れてしばらくドリフトが発生する状態が続いてた、のような状態は避けたいはずです。どういう扱いにしておくのか設計段階で意識しておく必要がある点だと思っています。

「管理」とは

「どうする」に該当する部分として捉えます。管理・・・。これまた守備範囲が広い言葉です。

何をする？

「構成」をどうすることを指すのでしょうか。少なくとも構成を「保管」することは共通といえそうです。

  • とにかく保管する
    • Excel による台帳の代わりなど
  • 差分を確認できるようにしておく
    • いわゆるコンフィグでよくきくニーズですね
  • 設定投入の元ネタとして扱う
    • コンフィグテンプレートに埋め込む変数として使う

誰が？

他にも「誰が扱うか？」という視点もありそうです。ここは2つしか思い浮かびませんでした。

  • 人が
    • Excel による台帳を人が読み書きする
  • システムが
    • システムが読み書きする

もちろん両方の場合も多いと思います。

単方向？双方向？（あまり整理できておらず）

  • 単方向
  • 双方向

例えば、機器から収集した情報をいれるだけであれば単方向。加えて、構成情報をもとにしてコンフィグを生成して投入するような場合もあるなら双方向、という考え方です。

方向というより、他のもの（人やシステムや機器）との関わり方、という感じかもしれません。

「Config Management Camp」という海外イベントから探る

他のアプローチでも考えてみます。

参加したことはないですが、海外には「Configuration Management Camp」というイベントがあります。Google 翻訳したら「構成管理キャンプ」でした。構成管理！

なんかヒントになることはあるかなと思い、過去にどんなセッションがあったのかを見てみます。2025年開催分のスケジュールは以下。

cfgmgmtcamp.org

例えば以下のようなツールの名前が見当たります。

なんとなくわかる気もしました。

少し毛色が違うものだと CUE を扱うワークショップもあるようでした。

あらためて「構成管理ツール」 を考える

たとえば、「構成」が「コンフィグ」であり、「管理」が貯めておいて差分も見たい、ということであれば、RANCID や Oxidized のようなツールが思い浮かびます。

Ansible とはだいぶ毛色が違いますよね。あらためて、それが何を指すのかが結構違うなぁと思いまいました。

「管理したい」は二次ニーズ

ところで、もし「構成管理したい」という声があった場合、この「管理したい」は二次ニーズであることが多いのではないかと思ってます。

本当は管理自体をしたいのではなく、なにか一次の課題があってそれを解決するための手段の一つが、何かを管理したいということなのかなと・・。

様々なケースがあるため、一概には言えないですが。これはまた難しい話です。

まとめ

  • 構成とは何か、どのような保存方法か
  • その情報は神様か
  • 管理とは何をすることか
  • 人が扱うか、システムが扱う、両方が扱うか
  • 単方向か、双方向か

おわりに

上手く整理できた自信はないのですが、今のところ考えていることをまとめてみました。

変な分け方して逆にわかりにくくなってしまったかもしれません。

つまるところ、何のために何をどうすることを指すのか、でしょうか。