Red Hat OpenShift

Dit jaar komt Red Hat met versie 3 van het OpenShift platform. Maar wat is OpenShift nou eigenlijk? En wat moet je er mee als Java Developer? We zullen dit uitleggen zonder al te veel buzzwords te gebruiken, maar helemaal ontkomen we hier niet aan. Na een korte introductie leggen we stap voor stap uit hoe je OpenShift in de praktijk kunt gebruiken.

 

OpenShift is Red Hat’s PaaS (Platform-as-a-Service) platform. De term PaaS komt steeds vaker voorbij, maar wat houdt deze term nu exact in?

Vroeger als je een website had gebouwd en die naar productie wilde brengen, dan kocht je een server en die schroefde je dan bij een Internet Service Provider in een rack. Je installeerde er een operating system op, daarop een applicatieserver en daarbinnen draaide je dan je applicatie. Kortom, veel werk dat ook nog eens expertise vereist op allerlei niveaus.

De evolutie in softwareontwikkeling heeft niet stilgestaan en tegenwoordig is het heel normaal dat je een (al dan niet virtuele) machine huurt, inclusief operating system. Dit concept heet Infrastructure-as-a-Service (IaaS). Dit scheelt al wat fysieke arbeid en ook de hoeveelheid kennis, die je nodig hebt om een website te beheren, is een stuk minder.

IaaS is inmiddels zo mainstream geworden dat dit geleid heeft tot ontwikkelingen op het gebied van het aanbieden van complete applicatieplatformen, waarbij je alleen nog maar een website in hoeft te deployen. Dit heet Platform-as-a-Service.

Zoals je kunt verwachten van Red Hat is alles gebaseerd op veelgebruikte standaarden en open source. Grote kans dus dat je geen nieuwe technieken hoeft te leren om met OpenShift te werken. Als je wilt, kun je zelf een OpenShift provider worden. De stack is open source en die kun je downloaden als OpenShift Origin. Als je er support op wilt hebben, dan kan dat met OpenShift Enterprise.

Voor ons geldt dat we het liefst zo min mogelijk tijd kwijt zijn met het beheer van de applicatieserver en alles wat daaronder zit. Dit zal voor veel van jullie ook gelden en dan ben je de perfecte kandidaat om gebruik te maken van een OpenShift provider. Red Hat zelf is er zo een met OpenShift Online. Dat draait dan weer in de Amazon EC2 service. 

Naast het simpelweg hosten van applicaties kun je ook je volledige buildstraat erin kwijt en biedt het de mogelijkheid om snel automatisch op te schalen als het verkeer op je website toeneemt. Hierover later meer. We zullen je eerst geheel volgens de traditie door de OpenShift “Hello World” loodsen.

 

Hello World

We maken gebruik van OpenShift Online (www.openshift.com). Daar kun je gratis 3 gears gebruiken, waarmee je al een heel eind zou moeten kunnen komen. Als je een account hebt aangemaakt, krijg je de mogelijkheid om een applicatie aan te maken. Je kunt voor kant-en-klare applicaties kiezen, zoals WordPress of Drupal of voor een applicatieserver als Tomcat of JBoss AS.

In OpenShift-terminologie heet zo’n voorgeconfigureerde “managed runtime” een cartridge. De onderliggende techniek is hetzelfde als bij Docker. Vanaf versie 3 is het ook simpelweg Docker dat gebruikt wordt. Uiteindelijk moet het ergens op een (gevirtualiseerde) machine komen te draaien. Dat wordt een gear genoemd en komt overeen met een Docker-container.

In dit artikel kiezen we voor een Tomcat 7 cartridge. Vervolgens kunnen we opgeven onder welk subdomein hij beschikbaar moet komen. Verder zijn er nog wat andere instellingen, zoals of de applicatie schaalbaar moet zijn. Daar komen we later op terug. Als je de applicatie laat aanmaken, dan wordt er flink wat werk verzet. Op de Amazon cloud wordt een virtual machine opgestart met daarop Java en Tomcat. DNS wordt ingeregeld, zodat de domeinnaam die je hebt opgegeven beschikbaar komt. Tevens wordt er een Git-repository aangemaakt waar je je applicatiebroncode in kwijt kunt, die automatisch gebuild en gedeployed zal worden. Zodra OpenShift klaar is, krijg je een scherm met instructies hoe je Git kunt gebruiken. Op dit moment draait er een default website, maar die gaan we vervangen. Als je het Git-project kloont, krijg je een standaard maven project waar de meeste Java developers wel bekend mee zijn. Om te kijken of alles werkt, kun je bijvoorbeeld de standaard index.html in de src/main/webapp directory verwijderen en een index.jsp toevoegen. Zie listing 1 voor een simpele “Hello World” variant). 

<html>

   <head>

      <title>OpenShift Hello World</title>

   </head>

   <body>

      <%= new String("Hello!") %>

   </body>

</html>

Listing 1: voorbeeld index.jsp

Met de standaard Git-commando’s 'add', 'commit' en 'push' voer je de wijziging door. De push zal een build triggeren op je OpenShift gear. Tomcat zal uitgezet worden, de maven build wordt gedraaid en de resulterende war-file wordt in Tomcat gedeployed. Vervolgens wordt Tomcat weer aangezet en zou je nieuwe pagina zichtbaar moeten zijn.

 

Tools

Om je leven wat gemakkelijker te maken, zijn er allerlei tools beschikbaar. Je hoeft dus niet de website te gebruiken, maar je kunt alles via tools doen. Zo kun je de JBoss Developer Studio gebruiken (gebaseerd op Eclipse) of simpelweg de JBoss Tools plugin installeren in bijvoorbeeld je favoriete IDE. Als je die geïnstalleerd hebt, dan heb je een nieuwe view gekregen: 'openshift explorer'. Daar kun je onder je account je applicatie vinden en veel standaardoperaties uitvoeren.

Daarnaast zijn er ook de commandline tools (rhc). Als je de commandline tools hebt gedownload, moet je ze nog configureren. Met ‘rhc setup’ kun je eenmalig je account configureren. Vervolgens kun je bijvoorbeeld je applicatie starten en stoppen met de commando’s ‘rhc app-stop <naam>’ en ‘rhc app-start <naam>’. Er zijn nog wat andere handige trucjes, zoals ‘rhc tail <naam>’ om de laatste logregels van je applicatie te bekijken en ‘rhc ssh <naam>’ om op de virtuele machine in te loggen zonder die lange domeinnaam te hoeven intikken. In de rest van dit artikel maken wij gebruik van de commandline tools.

 

Een database toevoegen

De meeste webapplicaties waar wij als developers voor nodig zijn, gebruiken een database. Als je niet teveel eisen stelt aan de performance kun je de database op dezelfde gear draaien als je applicatieserver. Om PostgreSQL toe te voegen kun je via de webinterface naar je applicatie navigeren en ‘add cartridge’ kiezen, of via de commandline het commando ‘rhc cartridge add postgresql-9.2 -a <naam>’ uitvoeren. Zodra de cartridge is toegevoegd, krijg je de login-gegevens te zien voor je database. Deze database wordt ook via JNDI ontsloten naar je applicatieserver.

In de Git checkout van je applicatie zit een “.openshift/config” directory. Het is de moeite waard om daar even in te kijken. Je ziet daar de verschillende xml-bestanden die Tomcat gebruikt voor zijn configuratie. Zo kun je in de context.xml file de JNDI-naam terugvinden van de database, zoals je die hebt aangemaakt (die staan er standaard in).

 

Continuous integration

Zoals hierboven beschreven, wordt het build proces getriggerd op het moment dat je iets naar de OpenShift git repository pusht. Deze build draait op dezelfde gear als waar je applicatie op draait. Dat is niet altijd wat je wilt, want op dat moment is je site een stuk langzamer en standaard wordt zelfs Tomcat uitgezet en weer aangezet.

Beide problemen kun je eenvoudig oplossen. Je kunt een continuous integration server inrichten, die de build voor je oppakt. In OpenShift is er een standaard Jenkins cartridge beschikbaar, die je aan je applicatie container cartridge kunt toevoegen. (Let op: je voegt hem dus toe aan je Tomcat cartridge, niet als losse cartridge). Je hebt hiervoor een extra gear nodig waarop Jenkins dan komt te draaien. Deze gear wordt dan verantwoordelijk voor het build proces. Zodra Jenkins de build klaar heeft, wordt deze automatisch in Tomcat gedeployed.

Om te voorkomen dat Tomcat uit- en weer aangezet wordt tijdens zo’n deployment kun je OpenShift vertellen dat er een hot-deploy gedaan mag worden. Dit kan door een zogenaamde marker file aan te maken. In de “.openshift/markers” directory van je checkout kun je een file “hot_deploy” plaatsen. De inhoud van de file maakt niet uit, want de aanwezigheid alleen al meldt OpenShift dat de applicatieserver niet herstart hoeft te worden. Deze markers kun je ook via je IDE aanmaken. In Eclipse is het rechts klikken op je project, OpenShift, Markers.

Als je geen Jenkins wilt gebruiken, dan is er ook een andere mogelijkheid. Misschien heb je al een eigen buildstraat ingericht of krijg je simpelweg een WAR (of EAR) aangeleverd van een ander team. Je wilt OpenShift dan alleen gebruiken om je applicatie te hosten. Daarvoor kun je dezelfde Git checkout gebruiken. De WAR-file kun je plaatsen in de webapps directory, die rechtstreeks is te vinden in de root van je checkout. Je kunt de src directory verwijderen en de pom.xml is ook niet meer nodig. Omdat OpenShift geen pom.xml file meer ziet, zal hij de webapps directory gebruiken om te gaan deployen. Je kunt ook iets netter werken en een marker plaatsen (“skip_maven_build”), zodat je wat explicieter aangeeft dat je een binary deploy wilt doen. In plaats van de broncode check je dus je binaries in via Git. Je houdt zo dus nog steeds de mogelijkheid om terug te gaan naar een vorige versie als dat nodig is. 

 

Schaalbare applicaties

Als de gear waarop je website draait niet meer toereikend is voor de bezoekersaantallen, dan kun je gaan opschalen. Dat kan simpelweg door verticaal te schalen en een grotere gear te gaan gebruiken. Je kunt ook horizontaal schalen door meerdere gears te gebruiken. Je applicatie moet daarvoor natuurlijk wel geschikt zijn.

Bij het aanmaken van de applicatie op de website heb je de mogelijkheid om de applicatie als ‘scalable’ te markeren. Op de commandline is dat de ‘-s’ optie bij ‘rhc app create’. Dit heeft een paar gevolgen. Ten eerste, als je aan een schaalbare applicatie een database toevoegt, dan wordt deze automatisch op een eigen gear geplaatst. Tevens wordt er een HAProxy voor je applicatie gezet. Initieel zal deze HAProxy op dezelfde gear draaien als je eerste applicatie gear. Als er verder opgeschaald wordt, dan zal ook HAProxy op een eigen gear komen te draaien. Deze high availability proxy fungeert als een loadbalancer: het verkeer komt nu niet meer rechtstreeks op je Tomcat binnen, maar op de HAProxy. Die stuurt vervolgens het verkeer door naar één van de Tomcat gears en verdeelt zo dus het werk.

De standaardconfiguratie heeft ook een autoscale functie. Wanneer er meer dan 16 sessions per gear zijn zal OpenShift gaan opschalen. Wat het minimale en maximale aantal gears is dat gebruikt mag worden voor een cartridge, dat kan opgegeven worden via ‘rhc cartridge scale’ of via de website. Als je een wat zwaardere applicatie hebt, dan is 16 sessies wellicht wat veel en voor lichte applicaties is het misschien weer te weinig. Je kunt die variable zelf beïnvloeden door een environment variable te zetten met:

‘rhc set-env OPENSHIFT_MAX_SESSIONS_PER_GEAR <max> -a <website>’

Listing 2

Elke applicatie schaalt anders. Om een goede autoscale functionaliteit te krijgen, zal je al snel eigen parameters moeten verzinnen. Misschien is CPU load of geheugengebruik een betere indicatie voor jouw applicatie. We hebben hier niet de ruimte om daar dieper op in te gaan, maar een goed startpunt is om de standaard ‘haproxy_ctld.rb’ aan te passen. Deze kun je downloaden vanaf de HAproxy cartridge in Github (http://bit.ly/jmopenshift). Als je deze in de  ‘.openshift/action_hooks’ directory plaatst, overschrijft hij de impliciete default versie.

Conclusie

OpenShift is een mooie PaaS oplossing die volledig gebaseerd is op open source standaarden. Omdat Java al behoorlijk gestandaardiseerd is op applicatieserver niveau kunnen veel applicaties zonder aanpassingen erop draaien. Met de gratis gears staat niets je in de weg om het eens een keer uit te proberen.

In juni wordt OpenShift 3 verwacht die volledig op Docker is gebaseerd. Voor de eindgebruiker zal er weinig veranderen, behalve dat er veel meer cartridges beschikbaar zullen komen. De tooling en de websites zullen grotendeels hetzelfde blijven. Mocht je je eigen cartridges willen maken, dan adviseren we je om te nog even te wachten op OpenShift 3.