Ricette di ditribuzione

Importante

Il AWS OpsWorks Stacks servizio ha raggiunto la fine del ciclo di vita il 26 maggio 2024 ed è stato disabilitato sia per i clienti nuovi che per quelli esistenti. Consigliamo vivamente ai clienti di migrare i propri carichi di lavoro verso altre soluzioni il prima possibile. Se hai domande sulla migrazione, contatta il AWS Support Team su AWS re:post o tramite Premium AWS Support.

Le ricette di ditribuzione sono assegnate all'evento del ciclo di vita Deploy del livello. In genere si verifica su tutte le istanze dello stack ogni volta che si distribuisce un'app, sebbene sia possibile facoltativamente limitare l'evento solo a istanze specifiche. AWS OpsWorks Stacks esegue anche le ricette Deploy su nuove istanze, dopo il completamento delle ricette di installazione. Lo scopo primario delle ricette di ditribuzione è distribuire codice e file correlati da un repository alle istanze del livello del server di applicazioni. Tuttavia, esegui spesso ricette di ditribuzione anche su altri livelli. Questo consente alle istanze di tali livelli, ad esempio, di aggiornare la propria configurazione per includere l'app appena distribuita. Quando implementi una ricetta Deploy, ricorda che un evento Deploy non significa necessariamente che le app vengono distribuite nell'istanza. Potrebbe trattarsi semplicemente di una notifica del fatto che le app vengono distribuite in altre istanze dello stack per consentire all'istanza di effettuare gli aggiornamenti necessari. La ricetta deve essere in grado di rispondere in modo appropriato, che potrebbe significare anche non fare nulla.

AWS OpsWorks Stacks distribuisce automaticamente le app dei tipi di app standard nei corrispondenti livelli di server di applicazioni integrati. Per distribuire app in un livello personalizzato, devi implementare ricette di ditribuzione personalizzate che eseguono il download dei file dell'app da un repository nel percorso appropriato sull'istanza. Tuttavia, spesso puoi limitare la quantità di codice che devi scrivere utilizzando il libro di ricette di ditribuzione integrato per gestire alcuni aspetti della distribuzione. Ad esempio, se archivi i tuoi file in uno dei repository supportati, il libro di ricette integrato può gestire i dettagli del download dei file dal repository nelle istanze del livello.

La ricetta tomcat::deploy è concepita per essere assegnata all'evento del ciclo di vita Deploy.

include_recipe 'deploy'

node[:deploy].each do |application, deploy|
  opsworks_deploy_dir do
    user deploy[:user]
    group deploy[:group]
    path deploy[:deploy_to]
  end

  opsworks_deploy do
    deploy_data deploy
    app application
  end
...

La ricetta tomcat::deploy utilizza il libro di ricette di ditribuzione integrato per aspetti della distribuzione che non sono specifici dell'applicazione. La ricetta deploy (forma abbreviata per la ricetta deploy::default integrata) è una ricetta integrata che gestisce i dettagli di configurazione di utenti, gruppi e così via, in base ai dati degli attributi deploy.

La ricetta usa due definizioni Chef integrate, opsworks_deploy_dir e opworks_deploy, per installare l'applicazione.

La definizione opsworks_deploy_dir configura la struttura della directory in base ai dati del JSON di distribuzione dell'app. Le definizioni sono molto utili per creare un pacchetto con le definizioni delle risorse e si trovano nella directory definitions di un libro di ricette. Le ricette possono utilizzare le definizioni in modo analogo alle risorse, tuttavia la definizione stessa non ha un provider associato, ma solo le risorse incluse nella definizione. Puoi definire variabili nella ricetta, che vengono passate alle definizioni di risorse sottostanti. La ricetta tomcat::deploy imposta le variabili user, group e path in base ai dati del JSON di distribuzione. Questi vengono passati alla risorsa di directory della definizione, che gestisce le directory.

Nota

L'utente e il gruppo dell'app distribuita sono determinati dagli [:opsworks][:deploy_user][:group] attributi [:opsworks][:deploy_user][:user] e, definiti nel file degli attributi del cookbook di deploy integrato. deploy.rb Il valore predefinito di [:opsworks][:deploy_user][:user] è deploy. Il valore predefinito di [:opsworks][:deploy_user][:group] dipende dal sistema operativo dell'istanza:

• Per le istanze Ubuntu, il gruppo predefinito è www-data.

• Per le istanze Amazon Linux che sono membri di un livello Rails App Server che utilizza Nginx e Unicorn, il gruppo predefinito è. nginx

• Per tutte le altre istanze Amazon Linux, il gruppo predefinito è apache.

Puoi modificare le impostazioni utilizzando un JSON personalizzato o un file di attributi personalizzato per sostituire l'attributo appropriato. Per ulteriori informazioni, consulta Sostituzione degli attributi.

L'altra definizione, opsworks_deploy, gestisce i dettagli di verifica del codice dell'app e dei file correlati del repository e della loro distribuzione nell'istanza, in base ai dati degli attributi deploy. Puoi utilizzare questa definizione per qualsiasi tipo di app. I dettagli di distribuzione, come i nomi di directory, sono specificati nella console o tramite l'API e inseriti negli attributi deploy. Tuttavia, opsworks_deploy funziona solo per i quattro tipi di repository supportati: Git, Subversion, S3 e HTTP. Se desideri utilizzare un altro tipo di repository, devi implementare personalmente questo codice.

Installi file di un'app nella directory webapps di Tomcat. Una procedura classica consiste nel copiare i file direttamente in webapps. Tuttavia, la distribuzione di AWS OpsWorks Stacks è progettata per conservare fino a cinque versioni di un'app su un'istanza, quindi puoi tornare a una versione precedente se necessario. AWS OpsWorks Stacks esegue quindi le seguenti operazioni:

1. Distribuisce app in una directory distinta il cui nome include un timestamp, come /srv/www/my_1st_jsp/releases/20130731141527.

2. Crea un collegamento simbolico denominato current, ad esempio /srv/www/my_1st_jsp/current, a questa directory univoca.

3. Se non esiste già, crea un collegamento simbolico dalla directory webapps al collegamento simbolico current creato al Passaggio 2.

Se devi eseguire il rollback a una versione precedente, modifica il collegamento simbolico current in modo che punti a una directory distinta contenente il timestamp appropriato modificando, ad esempio, la destinazione del collegamento di /srv/www/my_1st_jsp/current.

La sezione centrale di tomcat::deploy configura il collegamento simbolico.

  ...
  current_dir = ::File.join(deploy[:deploy_to], 'current')
  webapp_dir = ::File.join(node['tomcat']['webapps_base_dir'], deploy[:document_root].blank? ? application : deploy[:document_root])

  # opsworks_deploy creates some stub dirs, which are not needed for typical webapps
  ruby_block "remove unnecessary directory entries in #{current_dir}" do
    block do
      node['tomcat']['webapps_dir_entries_to_delete'].each do |dir_entry|
        ::FileUtils.rm_rf(::File.join(current_dir, dir_entry), :secure => true)
      end
    end
  end

  link webapp_dir do
    to current_dir
    action :create
  end
  ...

La ricetta prima crea due variabili, current_dir e webapp_dir, per rappresentare, rispettivamente, le directory current e webapp. Quindi, utilizza una risorsa link per collegare webapp_dir a current_dir. La deploy::default ricetta AWS OpsWorks Stacks crea alcune directory di stub che non sono necessarie per questo esempio, quindi la parte centrale dell'estratto le rimuove.

La parte finale di tomcat::deploy riavvia il servizio Tomcat, se necessario.

  ...
  include_recipe 'tomcat::service'

  execute 'trigger tomcat service restart' do
    command '/bin/true'
    not_if { node['tomcat']['auto_deploy'].to_s == 'true' }
    notifies :restart, resources(:service => 'tomcat')
  end
end

include_recipe 'tomcat::context'

La ricetta innanzitutto esegue tomcat::service per garantire che il servizio venga definito per questa esecuzione di Chef. Quindi, utilizza una risorsa execute per notificare il riavvio al servizio, ma solo se ['tomcat']['auto_deploy'] è impostato su 'true'. In alternativa, Tomcat ascolta le modifiche nella propria directory webapps, che rende superfluo un riavvio esplicito del servizio Tomcat.

Nota

La risorsa execute non esegue effettivamente niente di sostanziale. /bin/true è uno script di shell fittizio che restituisce semplicemente un codice di successo. Qui è utilizzato semplicemente come un metodo utile per generare una notifica di riavvio. Come accennato in precedenza, l'utilizzo di notifiche garantisce che i servizi non vengano riavviati troppo frequentemente.

Infine, tomcat::deploy esegue tomcat::context, che aggiorna il file di configurazione del contesto dell'app Web se hai modificato il database di back-end.