Erlang（そして定義上Elixir）の機能の1つは、ホットコードスワップができることです。しかし、これはDockerで奇妙に思えます。ここでは、インスタンスを停止し、新しいコードを保持する新しいイメージで新しいインスタンスを再起動する必要があります。これは本質的に誰もがしているようです。Erlang/Elixir on Dockerとホットコードスワップ
これは、1つの隠れノードを使用してネットワーク経由で他のすべてのノードに更新を配信することも可能であることも知っています。もちろん、それは問題を尋ねるような音ですが、...
私の質問は以下の通りです：Erlang/ElixirのためのDockerベースのインフラストラクチャホットコードスワップ？もしそうなら、do、don'ts、caveatsは何ですか？
物語
（つまりはアーランがために作成されたものです）、携帯電話やモバイルデータアクセスを処理するためのシステムを想像してみてください。通話中、またはデータアクセスセッション中にユーザーセッションを維持するゲートウェイサーバーがあります（私はそれをセッションと呼びます）。それらのサーバは、セッションがアクティブである（ユーザが接続されている）限り、セッションのメモリ内表現を有する。
ここでは、通話またはデータの転送にどれだけ料金を請求するかを計算する別のシステムがあります（PDF-Policy Decision Function）。両方のシステムは、ゲートウェイサーバーがPDFへの一握りのTCP接続を作成し、それらのTCP接続が切断されるとユーザーセッションを切断するように接続されます。ゲートウェイは、一度に数十万の顧客を扱うことができます。ユーザが課金する必要があるイベント（次回のデータ転送、コールの1分）が発生するたびに、ゲートウェイはPDFに事実を通知し、PDFはユーザアカウントから特定の金額を差し引きます。ユーザーアカウントが空の場合、PDFはゲートウェイに通話を切断するように通知します（お金が足りなくなったため、トップレベルにする必要があります）。
ご質問
最後のは、この文脈では、あなたの質問について話しましょう。 PDFノードをアップグレードし、そのノードがDocker上で動作するようにします。新しいバージョンのソフトウェアで新しいDockerインスタンスを作成しますが、古いバージョンをシャットダウンすることはできません（通話中に数十万の顧客がいるため、切断することはできません）。しかし、私たちは何とか古いPDFから新しいバージョンに顧客を移す必要があります。そこで、ゲートウェイノードに、古いPDFではなく更新されたノードとの新しい接続を作成するように指示します。お客様はおしゃべりになるかもしれませんし、その中には長時間実行されるデータ接続（Windows 10 isoのダウンロード）があり、操作全体が完了するまで2〜3日かかります。それは、重要なバグの場合にソフトウェアのあるバージョンを別のバージョンにアップグレードするのにどれくらいの時間がかかります。また、このような数十台のサーバーがあり、それぞれが何百もの顧客を処理します。
代わりにErlangリリースハンドラを使用した場合はどうなりますか？新しいバージョンのソフトウェアでrelupファイルを作成します。私たちはそれを適切にテストし、PDFノードにデプロイします。各ノードはインプレースでアップグレードされます。アプリケーションの内部状態は変換され、ノードはソフトウェアの新しいバージョンを実行しています。しかし、最も重要なのは、ゲートウェイサーバーとのTCP接続が切断されていないことです。顧客が喜んで電話を続けるか、システムをアップグレードする間に最新のWindows isoをダウンロードしています。すべては2〜3日ではなく10秒で実行されます。
答え
これは、特定の要件を持つ特定のシステムの一例です。 DockerおよびErlang's Release Handlingは直交技術です。あなたがいずれかまたは両方を使用することができ、それはすべて、以下に要約：
実際にはDockerを使用して最初にノードを展開し、Erlang release handler（最初にDockerを使用する必要がある場合）でアップグレードすることが考えられます。また、アップグレード中にシステムを使用する必要がない場合（PDFシステムの例のように）、Dockerを使用して常に新しいバージョンを配備し、リリース処理については忘れてしまうかもしれません。また、リリースハンドラを使用して、オンザフライで迅速かつ信頼性の高いアップデートが必要な場合はDockerを忘れてしまい、Dockerが最初のデプロイメントでのみ使用されます。私はそれが助けて欲しい
丁寧な回答ですが、この件に関する文献はほとんどなく、これは私にとって重要な参考文献の1つです。 Dockerは遍在しているようで、ほとんどのCIツールとクラウドプロバイダーがそれを提供しているようですが、私は今日Dockerを使用することはほとんどのアプリケーションでは不可能だと言います。しかし、ホットコードスワップ機能は非常に便利で、私は誰もがそれを試して、これを活用して計画外の緊急時の変更を行う手順を実行することをお勧めします。 – Aki
ありがとう@アキ別々の資料ごとにたくさんの文献があります。彼らは実際に一緒に議論する必要はないので、両方について議論する文献はほとんどない。 ErlangアプリケーションがDockerまたは他の技術と一緒に配備されていても、HCSを使用できます。 – Amiramix
私のコメントにもかかわらず、これはまだ実際には答えられていないと思います。私は、Docker内でHCSを使用するさまざまな実装戦略について、より多くのことが書けると考えています。私の推測では、DockerはDockerまたはErlangを介して新しいコンテナがプッシュされるかどうかは関係ありません。しかし、物事を同期させてください！ – Aki
DockerはErlangにとって特に適していません。これは今日知っている若い店の多くを展開する唯一の方法です。 Erlangがすでに完全に解決している問題は、Docker（軽量並列処理、実行環境衛生、 "ネットワークは抽象化"、プロセス分離、メモリー安全性など）で解決しようとする問題のようなものです。ホットコードをアップグレードするには、動作中のデータタイプと実行時のストレージ/コードロード環境の高度な制御と知識が必要です。 Dockerは、通常の場合の2番目の要件を防ぎます。 – zxq9
@ zxq9：これは、Docker以外でPhoenix/Elixirアプリケーションを実行するのにもっと自信を持ってくれますが、HCSはCircleCIまたはTravisCIを使用するDevOps環境で実際に意味がありますか？基本的に、Erlang HCSはDockerおよびCIツールと直交していませんか？これは、HCS機能の再評価を必要としています。PaaSは、HCSがうまく動作するように、ノードが相互にやりとりすることを許さないことがよくあります。 これはまったく新しい投稿であるはずです：ErlangのWebアプリケーションはDockerとCIのためにHCSを犠牲にするべきですか？ – Aki