Recomendados
Recomendados
Más contenido relacionado
Similar a d4r^7 - docker alla settima
Similar a d4r^7 - docker alla settima (20)
d4r^7 - docker alla settima
- 1. d4r^7 Gianni Bombelli Mini IAD Vimercate 19 maggio 2018
- 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. 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. 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. 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. 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. Mini IAD Vimercate - 19 maggio 2018
- 8. Mini IAD Vimercate - 19 maggio 2018 Giochiamo, sperimentiamo, ma ci serve un obiettivo concreto... Replichiamo il nostro build server usando docker
- 9. Mini IAD Vimercate - 19 maggio 2018 10+ progetti differenti tecnologie diversi environment per le build
- 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. Mini IAD Vimercate - 19 maggio 2018 Abbiamo creato 2 immagini: ● jenkins-slave ● jenkins-sencha-slave
- 12. Mini IAD Vimercate - 19 maggio 2018 dipendenze tra applicazioni e repository
- 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. Mini IAD Vimercate - 19 maggio 2018 dipendenze tra applicazioni e repository: job in cascata build pipeline => solo 1 job per ogni applicazione
- 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. Mini IAD Vimercate - 19 maggio 2018 Ottimizziamo il processo creando delle immagini “base” che rilasciamo sull’artifactory interno e riutilizziamo
- 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. Mini IAD Vimercate - 19 maggio 2018
- 19. Mini IAD Vimercate - 19 maggio 2018
- 20. Mini IAD Vimercate - 19 maggio 2018 Sviluppiamo nuove funzionalità per l’app. “pippo”, ma non sono pronte per i test d’integrazione
- 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. Mini IAD Vimercate - 19 maggio 2018 counting
- 23. Mini IAD Vimercate - 19 maggio 2018 Andiamo in produzione con docker… Evviva (forse)!!!
- 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. Mini IAD Vimercate - 19 maggio 2018 Due ambienti di build “gemelli”: 2 Jenkins, 2 artifactory (docker-registry) 2 Jenkinsfile e 2 Dockerfile
- 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. 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. 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. Mini IAD Vimercate - 19 maggio 2018 C’è ancora strada da percorrere...
- 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. 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. 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. 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.
Notas del editor
- 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 ?