Ubuntu16.04で蒸留所とedeliverを使用してElixir-Phoenixのデプロイを自動化する方法
序章
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をテストするために使用するポートです。
- 私たちの目標は展開プロセスを自動化することなので、セットアップチュートリアルのステップ4に従うときは、SSHパスフレーズを入力しないでください。 さらに、セットアップチュートリアルのステップ7で、コマンド
- このUbuntu16.04ガイドにNginxをインストールする方法に従ってNginxを本番サーバーにインストールします。
- 完全に登録されたドメイン名。 このチュートリアルでは、全体を通して
example.com
を使用します。 Namecheap でドメイン名を購入するか、 Freenom で無料でドメイン名を取得するか、選択したドメイン登録事業者を使用できます。 - 次の両方のDNSレコードがサーバー用に設定されています。 それらを追加する方法の詳細については、このホスト名チュートリアルに従うことができます。
- サーバーのパブリックIPアドレスを指す
example.com
のAレコード。 - サーバーのパブリックIPアドレスを指す
www.example.com
のAレコード。
- サーバーのパブリックIPアドレスを指す
- この設定に従って、SSL証明書で保護されたNginxは、Ubuntu16.04チュートリアルでNginxサーバーブロックを使用して暗号化します。 Nginxセットアップチュートリアルのステップ4でオプション2
Redirect
を選択してください。これにより、このチュートリアルで作成している本番サーバー上のHTTPSへの自動リダイレクトが提供されます。
ステップ1—ローカル開発マシンへのElixirとPhoenixのインストール
ElixirはErlangVMで実行されるため、Elixir自体をインストールする前にVMをインストールする必要があります。 また、Erlangの最新の安定バージョンを使用していることを確認したいので、ErlangソリューションリポジトリからErlangをインストールします。
まず、ErlangSolutionsリポジトリをダウンロードしてローカル開発マシンに追加します。
cd ~ wget https://packages.erlang-solutions.com/erlang-solutions_1.0_all.deb sudo dpkg -i erlang-solutions_1.0_all.deb
次に、パッケージリストを更新し、esl-erlang
パッケージをインストールします。このパッケージは、Erlangプログラミング言語と、Erlang / OTPプラットフォームと総称される便利なツール、ライブラリ、ミドルウェアの両方を提供します。
sudo apt-get update sudo apt-get install esl-erlang
次に、Elixirをインストールします。
sudo apt-get install elixir
次に、Mix(Elixirプロジェクトを作成して依存関係を管理するためのElixirにバンドルされているビルドツール)を使用して、Elixir独自のパッケージマネージャー Hex をインストールします。これは、後でPhoenixをインストールするために使用します。
このコマンドの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] Y * 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] Y * creating .mix/archives/phx_new-1.3.0
警告: phx_new.ez
アーカイブからPhoenixをインストールすると、このチュートリアルで使用しているものとは異なる可能性のある最新バージョンのPhoenixを入手できます—1.3.0。 次に、このチュートリアルを使用しているフェニックスのバージョンに適合させる必要があります。
ElixirとPhoenixをローカル開発マシンにインストールしたら、必要な部分を本番サーバーにインストールしましょう。
ステップ2—本番サーバーへのElixirとPhoenixのインストール
フェニックスプロジェクトをローカル開発マシンと本番サーバーの両方で実行する必要があるため、両方の場所に同じ言語とツールをすべてインストールする必要があります。
ステップ1と同じコマンドを使用して、ErlangSolutionsリポジトリをダウンロードして本番サーバーに追加します。
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] Y * creating .mix/archives/hex-0.17.1
これで、ローカル開発マシンと本番サーバーの両方でPhoenixを実行する準備が整いましたが、SSHホストエイリアスを設定して、ローカル開発マシンから本番サーバーに簡単に接続できるようにしましょう。
ステップ3—SSHホストエイリアスを設定する
私たちの目標は完全に自動化された展開プロセスであるため、本番サーバーの初期セットアップ中に、パスフレーズの入力を求めないSSHキーペアを生成しました。
現在、コマンドssh -i ~/.ssh/private_key_file [email protected]
を使用して、ローカル開発マシンから本番サーバーに接続できます。
ここでは、ユーザーsammyとしてexample.com
に接続しています。 -i
フラグは、SSHに~/.ssh/private_key_file
にある秘密鍵ファイルを接続に使用するように指示します。
ただし、本番サーバーに接続するときに使用する秘密鍵、ユーザー、およびドメインを自動的に認識するSSHホストエイリアスを設定することで、このコマンド(および展開プロセス自体)をさらに簡単にすることができます。
ローカル開発マシンで~/.ssh/config
を開いて編集します。
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に使用する秘密鍵ファイルを通知します。
変更を保存してファイルを閉じます。
最後に、運用サーバーに接続して構成をテストします。
ssh example.com
ユーザー、秘密鍵ファイル、またはドメインを指定しなくても接続できるはずです。 接続できなかった場合は、画面上のメッセージに従い、前の手順に戻って問題を解決してください。
本番サーバーへの接続が簡略化されたので、デプロイ用のサンプルのPhoenixプロジェクトを作成できます。
ステップ4—テストプロジェクトの作成
デフォルトでは、新しいPhoenixプロジェクトを作成すると、PostgreSQLデータベースアダプターとBrunch、JavaScriptベースのWebアプリケーションビルドツールで構成されます。 この追加の複雑さを回避するために、--no-ecto
フラグと--no-brunch
フラグをそれぞれ渡すことにより、データベースアダプターなしとブランチなしのmyproject
という名前の単純なPhoenixプロジェクトを作成します。
ホームディレクトリに移動して、新しいプロジェクトを作成します。
cd ~ 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
コマンドを実行してプロジェクトをコンパイルし、サーバーを起動します。
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] 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
を開いて編集します。
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
を保存します。
cd ~ mkdir app_config
次に、scp
を使用して、prod.secret.exs
を運用サーバーのapp_config
ディレクトリにコピーします。
scp ~/myproject/config/prod.secret.exs example.com:/home/sammy/app_config/prod.secret.exs
最後に、本番サーバーにapp_config
の内容を一覧表示して、転送が行われたことを確認します。
ls ~/app_config
出力にprod.secret.exs
が表示されない場合は、ローカル開発マシンの端末で追加情報を確認してください。
prod.secret.exs
を本番サーバーにインストールすると、ビルドプロセス用にDistilleryをインストールし、myproject
のメイン構成ファイルであるmix.exs
に両方を含めることで展開用に配信する準備が整います。 ] 事業。
ローカル開発マシンで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"}, {:edeliver, "~> 1.4.3"}, {:distillery, "~> 1.4"} ] end ...
注:潜在的な構成の問題を回避するために、新しいedeliver
エントリの前の行の最後に、が追加されていることを再確認してください。
変更を保存して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を指定します。 ステップ4で表示したものと同じデフォルトのPhoenixホームページが表示されます。 そうでない場合は、前の手順を再度トレースし、ローカル開発マシンの端末で追加情報を確認してください。
続行する準備ができたら、CTRL+C
を2回押してサーバーを停止し、次のステップでさらに構成できるようにします。
Distilleryとedeliverがインストールされたら、展開用に構成する準備が整いました。
ステップ6—Edeliverと蒸留所の構成
蒸留所には、デフォルトでは生成されないビルド構成ファイルが必要です。 ただし、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/myproject
ディレクトリでリリースを検索しますが、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[X@sqG=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="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リポジトリを作成します。
cd ~/myproject git init
ファイルをGitインデックスに追加する前に、リリースtarballを含むディレクトリも.gitignore
ファイルに追加する必要があります。 そうしないと、Gitリポジトリのサイズが数回のリリース後に非常に大きくなります。
echo ".deliver/releases/" >> .gitignore
次に、myproject
プロジェクトのファイルの完全なセットをGitステージング領域に追加して、次のコミットに含まれるようにします。
git add .
次に、Gitがこのリポジトリに関連付ける必要があるIDを設定します。 これは、プロジェクトへの変更がどこから来たのかを追跡するのに役立ちます。
git config user.email "[email protected]" git config user.name "Your 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と蒸留所にコミットされ、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: [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は、問題が発生したときに実行しようとしたコード行を示します。 その情報を使用して、問題のトラブルシューティングを行うことができます。
ビルドが完了したら、リリースを本番サーバーに転送します。
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 : sammy host : example.com path : /home/sammy/app_release response: START DONE!
ブラウザでhttp://example.com:4000
を指定して、展開プロセスをテストします。 デフォルトのPhoenixFrameworkホームページがもう一度表示されます。 そうでない場合は、本番サーバーでポート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: "0.0.2", 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"
最後に、変更をホットスワップする準備が整いました。 今回は、ステップ7で使用した3つの関連コマンドと同等の1つのコマンドがあります。
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: [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サーバーブロックを作成しておく必要があります。
そのサーバーブロックの構成ファイルを開いて編集します。
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構成を確認します。
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://example.com
を指定して、すべてが機能していることをテストします。
これで、完全に自動化されたビルドとデプロイのプロセスと、リバースプロキシとSSL証明書の両方で保護された運用サーバーができました。
結論
1つのコマンドでPhoenixプロジェクトをビルドして本番サーバーにデプロイするようにedeliverをセットアップしましたが、まだまだできることがたくさんあります。
ほとんどの本番Phoenixアプリケーションはデータベースを使用します。 Ubuntu 16.04でMySQLを使用してElixir-Phoenixアプリケーションをデプロイする方法では、MySQLデータベースを追加し、新しい機能を本番環境にデプロイするときに、このアプリケーションの操作を続行します。
本番インフラストラクチャがPhoenixノードのクラスターで構成されている場合は、edeliverを使用して、すべてのノードに一度にデプロイしてホットスワップを実行できます。
または、より信頼性の高いセットアップが必要な場合は、本格的なステージングインフラストラクチャを作成し、edeliverを使用してステージングと展開のプロセスを管理できます。
これらのトピックのいずれかについて、または現在のedeliverのインストールを一般的に拡張する方法について詳しくは、プロジェクトのGitHubの公式ホームにアクセスしてください。