Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

138

8

章 サーバーのアップデート

/

変更のパターン

変更する必要がないということだ。

しかし、これらの管理されていない領域は、構成ドリフトを引き起こす可能性を残している。誰か

が、サーバーの未管理部分の構成 / 設定に変更が必要なことに気付いたとき、彼らは新しい構成定義を

書くという大仕事を省略し、手作業で変更を加えたいと思ってしまうだろう。すると、その変更は、必

要な場所にはかならず適用されるような形では管理されなくなる。このような変更は、アプリケーショ

ンが動くサーバーと動かないサーバーがあるが誰もその理由を覚えていないというスノーフレークサー

バーも生み出してしまう。

8.3.4.1

　

未管理領域の発生が避けられないのはなぜか

この問題の当然とも言える解決方法は、システムのすべての構成 / 設定を構成定義ファイルで管理

するようにすることである。しかし、現在の世代の構成管理ツールでは、これは単純に現実的ではな

い。ふたつの大きな問題がある。ひとつは、サーバーには現在のツールで現実的に管理できる範囲を

越える非常に多くの構成 /設定があること、もうひとつは、現在のツールでは、システムに望まれない

構成/設定が追加されることを阻止できないことだ。

まず、どれだけのものを管理しなければならないのかを考えよう。すぐあとのコラム「Linuxサー

バーにはどれだけのものがあるか」で説明しているように、スリム化したLinuxサーバーイメージを

使っていても、膨大な数のファイルが残る。これらすべてを明示的に管理するような ...