Architetture a Microservizi con Docker Container

1. Architetture a Microservizi con
Docker Container
Seminario
Ordine Ingegneri Lecco
Ing. Roberto Messora
Lecco, 24/10/2016

2. 2
– @robymes
– robymes@gmail.com
– roberto.messora@valuelab.it
– robymes
Contatti
www.ugidotnet.org

3. 3
Presentare Docker e i suoi concetti di base, una delle tecnologie
con il trend di crescita e adozione più alto
Definire quali sono i contesti architetturali in cui Docker si
colloca al fine di fornire elementi di valutazione circa la sua
eventuale adozione
Presentare l’ecosistema di Docker e le tecnologie/prodotti ad
esso legati
Fornire alcuni elementi legati al ciclo di vita di sviluppo di una
soluzione basata su Docker
Presentare una soluzione demo basata su Docker
Obiettivi

4. 4
Riferimenti
Demo
–https://github.com/robymes/OrdinglcDocker
Presentazione
–http://www.slideshare.net/RobertoMessora/architetture-a-
microservizi-con-docker-container

5. 5
Docker
–“It works on my machine”
–Docker Container e dintorni
–Consolidare il deploy: Virtual vs Container
–Scalare Docker: Docker Swarm (et al.)
–Ciclo di sviluppo di una soluzione Docker
Architetture basate sui servizi
–Microservices vs SOA
Demo
Agenda

8. 8
“Docker containers wrap a piece of software in a
complete filesystem that contains everything needed to
run: code, runtime, system tools, system libraries –
anything that can be installed on a server. This
guarantees that the software will always run the same,
regardless of its environment.”
https://www.docker.com/what-docker
Cos’è un Container

9. 9
Da Wikipedia
–Docker è un progetto open-source che automatizza il deployment di
applicazioni all'interno di container software, fornendo un'astrazione
addizionale grazie alla virtualizzazione a livello di sistema operativo di
Linux
–Utilizza le funzionalità di isolamento delle risorse del kernel Linux per
consentire a container indipendenti di coesistere sulla stessa istanza di
Linux, evitando l'installazione e la manutenzione di una macchina virtuale
–Le risorse possono essere isolate, i servizi limitati ed i processi avviati in
modo da avere una prospettiva completamente privata del sistema
operativo, col loro proprio identificativo, file system ed interfaccia di rete
• Namespace del kernel: isolano ciò che l'applicazione può vedere dell'ambiente
operativo (l'albero dei processi, la rete, gli ID utente ed i file system montati)
• Cgroups del kernel: isolamento delle risorse (CPU, memoria, I/O a blocchi, rete)
• Libreria libcontainer: uso delle funzionalità di virtualizzazione del kernel
Docker in pillole

10. 10
Docker Container: uno stack di immagini

11. 11
Con Windows Server 2016 Docker è disponibile nativamente anche su Windows
I principi di base sono gli stessi di Linux: accesso limitato e controllato alle risorse del
kernel
Un container Linux NON può essere ospitato su un host Windows e viceversa: i
kernel sono differenti, le API utilizzate dal container sono specifiche per i due sistemi
operativi (API Windows e API Linux)
Un client Docker è in grado di supportare entrambe le API: un solo prodotto per
enrambi i sistemi operative
I container Windows sono di due tipi
– Windows Container: i container condividono il kernel con il sistema operativo host
(Windows Server 2016), altamente efficienti, ma adatti per ambienti trusted
– Hyper-V Container: ad ogni container è assegnato un kernel virtualizzato e le
relative risorse (CPU, memoria, …), meno efficienti, ma isolamento totale
Docker for Windows

12. 12
Sviluppato inizialmente come progetto interno in dotCloud, una
società che si occupa di PaaS (Platform as a Service)
Pubblicato su github come open source nel Marzo del 2013
Nel Marzo del 2014 viene rilasciata la sua principale libreria
libcontainer, sviluppata in Go
Ad oggi l’adozione di Docker da parte dei maggiori player di
PaaS e cloud è praticamente totale: Amazon Web Services,
Google Cloud Platform, IBM Bluemix, Microsoft Azure,
OpenStack Nova, Vagrant, VMware vSphere, …
Fra i maggiori contributori del progetto ci sono: il team di
Docker, Cisco, Google, Huawei, IBM, Microsoft, Red Hat
Docker, un po’ di storia

13. 13
Consolidare il deploy: Virtual vs Container

14. 14
Docker Survey 2016

15. 15
Docker Survey 2016

16. 16
Docker Survey 2016

17. 17
L’ecosistema Docker è composto da una serie di
elementi
–Docker Engine
–Docker Machine
–Docker Compose
–Docker Swarm
–Docker Hub
Docker Container e dintorni

18. 18
Docker Engine e Docker Machine
Docker Engine
Docker Machine

19. 19
Tempo di andare in produzione:
–Scalabilità
–Affidabilità
–Facilità di deploy
–Dev once run everywhere
Scalare Docker: Docker Swarm

20. 20
Apache Mesos
Marathon
Mesosphere DC/OS
Kubernetes
…
Scalare Container: non solo Docker Swarm

21. 21
Ciclo di sviluppo con Docker
Hub
Push
Dockerfile
Pull
Dockerfile Pull
Image
Pull
Image

22. 22
Container e Architettura: Microservices?

23. 23
Modello OASIS
– Servizio: A mechanism to enable access to one or more capabilities, where the
access is provided using a prescribed interface and is exercised consistent with
constraints and policies as specified by the service description
Generalmente topologicamente distribuite
– Accesso ai servizi è remoto (REST, SOAP, AMQP, ...)
Pro
– Scalabilità
– Disaccoppiamento
– Controllo dello sviluppo, testing, deployment
– Riscrittura invece che manutenzione
Contro
– Gestione dei contratti
– Accesso remoto
Architetture basate sui servizi

24. 24
Contratto
– Service-based: contratto gestito dal solo servizio
– Consumer-driven: contratto gestito in collborazione fra servizio e consumer
– Attenzione al versioning
Disponibilità
– Capacità di un servizio di essere raggiunto (connettività)
Responsività
– Capacità di un servizio di rispondere alla chiamata
Sicurezza
– Approccio Microservices: sicurezza gestita indipendentemente da ogni servizio
senza mediazione di un middleware (altrimenti ci sarebbe troppo "traffico" e la
sicurezza uscirebbe dal buonded context introducendo troppe dipendenze esterne)
– Approccio tradizionale: sicurezza gestita tramite middleware infrastrutturale
Transazioni
Architetture basate sui servizi: ATTENZIONE
Blog Mauro Servienti
http://blogs.ugidotnet.org/topics

25. 25
Transazioni tradizionali
–ACID (atomicity, consistency, isolation, durability): in un contesto
transazionale se una azione fallisce, fallisce l’intera transazione e si esegue
un rollback
In una architettura distribuita è praticamente impossibile mantenere un
contesto transazionale: in genere una singola richiesta di business viene
gestita da n servizi
Transazioni distribuite
–BASE (basic availability, soft state, eventual consistency): workflow, saga
Nel caso in cui sia necessario assicurare ACID a livello di business la
soluzione è rendere i servizi più "grossi" al fine di includere tutte le
operazioni coinvolte
Per rafforzare BASE è possibile utilizzare gli eventi
–Miglior tracciamento di che cosa sta accadendo nel sistema al costo di una
maggiore complessità di gestione della messaggistica
Architetture basate sui servizi: Transazioni

26. 26
Limitata tassonomia dei servizi
– Servizi Funzionali
– Servizi di Infrastruttura
• non esposti verso l’esterno
• Gestiti come servizi condivisi privati ad uso dei Servizi Funzionali
Tassonomia: Microservices

27. 27
Ampia tassonomia dei servizi
– Servizi di Business
– Servizi di Infrastruttura
– Servizi Enterprise
– Servizi Applicativi
Tassonomia: SOA

28. 28
Granularità
Microservices SOA
Una sola completa funzionalità di
business
Dimensione molto piccola
Necessità di comunicazione diretta
fra servizi
Difficoltà di implementazione
transazioni tradizionali
Una intera funzionalità di business
implementata da più servizi
Dimensioni variabili fino anche ad
un intero sotto Sistema
Comunicazione fra servizi tramite
middleware (ESB)
Possibilità di utilizzo transazioni
tradizionali
“Start with a small number o larger services first”
Sam Newman
Building Microservices, O’Really

29. 29
Architetture di riferimento
Microservices
– Domain Driven Design (DDD)
– Bounded Context
– Dipendenze ridotte al minimo
(infrastruttura)
– Service chaining (attenzione a
catene troppo lunghe)
SOA
– Service component sharing
– Enterprise services
– Dipendenze gestite introducendo
altri livelli di servizi
– Service orchestration

30. 30
Interoperabilità fra servizi
Microservices
– REST
– Accesso diretto al servizio
– Semplificazione dei protocolli e
delle implementazioni
SOA
– REST, AMQP, SOAP, …
– Accesso ai servizi tramite
middleware (ESB)
– Protocol transformation, Message
transformation, Contract
decoupling

31. 31
Demo Docker

32. 32
Contatti
Roberto Messora
ESRI & Microsoft Specialist
– @ Value Lab Spa
Speaker & Collaborator
– @ UGIDotNET
Recapiti
Value Lab Spa
Piazza A. Diaz 2, 20123 Milano
(+39) 348-5138717
roberto.messora@valuelab.it
robymes@gmail.com
Value Lab Srl
Piazza Diaz 2, 20123 Milano (Italy)
T +39.02.7788931 F +39.02.76313384
valuelab@valuelab.it - www.valuelab.it