環境のデプロイメントを探る
サーバーがクラッシュしたために、深夜の緊急サポートの呼び出しを受けたことがあるとします。
その場合、新しいマシンを設定する手動の手順にアクセスするために、複数のスプレッドシートやメモリを検索する作業の苦労を知っています。
その後、開発環境と運用環境の一貫性を維持する難しさもあります。
マシンを初期化するときに人的エラーが発生する可能性を取り除く簡単な方法は、コードとしてのインフラストラクチャを使用することです。
手動デプロイとコードとしてのインフラストラクチャ
コードとしての手動デプロイとインフラストラクチャの違いを理解するための一般的な例として、ペットの所有と牛の所有の違いがあります。
あなたがペットを持っているとき、あなたはそれぞれに名前を付け、それらを個人と見なします。あなたのペットの1つに恐ろしいことが起こった場合、あなたは多くのことを気にする傾向があります。
牛の群れがある場合、個別に名前を付けることもあるでしょうが、それを全体としての群れとして考えます。
インフラストラクチャの観点から見ると、1 台のマシンがクラッシュし、それを置き換える必要がある場合 (ペット) は、手動デプロイ アプローチに重大な影響を与える可能性があります。
コード アプローチとしてインフラストラクチャを採用すると、1 台のマシンがダウンした場合にインフラストラクチャ全体 (牛) に悪影響を与えることなく、別のマシンをより簡単にプロビジョニングできます。
コードとしてのインフラストラクチャの実装
コードとしてのインフラストラクチャでは、環境 (または環境) をテキスト ファイル (スクリプトまたは定義) にキャプチャします。
ファイルには、ネットワーク、サーバー、およびその他のコンピューティング リソースが含まれる場合があります。
スクリプトまたは定義ファイルをバージョン管理にチェックインし、既存の環境を更新したり、新しい環境を作成したりするためのソースとして使用できます。
たとえば、環境にリモート処理して新しいサーバーを手動でプロビジョニングするのではなく、テキスト ファイルを編集してリリース パイプラインを実行することで、新しいサーバーを追加できます。
次の表に、手動デプロイとコードとしてのインフラストラクチャの大きな違いを示します。
| 手動デプロイ | インフラストラクチャ・アズ・コード |
|---|---|
| Snowflake サーバー。 | 環境間の一貫性のあるサーバー。 |
| デプロイ手順は環境によって異なります。 | 環境は簡単に作成またはスケーリングできます。 |
| より多くの検証手順とより複雑な手動プロセス。 | 環境更新プログラムの完全に自動化された作成。 |
| 違いを考慮してドキュメントを増やしました。 | 不変インフラストラクチャへの移行。 |
| 週末にデプロイして、エラーから回復する時間を可能にします。 | 青/緑のデプロイを使用します。 |
| 痛みや長い週末を最小限に抑えるためにリリース周期を遅くします。 | サーバーはペットではなく牛として扱います。 |
コードとしてのインフラストラクチャの利点
コードとしてのインフラストラクチャの利点を次に示します。
- デプロイされた内容、タイミング、および方法を追跡しやすくすることで、監査を促進します。 (つまり、追跡可能性が向上します)。
- リリースからリリースまでの一貫した環境を提供します。
- 開発環境、テスト環境、運用環境全体の一貫性が向上します。
- スケールアップとスケールアウトのプロセスを自動化します。
- 構成をバージョン管理できるようにします。
- インフラストラクチャの変更の管理に役立つコード レビューと単体テスト機能を提供します。
- 変更できない サービス プロセス 使用します。つまり、環境に変更が必要な場合、新しいサービスがデプロイされ、古いサービスが停止された場合、更新されません。
- 青/緑 デプロイを許可します。 このリリース手法により、2 つの同じ環境 (1 つはライブ環境、もう 1 つは稼働していない環境) が存在するダウンタイムが最小限に抑えられます。 更新プログラムは、稼働していないサーバーに適用されます。 テストが検証されて完了すると、異なるライブ サーバーとスワップされます。 それは新しいライブ環境になり、以前のライブ環境はもはやライブではありません。
- インフラストラクチャは、必要に応じてプロビジョニング、プロビジョニング解除、再プロビジョニングできる柔軟なリソースとして扱います。