Presentiamo un caso di studio di un progetto web nato e cresciuto con Docker al centro della scena. Vedremo le soluzioni scelte durante tutto il percorso, partendo da docker-compose in locale, per arrivare a CoreOS e systemd in produzione, passando per la fase di continuous integration/build e il deploy.
Talk DockerOps 13-02-2016, Ferrara
Drupal 8: dal download del Core alla pubblicazione in produzione. Cos'è cambi...
Livin' with Docker - dallo sviluppo alla produzione
1. dallo sviluppo alla produzione
Livin' with Docker
abstract per DockerOps 2016[giacomo.spettoli, simone.deponti]@abstract.it /
2. Indice (Spoiler alert!)
● Introduzione del caso di studio
● Perchè proprio docker?
● Lo sviluppo
● CI / CB / CD
● Deploy
● Produzione
3. Obiettivi del progetto
● Migrazione portale del cliente verso una
soluzione basata sul cms Plone
● Fornire una soluzione gestionale su
misura con Odoo (aka OpenERP)
4. Pecularità
● vari strati software da configurare e far
interagire (nginx, elasticsearch,
postgres, haproxy.)
● gruppo di lavoro distribuito e variabile
per numero e componenti
5. Possibili soluzioni...
● configurazione a mano! (“I’m on a highway to
Hell ♫”)
● sistema di provisioning (chef, puppet, ansible,
#younameit)
● sistema di virtualizzazione (vagrant +
virtualbox, vmware, hyperv, ...)
6. ...docker!
● più leggero e modulare di una VM
● più stabile e scalabile di un sistema di
provisioning
● essendo un cambio di paradigma
bisogna trovare il modo giusto di usarlo
(per il contesto specifico)
7. la fase di sviluppo
Makefile + Ansible per il bootstrap
(download pacchetti, bower & grunt)
Docker-compose per l’orchestration dei
containers
8. il testing e le build: Jenkins
1. scarica il codice
2. fa il build delle immagini
3. esegue i test
4. fa il push sul nostro registry
Bonus: Jenkins dentro ad un container
docker che si connette al docker padre
9.
10. il testing e le build: Jenkins
1. scarica il codice
2. fa il build delle immagini
3. esegue i test
4. fa il push sul nostro registry
Bonus: Jenkins dentro ad un container
docker che si connette al docker padre
11.
12. il testing e le build: Jenkins
1. scarica il codice
2. fa il build delle immagini
3. esegue i test
4. fa il push sul nostro registry
Bonus: Jenkins dentro ad un container
docker che si connette al docker padre
13. il testing e le build: Jenkins
1. scarica il codice
2. fa il build delle immagini
3. esegue i test
4. fa il push sul nostro registry
Bonus: Jenkins dentro ad un container
docker che si connette al docker padre
14.
15. il testing e le build: Jenkins
1. scarica il codice
2. fa il build delle immagini
3. esegue i test
4. fa il push sul nostro registry
Bonus: Jenkins dentro ad un container
docker che si connette al docker padre
27. Conclusioni
● siamo volutamente partiti “bassi” (niente scheduling)
● entrare mentalmente nel “concetto” di container (stateless)
● certe cose sono difficili da mettere in un container (RDBMS)
presentazione speakers
ringrazio organizzazione per eventi in zona FE
presentazione azienda
presentazione talk: no verità assolute o arcani segreti, solo la “my way” (cit. Frank Sinatra)
docker come black box, no dettagli tecnici, ma il suo uso in real life
Il caso di studio che vogliamo presentarvi si basa su un progetto sviluppato da Abstract per un sito di promozione culturale sulle opere teatrali.
L’obiettivo del progetto era aggiornare il portale attuale del cliente ad una diversa tecnologia, nello specifico una migrazione verso il cms Plone. Si tratta, per chi non lo conoscesse, di un cms opensource, scritto principalmente in python e che ha ormai 14anni di onorato servizio. Come tutti i pezzi di software non banali che raggiungono un certo grado di anzianità, anche Plone ha le sue peculiarità e best practice per funzionare correttamente. A tal proposito vedremo in seguito cos’è il buildout, strumento simile ad Ant per java.
Per un progetto articolato come quello in questione, il solo cms non era sufficiente, perchè serviva anche l’aiuto di elasticsearch per la ricerca geolocalizzata degli eventi teatrali. Servivano anche haproxy per il bilanciamento del cluster applicativo, ovviamente nginx per il reverse proxing. Successivamente, siccome l’appetito si sa vien mangiando, al progetto si è unito anche un gestionale, sviluppato con Odoo. Quindi alla lista dei componenti coinvolti si aggiungevano odoo e postgres per la base dati.
A questo punto siamo arrivati a ben 6 diversi componenti software, ogniuno dei quali va installato e configurato correttamente per interagire fra di loro. Ora non saranno i numeri che si possono raggiungere con i microcomponenti, ma è comunque un bel numero da gestire.
Fare presente che il gruppo di lavoro era disomogeneo per quanto riguarda il sistema di sviluppo: alcuni su Mac, altri su Ubuntu, uno su Fedora<
perchè è più leggero e agile di vagrant, puoi infatti prendere dal registry parti di software già containerizzati e comporre così l’environment
più “sicuro” di un sistema di provisioning, anche se alla fine un sistema di provisioning lo usiamo lo stesso