Erlangクラスターサービス：アイデアからDebパッケージへ

挑戦する

クラスターで動作するerlangで実際のサービスを作成する必要があります。 さらに、サービスを提供する人の生活を簡素化する必要があります。

要件：

• サービスにはRESTfulインターフェイスがあります（ファッショナブルでモダンです）
• サービスのメイン設定は、明確な構文を持つ小さなファイルに移動する必要があります
• サービスはオプションのアクセスログを書き込む必要があります
• サービスはupstartから起動する必要があります

簡単にするために、サービスはカウンターになります。これにより、各クライアントはリクエストごとに増加する整数になります（カウンターが再起動されるまで一意です）。

テクノロジー

最もファッショナブルでモダンなものを選択してください：

• HTTPサーバー- カウボーイ0.10.0
• ロガー- ラガー
• ビルドシステム-erlang.mk
• リリースコレクター-relx

建築

カウボーイはポートにハングアップし、ハンドラーでリクエストを処理します。ハンドラーはカウンターを呼び出し、クライアントに応答してログエントリを書き込みます。

カウンターはグローバルに登録されるため、クラスターの任意のノードから簡単にアクセスできます。

起動時に、カウンタは、終了しない場合（カウンタが別のノードにすでに登録されている場合）、登録を試行します。これを行う機会を待ちます。

アプリケーションのスケルトン

すべての標準に従ってOTPアプリケーションを作成する必要がありますが、最小限の労力で行います。

プロジェクトのerdicoディレクトリを作成し、その中にgit initを作成し、同じ名前のプロジェクトのリポジトリからerlang.mkファイルをダウンロードし、単純なMakefileを作成します。

PROJECT = erdico ERLC_OPTS= "+{parse_transform, lager_transform}" DEPS = cowboy lager dep_cowboy = pkg://cowboy 0.10.0 dep_lager = https://github.com/basho/lager.git 2.0.3 include erlang.mk
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Mac OS / BSDユーザー ：wgetが必要です。 Linuxでは、どこでもすぐに使えるようになりました。

カウボーイは有名なパッケージとして含まれていることに注意してください。 erlang.mkリポジトリは小さいですが、そうです。



src / erdico.app.srcファイルで、アプリケーションを記述します（すべてのパラメーターが必要です。そうしないと、erlang.mkまたはrelxが破損します）。

 {application, erdico, [ {description, "Hello, Upstart distributed Erlang service"}, {id, "ErDiCo"}, {vsn, "0.1"}, {applications, [kernel, stdlib, lager, cowboy]}, % run-time dependencies {modules, []}, % here erlang.mk inserts all application modules, not added automatically, required by relx {mod, {erdico, []}}, % application callback module {registered, [erdico]} % required by relx ]}.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

src / erdico.erlファイルを作成しますが、現時点では-module（erdico）ディレクティブを除きます。 そこには何も書かないでください。

この状態では、makeは依存関係を収縮させ、検出したすべてを収集する必要があります。

アプリケーションの起動、カウボーイおよび最も単純なリクエストハンドラ（ launcher 、 handler ）

簡単にするために、すべての制御コードを1つのerdicoモジュールに入れています。 狂信者はここ​​で4つのモジュールを作成でき、残りのすべては、ロジックが突然顕著に非自明になり、したがって別のモジュールにふさわしいピースを作成します。

HTTPサーバー

おおよその最小構成が含まれています。 他に何が起こるかは、 ドキュメントに記載されています。

 start_cowboy() -> DefPath = {'_', erdico_handler, []}, % Catch-all path Host = {'_', [DefPath]}, % No virtualhosts Dispatch = cowboy_router:compile([Host]), Env = [{env, [{dispatch, Dispatch}]}], cowboy:start_http(?MODULE, 10, [{port, 2080}], Env).
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リクエストハンドラー

ここまではすべてが原始的です：

 -module(erdico_handler). -behavior(cowboy_http_handler). -export([init/3, handle/2, terminate/3]). init(_Type, Req, _Options) -> {ok, Req, nostate}. handle(Req, nostate) -> {ok, Replied} = cowboy_req:reply(200, [], <<"hello\n">>, Req), {ok, Replied, nostate}. terminate(_Reason, _Req, nostate) -> ok.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

収集、実行、確認

ビルドするには、作成するだけです。

まず、依存関係のあるディレクトリと、アプリケーションのバイナリのあるディレクトリを指定する必要があります。

 盗まれた@ node1：〜/ erdico $ ERL_LIBS = deps erl -pa ebin -s erdico 

ラガーでさえ、何らかの形で機能し始めたことがわかります（コンソールに加えて、彼はディスクにも書き込みました）。

盗まれた@ node2：〜$ curl node1：2080
こんにちは

カウンター

さて、アプリケーションが起動して実行されます。 その存在に意味を加える時です。

実装の詳細については触れませんが、 パッチを読んでください。

デモンストレーション

これまで、同じホストnode1-e1 @ node1およびe2 @ node1で両方のアーランノードを起動しました。 これを行うには、サーバーがハングするポートをコマンドラインから構成します。

最初のメモでは、カウンターを20に、2番目に-1に巻き上げます。クラスターをアセンブルし、2番目のノードのカウンターが強制終了したことを確認します。その後、2番目のノードからカウンターへのアクセスが最初のカウンターを呼び出します。

カウボーイとカウンター

まあ、それは簡単です。





投稿の簡単な部分は終わりました 。

access.log

Lagerは、Erlangで唯一のライブログフレームワークです。 あいにく、彼は生涯の例を含む簡潔な文書を欠いています。 少なくともRunetにとって、この投稿がそのような例になることを願っています。

さらに、 カウボーイの access.logエントリでは、インターネットはそれほど寛大ではありません。 この投稿でもこれが修正されることを願っています。

ラガートレース

ラガー構成では、イベントは重大度に応じてファイル間で分散されます。 HTTPサーバーのログを記録するには、イベントを特定のログに明示的に送る必要があるため、これは私たちには適していません。 このため、ラガーにはトレースと呼ばれる特別な切り傷があります。これを使用します。

この時点で、すでに設定ファイルが必要です。

ここで、クラッシュログをリダイレクトし、多かれ少なかれ重要なイベントを含むログを作成し、イベントメタデータに{tag、access}が含まれている場合、トレースを通じてのみ書き込まれるaccess.logを宣言します。 このフォーマットでは、すべてが多かれ少なかれ明確です。行は文字列として挿入され、アトムは対応するキーのメタデータからの値に置き換えられます（後で使用方法を説明します）。

設定されたすべてのログについて、ローテーションは深夜にオンになり、5つの古いファイルが保存されます。 ログローテーションは無効です。

カウボーイonresponseフック

既製のコードに関する最大限の作業をダンプしたいと思います。 したがって、cowboy_req：reply / 4を呼び出す各場所にロギングを挿入する代わりに、カウボーイ自体にロギングを挿入します。 このため、判明したように、答えへのフックの形で特別な場所さえあります。 ドキュメントはあなたの友達です。

「額に」ソリューションはこのように見え、書き込みます

ノンブロッキングフック

onresponseフックのドキュメントを読んだ人は、上記のソリューションでは、ログへの書き込み後に厳密に答えが送信されることをすでに推測できました。

これは、スタックしたロガー（たとえば、ディスクが遅い）が応答時間を増やすことを意味します。

また、これは、リクエストの処理時間をログに書き込むことにした場合、ロギングに費やされた時間は含まれず、クライアントの観点とは大きく異なる可能性があることも意味します。

したがって、クライアントに応答を送信した後にログが厳密に書き込まれるように、もう一度ドキュメントを確認してフックをやり直します。

切断可能なログ

RPSを測定する場合、各リクエストのログに行を書き込まないようにする必要があります。

設定がログが不要であることを明示的に示している場合、フックが発生しないようにします。

このパッチの後、起動ラインに「-erdico log_access false」パラメーターを追加すると、ログが無効になります。

リリースとrelx

リリースは、おそらくErlangで開発する最大の苦痛の1つです。 relxは、ユーザーをこの痛みから救うように設計されています。 （ネタバレ：本当ではない）

ビルドをリリースするだけ

このファイルに入力した後、makeを呼び出すと、_relディレクトリにリリースがビルドされます。



拡張された起動スクリプトなしでは成功しませんでしたが、後で必要になります。



ご覧のとおり、リリースには遅延設定は含まれていません。 また、このことは、クラスターでの作業にはあまり適さないノードの名前も入力しました。 これらおよびその他の問題をさらに解決します。

リリースに適切な設定を含める

そのため、リリースを正しいノード名で開始し、起動時にノードをクラスター姉妹に接続する必要があります。 また、これらの設定やその他の設定を、欠落しているコンマから逸脱しない明確な構文でファイルに設定できるようにします。

まず第一に、すべてがハードコードです。

カーネルオプションsync_nodes_optionalとsync_nodes_timeoutに注意してください-一緒に起動時に指定された姉妹にノードを接続させ、それらからの応答を1秒間待ちます。 この2秒間は、カウンターのglobal：sync（）の呼び出しがブロックされ、開始時の不必要な死亡がなくなります。

vm.argsでは、明らかに、他のオプションを記述できます。 ただし、-nameまたは-snameを指定しない場合、リリースは開始されません。

これで、リリースを完全に2番目のノードにコピーすることができ、クラスターの起動後に魔法のように組み立てられます-curlによるチェックに合格しました。 2番目のノードのアーランがインストールされていないことが重要です。つまり、リリースは自給自足です。

リリーススクリプトによる変数の開示

relxが提供する優れた機能の1つは、変数の拡張です。 _rel / erdico / bin / erdicoリリース起動スクリプトでRELX_REPLACE_OS_VARSという行を見つけると、これがどのように発生するかを確認できます。 すべてが単純なので、柔軟性さえありません。



1つの問題：変数を公開しないと、リリースが開始されません。

ハック：リリーススクリプトによる変数の非開示

リリースを開示と非開示の両方で開始するために、私はそのようなハックを思いつきました。 とにかく拡張はupstartスクリプトに送られるため、人間の構成が同時に読み取られるため、コメント内のすべての変数を非表示にし、コメントを完成させる変数を追加します。 リリースをそのままで、または近隣ノードの指示を伴って実行できるパッチ -

  RELX_REPLACE_OS_VARS = 1 CLUSTERNODES = "erdico @ node2、erdico @ node1" NL = $ '\ n' _rel / erdico / bin / erdicoコンソール 

コンボハック：名前の開示と重複

プロダクションと競合することなく、汚れた手でリリースを開始できるようにしましょう。 これを行うには、ノード名もパラメーター化する必要があります。 同時に、パラメータ化により、そこにフルネーム（FQDNを含む）を入力します。

一方では、vm.argsをノード名なしで残すことはできません。 一方、以前のハックでは、構成に行を追加できますが、削除することはできません。 3番目-Erlangにいくつかの名前を付けた場合、彼の選択はあまり予測できません。

vm.argsでは、-extraディレクティブがパラメーターの別のセクションに進み、カーネルによって読み取られない後に書き込まれるすべてのものが判明しました。 これが使用するものです。

パラメータ化された開始は次のようになります。

  RELX_REPLACE_OS_VARS = 1 CLUSTERNODES = "'erdico@node2.example.net'、 'erdico@node1.example.net'" FQDN = `hostname -f` NL = $ '\ n' _rel / erdico / bin / erdicoコンソール 

ビルドdebパッケージ

Debianは開発者に大きな苦痛を与えます。 痛みはdebianディレクトリ内のファイルの束から始まり、プロジェクトのルート、debianディレクトリの代替の場所、または収集されたパッケージを折りたたむためのパスを指定できないことから続きます。

収集されたパッケージは、プロジェクトソースがあるディレクトリの1レベル上のディレクトリに送信されることがわかっています。 したがって、このすべての汚物は深く埋められるべきです。

upstart configでさえ、非常に貧弱なスクリプト機能があるため、適切な環境を準備する別のconf_erdico.shスクリプトで開始スクリプトをラップする必要がありました。

ラガーは、シンボリックリンクの下にあるログを書き込めないことが判明しました（filelibの特性により、ensure_dir / 1）。 そのため、ログへのパスを置き換えるために、構成にハックを挿入する必要がありました。

実際、外部スクリプトはとにかく書かれているので、sedを使用して構成内のすべての置換を行うことはすでに可能でした。 そのままにしておくと、概念実証があります。

組み立て、インストール、構成、起動！

うまくいく！

約束されたREST

ここにある。

道徳

人生は苦痛です。

ラガーは優れていますが、構成の柔軟性に欠けています（たとえば、構成ごとにルートディレクトリとデフォルトのファイルログオプションを設定するなど）。

カウボーイは良いですが、パフォーマンスが低下しないように、それがどのように機能するかを理解する必要があります。

Debianは優れていますが、そのためのパッケージのアセンブリは、ミュータントのミュータントによっても行われました。

Upstartは優れていますが、サービス構成で行うにはあまりにも少ないため、ロジックを追加のスクリプトに追加する必要があります。

Erlangは、彼を知らない人をサポートするためにアプリケーションを提供する必要があるまでは良いです。

アーランには依存関係マネージャーがありますが、機能しますが、依存関係の地獄の問題は解決されていません。

Erlangのリリースビルドは、それほどではありませんが、依然として苦痛です。 Relxはコミットを待っていますが、それを使用しなければ、それを使用するのはまだ不便です。 さらに、依存関係のどこかにシンボリックリンクのサイクルまたはアセンブルされたリリースがある場合、それはおかしくなります。

このアプリケーションで他にできること

まず、カウンターの複製を実行できます。 ただし、クラスターのすべてのノードに各呼び出しの通知を送信すると、ボトルネックが発生します。

第二に、設定で指定されたネイバーを常にpingするプロセスを追加できます。 これがないと、アーランはネットワークの切断にひどく耐えられません。

第三に、ステータス付きのペンを追加します。 このアプリケーションが実行されているクラスターのノードと、ウィザードが現在実行されているノードを表示します。

4番目に、マスターが現在配置されているホストをヘッダーに指定します。 十分にスマートなクライアントは、ノード間でトラフィックを駆動しないように、次回すぐにそこに行くことができます。

第5に、設定からすべてのハックを削除し、sedと彼の友人とのすべての置換を行います。

第6に、別のプロジェクトでカウボーイラガーバンドルのonresponseフックを配置し、フォーマットアトムを要求プロパティ値に自動的に変換する方法を学習できます。 さらに、処理時間やリクエストなどのトラフィックなど、あらゆる種類のメトリックを整理できます。

7番目に、 log4erlを調べます 。

8番目に、 epmを学びます 。 最大のタスクとして、依存関係マネージャーと友達を作りましょう。