Software ontwikkelen met Docker

The next best thing since sliced bread?

En krijg je een antwoord op de vraag of het the next best thing since sliced bread is. Dit artikel is het tweede deel over Docker, lees ook: Wat is Docker?

Opvallende Docker facts: de top 3

Docker is niet alleen populair, het krijgt steeds meer erkenning. Maar waarom? Dit zijn de top 3 opvallende Docker feiten.

1. Docker maakt Continuous Integration & Delivery een stuk beheersbaarder

De tooling van Docker is erop gericht om packaging en delivery van een applicatie te vereenvoudigen en versnellen. Een applicatie vanaf de laptop van een developer uiteindelijk in productie krijgen is daarmee niet langer een traag proces.

2. Dockers coolness op Windows

De populariteit van Docker dwong Microsoft ertoe om eens kritisch te kijken naar applicatie delivery. Er is nog een hoop werk te doen, maar zij hebben een eerste stap gezet met de release van Windows 2016 mét Container support. Met name in het afslanken van Windows ten behoeve van kleinere images (een 8GB download is een nog wat teveel gevraagd!), daar is nog terrein te winnen. En de interesse vanuit de .NET community is groot, kijkend naar de grote hoeveelheid blogposts die er inmiddels geschreven zijn (mezelf incluis). De recente aankondigingen op DockerCon onderschrijven dat Microsoft zich gecommitteerd heeft om Docker op het Windows platform succesvol te maken. Zo heeft Docker een sleutelrol in zowel in good old on premise, hybrid cloud, als de cloud strategie. En het is zelfs zo dat Windows het nu mogelijk maakt om zowel Windows als Linux containers naast elkaar op één host (lees: machine) te draaien…

3. Complexe architecturen beheersbaar met Docker

De steeds complexere architecturen worden moeilijker en moeilijker te testen en zelfs te deployen. Dat vereist van beheerders steeds meer skills. Tegelijkertijd wil “de markt” telkens sneller nieuwe software versies kunnen releasen. Om dat mogelijk te maken zullen we op andere manieren software moeten uitrollen. Docker is een van de middelen die daarbij kan helpen. Met name de kwaliteit van een release en de eenvoud van het deployen zijn zaken die met het gebruik van Docker eenvoudiger zijn te realiseren.

In welke scenario’s is Docker je vriend?

De tooling van Docker is er dus op gericht om packaging en delivery van een applicatie te vereenvoudigen en versnellen. Hieronder geef ik je een aantal scenario’s waarin Docker je uitkomst biedt.

Deployen van applicaties

Je bouwt geen applicatie meer die daarna uitgerold wordt op een server, maar je build een image die alles in zich heeft om direct gedraaid te kunnen worden. Dit speelt zich precies af op het raakvlak tussen Dev en Ops, waarmee het dus ook essentieel is dat deze disciplines heel goed met elkaar samenwerken om succesvol en eenvoudig gebruik te maken van containers en Docker. Docker maakt het - door een eenvoudig middel als een Dockerfile - heel inzichtelijk wat er nu in een Docker Image zit.

Je kunt ook verschillende versies van de applicatie naast elkaar draaien. Of: dezelfde applicatie op verschillende frameworks (bijvoorbeeld cloud optimised vs regulier). En je zou zelfs een hele “straat” kunnen uitrollen die gebruikt kan worden voor een A/B test van een nieuwe feature.

Snel inrichten van een lokale ontwikkelomgeving

“It works on my machine” is hiermee verleden tijd. Je kunt lokaal dezelfde configuratie draaien als bijvoorbeeld in een productieomgeving. Sterker nog: je zou exact dezelfde image die in productie draait lokaal kunnen draaien, en daar “bovenop” een nieuwe feature bouwen. Je hoeft dan niet een centrale “ontwikkelserver” meer te hebben om te zien of jouw feature werkt, maar je kunt lokaal heel snel zien of er wat fout gaat en het oplossen voor je überhaupt een pull request aanmaakt. De ultieme vorm van Continuous Deployment. Een interessant voorbeeld is wat de jongens en meisjes bij Gitlab met het concept van Review Apps beschrijven.

Optuigen van een testomgeving

Het mooie is dat er vrijwel geen verschil is tussen het inrichten van een ontwikkelomgeving en het optuigen van een testomgeving. Het enige verschil is dat een tester geen ontwikkeltools gebruikt, maar de applicatie op de pijnbank legt door gebruik te maken van testtools zoals Selenium/Specflow of Tosca.

Een developer stelt een nieuwe versie of release van de applicatie-images beschikbaar door deze naar een centrale plek te publishen. De tester gebruikt deze images om lokaal een testomgeving op te tuigen middels een of compositie van Docker Containers. Nadat hij zijn tests heeft gedaan kan hij deze release goedkeuren, waardoor de geteste image goed is om naar productie te deployen.

Lagen van applicatie expliciet maken

Een typische manier van deployen van software is als volgt: softwareontwikkelaars bouwen hun code, stoppen die in een pakketje en geven deze aan de beheerders. De beheerders deployen op hun beurt dat pakketje op een x-aantal servers. Dit is het welbekende “over de schutting gooi”-werk, wat resulteert in een grote hoeveelheid aan documentatie van handmatig uit te voeren acties om een applicatie in productie te krijgen.

Met Docker ontwikkel je samen met je “ops” teamgenoot, dus bij voorkeur iemand die ook in je Scrum team meewerkt, een of meerdere basis image(s). Deze basis images bevatten zaken die stabieler zijn dan de software die je ontwikkelt. Je gaat immers niet voor iedere sprint een andere soort database gebruiken, of je applicatieplatform van Node.js naar .NET aanpassen. Met andere woorden: de onderste lagen zijn stabieler dan de bovenste. Je code verandert vaker dan je basis image. Mocht je basis image geüpdatet moeten worden, dan kun je dat doen door je Docker file aan te passen, en nieuwe images te bakken en te testen.
Lagen van een Docker image

De gelaagdheid van een Docker image maakt de grenzen tussen de verschillende lagen veel explicieter. “Abstraction leakage” wordt veel sneller zichtbaar, en moet je zoveel vermijden om de kracht van Docker containers goed te benutten.

Lokaal draaien van build server

Een populaire build server is Teamcity van Jetbrains. Jetbrains heeft officiële images beschikbaar gemaakt om een Teamcity server en agent te draaien. Zie TeamCity on Docker Hub – it’s official now! Dit maakt het mogelijk om lokaal een build omgeving in de lucht te brengen en een build configuratie te ontwikkelen. Je hoeft niet meer te wachten op de build van die git push happy collega die de hele build queue volzet.

Wie gaan er gelukkig worden van Docker?

WIJ, de ontwikkelaars! Wacht. Ik bedoel natuurlijk onze opdrachtgevers, beheerders, echtgenoten, vrienden, ouders en eigenlijk gewoon de volledige mensheid. Zij waren al die jaren opgezadeld met onze vloekende en tierende kant. Als we iets niet met één druk op de knop naar productie kregen, of toen het weer eens doorploeteren werd tot 3 uur ’s nachts en we met rook uit onze oren de applicatie voor de tigste keer met de hand probeerden uit te rollen. Zij waren steeds weer de klos. En juist voor hun brengt Docker verlichting, het medicijn voor al dat second hand deployment leed!

Maar serieus. Docker gaat in mijn ogen een grote impact hebben op hoe we applicaties ontwerpen, hoe we projecten starten, het hergebruik van componenten, en wáár we onze applicaties kunnen draaien. De impact die Docker kan hebben op software ontwikkeling is zo groot dat ik me niet eens waag aan het voorspellen van hoe we over een jaar met Docker werken; de ontwikkelingen gaan daar echt te hard voor. Was het, bijvoorbeeld bij de introductie van Windows 2016 nog niet mogelijk om Windows Containers naast Linux Containers te draaien op één platform, na zes maanden is dat inmiddels ook mogelijk.

In eerste instantie was Docker bedoeld om snel en makkelijk een ontwikkelomgeving op een reproduceerbare manier in de lucht te brengen. Dus vooral ontwikkelaars en testers werden hier gelukkig van. Het loste vooral het probleem op van steeds complexere ontwikkel- en testomgevingen.

Het is pas sinds 2015 dat Docker containers ook echt in productie worden gebruikt. Je ziet het afgelopen jaar steeds meer producten, projecten en tools beschikbaar komen om dit in de juiste banen te leiden. Deze betere tooling heeft als gevolg dat ook beheerders steeds meer vertrouwen krijgen in het werken met containers. Daarnaast leveren ontwikkelaars in samenwerking met testers kant en klaar werkende images op, die getest zijn, en dus een stuk minder verrassingen bevat.

Maar het allerbelangrijkste is natuurlijk dat “de business” gelukkig wordt van de snelheid waarmee applicaties uitgerold kunnen worden, zonder daarmee op kwaliteit te hoeven inboeten. De frequentie van releases kan omhoog, zodat de marketingmedewerker eindelijk de time-to-market term weer kan waarmaken.

Kortom, het antwoord is: JA! Docker is the next best thing since sliced bread.

Meer weten over Docker?

Je kunt nu al eindeloos veel informatie vinden over Docker. Als je je verder wilt verdiepen, dan raad ik je de volgende artikelen aan:

• Docker Overview - Natuurlijk de introductie van Docker door Docker zelf.
• Docker for developers - Een goede introductie over wat Docker is.
• Awesome Docker - Een lijst met interessante Docker gerelateerde links. Aanrader!
• The Internals Behind Bringing Docker & Containers to Windows:Black belt - Als je graag wat meer wilt weten hoe Docker op Windows is geïmplementeerd.

Wil je met mij sparren over Docker of de mogelijkheden verkennen? Stuur een mailtje, tweet of bel via het algemene nummer 071 710 7474.