mix releaseを使ってPhoenixアプリをgigalixirにデプロイする理由について。
なぜGigalixirなのか
PhoenixアプリをデプロイするPaasはドキュメントで３つ紹介されています。
1. Gigalxir
2. Fly.io
3. Heroku
他にCommunity Deployment Guidesとして
4. render.com
のリンクもあります。
Gigalixirを選んだ理由はこちらの記事で上記の四つの候補を比較してGigalixirがベストだと言及されていたからです。
選出理由としては、Dockerの設定が不要、Elxiirに特化していることなどが挙げられています。
とはいえ結局は最終的にどの手段ででプリロイするのかは各開発者次第です。
Chris Mccord氏がfly.ioに就職したこと、fly.ioがLiveBookのスポンサーになったことなどから今後はfly.ioでのデプロイも充実していくものと考えられます。
そもそもAWSやGCPにデプロイすればいいのでは？
Gigalixirは内部的にAWSやGCPを使っており、開発者自身が自分でAWSやGCPにデプロイするよりも手順が簡単になっておりGigalixirを採用するメリットは十分にあるのではないかと思います。しかしGigalixirではできないことをしたい場合は情報が少ないかもしれませんが、自前でAWSやGCPにデプロイする必要が出てくるかもしれません。
なぜreleaseなのか
ドキュメントではreleaseを使う理由を以下のように説明しています。以下 Google翻訳
コードのプリロード
VMには、コードをロードするための2つのメカニズムがあります。インタラクティブと埋め込みです。デフォルトでは、モジュールが初めて使用されるときに動的にモジュールをロードするインタラクティブモードで実行されます。アプリケーションが初めてEnum.map/2を呼び出すと、VMはEnumモジュールを見つけてロードします。欠点があります。本番環境で新しいサーバーを起動すると、他の多くのモジュールをロードする必要があり、最初のリクエストの応答時間が異常に急上昇する可能性があります。 23より前のErlang / OTPで実行している場合、システムは常に組み込みモードで実行されます。 Erlang / OTP 23+を使用する場合、構成中はインタラクティブモードで実行され、その後組み込みモードに切り替わり、システムが起動後にリクエストを処理できるようになります。構成とカスタマイズ
リリースにより、開発者はシステム構成とシステムの起動に使用されるVMフラグをきめ細かく制御できます。自己完結型
リリースでは、ソースコードを本番アーティファクトに含める必要はありません。すべてのコードはプリコンパイルされ、パッケージ化されています。リリースにはErlangVMとそのランタイムがデフォルトで含まれているため、サーバーにErlangやElixirも必要ありません。さらに、ErlangとElixirの両方の標準ライブラリが削除され、実際に使用しているパーツのみが表示されます。複数のリリース
アプリケーションごとに、またはアプリケーション全体でさえ、異なる構成で異なるリリースをアセンブルできます。管理スクリプト
リリースには、起動、再起動、実行中のシステムへのリモート接続、RPC呼び出しの実行、デーモンとしての実行、Windowsサービスとしての実行などのスクリプトが付属しています。
色々選択肢があること自体が素晴らしい
今でこそPaasのプロバイダーが増えていて、どれを選ぶのかを迷うことができますが、過去にはHerokuしかなかった時期があったはずですし、Elixir v1.9以前はreleaseもなかったことを考えるとElixir コミュニティーの発展ぶりに感心します。
寄与した多くの開発者に感謝します😌
チュートリアルのリンク集
https://hexdocs.pm/phoenix/gigalixir.html#content
https://staknine.com/deploy-phoenix-to-gigalixir-using-elixir-releases/
https://dev.to/miguelcoba/deploying-an-elixir-release-to-gigalixir-2d80