プロローグ

エルバのチームである私たちの製品の魔法的で神秘的な詳細の詳細を世界と共有したいときが来ました。 特別な誇りと簡単な礼拝の対象である最も複雑なプロジェクトの1つから始めることにしました。 ちょっとした謎に覆われ、暗黒の魔法の光輪に包まれています。 彼に関する伝説は口から口へと受け継がれています。 知識のごく一部のみがwikiまたはyutrekに文書化されており、大部分はバージョン管理システムのソースコードに隠されています。 この秘密のコードをプロジェクトでますます解読できる賢明な長老たち。 詳細な原稿にすべての魔法の呪文を書き留める時が来ました。 それはElbeの展開システム、つまり強力なDeployについてです。



Elbaは起業家向けのWebサービスであり、ビジネスの運営を支援します。 そして、強力なデプロイの仕事はエルベを更新することです。 サービスの新しいバージョンの準備ができたら、 Deployはそれを世界に公開する必要があります。 ユーザーに。 つまり、システムのすべての部分を更新して起動し、すべてのデータを変換して準備する必要があります。 私たちのDeployはその仕事をうまくやっています-Elbaの更新は、ユーザーの作業を中断することなく、ユーザーにはまったく見えません。 これにより、必要に応じて-準備ができていれば、新しいリリースをアップロードできます。 これをどのように達成したか、Webサービスがユーザーに対してノンストップで透過的に更新される方法については、後で説明します。

第1章 起源

古代、エルバはASP.Net Web Forms上の小さなWebアプリケーションとMS SQL Server上のデータベースで構成されていました。 このアプリケーションにより、起業家は小さなウィザードの助けを借りて、税務署に簡素化された税制申告を準備し提出することができました。 それ以来、多くの時代が変わりました-現在、エルバはあなたにもっと多くのことをすることができます。 彼女が何ができるか、そして彼女がどのように起業家を助けるか、私たちのマーケティングとプロモーションサイトの魅力的な読書は教えてくれます。



技術面にもっと興味があります。 エルバが小さかったとき、配達プロセスは単純で素朴でした。 アプリケーションは、バランサーの後ろに隠された2つのホスト上のデータセンターにありました。 両方のアプリケーションを更新するために、プログラマーはRDPの手で本番サーバーに行き、プリコンパイルされたコードを両方のホストのフォルダーにコピーしました。 優れたIISはすぐに変更を取得し、システムを再起動しました。 データベースのデータを更新するには、SQLサーバーでスクリプトを手動で実行する必要がありました。



時間が経つにつれて、コードベースは成長し、強度を獲得しました。 多くの前線が現れ、サービスはそれぞれのホストに別々に住んでいて、ロボットが人に取って代わり、いつか世界を引き継ぎたいと思っていました。サードパーティの製品やサービスとの統合が追加され、多くの異なる興味深いことがありました。 まず、リリース用にバッチファイルのパックが作成されたため、コピーする際の手作業が簡略化されました。 Batnikovは、すべてのホストで新しいディストリビューションをレイアウトして実行しました。 しかし、すぐにコードが非常に多くなり、すべてのホストにコピーする時間が増加しました。 Batnikovの管理は難しくなりました。サービスとトポロジーの最新リストを維持してください。 さらに、ユーザー数の増加に伴い、新しいリリースの前に更新する必要があるデータの量も増加しました。 自動化の時が来ました。



それらの古代は非常に過酷でした。 完成したツールを誰も知らず、グーグルの使い方を知らず、他人のツールを使用しませんでした。 プログラマーはコードを書くのが大好きです。 私たちは自分で書くことにしました。 そして彼らは書いた。



Deployの最初のバージョンはaのように振る舞いました。 男性はコンソールを立ち上げ、最初に製品全体をリリース形式で収集しました。 これには、サービス/ロボット/フロントのコードと統計のコンパイル、およびデプロイ自体が含まれます。 次に、サイトのトポロジ、アドレス、外観、パスワード、フラグ、トグルスイッチ、マジック定数など、これらすべての製品設定を準備しました。 準備されたディストリビューションは、特別に訓練されたリモートサービスのデータセンターに転送されました。リモートサービスは、転送の終了後に同じマジックデプロイを起動する方法のみを知っていました。



前面の最初のものは、外の世界の「技術作業中」のスタブに見えました。 彼女のカバーの下で、 デプロイは彼が到達できるすべてのものを殺していました。 サイト全体を消滅させました。 ロボット、サービス、戦線、すべての作業プロセスを殺し、親も子もspaしみ、焦土を残しました。 エルバは機能しなくなりました。 そして、これらの廃 onの上で、 Deployは新しい、より良い世界を構築し始めました。 指定されたトポロジに従って分布をゆっくりと分散させ、設定を変更し、スクリプトを実行してデータベース内のデータを更新します。 それから彼はゆっくりと農場全体を始めました。 最も動きの遅いサービスの開始後、スタブは削除され、うれしそうなユーザーが最終的に更新されたシステムにアクセスできるようになりました。



明らかに、すべてのユーザーが常に満足しているわけではありません。 最良の場合、ダウンタイムは深夜に約10〜20分かかりました。そして、すべてがうまくいったときです。 星がうまくいかなかった場合、 デプロイは仕事を終えることなく、最も不適切な場所で予期せずに死亡し、チームはプラットフォームがゴミ箱に壊れたままになりました。 どこかで、何かが機能し、どこかで機能しませんでしたが、意図したとおりに機能しませんでした。 そして、次の眠れない夜の数時間で、私は緊急にすべてを整頓しなければなりませんでした。 技術サポートが困難なため、ユーザーの怒りが抑えられ、最もイライラした人は安心でき、電話ホットラインで直接バレリアンとはんだ付けされました。



当時、エルベでの開発の進化は、より多く、より頻繁に、より良くリリースしたい段階に達しました。 彼らは、リリースのキューを構築したり、ユーザーや技術サポートに負担をかけたりすることをもはや望みませんでした。



Deployの新しい要件が形成されました ：

• エルベの最小ダウンタイム、理想的には-その不在;
• 透過的なデータ更新。
• リリースが失敗した場合でも、システムは引き続き動作するはずです。
• 人的要因を排除するための完全自動化または最小限の手動アクション。
• さらなる改善と開発のためのシンプルなコード。

要件をすぐに理解することで、メインアプリケーションでサポートがなければ、ベンチャーは失敗に終わります。 スタンドアロンの展開システムを作成することはできません。 システム自体、最も基本的なコードでは、リリーススクリプトをサポートし、インフラストラクチャを追加し、コード、データ、およびトポロジの要件を確立する必要があります。



Elbaの新しいバージョンを展開する作業のほとんどは、作業中のバージョンと並行して実行できます。 デプロイメントは、特定のサービスが存在するホストとポートを示す、コンパイルされたディストリビューションとトポロジを入り口で受け取ります。その後、必要なすべてのサービスを分散して起動します。 適切なタイミングで、スイッチを引いてプラットフォーム全体を切り替えるだけです。



海岸では、すべてが人間の制御を超えた魔法のように聞こえた。



プログラマーが袖をまくり上げ、先人たちの欠点や弱さから解放され、魔法の力を備えた新しい「より良い」 Deployを世界に見せなければならない瞬間が訪れました。



偉大なgusev_pとあなたの謙虚な召使の助けを借りて、彼はどれくらいの時間、簡潔に、塵と灰から生まれました-強力な止められないデプラ 。

第2章 環境

展開プロセスと純粋に技術的な詳細を説明する前に、何を扱っていたかを伝える価値があります。

-Elba-Webサービス、Windowsスタックの製品、コードはC＃で記述されています。

-メインアプリケーション（フロント）-IIS用のASP.Net Webサイト。 部分的にWebフォーム、部分的にMVC。

-多数のhttpインターフェイスを備えたスタンドアロンサービスを継続的に調達しました。 サービスは、バランスとフォールトトレランスのために複製されます。

-スケジュールに従ってスケジューラによって起動された多数のロボット。

-主記憶-MS SQL Serverデータベース。

-非正規化データおよび集計用のMongoDB。

-全文検索のためのElasticSearch。

-メッセージング用のRabbitMQ。



SQLデータベースは追加専用として使用されます。 アプリケーションコードはUPDATEとDELETEを使用せず、エンティティの変更と削除は、変更されたフィールドまたは削除のサインを含む新しいリビジョンの追加によって行われます。 リビジョン番号は、1種類のエンティティを通過する増分カウンターです。 リポジトリのアプリケーションコード内でORMを使用すると、特定の各エンティティの最後の削除されていないリビジョンのみが選択されます。 このようなスキームの結果として、すべてのデータのバージョニングと変更の履歴が取得されます。これにより、以下に説明する+86の魔法が得られます。

第3章 魔法の学校

Deployの作業を説明します。 まず、リリースを展開するプロセス全体を約40のステップに分けました。 各ステップは、大きな作業の小さな部分を実行し、それに対してのみ責任を負います。 次のステップは、前のステップが正常に完了した後にのみ開始されます。 ほとんどの手順は、動作中のエルベと並行して実行できます。 失敗した場合、可能であれば、ステップはシステムを元の状態に戻します。



前と同様に、特別に訓練された小さなリモートサービスがElbaの新しいディストリビューションを受け取り、 Deployを起動します。 時間を無駄にすることなく、彼は最初の一歩を踏み出します。



最初の手順はそれほど興味深いものではありません。 現在の構成が確認され、ファイルシステムが準備され、新しいサービスコードが対応するホストの新しいフォルダーにコピーされ、スケジューラでタスクが準備されます。 同様のタスクがすべてのホストで並列化されます。



Next Deployはデータの移行に対処する必要があります。 この瞬間、彼は魔法の領域に入ります。

新しいリリースでは、プログラマーは良い仕事をし、多くの新しいコードを書き、新しいエンティティを作成し、既存のものをリファクタリングしました。 それらのいくつかでは、デフォルトが変更され、新しいプロパティが表示されるか、古いプロパティが削除されています。 現在では、古いエンティティの代わりに、いくつかの新しいエンティティのセットを使用、相互接続、またはその逆にすることができます。 1対1の関係がある場合、多対多の関係が表示される場合があります。 問題は、新しいコードが古いデータを処理する方法を知らないことです。 新しいコードを開始する前に、既存のデータを準備-移行する必要があります。 新しいリリースを準備するとき、プログラマは、リポジトリ内のデータ構造を変更し、現在のエンティティを変更および変換する適切なスクリプトとユーティリティを作成します。



しかし、古いコードは新しいデータを扱う方法も知りません。 また、通常、データの移行が簡単な場合、逆方向の移行は不可能ではないにしても困難です。 新しいコードがエンティティを新しい方法で書き込む場合、それらを古いものに変換することはできません。 データの移行をロールバックする価値はありません。 したがって、時間と空間が交差しない場合にのみ、古いコードで古いデータを処理し、新しいコードで新しいデータを処理します。



そのため、 Deployの最初の仮定が生まれました。つまり、データの移行が動作中のコードを壊してはなりません。 新しい列とテーブルを作成できますが、現在のデータを変更することはできません。 それらを変換する必要がある場合は、新しい列とテーブルを作成し、そこに結果を配置する必要があります。 幸いなことに、アプリケーションコードのORMはストレージから適切に抽象化され、そのような変更に気付かないようにしています。

呪文＃1

非常に多くの場合、移行は長く、常に時間で決まるプロセスではありません。 数百万行のテーブルとギガバイトのデータをダウンロードする必要がある場合があります。 しかし、ユーザーは待ちたくないので、単純なサービスは悪いです。 そして、Deployは最初の魔法-ボールトのバージョン管理された構造-を使用しました。 すべての移行は2つの段階に分けられました。



最初の段階-時間の制限はほとんどありません-データスキームを更新し、エンティティのメインボリュームの移行を行います。 列とテーブルを追加し、すべてのエンティティタイプの現在の最新リビジョンを記憶します。 データ変換用のスクリプトとユーティリティを実行した後、新しいコードを操作するためのエンティティを準備します。 主なことは、最初の段階は既存のコードの作業を妨げず、変更されたデータは古いコードからは見えない新しいフィールドに表示されることです。



2番目のステージDeployは、バージョンを切り替える前に個別のステップを実行します。 その上で、最初の段階の後に出現したエンティティの新しい改訂の支配が行われます。 これを行うには、同じスクリプトと変換ユーティリティがすべて実行されますが、以前に記憶されたリビジョンがすでに使用されています。 これにより、累積された変更のみが処理されます。

最初の移行後、 Deployはすべてのロボットを停止します。リリースの期間中、ロボットの作業は犠牲になります。 次にサービス。 ただし、システムが機能するにはサービスが必要であり、すべてを停止することはできません。 各リリースでトポロジと設定を変更したくありませんでした。 ほとんどの場合、新しいリリースのトポロジは、すでに展開され動作しているElbaのトポロジと一致します。 ほとんどのリリースでは、トポロジはめったに変更されず、必要に応じて少しの手動操作で簡単に変更できるため、この要件は干渉しません。


そのため、 Deployの2番目の仮定が登場しました。同じホスト上で、古いコードの代わりに新しいコードでサービスを実行します。 簡単にするために、展開時に作業サービスのレプリカの半分を停止し、代わりに新しいサービスを起動することにしました。 古いサービスが機能している間、更新されたバージョンはすでに近くにコピーされていました。 現在のサービスはDeployによって停止され、新しいサービスが起動されます。 同時に、一時的に削減されたレプリカ数でシステム全体が動作し続けます。

スペル＃2

システムの基本的なネットワークインフラストラクチャを変更する必要がありました。 各サービスは特定の設定セットで実行されます。このリリースでは、リリースバージョンが表示され、新しい展開のたびに増加します。 サービス設定でバージョンを正しく指定し、ログ-デプロイのタスクを維持します。 フロントを含むすべてのサービスは、同じバージョン内でのみ通信できます。 あるサービスが別の古いまたは新しい別のサービスにリクエストを行うと、リクエストを処理する代わりに、特定の応答が返されます。 次に、このサービスはブラックリストに登録され、リクエストは別のレプリカに送られます。

霧が濃くなっています。 デプロイはダークマジック自体の領域に近づきました。 前線を更新する番でした。 明らかな理由で、それらで主な困難が生じました。 第一に、新しいアプリケーションの開始が長いためです。 IISが何をするのかは明確ではありませんが、すべてのアセンブリをメモリに上げたり、キャッシュしたり、メタベースを更新したりします。 秒のまともな量を食べる。 第二に、実行中のアプリケーションのユーザーからのhttpリクエストのため。 それでも、それらを切り捨て、スタブ、エラー、またはタイムアウトを返したくありません。 現在のすべての要求と新しい要求をすべて処理する必要があります。



Deployは、古いホストが実行されているすべてのホスト上のIISで新しいフロントを展開します。 しかし、別のポートで。 加熱されていないアプリケーションは起動時に停止するため、ウォームアップする方法を学びました。 これを行うには、開始時にユーザーが最も人気のあるページにアクセスしてシミュレートします。これにより、IISは必要なすべてのキャッシュアクションを実行できます。 新しい補助フロントがウォームアップするのを辛抱強く待ちます。 その結果、古いアプリケーションは引き続き各フロントで機能し、着信ユーザーリクエストを常に処理します。新しいアプリケーションは既に起動されており、まだ待機しています。



リリースの切り替えはすぐに始まります。 新しいコードのデータ準備を完了し、すべてのエンティティの既存のリビジョンを変換する必要があります。 このプロセスを妨げるものはありません。 これ以上最新のエントリは表示されません。 この仮定を修正するために、すべての着信ユーザー要求に対して「ブロック」を確立することが決定されました。 これは非常に強力な呪文であり、多くの異なる効果で構成されています。



すべてのフロントおよび作業サービスは、リリースの切り替えの開始に関するDeployからのシグナルを受信します。これは、作業の顕著な変化につながります。 信号を受信した瞬間から、同じ「ブロック」がアプリケーションコード内に設定されます。 フロントの新しいhttpリクエストはすべて一時停止し、削除されるのを待ちます。 「ブロック」は、データベースへの新しいレコードの追加を禁止して、最終的な移行の自由を提供します。 「ブロック」をインストールする前にアプリケーションに到達した現在の要求が記録を試みている場合、インフラストラクチャコードの最も深いところから例外がスローされ、クエリは先頭で繰り返され、すべての新しいブロックと同じ「ブロック」に対して停止します。



Deployは、データ移行の2番目の最終段階を実行します。 それ以来、利用可能なすべてのデータは、新しいコードで処理する準備ができています。 移行が完了すると、「ブロック」を削除するための信号がフロントに送信されます。 「古い」アプリケーションへの入り口で神経質になっているすべてのリクエストは、すでにウォームアップされた「補助」新しいものにプロキシされ、その応答はクライアントにプロキシされます。 したがって、ユーザーの要求は新しい「補助」アプリケーションの新しいコードによってすでに処理されており、古いアプリケーションはプロキシ処理のみを処理します。 古いコードは新しいデータでは機能しません。 また、単一のユーザーリクエストも失われていません。



「ブロック」のインストールから削除までのプロセス全体は、文字通り数秒かかります。 アイデア全体が、新しいアプリケーションでリクエストの処理を開始できる唯一の瞬間を決定するのに役立ち、この瞬間までに、既存のデータはすべて完全に既に移行されています。 いつでも、新しいエントリは古いコードまたは新しいコードからデータベースに落ちますが、同時にはなりません。 これにより、データに応じたコードの非互換性が排除され、リリースの切り替えが簡素化および高速化されます。

呪文＃3

クエリの「ブロック」を削除する手順は、最終的な展開手順と見なされます。 世界は変わりました。 新しいコードが機能し、過去に戻ることは不可能です。 これより前のステップは、結果なしでロールバックできます。 前面が切り替わる前に例外的な状況が発生した場合、Deployは、現在の手順から最初の手順へと逆の順序でステップをロールバックし、システム全体を使用可能な状態に戻します。 新しいサービスはオフになり、古いサービスはオンになり、停止したロボットが起動されます。

Deployの作業はまだ完了していません。 2つのアプリケーションとプロキシを使用することはあまり便利ではありません。 Deployは、IISのデフォルトアプリケーションを、新しいアプリケーション（「補助」が起動されるまさにそのアプリケーション）のあるフォルダーに切り替えます。 このプロセスにもIIS時間（通常は数秒）がかかります。 この間ずっと、要求は古いアプリケーションで受信され、「補助」アプリケーションにプロキシされます。 一方、新しい「動作中の」アプリケーションが起動し、起動後はいつものように、「ウォームアップ」する時間を与える必要があります。 したがって、新しいアプリケーションは着信HTTP要求を処理せず、加熱時間全体にわたって「補助」要求へのプロキシを処理します。

呪文＃4

ある時点で、3つのElbaアプリケーションが同じIISの同じホストで実行されています。 古いものは、IISを切り替える前に着信要求を受け入れ、それを「補助的な」新しいものにプロキシしました。 第三に、また新しい、切り替えの直後に発売された、 2番目の「補助」と完全に同一です。 3番目のプロキシは、ウォームアップ中に2番目にプロキシを要求します。 最後の「ウォームアップ」の後、アプリケーションはプロキシを停止し、それ自体でリクエストの処理を開始します。 残りのアプリケーションは、それらへのリクエストのフローがなくなると消滅します。 最後に、残っているものは1つだけです。

最後の手順では、 Deployは古いサービスの半分動作しているレプリカを停止し、代わりに新しいサービスを起動し、スケジューラで新しいロボットをオンにし、新しいフロントがウォームアップするのを待って、リリースの成功に関するログを書き込む必要があります。 デプロイ完了！

エピローグ

この記事では、主なアイデアと、 Elbaが短時間でノンストップの迅速な更新を実行できるようにする特定のトリックについて説明します。

MongおよびElasticでデータを移行し、レコードの正しいロールバックを確保し、悪名高い「ブロック」を同期し、IISと戦って、 デプロイの UIを作成し、他の多くの小さな技術的問題を解決する方法は、舞台裏のままです。 詳細に興味がある場合は、コメントでお答えします。



時々、Elbaは「スタブ」の下で更新されますが、これは通常、ハードウェアの移動、OS、インフラストラクチャサービスのアップグレード、およびほとんど決して新しい機能のリリースに関連しています。

新しいDeployの開発の結果、私たちはほぼ望んでいたものを手に入れました-ユーザーに完全に透過的な新しいリリースのノンストップデプロイメントです。 クライアントは、古いアプリケーションのページに移動して更新し、新しいアプリケーションに表示できます。 展開プロセス全体の所要時間は10分未満であり、要求に対する応答の最大遅延時間は3〜4秒です。 さらに、 Deployコード全体が私たちのものです。 引き続き改良と改善を行い、新しい機能を導入し、機能を開発しています。