前書き

Erlangプログラミング言語上に構築されたhttps://elixir-lang.org/[Elixir]は、開発者の生産性と高度な記述の容易さに重点を置いていることから人気のある機能的なプログラミング言語です。同時かつスケーラブルなアプリケーション。

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

また、2つの追加ツール(https://github.com/bitwalker/distillery[Distillery]およびhttps://github.com/edeliver/edeliver[edeliver])と組み合わせると、開発からPhoenixプロジェクトの展開を完全に自動化できます。本番サーバーへの環境。

DistilleryはElixirアプリケーションを単一のパッケージにコンパイルし、それを他の場所に展開できます。 また、コードの_hot-swapping_を可能にするパッケージを生成します。つまり、ダウンタイムなしでライブアプリケーションをアップグレードできます。 これはすべて、構成をほとんどまたはまったく行わずに実行できます。これにより、Distilleryは他の多くのオプションとは一線を画しています。

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

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

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

  • 実稼働環境と互換性のあるPhoenixリリースを構築する

  • 本番環境にリリースを展開する

  • 実稼働環境でアプリケーションを開始する

  • ダウンタイムなしで新しいリリースを展開することにより、現在の製品リリースをホットスワップします

前提条件

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

  • Ubuntuベースのローカル開発マシン。 このチュートリアルの手順はUbuntuベースのローカル開発マシン向けに書かれていますが、この展開プロセスの強みの1つは、運用環境から完全に独立していることです。 他のオペレーティングシステムでローカル開発マシンをセットアップする手順については、https://elixir-lang.org/install.html [Elixirの公式インストールドキュメント]を参照してください。 または、Ubuntuベースの_remote_開発マシンをセットアップするには、https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-16-04 [この初期サーバーセットアップチュートリアル]に従ってください。

  • 少なくとも1GBのRAMを備えたUbuntu 16.04運用サーバーでのsudo特権を持つ非ルートユーザーアカウント。https://www.digitalocean.com/community/tutorials/initial-server-setupの最初の4つの手順に従って設定します。 -with-ubuntu-16-04 [このサーバーの初期セットアップチュートリアル]。

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

  • Nginxは、https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-16-04 [このUbuntuでのNginxのインストール方法16.04ガイド]に従って、本番サーバーにインストールされています。

  • 完全に登録されたドメイン名。 このチュートリアルでは、全体で `+ example.com +`を使用します。 https://namecheap.com [Namecheap]でドメイン名を購入するか、http://www.freenom.com/en/index.html [Freenom]で無料で入手するか、選択したドメインレジストラを使用できます。 。

  • 次の両方のDNSレコードがサーバーに設定されています。 追加方法の詳細については、https://www.digitalocean.com/community/tutorials/how-to-set-up-a-host-name-with-digitalocean [このホスト名チュートリアル]を参照してください。

  • サーバーのパブリックIPアドレスを指す「++」を持つAレコード。

  • サーバーのパブリックIPアドレスを指す「+ www。+」を持つAレコード。

  • https://www.digitalocean.com/community/tutorials/how-to-set-up-let-s-encrypt-with-nginx-server-blocks-on-ubuntu-16-に従ってSSL証明書で保護されたNginx 04 [この設定は、Ubuntu 16.04チュートリアルでNginxサーバーブロックで暗号化しましょう]。 Nginxセットアップチュートリアルのステップ4でオプション2の `+ Redirect +`を選択してください。これにより、このチュートリアルで作成する実稼働サーバー上のHTTPSへの自動リダイレクトが提供されます。

ステップ1-ローカル開発マシンにElixirとPhoenixをインストールする

ElixirはErlang VM上で実行されるため、Elixir自体をインストールする前にVMをインストールする必要があります。 また、最新の安定バージョンのErlangを使用するようにするため、Erlang SolutionsリポジトリーからErlangをインストールします。

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

cd ~
wget https://packages.erlang-solutions.com/erlang-solutions_1.0_all.deb
sudo dpkg -i erlang-solutions_1.0_all.deb

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

sudo apt-get update
sudo apt-get install esl-erlang

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

sudo apt-get install elixir

次に、Mix(Elixirプロジェクトを作成し、依存関係を管理するためのElixirにバンドルされているビルドツール)を使用して、Elixirの独自のパッケージマネージャーhttps://hex.pm/[Hex]をインストールします。

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

mix local.hex

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

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

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

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

繰り返しますが、インストールの確認を求められたら、「+ Y +」と入力します。

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

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

ステップ2-実稼働サーバーへのElixirとPhoenixのインストール

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

link:#step-1-%E2%80%94-installing-elixir-and-phoenix-on-the-local-development-machine [Step 1]から同じコマンドを使用して、Erlang Solutionsリポジトリをダウンロードして追加します本番サーバー。

cd ~
wget https://packages.erlang-solutions.com/erlang-solutions_1.0_all.deb
sudo dpkg -i erlang-solutions_1.0_all.deb

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

sudo apt-get update
sudo apt-get install esl-erlang

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

sudo apt-get install elixir

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

mix local.hex

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

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

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

手順3-SSHホストエイリアスの設定

目標は完全に自動化された展開プロセスであるため、リンク中にパスフレーズの入力を求めないSSHキーペアを生成しました。

今、コマンド `+ ssh -i〜/ .ssh / @ +`を使用して、ローカル開発マシンから本番サーバーに接続できます。

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

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

ローカル開発マシンで編集のために「+〜/ .ssh / config +」を開きます。

nano ~/.ssh/config

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

〜/ .ssh / config

Host
   HostName
   User
   IdentityFile

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

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

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

ssh

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

実稼働サーバーへの接続を簡素化したので、展開用のサンプルPhoenixプロジェクトを作成できます。

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

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

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

cd ~
mix phx.new --no-ecto --no-brunch

出力には、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]
* 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 +`コマンドを実行してプロジェクトをコンパイルし、サーバーを起動します。

cd ~/myproject
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]
...
Compiling 11 files (.ex)
Generated myproject app
[info] Running MyprojectWeb.Endpoint with Cowboy using http://0.0.0.0:4000

現在のセットアップをテストするには、Webブラウザーでhttp:// localhost:4000を指定します。 デフォルトのPhoenix Frameworkホームページが、Phoenixへの歓迎を表示するはずです。 そうでない場合は、ファイアウォールがポート「4000」での接続を許可していることを確認してから、端末の出力で詳細な手順を確認してください。

すべてが機能していることを確認したら、 `+ CTRL + C +`を2回押してサーバーを停止し、リンクでさらに設定できるようにします:#step-5-%E2%80%94-configuring-the-project-to -use-distillery-and-edeliver [ステップ5]。

完全に機能するローカルフェニックスプロジェクトができたので、Distilleryとedeliverを使用するように設定しましょう。

ステップ5-Distilleryとedeliverを使用するためのプロジェクトの構成

Phoenixプロジェクトは、プロジェクトが実行されるポートやプロジェクトのホストURLなどの構成の詳細を `+ config / prod.exs +`に保存するため、本番環境でプロジェクトにアクセスする方法をPhoenixに伝えることから始めます。

ローカル開発マシンで編集のために「+ config / prod.exs +」を開きます。

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,

 url: [host: "", port: 80],
 cache_static_manifest: "priv/static/manifest.json"


...

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

link:#step-4-%E2%80%94-creating-a-test-project [ステップ4]で `+ myproject `プロジェクトを作成すると、Phoenixは自動的に ` .gitignore +`ファイルを生成します。必要なリンク:#step-6-%E2%80%94-configuring-edeliver-and-distillery [ステップ6] edeliverを使用してビルドサーバーにコード変更をプッシュするとき。

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

`+ myproject `プロジェクトは、プロダクションサーバー上で正しく機能するために ` prod.secret.exs +`を必要とし、Gitでそこに移動できないため、手動でサーバーに転送する必要があります。

本番サーバーのホームディレクトリで、 `+ app_config `という新しいディレクトリを作成します。 これは、 ` prod.secret.exs`を保存する場所です。

cd ~
mkdir app_config

ここで、 `+ scp `を使用して ` prod.secret.exs `を本番サーバーの ` app_config +`ディレクトリにコピーします。

scp ~/myproject/config/prod.secret.exs :/home//app_config/prod.secret.exs

最後に、本番サーバー上の `+ app_config +`の内容をリストして、転送が行われたことを確認します。

ls ~/app_config

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

本番サーバーに + prod.secret.exs +`があれば、ビルドプロセスにDistilleryをインストールし、 `+ myproject +のメイン設定ファイルである + mix.exs + `に両方を含めることで、展開用にedeliverを準備できます。 `プロジェクト。

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

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"}


   ]
 end
 ...

変更を保存して、「+ mix.exs +」を閉じます。

ここで、実行時に利用できるように、新しい依存関係を取得するように「+ mix +」に指示します。

cd ~/myproject/
mix deps.get

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

OutputResolving 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のサーバーを再起動して、現在の構成をテストします。

mix phx.server

ブラウザでhttp:// localhost:4000を指定します。 link:#step-4-%E2%80%94-creating-a-test-project [ステップ4]で見たものと同じデフォルトのPhoenixホームページが表示されるはずです。 そうでない場合は、前の手順を再度トレースし、追加情報についてローカル開発マシンの端末を確認します。

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

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

ステップ6-EdeliverとDistilleryの構成

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

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

cd ~/myproject
mix release.init

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

OutputAn 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 / `ディレクトリでリリースを検索しますが、Distilleryはデフォルトでリリースを ` _build `ディレクトリに配置します。 それでは、Distilleryのデフォルト設定ファイルである ` rel / config.exs +`を変更して、本番リリースを適切な場所に配置しましょう。

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

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[[email protected]=m`yBYVt4/`:"
end
...

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

ファイルを閉じます。

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

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

cd ~/myproject
mkdir .deliver
nano .deliver/config

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

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

deliver/config
APP=""

BUILD_HOST=""
BUILD_USER=""
BUILD_AT="/home//app_build"

PRODUCTION_HOSTS=""
PRODUCTION_USER=""
DELIVER_TO="/home//app_release"

次に、ビルドフォルダーに `+ prod.secret.exs `へのシンボリックリンクを作成します。このファイルは、リンクで本番サーバーの ` app_config `ディレクトリーに転送します:#step-5-%E2%80% 94使用するプロジェクトを設定して、蒸留器とエデリバーを使用します[ステップ5]。 このシンボリックリンクは、_edeliverフック_内に作成されます。 ビルド、ステージ、およびデプロイメントプロセスの各ポイントで、edeliverによって特定のフックが呼び出されます。 自動展開のセットアップでは、edeliverが依存関係を取得してコンパイルを開始する前に呼び出される ` pre_erlang_get_and_update_deps +`フックをリッスンしています。

次を「+ .deliver / config +」に追加します。

deliver/config
pre_erlang_get_and_update_deps() {
 local _prod_secret_path="/home//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リポジトリを作成します。

cd ~/myproject
git init

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

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

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

git add .

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

git config user.email ""
git config user.name ""

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

git commit -m "Setting up automated deployment"

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

Output[master (root-commit) e58b766] Setting up automated deployment
39 files changed, 2344 insertions(+)
create mode 100644 .deliver/config
...

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

手順7-プロジェクトの展開

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

`+ myproject +`プロジェクトをプロダクションサーバーにプッシュして、すべてをmyprojectにしましょう。

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

cd ~/myproject
mix edeliver build release

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

OutputBUILDING RELEASE OF MYPROJECT APP ON BUILD HOST

-----> Authorizing hosts
-----> Ensuring hosts are ready to accept git pushes
-----> Pushing new commits with git to:
-----> 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は問題が発生したときに実行しようとしていたコード行を示します。 その情報を使用して、問題のトラブルシューティングを行うことができます。

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

mix edeliver deploy release to production

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

OutputDEPLOYING 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 +`プロジェクトを開始します。

mix edeliver start production

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

OutputEDELIVER MYPROJECT WITH START COMMAND

-----> starting production servers

production node:

 user    :
 host    :
 path    : /home//app_release
 response:

START DONE!

ブラウザで「+ http://:4000+」を指定して、展開プロセスをテストします。 デフォルトのPhoenix Frameworkホームページが再び表示されるはずです。 そうでない場合は、実稼働サーバーでポート「4000」が開いていることを再確認し、追加情報についてローカル開発マシンの端末に問い合わせてください。

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

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

ビルドおよびデプロイメントプロセスの機能の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 +`を開きます。

nano ~/myproject/mix.exs

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

mix.exs

 ...
 def project do
   [app: :myproject,
    version: "0.0.1",
    elixir: "~> 1.2",
    elixirc_paths: elixirc_paths(Mix.env),
    compilers: [:phoenix, :gettext] ++ Mix.compilers,
    build_embedded: Mix.env == :prod,
    start_permanent: Mix.env == :prod,
    deps: deps()]
 end
 ...

バージョンを「0.0.1」から「0.0.2」に増やします。

mix.exs

 ...
 def project do
   [app: :myproject,
    version: "",
    elixir: "~> 1.2",
    elixirc_paths: elixirc_paths(Mix.env),
    compilers: [:phoenix, :gettext] ++ Mix.compilers,
    build_embedded: Mix.env == :prod,
    start_permanent: Mix.env == :prod,
    deps: deps()]
 end
 ...

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

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

git add .
git commit -m "Changed welcome message"

最後に、変更をホットスワップする準備ができました。 今回は、リンクで使用した3つの関連コマンド:#step-7-%E2%80%94-deploying-the-project [Step 7]に相当する単一のコマンドがあります。

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

mix edeliver upgrade production

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

OutputEDELIVER 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:
-----> 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://:4000 +`をリロードします。 新しいメッセージが表示されるはずです。 そうでない場合は、前の手順を再度トレースし、追加のエラーおよび警告メッセージがないか端末を確認します。

展開プロセスはたった1つのコマンドに削減され、Erlangの最も有名な機能の1つであるコードホットスワップも利用しています。 最後に、Nginxプロキシの背後に配置することにより、実稼働環境でアプリケーションを強化しましょう。

手順9-実稼働サーバーでのリバースプロキシのセットアップ

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

https://www.digitalocean.com/community/tutorials/how-to-set-up-let-s-encrypt-with-nginx-server-blocks-on-ubuntu-16-04 [セットアップ前提条件のUbuntu 16.04チュートリアルでNginxサーバーブロックを使用して暗号化しましょう]、プロジェクト用に本番サーバーに別のNginxサーバーブロックを作成しておく必要があります。

そのサーバーブロックの構成ファイルを編集用に開きます。

sudo nano /etc/nginx/sites-available/

まず、NginxにPhoenixプロジェクトの場所と、それがリッスンするポートを伝える必要があります。 ポート「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に指示する必要があります自体。

また、https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API [WebSockets]を介して着信リクエストを転送するようにNginxを構成します。これは、Webサーバーとクライアント間のメッセージ交換プロトコルです。永続的な接続への標準のステートレスHTTP接続。

フェニックスには、このチュートリアルでは取り上げなかったチャンネルという機能がありますが、チャンネルには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構成を確認します。

sudo nginx -t

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

Nginxを再起動して、変更を反映します。

sudo systemctl restart nginx

最後に、セキュリティのため、ポート `+ 4000 +`でHTTPを介したアプリケーションへのアクセスを許可しません。

sudo ufw delete allow 4000

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

sudo ufw status

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

OutputStatus: active

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

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

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

結論

edeliverをセットアップして、Phoenixプロジェクトを1つのコマンドで実稼働サーバーにビルドおよびデプロイしましたが、まだまだ多くのことができます。

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

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

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

これらのトピックのいずれかについて、または現在のedeliverインストール全般の拡張について詳しく知るには、プロジェクトのhttps://github.com/edeliver/edeliver[GitHubの公式ホーム]にアクセスしてください。