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

この記事では、Azure App Service を使用して Linux コンテナー内で Ruby アプリを実行する方法と、必要に応じて App Service の動作をカスタマイズする方法について説明します。This article describes how Azure App Service runs Ruby apps in a Linux container, and how you can customize the behavior of App Service when needed. Ruby アプリは、必要なすべての gems と共にデプロイする必要があります。Ruby apps must be deployed with all the required gems.

このガイドでは、App Service のビルトイン Linux コンテナーを使用する Ruby 開発者のために、主要な概念と手順を紹介します。This guide provides key concepts and instructions for Ruby developers who use a built-in Linux container in App Service. Azure App Service を使用したことがない場合は、まず Ruby 用のクイック スタートPostgreSQL を使った Ruby のチュートリアルに従ってください。If you've never used Azure App Service, you should follow the Ruby quickstart and Ruby with PostgreSQL tutorial first.

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

Ruby の現在のバージョンを表示するには、Cloud Shell で次のコマンドを実行します。To show the current Ruby version, run the following command in the Cloud Shell:

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

Ruby のサポートされているすべてのバージョンを表示するには、Cloud Shell で次のコマンドを実行します。To show all supported Ruby versions, run the following command in the Cloud Shell:

az webapp list-runtimes --linux | grep RUBY

サポートされないバージョンの Ruby を実行するには、代わりに独自のコンテナー イメージを作成します。You can run an unsupported version of Ruby by building your own container image instead. 詳細については、カスタム Docker イメージの使用に関するページを参照してください。For more information, see use a custom Docker image.

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

Ruby のバージョンを 2.3 に設定するには、Cloud Shell で次のコマンドを実行します。Run the following command in the Cloud Shell to set the Ruby version to 2.3:

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

注意

デプロイ中に次のようなエラーが表示されることがあります。If you see errors similar to the following during deployment time:

Your Ruby version is 2.3.3, but your Gemfile specified 2.3.1

oror

rbenv: version `2.3.1' is not installed

これは、プロジェクトに構成されている Ruby のバージョンが、実行中のコンテナーにインストールされているバージョン (上の例では 2.3.3) と異なることを意味します。It means that the Ruby version configured in your project is different than the version that's installed in the container you're running (2.3.3 in the example above). 上の例では、 Gemfile.ruby-version の両方をチェックし、Ruby のバージョンが未設定になっているか、または実行中のコンテナーにインストールされているバージョン (上の例では 2.3.3) に設定されていることを確認してください。In the example above, check both Gemfile and .ruby-version and verify that the Ruby version is not set, or is set to the version that's installed in the container you're running (2.3.3 in the example above).

環境変数へのアクセスAccess environment variables

App Service では、アプリ コードの外部でアプリ設定を指定できます。In App Service, you can set app settings outside of your app code. その後、標準の ENV['<path-name>'] パターンを使用して、それらにアクセスできます。Then you can access them using the standard ENV['<path-name>'] pattern. たとえば、WEBSITE_SITE_NAME というアプリ設定にアクセスするには、次のコードを使用します。For example, to access an app setting called WEBSITE_SITE_NAME, use the following code:

ENV['WEBSITE_SITE_NAME']

デプロイのカスタマイズCustomize deployment

Git リポジトリまたはビルド プロセスがオンになっている Zip パッケージをデプロイすると、デプロイ後にデプロイ エンジン (Kudu) によって既定で次のステップが自動的に実行されます。When you deploy a Git repository, or a Zip package with build processes switched on, the deployment engine (Kudu) automatically runs the following post-deployment steps by default:

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

--without フラグを使用するUse --without flag

--without フラグを使用して bundle install を実行するには、BUNDLE_WITHOUT アプリ設定に一連のグループをコンマ区切りで指定します。To run bundle install with the --without flag, set the BUNDLE_WITHOUT app setting to a comma-separated list of groups. たとえば、次のコマンドでは development,test に設定しています。For example, the following command sets it to 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 を使用して実行されます。If this setting is defined, then the deployment engine runs bundle install with --without $BUNDLE_WITHOUT.

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

既定では、デプロイ後のステップでアセットがプリコンパイルされることはありません。The post-deployment steps don't precompile assets by default. アセットのプリコンパイルを有効にするには、ASSETS_PRECOMPILE アプリ設定true に設定します。To turn on asset precompilation, set the ASSETS_PRECOMPILE app setting to true. これで、デプロイ後ステップの最後に bundle exec rake --trace assets:precompile コマンドが実行されます。Then the command bundle exec rake --trace assets:precompile is run at the end of the post-deployment steps. 次に例を示します。For example:

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

詳細については、「静的アセットを提供する」を参照してください。For more information, see Serve static assets.

スタートアップのカスタマイズCustomize start-up

既定では、Ruby コンテナーによって Rails サーバーが次の順序で起動されます (詳細については、スタートアップ スクリプトを参照してください)。By default, the Ruby container starts the Rails server in the following sequence (for more information, see the start-up script):

  1. secret_key_base の値がまだ存在しない場合は、この値を生成します。Generate a secret_key_base value, if one doesn't exist already. アプリを実稼働モードで実行するためには、この値が必要になります。This value is required for the app to run in production mode.
  2. RAILS_ENV 環境変数を production に設定します。Set the RAILS_ENV environment variable to production.
  3. これまでに Rails サーバーを実行したことで .pid ファイルが残っていれば tmp/pids ディレクトリからすべて削除します。Delete any .pid file in the tmp/pids directory that's left by a previously running Rails server.
  4. すべての依存関係がインストール済みであるかどうかを確認します。Check if all dependencies are installed. インストールされていない場合は、ローカル vendor/cache ディレクトリから gems をインストールします。If not, try installing gems from the local vendor/cache directory.
  5. rails server -e $RAILS_ENV を実行します。Run rails server -e $RAILS_ENV.

このスタートアップ プロセスは、次の方法でカスタマイズできます。You can customize the start-up process in the following ways:

静的アセットを提供するServe static assets

Ruby コンテナー内の Rails サーバーは、既定では実稼働モードで実行され、また、アセットがプリコンパイル済みで Web サーバーから提供されることを想定しています。The Rails server in the Ruby container runs in production mode by default, and assumes that assets are precompiled and are served by your web server. Rails サーバーから静的アセットを提供するには、次の 2 つのことを行う必要があります。To serve static assets from the Rails server, you need to do two things:

非実稼働モードで実行するRun in non-production mode

既定では、Rails サーバーが実稼働モードで実行されます。The Rails server runs in production mode by default. たとえば、開発モードで実行する場合は、RAILS_ENV アプリ設定development に設定することになります。To run in development mode, for example, set the RAILS_ENV app setting to development.

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

ただし、この設定だけを行った場合、Rails サーバーが開発モードで起動し、localhost 要求しか受け付けなくなるので、コンテナーの外部からアクセスすることができません。However, this setting alone causes the Rails server to start in development mode, which accepts localhost requests only and isn't accessible outside of the container. リモートのクライアント要求を受け付けるには、APP_COMMAND_LINE アプリ設定rails server -b 0.0.0.0 に設定してください。To accept remote client requests, set the APP_COMMAND_LINE app setting to rails server -b 0.0.0.0. このアプリ設定により、Ruby コンテナーでカスタム コマンドを実行することができます。This app setting lets you run a custom command in the Ruby container. 次に例を示します。For example:

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 を手動で設定するSet secret_key_base manually

secret_key_base の値を App Service で自動的に生成するのではなく独自の値を使用するには、SECRET_KEY_BASE アプリ設定にその値を設定します。To use your own secret_key_base value instead of letting App Service generate one for you, set the SECRET_KEY_BASE app setting with the value you want. 次に例を示します。For example:

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

診断ログにアクセスするAccess diagnostic logs

App Service のアプリケーション コード内から生成されたコンソール ログにアクセスするには、Cloud Shell で次のコマンドを実行して、診断ログを有効にします。To access the console logs generated from inside your application code in App Service, turn on diagnostics logging by running the following command in the Cloud Shell:

az webapp log config --resource-group <resource-group-name> --name <app-name> --application-logging true --level Verbose

--level で有効な値は、ErrorWarningInfo、および Verbose です。Possible values for --level are: Error, Warning, Info, and Verbose. 後続の各レベルには、前のレベルが含まれます。Each subsequent level includes the previous level. たとえば、Error にはエラー メッセージのみが含まれ、Verbose にはすべてのメッセージが含まれます。For example: Error includes only error messages, and Verbose includes all messages.

診断ログがオンになったら、次のコマンドを実行して、ログのストリームを確認します。Once diagnostic logging is turned on, run the following command to see the log stream:

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

コンソール ログがすぐに表示されない場合は、30 秒以内にもう一度確認します。If you don't see console logs immediately, check again in 30 seconds.

注意

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

任意のタイミングでログのストリーミングを停止するには、Ctrl+C と入力します。To stop log streaming at any time, type Ctrl+C.

ブラウザーで SSH セッションを開くOpen SSH session in browser

コンテナーとの直接 SSH セッションを開くには、アプリが実行されている必要があります。To make open a direct SSH session with your container, your app should be running.

ブラウザーに次の URL を貼り付け、<app-name> をお使いのアプリの名前に置き換えます。Paste the following URL into your browser and replace <app-name> with your app name:

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

まだ認証されていない場合、接続するには Azure サブスクリプションで認証する必要があります。If you're not yet authenticated, you're required to authenticate with your Azure subscription to connect. 認証されると、ブラウザー内シェルが表示され、コンテナー内でコマンドを実行することができます。Once authenticated, you see an in-browser shell, where you can run commands inside your container.

SSH 接続

注意

/home ディレクトリの外部で行ったすべての変更は、コンテナー自体に格納され、アプリの再起動後には保持されません。Any changes you make outside the /home directory are stored in the container itself and don't persist beyond an app restart.

ローカル コンピューターからリモート SSH セッションを開くには、「リモート シェルから SSH セッションを開く」を参照してください。To open a remote SSH session from your local machine, see Open SSH session from remote shell.

ログの robots933456robots933456 in logs

コンテナー ログで次のメッセージが表示されることがあります。You may see the following message in the container logs:

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

このメッセージは無視してかまいません。You can safely ignore this message. /robots933456.txt は、コンテナーが要求を処理できるかどうかを調べるために App Service が使用するダミーの URL パスです。/robots933456.txt is a dummy URL path that App Service uses to check if the container is capable of serving requests. 404 応答は、パスが存在しないことを示すだけですが、コンテナーが正常であり、要求に応答できる状態であることを App Service に知らせます。A 404 response simply indicates that the path doesn't exist, but it lets App Service know that the container is healthy and ready to respond to requests.

次のステップNext steps