はじめに
自動化自動化、と言いますが、見方次第では、ITインフラの作業を効率化する、一種の業務システムだと捉えています。
そのため、自動化システムのことを考えるときは、一般的（とは・・？ですが）なシステム設計、開発での考え方を参照して当てはめることがあります。
システムにおけるデータベースと、ネットワーク機器のコンフィグを重ねて考えたことがあったので、簡単ですがまとめます。
コンフィグをデータストアと考える
ネットワーク機器は、コンフィグ（Configuration）と呼ばれる設定情報を持っています。そのコンフィグを手動なり、自動化なりで変更して、設定を変更します。
ある時、コンフィグを持つ領域って、ある意味データストアかも、と考えました。
データベースに対して SQL で insert、update、delete する操作が、ネットワーク機器に CLI や API で設定変更する操作と重なりました。
どう当てはめて考えるか
コンフィグはデータストアかも、という考えが、一番リンクしたのは、書籍「単体テストの考え方/使い方」を読んだときです。
「第10章 データベースに対するテスト」内の「10.3 テスト・データのライフ・サイクル」に、統合テストにける不要なデータの後始末の考え方が書かれています。
後始末の方法が4つ書かれていて、4つめの「テスト・ケースの実行前にデータの後始末を行う」がもっとも優れている、としています（P350）。もしテスト・ケース実行後に後始末だと、テスト・ケースを中断した場合に後始末がされず、それが別のテスト・ケースに影響を与えてしまうから、などが「実行 前 に 後 始末」がいいとする理由です。
非常に既視感があります。以前、ネットワーク機器への設定変更の Ansible の Playbook のテストを組んだとき、最初は実行後にコンフィグを後始末していました。が、やはりテストに失敗するとその残骸の影響で次のテストを意図通り実行できないことがありました。なので、「実行 前 に 後 始末」に変更しました。
こんな経験を通じて、ネットワーク機器のコンフィグの領域はデータストアとして扱うと、設計のヒントになるのではと考えるようになりました。
テストの実行前に、後始末 って日本語的にはおかしいかもだけど、前段のテストがこけてデータストアが中途半端な状態になってることもあることを考慮数すると、やっぱ前にcleanupしたほうが良いのかなと思う。
— よこち (@akira6592) 2024年11月13日
「データストア」を「使い捨てでないネットワーク機器のコンフィグ」 に読み替えても同じ。 https://t.co/ZS43xll5nG
そもそも仮想のネットワーク機器をテストのたびに作り直せて、それが素早くできればベストですが。
そういえば
RFC 8342 や、RFC 8345 には「configuration datastore」という言葉がでてきます。
なので、そんな突飛な話でもないかなと思いました。
おわりに
最初の話にもどりますが、「自動化」はITインフラの作業を効率化するの業務システム、と捉えるとまだ色々とヒントが得られるのではないかと考えています。
