Edit

Configure a Linux Ruby app for Azure App Service

  • Article

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 Cloud Shell:

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 Cloud Shell:

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

You can run an unsupported version of Ruby by building your own container image instead. For more information, see use a custom Docker image.

Set Ruby version

Run the following command in the Cloud Shell 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 diagnostics logging by running the following command in the 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, 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>

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

Note

You can also inspect the log files from the browser at https://<app-name>.scm.azurewebsites.net/api/logs/docker.

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

Open SSH session in browser

To make open a direct SSH session with your container, your app should be running.

Paste the following URL into your browser and replace <app-name> with your app name:

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

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 connection

Note

Any changes 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.

robots933456 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 is a dummy URL path that App Service uses to check if the container is capable of serving requests. 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.

More resources