Architetture a Microservizi con Docker Container

SeminarioOrdine Ingegneri Lecco

Ing. Roberto Messora

Lecco, 24/10/2016

2

–@robymes

– robymes@gmail.com– roberto.messora@valuelab.it

– robymes

Contatti

www.ugidotnet.org

3

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

Obiettivi

4

Riferimenti

Demo–https://github.com/robymes/OrdinglcDocker

Presentazione–http://www.slideshare.net/RobertoMessora/architetture-a-

microservizi-con-docker-container

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

“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

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

Docker Container: uno stack di immagini

11

Con Windows Server 2016 Docker è disponibile nativamente anche su WindowsI principi di base sono gli stessi di Linux: accesso limitato e controllato alle risorse del kernelUn 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 operativeI 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

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 2013Nel Marzo del 2014 viene rilasciata la sua principale libreria libcontainer, sviluppata in GoAd 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

Consolidare il deploy: Virtual vs Container

14

Docker Survey 2016

15

Docker Survey 2016

16

Docker Survey 2016

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

Docker Engine e Docker Machine

Docker Engine

Docker Machine

19

Tempo di andare in produzione:– Scalabilità–Affidabilità– Facilità di deploy–Dev once run everywhere

Scalare Docker: Docker Swarm

20

Apache MesosMarathonMesosphere DC/OSKubernetes…

Scalare Container: non solo Docker Swarm

21

Ciclo di sviluppo con Docker

HubPush

DockerfilePull

Dockerfile PullImage

PullImage

22

Container e Architettura: Microservices?

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 manutenzioneContro– Gestione dei contratti– Accesso remoto

Architetture basate sui servizi

24

Contratto– Service-based: contratto gestito dal solo servizio– Consumer-driven: contratto gestito in collborazione fra servizio e consumer– Attenzione al versioningDisponibilità– Capacità di un servizio di essere raggiunto (connettività)Responsività– Capacità di un servizio di rispondere alla chiamataSicurezza– 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 infrastrutturaleTransazioni

Architetture basate sui servizi: ATTENZIONE

Blog Mauro Servientihttp://blogs.ugidotnet.org/topics

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 serviziTransazioni distribuite–BASE (basic availability, soft state, eventual consistency): workflow, sagaNel 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 coinvoltePer 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

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

Ampia tassonomia dei servizi– Servizi di Business– Servizi di Infrastruttura– Servizi Enterprise– Servizi Applicativi

Tassonomia: SOA

28

Granularità

Microservices SOA

Una sola completa funzionalità di businessDimensione molto piccolaNecessità di comunicazione diretta fra serviziDifficoltà di implementazione transazioni tradizionali

Una intera funzionalità di business implementata da più servizi Dimensioni variabili fino anche ad un intero sotto SistemaComunicazione 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

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

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

Demo Docker

32

Contatti

Roberto Messora

ESRI & Microsoft Specialist – @ Value Lab Spa

Speaker & Collaborator– @ UGIDotNET

Recapiti

Value Lab SpaPiazza A. Diaz 2, 20123 Milano(+39) 348-5138717roberto.messora@valuelab.itrobymes@gmail.com

Value Lab SrlPiazza Diaz 2, 20123 Milano (Italy)

T +39.02.7788931 F +39.02.76313384valuelab@valuelab.it - www.valuelab.it