ABC-Groep

Hoe kan je in sneltempo een project van begin tot einde te ontwikkelen met de laatste java technologieën?

Het doel van deze blog-serie is om in sneltempo een project van begin tot einde te ontwikkelen met de laatste java technologieën zodat nadien de focus kan komen te liggen op de eigenlijke applicatie. Dit zullen we verwezenlijken met JHipster, docker en Jenkins.

Inleiding

Origineel was deze blog-serie niet vertrokken vanuit de DevOps gedachte maar gezien de omvang van de serie is de gelijkenis hiermee steeds groter geworden en dus opteer ik voor deze titel.

Enkele definities voor DevOps van theagileadmin.com/what-is-devops/

  • DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.
  • DevOps is also characterized by operations staff making use many of the same techniques as developers for their systems work.

We trachten een structuur te voorzien welke het toelaat om developers op een agile manier te laten ontwikkelen en support te voorzien van beheerbare eindproducten.
Enkele kern-taken van een software ontwikkelaar (of software architect) zijn:

  • Het identificiëren van processen die geautomatiseerd kunnen worden;
  • De benodigde data in een genormaliseerd model te vormen;
  • Use cases uitwerken en implementeren;

Als je vraagt waar de meeste tijd verloren gaat is dit vooral:

  • Puzzelen met frameworks, build-files en configuratie;
  • Enkele tot tientallen klassen en files voorzien per entiteit in het data-model;
  • Zorgen dat css + javascript wel compatibel is met alle browsers;
  • Al de secutity features goed configureren;

Vaak zijn er veel technologieën die veel problemen oplossen maar het is zelden tot nooit dat we alles in harmonie samen zien draaien. En als dit al zo is zouden we dan dezelfde structuur niet willen overnemen naar een nieuw project?

DevOps, continuous Delivery, Continuous Integration zijn trending buzzwords maar vaak is het moeilijk om zulke ideale toestand te bekomen. Doch is dit wat we trachten te doen door een rudimentaire basis te voorzien om nieuwe projecten snel van de grond te krijgen op een efficiënte en betrouwbare manier. 

Om dit te verwezelijken zullen we gebruiken maken van enkele basis frameworks:

  • JHipster
  • Docker
  • Jenkins
  • (+ GitHub)

Aangezien er veel technologieën aan bod zullen komen kan de uitleg soms onvoldoende zijn. Indien er onduidelijkheden zijn wil ik hier wel dieper op ingaan in de commentaar of via een nieuwe post.

Wat is JHipster?

JHipster is een code generator met een eigen (JHipster) domain language. Het lost veel van de eerder genoemde problemen op door de ontwikkelaar te laten kiezen tussen enkele technologieën over de verschillende lagen in het project waarna er meer focus gegeven kan worden aan de werkelijke automatisatie en feature implementatie.

Op basis van een data-model wordt zoveel mogelijk boilerplate code gegenereerd om crud-schermen en ondersteuning voor allerhande technologieën out-of-the-box aan te bieden.
Hoewel we niet zullen ingaan op de exacte specificaties van het model kun je hier alvast een editor uitproberen om een datamodel te modelleren.

Om maar enkele technologieën te noemen die ondersteund worden door JHipster:

  • Springboot
  • Elastisearch
  • AngularJs
  • Sass
  • Bootstrap
  • Cucumber

Afhankelijk van de laag zijn meerdere technologieën mogelijk waartussen gekozen kan worden. Deze worden dan optimaal geconfigureerd volgens een logisch standaard waarde waarna deze steeds aangepast kan worden naar de behoefte van het project.

Hoewel de technologieën door de tijd heen zullen veranderen en evolueren proberen we het ontwikkelingsproces zoveel mogelijk technologie onafhankelijk te laten zijn. We blijven met JHipster uiteraard wel met Java en Javascripts-frameworks werken hoewel in theorie dit later ook uitgebreid kan worden naar andere talen.

Voor zij die de presentatie van Koen en mij zagen over NSX vermeld ik alvast dat het grootste verschil is dat JHipster enkel code genereert terwijl NSX ook de custom code harvest. Hiernaast voorziet het ook om aanpassingen aan de entiteiten toe te laten zonder de custom code te overschrijven. In deel 2 van deze serie zal ik een truk tonen hoe we deze functionaliteit ook kunnen introduceren voor JHipster.

Het concept 'module' is ook verschillend waarbij JHipster toelaat om zelf in te haken op het expansie process terwijl men bij NSX een module bekijkt als een logische scheiding tussen verschillende data-entiteiten. Tot slot zijn het aantal ondersteunde technologieën bij NSX beperkt en is er minder mogelijkheid tot het eenvoudig opzetten van continuous integration.

Wat is Docker?

Virtualisatie van applicaties is steeds populairder aan het worden. Waar vroeger er op dedicated servers geïnstalleerd werd is er een overgang geweest waarbij het OS op een virtuele laag beheerd werd in een Virtualisatie-container. Deze containers konden dan eenvoudig processorkracht en geheugen toewijzen naar gelang de nood per besturingssysteem. Omdat het besturingssysteem vaak zelf veel kracht en geheugen ontneemt is men op zoek gegaan om deze laag proces-dedicated te maken. Dit wil zeggen dat zodra de service opgestart is er geen extra processorkracht nodig voor deze service.

Om deze services te omschrijven maakt docker gebruik van docker images. Een docker image bestaat altijd uit lagen. Elke laag is 1 (of meerdere) commando’s die uitgevoerd worden, steeds verder bouwend op de vorige laag. Om veel werk te besparen kan via de docker hub repositories een groot aantal images gebruikt worden om verder op te bouwen. Zo zijn er images die ubuntu of Postgresql voorzien maar ook JHipster of Jenkins en iedereen kan zijn eigen images naar believen toevoegen en delen.

Het gebruik van deze layered images heeft wel een nadeel om rekening mee te houden. Zo wordt een image enkel groter aangezien er nooit plaats wordt vrijgemaakt tussen verschillende commando's. Dit is omdat elk nieuw commando dat uitgevoerd wordt op steeds een nieuwe laag maakt met een soort git-patch toegepast op de vorige laag.

Door correct gebruik te maken van gedeelde volumes kan data gerelateerd aan de service maar niet eigen aan de service altijd buiten de image gebruikt worden. Zo zullen de plugins en configuratie bij de jenkins container gelinkt worden met een lokale folder. Indien er geen folder expliciet gelinkt wordt zal deze een soort van tijdelijke ruimte toegewezen krijgen van docker buiten de image. Deze data kan wel verloren raken bij het verwijderen van een container instantie.

Toch kan docker best gebruikt worden door steeds een nieuwe container instantie te maken en de oude instantie te verwijderen. Het voordeel hiervan kon ik tijdens het testen meteen in de praktijk omvormen. Zo was bij een docker update iets corrupt geraakt in de hyper-V installatie waardoor ik al mijn containers verloren had. Door gewoon base-images opnieuw binnen te halen en te koppelen aan mijn shared folders was er niets verloren gegaan. Dit maakt het voorzien van back-ups ook eenvoudiger want het is duidelijk welke directories en files een back-up vereisen.

Men kan met 1 image maar 1 service laten lopen maar er is niets voorzien om deze afhankelijk te laten maken van een andere service zoals een databank. Om dit te vereenvoudigen bestaat er docker-compose. Docker compose zal op basis van een .yml configuration file automatisch de juiste services starten en stoppen in de juiste volgorde.

Wat is Jenkins?

Jenkins is een Continuous integration tool welke toelaat om automatisch tests te laten lopen op code in een repository, builds klaar te zetten en te deployen naar de gekozen omgevingen. Het kan echter ook allerhande praktische trucjes zoals automatisch repository branches te mergen.

Doelstelling

Met enkel een Docker installatie op het host besturingssysteem zullen we een programma automatisch genereren met JHipster. Onze source repository zal 4 branches voorzien. Base/Development/Testing/Master

Jenkins zal als service op docker draaien en zodra er wijzigingen zijn op de development branch wordt een build uitgevoerd en gedeployen als nieuwe container naast onze jhipster en jenkins container. 
Indien dit zonder problemen is verlopen worden de wijzigingen automatisch naar test gemerged waarna deze ook getest wordt en gedeployed. In een later stadium zouden ook REST integratie testen kunnen triggeren.

Als alles goed verloopt zouden we volgende docker containers hebben draaien:

  • Jhipster
  • Jenkins
  • dev_app
  • dev_postgres
  • tst_app
  • tst_postgres
  • prd_app
  • prd_postgres

Voorbereiding docker

Om te zorgen dat al de instructies gelijk zijn op eender welke installatie zullen we gebruiker maken van docker.

Docker was origineel op Linux uitgebracht maar er is nu ook een beta beschikbaar voor Mac + Windows.
Zelf werk ik op Windows (met cygwin) dus indien hier speciale acties voor vereist zijn zal dit ook vermeld worden.

Om docker zelf te installeren refereer ik naar de docker installatie instructies.

Linux gebruikers moeten nog apart "docker-compose" installeren. Dit zit reeds bij in de Windows + Mac installatie.

Windows gebruikers moeten rekening houden dat enkel folders in hun home-directory gelinkt kunnen worden aan containers.
Dit kan enkel indien de C: drive zelf ook 'shared' staat onder de docker settings.

undefined

Voor cygwin kan je onderstaande fix installeren indien je een interactieve shell wilt met de docker containers via de mintty terminal.

(32bit)
$ curl -s https://raw.githubusercontent.com/tiangolo/babun-docker/master/setup.sh | source /dev/stdin

(64bit)
$ curl -s https://raw.githubusercontent.com/tiangolo/babun-docker/master/setup.sh | sed 's/ia32/x64/' | source /dev/stdin

Quick peek: deel 2

In het volgende deel gaan we een eerste Jhipster applicatie aanmaken waarna we onze git-repository voorbereiden.

 

Door: Mathias 

Wij gebruiken cookies om ervoor te zorgen dat onze website voor de bezoeker beter werkt. Daarnaast gebruiken wij o.a. cookies voor onze webstatistieken. Meer informatie