序章

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パスフレーズを入力しないでください。 さらに、ポートへのアクセスを必ず許可してください 4000 コマンドを使用したセットアップチュートリアルのステップ7 sudo ufw allow 4000. これは、このチュートリアル全体でPhoenixをテストするために使用するポートです。

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

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

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

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

  • この設定に従って、SSL証明書で保護されたNginxは、Ubuntu16.04チュートリアルでNginxサーバーブロックを使用して暗号化します。 必ずオプション2を選択してください。 Redirect、Nginxセットアップチュートリアルのステップ4で、これにより、このチュートリアルで作成している本番サーバー上の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をインストールするために使用します。

The local このコマンドの一部は、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

次に、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の最新バージョンが入手できます。これは、このチュートリアルで使用しているものとは異なる場合があります—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.

ここでは、に接続しています example.com ユーザーとしてsammy。 The -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 ファイルにはすでに何かが含まれています。この新しい構成を既存の構成から分離する空の行を追加してください。

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

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

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

  1. ssh example.com

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

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

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

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

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

  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そのため、まずそのファイルを編集して、Phoenixに本番環境でプロジェクトに到達する方法を指示します。

開ける 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ポートと呼ばれます。

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

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

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

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

The 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
...

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

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

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

デフォルトでは、 .gitignore fileは、リポジトリが不必要に大きくならないように、依存関係を無視してファイルをビルドするようにGitに指示します。 さらに、そのファイルはGitに無視するように指示します prod.secret.exs、内のファイル 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をインストールし、両方をに含めることでデプロイ用に配信する準備ができています。 mix.exs、のメイン構成ファイル myproject 事業。

開ける 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、転送したファイル app_config ステップ5の運用サーバー上のディレクトリ。 このシンボリックリンクは、edeliverフック内に作成されます。 ビルド、ステージング、およびデプロイメントプロセスの各ポイントで、特定のフックがedeliverによって呼び出されます。 自動展開のセットアップについては、 pre_erlang_get_and_update_deps edeliverが依存関係を取得してコンパイルを開始する前に呼び出されるフック。

以下を追加します .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 ローカルでは、プロキシエンドポイントがにあることをNginxに伝えています 127.0.0.1:4000.

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

/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

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

  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の公式ホームにアクセスしてください。