序章

Erlangプログラミング言語に基づいて構築されたElixirは、開発者の生産性と高度な並行性とスケーラブルなアプリケーションの作成のしやすさに重点を置いていることで人気のある関数型プログラミング言語です。

Phoenix は、Elixir上に構築されたWebフレームワークであり、高性能のWebアプリケーションの作成を可能にします。

また、蒸留所と edeliver の2つの追加ツールと組み合わせると、開発環境から本番サーバーへのPhoenixプロジェクトのデプロイを完全に自動化できます。

Distilleryは、Elixirアプリケーションを単一のパッケージにコンパイルし、他の場所にデプロイできるようにします。 また、コードのホットスワップを可能にするパッケージを生成します。これは、ダウンタイムなしでライブアプリケーションをアップグレードできることを意味します。 これらはすべて、構成をほとんどまたはまったく行わずに実行できるため、蒸留所は他の多くのオプションとは一線を画しています。

edeliverは、アプリケーションのビルド、ビルドされたパッケージのサーバーへの転送、データベースの移行、サーバーの起動/更新などの反復的なタスクを処理することにより、このビルドとデプロイメントのプロセスを自動化します。 必要に応じて、中間ステージング設定を可能にするようにedeliverを構成することもできます。

このチュートリアルでは、Erlang、Elixir、Phoenix 1.3をローカル開発マシンと本番サーバーにインストールし、2つの場所間のSSH通信を簡素化してから、サンプルのPhoenixプロジェクトを作成してビルドします。 edeliverでデプロイします。 最後に、NginxリバースプロキシとSSL証明書を使用して本番サーバーを保護します。

チュートリアルが終了するまでに、次のことができる単一のコマンドが作成されます。

  • 本番環境と互換性のあるPhoenixリリースをビルドします
  • リリースを実稼働環境にデプロイします
  • 実稼働環境でアプリケーションを開始します
  • ダウンタイムなしで新しいリリースをデプロイすることにより、現在の本番リリースをホットスワップします

前提条件

開始する前に、次のものがあることを確認してください。

  • Ubuntuベースのローカル開発マシン。 このチュートリアルの手順はUbuntuベースのローカル開発マシン向けに書かれていますが、このデプロイメントプロセスの1つの強みは、実稼働環境から完全に独立していることです。 他のオペレーティングシステムでローカル開発マシンをセットアップする手順については、公式のElixirインストールドキュメントを参照してください。 または、Ubuntuベースのリモート開発マシンをセットアップするには、この初期サーバーセットアップチュートリアルに従ってください。

  • この初期サーバーセットアップチュートリアルの最初の4つの手順に従ってセットアップされた、少なくとも1GBのRAMを搭載したUbuntu16.04本番サーバーでsudo特権を持つ非rootユーザーアカウント。

    • 私たちの目標は展開プロセスを自動化することなので、セットアップチュートリアルのステップ4に従うときは、SSHパスフレーズを入力しないでください。 さらに、セットアップチュートリアルのステップ7で、コマンドsudo ufw allow 4000を使用してポート4000へのアクセスを許可してください。 これは、このチュートリアル全体でPhoenixをテストするために使用するポートです。

  • このUbuntu16.04ガイドにNginxをインストールする方法に従ってNginxを本番サーバーにインストールします。

  • 完全に登録されたドメイン名。 このチュートリアルでは、全体を通してexample.comを使用します。 Namecheap でドメイン名を購入するか、 Freenom で無料でドメイン名を取得するか、選択したドメイン登録事業者を使用できます。

  • 次の両方のDNSレコードがサーバー用に設定されています。 それらを追加する方法の詳細については、このホスト名チュートリアルに従うことができます。

    • サーバーのパブリックIPアドレスを指すexample.comのAレコード。
    • サーバーのパブリックIPアドレスを指すwww.example.comのAレコード。

  • この設定に従って、SSL証明書で保護されたNginxは、Ubuntu16.04チュートリアルでNginxサーバーブロックを使用して暗号化します。 Nginxセットアップチュートリアルのステップ4でオプション2Redirectを選択してください。これにより、このチュートリアルで作成している本番サーバー上のHTTPSへの自動リダイレクトが提供されます。

ステップ1—ローカル開発マシンへのElixirとPhoenixのインストール

ElixirはErlangVMで実行されるため、Elixir自体をインストールする前にVMをインストールする必要があります。 また、Erlangの最新の安定バージョンを使用していることを確認したいので、ErlangソリューションリポジトリからErlangをインストールします。

まず、ErlangSolutionsリポジトリをダウンロードしてローカル開発マシンに追加します。

  1. cd ~

  2. wget https://packages.erlang-solutions.com/erlang-solutions_1.0_all.deb

  3. sudo dpkg -i erlang-solutions_1.0_all.deb

次に、パッケージリストを更新し、esl-erlangパッケージをインストールします。このパッケージは、Erlangプログラミング言語と、Erlang / OTPプラットフォームと総称される便利なツール、ライブラリ、ミドルウェアの両方を提供します。

  1. sudo apt-get update

  2. sudo apt-get install esl-erlang

次に、Elixirをインストールします。

  1. sudo apt-get install elixir

次に、Mix（Elixirプロジェクトを作成して依存関係を管理するためのElixirにバンドルされているビルドツール）を使用して、Elixir独自のパッケージマネージャー Hex をインストールします。これは、後でPhoenixをインストールするために使用します。

このコマンドのlocalの部分は、hexをローカルにインストールするようにMixに指示します。

  1. mix local.hex

インストールの確認を求められたら、Yと入力します。

Output
Are you sure you want to install "https://repo.hex.pm/installs/1.5.0/hex-0.17.1.ez"? [Yn] Y
* creating .mix/archives/hex-0.17.1

次に、Hexを使用してPhoenix 1.3.0 Mixアーカイブをインストールします。これは、構築する新しいベースPhoenixプロジェクトを生成するために必要なすべてを含むZipファイルです。

  1. mix archive.install https://github.com/phoenixframework/archives/raw/master/phx_new-1.3.0.ez

ここでも、インストールの確認を求められたら、Yと入力します。

Output
Are you sure you want to install "https://github.com/phoenixframework/archives/raw/master/phx_new-1.3.0.ez"? [Yn] Y
* creating .mix/archives/phx_new-1.3.0

警告： phx_new.ezアーカイブからPhoenixをインストールすると、このチュートリアルで使用しているものとは異なる可能性のある最新バージョンのPhoenixを入手できます—1.3.0。 次に、このチュートリアルを使用しているフェニックスのバージョンに適合させる必要があります。

ElixirとPhoenixをローカル開発マシンにインストールしたら、必要な部分を本番サーバーにインストールしましょう。

ステップ2—本番サーバーへのElixirとPhoenixのインストール

フェニックスプロジェクトをローカル開発マシンと本番サーバーの両方で実行する必要があるため、両方の場所に同じ言語とツールをすべてインストールする必要があります。

ステップ1と同じコマンドを使用して、ErlangSolutionsリポジトリをダウンロードして本番サーバーに追加します。

  1. cd ~

  2. wget https://packages.erlang-solutions.com/erlang-solutions_1.0_all.deb

  3. sudo dpkg -i erlang-solutions_1.0_all.deb

パッケージリストを更新し、esl-erlangパッケージをインストールします。

  1. sudo apt-get update

  2. sudo apt-get install esl-erlang

Elixirをインストールします。

  1. sudo apt-get install elixir

Mixを使用してHexをインストールします。

  1. mix local.hex

インストールの確認を求められたら、Yと入力します。

Output
Are you sure you want to install "https://repo.hex.pm/installs/1.5.0/hex-0.17.1.ez"? [Yn] Y
* creating .mix/archives/hex-0.17.1

これで、ローカル開発マシンと本番サーバーの両方でPhoenixを実行する準備が整いましたが、SSHホストエイリアスを設定して、ローカル開発マシンから本番サーバーに簡単に接続できるようにしましょう。

ステップ3—SSHホストエイリアスの設定

私たちの目標は完全に自動化された展開プロセスであるため、本番サーバーの初期セットアップ中に、パスフレーズの入力を求めないSSHキーペアを生成しました。

現在、コマンドssh -i ~/.ssh/private_key_file sammy@example.comを使用して、ローカル開発マシンから本番サーバーに接続できます。

ここでは、ユーザーsammyとしてexample.comに接続しています。 -iフラグは、SSHに~/.ssh/private_key_fileにある秘密鍵ファイルを接続に使用するように指示します。

ただし、本番サーバーに接続するときに使用する秘密鍵、ユーザー、およびドメインを自動的に認識するSSHホストエイリアスを設定することで、このコマンド（および展開プロセス自体）をさらに簡単にすることができます。

ローカル開発マシンで~/.ssh/configを開いて編集します。

  1. nano ~/.ssh/config

そして、次の行にコピーします。

〜/ .ssh / config
Host example.com 
    HostName example.com
    User sammy
    IdentityFile ~/.ssh/private_key_file

注： configファイルにすでに何かが含まれている場合は、この新しい構成を既存の構成から分離する空の行を追加してください。

Host行は、この特定の構成を識別するエイリアスを提供します。 覚えやすくするために、ドメイン名を使用しています。 HostName行は、SSHに接続するホストを指示します。 User行はSSHに接続するユーザーを通知し、IdentityFileはSSHに使用する秘密鍵ファイルを通知します。

変更を保存してファイルを閉じます。

最後に、運用サーバーに接続して構成をテストします。

  1. ssh example.com

ユーザー、秘密鍵ファイル、またはドメインを指定しなくても接続できるはずです。 接続できなかった場合は、画面上のメッセージに従い、前の手順に戻って問題を解決してください。

本番サーバーへの接続が簡略化されたので、デプロイ用のサンプルのPhoenixプロジェクトを作成できます。

ステップ4—テストプロジェクトの作成

デフォルトでは、新しいPhoenixプロジェクトを作成すると、PostgreSQLデータベースアダプターとBrunch、JavaScriptベースのWebアプリケーションビルドツールで構成されます。 この追加の複雑さを回避するために、--no-ectoフラグと--no-brunchフラグをそれぞれ渡すことにより、データベースアダプターなしとブランチなしのmyprojectという名前の単純なPhoenixプロジェクトを作成します。

ホームディレクトリに移動して、新しいプロジェクトを作成します。

  1. cd ~

  2. mix phx.new --no-ecto --no-brunch myproject

出力には、Phoenixがmyprojectプロジェクトのスキャフォールディングとして作成したディレクトリとファイル、必要な依存関係をインストールすることを確認するプロンプト、Phoenixの組み込みサーバーを起動する方法の説明が含まれます。

インストールの確認を求められたら、Yと入力します。

Output
* creating myproject/config/config.exs
* creating myproject/config/dev.exs
* creating myproject/config/prod.exs
...

Fetch and install dependencies? [Yn] Y
* running mix deps.get
* running mix deps.compile

We are all set! Go into your application by running:

    $ cd myproject

Start your Phoenix app with:

    $ mix phx.server

You can also run your app inside IEx (Interactive Elixir) as:

    $ iex -S mix phx.server

それでは、テストプロジェクトが機能しているかどうかを見てみましょう。

myprojectディレクトリに移動し、mix phx.serverコマンドを実行してプロジェクトをコンパイルし、サーバーを起動します。

  1. cd ~/myproject

  2. mix phx.server

出力には、Phoenixがコンパイルしたファイルの数と種類が示され、途中で発生した問題に関する警告が表示され、成功した場合は、プロジェクトに到達する場所が示されます。

ローカル開発マシンでElixirベースのアプリケーションを初めてコンパイルすると、Mixが依存するErlangのビルドおよび依存関係ツールであるRebarをインストールするように求められます。 プロンプトでYと入力します。

Output
==> file_system
Compiling 6 files (.ex)
Generated file_system app
...
Could not find "rebar3", which is needed to build dependency :ranch
I can install a local copy which is just used by Mix
Shall I install rebar3? (if running non-interactively, use "mix local.rebar --force") [Yn] Y
...
Compiling 11 files (.ex)
Generated myproject app
[info] Running MyprojectWeb.Endpoint with Cowboy using http://0.0.0.0:4000

現在の設定をテストするには、Webブラウザで http：// localhost：4000を指定します。 フェニックスにあなたを歓迎するデフォルトのフェニックスフレームワークホームページが表示されます。 そうでない場合は、ファイアウォールがポート4000での接続を許可していることを確認してから、端末の出力で詳細な手順を確認してください。

すべてが機能していることを確認したら、CTRL+Cを2回押してサーバーを停止し、ステップ5でさらに構成できるようにします。

完全に機能するローカルのPhoenixプロジェクトができたので、蒸留所とedeliverを使用するように構成しましょう。

ステップ5—蒸留所とedeliverを使用するようにプロジェクトを構成する

フェニックスプロジェクトは、プロジェクトが実行されるポートやプロジェクトのホストURLなどの構成の詳細をconfig/prod.exsに保存するため、まずそのファイルを編集して、本番環境でプロジェクトにアクセスする方法をフェニックスに指示します。

ローカル開発マシンでconfig/prod.exsを開いて編集します。

  1. nano ~/myproject/config/prod.exs

次のコードブロックを見つけます。

config / prod.exs
...
config :myproject, MyprojectWeb.Endpoint,
  load_from_system_env: true,
  url: [host: "example.com", port: 80],
  cache_static_manifest: "priv/static/cache_manifest.json"
...

load_from_system_envがtrueに設定されている場合、Phoenixは、プロジェクトを実行するポートをPORT環境変数からデフォルトで取得します。 これはHTTPポートと呼ばれます。

url: [host]およびurl: [port]は、プロジェクト内でリンクを生成するために使用されます。 HTTPとURLのこの違いは、プロキシエンドポイントがPhoenixプロジェクトとは異なるポートで公開されるプロキシを設定する場合に特に役立ちます。

簡単にするために、myprojectが実行されるHTTPポートにハードコーディングします。 これにより、可動部品の数が減り、自動展開プロセスの信頼性が向上します。

変更するデフォルトのオプションに加えて、2つの新しいオプションも追加します。

serverオプションは、開始時にHTTPサーバーを起動するようにプロジェクトを構成するようにDistilleryに指示します。これは、完全に自動化された展開プロセスで必要なことです。

code_reloaderオプションは、プロジェクトのコードが変更されるたびに、接続されているすべてのWebブラウザーを更新するようにプロジェクトに指示します。 これは開発において非常に役立つ機能ですが、実稼働環境向けではないため、オフにします。

次に、デフォルト構成を変更します。

config / prod.exs
...
config :myproject, MyprojectWeb.Endpoint,
  http: [port: 4000],
  url: [host: "example.com", port: 80],
  cache_static_manifest: "priv/static/manifest.json",
  server: true,
  code_reloader: false
...

注：潜在的な構成の問題を回避するために、続行する前に,が追加されていることを再確認してください。

変更を加えたら、config/prod.exsを保存して閉じます。

ステップ4でmyprojectプロジェクトを作成すると、Phoenixはステップ6でコードをプッシュするときに必要な.gitignoreファイルを自動的に生成しました。 edeliverを使用したビルドサーバーへの変更。

デフォルトでは、その.gitignoreファイルは、リポジトリが不必要に大きくならないように、依存関係を無視してファイルをビルドするようにGitに指示します。 さらに、そのファイルはGitにprod.secret.exsを無視するように指示します。これは、すべてのPhoenixプロジェクトのconfigディレクトリにあるファイルで、本番データベースのパスワードやトークンに署名するためのアプリケーションシークレットなどの非常に機密性の高い情報を保持します。

myprojectプロジェクトが正しく機能するには、本番サーバーでprod.secret.exsが必要であり、Gitで移動できないため、手動でサーバーに転送する必要があります。

本番サーバーのホームディレクトリに、app_configという名前の新しいディレクトリを作成します。 ここにprod.secret.exsを保存します。

  1. cd ~

  2. mkdir app_config

次に、scpを使用して、prod.secret.exsを運用サーバーのapp_configディレクトリにコピーします。

  1. scp ~/myproject/config/prod.secret.exs example.com:/home/sammy/app_config/prod.secret.exs

最後に、本番サーバーにapp_configの内容を一覧表示して、転送が行われたことを確認します。

  1. ls ~/app_config

出力にprod.secret.exsが表示されない場合は、ローカル開発マシンの端末で追加情報を確認してください。

実稼働サーバーにprod.secret.exsを使用すると、ビルドプロセス用にDistilleryをインストールし、myprojectのメイン構成ファイルであるmix.exsに両方を含めることで展開用に配信する準備が整います。 ] 事業。

ローカル開発マシンでmix.exsを開きます。

  1. nano ~/myproject/mix.exs

ここで、次のコードブロックを見つけます。

mix.exsの依存関係
  ...
  defp deps do
    [
      {:phoenix, "~> 1.3.0"},
      {:phoenix_pubsub, "~> 1.0"},
      {:phoenix_html, "~> 2.10"},
      {:phoenix_live_reload, "~> 1.0", only: :dev},
      {:gettext, "~> 0.11"},
      {:cowboy, "~> 1.0"}
    ]
  end
  ...

depsは、myprojectプロジェクトのすべての依存関係を明示的に定義するプライベート関数です。 厳密には必須ではありませんが、プロジェクト構成を整理するのに役立ちます。

edeliverとdistilleryを依存関係のリストに追加します。

mix.exsの依存関係
  ...
  defp deps do
    [
      {:phoenix, "~> 1.3.0"},
      {:phoenix_pubsub, "~> 1.0"},
      {:phoenix_html, "~> 2.10"},
      {:phoenix_live_reload, "~> 1.0", only: :dev},
      {:gettext, "~> 0.11"},
      {:cowboy, "~> 1.0"},
      {:edeliver, "~> 1.4.3"},
      {:distillery, "~> 1.4"}
    ]
  end
  ...

注：潜在的な構成の問題を回避するために、新しいedeliverエントリの前の行の最後に、が追加されていることを再確認してください。

変更を保存してmix.exsを閉じます。

次に、mixに、実行時に使用できるように新しい依存関係をフェッチするように指示します。

  1. cd ~/myproject/

  2. mix deps.get

出力は、edeliverとdistilleryがプロジェクトに正常に追加されたことを示しています。

Output
Resolving Hex dependencies...
Dependency resolution completed:
  ...
* Getting edeliver (Hex package)
  Checking package (https://repo.hex.pm/tarballs/edeliver-1.4.4.tar)
  Fetched package
* Getting distillery (Hex package)
  Checking package (https://repo.hex.pm/tarballs/distillery-1.5.2.tar)
  Fetched package

最後に、ローカル開発マシンでPhoenixのサーバーを再起動して、現在の構成をテストします。

  1. mix phx.server

ブラウザでhttp：// localhost：4000を指定します。 ステップ4で見たのと同じデフォルトのPhoenixホームページが表示されます。 そうでない場合は、前の手順を再度トレースし、ローカル開発マシンの端末で追加情報を確認してください。

続行する準備ができたら、CTRL+Cを2回押してサーバーを停止し、次のステップでさらに構成できるようにします。

Distilleryとedeliverがインストールされたら、展開用にそれらを構成する準備が整いました。

ステップ6—Edeliverと蒸留所の構成

蒸留所には、デフォルトでは生成されないビルド構成ファイルが必要です。 ただし、mix release.initを実行することでデフォルト構成を生成できます。

ローカル開発マシンのmyprojectディレクトリに移動し、構成ファイルを生成します。

  1. cd ~/myproject

  2. mix release.init

出力は、ファイルが作成されたことを確認し、リリースを編集およびビルドする方法に関する詳細な手順が含まれています。

Output
An example config file has been placed in rel/config.exs, review it,
make edits as needed/desired, and then run `mix release` to build the release

edeliverは、ホットアップグレードを実行するときに、rel/myprojectディレクトリでリリースを検索しますが、Distilleryは、デフォルトで _buildディレクトリにリリースを配置します。 それでは、Distilleryのデフォルトの構成ファイルrel/config.exsを変更して、製品リリースを適切な場所に配置しましょう。

エディターでrel/config.exsを開きます。

  1. nano rel/config.exs

次のセクションを見つけてください。

rel / config.exs
...
environment :prod do
  set include_erts: true
  set include_src: false
  set cookie: :"f3a1[Q^31~]3~N=|T|T=0NvN;h7OHK!%%c.}$)iP9!X|TS[X@sqG=m`yBYVt4/`:"
end
...

このブロックは、Distilleryに自己完結型の製品リリースパッケージを構築する方法を指示します。 include_ertsは、Erlangランタイムシステムをバンドルするかどうかを示します。これは、ターゲットシステムにErlangまたはElixirがインストールされていない場合に役立ちます。 include_srcは、ソースコードファイルを含めるかどうかを示します。 また、cookie値は、Erlangノードが相互に通信することを認証するために使用されます。

ファイルを閉じます。

これでedeliverを構成する準備ができましたが、構成ファイルを手動で作成する必要があります。

ローカル開発マシンのmyprojectディレクトリに移動し、.deliverという名前の新しいディレクトリを作成してから、.deliver/configで新しいファイルを開いて編集します。

  1. cd ~/myproject

  2. mkdir .deliver

  3. nano .deliver/config

このファイルでは、ビルドサーバーと本番サーバーの詳細を指定します。 ビルドと本番の両方に同じサーバーを使用しているため、ホストとユーザーはビルドと本番で同じです。 さらに、app_buildディレクトリでビルドを実行し、コンパイルされた本番ファイルをapp_releaseディレクトリに配置します。

以下をファイルにコピーします。

.deliver / config
APP="myproject"

BUILD_HOST="example.com"
BUILD_USER="sammy"
BUILD_AT="/home/sammy/app_build"

PRODUCTION_HOSTS="example.com" 
PRODUCTION_USER="sammy" 
DELIVER_TO="/home/sammy/app_release"

次に、ビルドフォルダにprod.secret.exsへのシンボリックリンクを作成します。これは、ステップ5で本番サーバーのapp_configディレクトリに転送したファイルです。 このシンボリックリンクは、edeliverフック内に作成されます。 ビルド、ステージング、およびデプロイメントプロセスの各ポイントで、特定のフックがedeliverによって呼び出されます。 自動デプロイメントのセットアップでは、edeliverが依存関係を取得してコンパイルを開始する前に呼び出されるpre_erlang_get_and_update_depsフックをリッスンしています。

.deliver/configに以下を追加してください。

.deliver / config
pre_erlang_get_and_update_deps() {
  local _prod_secret_path="/home/sammy/app_config/prod.secret.exs"
  if [ "$TARGET_MIX_ENV" = "prod" ]; then
    __sync_remote "
      ln -sfn '$_prod_secret_path' '$BUILD_AT/config/prod.secret.exs'
    "
  fi
}

編集が完了したら、ファイルを保存して閉じます。

edeliverはGitを使用して、コードを最新のコミットからビルドサーバーにプッシュし、さらにアクションを実行するため、デプロイ前の最後のステップは、プロジェクトのGitリポジトリを作成することです。

ローカル開発マシンのmyprojectディレクトリで、git initコマンドを使用して、空のGitリポジトリを作成します。

  1. cd ~/myproject

  2. git init

ファイルをGitインデックスに追加する前に、リリースtarballを含むディレクトリも.gitignoreファイルに追加する必要があります。 そうしないと、Gitリポジトリのサイズが数回のリリース後に非常に大きくなります。

  1. echo ".deliver/releases/" >> .gitignore

次に、myprojectプロジェクトのファイルの完全なセットをGitステージング領域に追加して、次のコミットに含まれるようにします。

  1. git add .

次に、Gitがこのリポジトリに関連付ける必要があるIDを設定します。 これは、プロジェクトへの変更がどこから来たのかを追跡するのに役立ちます。

  1. git config user.email "[email protected]"

  2. git config user.name "Your Name"

最後に、-mオプションを使用してファイルをリポジトリにコミットし、コミットの理由を説明します。

  1. git commit -m "Setting up automated deployment"

出力はコミットメッセージを繰り返し返し、変更されたファイルの数、挿入された行の数、およびリポジトリに追加されたファイルの名前を報告します。

  1. Output
    [master (root-commit) e58b766] Setting up automated deployment

  2.  39 files changed, 2344 insertions(+)

  3.  create mode 100644 .deliver/config

  4. ...

プロジェクトがGitと蒸留所にコミットされ、edeliverが完全に構成されたので、最初の展開の準備が整いました。

ステップ7—プロジェクトの展開

この展開プロセスの利点の1つは、ローカル開発マシンでほとんどすべてを実行できることです。本番サーバーにアクセスする必要はほとんどありません。

myprojectプロジェクトを本番サーバーにプッシュして、すべてをmyprojectしてみましょう。

まず、ローカル開発マシンでmixを使用してプロジェクトのリリースをビルドし、edeliverを使用してビルドサーバーに転送します。

  1. cd ~/myproject

  2. mix edeliver build release

出力は、ビルドプロセスの各ステップについてリアルタイムで更新し、すべてが期待どおりに機能する場合は、ビルドが成功したことを示します。

Output
BUILDING RELEASE OF MYPROJECT APP ON BUILD HOST

-----> Authorizing hosts
-----> Ensuring hosts are ready to accept git pushes
-----> Pushing new commits with git to: [email protected]
-----> Resetting remote hosts to fc86f878d96...
-----> Cleaning generated files from last build
-----> Fetching / Updating dependencies
-----> Compiling sources
-----> Generating release
-----> Copying release 0.0.1 to local release store
-----> Copying myproject.tar.gz to release store

RELEASE BUILD OF MYPROJECT WAS SUCCESSFUL!

ビルドが成功しなかった場合、edeliverは、問題が発生したときに実行しようとしたコード行を示します。 その情報を使用して、問題のトラブルシューティングを行うことができます。

ビルドが完了したら、リリースを本番サーバーに転送します。

  1. mix edeliver deploy release to production

繰り返しになりますが、出力はプロセスの各ステップについてリアルタイムで更新し、すべてが機能する場合は、ビルドが本番環境にリリースされたことを示します。

Output
DEPLOYING RELEASE OF MYPROJECT APP TO PRODUCTION HOSTS

-----> Authorizing hosts
-----> Uploading archive of release 0.0.1 from local release store
-----> Extracting archive myproject.0.1.tar.gz

DEPLOYED RELEASE TO PRODUCTION!

展開で問題が発生した場合は、端末の出力で追加情報を確認してください。

最後に、本番サーバーでmyprojectプロジェクトを開始します。

  1. mix edeliver start production

出力は、プロジェクトが実行されていること、プロジェクトが実行されているホスト、および本番サーバーで使用されているリリースへのパスをユーザーに通知します。 応答はSTART DONE!になります。

Output
EDELIVER MYPROJECT WITH START COMMAND

-----> starting production servers

production node:

  user    : sammy
  host    : example.com
  path    : /home/sammy/app_release
  response:

START DONE!

ブラウザでhttp://example.com:4000を指定して、展開プロセスをテストします。 デフォルトのPhoenixFrameworkホームページがもう一度表示されます。 そうでない場合は、本番サーバーでポート4000が開いていることを再確認してから、ローカル開発マシンの端末で追加情報を確認してください。

完全なビルドとデプロイのプロセスを確認したので、本番サーバーでダウンタイムなしでコードの更新を実行して、セットアップをさらに一歩進めましょう。

ステップ8—本番ダウンタイムなしでプロジェクトをアップグレードする

ビルドおよびデプロイプロセスの機能の1つは、コードをホットスワップして、ダウンタイムなしで本番サーバー上のプロジェクトを更新できることです。 これを試すために、プロジェクトにいくつかの変更を加えましょう。

プロジェクトのホームページファイルを開いて編集します。

  1. nano ~/myproject/lib/myproject_web/templates/page/index.html.eex

次の行を見つけます。

〜/ myproject / web / templates / page / index.html.eex
...
<h2><%= gettext "Welcome to %{name}", name: "Phoenix!" %></h2>
...

ここで、その行を次のように置き換えます。

<h2>Hello, World!</h2>

ファイルを保存して閉じます。

コードベースを更新したので、アプリケーションのバージョンもインクリメントする必要があります。 バージョン番号を使用すると、リリースの追跡と、必要に応じて以前のバージョンへのロールバックが容易になります。

ローカル開発マシンでmix.exsを開きます。

  1. nano ~/myproject/mix.exs

次のブロックを見つけます。

mix.exs
  1.   ...

  2.   def project do

  3.     [app: :myproject,

  4.      version: "0.0.1",

  5.      elixir: "~> 1.2",

  6.      elixirc_paths: elixirc_paths(Mix.env),

  7.      compilers: [:phoenix, :gettext] ++ Mix.compilers,

  8.      build_embedded: Mix.env == :prod,

  9.      start_permanent: Mix.env == :prod,

  10.      deps: deps()]

  11.   end

  12.   ...

バージョンを0.0.1から0.0.2にインクリメントします。

mix.exs
  1.   ...

  2.   def project do

  3.     [app: :myproject,

  4.      version: "0.0.2",

  5.      elixir: "~> 1.2",

  6.      elixirc_paths: elixirc_paths(Mix.env),

  7.      compilers: [:phoenix, :gettext] ++ Mix.compilers,

  8.      build_embedded: Mix.env == :prod,

  9.      start_permanent: Mix.env == :prod,

  10.      deps: deps()]

  11.   end

  12.   ...

次に、ファイルを保存して閉じます。

次に、変更をGitに追加してコミットし、edeliverが変更をビルドサーバーにプッシュする必要があることを認識できるようにする必要があります。

  1. git add .

  2. git commit -m "Changed welcome message"

最後に、変更をホットスワップする準備が整いました。 今回は、ステップ7で使用した3つの関連コマンドと同等の1つのコマンドがあります。

1つのコマンドで、本番サーバーでアプリケーションをビルド、デプロイ、および再起動します。

  1. mix edeliver upgrade production

繰り返しになりますが、出力はプロセスの各ステップをリアルタイムで実行し、成功した場合はUPGRADE DONE!で終了します。

Output
EDELIVER MYPROJECT WITH UPGRADE COMMAND

-----> Upgrading to revision 2fc28b6 from branch master
-----> Detecting release versions on production hosts
-----> Deploying upgrades to 1 online hosts
-----> Checking whether installed version 0.0.1 is in release store
-----> Building the upgrade from version 0.0.1
-----> Authorizing hosts
-----> Validating * version 0.0.1 is in local release store
-----> Ensuring hosts are ready to accept git pushes
-----> Pushing new commits with git to: [email protected]
-----> Resetting remote hosts to 2fc28b6...
-----> Cleaning generated files from last build
-----> Checking out 2fc28b6...
-----> Fetching / Updating dependencies
-----> Compiling sources
-----> Checking version of new release
-----> Uploading archive of release 0.0.1 from local release store
-----> Extracting archive myproject_0.0.1.tar.gz
-----> Generating release
-----> Removing built release 0.0.1 from remote release directory
-----> Copying release 0.0.2 to local release store
-----> Copying myproject.tar.gz to release store
-----> Upgrading production hosts to version 0.0.2
-----> Authorizing hosts
-----> Uploading archive of release 0.0.2 from local release store
-----> Upgrading release to 0.0.2

UPGRADE DONE!

すべてが機能したことを確認するには、ブラウザでhttp://example.com:4000をリロードします。 新しいメッセージが表示されます。 そうでない場合は、前の手順を再度トレースして、端末に追加のエラーおよび警告メッセージがないか確認してください。

デプロイメントプロセスが1つのコマンドに削減され、Erlangの最も有名な機能の1つであるコードのホットスワップも利用されています。 最後の仕上げとして、アプリケーションをNginxプロキシの背後に配置して、本番環境でアプリケーションを強化しましょう。

手順9—本番サーバーでリバースプロキシを設定する

アプリケーションをインターネットに直接公開することはできますが、リバースプロキシを使用するとセキュリティが向上します。 構成を容易にし、SSLをサポートし、カスタムHTTP応答ヘッダーを設定できるようにするために、プロキシにNginxを使用します。

前提条件でUbuntu16.04チュートリアルでLet’sEncryptwith Nginxサーバーブロックを設定した場合、プロジェクト専用に本番サーバーに別のNginxサーバーブロックを作成しておく必要があります。

そのサーバーブロックの構成ファイルを開いて編集します。

  1. sudo nano /etc/nginx/sites-available/example.com

まず、Phoenixプロジェクトが存在する場所と、それがリッスンするポートをNginxに通知する必要があります。 ポート4000でプロジェクトをローカルで提供しているため、プロキシエンドポイントが127.0.0.1:4000にあることをNginxに通知しています。

次のコードを、デフォルトのサーバー構成ブロックの上の構成ファイルにコピーします。

/etc/nginx/sites-available/example.com
upstream phoenix {
    server 127.0.0.1:4000;
}

ここで、同じファイルで、次のコードブロックを見つけます。

/etc/nginx/sites-available/example.com
    ...
        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                try_files $uri $uri/ =404;
        }
    ...

プロキシが機能するには、リクエストヘッダー、クライアントがプロキシされたサーバーのIPアドレス、クライアントのIPアドレスなど、Webサーバーへのすべての接続をPhoenixプロジェクトにリダイレクトするようにNginxに指示する必要があります。自体。

また、 WebSockets を介して着信リクエストを転送するようにNginxを構成します。これは、標準のステートレスHTTP接続を永続的なものにアップグレードするWebサーバーとクライアント間のメッセージングのプロトコルです。

フェニックスには、このチュートリアルでは説明しなかったChannelsという機能がありますが、ChannelsにはWebSocketのサポートが必要です。 この構成がないと、WebSocketリクエストがサーバーに到達しないため、チャネルは機能しません。

前のlocationブロックを次のものに置き換えます。

/etc/nginx/sites-available/example.com
  location / {
    allow all;

    # Proxy Headers
    proxy_http_version 1.1;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_set_header X-Cluster-Client-Ip $remote_addr;

    # WebSockets
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

    proxy_pass http://phoenix;
  }

ファイルを保存して閉じ、続行します。

次に、新しいNginx構成を確認します。

  1. sudo nginx -t

Nginxは、構文に問題がなく、テストが成功したことを報告する必要があります。 そうでない場合は、画面のメッセージに従って問題を解決してください。

Nginxを再起動して、変更を伝達します。

  1. sudo systemctl restart nginx

最後に、セキュリティ上の理由から、ポート4000でHTTPを介したアプリケーションへのアクセスを禁止します。

  1. sudo ufw delete allow 4000

次に、UFWのステータスを確認します。

  1. sudo ufw status

ファイアウォールは、この時点でSSHおよびNginxアクセスのみを許可する必要があります。

Output
Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
Nginx Full                 ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
Nginx Full (v6)            ALLOW       Anywhere (v6)

最後に、ブラウザでhttps://example.comを指定して、すべてが機能していることをテストします。

これで、完全に自動化されたビルドとデプロイのプロセスと、リバースプロキシとSSL証明書の両方で保護された運用サーバーができました。

結論

1つのコマンドでPhoenixプロジェクトをビルドして本番サーバーにデプロイするようにedeliverをセットアップしましたが、まだまだできることがたくさんあります。

ほとんどの本番Phoenixアプリケーションはデータベースを使用します。 Ubuntu 16.04でMySQLを使用してElixir-Phoenixアプリケーションをデプロイする方法では、MySQLデータベースを追加し、新しい機能を本番環境にデプロイするときに、このアプリケーションの操作を続行します。

本番インフラストラクチャがPhoenixノードのクラスターで構成されている場合は、edeliverを使用して、すべてのノードに一度にデプロイしてホットスワップを実行できます。

または、より信頼性の高いセットアップが必要な場合は、本格的なステージングインフラストラクチャを作成し、edeliverを使用してステージングと展開のプロセスを管理できます。

これらのトピックのいずれかについて、または現在のedeliverのインストールを一般的に拡張する方法について詳しくは、プロジェクトのGitHubの公式ホームにアクセスしてください。