OpenShift Origin Architecture Componenti I due elementi base della piattaforma sono il Broker ed il/i Node/s. il server Broker è un’applicazione Rail che.

Presentazione sul tema: "OpenShift Origin Architecture Componenti I due elementi base della piattaforma sono il Broker ed il/i Node/s. il server Broker è un’applicazione Rail che."— Transcript della presentazione:

1 OpenShift Origin Architecture Componenti I due elementi base della piattaforma sono il Broker ed il/i Node/s. il server Broker è un’applicazione Rail che gestisce tutte le attività inerenti il controllo delle applicazioni, autenticazione utenti e gli update DNS. Gli utenti non accedono direttamente al broker ma interagiscono con esso via REST API mediante Web console, CLI tools (rhc), o i IDE Eclipse (JBoss Tools). I server Node sono i sistemi che ospitano le applicazioni utente e supportano sia le Cartridges built-in che i Gears. Ogni Node è multi-tenant. I Gears identificano la quota di risorse di RAM, CPU e storage che viene resa disponibile all’applicazione utente su quell nodo. Gli utenti hanno accesso via ssh al Gear. La Cartrideges Built-in è un componente (linguaggio di programmazione, database, ambienti di sviluoppo, vari tool di gestione) che può essere combinato con altri all’interno di una stessa applicazione. E’ possibile importare Cartridges della community da repository. Possibili configurazioniPossibili configurazioni: 1.Tutti i componenti (Broker e Nodes) in un singolo host (all-in-one) 2.Un Broker + ActiveMQ host, multiple Node hosts 3.Load-balanced Brokers, standalone ActiveMQ host, separate replicated MongoDB servers, multiple Node hosts Tipi di autenticazione utente OO supporta vari sistemi per autenticare un utente, fornendo i segunti file di configurazione delle autenticazioni nella directory the /var/www/openshift/broker/httpd/conf.d/: Authentication TypeDescription Mongo Authopenshift-origin-auth-mongo.conf.sample Basic Authopenshift-origin-auth-remote-user-basic.conf.sample Kerberosopenshift-origin-auth-remote-user-kerberos.conf.sample LDAPopenshift-origin-auth-remote-user-ldap.conf.sample Il Gear non è una VM… OO non utilizza gli hypervisor ma piuttosto sfrutta i Linux Container, ed in particolare: Linux Control Groups (cGroups) per il confinamento delle risorse (CPU, memory, etc.) Linux kernel namespaces per la directory polyinstantiation SELinux per la security e isolation. Tra i Container figura Docker. In particolare è in sviluppo GEARD, un client CLI ed agent per integrare e linkare I container Docker nel systemd su hosts multipli.GEARD Per i dettagli visitare: https://www.openshift.com/walkthrough/how-it-workshttps://www.openshift.com/walkthrough/how-it-works

2 OpenShift Origin: a cosa serve Sembra apparentemente che l’obiettivo principale di Openshift sia diverso da quello di Cloudify: Cloudify è pensato per fornire applicazioni e servizi di qualunque tipo, monitorarne talune metriche e visualizzarle su una dashboard, e gestirne la scalabilità OpenShift è pensato maggiormente per lo sviluppo software e continuos integration, fornendo appunto tutti gli strumenti che servono per il build, test, deploy, e run di applicazioni (oltre che a gestirne la scalabilità). Con OpenShift, ogni application ha un repository git. Gli utenti possono modificare il codice nel loro repository ed eseguire un git push per deployare il loro codice OpenShift Origin enables you to create, deploy and manage applications within the cloud. It provides disk space, CPU resources, memory, network connectivity, and an Apache or JBoss EAP server. Depending on the type of application being deployed, a template file system layout is provided (for example, PHP, Python, and Ruby/Rails). It also manages a limited DNS for the application. Alcuni estratti che spiegano in breve qual è l’obiettivo principale di OpenShift: OpenShift Origin is Red Hat’s open source Platform as a Service (PaaS) offering. OpenShift Origin is an application platform where application developers and teams can build, test, deploy, and run their applications. OpenShift Origin also serves as the upstream code base upon which OpenShift Online and OpenShift Enterprise are based. Esempio di creazione Applicazione Esempio di application deployment con Jenkins

3 OpenShift Origin: scalabilità Horizontal scaling Horizontal scaling viene realizzato usando un HAProxy cartridge come load-balancer. Quando una richiesta web arriva all’HAProxy, essa viene inoltrata sul gear che esegue il web tier dell’applicazione. Anche i deploy del codice vengono gestiti dall’HAProxy: quando il cliente esegue un git push verso il gear dell’HAProxy gear, questo a sua volta esegue un git push verso ognuno degli altri web gears. ToDo E’ necessario indagare sulla possibilità di eseguire uno scaling multi nodes, cioè verificare se è possibile fare in modo che gear diversi della stessa applicazione possano risiedere su Nodes differenti.

4 OpenShift Origin: installazione manuale Modalità di installazione e configurazione manuale L’installazione di una infrastruttura OpenShift può essere eseguita in vari modi:in vari modi Comprehensive Deployment Guide: descrive tutti i passi per un’installazione manuale di ogni singolo servizio del prodotto OO, consentendone la customizzazione di singolo servizio Comprehensive Deployment Guide Puppet Deployment Guide: descrive come configurare nel dettaglio i file di Puppet per eseguire l’installazione (singola VM o multipla) con tale strumento Puppet Deployment Guide oo-install User’s Guide: non fa altro che eseguire sotto il cofano un manifest Puppet senza che l’utente debba configurarlo a mano. lo fa il processo di installazione per lui: l’utente deve solo inserire alcuni parametri (domain, hostname, ruolo della VM [broker o Node]) oo-install User’s Guide Vagrant Deployment Guide: utilizza vagrant per l’installazione del prodotto su ciascuna VM Vagrant Deployment Guide Virtual Machine Deployment Guide: dice come effettuare l’installazione mediante un hypervisor (es. virtualbox) e una immagine preconfezionata da eseguire sull’hypervisor Virtual Machine Deployment Guide Attività Reply: Come Reply, abbiamo installato un sistema OpenShift all-in-one mediante processo manuale oo-install

5 OpenStack Tenant HEAT API OpenShift Origin: deploy automatico su OpenStack Installazione e configurazione automatica su OpenStack: Heat I Broker e i Nodes di OpenShift Origin possono essere deployati automaticamente su una infrastruttura IaaS, come ad esempio OpenStack, teoricamente utilizzando qualunque strumento di gestione remota di macchine virtuali. Nel caso di OpenStack, ad esempio, è possibile usare un template Heat sia per una installazione «all-in-one» che per una «multi-node». Su repository git di OpenStack vengono forniti dei template per installare OpenShift su sistema operativo Fedora19 e CentOS6.5. Il processo di installazione, tuttavia, non è andato a buon fine a causa dell’impiego di repository Puppet e Fedora non aggiornati. E’ necessario revisionare i template.template Alcuni riferimenti: https://wiki.openstack.org/wiki/Heat/Running-openshift ; http://docwiki.cisco.com/wiki/OpenShift_Origin_Heat_Deployment_Guide ; http://www.slideshare.net/openshift/open-stackseattlemeetup2014v7https://wiki.openstack.org/wiki/Heat/Running-openshifthttp://docwiki.cisco.com/wiki/OpenShift_Origin_Heat_Deployment_Guide http://www.slideshare.net/openshift/open-stackseattlemeetup2014v7 Attività Reply: Come Reply, abbiamo realizzato un template Heat che ripropone i passi eseguiti per una installazione manuale mediante oo-install (Scenario 1). Broker + Node HeatTemplate(all-in-one) OpenStack Tenant HEAT API BrokerNode 1 Node 2 HeatTemplate(multi-host) HeatTemplate (multi-host con broker altrove) OpenStack Tenant HEAT API Broker Node 1 Node 2 Scenario 1 Scenario 2 Scenario 3 Possibili scenari Di seguito alcuni possibili scenari relativi ad una installazione di OpenShift su OpenStack. ToDo: E’ da indagare la possibilità di realizzare lo Scenario 3.