Configurare un'app Ruby in Linux per il Servizio app di Azure

Questo articolo descrive in che modo il Servizio app di Azure esegue le app Ruby in un contenitore Linux e come è possibile personalizzare il comportamento del servizio app quando è necessario. Le app Ruby devono essere distribuite con tutti i moduli gems richiesti.

Questa guida illustra i concetti chiave e le istruzioni per gli sviluppatori Ruby che usano un contenitore Linux predefinito nel servizio app. Se non si è mai usato il Servizio app di Azure, è consigliabile seguire per prima cosa l'Avvio rapido di Ruby e l'esercitazione di Ruby con PostgreSQL.

Visualizzare la versione di Ruby

Per visualizzare la versione corrente di Ruby, eseguire il comando seguente in Cloud Shell:

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

Per visualizzare tutte le versioni di Ruby supportate, eseguire il comando seguente in Cloud Shell:

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

È possibile eseguire una versione non supportata di Ruby creando un'immagine del contenitore personalizzata. Per altre informazioni, vedere Usare un'immagine Docker personalizzata.

Configurare la versione di Ruby

Eseguire il comando seguente in Cloud Shell per impostare la versione di Ruby su 2.3:

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

Nota

Se vengono visualizzati errori simili al seguente durante la fase di distribuzione:

Your Ruby version is 2.3.3, but your Gemfile specified 2.3.1

o

rbenv: version `2.3.1' is not installed

Significa che la versione di Ruby configurata nel progetto è diversa rispetto alla versione installata nel contenitore in esecuzione (2.3.3 nell'esempio precedente). Nell'esempio precedente controllare sia Gemfile che .ruby-version e verificare che la versione di Ruby non sia configurata o che sia impostata sulla versione installata nel contenitore in esecuzione (2.3.3 nell'esempio precedente).

Accedere alle variabili di ambiente

Nel servizio app è possibile configurare le impostazioni dell'app al di fuori del codice dell'app. È quindi possibile accedervi usando il modello standard ENV['<path-name>']. Ad esempio, per accedere a un'impostazione dell'app denominata WEBSITE_SITE_NAME, usare il codice seguente:

ENV['WEBSITE_SITE_NAME']

Personalizzare la distribuzione

Quando si distribuisce un repository Git o un pacchetto ZIPcon l'automazione della compilazione abilitata, il motore di distribuzione (Kudu) esegue automaticamente i passaggi di post-distribuzione seguenti per impostazione predefinita:

  1. Controllare se Gemfile esiste.
  2. Eseguire bundle clean.
  3. Eseguire bundle install --path "vendor/bundle".
  4. Eseguire bundle package per creare un pacchetto di gemme nella cartella vendor/cache.

Usare il flag --without

Per l'esecuzione bundle install con il flag --without, impostare l'impostazione dell'appBUNDLE_WITHOUT su un elenco delimitato da virgole di gruppi. Ad esempio, il comando seguente la imposta su development,test.

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

Se questa impostazione viene definita, il motore di distribuzione esegue bundle install con --without $BUNDLE_WITHOUT.

Precompilare gli asset

Per impostazione predefinita, la procedura di post-distribuzione non precompila gli asset. Per attivare la precompilazione degli asset, impostare l'impostazione dell'appASSETS_PRECOMPILE su true. Il comando bundle exec rake --trace assets:precompile verrà eseguito al termine della procedura di post-distribuzione. Ad esempio:

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

Per altre informazioni, vedere Gestire asset statici.

Personalizzare l’avvio

Per impostazione predefinita, il contenitore Ruby avvia il server Rails nella sequenza seguente (per altre informazioni, vedere lo script di avvio):

  1. Generare un valore secret_key_base, se non esiste già. Questo valore è obbligatorio per l'esecuzione dell'app in modalità di produzione.
  2. Impostare la variabile di ambiente RAILS_ENV su production.
  3. Eliminare eventuali file con estensione pid nella directory tmp/pids originata da un server Rails eseguito in precedenza.
  4. Controllare se sono state installate tutte le dipendenze. In caso contrario, provare a installare le gemme dalla directory vendor/cache locale.
  5. Eseguire rails server -e $RAILS_ENV.

È possibile personalizzare il processo di avvio nei modi seguenti:

Gestire asset statici

Per impostazione predefinita, il server Rails nel contenitore Ruby viene eseguito in modalità di produzione e presuppone che gli asset vengano precompilati e siano gestiti dal server Web. Per gestire asset statici dal server Rails, è necessario eseguire due operazioni:

Procedere all'esecuzione in modalità non di produzione

Per impostazione predefinita, il server Rails viene eseguito in modalità di produzione. Per l'esecuzione in modalità di sviluppo, ad esempio, impostare l'impostazione dell'appRAILS_ENV su development.

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

Tuttavia, questa impostazione da sola fa sì che il server Rails venga avviato in modalità di sviluppo, accettando solo richieste localhost e non risultando accessibile al di fuori del contenitore. Per accettare le richieste client remote, impostare l'impostazione dell'appAPP_COMMAND_LINE su rails server -b 0.0.0.0. Questa impostazione dell'app consente di eseguire un comando personalizzato nel contenitore Ruby. Ad esempio:

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

Impostare manualmente secret_key_base

Per usare il proprio secret_key_base valore invece di lasciare servizio app generarne uno automaticamente, impostare l'impostazione dell'appSECRET_KEY_BASE con il valore desiderato. Ad esempio:

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

Accedere ai log di diagnostica

Per accedere ai log della console generati dall'interno del codice dell'applicazione nel servizio app, attivare la registrazione diagnostica eseguendo il comando seguente in Cloud Shell:

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

I valori possibili per --level sono: Error, Warning, Info e Verbose. Ogni livello successivo include il livello precedente. Ad esempio, Error include solo i messaggi di errore, mentre Verbose include tutti i messaggi.

Dopo aver attivato la registrazione diagnostica, eseguire il comando seguente per visualizzare il flusso di registrazione:

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

Se i log di console non sono immediatamente visibili, controllare nuovamente dopo 30 secondi.

Nota

È anche possibile esaminare i file di log nel browser all'indirizzo https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Per interrompere lo streaming dei log in qualsiasi momento, digitare Ctrl+C.

Aprire una sessione SSH nel browser

Per aprire una sessione SSH diretta con il contenitore, l'app deve essere in esecuzione.

Incollare l'URL seguente nel browser e sostituire <app-name> con il nome dell'app:

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

Se non lo si è già fatto, per connettersi è necessario eseguire l'autenticazione con la sottoscrizione di Azure. Al termine dell'autenticazione viene visualizzata una shell nel browser, in cui è possibile eseguire i comandi all'interno del contenitore.

Connessione SSH

Nota

Le eventuali modifiche apportate all'esterno della directory /home vengono archiviate nel contenitore stesso e non persistono oltre il riavvio dell'app.

Per aprire una sessione SSH remota dal computer locale, vedere Aprire una sessione SSH dalla shell remota.

robots933456 nei log

È possibile che nei log del contenitore venga visualizzato il messaggio seguente:

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

È possibile ignorare tale errore. /robots933456.txt è un percorso URL fittizio usato dal servizio app per verificare se il contenitore è in grado di gestire le richieste. Una risposta 404 indica semplicemente che il percorso non esiste, ma consente al servizio app di capire che il contenitore è integro e pronto per rispondere alle richieste.

Altre risorse