Use OpenStack to run Java programs inside a Docker container
•Download as PPTX, PDF•
2 likes•357 views
Use OpenStack to run Java programs inside a Docker container
Recommended
Recommended
More Related Content
What's hot
What's hot (19)
Similar to Use OpenStack to run Java programs inside a Docker container
Similar to Use OpenStack to run Java programs inside a Docker container (20)
Recently uploaded
Recently uploaded (20)
Use OpenStack to run Java programs inside a Docker container
- 1. Use OpenStack to run Java programs inside a Docker container SEBASTIANO MIANO TESINA PROTOCOLLI E ARCHITETTURE DI ROUTING 1/2430/01/2016 17.12
- 2. Outline • Problem presentation and proposed solution • Implementation steps • Performance Analysis • Final Considerations 2/2430/01/2016 17.12
- 3. OpenStack OpenStack is a free and open-source cloud computing software platform. Users primarily deploy it as an infrastructure as service (IaaS) solution. 3/2430/01/2016 17.12
- 4. VM migration: use case 4/2430/01/2016 17.12
- 5. Hypervisor VMs vs. LXC vs. Docker LXC 5/2430/01/2016 17.12
- 6. VM migration: Docker 6/24 …also 400-500 MB 30/01/2016 17.12
- 7. Migrate Java programs instead VM 7/2430/01/2016 17.12
- 8. VM migration problem: solution 8/2430/01/2016 17.12
- 9. Implementation steps Modify OpenStack so that recognizes this object (JAR) and lunches this object inside a Docker container with a JVM. Create a bridge in C using libpcap library that forwards packets between 2 vNIC. Integrate the previous prototype in Java. 9/2430/01/2016 17.12
- 10. OpenStack and libvirt In order to interact with the virtualization capabilities of VM, OpenStack uses the libvirt and its corresponding API to deploy an instance on the compute node. 10/2430/01/2016 17.12
- 11. OpenStack and NovaDocker 11/2430/01/2016 17.12
- 12. Transfer instance (JAR) from Glance The Glance project provides a service where users can upload and discover data assets that are meant to be used with other services. This currently includes images and metadata definitions. os_command_line 12/24 image_id 30/01/2016 17.12
- 13. OpenStack and NovaJar In order to load the Jar inside the Docker container and run it I developed two solutions: 1. The first one uses docker data volumes to mount a Host Directory as a Data Volume. 2. The second one uses the new exec command included in the docker API 1.15 that allows to run a command inside a running container. 13/2430/01/2016 17.12
- 14. Solution with Data Volumes With this solution I transfer the jar image in the host directory and when NovaJar receives a request from scheduler mount this directory in a directory on the just created container. 14/2430/01/2016 17.12
- 15. Solution with Exec Command With this solution I need to start the container and after that I have to inject the JAR image inside the container. There are not “official” solution to do this when a container is already running, but I solved this problem by copying the JAR retrieved from glance in this path -> /var/lib/docker/aufs/mnt/{container_id}. After that I use the exec command to run the jar inside the container. Docker REST API exec /var/lib/docker/aufs/mnt/{container_id} 1530/01/2016 17.12
- 16. Data Volumes VS Exec Command Data Volumes • Good: ― Uses a feature of Docker’s API in order to use the JAR inside the container ― If the JAR does not use the network is possible to start it at container boot. Exec Command • Good: ― Allows a user to spawn a process inside their Docker container via the Docker API. • Bad: ― If the JAR uses the network (all times) the “pure” solution does not work because when the container starts the network is not yet available. • Bad: ― The command started using docker exec will only run while the container’s primary process is running. ― Uses an “unofficial” solution in order to inject the JAR inside the container (other solution: Dockerfile). 16/2430/01/2016 17.12
- 17. Third solution: merge of the previous Data Volumes and Exec Command • Good: ― Uses a feature of Docker’s API in order to use the JAR inside the container ― Allows a user to spawn a process inside their Docker container via the Docker API. • Bad: ― The command started using docker exec will only run while the container’s primary process is running (requires container already running). 17/2430/01/2016 17.12
- 18. Changes to the controller: Nova-scheduler Nova-scheduler is the module on the controller node that decide on which host run the instance selected. There are some standard filters available in nova.schedule.filters. We have to enable the ImagePropertiesFilter. It filters hosts based on properties defined on the instance’s image. It passes hosts that can support the specified image properties contained in the instance. In particular it filters hosts based on the architecture, hypervisor type, and virtual machine mode specified in the instance. os_command_line hypervisor_type = nova_jar 18/2430/01/2016 17.12
- 19. Performance Analysis First JAR output 0.129 Retrieve JAR (4 KB) 0.207 Start Container 0.707 Create Container 0.167 0.167 0.707 0.207 0.129 TIME(S) START JAR BRIDGE 19/2430/01/2016 17.12
- 20. Performance Analysis 0 1 2 3 4 5 6 7 8 9 10 1 NIC 2 NIC 4 NIC 6 NIC 8 NIC 12 NIC Time to start container Container creation Container start Retrieve JAR First JAR output 0 1 2 3 4 5 6 7 8 9 10 1 NIC 2 NIC 4 NIC 6 NIC 8 NIC 12 NIC Total Time Total Time 20/2430/01/2016 17.12
- 22. Final Observations 22/24 • Transfer JAVA programs is better than transfer VM images - not only java programs • Use the hybrid solution (volume + exec) is better - use only “official” API • Container start problem - OVS? • Container start delay can be solved - use a container already running - attach vNIC in this container at runtime • Nova-docker driver still under development - great start, but additional features needed for parity - additions to nova-docker driver could change cloud performance • Docker is still under development30/01/2016 17.12
- 23. JavaBridge and libpcap wrapper 23/24 eth0 eth2eth1 Java Bridge Docker Container JNI 30/01/2016 17.12
- 24. Thanks for your attention! 24/2430/01/2016 17.12
Editor's Notes
- Per prima cosa vediamo come ho deciso di impostare questa presentazione. Inizialmente parlerò del problema che si doveva cercare di risolvere e la soluzione proposta per risolverlo. Successivamente parlerò degli step implementativi che ho seguito per la realizzazione della soluzione finale e infine farò una piccola analisi delle performance ottenute.
- OpenStack è un progetto opensource realizzato dalla NASA e distribuito pubblicamente che consiste in una piattaforma software open-source per il cloud computing per realizzare soluzione IaaS (infrastructure as a service). E’ formato da una serie di progetti correlate che permettono di gestire principalmente tramite una dashboard o delle apposite API risorse di processing, storage e networking.
- Una delle possibilità di applicazione di OpenStack è rappresentata dal seguente caso d’uso. Supponiamo di avere una OpenStack Network di un ISP, e supponiamo di avere un router di casa (home router) che forniamo all’utente e su cui vogliamo fare in modo da realizzare dei servizi aggiuntivi da fornire all’utente o comunque realizzare qualche pre-processamento di dati. Questo vuol dire avere la possibilità di caricare a runtime delle VM dentro il router di casa dell’utente (home router) che vanno ad eseguire questi servizi aggiuntivi. Questo significa scegliere uno tra i diversi tipi di hypervisor a disposizione che permettano di andare ad eseguire la VM dentro l’home router. Tra quelli a disposizione vi sono questi. Tuttavia abbiamo notato che nell’ambito di questo caso d’uso effettuare un trasferimento in una rete possibilmente con una velocità non alta è sicuramente un aggravio importante data la notevole dimensione di queste VM che usando queste tecnologie si portano dietro un intero SO. Per cercare di mitigare questo problema si è allora cercato di utilizzare un altro tipo di tecnologia…
- Come possiamo notare da questa figura per quanto riguarda i classici hypervisor, abbiamo la tipica configurazione delle bare machine (bare metal = macchine senza un SO) oppure un tipo due dove abbiamo sopra l’hardware anche un SO, tuttavia notiamo che in questa configurazione la VM si porta dietro tutto un SO cosa che la rende sicuramente molto pesante da trasferire. Basandosi si questa considerazione è stato sviluppato un nuovo tipo di virtualizzazione a livello di SO denominata Linux Containers che permette di eseguire molteplici sistemi linux isolati (containers) ma condividono il sistema operativo e dove c’è bisogno anche le librerie. Basandosi su questo sistema di virtualizzazione è nato il progetto OpenSource denominato Docker in pratica è un framework LXC che astrae i vari aspetti della realizzazione sottostante, esso porta una nuova serie di caratteristiche che rende i container più produttivi, tra i quali la possibilità di fare dei build automatici di questi container (Dockerfiles), delle RESP API che ne permettono l’interazione oltre ad una Command Line Interface. Utilizzare delle VM basate su questa nuova considerazione rende quest’ultime sicuramente più leggere e quindi il tempo di trasferimento molto più basso rispetto al caso precedente, tuttavia…
- …mentre abbiamo notato che le dimensioni sono sicuramente più piccolo rispetto ad una VM full in realtà si è potuto constatare che le dimensioni raggiungono facilmente i 400-500 MB, sicuramente ancora troppi per pensare di non poter influire in maniera significativa sulle prestazioni. Per risolvere questo ulteriore problema si è allora pensato di evitare questo trasferimento di immagini che comunque richiedono una dimensione significativa e trasferire programmi JAVA (file JAR) invece di queste.
- Diamo uno sguardo adesso dentro al nodo compute, che dovrebbe essere il router di casa. Come possiamo vedere all’interno di questo possiamo avere diverse istanze con diverse vNIC, ognuna di queste è collegata ad openvswitch che è un multilayer switch OpenSource che supporta la maggior parte di protocolli e standard utilizzati nel mondo delle reti. Questo permette alle istanze di comunicare tra di loro oltre a raggiungere l’esterno attraverso questa interfaccia 2 che fa un tunnel GRE verso il network node. Quello che a noi interessa è l’istanza che andiamo ad eseguire dentro questo nodo controller che come possiamo vedere è in pratica un container Docker dotato di una JVM (Java Virtual Machine) che mi permette quindi di eseguire i programmi Java all’interno. In questo caso il container con la JVM però non viene più trasferito utilizzando la rete ma si trova già all’interno del nodo compute e funge soltanto da ambiente isolato per la JVM all’interno del quale ospitare programmi Java.
- Ritornando quindi alla figura di prima che rappresenta il caso d’uso possiamo notare che in questo caso non andiamo più a trasferire la VM che quindi aveva dimensioni significative ma andiamo a trasferire un programma Java che sicuramente avrà dimensioni più ridotte.
- Vediamo gli step implementativi che ho seguito e che mi hanno permesso di raggiungere questo risultato finale. Per prima cosa è naturalmente necessario apportare delle modifiche ad OpenStack affinché riconosca l’oggetto JAR come una istanza da lanciare in un determinato nodo compute che naturalmente supporta questa mia modifica allo stesso modo in cui Nova va a lanciare una generica VM dentro il nodo compute. Oltre a questo è naturalmente necessaria anche modifica al tipo di hypervisor da utilizzare affinché una volta ricevuta la richiesta vada a lanciare il JAR dentro il container Docker. L’altra parte del progetto era sostanzialmente focalizzata sul creare una sorta di libreria in Java che svolga da wrapper alla libpcap utilizzando la JNI al fine ultimo di creare un bridge che andasse ad inoltrare i pacchetti ricevuti tra due vNIC.
- Al fine di interagire con le capacità di virtualizzazione di una VM, OpenStack, ed in particolare il modulo predisposto alla gestione della parte di computing che è nova, usa libvirt che è una libreria usata proprio per gestire le capacità di virtualizzazione di un hypervisor. All’interno del nodo compute deve infatti essere presente un driver specifico per un determinato tipo di hypervisor che permetta di ricevere questi comandi da nova e creare ed avviare l’istanza che mi interessa. Nel mio caso creare un docker ed andare a mettere il Jar al suo interno.
- Per fare questo ho iniziato basandomi su un driver già esistente e denominato NovaDocker che appunto riceve le richieste tramite le API di nova (le Virt API) e le trasforma in effettive realizzazioni di istanze parlando con Docker tramite le sue REST API. Io ho sviluppato un driver chiamato NovaJar che in pratica utilizza gran parte delle funzionalità disponibili da NovaDocker con la differenza che oltre ad avviare il container in questo caso va anche ad iniettare il Jar al suo interno. In realtà in questo modo è possibile anche un’altra realizzazione ossia quella dove il container invece di partire ogni volta che viene lanciata un’istanza sia già in esecuzione dentro il nodo compute e quindi ogni volta che viene lanciato il JAR non viene creato un nuovo container ma viene semplicemente lanciato il JAR al suo interno. Come possiamo vedere da questa freccia il driver NovaJar ha la necessità di comunicare con un altro modulo di OpenStack denominato Glance.
- Il modulo Glance offre un servizio dove gli utenti possono caricare le virtual disk images, nel mio caso i JAR che in pratica rappresentano l’istanza da eseguire dentro il nodo compute. Come possiamo vedere dalla figura abbiamo il servizio di storing delle immagini di OpenStack che è glance, questo è dotato di API che permettono di svolgere diverse operazioni su queste immagini. Possibilità di aggiungere metadati: glance da la possibilità oltre ad immagazzinare delle immagini all’interno del suo db anche di associare a queste delle informazioni, cioè dei metadati. Io ho introdotto una property che è questa os_command_line che in pratica rappresenta dei parametri che possono essere dati in ingresso al jar quando questo viene avviato. Nel mio caso questa property mi permette di scegliere al volo, cioè durante la fase di lancio dell’instanza quali sono le interfacce su cui attivare la funzionalità di bridge e quali invece lasciare con il normale stack TCP/IP. Immagazzinare il JAR nel glance db. Ricevere richiesta da Nova per trasferimento con image_id: una volta ricevuta la richiesta di esecuzione di una instanza da OpenStack che abbiamo detto comunica al driver tramite le libvirt API, l’immagine del JAR che mi è stata fornita come un ID dentro questo glance database. Il driver NovaJar a questo punto tramite questo le API offerte da glance comunica l’ID dell’immagine da ottenere che quindi viene prelevata e trasferita all’interno del nodo compute. A questo punto abbiamo prelevato l’immagine e vogliamo trasferirla all’interno del Docker ed avviarla. Prima di vedere come è stata realizzato questo volevo porre l’attenzione su un altro fatto,
- Una volta trasferito il JAR all’interno del nodo compute come abbiamo detto è necessario introdurlo dentro il container Docker e successivamente eseguirlo. Per realizzare questo ho trovato sostanzialmente due soluzioni: - La prima usa il concetto di data volume e la seconda invece usa un comando introdotto nelle API 1.15 di Docker che è il comando exec che permette di eseguire un comando arbitrario all’interno del container.
- Per quando riguarda la soluzione con i data volume questa è realizzata in questo modo: Per prima cosa una volta che io vado ad ottenere il JAR da glance prendo questo e lo vado ad inserire all’interno di una directory del nodo compute, nel sistema operativo dell’host vero e proprio. Successivamente vado a creare un nuovo container docker specificando di «collegare» questa directory dell’host con una directory all’interno del container, questo vuol dire che qualsiasi cosa io vado ad inserire dentro la directory dell’host risulta essere direttamente visibile all’interno del container. A questo punto in fase di boot del container posso andare a specificare il comando per avviare il JAR ed il gioco è fatto. Naturalmente vi sono degli aspetti negativi di questa soluzione che analizzerò successivamente.
- Per quanto riguarda la soluzione con il comando exec, come ho detto prima questa API fornita da Docker permette di eseguire il comando per avviare dentro il container come un nuovo processo che viene iniettato al suo interno. Tuttavia in questo caso ho il problema di come andare ad inserire il JAR dentro il container. Io ho risolto questo problema andando a notare che quando un container viene creato tutto il so albero di directory, in pratica il file system parte da questo percorso dove container_id indica appunto un id assegnato da docker in fase di avvio del container. A questo punto dopo aver creato il container io posso andare copiare il JAR ottenuto in questo percorso e automaticamente me lo trovo all’interno del container, dopo aver fatto questo vado a comunicare tramite le API di Docker utilizzando questo comando exec per creare il nuovo processo JAVA che andrà ad eseguire il JAR.
- Vediamo adesso di analizzare gli aspetti positivi e negativi di entrambe le soluzioni: Per quando riguarda la soluzione con i volumi sicuramente una cosa positiva è data dal fatto che si usa una caratteristica prevista nelle API di docker, questa infatti rappresenta al momento l’unica possibilità ufficiale per inserire file dentro il container docker. Un altro fattore positivo è dato dalla possibilità di avviare direttamente il JAR al boot del container ma dato che il driver richiede del tempo per creare le interfacce e sostanzialmente le crea dopo che il container è avviato non posso immediatamente utilizzare la rete dato che altrimenti l’esecuzione del programma fallisce e il container non viene avviato. Per quanto riguarda gli elementi positivi dell’utilizzo del comando exec è sicureamente dato dal fatto che questo permette all’utente di avviare qualsiasi processo nel container Docker dopo che questo è avviato e non soltanto usare il container come usa e getta come nel caso di prima. Questo tuttavia richiede che il container sia già in esecuzione per avviare il comando al suo interno, questo può essere tranquillamente risolto avviando il container come processo primario la bash in modo che il container non muoia una volta che è stato creato. Io ho messo questa tra le cose negative anche se a mio parere potrebbe tranquillamente essere una cosa positiva, infatti se ho la possibiltà di avviare qualsiasi comando dentro il container che è già in running allora posso anche azzerare il delay causato dalla creazione iniziale del container che come vedremo dopo subisce notevoli rallentamenti quando il numero di vNIC è elevato. Come elemento negativo ho però messo che questa soluzione richiede di usare una soluzione non ufficiale al fine di iniettare il JAR dentro il container che in pratica è copiare il JAR in quel percorso che ho detto prima. Basandomi sugli elementi positivi di entrambe le soluzione allora quello che propongo è di usare una soluzione ibrida.
- In questa soluzione vado ad avviare il container inizialmente attaccando una directory dell’host sul container, questo vuol dire che qualsiasi cosa vado a mettere dentro questa directory allora verrà vista direttamente dentro il container, tuttavia ho la necessità di avviare il container con la bash in modo da permette l’esecuzione di più processi contemporaneamente e quindi usare il container non solo come usa e getta ma eventualmente per poter avviare più JAR all’interno e diminuire il costo di setup. Questo può essere una cosa positiva ma anche negativa perché va contro il principio che i creatori di Docker danno dei container che sostanzialmente devono essere dei contenitori usa e getta per eseguire un solo programma alla volta e non per eseguire più programmi all’interno dello stesso container. La stessa documentazione del comando exec dice che questo è stato introdotto principalmente per motivi di debug e non per dare la possibilità di iniettare più processi contemporaneamente.
- A questo punto diciamo che per quanto riguarda le modifiche al nodo compute abbiamo terminato. Tuttavia bisogna introdurre qualche considerazione aggiuntiva per quanto riguarda il modo in cui lo scheduler presente dentro il nova controller si rende conto che un determinato nodo compute sta utilizzando come hypervisor nova-jar e quindi scegliere tra i nodi che usano questo driver per avviare il JAR. Esistono diverse possibilità per gestire questo come quella di creare un filtro custom. In realtà io ho utilizzando un filtro già presente tra quelli di default di nova scheduler, questo è denominato ImagePropertiesFilter e in pratica come dice lo stesso nome filtra gli host in base a delle proprietà contenute nell’immagine stessa. Se infatti io in fase di caricamento dell’immagine su glance vado ad aggiungere un’altra proprietà oltre a quella di cui ho parlato prima, questa si chiama hypervisor_type e se io vado a specificare il tipo di hypervisor che voglio usare allora il filtro andrà a selezionare gli host corretti ossia proprio quelli che usano mio driver.
- Come ultima cosa ho effettuato un’analisi delle performance per capire il tempo impiegato da ogni diversa fase. Prima di tutto possiamo notare che non abbiamo il problema di fare il retrieve dell’immagine del container dato che questa è già presente localmente nell’host. In realtà ho previsto anche che nel caso in cui questa non fosse disponibile in locale venga presa da repository ma comunque sarebbe soltanto per la prima esecuzione dato che tutte le volte successive questa si troverebbe già localmente. I diversi elementi che ho preso in considerazione sono la creazione del container, questo comprende anche il tempo per fare l’attach del volume, possiamo vedere che il tempo è abbastanza basso dato che siamo nell’ordine di 167 ms. L’altro elemento che sono andato a considerare è il tempo necessario per avviare il container, in questo caso il container viene avviato con la bash, questo tempo è il più alto di tutti perché comprende anche il tempo necessario per fare l’attach delle interfacce. Infine ho il tempo necessario per prelevare il JAR dal glance db, naturalmente io ho fatto delle prove in locale tuttavia stiamo parlando di dimensioni di pochi KB al massimo pochi MB ma mai arriviamo naturalmente alle dimensioni di una immagine di VM. Infine vi è il tempo per fare l’exec e quindi avviare il JAR dentro il container e quindi eseguire il primo output che è di 129 ms quindi abbastanza basso. Il tempo necessario per la creazione del container abbiamo visto che è uno dei tempi sicuramente più alto, a questo proposito ho fatto delle misure di performance…
- Dai grafici della figura possiamo notare gli stessi parametri calcolati precedentemente al variare però del numero di vNIC che vengono create nel container docker, qui possiamo vedere che mentre tutti gli altri tempi rimangono pressoché identici e quindi non subiscono l’influenza dovuta all’aumento del numero di interfacce sicuramente l’avvio del container che come ho detto comprende anche l’attach di queste ne risente infatti possiamo vedere che aumenta sia il tempo totale fino ad arrivare all’ordine di quasi 9 secondi nel caso di 12 vNIC. Questo naturalmente porta ad aumento anche per quello che riguarda il tempo totale che arriva quindi a superare i 9 secondi nel caso di 12 vNIC.
- Un’ultima considerazione che volevo fare riguarda la differenza tra il boot del container utilizzando la CLI e utilizzando il driver NovaDocker, in questo caso ho fatto in boot andando a creare 4 vNIC. Vi è una considerevole differenza tra la creazione di queste utilizzando la CLI e utilizzando il nova-docker. Il sospetto di questo ritardo anche se naturalmente è soltanto una mia considerazione sembra venire dal ritardo causato nella creazione delle porte nell’OVS.
- Il progetto prevedeva anche la realizzazione di un bridge in Java che semplicemente inoltrava i pacchetti da un’interfaccia ad un’altra. In questa figura infatti possiamo vedere il container Docker che rappresenta in pratica la istanza che vado ad avviare con dentro il Jar da me creato che rappresenta un bridge che permette di forwardare i pacchetti in ingresso da un’interfaccia del container verso un’altra interfaccia, tutto customizzabile comunque come abbiamo visto a runtime. Affinché questo programma Java fosse in grado di richiamare le funzioni della libreria libpcap in C ho dovuto però creare una sorta di wrapper a questa libreria utilizzando la JNI in modo tale da permettere ad un programma Java di chiamare queste funzioni. In pratica lo schema è il seguente