zephirworks blog

In quest'ultimo periodo in ZephirWorks stiamo tutti lavorando come dei pazzi e non c'è nulla come ricevere un riconoscimento pubblico per il proprio impegno per trovare nuove energie. In particolare questa settimana Andrea Campi è stato nominato da Opscode Most Valuable Player per il suo prezioso contibuto alla release 10.6 di Chef Server. Vedere citata ZephirWorks sul blog di Opscode e riconoscuto l'ottimo lavoro fatto da Andrea è una grande soddisfazione per tutti noi.

In particolare Andrea (sacrificando un po' del suo sonno...) oltre ad aver migliorato il supporto per FreeBSD nei cookbook Chef ha rifattorizzato alcune parti di Chef Server rendendone più facile l'installazione su Cloud Foundry ovvero la Platform as a Service Open Source sviluppata da Vmware.

E' stata anche una grande soddisfazione essere l'unica azienda europea presente a Seattle al Community Summit di Opscode Chef che si è svolto nei primi giorni di Dicembre. Abbiamo scambiato idee e impressioni con professionisti provenienti da aziende importanti come HP, Dell, Rackspace giusto per citarne alcune. Per noi è stata una importante verifica di quanto noi come azienda siamo facendo per diffondere e creare metodologie, best practices e strumenti DevOps e del perché non dobbiamo avere nessuna soggezione e/o timore reverenziale rispetto a quello che succede dall'altra parte dell'oceano. 

Per quanto mi riguarda poi ultimamente mi sono trovato a discutere e a presentare metodologie e strumenti DevOps in alcune grandi aziende - tra le quali anche una delle più importanti banche italiane - e il feedback che ne ho ricevuto è stato di grande interesse. Anche questa è una soddisfazione :)

Last but not Least, Savory l'ultima creatura in casa ZephirWorks sta per raggiungere la beta. Pietro ci ha lavorato alacremente e l'ultima release è più bella che mai!

Se siete interessati a pubblicare la vostra webzine o il vostro giornale su iPad/iPhone (ma anche sul galaxy tab :) ) sappiate che presto dovremmo poter mandare un nuovo batch di inviti quindi registratevi su savory.io, chissà che babbo natale vi recapiti un account Savory nuovo di zecca.

Noi di ZephirWorks stiamo cercando una persona che si dedichi al nostro nuovo progetto Savory.

Savory è la nostra piattaforma di publishing mobile e nasce con l'obbiettivo di permettere anche a realtà piccole - blogger, webzine, piccole case editrici - o grandi ma con budget piccolo di avere una versione per i più diffusi dispositivi mobile dei propri contenuti.

La persona che stiamo cercando dovrà occuparsi della preparazione dei template grafici treesaver ma anche della comunicazione social di Savory e dell'interfacciamento con i clienti più importanti.

Deve essere un/una entusiasta del web design: ce lo/la immaginiamo che legge smashing magazine mentre fa colazione, crea un mockup HTML5 nel pomeriggio e sperimenta con le feature più esotiche di CSS3 la sera.

Ci piacerebbe poi che avesse le conoscenze base di javascript e/o di rails e sarebbe fantastico ma non indispensabile avesse fatto una precedente esperienza in una azienda editoriale.

Quello che garantiamo è una retribuzione più che soddisfacente con inquadramento ccnl del commercio.

Se ti riconosci in questa job description mandaci una mail a jobs@zephirworks.com o un DM a @zephirworks

I really like CloudFoundry, it is an amazing project with great potential. So many projects born from within a corporation end up as nothing more than neglected step-children, lagging way too much behind the commercial product they originated from. Vmware has been a lot more open, at least so far, and the OpenSource code is apparently the same code base as they use in production.

The downside of this is that, until the community grows and more developers start contributing, the choice of supported frameworks and services is mostly driven by the needs of the commercial product. A few companies have stepped up to the plate and generously donated their work to the project.

Our first contribution to the project is a CouchDB service; we have pushed it to github and sent a pull request. This is a first draft, a few features are still missing (notably backup/restore/rebalance, as well as quota enforcement); we will be working on these in the coming weeks. Despite these limitations, if you run CF on your own private cloud and your applications needs CouchDB, you can start using testing today.

The reason I'm quite confident with the code is that we are using it to run Chef on CF in staging, with a goal to get it to production in the coming weeks. CouchDB support was the major roadblock; with this service, I'm happy to report it works quite well. We are currently using an external Solr PaaS, but we will be developing a CF service for that as well.

I assume you are vaguely familiar with JNI, the useful if tricky technology that allows Java code to call native C code. If you are not, fair warning--you will find this post boring or even slightly headache-inducing. Go read The Oatmeal instead.

Working with JNI may not be the most exciting proposition, but it doesn't need to be painful. Tools like JNIWrapper take care of the mundane parts such as loading the native library from the classpath, mapping the different types and so on. It even comes with a tool that will create wrapper code for you, so the only work that is left for you is implementing Real Stuff (TM).

That's all fine and well, until you introduce a bug; at that point chances are you'll get an error message that is just about as useful as a necktie in the Sahara. To wit:

Turning to your trusty debugger won't help you much; even if you set a breakpoint in Eclipse and single-step over the call to native code, it will just skip over--and crash you again. Unless your problem is very obvious (say, passing a null in the first place), not useful.

A solution

The good news is, depending on the operating system two debuggers may be allowed to attach to the same process. In my case, working on Mac OS X, that means I can use both Eclipse and Xcode; the process will happily jump between them depending on the function I'm currently in. If you have two monitor, it's actually mildly entertaining (at least for me--but maybe I'm just easily entertained).

How to work that magic:

1. set a breakpoint in Eclipse, and start the application;
2. when execution stops, go over to Xcode and select Product > Attach to Process from the menu; find your process in the list and click it (it will probably just show up as "java"; the pid is also provided);
3. if you want to, you can also set breakpoints in your C code;
4. now go over to Eclipse and continue execution or single step until you hit the native code. You will see Eclipse pause execution, and Xcode will bring up the function you just entered.

Bingo!

One word of notice: you may want to wait a few moments between steps 2 and 4, otherwise Eclipse may lose its wits and error out with an obscure message. That's especially true if you have a lot of breakpoints.

If you are that kind of person, you can do the same in plain old gdb. Not sure why you'd want to do that, but who I am to argue. However if you do figure it out, please leave a comment with instructions for other weirdos like you.

Trivia

In case you are wondering, the code I'm calling is actually Objective-C (CoreAudio), with a relatively thin wrapper in C. Also, the Java code is a faceless applet that interacts with JavaScript.

So in a typical scenario, the user clicks on something in the browser, that triggers JavaScript, which calls Java, that will quickly go through C only to have it call into Objective-C. Enough to make your head spin!

Nel post precedente ho parlato di Cloud Foundry di VMware, la prima Platform as a Service open, e di come testare la propria applicazione Ruby on Rails su Micro Cloud Foundry in una virtual machine sul proprio Mac (naturalmente è possibile usare Micro Cloud Foundry anche su GNU/Linux o MS Windows, cambia solo la versione di VMware da installare!).

Avevo anche anticipato di aver incontrato qualche difficoltà; ecco che ne parlo.

Configurazione di Rete

All'avvio di Micro Cloud Foundry, come raccontavo, viene mostrato un breve menu che propone di configurare varie cose, fra cui la rete. Nel post precedente ho detto di aver scelto DHCP; quello che, per semplicità, ho taciuto, è che il DHCP non ha funzionato.

Sniffando la rete, ho scoperto che il problema è legato al timeout del client DHCP, troppo breve. È una cosa che ho già visto succedere in altri server out of the box, che a quanto pare si aspettano di ricevere una risposta entro pochissimi istanti.

Niente di grave, Alt-F2, entro con l'utente vcap, faccio le mie verifiche e infine faccio partire la rete. Nel frattempo, però, scopro dalla documentazione che è possibile usare Micro Cloud Foundry anche senza avere accesso alla rete.

Utilizzare Micro Cloud Foundry offline

Se non si dispone di un collegamento di rete, o se per qualunque motivo si vuole lavorare offline, è comunque possibile utilizzare Micro Cloud Foundry senza accedere alla rete, come descritto qui.

Per farlo, bisogna innanzi tutto spegnere la macchina virtuale, configurare VMware per usare l'opzione NAT e riavviare Micro Clound Foundry, inserendo il token di configurazione:

vcap.me

Micro Cloud Foundry avvierà quindi la configurazione per l'utilizzo offline, impiegando un paio di minuti circa, dopo di che verrà mostrato l'ip della macchina virtuale.

A questo punto è necessario creare un tunnel SSH tra la propria macchina e la macchina virtuale:

ssh -L 80:IPDELLAMACCHINAVIRTUALE:80 vcap@IPDELLAMACCHINAVIRTUALE

Fatto questo, è possibile procedere col deploy, avendo però l'accortezza di specificare api.vcap.me come target per vmc:

vmc target http://api.vcap.me

Deploy di applicazioni Ruby on Rails

Per essere sicuri di poter usare la propria applicazione Rails con Micro Cloud Foundry, bisogna seguire alcuni accorgimenti.

Usare Bundler

In teoria, Micro Cloud Foundry supporta applicazioni 2.3 tradizionali, con le gemme specificate in config/environment.rb, purché freezate in vendor/gems.

In pratica, ci sono molte probabilità che la vostra applicazione non funzioni.

In questo e in altri casi, il messaggio d'errore fornito da vcap deploy è un po' criptico; è però possibile saperne di più col comando:

vmc files NOMEAPPLICAZIONE logs/migration.log

Il team di Cloud Foundry consiglia di usare sempre e comunque Bundler, e nel mio piccolo lo consiglio anch'io, e non solo per poter usare Cloud Foundry, ma soprattutto perché ci si guadagna in salute.

Rubygems

Un'altra questione che ho incontrato è legata alla versione di rubygems utilizzata: Micro Cloud Foundry usa attualmente rubygems 1.8.6, che ha problemi con il formato delle date nel gemspec di alcune gemme, tra cui paperclip e due dipendenze di Rails 3.1, ovvero rack-cache e tilt.

Conviene quindi assicurarsi che le gemme utilizzate funzionino con rubygems 1.8.6 prima di effettuare il deploy su Micro Cloud Foundry.

Conclusioni

Questa prova con Micro Cloud Foundry mi ha mostrato che il prodotto è ancora giovane, ma molto promettente, e consente, con relativamente poca fatica, di testare le proprie applicazioni in un ambiente di pre-staging pulito e comodo.

Micro Cloud Foundry promette di essere un'ottimo tool per vedere la propria applicazione in un ambiente di pre-staging, verificarne le performance, scoprire eventuali dipendenze impreviste, effettuare test d'integrazione e in genere capire come si comporterà l'applicazione in un ambiente di produzione, senza dover dedicare risorse e tempo prezioso per questo scopo.

Today I was doing a spike on a crazy idea we've been toying on for a while, and I found myself in need of disabling authentication on one API endpoint in an existing application.

Of course I could just edit the source, but where's the fun in that? Surely there must be a better way. Alas the application is written in Merb, which has been in "suspended animation" since the merge with Rails was announced. As a consequence there doesn't seem to be much information around on this kind of -nasty hacks- advanced topics.

Long story short, Merb accepts an optional -I [filename.rb] argument; the file will be loaded and evaluated at some point during the application startup.

That's not the end of the story though: the file is evaluated early in the boot; merb-core is available, but none of your models, controllers and so on. Not a big deal, you just have to use the correct hook.

And that's it--this controller is now wide open, just the way I wanted it!

Da pochi mesi, VMware ha annunciato Cloud Foundry, la prima Platform as a Service open (Licenza Apache 2), che promette di rimuovere i costi e la complessità della configurazione dell'infrastruttura e degli ambienti di esecuzione, consentendo quindi all'utente di concentrarsi solo sullo sviluppo dell'applicazione, rendendo il deploy semplice e indolore.

Cloud Foundry supporta Spring, Sinatra e Ruby on Rails, Node.js, Groovy, Grails, Scala e altre piattaforme.

Volevo verificare di persona quanto sia semplice il deploy di un'applicazione Rails su questa piattaforma, sia per test da fare sulla propria macchina di sviluppo che in un ambiente di staging o di sviluppo, installando localmente Micro Cloud Foundry, una versione completa di Cloud Foundry che gira su una virtual machine, basata su Ubuntu Server a 64 bit.

Ho deciso di raccontare questa prova in due post, uno con i passi di base da seguire quando tutto va bene, il prossimo con le difficoltà incontrate e le mie impressioni su questo software.

Installazione

Dal momento che la mia macchina di sviluppo è un macbook, per prima cosa ho installato VMware Fusion (versione di prova gratuita per 30 giorni); poi mi sono registrato sul sito di Cloud Foundry ed ho aspettato qualche ora prima di ricevere le credenziali d'accesso per poter scaricare Micro Cloud Foundry.

Con quelle credenziali ho anche potuto generare un dominio di terzo livello per la mia applicazione di prova, sotto cloudfoundry.me. Fatto questo, mi è stato dato un token da inserire successivamente in Micro Cloud Foundry.

Appena accesa la macchina virtuale, viene mostrato un menu molto scarno, e di fatto la scelta obbligata è la prima, "configure", che fa poche domande: password dell'utente vcap (che sta per VMware's Cloud Application Platform, ed è anche il nome del progetto su GitHub), configurazione di rete (DHCP o statica), token di configurazione del DNS.

Deploy di un'applicazione

Per il deploy di un'applicazione, si usa il tool a riga di comando vmc, da installare con:

gem install vmc

A questo punto, per prima cosa si deve indicare la destinazione del deployment, ovvero:

vmc target http://api.TUODOMINIO.cloudfoundry.me

Poi (solo la prima volta) occorre creare un utente, con:

vmc register

Verranno richiesti un indirizzo email e una password. Si può quindi procedere al login:

vmc login

Dopo aver digitato le credenziali immesse prima, si può finalmente eseguire il deploy vero e proprio; dalla directory dell'applicazione, digitare:

vmc push

Verranno richieste alcune informazioni, fra cui:

• se usare il path corrente per il deploy;
• nome dell'applicazione;
• URL dell'applicazione (vedi più avanti);
• se si tratta davvero di un'applicazione Rails come rilevato;
• se si vogliono usare servizi, ovvero, attualmente, mongodb, mysql o redis.

Pochi secondi dopo, il deploy è terminato e l'applicazione è accessibile su TUODOMINIO.cloudfoundry.me.

Semplice, no?

Beh, in realtà ho barato: confesso che ho incontrato qualche difficoltà, e che dopo diverse prove ho optato per il deploy di un'applicazione rails 3.0 hello world, o quasi, perché ci sono numerose limitazioni sul tipo di applicazione, le gemme e altro ancora. Nel frattempo però ho avuto modo di scoprire alcune cose interessanti su Micro Cloud Foundry, delle quali parlerò nella prossima puntata.

E' passato un mese dall'ultimo post sul blog, wow! Nel frattempo sono successe un sacco di cose...

Andando in ordine, Euruko 2011, la conferenza europea di Ruby, è stata un grande successo, come si era intuito dal "tutto esaurito" fatto dai biglietti, venduti tutti in pochi minuti (!). E' stato molto bello vedere quanto è viva la community Ruby internazionale.

Ahime gli italiano erano tra i meno rappresentati; a parte noi (quest'anno eravamo sponsor) c'erano solo altre 3 italiani. Per fortuna uno di questi era il grande Paolo Perrotta (@nusco), di gran lunga il miglior speaker presente :)

Il livello dei talk e degli speaker è stato un po' altalenante, ma per il resto un'ottima conferenza, organizzata in modo impeccabile. Farò di tutto per andare anche l'anno prossimo (Amsterdam).

Appena tornato da Berlino è stata la volta del Ruby Day, il primo evento di questo tipo e di queste dimensioni in Italia. 200 persone, per di più in un giorno feriale, sono state un successone! Complimenti davvero a tutti quelli che si sono dati da fare.

Alcune sessioni sono state molto stimolanti, penso ad Antonio Carpentieri (@acarpe) e anche di più a Matteo Vaccari; soprattutto Matteo ha dato il via ad una discussione in sala che ho visto raramente ad un evento italiano. Segno dell'interesse e della vivacità della nostra community; speriamo sia un ulteriore segnale che porti ad incontrarsi più spesso, anche con eventi più piccoli.

Ultimo ma almeno per noi altrettanto importante è stato il party per il lancio di Varnish 3, che abbiamo organizzato in contemporanea mondiale con un'altra ventina di città. 20 persone si sono ritrovate in ufficio da noi per 4 ore di presentazioni e chiacchere libere su Varnish, ma anche su altri argomenti di devops e "operations 2.0".

E' stata una bella esperienza, di nuovo con molta partecipazione del gruppo (a dire il vero composto in gran parte da facce ben note :) ). Durante la serata è emerso un interesse diffuso per proseguire e approfondire queste tematiche; abbiamo deciso di iniziare con una mailing list (https://groups.google.com/group/devops-italia), ma l'intenzione è quella di organizzare altri eventi e barcamp in autunno. Se ne riparlerà sicuramente a settembre!

Dopo tutti questi impegni, settimana prossima sarò in ferie ma la stagione delle conferenze non è ancora finita... Node.js a Settembre, MongoDB in autunno, e molto ancora. A presto!

Continuiamo la panoramica sulla nuova release di Varnish (iniziata nel post precedente) analizzando le nuove opzioni a disposizione per controllare quali pagine devono essere escluse dalla cache.

Ban e Purge

Varnish ha diversi meccanismi per eliminare un oggetto dalla cache; aggiunti in diversi momenti nella storia del progetto, svolgono compiti diversi ma sicuramente generano confusione. Varnish 3.0 porta chiarimenti nella nomenclatura, ma anche funzionalità potenti.

Verbo PURGE

Il metodo classico viene direttamente da Squid:

acl allowed_for_purge {}

sub vcl_recv {
        if (req.request == "PURGE") {
                if (!client.ip ~ allowed_for_purge) { error 405 "Not allowed."; }
                return (lookup);
        }
}

sub vcl_hit {
        if (req.request == "PURGE") {
                set obj.ttl = 0s;
                error 200 "Purged.";
        }
}

sub vcl_miss {
        if (req.request == "PURGE") {
                error 404 "Not in cache.";
        }
}

Con questo VCL è possibile eliminare un oggetto dalla cache semplicemente con una richiesta HTTP:

curl -X PURGE http://www.example.com/index.html

L'unica novità a riguardo è il comando purge, che sostituisce la manipolazione esplicita del ttl:

sub vcl_hit {
        if (req.request == "PURGE") {
                purge;
                error 200 "Purged.";
        }
}

La semplicità di questo metodo è anche il suo limite: se volessimo far scadere dalla cache tutte le pagine di una sezione del sito dovremmo inviare centinaia o migliaia di richieste esplicite. 

Ban

Un ban indica a Varnish di non servire contenuti dalla cache in base a regole che possono essere anche molto sofisticate.

E' possibile inserire un ban tramite l'interfaccia di management:

req.http.host ~ "example.com" && req.url ~ "\.png" && obj.http.set-cookie ~ "USER=JOHN_DOE"

o anche da VCL:

sub vcl_recv {
        if (req.request == "BAN") {
                if (!client.ip ~ allowed_for_purge) {                        error 405 "Not allowed.";
                }
                ban("req.http.host == " + req.http.host "&& req.url == " + req.url);

                error 200 "Ban added"
        }
}

La semantica dei ban è molto precisa ed è importante capirla a fondo. I ban vengono memorizzati da Varnish, e ogni richiesta successiva che passa dalla cache causa la valutazione delle condizioni; se la richiesta matcha le condizioni viene gestita come miss e la risorsa viene eliminata dalla cache.

Gli oggetti già presenti in cache non vengono eliminati immediatamente; in altre parole, se un oggetto non viene mai richiesto rimarrebbe comunque in cache per tutta la durata del TTL. Per ovviare a questo problema e recuperare spazio nella cache, Varnish 3.0 abilita di default un thread in background che attraversa tutta la cache e fa scadere gli oggetti corrispondenti. Quando tutte le risorse sono state esaminate, il ban scade e viene cancellato.

Un ban non impedisce l'inserimento di nuove risorse in cache, anche se rispettano le condizioni del ban stesso. Questo è un punto importante se lo scopo è prevenire il caching di determinate risorse (e non semplicemente forzare il refresh): in questo caso sarà necessario modificare il VCL per vietare il caching di quelle URL, prima di inserire il ban.

Una nota finale per chi usa lo storage persistente: i ban vengono salvati nello storage e vengono riapplicati automaticamente dopo un riavvio.

La prossima major release di Varnish è finalmente in dirittura d'arrivo, la prima beta arriverà fra pochi giorni, seguita in tempi brevi dal rilascio pubblico.

Visto che al momento le informazioni in italiano sono poche per non dire inesistenti, nei prossimi giorni pubblicheremo qualche appunto su cosa vi potete aspettare da Varnish 3.0.

Ottimizzazioni gzip

La funzionalità che aspettavo con più ansia: nella nuova versione coesistono senza problemi out of the box, e si comportano esattamente come ci si può aspettare. Se però vi serve più controllo, sono state aggiunte delle direttive per controllare compressione e decompressione delle risposte.

Se vi interessano i dettagli tecnici:

In Varnish 2 ESI interagiva male con le risposte con encoding gzip, col risultato che era necessario disabilitare gzip dal backend--ammesso che il vostro carico ve lo consentisse. Peggio ancora, la conseguenza è che era Varnish a sua volta inviava i contenuti di risposta non compressi, ed era quindi necessario mettere davanti a tutto un ulteriore proxy per comprimere.

In Varnish 3 tutto il processo è stato ridisegnato e ottimizzato: Varnish di default chiede al backend il contenuto compresso; se il client non supporta gzip (e sono pochi) lo decomprime. La copia cachata è solo quella compressa, e questo si traduce anche in più oggetti a parità di cache, che non guasta.

ESI e gzip

Il caso ESI è più complesso, perché Varnish deve gestire la possibilità di documenti non compressi inclusi in pagine compresse e viceversa. La nuova implementazione gestisce questi casi bene, ed è anche molto ben pensata e realizzata.

Ogni documento su cui ESI è abilitato viene temporaneamente decompresso quando viene ricevuto dal backend, e Varnish genera del bytecode di controllo che tiene traccia della posizione esatta dell'include. In seguito quando è il momento di servire la pagina è possibile semplicemente concatenere i pezzi.

Qualcosa di questo tipo:

Contenuto originale:

<html>
....
<esi:include src="include1"/>
... 
<esi:include src="include2"/>
...
</html> 

Viene salvato in memoria come:

[parte 1, compressa]
[bytecode che indica la presenza dell'include di "include1"]
[parte 2, compressa]
[bytecode che indica la presenza dell'include di "include2"] 
[parte 3, compressa]

Al momento di un hit:

[parte 1, compressa]
[risultato della richiesta al backend di "include1", compresso]
[parte 2, compressa]
[risultato della richiesta al backend di "include1", compresso] 
[parte 3, compressa]

La parte importante è che il risultato finale non ha bisogno di essere decompresso e ricompresso: gzip supporta una modalità per cui tra una "parte" e l'altra è sufficiente inviare un comando di reset. Furbo, no?

Per approfondimenti e altre informazioni:

• https://www.varnish-software.com/blog/varnish-30-changes
• http://www.varnish-cache.org/lists/pipermail/varnish-misc/2011-January/005510...