Configure a Linux Ruby app for Azure 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 apps must be deployed with all the required gems.

This guide provides key concepts and instructions for Ruby developers who use a built-in Linux container in App Service. If you've never used Azure App Service, you should follow the Ruby quickstart and Ruby with PostgreSQL tutorial first.

Show Ruby version

To show the current Ruby version, run the following command in the Azure CLI:

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

To show all supported Ruby versions, run the following command in the Azure CLI:

az webapp list-runtimes --os linux | grep RUBY

Set Ruby version

Run the following command in the Azure CLI to set the Ruby version to 2.7:

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

Note

If you see errors similar to the following during deployment time:

Your Ruby version is 2.7.3, but your Gemfile specified 2.3.1

or

rbenv: version `2.3.1' is not installed

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.7.3 in the example above). 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.7.3 in the example above).

Access environment variables

In App Service, you can set app settings outside of your app code. Then you can access them using the standard ENV['<path-name>'] pattern. For example, to access an app setting called WEBSITE_SITE_NAME, use the following code:

ENV['WEBSITE_SITE_NAME']

Customize deployment

When you deploy a Git repository, or a Zip package with build automation enabled, the deployment engine (Kudu) automatically runs the following post-deployment steps by default:

  1. Check if a Gemfile exists.
  2. Run bundle clean.
  3. Run bundle install --path "vendor/bundle".
  4. Run bundle package to package gems into vendor/cache folder.

Use --without flag

To run bundle install with the --without flag, set the BUNDLE_WITHOUT app setting to a comma-separated list of groups. 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"

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. To turn on asset precompilation, set the ASSETS_PRECOMPILE app setting to true. 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

By default, the Ruby container starts the Rails server in the following sequence (for more information, see the start-up script):

  1. 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. Set the RAILS_ENV environment variable to production.
  3. 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. If not, try installing gems from the local vendor/cache directory.
  5. Run rails server -e $RAILS_ENV.

You can customize the start-up process in the following ways:

Serve static assets

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. To serve static assets from the Rails server, you need to do two things:

Run in non-production mode

The Rails server runs in production mode by default. 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"

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. To accept remote client requests, set the APP_COMMAND_LINE app setting to rails server -b 0.0.0.0. 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"

Set secret_key_base manually

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

To access the console logs generated from inside your application code in App Service, turn on diagnostic logging by running the following command in Cloud Shell:

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

Possible values for --level are Error, Warning, Info, and Verbose. Each subsequent level includes the previous level. For example, Error includes only error messages. Verbose includes all messages.

After you turn on diagnostic logging, run the following command to see the log stream:

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

If console logs don't appear immediately, check again in 30 seconds.

To stop log streaming at any time, select Ctrl+C.

Open SSH session in browser

If you want to open a direct SSH session with your container, your app should be running.

Use the az webapp ssh command.

If you're not authenticated, you need to authenticate with your Azure subscription to connect. When you're authenticated, you see an in-browser shell where you can run commands inside your container.

SSH connection

Note

Any changes that you make outside the /home directory are stored in the container itself and don't persist beyond an app restart.

To open a remote SSH session from your local machine, see Open SSH session from remote shell.

Ignore the robots933456 message in logs

You might 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 is a dummy URL path. App Service uses it to check if the container is capable of serving requests. A "404" error response indicates that the path doesn't exist, and it signals to App Service that the container is healthy and ready to respond to requests.

More resources

  • Last updated on