不変サーバーとは何ですか？

不変のサーバーについては、次のような質問があります。

• 事後分析を行う能力を失うことなく、不変のサーバーパターンを実装する方法は？
• 構成管理ツールは、不変のインフラストラクチャでどのような役割を果たしますか？

サーバー（私が得た部分）に関係していることは明らかです。そして不変の文法を消化するだけで、「ミュートすることは不可能」と関係があると思います。その推測が近い場合、私は正確にミュートすることができないものの手掛かりを持っていないだろう（と私はそれがサウンドカードまたは何かに関係しているとは思わない...）。

私の質問：

• （DevOpsのコンテキストで）実際に「不変サーバー」とは何ですか？
• なぜ使用されるのですか？

不変性とは、コンピューターサイエンスの分野でよく使用される用語であり、一般に「作成後に変更することはできません」という意味です。通常、並列性、同時実行性、およびスレッドセーフティに関して使用されます。

そのトピックの議論は魅力的ですが、一般的にStack Overflowの他の場所で見つけることができます。ここに飛び込む衝動に抵抗しています。重要な概念は「作成後に変更することはできません」です。

Amazonで、WebサービスをMachine Image（AMI-繰り返し再プロビジョニングできるビルド済みのインスタンス）にベイクして展開する場合を想像してください。起動時にレジストリから取得する資格情報を介してバックエンドデータベースに接続します。Splunkなどのログツールにログをダンプします。通常の日常的な操作では、このボックスにsshする理由はありません。そのサービスをスケールアップする必要がある場合は、そのAMIのインスタンスをさらに作成し、ロードバランサーを調整するだけです。スピンダウンすると、単にインスタンスとロードバランサーが破壊されます。

日常の操作では、このボックスに変更する理由はありません。AMIからさらに起動できます。

OSレベルのセキュリティパッチを提供する必要がある場合はどうなりますか？パッチをインストールして新しいAMIをベイクして実行中のすべてのインスタンスを再デプロイするか、既存のイメージにsshしてパッチを更新しますか？ただsshする人がたくさんいます。「不変のアーキテクチャ」の支持者は、そのようなことを可能にすることを提案することでさえ私に怒鳴りました。

不変主義者（そのような言葉がある場合）は、新しいamiを焼くことを主張します。彼らは、これまでマシンにsshする理由をすべて取り除くことを提唱しています。彼らは、リポジトリから設定の詳細を引き出すことにより、そのマシンの起動時に特定のマシン設定を行うべきだと主張しています。これは「ペットではなく牛」の究極の表現です。

不変のアーキテクチャは、マシンイメージの作成の後に変更する理由がないマシン構成に関するものです。何かを変更する必要がある場合は、新しいインスタンスイメージをベイクし、古いものをシャットダウンして、新しいものを表示します。

クラウドテクノロジーはハードウェアとソフトウェアの境界を変えたため、以前はハードウェアの世界の独占的市民であった多くの技術的運用もソフトウェアの領域の対象となりました。共有コンピューティング環境では、コンピュータなどの古いようであるかもしれない自分自身¹が、クラウド技術は、彼らと対話するための便利でお馴染みのメタファーを提供することによって、それらを普及可能性：クラウドのユーザーは予約インスタンス、完全なコンピュータや模倣を古い共有コンピューティング環境は、すべての可能なセットを持っているのに対し、扱いにくい制限と「プログラムをFTPサーバーにアップロードする必要があり、環境X（通常、使用するソフトウェアの10年前のバージョンを使用）で最大60分間実行する」は、以前のユーザーまたは実際のユーザーに馴染みがあるコンピューティングセンターの。

この移行の実際的な結果は、展開手順をソフトウェアアーティファクトで表すことができるようになったことです。（展開手順は、データベース、Webサーバー、またはこのインフラストラクチャに属するものを使用してインフラストラクチャをセットアップする方法と、それらが実行されるネットワークを合わせた指示です。）これらの新しいレンズに合わせて、サーバーの手動メンテナンスはほとんど似ています実動コードの手動パッチ-これはごくまれに望ましいことです。手動メンテナンスでは、実稼働で実際に実行されているシステムとこれらのシステムを説明するコードの間に矛盾が生じる可能性があります。つまり、再現性のない動作や不可能なバグ分析、二重バグ修正、その他の災害を意味します。

不変のサーバーパターンは、我々はプログラムを実行しているの手動メンテナンスを避ける必要がありますそれによれば、上記のマントラのクラウド運用のためだけの転置です。不変のサーバーパターンでは、サーバーを手動で構成する代わりに、この構成を自動化することをお勧めします。

実装フレーバー

不変サーバーパターンの一般的な考え方は非常に明確ですが、実装の微妙な違いがたくさんあります。たとえば、一部のアプローチでは、サーバーをまったく更新せず、代わりに体系的にサーバーを置き換えることを提案しています。これは、更新により、展開が複数の異なる時間に開始され、複数の異なる更新プロセスを経たサーバーで構成される状況が生じ、サーバーの不均一なセットが暗示され、サーバーがジョブを処理する方法に微妙な違いが生じる可能性があるためです。2番目の一般的なバリエーションポイントは、サーバーへのリモートアクセスに関する規律です。手動メンテナンスが発生しないことを保証するために、サーバーへの完全なリモート管理アクセスを無効にしたい人もいます。

履歴メモ

私の知る限り、「不変サーバー」という用語はKief Morrisによって一般化されましたが、そのアイデア自体ははるかに古いものです。1999年に、FreeBSD刑務所は、使い捨てコンピューティング環境の構成を完全に自動化するというアイデアをすでに広めました。この手法を説明するこの名前を聞く何年も前に、これが「不変サーバー」パターンの実装を開始した方法です。

CD-ROMに基づく物理的な不変性を装う不変性は、信頼できるコンピューティングシステムを製造するための一般的な手段でもあります。これは不変のサーバーパターンと間違われることはありません。

不変サーバーとは、変更や修正ができないサーバーです（理想的には更新とセキュリティパッチ以外）。サーバー上のソフトウェアを変更する代わりに、目的のソフトウェアで新しいサーバーをスプールし、古いサーバーを終了します。

この概念は、テスト、開発、およびQAサーバーがすべて同一であることを保証するのに役立ちます。これは、この質問の範囲外の複数の理由で重要です。不変サーバーのもう1つの利点は、古いサーバーにアプリケーションをロールバックできることです。たとえば、本番サーバー1でKを変更する必要があるため、サーバー2をスプールしてKを変更します。10分後に、Kがすぐに修正するのではなく、アプリケーションで何かを壊したことに気付きました。顧客のダウンタイムを引き起こす可能性があるため、トラフィックをサーバー1にリダイレクトし、2の何が問題なのかを見つけます。

最高の説明は、（いつものように）Martin FowlerのImmutable Serversに関するblikiの記事にあります。

サーバーは、ハードウェアであろうとクラウド内の仮想サーバーであろうと、通常、オペレーティングシステムとアプリケーションが実行されています。

多くの場合、アプリケーションとオペレーティングシステムのコンポーネントは、構成が必要であり、変更を適用する必要があります。たとえば、セキュリティパッチ、アプリケーションの新しいバージョンの展開、構成の変更。

あなたはどんな変化があることを考えると、突然変異サーバーの状態には、この用語は、immutableより多くの意味を作るために開始します。それは何を意味突然変異は、このようなAサーバー上で許可されていません。

多くの場合、サーバーの状態の変更に関与しているのは、バージョンの展開、構成の変更、またはセキュリティパスなどです。その結果、サーバーは期待どおりに機能しなくなります。たとえば、構成の誤りなどにより、アプリケーションが実行されない場合があります。

これが、不変サーバーを作成するためのプラクティスが確立されている理由です。で不変のサーバ、画像サーバはにバンドルされたすべての設定、パッチ、アプリケーションのバージョンで作成されます。サーバ、そのイメージは様々な環境でのサーバーを作成するために使用することができます。

このようなイメージが使用される最初の環境は、イメージが機能するかどうかをテストできる環境です。異常が検出された場合にのみ、そのようなイメージを実稼働環境に昇格させて、そこでサーバーを新しいバージョン（正常に機能することがわかっている）に置き換えることができます。

画像の作成と画像のプロモートのプロセスが自動化されると、非常に失敗に耐えるプロセスが得られます。このプロセスには、人的労力がほとんどかからず、サービスに失敗する可能性が非常に低くなります。

不変サーバーには、たとえばsshサーバーがないなど、「入力」する方法が含まれていません。この場合、サーバーのすべての計測（メトリック、ログ）がメトリックデータベースやログ集約サービスなどの外部のシステムに出荷されることもよくあります。

コンテナー（参照：Docker）には、イメージを作成し、それらを実行中のコンテナーにスポーンするプロセスもあります。これらは、更新された画像に基づいて新しいコンテナに置き換えられることが非常に多く、変更されることはありません。変更を導入して「何かを修正」するためにコンテナに人が入らないことを意味します。

逆から始めましょう、可変サーバーとは何ですか？

従来、変更可能なサーバーインフラストラクチャは、継続的に変更および更新されます。シェルを保護し、パッケージをアップグレードし、構成し、サービスをインストールし、新しいコードを展開できます。これは、それを変更可能にするものであり、変更または変更できます。

不変のインフラストラクチャは、展開後にサーバーが変更されることのないもう1つのインフラストラクチャパラダイムです。何らかの方法で何かを更新、修正、または修正する必要がある場合、適切な変更を加えた共通イメージから構築された新しいサーバーがプロビジョニングされ、古いサーバーが置き換えられます。検証後、それらは使用され、古いものは廃止されます。

なぜ使用されるのですか？ 不変のインフラストラクチャの利点は、インフラストラクチャの一貫性と信頼性の向上、およびよりシンプルで予測可能な展開プロセスです。また、サーバーのクラッシュなどによるダウンタイムなど、可変インフラストラクチャの一般的なサーバーの問題を軽減します。

ただし、包括的な展開の自動化と高速サーバープロビジョニングを介して効率的にプロビジョニングする方法を知る必要があります。

あなたがビットコインをマイニングしていると想像してください。サーバーがクラッシュした場合、ダウンタイムは必要ありません。できるだけ早くバックアップする必要があるため、不変のインフラストラクチャがソリューションとなるはずです。