Successfully reported this slideshow.
Your SlideShare is downloading. ×

d4r^7 - docker alla settima

d4r^7 - docker alla settima

Download to read offline

Ambiente di Continuous Delivery che gira in container docker, produce container docker sfruttando altri container docker, testa container docker usando altri container docker e rilascia container docker in container docker.

Questo è un racconto di come abbiamo imparato a usare i container e sfruttato le loro caratteristiche per creare le nostre build pipeline e l’infrastruttura stessa di build e test. Sarà un viaggio tra le sfide affrontate e illustrando le pratiche, buone e cattive, che abbiamo adottato. Da (le ceneri di) un build server confusionario, poco flessibile e con capacità limitate abbiamo realizzato un sistema ordinato, flessibile e scalabile… tutto questo sfruttando docker fino all’eccesso (e oltre)!

Il sentiero che stiamo percorrendo è lungo e a tratti impervio e noi abbiamo ancora parecchia strada da percorrere, ma gli sforzi fatti ci hanno ripagato con grandi soddisfazioni e vale la pena condividere questa esperienza!

Ambiente di Continuous Delivery che gira in container docker, produce container docker sfruttando altri container docker, testa container docker usando altri container docker e rilascia container docker in container docker.

Questo è un racconto di come abbiamo imparato a usare i container e sfruttato le loro caratteristiche per creare le nostre build pipeline e l’infrastruttura stessa di build e test. Sarà un viaggio tra le sfide affrontate e illustrando le pratiche, buone e cattive, che abbiamo adottato. Da (le ceneri di) un build server confusionario, poco flessibile e con capacità limitate abbiamo realizzato un sistema ordinato, flessibile e scalabile… tutto questo sfruttando docker fino all’eccesso (e oltre)!

Il sentiero che stiamo percorrendo è lungo e a tratti impervio e noi abbiamo ancora parecchia strada da percorrere, ma gli sforzi fatti ci hanno ripagato con grandi soddisfazioni e vale la pena condividere questa esperienza!

More Related Content

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

d4r^7 - docker alla settima

  1. 1. d4r^7 Gianni Bombelli Mini IAD Vimercate 19 maggio 2018
  2. 2. Mini IAD Vimercate - 19 maggio 2018 Docker alla settima Ambiente di Continuous Delivery che gira in container docker, produce container docker sfruttando altri container docker, testa container docker usando altri container docker e rilascia container docker in container docker.
  3. 3. Mini IAD Vimercate - 19 maggio 2018 Il Team Scrum Team composto da: ● 4 “full-stack” Software Engineer ● 1 UX e UI Designer ● 1 UI Designer e front-end Developer ● (1 Tester)
  4. 4. Mini IAD Vimercate - 19 maggio 2018 Le Applicazioni Suite composta da 8 applicazioni Web che fanno parte di un sistema ancora più vasto. Installazioni in oltre 30 paesi sparsi per il mondo.
  5. 5. Mini IAD Vimercate - 19 maggio 2018 Supporto continuo al Team di Operation... ● Ogni server si è evoluto seguendo la propria via ● Problemi durante l’installazione delle dipendenze ● Errori di configurazione delle applicazioni ● Uso di configurazioni vecchie “deprecate”
  6. 6. Mini IAD Vimercate - 19 maggio 2018 Supporto continuo al Team di Operation... ● Ogni server si è evoluto seguendo la propria via ● Problemi durante l’installazione delle dipendenze ● Errori di configurazione delle applicazioni ● Uso di configurazioni vecchie “deprecate”
  7. 7. Mini IAD Vimercate - 19 maggio 2018
  8. 8. Mini IAD Vimercate - 19 maggio 2018 Giochiamo, sperimentiamo, ma ci serve un obiettivo concreto... Replichiamo il nostro build server usando docker
  9. 9. Mini IAD Vimercate - 19 maggio 2018 10+ progetti differenti tecnologie diversi environment per le build
  10. 10. Mini IAD Vimercate - 19 maggio 2018 10+ progetti differenti tecnologie diversi environment per le build Jenkins tool providers Jenkins slaves container docker come slave
  11. 11. Mini IAD Vimercate - 19 maggio 2018 Abbiamo creato 2 immagini: ● jenkins-slave ● jenkins-sencha-slave
  12. 12. Mini IAD Vimercate - 19 maggio 2018 dipendenze tra applicazioni e repository
  13. 13. Mini IAD Vimercate - 19 maggio 2018 Per generare il package ci sono tanti job in cascata Non abbiamo un colpo d’occhio sullo stato delle build...
  14. 14. Mini IAD Vimercate - 19 maggio 2018 dipendenze tra applicazioni e repository: job in cascata build pipeline => solo 1 job per ogni applicazione
  15. 15. Mini IAD Vimercate - 19 maggio 2018 Operation ha un “Agreement” con Security Team: ● Tutte le VM e le immagini docker devono essere basate su CentOS 7.4 ● Lentezza nella build causata dalla creazione delle immagini partendo da CentOS 7.4 Passi per creare un immagine: ● Download immagine base ● Installazione dipendenze ● Configurazione ambiente interno all’immagine ● “Deploy” nell’immagine della nostra applicazione
  16. 16. Mini IAD Vimercate - 19 maggio 2018 Ottimizziamo il processo creando delle immagini “base” che rilasciamo sull’artifactory interno e riutilizziamo
  17. 17. Mini IAD Vimercate - 19 maggio 2018 test di integrazione serve una istanza dedicata dell’applicazione i dati nel DB devono essere noti reset dei dati nel DB a ogni esecuzione
  18. 18. Mini IAD Vimercate - 19 maggio 2018
  19. 19. Mini IAD Vimercate - 19 maggio 2018
  20. 20. Mini IAD Vimercate - 19 maggio 2018 Sviluppiamo nuove funzionalità per l’app. “pippo”, ma non sono pronte per i test d’integrazione
  21. 21. Mini IAD Vimercate - 19 maggio 2018 Sviluppiamo nuove funzionalità per l’app. “pippo”, ma non sono pronte per i test d’integrazione Gitflow Jenkins multi-branch pipeline
  22. 22. Mini IAD Vimercate - 19 maggio 2018 counting
  23. 23. Mini IAD Vimercate - 19 maggio 2018 Andiamo in produzione con docker… Evviva (forse)!!!
  24. 24. Mini IAD Vimercate - 19 maggio 2018 Andiamo in produzione con docker… Evviva (forse)!!! ● Build fatta dal Jenkins “Corporate” ● Rilasciata sull’artifactory “Corporate” ● Deployed automatico con il sistema di configurazione e gestione “Corporate” ● Unit test, end-to-end test e UAT in ambiente “Corporate”
  25. 25. Mini IAD Vimercate - 19 maggio 2018 Due ambienti di build “gemelli”: 2 Jenkins, 2 artifactory (docker-registry) 2 Jenkinsfile e 2 Dockerfile
  26. 26. Mini IAD Vimercate - 19 maggio 2018 Due ambienti di build “gemelli”: 2 Jenkins, 2 artifactory (docker-registry) 2 Jenkinsfile e 2 Dockerfile nuova sfida vinta :-) 2 ambienti => 2 variabili d’ambiente, 1 Jenkinsfile, 1 Dockerfile semplice, no!?
  27. 27. Mini IAD Vimercate - 19 maggio 2018 Le nuove installazioni useranno immagini docker Quelle vecchie continuano a utilizzare pacchetti RPM Il periodo di transizione sarà lungo… qualche anno
  28. 28. Mini IAD Vimercate - 19 maggio 2018 Le nuove installazioni useranno immagini docker Quelle vecchie continuano a utilizzare pacchetti RPM Il periodo di transizione sarà lungo… qualche anno Aggiunta di uno step alla pipeline per creare RPM Sonatype Nexus OSS 3 al posto di docker registry
  29. 29. Mini IAD Vimercate - 19 maggio 2018 C’è ancora strada da percorrere...
  30. 30. Mini IAD Vimercate - 19 maggio 2018 Ci sono altre sfide da affrontare Creazione automatica certificati SSL Monitoring dei container docker Migliorare il processo di configurazione delle applicazioni a livello world-wide per renderlo efficiente e cost-effective
  31. 31. Grazie! Gianni Bombelli Mini IAD Vimercate 19 maggio 2018 Quando inizi a lavorare con una squadra devi lasciare che il team vada avanti per conto suo. E alla fine devi tutto a loro. (Michael Schumacher)
  32. 32. Except where otherwise noted,these slides by Gianni Bombelli are licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License: https://creativecommons.org/licenses/by-nc-sa/4.0/
  33. 33. Exceptions: Creative Commons and the double C in a circle are registered trademarks of Creative Commons in the United States and other countries. Third party marks and brands are the property of their respective holders.

Editor's Notes

  • Ambiente di Continuous Delivery che gira in container docker
    produce container docker sfruttando altri container docker,
    testa container docker usando altri container docker
    e rilascia container docker in container docker.
  • Scrum Team cross-funzionale, ma non contiene ragazzi di operation!
  • Usiamo container per “disaccoppiare” il server dall’applicazione…
    Unica dipendenza docker-engin e docker-compose
    Le dipendenze sono inserite nel container in fase di creazione dell’immagine
    Se il container funziona sul server di dev, esso funzionaerà anche in altri server
    Le configurazioni sono interne al container… mascherate, generalizzate e semplificate
    Il container riceve come input un elenco di variabili che sostiuirà nel file di configurazione interno e.g. ip del db server
    Dire cosa e’ un container
  • To try somenthing more ambitious, you can run an Ubuntu container ...
  • Non è una buona pratica… stiamo usando docker per sostituire una vm
    Dire cosa sono jenkins, docker-registry e docker-compose
  • Tool Provider: Jenkins si occupa di installare la versione del tool (SDK, compilatore, package manager), in modo semplice e locali al workspace della build (evitando installazioni globali evitiamo conflitti)
    Jenkins slave: il server Jenkins viene usato come orchestratore e scheduler delle build, tutto il lavoro viene fatto in un nodo dedicato (tipicamente VM)
    Container docker come slave: immagine sempre pulita… dall’immagine viene creato un container ed eseguito; al termine della build il container viene rimosso
  • sencha-cmd non è installabile tramite tool provider, quindi creiamo 1 immagine con esso… se servono altri tool li installiamo con il tool provider
    Vogliamo limitare i container da mantenere e sfruttare il tool provider quando possibile!
  • 3 applicazioni (arancio)
    4 dipendenze (grigio)
    7 repository (grigio + arancio)
    4 package creati (verdi)
    11 job, uno per ogni repository + 1 per creare il pacchetto da rilasciare
    Con l’attuale struttura delle applicazioni e dei repository:
    1 o più repository per applicazioni
    Lo sviluppo di nuova funzionalità porta sempre codice nuovo in più repository
    Solitamente lavoriamo trunk based, quindi raramente di capita lavorare su long living branch, ma quando capita vogliamo aggiungere una build per la branch
  • PROBLEMI:
    NON si capisce quale job lanciare per fare la build di un progetto - 1 job “radice” per ogni package che si limita a scatenare tutto il downstream partendo dalla prima dipendenza da compilare
    NON abbiamo un colpo d’occhio sullo stato delle build
  • VANTAGGI:
    Pochi job – 1 per progetto può generare 1 o più package, ma abbiamo 1 solo job
    Si capisce a colpo d’occhio lo stato generale dei progetti (quali sono falliti e quali stabili)
    La visualizzazione della pipeline ci mostra il dettaglio di quale repository / componente del progetto fallisce… le colonne sono i singoli step
    La visualizzazione della pipeline ci fornisce il colpo d’occhio sulla storia recente delle build del singolo progetto… ogni riga è 1 esecuzione della pipeline
  • Abbiamo creato un file docker-compose contenente la definizione di tutta la nostra applicazione
  • Modifiche alla confiurazione:
    Usiamo un’altra porta
    Configuriamo il rest per collegarsi al nuovo schema
    PostgreSQL in container e script di creazione
    NON creiamo un nuovo docker-compose… sfruttiamo la funzionalità di override
  • I repository dell’applicazione sono in subversion…
    Lavoriamo trunk-based
    CAMBIAMO IL MODO DI LAVORARE
  • Multibranch pipeline:
    Plugin aggiuntivo di Jenkins
    Nessuna configurazione iniziale
    Creiamo job di tipo multibranch e in automatico Jenkins:
    Cerca per noi le branch nel repository che contengono un Jenkinsfile
    Crea nuovi job figli quando trova nuove branch
    Esegue la pipeline sulla branch quando viene fatto commit
    Elimina i job quando vengono eliminate le branch
  • i progetti aumentano di numero…
    diventano 2, 3, 4, 5, 6
    le tecnologie, i framework e le loro versioni cambiano …
    Java 8/9/10, Maven, Ant, npm, Node.js 6/8, Ext JS, Angular 2/6
    Ma manteniamo l’approccio illustrato prima….
    usiamo Jenkins tools provider per installare nei container slave tutto quello che ci serve
  • Siamo sviluppatori… i copia-incolla non ci piacciono!
    Significa:
    Replicare codice
    Mantenere allineati 2 file quasi per intero identici
  • Ora lanciamo noi la sfida:
    Cambiate pure docker server e docker-registry…
    Non non modifichiamo il codice!
    OK, per 2 volte e’ cambiato il registry
  • Le installazioni sono sparse per il mondo…
    I server stanno in datacenter dislocati nel singoli country…
    Operation global si deve coordinare con operation locale
    Vogliamo consolidare l’infrastruttura e usare un unico sistema per entrambi i pacchetti
  • Fermiamo il container di docker-registry
    avviamo quello di Sonatype Nexus OSS 3
    Così possiamo rilasciare anche pacchetti Bower, Maven/Java, npm e PyPI
  • Creazione certificati SSL… sembra semplice, ma non possiamo usare Let’s Encrypt perche’ i server sono in intranet e non abbiamo accesso ai DNS
    Zabbix e’ utilizzato per monitorare i server, possiamo usarlo anche per docker ?

×