What are the goals of CI/CD, how can they be reached? A great variety of tools are used and often managed by a central CI/CD team who integrate, standardise and maintain them. As a CI/CD consultant, I have created numerous pipelines, but none of them was so complete and mature as the Auto DevOps pipelines templates from GitLab.

Join this webinar to see what CI/CD can do and take the next step in your DevOps journey.

CI/CD – from code to running in production

Sign up for our free webinar: the Benefits of CI/CD

Ik heb de afgelopen 2 jaar redelijk wat met Kubernetes gewerkt bij onze klanten en ondertussen is het uitgegroeid tot mijn favoriete (container/cloud) platform. In onze DevOps unit bij CINQ hebben wij aardig wat aandacht besteed aan Kubernetes met interne kennis-sessies, een reis naar KubeCon Europe '18 in Kopenhagen en ons eigen Kubernetes “bootcamp” in Friesland. 

👩‍🏫In twee dagen Kubernetes Advanced training, worden onze DevOps engineers klaargestoomd voor het KCA examen.

Dag 1 zit er bijna op, tijd voor de vrijmibo! 🍻

@container_solutions #kubernetes #containersolutions #joure #cinqict #work #prep #workshop #devops #cinq

Ik wilde graag mijn CKA (Certified Kubernetes Administrator) halen omdat ik in de breedste zin wilde weten hoe Kubernetes precies werkt, in plaats van alleen maar de nodige resources te gebruiken voor deployments. Denk hierbij aan de werking van de controlplane en het gebruiken van alle resources die Kubernetes tot je beschikking stelt. Dat zijn er namelijk nogal wat. Ook is het natuurlijk fijn om te weten dat je een bepaalde techniek beheerst.

Het CKA examen is een examen van 3 uur waar er van je verwacht wordt 24 problemen/vraagstukken op te lossen in verschillende Kubernetes clusters. Een score van 74% is vereist om te slagen. 

- EDIT oktober '20: Sinds kort duurt het examen 2 uur, waarin je 15 tot 20 problemen / vraagstukken op moet lossen en je een score van 66% moet halen om te slagen. Alle andere informatie in deze post is nog steeds relevant. - 

Ik heb het examen pas ingepland toen ik er van overtuigd was dat ik de tijd zou hebben om een paar weken achter elkaar te kunnen studeren en te oefenen. Zeker ook omdat ik meerdere malen heb gehoord dat het een pittig examen is waar je goed gebruik moet maken van je tijd. 

Op 5 juli heb ik mijn eerste examen gedaan. Ik had het gevoel goed voorbereid te zijn. Het examen kan je in je eigen huis/kantoor afnemen, waar je door een toezichthouder via de webcam en screensharing in de gaten wordt gehouden. Het online examen programma werkte prima. 

Ik twijfelde of ik het had gehaald na afloop, omdat mijn KubeADM vraag in de soep liep door een error van de cloudprovider (AWS). Achteraf heeft dit geen verschil gemaakt en is het misschien zelfs nog goed gerekend. Het resultaat kwam pas na 36 uur aan in de mail. Uiteindelijk heb ik toch een score van 91% behaald op mijn eerste poging.

Hoe kun je jezelf nou zo goed mogelijk voorbereiden voor het examen? En welke punten hebben extra aandacht nodig? Hieronder geef ik 10 tips waardoor ik het examen heb gehaald:

1. “Certified-kubernetes-administrator-with-practice-tests” 

Een alles omvattende cursus op Udemy door Mumshad Mannambeth. Zorg dat je de hele cursus hebt doorlopen en maak alle labs in Kodekloud. Alles wat in mijn examen werd gevraagd is behandeld in deze cursus.

Leer de kubectl commandline. Zorg dat je weet welk commando je waarvoor moet gebruiken, get, describe, logs, events, apply, etc.

Je mag de officiële Kubernetes documentatie erbij houden. Maak hier gebruik van door de cheatsheet erbij te pakken of snel te zoeken naar het onderwerp naar keuze.

Bouw een Kubernetes cluster handmatig vanaf de grond op. Alhoewel ik deze niet zo belangrijk vond als dat andere mensen die vonden, is het in ieder geval handig om het een keer te doen. Bovenstaande Udemy cursus heeft een guide om het op je eigen workstation met Vagrant en Virtualbox te doen. 

Bespaar jezelf wat tijd door de “imperative commands” te kunnen van simpele opdrachten. Denk aan: “kubectl run”, voor het deployen van simpele pods, of “kubectl expose” voor het aanmaken van een service die verwijst naar een bestaande pod. Dit zijn geen complexe opdrachten en zijn sneller uit te voeren op deze manier, in plaats van een YAML file te genereren of op zoek te gaan in de documentatie.

Zorg voor de complexere deployments dat je een YAML genereert, hergebruikt uit een eerdere opdracht of gebruikt vanuit de documentatie. Denk aan deployments met secrets of volumes. Gebruik hiervoor de voorbeelden in de documentatie en verander die naar wens.

Sla opdrachten over die je niet meteen weet, en maak deze later. Je hebt misschien de volle 3 uur nodig en elke punt is meegenomen. Vlag bepaalde vragen die je niet zeker weet om later op terug te komen.

Zorg dat je de Docker commando’s en concepten ook kent om te troubleshooten. Soms heb je geen kubectl tot je beschikking. Basic Linux kennis om te troubleshooten en opdrachten uit te voeren zoals: systemctl, nslookup, vi/vim, ps, ls, cp etc. 

Het gene waar CKA zich in onderscheid ten opzichte van CKAD is infrastructuur kennis. Zorg dat je gerelateerde opdrachten hieraan goed kunt maken. Denk aan ETCD backups, het gebruik van KubeADM, controlplane service configuratie en certificaten. Deze vragen zijn vaak veel punten waard en kosten meer tijd.

Controleer elke deployment of pods wanneer je deze hebt aangemaakt. Gebruik met de “get” of “describe” commands of jouw pods/deployments de juiste naam hebben, de juiste images gebruiken en überhaupt draaien en doen wat deze zouden moeten doen.

Met deze zorgvuldige voorbereiding en werkwijze tijdens het examen, heb ik het in één keer weten te halen. Heel veel succes met studeren en het examen, en als je vragen hebt - laat het weten in de comments of neem contact met ons op.

Met deze 10 tips ga je slagen voor je Certified Kubernetes Administroator examen.

10 tips voor het halen van je Certified Kubernetes Administrator examen

Sommige opdrachten kun je gewoon niet weigeren. Wij zijn gevraagd door de Rijksoverheid om te helpen bij het monitoren van de infrastructuur van de CoronaMelder app. Een uitdaging die we graag aan zijn gegaan!

We hebben hiervoor direct onze control room ingericht en inmiddels monitoren we live de performance van de CoronaMelder app.

De app wordt momenteel in een aantal GGD regio's in de praktijk getest, voordat deze straks landelijk wordt ingezet. Het doel van de app is om mogelijke besmettingen eerder te lokaliseren, zodat er eerder getest kan worden en verdere verspreiding wordt voorkomen.

Mooi dat we hier met CINQ een bijdrage aan kunnen leveren!

Meer informatie over de app vindt je op https://coronamelder.nl/

Sommige opdrachten kun je gewoon niet weigeren. Wij zijn gevraagd door de Rijksoverheid om te helpen bij het monitoren van de infrastructuur van de CoronaMelder app.

Monitoring inrichten voor de CoronaMelder app

In de afgelopen periode heeft zich een vrij nieuwe techniek zich aangediend genaamd WebAssembly. Wat kunnen wij ermee en wat zou het kunnen veranderen?

Vrij simpel gezegd is WebAssembly een techniek waarmee je in verschillende talen, dus niet vastgepind op één specifieke taal, iets voor de webbrowser kan ontwikkelen. Het is erop gericht om op een laagdrempelige manier de code te schrijven en hoogwaardige (native) gevoel te creëren. Daarnaast heeft het als doel om gecompileerd te kunnen worden tot een taal die de moderne webbrowser begrijpt. Niet als Javascript code, maar om hiernaast te kunnen draaien. Voorheen kon je alleen met Javascript een volwaardige ‘native’ webapplicatie voor de browser maken. 

WebAssembly kunnen wij zien als aanvulling op de Javascript code. Je kunt deze dan ook prima combineren om het beste uit beide werelden te halen. WebAssembly zegt een volwaardige oplossing te kunnen bieden voor een sterke performance. Wat hun sterk maakt is dat alle moderne browsers de techniek ondersteunen.

WebAssembly gebruik je om een webapplicatie voor de browser te ontwikkelen. Je kunt de componenten van je applicatie schrijven in diverse talen, waarna deze gecompileerd worden naar WebAssembly code. Door middel van de payload kan de browser het uiteindelijk via Javascript begrijpen. Belangrijk om te weten is dat WebAssembly een techniek is en geen nieuwe taal is. Het doet iets wat voor veel developers ongrijpbaar is. 

Met WebAssembly kan je grootschalige dingen als games of tekenprogramma’s bereiken. De vraag is alleen zijn wij al zover? Het geeft ons vandaag de dag wel al de mogelijkheid om bijvoorbeeld een complexe reken functionaliteit uit een andere taal als module over te nemen.

Aan elke techniek of code zitten voor- en nadelen, zo ook bij WebAssembly. Ten eerste geven zij aan geen vervanging te zijn voor Javascript. Zij zien de combinatie van bijvoorbeeld DOM manipulatie veel beter via Javascript gaan en bijvoorbeeld tijdelijk opslaan van data via WebAssembly. Het zou sneller en kleiner moeten zijn dan andere dingen. Volgens de makers zou je zelfs de gecompileerde code – wat zelfs voor Javascript lastig kan zijn – op een eenvoudige manier te debuggen is. De nadelen richten zich vooral op het feit dat het nog steeds geen native code zal zijn. Het voegt ook weinig toe voor de normale webapplicaties. 

Persoonlijk denk ik dat WebAssembly de wereld weer een extra mogelijkheid geeft. Ik zie vooral de voordelen in voor de zwaardere applicaties en niet voor meer ‘user friendly’ webapplicaties met wat data. Hiervoor is bijvoorbeeld de opstarttijd te zwaar, wat al snel weer als nadeel gezien kan worden. Daarnaast zie ik een vervanging van Javascript ook nog niet zo snel gebeuren. Hiervoor moet nog te veel gebeuren op allerlei vlakken. Javascript heeft zich al tientallen jaren bewezen als betrouwbare code voor het web. Kort gezegd geeft het ons weer nieuwe mogelijkheden en zal de toekomst, zoals wel vaker, gaan uitwijzen wat voor effect het heeft. Het zijn in elk geval mooie ontwikkelingen!

Verslaat WebAssembly het gewaardeerde JavaScript? Lees het blog op de CINQ website.

Verslaat WebAssembly het gewaardeerde JavaScript?

In this tutorial you can experiment with a local Kubernetes cluster that can be installed using VirtualBox or another virtualization product. This time we will use VirtualBox and Vagrant to set it all up. The Vagrant file will create one Kubernetes master server and two Kubernetes workers. A loadbalancer will also be created and will be used in our next blog about Traefik. After the installation we use Lens to connect to the created cluster. You must have a minimum of 16 GB of RAM for setting up this cluster.

To get started, make sure you download and install Vagrant, VirtualBox and Lens if you don’t already have them.
Vagrant
VirtualBox
Lens

First, we will install the boxes. In your terminal do the following:

vagrant box add ubuntu/bionic64
==> box: Loading metadata for box 'ubuntu/bionic64'
    box: URL: https://vagrantcloud.com/ubuntu/bionic64
This box can work with multiple providers! The providers that it
can work with are listed below. Please review the list and choose
the provider you will be working with.
 
1) hyperv
2) libvirt
3) virtualbox
4) vmware_desktop
 
# Choose 3) virtualbox


Getting the master, workers and loadbalancer.

git clone https://dennisvermeulen@bitbucket.org/dennisvermeulen/kubernetes-cluster.git

cd kubernetes-cluster/k8smaster
vagrant up
cd ../k8sworker1
vagrant up
cd ../k8sworker2
vagrant up
cd ../k8slb
vagrant up
cd ../k8smaster

vagrant ssh

vagrant@k8smaster:~$ sudo su -
root@k8smaster:~$ kubeadm init --config=kubeadm-config.yaml --upload-certs | tee kubeadm-init.out

Copy config file to communicate with the cluster

root@k8smaster:~$ mkdir -p $HOME/.
kuberoot@k8smaster:~$ sudo cp -i /etc/kubernetes/admin.conf 
$HOME/.kube/config
root@k8smaster:~$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

root@k8smaster:~$ kubectl create -f calico.yaml

root@k8smaster:~# kubectl -n kube-system get pods

NAME                                       READY   STATUS    RESTARTS   AGE
calico-kube-controllers-6b9d4c8765-p9wn7   1/1     Running   0          52s
calico-node-bgklp                          1/1     Running   0          52s
coredns-5644d7b6d9-fmbsb                   1/1     Running   0          71s
coredns-5644d7b6d9-tdn9f                   1/1     Running   0          71s
etcd-k8smaster                             1/1     Running   0          13s
kube-apiserver-k8smaster                   1/1     Running   0          30s
kube-controller-manager-k8smaster          1/1     Running   0          19s
kube-proxy-kknp8                           1/1     Running   0          71s
kube-scheduler-k8smaster                   1/1     Running   0          32s

Join any number of worker nodes by running the following on each as root:
cd ../k8sworker1 
vagrant ssh
sudo -i 

Get the following information out of the kubeadm-init.out for joining the worker in the cluster.

kubeadm join k8smaster:6443 --token pzybeg.5ebv6ct0ts7q0dde \
    --discovery-token-ca-cert-hash 
sha256:b8bac2cb45f9e1e1c9db53dded9be20b3304462dc2586fe7ad5418e034013a58
  
cd ../k8slbvagrant sshsudo -idocker run -d --restart=unless-stopped --name nginx -p 
80:80 -p 443:443 -v /home/vagrant/nginx/nginx.conf:/etc/nginx/nginx.conf 
nginx:latest

Lens is the only IDE you’ll ever need to take control of your Kubernetes clusters. It is a standalone application for MacOS, Windows and Linux operating systems. It is open source and free. After you have installed Lens you can connect to your cluster using the Kubernetes config file, the only thing you have to do is change:

“server: https://k8smaster:6443” to “server: https://192.168.33.20:6443”

vagrant@k8smaster:~$ sudo cat /root/.kube/config

Start Lens and add the config file, don’t forget to change the server into https://192.168.33.20:6443.

Learning and starting with Kubernetes clusters on your local device with Lens is fun and a good starting point to experiment with Kubernetes.

Good luck and feel free to reach out if you have any questions or ideas.

Installing a Kubernetes cluster and connecting it to Lens

Splunk is vooral bekend van haar kracht om inzicht in applicaties te geven, maar wordt vaak ook vanuit security oogpunt gebruikt. Als Splunk consultant kom je daardoor vaak in aanraking met security gerelateerde use-cases. Doordat ik zelf weinig ervaring had met cybersecurity ben ik op zoek gegaan naar mogelijkheden om hier meer ervaring mee op te doen. In dit blog lees je een aantal voorbeelden waarmee ik zelf aan de slag ben gegaan. 

Een van de eerste oefeningen die ik tegenkwam was de website van Over the Wire.
Op de website staan verschillende “war games” waarmee je kunt oefenen met verschillende security concepten. Zo kan je beginnen met de Bandit wargame, deze is volledig gericht op beginners. Tijdens de verschillende levels leer je welke commando’s er in Linux zijn en moet je het wachtwoord voor het volgende level zien te achterhalen. Al snel ben je bezig met base64, openssl, nmap of zelfs een script om een pincode middels brute force te kraken.  

Als je alle Bandit levels hebt afgerond kan je nog 11 andere wargames op de site proberen waarbij het elke keer net een beetje moeilijker wordt. Met deze games leer je een hoop basis skills van security.

Na de oefeningen van Over the Wire, was ik op zoek naar een cursus waar ik theorie en praktijk samen kon brengen. Na verschillende opties die of heel veel geld kostten, of veel ervaring verwachtten, kwam ik uit bij TheCyberMentor.
Na verschillende YouTube videos van hem bekeken te hebben zag ik dat hij ook een Ethical Hacking cursus via Udemy aanbiedt. In de cursus komen veel verschillende onderwerpen aan bod zoals:

En er zit ook een onderdeel in om op de website Hack the Box 10 machines te kraken. De cursus is vooral gericht om informatie meteen toe te passen waardoor je het gelijk in de praktijk brengt. Dit is voor mij de meest prettige vorm van leren en zo blijf ik tijdens de cursus het meest gemotiveerd om door te gaan. Een aanrader!

Na de Ethical Hacking cursus wilde ik ook binnen Splunk verder kijken naar security.
Vanuit Splunk wordt er regelmatig een Boss of the SOC (BOTS) georganiseerd waarbij verschillende teams het tegen elkaar opnemen om binnen Splunk security vragen te beantwoorden door de data te analyseren. Door op deze manier leer je veel over de security mogelijkheden in Splunk.

Een aantal voorbeeldvragen zie je hieronder:

Het voordeel is dat je hier vrij eenvoudig ook zelf mee aan de slag kan gaan. Als je een Linux VM hebt dan kan je de dataset downloaden en de stappen die bij de scoring app staan volgen om je eigen BOTS machine in te richten. 

Hierna kan je op je eigen tempo de verschillende vragen proberen te beantwoorden. Enkele maanden terug hebben wij dit bij CINQ met de v2 dataset gedaan. In 2 teams gingen we aan de slag om te kijken wie de meeste punten kon halen, hierdoor leer je van elkaar. Dit is ontzettend leerzaam én gezellig om te doen met je Splunk team. We hopen dan ook dat we binnenkort een volgende Boss of the SOC sessie met de nieuwe dataset kunnen organiseren.

Naast BOTS is er nog een app die die je op weg kan helpen binnen Splunk en dat is Splunk Security Essentials. Deze app laat zien welke data security gerelateerd is, hoe je dit kan aansluiten en welke use-cases je vervolgens zou kunnen gebruiken. Het voordeel hiervan is dat de use-case wordt uitgelegd, er wordt aangegeven welke data je ervoor nodig hebt, en hoe de search binnen Splunk eruitziet.  Daarnaast zit er ook een MITRE ATT&CK framework in waarmee je kan zien welke use-cases door welke ATT&CK techniek gebruikt kunnen worden en of hiervoor de benodigde data al is aangesloten.

Het voordeel van de app is dat je op een simpele manier kan zien welke use-cases interessant zijn voor je eigen omgeving. Bij mijn opdrachtgever zijn we nu aan het kijken of we de koppeling naar Splunk Enterprise Security voor de MITRE ATT&CK informatie kunnen maken zodat we in Enterprise Security nog meer relevante informatie kunnen zien. 

Deze app heeft ook een demo omgeving die hier te vinden is.  Meer informatie over deze app is te vinden via splunksecurityessentials.com.

Aan de slag met security in Splunk

Bij Visser & Smit Hanab hebben we een review gedaan op de Terraform codebase. 

Bij deze review hebben we de de kwaliteit, complexiteit en technische validiteit van de code beoordeeld, en hoeverre deze gebruikt kon worden in een multi-cloud omgeving (Azure / AWS). 

Het eindproduct van deze opdracht was een rapport met aanbevelingen die de klant met onze hulp heeft geïmplementeerd.

Bij Visser & Smit Hanab hebben we een review gedaan op de Terraform codebase.

Terraform audit bij Visser & Smit Hanab

In de wonderlijke wereld van front-end technologie gaan de ontwikkelingen bijster snel. Het is niet altijd mogelijk om deze nieuwe ontwikkelingen direct toe te passen bij de opdrachtgever. Hier werk je namelijk vaak aan al een bestaande applicatie/project, waardoor je niet altijd direct in staat bent om nieuwe keuzes te maken. Toch krijg ik steeds vaker de vraag wat nu de beste keus is om een toekomstbestendige front-end neer te zetten. Dat vind ik persoonlijk een lastige vraag die ik niet binnen twee minuten kan beantwoorden, omdat dit ook te maken heeft met wensen, tijd, capaciteit en budget. In dit blog deel ik graag één van de keuzes die dit mogelijk zouden kunnen maken, namelijk Web Components. Zal dit de standaard worden en daarmee ook meer toekomstvast? 

In het kort gezegd zijn Web Components geïsoleerde componenten die je kan (her)gebruiken in HTML-pagina’s en webapplicaties. Een Web Component bouw je zonder tussenkomst van een toegevoegde bibliotheek. 

Als developer ben je in staat om je eigen Custom Element te schrijven, wat in principe dus je eigen HTML-element is met zijn eigen CSS en Javascript. Dit element is gebaseerd op web standaarden, waardoor het nu al in de meest gebruikte browsers toegepast kan worden. Ook Microsoft Edge ondersteund sinds januari 2020 dit principe. Dat maakt het bijzonder interessant.

Web components are based on existing web standards. Features to support web components are currently being added to the HTML and DOM specs, letting web developers easily extend HTML with new elements with encapsulated styling and custom behavior.

bron: https://www.webcomponents.org/introduction

Een Web Component bestaat uit vier specificaties, dit zijn:

Custom Elements
Een Custom Element is een HTML-element die je kan toevoegen aan de DOM.

Shadow DOM
Shadow DOM zorgt ervoor dat de styling gespecifieerd kan worden voor alleen dat element.

Es Modules
Het gebruik van ES Modules geeft de mogelijkheid tot het schrijven en gebruiken van modules op een standaard Javascript manier.

HTML Template
Declareer je eigen herbruikbare templates die getoond worden bij de rendering.

Hoe verhouden Web Components zich tot frameworks?

Nu wij simpel gezegd weten dat een Web Component een native component is, nu de vraag hoe deze zich verhoudt ten opzichte van de al bestaande frameworks. Ten eerste de vraag of wij moeten kiezen voor een Web Component, een framework of een combinatie van beiden? Uit mijn eigen ervaring heb ik nooit een combinatie van deze twee gezien. Neem ik het statement van React als voorbeeld, dan herken ik zeker dat elk framework zijn eigen problemen probeert op te lossen.

React and Web Components are built to solve different problems. Web Components provide strong encapsulation for reusable components, while React provides a declarative library that keeps the DOM in sync with your data. The two goals are complementary. As a developer, you are free to use React in your Web Components, or to use Web Components in React, or both. 

bron: https://reactjs.org/docs/web-components.html

Angular geeft zijn eigen invulling door het gebruik van Angular elements. Dat komt neer op een soort van afgeleide Web Component alleen dan met een isolatie van Angular eromheen.

De redenen waarom frameworks zo populair zijn komt omdat deze vaak bestaan uit één of meerdere van de volgende dingen: LifeCycle “de leef status” van het component voor view en data, data binding, routing, templating en herbruikbaarheid. Natuurlijk bevatten frameworks ook voordelen om sneller een applicatie te ontwikkelen, maar is het daarmee altijd de juiste keuze?

Ik denk het niet. Deze frameworks gebruiken namelijk ook gewoon native Javascript om de applicatie te laten runnen. Als voorbeeld neem ik het stukje routing. Zou ik dit zonder framework doen en in combinatie met Web Components, dan gok ik dat ik rond de 100-150 regels code nodig heb om de browser history API aan te sturen.

Natuurlijk is dit maar een minimale vergelijking en zijn er nog tientallen andere vergelijkingen te maken om een verschil aan te duiden. Dat zal alleen voor deze blog veel te veel (rand)informatie geven.

Het is niet zo simpel als dat het lijkt. Web Components zijn niet moeilijk om te ontwikkelen, maar met alle randzaken erbij kom je al snel op flink wat “maatwerk”. Wanneer ga je dan overstag? Ikzelf zie een aantal nuttige dingen.

Wanneer er in een organisatie de nodige applicaties ontwikkeld worden en/of er wordt met meerdere teams gewerkt, dan is het zeer belangrijk om niet in herhaling te vallen. Web Components werken onafhankelijk van andere frameworks. Doordat het zo dicht bij de standaard ligt, zou het dus een optie kunnen zijn om je design system (branding) hierin op te zetten. De componenten kunnen dan in elke willekeurige applicatie gebruikt worden. Een win-win situatie en daarmee dus ook toekomstbestendig? Wie weet.

Wanneer je met ontwikkelaars afspreekt om 1 taal te spreken en schrijven zal dat de kwaliteit van je code ook verhogen. Je kan naar mate de applicatie groeit, nog steeds vastbijten op web standaarden voor HTML, CSS en Javascript. Ik denk dat je ownership kan geven en eisen, maar nog belangrijker kan blijven houden. Daarnaast denk ik dat je als ontwikkelaar ook meer hebt aan het leren van web standaarden dan het leren van een framework.

Als je bereid bent om een investering te doen in Web Components, inclusief het hierboven beschreven “maatwerk”, dan denk ik dat je op termijn geld kunt besparen. Ontwikkelaars zullen namelijk sneller in staat zijn om de business te kunnen bedienen, doordat zij enkel bezig zijn met nieuwe componenten gebaseerd op web standaarden.

De nadelen van het gebruik van Web Components

Hoewel de meest gangbare browsers inmiddels Web Components ondersteunen blijft het toch een redelijk nieuw begrip. Daarom zal je ook rekening moeten houden met de volgende zaken.

Er zijn developers die erbij zweren dat alles per definitie in 1 file zou moeten staan, dus ook de styling van je component. Mijn voorkeur gaat echter om de styling altijd te scheiden van hetzelfde document, maar de styling moet wel alleen voor dat component toepasbaar zijn. Dit is meer een persoonlijke voorkeur, dan een hard argument.

Om een webapplicatie geschikt te maken voor een goede indexbaarheid voor zoekmachines als Google, dan vereist dat wel de benodigde best practices. Voor Google geldt dat de HTML gerenderd moet worden, zodat de bot de informatie kan lezen en begrijpen. 

Wanneer je Web Components gaat gebruiken, dan ben je in meer of mindere mate nog niet af van libraries. Er zijn namelijk een aantal libraries die het leven met Web Components een stuk fijner kan maken, bijvoorbeeld: Hybrids, lit-html, Skate.js, Slim.js of Stencil. Daarnaast is ook Open Web Components een actieve bibliotheek. Kort gezegd ben je dus niet af van het gebruik van third party stuff.

Dat de juiste frontend technologie kiezen een lastig vraagstuk is blijkt maar. Ik heb geprobeerd een kleine inkijk te geven op het gebied van Web Components. Terugkomend op de vraag of deze de standaard worden en toekomstbestendig zijn? Ik denk wel dat Web Components zeker de toekomst hebben. Juist omdat deze op de web standaard gebaseerd zijn. Alleen wanneer is een webapplicatie nu toekomstbestendig? In de afgelopen 30 jaar is er nog geen toekomstvaste applicatie neergezet die eeuwig blijft leven. 

De keuze om voor Web Components te kiezen zou het leven van de applicatie wel kunnen verlengen. Je blijft, voor nu, afhankelijk van libraries die het ontwikkelen makkelijker maken. Daarnaast is het ook nog maar de vraag of Web Components past bij de wensen, tijd, capaciteit en budget van de opdrachtgever. Er zijn nog niet heel veel bedrijven die nu al (volledig) gebruik maken van Web Components. In Nederland is ING er bijvoorbeeld heel actief mee bezig. Kijk je naar de trends van installatie, dan zie je dat lit-html wel aan het groeien is de afgelopen 6 maanden.

Om af te sluiten zie ik dus potentie in het ontwikkelen van Web Components. De vraag ernaar zal gaan toenemen. Ik zal het in elk geval altijd meenemen in mijn afweging tussen een framework als bijvoorbeeld Angular, Vue of Svelte en Web Components. Ik verklaar alleen niet mijn volledige liefde eraan. Op het gebied van front-end development blijven de ontwikkelingen immers nog steeds razendsnel gaan.

In de wonderlijke wereld van front-end technologie gaan de ontwikkelingen bijster snel. Het is niet altijd mogelijk om deze nieuwe ontwikkelingen direct toe te passen bij de opdrachtgever.

Web Components - de toekomst van front-end ontwikkeling?

Sinds 13 november 2019 is GitHub Actions officieel beschikbaar, de nieuwe CI/CD tool van Github. Nu bijna een half jaar verder, ben ik benieuwd hoe dicht Github Actions naar Azure Pipelines is gegroeid qua functionaliteiten maar ook in hoeverre Github Actions al Azure Pipelines kan vervangen. In dit blog zet ik de belangrijkste verschillen op een rij. 

Zowel een Github Action workflow als een Azure Pipeline is een configureerbaar geautomatiseerd proces dat bestaat uit één of meerdere "Jobs". Met dit proces bepaal je de CI/CD flow. 

In beide gevallen word de YAML syntax gebruikt.  Dit word vaak gebruikt voor "Configuration as Code". In dit bestand bepaal je de configuratie van de workflow/pipeline. De locaties van deze bestanden verschilt per oplossing. Bij Azure Pipelines zet je het YAML bestand azure-pipelines.yml in de root folder van het project. Bij GitHub Actions komt deze in de folder /.github/worksflows/<workflownaam>.yml. De YAML bestanden in deze folder worden automatisch opgepakt. Je kan zowel de .yaml of .yml als bestandsextensie gebruiken.

Wil je meer informatie over YAML zie: Learn YAML in five minutes.

Github Actions en Azure pipelines gebruiken voor vergelijkbare stappen soms verschillende benamingen, hieronder een opsomming van de verschillen. Github Actions wordt steeds als eerst genoemd en Azure Pipelines als tweede. 

Een event / trigger is een activiteit welke de Workflow / Pipeline triggert.  

Workflows kunnen net als Pipelines getriggerd worden door het pushen van commits of tags naar specifieke branches in de gekoppelde repository. Maar ook door Pull requests of een scheduled trigger. Naast deze standaard triggers bied Workflows nog een groot aantal activiteiten binnen Github welke de workflow kunnen triggeren. 

Kijk voor een lijst van alle Workflow en Pipeline triggers op Workflow Triggers en Pipeline Triggers.

Azure Pipeline ``stages`` zijn bedoelt om de activiteiten van de pipeline in fases te verdelen. Met gebruik van ``stages`` krijg je de mogelijkheid om de pipeline te pauzeren voor een handmatige check. Bijvoorbeeld wanneer een manager de release van de staging moet goedkeuren voordat deze door mag naar productie.

Github Actions heeft deze mogelijkheid niet. 

Zowel Workflows als Pipelines bestaan uit ``jobs``. Een ``job`` bestaat uit één of meerdere ``steps``. 

Een ``step`` kan bestaan uit een inline-script of een pre-packaged script. binnen Azure Pipelines ook wel een `task` genoemd. Een pre-packaged script is een `action` in Github Actions.

Een ``action`` of een ``task`` is een vooraf gemaakt script die je aan kan roepen in meerdere Pipelines of Workflows. Zowel Github Actions als Azure Pipelines bied built-in en custom ``actions``/``tasks``.

Het idee achter een custom ``action``/``task`` is het beheer van terug kerende activiteiten te versimpelen. Als je bijv. 10 Workflows of Pipelines hebt met een inline-script waar een aanpassing in nodig is. Zul je al die 10 Workflows/Pipelines moeten wijzigen. Met een ``action``/``task`` hoef je alleen de ``action`` of de ``task`` te wijzigen. De aanpassing is gelijk beschikbaar de eerst volgende keer dat de Pipelines draaien. Hierdoor hoef je niet meer al je Pipelines te wijzigen. 

Pipeline ``Tasks`` zijn beschikbaar in de Visual Studio Marketplace. Maar er is ook de mogelijkheid om ze zelf te schrijven.

Community ``Actions`` zijn beschikbaar via de Github Marketplace. Ook ``Actions`` kan je zelf schrijven.

In Github Actions worden ``jobs`` toegewezen aan een ``virtual environment``. Dit kan zowel een Github-hosted of een Self-hosted runner zijn. Je hebt de keuze uit een Windows, Linux of een MacOS enviroment.

Github self-hosted runners zijn nog niet zo heel lang beschikbaar. De belangrijkste verschillen tussen hosted en Github-hosted runners zijn:

Github-Hosted runners bieden een simpelere en makkelijkere manier voor het draaien van workflows. Terwijl self-hosted runners meer configuratie mogelijkheden bieden voor specifieke benodigdheden binnen een workflow.

In Azure Pipelines worden ``jobs`` toegewezen aan ``agent pools``. Een `agent pool` is een groep van gelijke ``agents``. Een ``agent`` kan zowel hosted zijn of self-hosted. Hier heb je dezelfde opties als in Github, Windows, Linux of MacOS. 

Als voorbeeld heb ik een simpele Angular app build pipeline gemaakt voor zowel Github Actions als Azure Pipelines binnen dezelfde repository zodat deze tegelijkertijd triggeren. [^1]  Omdat Github Actions nog geen stages ondersteunt heb ik hier geen gebruik van gemaakt. Hierdoor zijn de YAML bestanden makkelijk te vergelijken.  

name: Build & Publish Angular in Github Action Workflow
on:
  push:
    branches:
      - master
jobs:
  Build_Angular_App:
    runs-on: ubuntu-latest
steps:
    - uses: actions/checkout@v2   
    - uses: actions/setup-node@v1
      with:
        node-version: 12.16.2
      name: Install Node.js
    - run: |
        npm install
        npm install -g @angular/cli
        npm run lint
        npm run build --prod
      name: npm install and build
    - uses: actions/upload-artifact@v1
      with:
        name: Artifact-GithubActionWorkflow
        path: dist/WorkflowvsPipeline
      name: Publish Artifact

 Het resultaat van de bovenstaande Github Actions Workflow: 

name: Build & Publish Angular in Azure DevOps Pipeline
trigger:
  - master
jobs:
  - job: Build_Angular_App
    pool:
      vmImage: 'ubuntu-latest'
    steps:  
      - task: NodeTool@0
        inputs:
          versionSpec: '12.16.2'
        displayName: 'Install Node.js'
      - script: |
          npm install
          npm install -g @angular/cli
          npm run lint
          ng build --prod
        displayName: 'npm install and build'
      - task: PublishPipelineArtifact@0
        inputs:
          artifactName: 'Artifact-AzurePipeline'
          targetPath: 'dist/WorkflowvsPipeline'
        displayName: 'Publish Artifact'

Het resultaat van de bovenstaande Azure Pipeline: 

 Azure Pipelines ondersteunt voor nu nog de classic editor, hoe lang deze nog beschikbaar blijft is onbekend. De classic editor bied de mogelijkheid om je CI configuratie in een GUI te definiëren in plaats van een YAML bestand. Github Actions heeft geen GUI editor en ondersteunt alleen YAML.

Azure Pipelines heeft een marketplace met veel kant en klare Pipelines en extensies. Ook Github Actions heeft een marketplace, maar is nog niet zo uitgebreid als die van Azure Pipelines. Dit zegt nu nog weinig omdat Github Actions nog redelijk nieuw is. Dit zal de aankomende tijd gaan veranderen doordat de github actions community verder zal groeien.

Azure Pipelines is minder strikt in de YAML structuur. Je kan bijv. taak definities weglaten wanneer je Pipeline maar uit één taak bestaat. Je hoeft dan niet de taak te definiëren, alleen de stappen zijn dan genoeg. Github Actions bied deze mogelijkheid niet.

Azure Pipelines ondersteunt ``stages ``, dit is zowel in de Classic editor als YAML beschikbaar. Stages bied de mogelijkheid om deployment workflows in verschillende fases op te delen. Bijv.  Build -> Test -> Staging -> Prod. 

Github Actions bied deze mogelijkheid niet.	

Kan ik Azure Pipelines vervangen door Github Actions?

Om eerlijk te zijn is het antwoord afhankelijk van de functionele eisen. Hoe complex je Workflow/Pipeline moet worden en of je afhankelijk bent van handmatige goedkeuringen van bijv. een manager. Dit verschilt natuurlijk per project.

Als je nog geen Azure Pipelines gebruikt maar wel al Github gebruikt als code repository, en je hebt geen manual approvals nodig, dan is Github Actions de juiste keuze om mee te beginnen.

Mocht je wel al gebruik maken van Azure Pipelines i.c.m. Github Repositories dan zou je bijv. je code kwaliteit checks naar Github Actions kunnen verplaatsen die dan weer je Azure Pipeline triggert wanneer de code voldoet aan alle voorwaarden.

Github Actions is de afgelopen maanden hard gegroeid, en is naast Azure Pipelines een mooie toevoeging aan de bestaande CI/CD tooling. Hou er rekening mee dat er nog vol aan Github Actions ontwikkeld wordt, dit kan betekenen dat de huidige "tekortkomingen" er over een paar maanden niet meer zijn.

Heb je vragen of opmerkingen? Laat het gerust weten!

[^1]: https://github.com/Luukxt8/workflowvspipeline

GitHub Actions vs Azure Pipelines

Sinds gisteravond (27 februari 2020) is het eerste Coronavirus geval in Nederland bekend. Het was een kwestie van tijd tot het virus ook in Nederland zou opdoemen. Vandaag (28 februari 2020) is ook meteen het tweede geval bekend gemaakt. Daarom dacht ik, tijd om eens in de data achter de outbreak van dit virus te gaan duiken om te zien waarom er zoveel ophef is over het Corona virus.

De eerste horde was het verkrijgen van de data. Het startpunt hier was de World Health Organisation, want deze hebben een hele nette website en publiceren elke dag een mooi rapport met daarin op zich goede data[1]. Echter wanneer je deze data moet gaan kopiëren en plakken, dan moet er een hoop in formatting aangepast worden. En 1 keer is dat prima maar ik wil een update-baar dashboard maken dus dat hield op.

Gelukkig ben ik niet de enige die denkt dat het handig is om deze data beschikbaar te hebben in een open format en zo kwam ik bij Isaac Lin van de University of HongKong terecht. Hij post updates van de data op Github[2] en daar kan ik met Splunk heel makkelijk en dankbaar gebruik van maken. Helaas gaat het hier over alleen Chinese data. Superhandig als ik zou willen zien hoe het zich in China verhoudt maar ik mis de rest van de wereld. Dus de zoektocht gaat door…

Uiteindelijk kwam ik uit bij HDX, zij stellen allerlei verschillende data ter beschikking en hebben iedere dag een update van de dataset voor het Coronavirus. In CSV, de hele wereld en met time series data waardoor ook heel goed te analyseren is wat er over tijd gebeurd met het virus. Eindelijk heb ik dus de data. En die kun jij ook gebruiken als je zelf aan de slag wilt [3]. Er zijn 3 databronnen: Confirmed, Deaths en Recovered.

Daarna het analyseren van de data in Splunk. Als eerste de data toegevoegd als lookup tables in Splunk. Het grote voordeel nu is dat wanneer ik nieuwe data toevoeg (en de data is te vinden op Github dus dat kan geautomatiseerd) dit automatisch ook in Splunk beschikbaar is. Daarna ben ik begonnen aan het maken van het overzicht.

Data per region was heel simpel, ik heb de 3 datasets allemaal in de search geladen en gefilterd op alleen data van de laatste dag (2/27/20). Daarna met het geostats commando de inzichten verspreid over de kaart (lat en long data velden waren beschikbaar in de data).

Corona outbreak over time was wat minder makkelijk. In de data is per column weergegeven op welke dag dit gebeurd is. Dit is niet hoe Splunk werkt, want die gaat er van uit dat de datum in de rijen zit en daarom moest dit worden getransformeerd. Gelukkig is hier het commando | transpose voor. Verder nog wat databewerkingen gedaan om te zorgen dat alles er netjes bij staat en met timechart het netjes uitgesmeerd over tijd.

Als laatste heb ik de single values die boven aan staan in het dashboard gemaakt. Het totaal aantal geregistreerde gevallen, de hoeveelheid doden en de recovered waren makkelijke panels om te maken, de death ratio was iets lastiger maar met 2 datasets bij elkaar en dan het percentage berekenen was dat ook prima te doen. De laatste panel geeft netjes inzicht in wanneer de data voor het laatst is geüpdate om dat voor iedereen helder te hebben.

In de glazen bol kijken kan natuurlijk maar gestaafd door de data wordt het natuurlijk pas echt interessant. Hieronder in basis dezelfde grafiek als de Corona outbreak over time in het dashboard, alleen word hier gekeken naar de totalen en niet de landen zelf. Als er dan gekeken word naar de groei in deze grafiek en dit doorgetrokken word dan is goed zichtbaar dat we de komende tijd waarschijnlijk nog niet van Corona af zijn. Volgens dit model passeren we op 5 maart de 100.000 infecties.

De outbreak van Corona gaat hard en loopt naar mate meer mensen geïnfecteerd raken alleen maar sneller op. Dit is natuurlijk een logisch gevolg want hoe meer mensen er besmet zijn hoe meer mensen ermee in aanraking kunnen komen. Het effect lijkt nog behoorlijk mee te vallen, een stijgende lijn is er zeker maar het is geen exponentiële stijging. In de data hebben we gezien dat de death rate van Corona op 3,4% ligt en dit is dan ook waarom er zoveel over Corona gezegd en geschreven wordt. Gewone griep ligt ongeveer op 0,5%[4] en dat maakt Corona een stuk gevaarlijker.

Het RIVM geeft een aantal tips om het Corona virus te voorkomen op de website [5]:

Hoest en nies in de binnenkant van je elleboog

Gebruik papieren zakdoekjes en gooi deze meteen na gebruik weg

Bronnen
[1] https://www.who.int/emergencies/diseases/novel-coronavirus-2019
[2] https://github.com/BlankerL/DXY-COVID-19-Data
[3] https://data.humdata.org/dataset/novel-coronavirus-2019-ncov-cases
[4] https://www.livescience.com/new-coronavirus-compare-with-flu.html
[5] https://www.rivm.nl/coronavirus/covid-19

Corona-virus: een data analyse met Splunk

Recently I finally took the time to dive into the world of Kubernetes with as my ultimate goal to obtain the CKA and CKAD certificates. After I started with quite some theory, I was looking for fun exercises to practice the k8s basics and kubectl, and to get more confident with the manifest yamls. The exercises from Game of Pods were perfect for this.

Game of Pods consists of a number of Katacoda scenarios. All scenarios have some flavour of Game of Thrones, which is just a fun gimmick in which they have put quite some effort, see the introduction video! But what matters more, the scenarios are all good and fun to do! They even made a nice Westeros map where you can choose which assignment you want to do.

For each scenario, you get a description of the desired architecture, a two-node k8s cluster, a terminal with kubectl and one hour to finish it. While you are working you can verify the current state by using the “Check” button. It shows you which part of the architecture is already correct and which part is not.

There are six scenarios. Most architectures consist of a number of “basic” resources such as configMaps, Deployments, Volumes and Services together with one or two more advanced resources such as statefullSets and persistentVolumeClaims, initContainers, RBAC and kubectl configurations. There is one exception, the scenario called Pento. Here you need to show your troubleshooting skills and fix a broken k8s cluster. This is quite challenging but doable and satisfying to solve.

The nice thing about all these scenarios is that each time you practice and speed up the basics and you get familiar with a new advanced subject, all with a nice feedback mechanism.

In the image below you see an example of the desired architecture on the right, and the terminal with a 2-node Kubernetes cluster on the left.

Since my goal is to earn the CKA or CKAD certificate. I have tried to stay within the boundaries of the exam. So I was only allowed to use the official k8s docs and the kubectl help command. This made me discover that kubectl <command> --help actually contains a lot of useful examples.
I also tried to gain some kubectl speed because the exam seems to require that. One thing I found very useful is the output option kubectl <command> ... -o yaml. This prints the yaml produced by the command. For instance kubectl run nginx --image=nginx -o yaml prints the yaml needed to create a Deployment of an nginx Pod. It saves a lot of time writing yaml, it saves you from making annoying yaml typo’s and in some cases, you can benefit from provided cli options and command completion.

Altogether, if you are studying for CKA or CKAD, you should definitely take a look at Game of Pods. It’s a very nice and fun way to practice your skills and prepare yourself.

Visit KodeKloud to start playing right away!

Learning Kubernetes with the Game of Pods

Vakmensen, dat zijn we. En wat we doen op het gebied van informatie- en communicatietechnologie helpt organisaties slim verder. Effectief en meetbaar bovendien. Aangenaam, CINQ. Specialisten in Data, DevOps en Development. Wij geloven in specialisten, vandaar de driedeling Data, DevOps en Development binnen ons bedrijf. Zo zorgen we dat jij excelleert, want je werkt het best waar je je het meest thuis voelt. Logisch, toch?

Onze laatste blogs