OpenShift Origin – Cosa è 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. 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. 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 Esempio di application deployment con Jenkins Esempio di creazione Applicazione

OpenShift Origin Architecture Per i dettagli visitare: https://www.openshift.com/walkthrough/how-it-works 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 configurazioni: Tutti i componenti (Broker e Nodes) in un singolo host (all-in-one) Un Broker + ActiveMQ host, multiple Node hosts 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/: 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. Authentication Type Description Mongo Auth openshift-origin-auth-mongo.conf.sample Basic Auth openshift-origin-auth-remote-user-basic.conf.sample Kerberos openshift-origin-auth-remote-user-kerberos.conf.sample LDAP openshift-origin-auth-remote-user-ldap.conf.sample

OpenShift Origin: scalabilità 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.