イミュータブルデプロイメント

ここまで、構成管理と オーケストレーションのツールについて 説明しましたが、 構成管理の領域には 新たな変化が生まれています。 プロビジョニングに関する興味深い動きは、 パブリックとプライベートの クラウドコンピューティングから、 Amazon の CloudFormation や、 Azure リソースマネージャーなど、 ベースシステムの宣言的モデルで システムを生成するモデル駆動型の 自動化が登場したことです。 すると今度は、システム、OS の構成、 アプリケーションに別々のモデルを 使わなければいけないのはなぜか という当然の疑問が起こってきます。 どう考えても非効率的です。 そこでジェームズと私は、 ある会社向けに統一モデルツールを 開発しました。 システムとアプリケーションの インスタンス作成と管理が 共通のモデルでできるため、 非常に効果的です。 コンテナの発達も変化を加速しました。 コンテナベースのアーキテクチャでは、 サーバー管理の必要性がなくなります。 アプリケーションは必要最小限の OS や依存関係を含むコンテナに パッケージングされ、 ベアボーンの物理インフラに送られます。 大規模クラウドを使う ネットフリックスなどの企業でも、 効率化のため再びイメージが 活用されています。 アーティファクト管理を 自動化できれば、 JAR ファイルを WAR ファイルに、 さらに DEB ファイルに パッケージ化して配布できます。 イメージも一種のアーティファクトです。 ネットフリックスは ビルドアーティファクト全体を イメージ化して、 デプロイ時の設定を最小化しています。 なぜなら、1,000 箇所のノードに 同一のアップグレード作業を実行すれば、 １つや２つは失敗して、 デプロイの進行が遅れ、 過熱によるシステムダウンに つながりかねないからです。 この方法は イミュータブルインフラストラクチャ、 アプリの場合は イミュータブルデリバリーと 呼ばれています。 コンテナ自体が OS の依存関係や アプリのコードを含めて アーティファクト化されているなら、 構成管理による変更を 行う必要はありません。 デプロイ後はイミュータブル、 不変であり、更新が必要になれば システム全体を一新します。 保存データには使いにくい方法ですが、 NoSQL…