Nuovo anno, nuovo tool per i deploy (o quasi)

Posted by michele, Wed Jan 10 01:10:00 UTC 2007

Distante dai botti di fine anno, dalle strenne natalizie e dai rumors su Vista™ due giorni prima di Natale è stata distribuita alle folle la nuova versione di Capistrano, tool di deploy realizzato da Jamis Buck (membro dei 37signals e mantainer di RubyOnRails). Se sei tra quelli che si chiede cosa c’entra una piccola città calabrese con ruby e rails, continua a leggere!

Capistrano è un tool per lanciare comandi parallelamente su più macchine remote; pensato per semplificare le pratiche di deploy delle vostre applicazioni è flessibile abbastanza da adattarsi praticamente a qualsiasi ambiente di sviluppo/produzione.

La nuova versione 1.3.1 introduce alcune importanti novità rispetto alla già rivoluzionaria versione 1.2 e da un chiaro assaggio della direzione in cui si stanno muovendo Jamis & 37 soci. Vediamo nel dettaglio come cambierà il modo di usarlo:

* Le credenziali d’accesso ai server possono essere specificate contestualmente alla definizione dei servers, ma cosa più importante è stata eliminata la limitazione che imponeva di avere lo stesso username su tutte le machine; ora è anche possibile connettersi su porte non standard:
1
2
role :web,  "webuser@web1.seesaw.it" 
role :db,   "db.seesaw.it:1234" 
  • L’invocazione di sudo() può essere fatta specificando l’utente con il quale eseguire il prorogramma, evitando mirabolanti giochi di permessi e gruppi all’amministratore di sistema

sudo "reboot", :as => "evil" 
  • Viene aggiornata la data d’accesso alle le directory di immagini, fogli di stile e scripts varii per fare in modo che il sistema di timestampinig di rails funzioni correttamente
  • ha fatto la sua comparsa il task update che aggiorna il codice dell’applicazione e la rende la corrente (il tutto in una transazione per evitare disservizi)
  • I task di setup e checkout ora verificano che le directory abbiano permessi di scrittura ai gruppi, risparmiandoci la realizzazione di noiosi after-task
  • L’integrazione con rake è deprecata in favore di cap (invocare rake è tuttavia transitoriamente possibile se vi siete realizzati dei tasks da voi)
  • E’ possibile usare un file di properties .caprc nella directory dell’utente per salvare settaggi in pieno stile unix

E per finire con il botto (avanzato da san silvestro) qui potete trovare un breve screencast di che vi illustra come realizzare una macchina con un full-stack rails, indovinate un po’, solo usando capistrano ;-)

Immagini by scr47chy

About the Author: Michele si occupa da anni di sviluppo software in Ruby e Java; irrimediabilmente malato di network security frequenta tutti gli eventi del settore a tenere curiosi seminari. E’ inoltre fondatore di SeeSaw srl. Se lo vedete online nelle primissime ore del mattino è di sicuro davanti ad un terminale.

Filed Under: Libreria Rails | Tags:

Comments

  1. Chiaroscuro 02.02.08 / 16PM
    Michele, in generale voi capistrano come lo usate? solo per deployare o ci sono usi non tradizionali per fare cosette interessanti?
  2. Andrea Reginato 02.02.08 / 16PM
    Ammetto di sentito nominare (da un bel pò), di sapere a grandi linee che cos'è, ma anche di non averlo mai usato. So che è potente, che semplifica notevolmente il deploy, ma mi sorge una domanda... forse banale (anzi, sicuramente :P). Quand'è che da un vero vantaggio usarlo? Sento di amministratori che lo usano per mettere applicazioni qua e la... rigirarle, frizzarle, ecc :D. A mio parere questo può tenere l'utente medio lontano dal suo uso... e forse è normale che sia così, ma volevo l'opinione di un esperto :)
  3. Chiaroscuro 02.02.08 / 16PM
    A me piacerebbe vedere un articolo che delinei in poco spazio gli step minimi pe mettere in piedi un processo di deploy automatico da subversion
  4. intinig 02.02.08 / 16PM
    ma che differenza c'è tra cap deploy e cap update per applicazioni che sono già state deployate almeno una volta?
  5. Michele 02.02.08 / 16PM
    Usi "non convenzionali" potrebbero essere il monitoring di un cluster di macchine: con la shell di capistrano puoi mandare in parallelo comandi a tutte le macchine del cluster e vedere le risposte in una finestra sola; per esempio se vuoi sapere se la tua architettura di server (2 frontend, 4 application server, 2 db server) è in salute lanci il comando _uptime_ de dentro la scell di capistrano, la risposta sarà l'uptime degli 8 server! abbastanza 'non convenzionale' ? ;-)
  6. Michele 02.02.08 / 16PM
    Riguardo alle impressioni di andrea... capistrano è stato fatto proprio nell'ottica inversa, ovvero queella con che guida lo sviluppo in rials: rendere il deploy un'operazione così semplice da poter essere fatta da un'utente 'medio' senza particolari skill sistemistici... visto che ci sono più _medi_ che amministratori in giro. Hai la possibilità di concentrarti su quello che devi fare, senza annegare tra task amministrativo-sistemistici Un breve step by step su come usare capistrano partendo da zero lo trovate "qui":http://blog.seesaw.it/articles/2006/03/21/capistrano-il-deploy-in-97-secondi
  7. Michele 02.02.08 / 16PM
    Senza scendere troppo in dettaglio nei meccanismi di funzionamento, _update_ non opera in una transazione, mentre _deploy_ sì, _update_ è una delle operazioni eseguite da _deploy_, etc La più grande delle molte differenze tra _deploy_ ed _update_ è che il secondo non riavvia l'istanza web mentre l'altro sì; se la tua applicazione web ne soffre si spaccherà tutto (un esempio è rails che gira in production mode e gli cambi un model) mentre se fai cambio della parte di view dovresti ottenere il risultato desiderato.

Have your say

A name is required. You may use HTML in your comments.