Azure App Service 向けの Linux Ruby アプリを構成する

この記事では、Azure App Service を使用して Linux コンテナー内で Ruby アプリを実行する方法と、必要に応じて App Service の動作をカスタマイズする方法について説明します。 Ruby アプリは、必要なすべての gems と共にデプロイする必要があります。

このガイドでは、App Service のビルトイン Linux コンテナーを使用する Ruby 開発者のために、主要な概念と手順を紹介します。 Azure App Service を使用したことがない場合は、まず Ruby 用のクイック スタートPostgreSQL を使った Ruby のチュートリアルに従ってください。

Ruby のバージョンを表示する

Ruby の現在のバージョンを表示するには、Cloud Shell で次のコマンドを実行します。

az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion

Ruby のサポートされているすべてのバージョンを表示するには、Cloud Shell で次のコマンドを実行します。

az webapp list-runtimes --linux | grep RUBY

サポートされないバージョンの Ruby を実行するには、代わりに独自のコンテナー イメージを作成します。 詳細については、カスタム Docker イメージの使用に関するページを参照してください。

Ruby のバージョンを設定する

Ruby のバージョンを 2.3 に設定するには、Cloud Shell で次のコマンドを実行します。

az webapp config set --resource-group <resource-group-name> --name <app-name> --linux-fx-version "RUBY|2.3"

注意

デプロイ中に次のようなエラーが表示されることがあります。

Your Ruby version is 2.3.3, but your Gemfile specified 2.3.1

or

rbenv: version `2.3.1' is not installed

これは、プロジェクトに構成されている Ruby のバージョンが、実行中のコンテナーにインストールされているバージョン (上の例では 2.3.3) と異なることを意味します。 上の例では、Gemfile.ruby-version の両方をチェックし、Ruby のバージョンが未設定になっているか、または実行中のコンテナーにインストールされているバージョン (上の例では 2.3.3) に設定されていることを確認してください。

環境変数へのアクセス

App Service では、アプリ コードの外部でアプリ設定を指定できます。 その後、標準の ENV['<path-name>'] パターンを使用して、それらにアクセスできます。 たとえば、WEBSITE_SITE_NAME というアプリ設定にアクセスするには、次のコードを使用します。

ENV['WEBSITE_SITE_NAME']

デプロイのカスタマイズ

Git リポジトリまたはビルド オートメーションが有効になっている Zip パッケージをデプロイすると、デプロイ後にデプロイ エンジン (Kudu) によって既定で次のステップが自動的に実行されます。

  1. Gemfile が存在するかどうかを確認します。
  2. bundle clean を実行します。
  3. bundle install --path "vendor/bundle" を実行します。
  4. bundle package を実行して、vendor/cache フォルダーに gems をパッケージします。

--without フラグを使用する

--without フラグを使用して bundle install を実行するには、BUNDLE_WITHOUT アプリ設定に一連のグループをコンマ区切りで指定します。 たとえば、次のコマンドでは development,test に設定しています。

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings BUNDLE_WITHOUT="development,test"

この設定が定義されている場合、bundle install は、デプロイ エンジンによって --without $BUNDLE_WITHOUT を使用して実行されます。

アセットをプリコンパイルする

既定では、デプロイ後のステップでアセットがプリコンパイルされることはありません。 アセットのプリコンパイルを有効にするには、ASSETS_PRECOMPILE アプリ設定true に設定します。 これで、デプロイ後ステップの最後に bundle exec rake --trace assets:precompile コマンドが実行されます。 次に例を示します。

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings ASSETS_PRECOMPILE=true

詳細については、「静的アセットを提供する」を参照してください。

スタートアップのカスタマイズ

既定では、Ruby コンテナーによって Rails サーバーが次の順序で起動されます (詳細については、スタートアップ スクリプトを参照してください)。

  1. secret_key_base の値がまだ存在しない場合は、この値を生成します。 アプリを実稼働モードで実行するためには、この値が必要になります。
  2. RAILS_ENV 環境変数を production に設定します。
  3. これまでに Rails サーバーを実行したことで .pid ファイルが残っていれば tmp/pids ディレクトリからすべて削除します。
  4. すべての依存関係がインストール済みであるかどうかを確認します。 インストールされていない場合は、ローカル vendor/cache ディレクトリから gems をインストールします。
  5. rails server -e $RAILS_ENV を実行します。

このスタートアップ プロセスは、次の方法でカスタマイズできます。

静的アセットを提供する

Ruby コンテナー内の Rails サーバーは、既定では実稼働モードで実行され、また、アセットがプリコンパイル済みで Web サーバーから提供されることを想定しています。 Rails サーバーから静的アセットを提供するには、次の 2 つのことを行う必要があります。

非実稼働モードで実行する

既定では、Rails サーバーが実稼働モードで実行されます。 たとえば、開発モードで実行する場合は、RAILS_ENV アプリ設定development に設定することになります。

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings RAILS_ENV="development"

ただし、この設定だけを行った場合、Rails サーバーが開発モードで起動し、localhost 要求しか受け付けなくなるので、コンテナーの外部からアクセスすることができません。 リモートのクライアント要求を受け付けるには、APP_COMMAND_LINE アプリ設定rails server -b 0.0.0.0 に設定してください。 このアプリ設定により、Ruby コンテナーでカスタム コマンドを実行することができます。 次に例を示します。

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings APP_COMMAND_LINE="rails server -b 0.0.0.0"

secret_key_base を手動で設定する

secret_key_base の値を App Service で自動的に生成するのではなく独自の値を使用するには、SECRET_KEY_BASE アプリ設定にその値を設定します。 次に例を示します。

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings SECRET_KEY_BASE="<key-base-value>"

診断ログにアクセスする

App Service のアプリケーション コード内から生成されたコンソール ログにアクセスするには、Cloud Shell で次のコマンドを実行して、診断ログを有効にします。

az webapp log config --resource-group <resource-group-name> --name <app-name> --docker-container-logging filesystem --level Verbose

--level で有効な値は、ErrorWarningInfo、および Verbose です。 後続の各レベルには、前のレベルが含まれます。 たとえば、Error にはエラー メッセージのみが含まれ、Verbose にはすべてのメッセージが含まれます。

診断ログがオンになったら、次のコマンドを実行して、ログのストリームを確認します。

az webapp log tail --resource-group <resource-group-name> --name <app-name>

コンソール ログがすぐに表示されない場合は、30 秒以内にもう一度確認します。

注意

https://<app-name>.scm.azurewebsites.net/api/logs/docker で、ブラウザーからログ ファイルを検査することもできます。

任意のタイミングでログのストリーミングを停止するには、Ctrl+C と入力します。

ブラウザーで SSH セッションを開く

コンテナーとの直接 SSH セッションを開くには、アプリが実行されている必要があります。

ブラウザーに次の URL を貼り付け、<app-name> をお使いのアプリの名前に置き換えます。

https://<app-name>.scm.azurewebsites.net/webssh/host

まだ認証されていない場合、接続するには Azure サブスクリプションで認証する必要があります。 認証されると、ブラウザー内シェルが表示され、コンテナー内でコマンドを実行することができます。

SSH 接続

注意

/home ディレクトリの外部で行ったすべての変更は、コンテナー自体に格納され、アプリの再起動後には保持されません。

ローカル コンピューターからリモート SSH セッションを開くには、「リモート シェルから SSH セッションを開く」を参照してください。

ログの robots933456

コンテナー ログで次のメッセージが表示されることがあります。

2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"

このメッセージは無視してかまいません。 /robots933456.txt は、コンテナーが要求を処理できるかどうかを調べるために App Service が使用するダミーの URL パスです。 404 応答は、パスが存在しないことを示すだけですが、コンテナーが正常であり、要求に応答できる状態であることを App Service に知らせます。

その他のリソース