
130
8
章 サーバーのアップデート
/
変更のパターン
●
自動化プロセスは、チームメンバーがシステムに変更を加えるための方法のなかでもっとも簡単
でもっとも自然に感じられる。
●
変更は、関連するすべての既存サーバーにロールアウトされる。
●
同種でなければならないサーバーが不統一を起こすことは許されない。
●
変更は無人プロセスで適用される。
●
変更のために必要な労力は、変更の影響を受けるサーバーの数がいくつでも同じである。
●
変更のエラーは、すぐに可視化される。
こ の 章 で は 、「 4.3 サーバー変更管理のモデル」で紹介した主要なサーバー変更管理モデルを掘り下
げ、それらを実現するためのパターンとプラクティスを説明する。
8.1
サーバー変更管理モデル
サーバーの構成/設定変更の4 つのモデルは、随時変更、構成/設定の同期、イミュータブルサー
バー、コンテナ化サーバーである。
8.1.1
随時変更
伝統的なアプローチは、特定の変更がどうしても必要でない限り、サーバーをそのまま放置すると
いうものである。変更が必要になると、誰かが手作業でファイルを編集するか、1度限りのスクリプト
を書いて変更を行う。Chef、Puppet、Ansibleなどの構成管理ツールを使っているチームの多くは、
今でも特定の変更を加えるときに限りそれを実行している。
本書全体を通じて述べているように、この方法ではサーバーの構成 /設定の統一性は失われ、包括
的な形で確実にオートメーションを実行するのは難しくなる。多くのサーバーで自動化プロセス ...