DOnations]プログラムの一環として300ドルの寄付を受け取りました。[edeliver]を使用して運用サーバーに展開しました。ほとんどの実際のアプリケーションでは、展開プロセスにいくつかの変更が必要なデータベースが必要です。edeliverを使用して、アプリケーションとデータベースの変更を運用サーバーに同時にプッシュできるため、展開中にデータベースの変更を管理できます。[Phoenix-Ecto]およびhttps://github.com/xerions/mariaex[Mariaex]を使用して、MySQLデータベースに接続するように既存のPhoenixアプリケーションを構成します。Ectoは、Phoenixアプリケーションで広く使用されているデータベースラッパーです。Mariaexは、Ectoと統合し、MySQLおよびMariaDBデータベースと通信するデータベースドライバーです。データベースを使用する開発マシンで簡単なアドレス帳を作成し、edeliverを使用して運用サーバーに変更を展開します。サイトのユーザーは、このアドレス帳のエントリを作成、読み取り、更新、および削除できます。前提条件このチュートリアルを完了するには、次のものが必要です。Phoenixの展開を自動化する]。Encrypt証明書を使用してNginxの背後で実行され、edeliverで展開される必要があります。16.04にMySQLをインストールする方法に従ってサーバーにインストールされたMySQL。展開する前にデータベースをテストするために、ローカル開発マシンにインストールされたMySQL。ステップ1-MariaexとEctoをアプリケーションに追加する通常、Phoenixアプリケーションはデータベースへの接続を直接確立せず、SQLクエリを実行しません。wrapper_を使用してデータベースを照会します。データベースドライバーは、接続の確立、接続の終了、クエリの実行など、データベースを使用する日常的なタスクを処理するElixirアプリケーションです。データベースラッパーは、ElixirプログラマーがElixirコードを使用してデータベースクエリを作成できるようにするデータベースドライバー上のレイヤーであり、クエリ構成(クエリのチェーン)などの追加機能を提供します。この分離により、モジュラーアプリケーションが実現します。データベースラッパー、したがってデータベースと対話するアプリケーションコードは、使用するデータベースに関係なくほぼ同じです。データベースドライバーを変更するだけで、Phoenixアプリケーションは別のデータベースソフトウェアを使用できます。[前のチュートリアル]、アプリケーションにはEctoもMariaexもインストールされていません。ここで、プロジェクトの依存関係としてEctoとMariaexを追加します。フェニックスプロジェクトを含むディレクトリに切り替えます。+`ファイルを開きます。mix.exs次のコードブロックを見つけます。endMariaexとPhoenix-Ectoを依存関係として追加します。+`を保存して閉じます。次に、次のコマンドを実行して、プロジェクトに追加したばかりの依存関係をダウンロードします。deps.get依存関係がインストールされると、次の出力が表示されます。package...出力は、Mixがパッケージ間の互換性をチェックし、Hexリポジトリからパッケージとその依存関係を取得したことを示しています。+`が正しく変更されていることを確認してください。EctoとMariaexを配置すると、Ectoリポジトリをセットアップできます。手順2-アプリケーションでのEctoリポジトリのセットアップPhoenixアプリケーションは、Ectoと呼ばれるデータベースラッパーを介してデータベースにアクセスします。データベースラッパーは、プロジェクトのElixirモジュールの形式で実装されます。データベースと対話し、モジュールが提供する機能を使用する必要があるときはいつでも、このモジュールをインポートできます。ラップされたデータベースは、_repository_と呼ばれます。`マクロを含める必要があります。+`という名前の関数でデータベースアダプターに渡されるオプションを初期化するコードを含める必要があります。+`フラグを使用していなかった場合、Phoenixはこのモジュールを自動的に生成していました。作成したので、自分で作成する必要があります。+`という名前のファイルにモジュールを作成しましょう。最初にファイルを作成します。lib//repo.ex次のコードをファイルに追加して、リポジトリを定義します。+`関数を定義します(このチュートリアルで後述するように)。+`を保存して閉じます。Phoenixプロジェクトは、同時実行性とフォールトトレランスのために軽量のElixirプロセスを使用します。_Supervisors_は、クラッシュした場合にこれらのプロセスを管理して再起動します。スーパーバイザーは他のスーパーバイザーを監督することもでき、この構造は「スーパービジョンツリー」と呼ばれます。+`モジュールは、データベースに接続するプロセスを管理するスーパーバイザーを実装します。このスーパーバイザーを開始するには、プロジェクトの監視ツリーに追加する必要があります。+`ファイルを開きます。lib//application.ex監視ツリーを定義する次のコードブロックを見つけます。`がスーパーバイザーとして開始されていることがわかります。]この手順をスキップすると、Ectoはデータベースと対話するプロセスを作成せず、データベースと対話しようとするとアプリケーションがクラッシュします。+`を保存して閉じます。+`などのMixタスクを使用してデータベースを作成および管理できるようにします。+`で設定ファイルを開きます。config/config.exsファイルの最後で次の行を見つけます。+`の設定を上書きできます。その行の上に次のコードを追加して、Ectoリポジトリを構成します。[.Repo]...変更を保存してファイルを閉じます。Ectoを構成したので、次にデータベース資格情報をアプリケーションに追加します。手順3-MySQL資格情報を使用したアプリケーションの構成アプリケーションがデータベースに接続する状況は、開発中、テスト中、本番中の3つです。同様に、Phoenixは、アプリケーションが実行されている環境に関連する資格情報を含む3つの環境固有の構成ファイルを提供します。+」ディレクトリにあります。この手順では、これら3つのファイルを変更します。開発環境を設定しましょう。+`に設定するには、次の行を追加します。adapter:次に、同じコードブロックでデータベースの目的の名前を指定します。これは、Phoenixアプリがデータベースに使用する命名規則です。代わりに独自の命名スキームを使用できます。次に、開発データベースサーバーのホスト名、ユーザー名、およびパスワードを指定します。"myproject_dev"最後に、プールサイズを適切な数値に設定します。プールサイズは、アプリケーションが保持できるデータベースへの接続の最大数です。これらの接続はリクエスト間で共有されます。最適なサイズはハードウェアによって異なりますが、開始するには「10」を使用できます。+`を保存して閉じます。次に、テスト環境を構成します。config/test.exsこのチュートリアルでは、開発用データベースと一緒にローカルデータベースサーバーでテストデータベースをホストします。そのため、テストデータベースの構成はほぼ同じです。これにより、サンドボックスモードでテストが実行されます。テスト中にテストデータベースで行われたトランザクションはすべてロールバックされます。これは、各テスト後にデータベースが初期状態にリセットされるため、ユニットテストをランダムな順序で実行できることを意味します。+`を保存して閉じます。`ファイルに追加します。+`を使用していることに注意してください。ここで指定したパスワードを使用して、本番データベースサーバー上でこのユーザーをすぐに作成します。ここでは、より安全なパスワードを使用する必要があります。10変更を保存してファイルを閉じます。このファイルはセキュリティ上の理由からGitによって追跡されないため、手動でサーバーに転送する必要があります。このプロセスの詳細については、前提条件https://www.digitalocean.com/community/tutorials/how-to-automate-elixir-phoenix-deployment-with-distillery-and-edeliver-on-ubuntuのステップ3を参照してください。[Phoenixアプリケーションのデプロイに関するチュートリアル]。Mixタスクを呼び出して、開発データベースを作成します。テストを実行するときにPhoenixが自動的に行うので、テストデータベースを作成する必要はありません。ecto.createEctoがデータベースを正常に作成したことを示す次の出力が表示されます。createdこの出力が表示されない場合は、設定の詳細が正しいことと、MySQLが実行されていることを確認してください。エラーのためにアプリケーションがコンパイルに失敗した場合、Ectoはデータベースの作成を拒否します。データベースに接続するようにプロジェクトを設定し、開発マシンでEctoを使用してデータベースを作成したので、サーバー上のデータベースの変更に進むことができます。Mixタスクを使用して、開発マシンに空のデータベースを作成しました。これで、実稼働サーバーでも同じことができます。残念ながら、これを実現するためのMixタスクやedeliverコマンドはありません。したがって、手動でサーバーにログインし、MySQLコンソールを使用してSQLコマンドで空のデータベースを作成します。SSH経由でサーバーに接続します。*ユーザーと設定したパスワードを使用してMySQLコンソールにアクセスします。-pログインしたら、本番データベースを作成します。;次の出力が表示され、データベースが作成されたことがわかります。*と前の手順で指定したパスワードを使用して、アプリのユーザーを作成します。*ユーザーアクセスを許可します。''@'localhost';最後に、許可の変更を適用します。」と入力して、MySQLコンソールを終了します。+」と入力して、SSH接続を終了します。これからは、ローカルマシンからのテーブルの作成や変更など、ほぼすべての操作を実行するため、本番データベースに触れる必要はほとんどありません。本番データベースの準備ができたら、アプリケーションをサーバーに再デプロイできます。手順5-サーバーへのプロジェクトの展開この手順では、データベースに接続していない実行中のアプリケーションを、新しく構成したアプリケーションとその新しいEctoリポジトリに置き換えます。この手順により、アプリケーションが正しく構成され、期待どおりに実行されることを確認できます。+`を開き、アプリケーションのバージョンを増やします。バージョン番号を使用すると、リリースを簡単に追跡し、必要に応じて以前のバージョンにロールバックできます。edeliverがダウンタイムなしでアプリケーションをアップグレードするために使用します。mix.exsバージョンフィールドを適切な値に増やします。endedeliverを使用してデータベースの移行を実行するには、edeliverがプロジェクト内で最後に起動するアプリケーションである必要があります。次のコードブロックを見つけます。+`を保存して閉じます。アプリケーションを起動して、すべてが機能し、コンパイルエラーがないことを確認します。addresses]にアクセスして、アプリが引き続き機能することを確認します。開始しない場合、またはコンパイルエラーが表示される場合は、先に進む前にこのチュートリアルの手順を確認し、解決してください。+」を2回押してサーバーを停止します。次に、Gitで変更をコミットします。edeliverはGitを使用してコードを最新のコミットからビルドサーバーにプッシュし、さらにアクションを実行するため、プロジェクトを変更するたびにこれを行う必要があります。database"最後に、edeliverを使用して、運用サーバー上のアプリケーションを更新します。次のコマンドは、ダウンタイムなしで運用マシンで実行されているアプリケーションをアップグレードする前に、プロジェクトの最新バージョンをビルドおよびデプロイします。production次の出力が表示されます。DONE!アップグレードは正常に完了しましたが、アプリケーションを再起動するまでデータベース関連のedeliverタスクを実行できません。production次の出力が表示されます。DONE!edeliverは、運用サーバーを正常に再起動したことを示しています。アプリケーションがアップグレードされたことを確認するには、次のedeliverコマンドを実行して、現在運用環境で実行されているアプリケーションのバージョンを取得します。`++`を実行していることを示しています。+`でアプリケーションにアクセスして、実行されていることを確認することもできます。アプリケーションのコード自体には手を加えていないため、アプリケーションに目に見える変更はありません。アップグレードは成功したが、アプリケーションの更新に失敗した場合は、コードをコミットし、アプリケーションのバージョンを上げたことを確認してください。アップグレードコマンドが失敗した場合、edeliverは、エラーが発生したときにサーバーで実行していたbashコードとエラーメッセージ自体を出力します。これらの手がかりを使用して問題を解決できます。データベースサポートをアプリに追加し、運用環境に展開したので、MySQLを使用する機能を追加する準備が整いました。ステップ6-アドレス帳の作成データベースの変更を展開する方法を示すために、アプリケーションに簡単なアドレス帳を作成し、運用環境に展開してみましょう。generators]を使用してアドレス帳を作成します。Phoenixジェネレーターは、単純なCRUD(作成、読み取り、更新、削除)機能のコードを生成するユーティリティです。これは、構築する可能性のある多くのアプリケーション機能の適切な出発点となります。アドレス帳には、エントリを保存するためのデータベース内のテーブルも必要です。このテーブルをデータベースに追加するには、SQLクエリを作成して実行できますが、代わりにEctoの移行機能を使用してデータベースを変更します。このアプローチにはいくつかの利点があります。データベースに依存しません。PostgreSQL、MySQL、またはその他のデータベースを使用している場合でも、コマンドは同じです。次に、移行ファイルは、データベーススキーマが時間とともにどのように変化したかを追跡する便利な方法を提供します。最後に、必要に応じて、開発マシンで最新の移行をロールバックすることもできます。ありがたいことに、Phoenixジェネレーターは、特に指定がない限り、移行ファイルを作成するため、移行ファイルを最初から作成する必要はありません。ジェネレーターを使用するには、コンテキスト、エンティティの単数名、エンティティの複数名、および他のすべてのフィールドをそれぞれのタイプで指定します。*は、関連リソースの機能を含むモジュールです。サイトにサインアップしたユーザーのリストとユーザーのサインイン時にセッションのログを保持することを計画している場合、ユーザーとセッションを「アカウント」という名前の単一のコンテキストモジュールの下に置くことは理にかなっています。慣例により、Phoenixはエンティティの複数名がそのリソースのデータベーステーブルの名前であると想定していることに注意してください。ジェネレータでアドレス帳を作成しましょう。アドレス帳をシンプルにするために、各レコードに名前、メール、郵便番号の3つのフィールドのみを含めます。次のコマンドを実行して、アドレス帳を生成します。ecto.migratePhoenixは、テンプレートファイル、テストファイル、モデル、コントローラー、移行ファイルを自動的に生成したことを教えてくれます。ルーターファイルにリソースを追加し、リポジトリを更新するよう指示します。出力に表示される指示に従うこともできますが、そうすることで、アプリケーションコードのアップグレードとデータベースの移行を単一のリリースにバンドルします。これにより、アプリケーションが運用サーバーに展開されてから運用データベースが移行されるまで、アプリケーションの特定の部分が運用で失敗する可能性があります。この間隔の間、アプリケーションコードは、データベース内に存在しないテーブルまたは列を参照している可能性があります。ダウンタイムとエラーを防ぐには、次の2つの手順で変更を展開します。アプリケーションコードを変更せずに、データベースに必要な変更を加えたデータベース移行ファイルを追加します。リリースを作成し、運用サーバーをアップグレードして、運用データベースを移行します。アプリケーションコードを変更してから、別のリリースを作成してデプロイします。この方法を使用しない場合、アドレス帳のコードはまだ作成していないアドレステーブルを参照しようとし、アプリケーションがクラッシュします。本番データベースを移行する前に、移行ファイルを見てみましょう。エディターでファイルを開きます。+」と呼ばれる単一の機能を持つElixirモジュールです。後で移行を実行すると、この関数が呼び出されます。`テーブルを作成するコードを記述しました。timestamps()+」関数も含まれています。これらのフィールドに保存されている値は、データを挿入または更新すると自動的に更新されます。変更を加えずにファイルを閉じます。必要なのは生成されたコードだけです。アプリケーションコードを含めずに移行ファイルのみをデプロイするには、edeliverがGitを使用してプロジェクトをビルドサーバーに転送するという事実を利用します。具体的には、生成された残りのファイルを追跡せずに、移行ファイルをステージングしてコミットします。+`でアプリケーションのバージョンを増やしてください。Edeliverは、ホットアップグレードの準備にバージョン番号を使用するため、更新ごとにバージョン番号を増やす必要があります。mix.exsアプリケーションのバージョンを適切な値に増やします。...ファイルを保存して閉じます。+`ファイルと移行ファイルの両方をステージングします。priv/repo/migrations/*_create_addresses.exs次に、ステージングされたファイルをコミットします。database"それで、edeliverを使用して運用アプリケーションをアップグレードします。productionアップグレードが完了したら、次のedeliverコマンドを実行して、運用データベースを移行します。production出力には、移行が正常に実行されたことが示され、移行ファイルのタイムスタンプが示されます。+`という名前の空のテーブルがあります。この場合、再度アップグレードする前に、Gitを使用してコードをコミットしたことを確認してください。+」と入力して本番アプリケーションを再起動し、データベース移行タスクを再度実行します。+`テーブルを用意したら、アドレス帳を生成して新しいリリースを作成するときにPhoenixが発行した指示に従うことができます。lib/myproject_web/router.ex次のコードブロックを見つけます。+`を保存して閉じます。次に、Ectoにローカルデータベースを変更するよう依頼します。+`が正常に作成されたことを示しています。0.0s次に、ローカル開発サーバーを起動して、新しい機能をテストします。addressesにアクセスして、動作中の新しい機能を確認します。+`を2回押してサーバーを終了します。作業が完了したので、変更を本番にデプロイできます。mix.exsバージョンフィールドを適切な値に増やします。+`を保存して閉じます。Gitで変更をコミットします。今回は、すべてのファイルをステージングします。book"edeliverを使用して実稼働アプリケーションをアップグレードします。+」で新しい機能にアクセスできます。これで、本番アプリケーションとデータベースが正常にアップグレードされました。結論この記事では、MySQLデータベースを使用するようにPhoenixアプリケーションを構成し、edeliverとEctoの移行を使用して本番データベースに変更を加えました。この方法を使用すると、本番データベースに触れる必要がなく、本番データベースに加えたい変更はすべてEcto移行ファイルを介して行われます。これにより、時間の経過に伴うデータベースへの変更のロールバックと変更の追跡が容易になります。[Ectoの公式移行ドキュメント]を参照してください。