Configuración de una aplicación de Ruby en Linux para Azure App Service

  • Artículo

En este artículo se describe la forma en que Azure App Service ejecuta las aplicaciones Ruby en un contenedor Linux y cómo se puede personalizar el comportamiento de App Service cuando es necesario. Las aplicaciones de Ruby deben implementarse con todos los archivos gem requeridos.

En esta guía se incluyen conceptos clave e instrucciones para los desarrolladores de Ruby que usan un contenedor Linux integrado en App Service. Si nunca ha usado Azure App Service, debe seguir primero el inicio rápido de Ruby y el tutorial de Ruby con PostgreSQL.

Consulta de la versión de Ruby

Para mostrar la versión actual de Ruby, ejecute el siguiente comando en Cloud Shell:

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

Para mostrar todas las versiones compatibles de Ruby, ejecute el siguiente comando en Cloud Shell:

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

Para ejecutar una versión no compatible de Ruby, cree su propia imagen de contenedor. Para más información, consulte Uso de una imagen personalizada de Docker.

Establecimiento de la versión de Ruby

Ejecute el siguiente comando en Cloud Shell para establecer la versión 2.7 de Ruby:

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

Nota

Si ve errores similares al siguiente durante el tiempo de implementación:

Your Ruby version is 2.7.3, but your Gemfile specified 2.3.1

or

rbenv: version `2.3.1' is not installed

Significa que la versión de Ruby configurada en el proyecto es distinta de la instalada en el contenedor que se está ejecutando (2.7.3 en el ejemplo anterior). En el ejemplo anterior, compruebe Gemfile y .ruby-version, y que la versión de Ruby no está establecida o que es la que está instalada en el contenedor en ejecución (2.7.3 en el ejemplo anterior).

Acceso a variables de entorno

En App Service, puede establecer la configuración de la aplicación fuera del código de la aplicación. Luego, puede acceder a ella mediante el patrón estándar ENV['<path-name>']. Por ejemplo, para acceder a una configuración de una aplicación denominada WEBSITE_SITE_NAME, use el código siguiente:

ENV['WEBSITE_SITE_NAME']

Personalización de la implementación

Al implementar un repositorio de Git o un paquete comprimidocon la automatización de compilaciones activada, el motor de implementación (Kudu) ejecuta de manera automática y predeterminada los siguientes pasos posteriores a la implementación:

  1. Compruebe si un existe Gemfile.
  2. Ejecute bundle clean.
  3. Ejecute bundle install --path "vendor/bundle".
  4. Ejecute bundle package para empaquetar los archivos gem en la carpeta vendor/cache.

Uso de la marca --without

Para ejecutar bundle install con la marca --without, establezca la configuración de la aplicaciónBUNDLE_WITHOUT en una lista de grupos separada por comas. Por ejemplo, el siguiente comando la establece en development,test.

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

Con esta configuración definida, el motor de implementación ejecuta bundle install con --without $BUNDLE_WITHOUT.

Precompilación de los recursos

Los pasos posteriores a la implementación no precompilan los recursos de forma predeterminada. Para activar la precompilación de recursos, establezca la configuración de la aplicaciónASSETS_PRECOMPILE en true. El comando bundle exec rake --trace assets:precompile se ejecutará al final de los pasos posteriores a la implementación. Por ejemplo:

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

Para más información, consulte Servicio de recursos estáticos.

Personalización del inicio

De forma predeterminada, el contenedor de Ruby inicia el servidor de Rails en la siguiente secuencia (para más información, consulte el script de inicio):

  1. Genere un valor de secret_key_base, si aún no existe ninguno. Este valor es necesario para que la aplicación se ejecute en modo de producción.
  2. Establezca la variable de entorno RAILS_ENV en production.
  3. Elimine cualquier archivo .pid del directorio tmp/PID que haya dejado un servidor de Rails que se ejecutó previamente.
  4. Compruebe si están instaladas todas las dependencias. Si no, pruebe a instalar los archivos gem desde el directorio vendor/cache.
  5. Ejecute rails server -e $RAILS_ENV.

Puede personalizar el proceso de inicio de las siguientes maneras:

Servicio de recursos estáticos

El servidor de Rails en el contenedor de Ruby se ejecuta en modo de producción de forma predeterminada y da por supuesto que los recursos están precompilados y los sirve el servidor web. Para servir recursos estáticos desde el servidor de Rails, es preciso hacer dos cosas:

Ejecución en otros modos distintos del de producción

El servidor de Rails se ejecuta en modo de producción de forma predeterminada. Para ejecutarlo en modo de desarrollo, por ejemplo, establezca la configuración de la aplicaciónRAILS_ENV en development.

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

Sin embargo, esta configuración por sí sola hace que el servidor de Rails se inicie en modo de desarrollo, que acepta solo solicitudes localhost y no es accesible fuera del contenedor. Para aceptar las solicitudes de cliente remoto, establezca la configuración de la aplicaciónAPP_COMMAND_LINE en rails server -b 0.0.0.0. Esta configuración de aplicación permite ejecutar un comando personalizado en el contenedor de Ruby. Por ejemplo:

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

Establecimiento manual de secret_key_base

Para utilizar su propio valor de secret_key_base en lugar de dejar que App Service genere uno automáticamente, establezca la opción de configuración de la aplicación SECRET_KEY_BASE en el valor que desee. Por ejemplo:

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

Acceso a los registros de diagnóstico

Para acceder a los registros de la consola generados desde el código de la aplicación en App Service, active el registro de diagnósticos, para lo que debe ejecutar el siguiente comando en Cloud Shell:

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

Los valores posibles de --level son: Error, Warning, Info y Verbose. Todos los niveles incluyen el nivel anterior. Por ejemplo: Error incluye solo los mensajes de error, mientras que Verbose incluye todos los mensajes.

Una vez que se activa el registro de contenedor, ejecute el siguiente comando para ver la transmisión del registro:

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

Si no ve los registros de la consola de inmediato, vuelve a comprobarlo en 30 segundos.

Nota

También puede inspeccionar los archivos de registro desde el explorador en https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Para detener el streaming del registro en cualquier momento, escriba Ctrl+C.

Abrir sesión SSH en el explorador

Para que una sesión de SSH directa sea abierta con el contenedor, la aplicación debe estar en ejecución.

Pegue la siguiente dirección URL en el explorador y reemplace <app-name> por el nombre de la aplicación:

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

Si aún no está autenticado, será preciso que se autentique con su suscripción a Azure para conectarse. Una vez autenticado, verá un shell del explorador en el que puede ejecutar comandos dentro del contenedor.

Conexión SSH

Nota

Los cambios que realice fuera del directorio /home se almacenan en el propio contenedor y no se conservan después del primer reinicio de la aplicación.

Para abrir una sesión remota de SSH desde un equipo local, consulte Abrir sesión SSH desde un shell remoto.

robots933456 en registros

Puede ver el mensaje siguiente en los registros del contenedor:

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

Puede omitir este mensaje sin problemas. /robots933456.txt es una ruta de acceso de la dirección URL ficticia que utiliza App Service para comprobar si el contenedor es capaz de atender las solicitudes. Una respuesta 404 simplemente indica que la ruta de acceso no existe, pero permite a App Service saber que el contenedor está en buen estado y listo para responder a las solicitudes.

Más recursos