環境のデプロイについて調べる
サーバーがクラッシュしたために、真夜間に緊急サポートの電話を受けたことがあるのではないでしょうか。
もしそうなら、新しいマシンを手作業で設定する手順を入手するため、多数のスプレッドシートや、自分の記憶さえもくまなく探す苦労を知っています。
そのようなときは、開発環境と運用環境の整合性を維持する困難もあります。
マシンを初期化するときの人的エラーの可能性を取り除くさらに簡単な方法は、コードとしてのインフラストラクチャを使用することです。
手動デプロイとコードとしてのインフラストラクチャ
手動でのデプロイとコードとしてのインフラストラクチャの違いを理解するための例えとしてよく持ち出されるのは、ペットを所有することと家畜を所有することの違いです。
ペットの場合は、それぞれに名前を付け、個別のものと見なします。ペットの 1 匹に何か恐ろしいことが起こった場合は、とても心配します。
家畜の群れの場合は、名前は付けるかもしれませんが、群れとして考えます。
インフラストラクチャの観点では、単一マシンがクラッシュしてそれを交換する必要がある場合 (ペット)、手動デプロイ アプローチでは重大な影響が発生する可能性があります。
コードとしてのインフラストラクチャでは、1 台のマシンがダウンした場合でも、インフラストラクチャ全体 (家畜) に悪影響を与えることなく、別のマシンを簡単にプロビジョニングできます。
コードとしてのインフラストラクチャの実装
コードとしてのインフラストラクチャでは、環境 (1 つまたは複数) をテキスト ファイル (スクリプトまたは定義) にキャプチャします。
ファイルには、何らかのネットワーク、サーバー、その他のコンピューティング リソースが含まれる場合があります。
スクリプトまたは定義ファイルをバージョン コントロールにチェックインし、既存の環境の更新や新しい環境の作成のソースとしてそれを使用できます。
たとえば、環境にリモート接続して新しいサーバーを手動でプロビジョニングするのではなく、テキスト ファイルを編集してリリース パイプラインを実行することで、新しいサーバーを追加できます。
次の表は、手動デプロイとコードとしてのインフラストラクチャの大きな違いを示したものです。
| 手動による展開 | コードとしてのインフラストラクチャ |
|---|---|
| それぞれ個別のサーバー。 | 環境間で一貫性のあるサーバー。 |
| デプロイ手順が環境によって異なる。 | 環境を簡単に作成またはスケーリングできる。 |
| より多くの検証手順と、より詳細な手動プロセス。 | 環境の更新プログラムの完全に自動化された作成。 |
| 違いを考慮するため、ドキュメントの増加。 | 変更できないインフラストラクチャへの移行。 |
| エラーからの復旧できるように週末のデプロイ。 | ブルーグリーン デプロイを使用する。 |
| 苦労や週末作業を最小限に抑えるため、リリースのペースが遅い。 | ペットではなく家畜としてサーバーを扱う。 |
コードとしてのインフラストラクチャの利点
コードとしてのインフラストラクチャの利点を次に示します。
- デプロイされたもの、時期、方法を追跡しやすくすることで、監査を促進します。 (つまり、追跡可能性が向上します。)
- リリースからリリースまで一貫した環境を提供します。
- 開発、テスト、運用の環境間での整合性の向上。
- スケールアップとスケールアウトのプロセスが自動化されます。
- 構成をバージョン コントロールできます。
- インフラストラクチャの変更を管理するためのコード レビューと単体テストの機能が提供されます。
- "不変" サービス プロセスを使用します。つまり、環境に対して変更が必要な場合は、新しいサービスがデプロイされ、古いサービスは破棄されて更新されません。
- "ブルーグリーン" デプロイが可能です。 このリリース手法は、ライブとそうでないものの 2 つの同一環境が存在する場合のダウンタイムを最小限に抑えます。 更新プログラムは、ライブではないサーバーに適用されます。 テストが検証されて完了すると、異なるライブ サーバーとスワップされます。 それが新しいライブ環境になり、前のライブ環境はライブではなくなります。
- インフラストラクチャは、必要に応じていつでもプロビジョニング、プロビジョニング解除、再プロビジョニングできる柔軟なリソースとして扱われます。