In een eerder blogartikel benadrukte ik dat een native app ontwikkelen lange tijd gezien werd als een must. Ik legde de nadruk op de keuzes die je kan maken om de juiste beslissing te kunnen maken. Daarin had ik mij voorgenomen om niet specifiek te richten op de mogelijkheden van native apps. Voorheen werd specifiek ontwikkelen voor Apple of Android als ‘lastig’, ‘duur’ en ‘veel tijd’ ervaren, omdat je dit moest doen in verschillende talen; namelijk Swift en Java/Kotlin. Om dit probleem op te lossen heeft Google een cross-platform gelanceerd genaamd Flutter. Is Flutter daarmee de toekomst van cross-platform native apps?

UI-toolkit voor native compiled applicaties voor mobile, web en desktop

Flutter zet zichzelf in de markt als een UI-toolkit om native compiled applicaties te ontwikkelen voor mobile, web en desktop. Dit doe je door middel van een single codebase, wat wil zeggen dat je één stuk code hebt wat zich laat compileren naar de specifieke platformen die jij wenst. Om een Flutter app te ontwikkelen zal je de (vrij) nieuwe programmeertaal Dart je eigen moeten maken. Flutter leent zich ervoor om snel te ontwikkelen door Stateful Hot Reload en ben je de baas over elke pixel van de applicatie. 

Dart lijkt enigszins op een combinatie tussen Java/C# en Javascript. Het verdeelt zichzelf over drie verschillende eigenschappen. Een geoptimaliseerde UI, productieve development ervaring en snelle performance op alle platformen. Dart is – volgens wat zij zelf schrijven – makkelijk om te leren. Je kunt gemakkelijk code (on)afhankelijk van elkaar maken. Door middel van je eigen editor kan jij dingen als debugging snel voor elkaar krijgen. Ook passen zij AOT-compile toe om zo de juiste performance ervaring te bereiken. 

Voor meerdere platformen (snel) ontwikkelen vanuit een single codebase

Ook mogelijkheid tot het compileren van een native desktopapplicatie

Voorzien van een herkenbare/vergelijkbare architectuur

Beschikbare widgets zijn getest en makkelijk te gebruiken

Dart-code het meest dicht bij het native platform

Regelmatig breaking changes, onderhoud kan een uitdaging zijn

Geen mogelijkheid tot specifieke UI voor verschillende platformen

Programmeren in Dart vereist een leer curve, maar makkelijk te leren

Niet volledige mogelijkheden kunnen benutten van de telefoon

Niet de eerste keuze voor kleine apps (compileert veel)

Als je kijkt naar de voor- en nadelen, dan zie je gelijkenissen met andere hybride frameworks. De juiste keuze hangt af van ervaring, doelen en vereisten. Flutter zou ik overwegen wanneer de focus echt ligt op performance. Het is hoe dan ook sneller dan oplossingen die door middel van een webview wordt geladen. Door de vele breaking changes zou ik eerder neigen bij grotere apps voor een andere oplossing (bijvoorbeeld React Native) te kiezen. Het heeft – net als vele anderen frameworks – zeker potentie. Nogmaals verwijzend naar mijn eerdere blogartikel, voeg daarbij Flutter zeker toe als optie.

Lost Flutter het probleem op om niet meer per platform te hoeven ontwikkelen? De mogelijkheden zijn er, maar is Flutter de toekomst?

Is Flutter de toekomst van cross-platform native apps?

Sinds Docker Enterprise is overgenomen door Mirantis is de naamgeving van het productportfolio compleet aangepast. Docker Enterprise heet tegenwoordig Mirantis Container Runtime, Universal Controle Plane (UCP) heeft de naam Mirantis Kubernetes Engine (MKE) gekregen en Docker Trusted Registry (DTR) heet Mirantis Secure Registry (MSR). 

Voor een opdracht bij een klant waar de omgeving voor 95% bestaat uit Windows Server 2019 en .NET als ontwikkel taal wordt gebruikt, is Linux een vreemde eend. Wat de opdracht interessant maakt was dat .NET containers gingen landen op Windows Server 2019 Core.

Dit in combinatie met een nieuwe Linux omgeving, waar MCR\MKE en MSR op geïnstalleerd werd. Om dit voor elkaar te krijgen zijn we aan de slag gegaan met Ansible-playbooks. Binnen de organisatie had men kennis hiervan, dus het toepassen van infrastructuur als code was bekend.  In deze opdracht zijn verschillende Ansible-playbooks gemaakt, waaronder het hardenen van de Linux omgeving zodat voldaan werd aan het security beleid. De betreffende playbooks werden in een repository geplaatst zodat versie beheer kon worden toegepast.

Het onderstaande voorbeeld werd o.a. gebruikt voor het het opzetten van de verschillende MKE-Clusters, d.m.v. Ansible code. Door gebuikt te  maken van de playbook kun je met 1 druk op de knop een MKE single node cluster opzetten, inclusief MSR en een Linux worker Node. Hoe we dit gedaan hebben leg ik hieronder uit. 

Om met de tutorial aan de slag te gaan heb je een PC of laptop met minimaal 16GB geheugen nodig, Vagrant en VirtualBox dient geïnstalleerd te zijn.

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

cd mirantis-cluster/

mirantis-cluster % vagrant up 

Installatie MKE/MSR met behulp van Ansible

mirantis-cluster % vagrant ssh vm1

[vagrant@cinqmke ~]$ cd ansible-mke-msr-wor/

[vagrant@cinqmke ansible-mke-msr-wor]$ ansible-playbook -b -K -i vm_hosts site.yml

BECOME password: vagrant 

Nadat alles ingesteld is via Ansible krijg je de onderstaande output.

Nu kun je inloggen in Mirantis Kubernetes Engine (MKE) en Mirantis Secure Registry met username “admin” en password “welcome01”.

Kies Next en plak onderstaande code in het veld Add Application File.

version: '3.7'
services:
  nginx:
    image: nginx:latest
    ports:
      - target: 80
        published: 5000
        protocol: tcp
        mode: host

Kies Create, wacht en ga naar de volgende URL http://192.168.33.72:5000. Als het goed is zie je dan de bevestiging dat nginx draait. 

Door het bestand vars in de directory ansible-mke-msr-wor/group_vars/ aan te passen heb je grip over de verschillende versies. Zie hiervoor ook: https://docs.mirantis.com/containers/v3.1/dockeree-release-notes/index.html

Wanneer je gebruik wilt maken van een MKE multinode cluster pas je het vm_host bestand aan in de directory ansible-mke-msr-wor.

Ruim de omgeving op, ga hiervoor als volgt te werk.

[vagrant@cinqmke ansible-mke-msr-wor]$ exit
mirantis-cluster % vagrant destroy
    vm3: Are you sure you want to destroy the 'vm3' VM? [y/N] y
==> vm3: Forcing shutdown of VM...
==> vm3: Destroying VM and associated drives...
    vm2: Are you sure you want to destroy the 'vm2' VM? [y/N] y
==> vm2: Forcing shutdown of VM...
==> vm2: Destroying VM and associated drives...
    vm1: Are you sure you want to destroy the 'vm1' VM? [y/N] y
==> vm1: Forcing shutdown of VM...
==> vm1: Destroying VM and associated drives…


 Pas het bestand aan, zoals hieronder aangegeven.

 mirantis-cluster % vi ansible-mke-msr-wor/vm_hosts


### MKE
[mke_main]
cinqmke ip_addr='192.168.33.70'

[mke]
cinqmke ip_addr='192.168.33.70'
cinqmsr ip_addr='192.168.33.71'
cinqwor ip_addr='192.168.33.72'

### MSR
[msr_main]
#cinqmsr ip_addr='192.168.33.71'

[msr]
#cinqmsr ip_addr='192.168.33.71'

### WORKER
[worker]
#cinqwor ip_addr='192.168.33.72'

mirantis-cluster % vagrant up 

Opnieuw installeren m.b.v. Ansible en je krijgt een multinode cluster:

mirantis-cluster % vagrant ssh vm1
[vagrant@cinqmke ~]$ cd ansible-mke-msr-wor/
[vagrant@cinqmke ansible-mke-msr-wor]$ ansible-playbook -b -K -i vm_hosts site.yml
BECOME password: vagrant
 

Met behulp van Ansible playbooks kun je met 1 druk op de knop een volledig MKE/MSR single- of multinode cluster opstarten en dit allemaal zonder al te veel inspanning. Ik hoop dat je er met deze tutorial uit komt. Als je vragen hebt, neem gerust contact met me op via email. 

In deze tutorial ga je met behulp van Ansible een multi-node Mirantis Container Engine (voorheen Docker Enterprise) cluster opzetten.

Met Ansible een Mirantis Container Engine cluster opzetten

In mei is Splunk 8.2 gelanceerd en in deze blogpost licht ik een aantal van de nieuwe functionaliteiten toe. Vooral Federated Search en Dashboard Studio zijn de moeite waard om je een paar uur in te verdiepen. 

Eindelijk daar is 'ie dan: Federated search! Met federated search kunnen search heads (clusters) zoeken in verschillende Splunk omgevingen. Er kan bijvoorbeeld een mix gemaakt worden van on-premise en cloud Splunk instances. Voor klanten met grote omgeving waarbij meerdere cloud providers gecombineerd worden met een deel on-premise is dit een hele handige functie. Zo kan data binnen de omgeving blijven waar deze al is maar kan wel in 1 Splunk omgeving (search head) doorzocht worden. In de afbeelding hieronder is schematisch weergegeven hoe dit werkt. De search head maakt verbinding met de federated provider 1 en kan hiermee via de search head in dat cluster de data in de indexers doorzoeken. Ook is het mogelijk remote datasets te kunnen gebruiken. Die datasets zijn erg interessant want hiermee is het ook mogelijk om lokale lookup files uit te kunnen lezen in een ander cluster. Erg handig wanneer er bij 1 klant meerdere search head clusters zijn (vaak het geval wanneer de klant 1 of meerdere enterprise apps draait zoals Enterprise Security of ITSI).

Meer informatie over hoe dit technisch in elkaar steekt staat hier.

Iedereen die wel eens met Splunk werkt weet dat het dashboard maken best prima werkt zolang je een standaard dashboard maakt. Maar als je iets buiten de gebaande kaders wil dan moet je aan de gang met zelf geschreven CSS en JavaScript. Werkt redelijk maar echt top werkt het niet. Daar is Splunk zelf inmiddels ook achter en daarom hebben ze dashboard studio gelanceerd. In dashboard studio kun je met een makkelijke interface gave dashboards zoals hierbeneden maken. Top om binnenkort op een regenachtige vrijdag middag eens even mee te spelen!

Backup & restore KVstore; niet nieuw maar wel fors verbeterd.


Durable search; waarmee kan worden geforceerd dat scheduled reports/alerts opnieuw uitgevoerd worden als de results incompleet zijn.


Improved handling of JSON; de functies json_array_to_mv, mv_to_json_array, json_append function en json_extend zijn toegevoegd. 

Voor het complete overzicht van alle nieuwe features in Splunk 8.2, bekijk de  Splunk Docs.

Splunk 8.2 is nog niet productie ready (ik zou dan nog even wachten tot 8.2.1) maar voor de testomgeving is dit zeker al aan te raden!

Maak gebruik van de Python Update Readiness app om te bepalen of je omgeving klaar is voor het uitfaseren van Python 2.7.

In mei 2021 is Splunk 8.2 gelanceerd en in deze blog bespreken we twee mooie nieuwe features: Federated Search en Dashboard Studio.

Federated Search in Splunk 8.2

Federated search nu beschikbaar in Splunk 8.2

Soms vraag ik mijzelf wel eens af of ik energie moet blijven steken in de verschillende frameworks, in het bijzonder Angular. De wereld gedraagt zich zoals deze gevormd wordt door ons als ontwikkelaars. Er is altijd wel weer wat nieuws, maar hoe zorg je dat je op de hoogte blijft van alles? Als ervaren front-end developer probeer ik bij te blijven in deze ontwikkelingen, maar pin ik mij niet vast aan een bepaald framework. Simpel gezegd leer ik de concepten van het ecosysteem van de frameworks en focus ik mijzelf altijd op de native kant van Javascript.

Terug naar het onderwerp; Angular. Om met de deur in het huis te vallen is het (nog steeds) een keuze die je als organisatie kan maken. Het framework is niet uitgestorven in tegenstelling wat je sommige soms hoort zeggen. Kijk je puur ter vergelijking van de downloads via NPM dan heeft Angular niet gewonnen en niet verloren. Op basis van de sterren kan je bepalen of iets populair is, daarin blijft Angular achter ten opzichte van een React of zelfs Vue. Het aantal issues is bij Angular vele maler groter dan bij de andere frameworks. Het biedt meer, dus er zijn meer bugs of feature requests.

Een aantal jaar geleden heeft het team van Angular besloten om elk halfjaar met een nieuwe versie (major) te komen. Sinds de eerste stabiele release medio 2016 zitten wij anno 2021 op versie 12. Hoewel het als major-release wordt uitgerold bevatten deze nauwelijks breaking changes. Door middel van de update guide kan je gemakkelijk van versie 6 naar 8 of van 8 naar 12 updaten. 

De ontwikkeling van Angular staat allesbehalve stil. Dat zie je vervolgens ook terug in de verbeterpunten en functionaliteiten die zijn toegevoegd. In versie 6 was de belangrijkste changes om de meest gebruikte third party packages eveneens mee te laten bewegen in de update cycles van Angular. Vanaf versie 8 stond performance en bundle sizing centraal, waar je in versie 9 het alom bekende ‘Ivy compiler and runtime’ als standaard werden gesteld. Last but not least in versie 12 hebben zij onder andere gewerkt aan het (beter) beschikbaar maken van libraries zodat functionaliteiten herbruikbaar kunnen zijn.

Als laatste punt waar ik stil bij wil staan is dat Angular een duidelijke roadmap beschikbaar heeft gemaakt. Momenteel zijn zij bezig met het versnellen van de unit test tijden. Kijk je verder naar waar zij nu mee bezig zijn, dan zie je daar een aantal interessante dingen op staan als bijvoorbeeld het verbeteren van toegankelijkheid van de components of het bijwerken van de end to end test strategie.

Mijn conclusie is dat Angular heel veel in zich heeft waarbij je ook voor de komende jaren prima mee vooruit kan. Dat wil niet zeggen dat het altijd de keuze is die het meest aansluit. Er zijn genoeg redenen (tijd/budget/kennis/doel/organisatie) om te kiezen voor een ander framework, dat zijn voor mij ook de belangrijkste redenen om mij te blijven verdiepen. Zoals ik eerder al schreef. Er is voor mij geen bepaald framework wat voor mij het belangrijkste is, zolang ik maar de context en concepten van de andere frameworks maar niet vergeet. Bijvoorbeeld dat de CINQ-website is ontwikkeld met Next.js en Prismic. Stay informed, je bent nooit te oud om te blijven leren!

Wat is de toekomst van Angular? En waarom gebruik ik het nog? Het blijft (nog steeds) een optie.

Waarom ik nog steeds Angular gebruik, maar ook andere frameworks niet vergeet

Recently I was asked to give a demo about PKI using HashiCorp Vault. Everyone with some history in Ops knows the painful manual work for renewing TLS certificates, putting it on the server and maybe even restarting your application or web server. This is the main reason why such certificates are often valid for one or even two years. So to show the power of having an API to manage your PKI and request certificates, I created a demo where you can completely automate the renewal of TLS certificates for your app on Kubernetes, using both Vault and Cert-Manager.

We will use Minikube to create a Kubernetes cluster where we can run Vault, Cert-Manager, Minikube's ingress controller and a webapp, where:

Vault will give us an API to request certificates for our own PKI.

Cert-Manager will manage the renewal of our certificate.

The ingress will expose our webapp on HTTPS.

We will first setup the prerequisites for demoing this certificate renewal automation:

Once the prerequisites are met, we are ready for the demo part which consist of:

Setup Cert-Manager and request certificate

Virtual Box. Ingress works pretty nice for Minikube with a vm driver. I use virtual box as a vm driver, but you can also choose other Minikube vm drivers.

I won't go into all the details of these prerequisites, but discuss only what we need.

Create Minikube cluster with ingress addon

minikube start --driver=virtualbox

minikube addons enable ingress


To install Vault we use Helm and just follow the docs from HashiCorp.

helm repo add hashicorp https://helm.releases.hashicorp.com
helm repo update
helm install vault hashicorp/vault \
    --set "injector.enabled=false"

# Get vault pod
kubectl get po vault-0

Wait for the vault-0 pod to get healthy and then unseal Vault. We write the Vault key to a file, so we can retrieve it when necessary. (This is clearly very insecure, but ok for this blog.)

# Create Vault unseal key
kubectl exec vault-0 -- vault operator init -key-shares=1 -key-threshold=1 -format=json > /tmp/demo-keys.json
cat /tmp/demo-keys.json | jq -r ".unseal_keys_b64[]"

# Unseal Vault
VAULT_UNSEAL_KEY=$(cat /tmp/demo-keys.json | jq -r ".unseal_keys_b64[]")
kubectl exec vault-0 -- vault operator unseal $VAULT_UNSEAL_KEY

We will often want to execute Vault CLI commands and can use the vault-0 pod to execute those. For instance like this:

# Get Vault token from our file
VAULT_TOKEN=$(cat /tmp/demo-keys.json | jq -r ".root_token")

# Get a shell in vault-0 pod with VAULT_TOKEN as environment variable
kubectl exec vault-0 -ti -- /bin/sh -c "VAULT_TOKEN=$VAULT_TOKEN sh" 

# Vault CLI example
vault token lookup

# Exit pod
exit

We enable Kubernetes Auth Method and connect our Kubernetes cluster with Vault. For now it is enough to know that

We will grant the Kubernetes service account issuer access to Vault

In this pki policy, the endpoints of our PKI engine are defined.

Note that these issuer service account and pki policy do not exist yet, that is fine, we will create them later.

# Prepare Vault CLI in `vault-0` pod
VAULT_TOKEN=$(cat /tmp/demo-keys.json | jq -r ".root_token")
kubectl exec vault-0 -ti -- /bin/sh -c "VAULT_TOKEN=$VAULT_TOKEN sh"

# Enable Kubernetes Auth Method
vault auth enable kubernetes
vault write auth/kubernetes/config \
    token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
    kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443" \
    kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

# Policy pki: read access to pki paths
vault policy write pki - <<EOF
path "pki*"                        { capabilities = ["read", "list"] }
path "pki/roles/example-dot-com"   { capabilities = ["create", "update"] }
path "pki/sign/example-dot-com"    { capabilities = ["create", "update"] }
path "pki/issue/example-dot-com"   { capabilities = ["create"] }
EOF

# Create Kubernetes Auth Method role: Grant service account `issuer` access via the `pki` policy
vault write auth/kubernetes/role/issuer \
    bound_service_account_names=issuer \
    bound_service_account_namespaces=default \
    policies=pki

# Exit pod
exit 

We will deploy a webapp and expose it with ingress, so it can use our TLS certificate to receive traffic over HTTPS.

For our ingress we use the domain name demo.example.com and a Kubernetes secret demo-example-com-tls where we will store our certificate.

Note: This Kubernetes secret demo-example-com-tls doesn't exist yet, but that is fine, we will create it later.

# Deploy webapp
kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0
# Create service
kubectl expose deployment web --port=8080
kubectl get service web

# Create ingress
cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  tls:
  - hosts:
    - demo.example.com
    secretName: demo-example-com-tls
  rules:
  - host: demo.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web
            port:
              number: 8080
EOF

This ingress will get an external IP address (this can take some time) and since we use Minikube with a vm driver, this external IP address is equal to the IP of the vm.

# Show ingress external IP and Minikube's IP
kubectl get ingress
minikube ip

To make the demo more pretty, we will add this ip to our /etc/hosts file so we can browse to our domain.
Edit your hosts file with sudo vi /etc/hosts, like this:

# PKI Demo 
192.168.99.128 demo.example.com

You can then browse to https://demo.example.com, or use curl to go to our webapp.

The ingress controller will serve a default self-signed certificate since we did not configured any certificate yet.

# Ignore invalid cert
curl --insecure https://demo.example.com
# Show tls handshake details
curl -kivL https://demo.example.com

We have Vault running and connected to our Kubernetes cluster and we have a webapp exposed via ingress.

We are now ready to automate certificate renewal by:

We will enable PKI in Vault. For most settings the default values suffices for this demo, we only:

Give the root CA certificate a name which we can recognize: Demo Root Certificate Authority

With this Vault pki role we define what kind of certificates we are allowed to request, in this case: certificates for example.com and all it's subdomains and, most importantly, with a maximum time to live of 3 minutes: max_ttl=3m.

# Prepare Vault CLI in `vault-0` pod
VAULT_TOKEN=$(cat /tmp/demo-keys.json | jq -r ".root_token")
kubectl exec vault-0 -ti -- /bin/sh -c "VAULT_TOKEN=$VAULT_TOKEN sh"

# Enable PKI secret engine
vault secrets enable pki

# Generate root CA (and write to file)
vault write -format=json pki/root/generate/internal \
    common_name="Demo Root Certificate Authority" > /tmp/demo-root-ca.json
cat /tmp/demo-root-ca.json

# Configure pki api endpoints
vault write pki/config/urls \
    issuing_certificates="http://vault.default:8200/v1/pki/ca" \
    crl_distribution_points="http://vault.default:8200/v1/pki/crl"

# Create `pki` role to create certificates for example.com and all subdomains and with a maximum time to live of 3 minutes.
vault write pki/roles/example-dot-com \
    allowed_domains=example.com \
    allow_subdomains=true \
    max_ttl=3m

# Exit pod
exit

Now that we have an api to request certificates, we can start using it.

We will deploy Cert-Manager and configure Vault to be the issuer of the certificates. When that is done, we can define our certificate and Cert-Manager will request and renew the certificate when it will expire.

We install Cert-Manager v1.3.0 with Helm and just follow the docs from Jetstack. This will install Cert-Manager in a separate namespace and also install it's custom resource definitions CRD's.

kubectl create namespace cert-manager
helm repo add jetstack https://charts.jetstack.io
helm repo update

# Install Cert-Manager 
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --version v1.3.0 \
  --set installCRDs=true

# View pods
kubectl get pods --namespace cert-manager

# View CRD's
kubectl get customresourcedefinitions.apiextensions.k8s.io

From the CRD's we will use Issuer and Certificate.

First with CRD Issuer, we can define the issuer of the certificates. Recall the Kubernetes Auth Method configuration, where we granted the Kubernetes service account issuer access to our pki api endpoints. Hence we create a service account issuer in Kubernetes. We then define the Issuer CRD with a.o.:

Connect it to the Vault server http://vault.default (to the pki/sign/example-dot-com uri in particular)

Authenticate via the token of our issuer service account

# Create service account
kubectl create serviceaccount issuer

# Token of service account `issuer`
ISSUER_SECRET_REF=$(kubectl get serviceaccount issuer -o json | jq -r ".secrets[].name")

# Define issuer
cat <<EOF | kubectl apply -f -
apiVersion: cert-manager.io/v1alpha2
kind: Issuer
metadata:
  name: vault-issuer
  namespace: default
spec:
  vault:
    server: http://vault.default
    path: pki/sign/example-dot-com
    auth:
      kubernetes:
        mountPath: /v1/auth/kubernetes
        role: issuer
        secretRef:
          name: $ISSUER_SECRET_REF
          key: token
EOF

# Show issuer
kubectl get issuer

Second, with CRD Certificate, we can define our TLS certificate, with:

Name of the Kubernetes secret, where the certificate needs to be stored: demo-example-com-tls

Specify at which issuer the certificate needs to be requested: vault-issuer

Define properties of our certificate:
undefined

# Define certificate
cat <<EOF | kubectl apply -f -
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
  name: demo-example-com
  namespace: default
spec:
  secretName: demo-example-com-tls
  issuerRef:
    name: vault-issuer
  commonName: demo.example.com
  dnsNames:
  - demo.example.com
EOF

# View certificate CRD
kubectl get certificate

Cert-Manager can now request this certificate at our issuer. Once that is done, you will see that a new secret is created.

# See the request in the events
kubectl describe certificate demo-example-com

# New secret
kubectl get secrets demo-example-com-tls

We are done! Let's check if we can see our new TLS certificate.

Cert-Manager using this pki api to request a certificate

the certificate is stored as a Kubernetes secret demo-example-com-tls

Ingress gets demo-example-com-tls and uses it to enable TLS on our webapp

When we now browse to https://demo.example.com, or use curl to go to our webapp, we still get an invalid certificate. But when we look closer to the certificate, we see that it is a certificate from Vault.

In this blog our engineer Eric shows you how to automate the renewal of TLS certificates with Vault and Cert-Manager, running on a Kubernetes cluster.

How to automate the renewal of TLS certificates with Vault and Cert-Manager on Kubernetes

Automate the renewal of TLS certificates with Vault and Cert-Manager

In 2021 Java celebrates its 25th anniversary. As part of this anniversary Oracle offered to register for the Java SE 11 Developer exam for only 25 dollars (22 euros). This is an interesting offer, because normally this will set you back ten times as much. So I decided to go for it and to give it a shot. This offer was valid for two months, so there was a deadline to keep me focussed on my goal. In this blog I will give you some tips to pass this exam.

Before I get to this a little bit more background on myself. I did the Java 8 OCA exam in 2017 (so four years ago). Please note that this was the OCA version. The OCA version is a lot simpler than the OCP version. It will test you on far less topics. The Java SE 11 Developer is comparable to the former OCP versions.

Because of my previous experience I already knew about the kind of questions you can expect. The questions are, to put it mildly, misleading. The exam tries to trip you up with really obscure notations and almost correct options. To give an example, does the following line compile?

public static void main (String []args) {}

All Java developers recognise this as the main entrypoint of a Java program. Most developers will frown their brows on the part between the parentheses. Normally we see one of the following:

I had never seen String []args before, but apparently it is allowed, so it does compile. Most questions contain several of these “interesting” cases.

So to pass this (or any other Java exams) you have to become a human compiler. You need to know if code will compile or not. Half of the questions have an option that says the code will not compile. 

The first question is: Where should I start? 

Tip 1 - OCP Java SE 11 Developer Complete Study Guide

I used and recommend the Oracle Certified Professional Java SE 11 Developer Complete Study Guide from Jeanne Boyarsky and Scott Selikoff. This book has around 1300 (!) pages, but it has all the information that you need. It has the depth that you need to become the aforementioned human compiler. Furthermore it is also brimming with questions to test your knowledge and sharpen your skills. 

This book also comes with an online test environment in which you can customize the kind of exam you like to do. For instance you can specify that you only want questions about exceptions or security. You can also create an exam with only x questions or one that only contains questions that you incorrectly answered in the past. A great tool to prepare effectively. 

Tip 2 - Do not underestimate the difficulty of this exam.

The exam was much more difficult than I expected when I started this adventure. It took far more time and effort than I had planned to commit to this. In the intro of this blog I mentioned passing for the OCA 8 exam. I had to study quite a lot for this exam, but leading up to the exam I was pretty confident that I would pass. For this exam I studied thrice as hard and I could not predict the outcome. So in the end I put in about 120 hours to fail at my first attempt. 😞

Tip 3 - Practice a lot (and then even more)

After spending sixty hours on studying I took my first mock exam and I failed gloriously. I only answered 40 percent of the questions correctly. The exam asks really in depth stuff, so for me just studying was not enough. I had to practice and practice to familiarize myself with all the nooks and crannies of the Java language. So I spend another sixty hours doing as many practice questions and mock exams as humanly possible. I had to do the exam twice and I barely passed it the second time. 

Tip 4 - Look at the answers before reading the rest of question

All previous tips are about preparing for the exam. The last tip will be about the exam itself. It consists of 50 questions and you have to answer them in 90 minutes. That is 108 seconds per question. That is a scary little amount of time when you have to parse 15 lines of code. Normally you start with checking if the code compiles. So you start looking for compile errors. Once you have done that you try to understand what the code does. The code will not be straight forward. There will be strange constructs in there. There will be things that do not make sense in the real world. Finally you have to find the correct answer. This is a pretty tall order to complete in 108 seconds. Actually I was not able to do it consistently. So I had to change my approach. 

I started looking at the answers before I read the question and this really sped me up. Maybe there is no answer option that says that it does not compile. So you do not have to check for compile errors. Maybe there is an answer option that says it will give a compile error at a given line. Now you can check this line for obvious errors. These are only two examples, but you can get a lot of information from the possible answers. So use this information to your advantage to get the correct answer faster. 

Thank you for reading this blog and good luck passing the exam!

The Java SE 11 Developer exam is a tough cookie. Read our 4 essential tips to help you pass the exam.

4 Tips to pass the Java SE 11 Developer exam

We schrijven allemaal wel eens code die op een later moment een punt van frustratie wordt voor onszelf, of onze collega’s. Soms copy-paste je een stuk code (dupliceren) en komt het er niet van om dit op te schonen. Of je maakt een ontwerp beslissing die in eerste instantie goed lijkt, maar waarvan later blijkt dat het een tijdrovende fout is geweest. 

In deze blog zal ik twee grote frustratiepunten beschrijven, met de focus op Java, wanneer je code probeert te veranderen: dupliceren (copy-pasten) en het onnodig koppelen (coupling) ten gevolge van overerving (inheritance). 

Het kan erg frustrerend zijn wanneer je denkt klaar te zijn met het aanbrengen van een verandering, om er dan achter te komen dat je dezelfde verandering op een tiental andere plekken in je code moet herhalen, voordat het goed zal werken. 

Tijdens het ontwerpen van een systeem, zou je altijd het DRY principe moeten volgen: Elk stukje kennis moet een enkele, eenduidige, belangrijke vertegenwoordiging hebben binnen een systeem. Echter, betekent dit niet dat elke identieke regel tekst of code een duplicaat is. Het kan ook gewoon zo zijn dat de implementatie identiek is. 

DRY gaat over het dupliceren van kennis, die onder andere voorkomt in:

Vaak vergeet men dat documentatie ook geüpdatet moet worden, samen met de veranderingen die je maakt aan je codebase. Het enige wat erger is dan geen documentatie, is verkeerde of verouderde documentatie. Verouderde documentatie kan misleidend zijn en kan je een hoop extra werk kosten. 

Commentaar, of ‘comments’, is slechts een andere vorm van duplicatie. Functies en variabelen met duidelijke namen hebben geen comments nodig. Comments binnen methodes zijn een teken dat de methode te lang is. Deze zouden opgedeeld moeten worden in aparte methodes, met duidelijk beschrijvende namen.

Developers die niet weten wat hun teamgenoten aan het bouwen zijn, lopen het risico om vergelijkbare code te schrijven. Hierdoor dupliceren ze onbewust functionaliteit die al bestaat. Dit kan alleen worden verminderd door betere communicatie. Actieve en frequente communicatie tijdens de dagelijkse stand-ups, forums, etc. Het is dan ook verstandig om de source code en documentatie van anderen te lezen tijdens code reviews of informeel. 

En dan nu: duplicatie in code. Het is het beste om klein te beginnen met het verwijderen hiervan. Allereerst lokaliseer en verwijder je kleinere stukjes gedupliceerde code in aparte methodes. Hierdoor wordt het makkelijker om daarna de grotere stukken van gedupliceerde code te lokaliseren en verwijderen. Vergeet niet om test units te draaien na elke grote verandering, zodat je niet elke keer te veel werk moet terugdraaien. 

Verplaats gedupliceerde code van verschillende klassen, naar zijn eigen klasse.  Na het verwijderen, moet de nieuwe klasse gekoppeld worden aan de klasse die gebruikt wordt. In Java heb je twee opties:

• Optie 1:een 'has a'-relatie. De originele klassen kunnen een fractie van de nieuwe klasse krijgen als een private attribute. Dit wordt ook wel composition of delegation genoemd, omdat je functionaliteit delegeert aan componenten van een andere klasse.

• Optie 2: Een "is-a" -relatie. De originele klassen kunnen de nieuwe klasse uitbreiden.

Het belangrijkste om rekening mee te houden wanneer je een implementatieoptie kiest, is: Erfbelasting. Je moet nog een verandering maken en denkt dat je klaar bent. Maar helaas, je komt erachter dat je zojuist de code op een tiental andere plekken hebt gebroken, omdat meerdere klassen sterk met elkaar gekoppeld zijn.

Gelukkig zijn er een aantal goede methodes als het gaat om het verminderen van onnodige koppelingen. Eén daarvan is: Betaal geen erfbelasting. Inheritance/overerving is een vorm van koppeling en moet dus vermeden worden indien mogelijk. 

Waarschijnlijk is dit niet wat je geleerd hebt. Inheritance gebruiken voor gedragssamenstelling en polymorfisme is een gangbare praktijk die je in elk OOP-handboek aantreft. In de praktijk heeft het echter een aantal ernstige nadelen.

Allereerste: dit zul je je misschien niet realiseren, maar wanneer een klasse is overerft, ontstaat er koppeling tussen meerdere concrete classes. Een kind klasse is gekoppeld aan een ouder klasse, een "grootouder klasse" enzovoorts. Maar elk object dat dit kind klasse gebruikt, is ook gekoppeld aan al zijn voorouders. 

Ten tweede: in een beperkt domein is het logisch dat een auto een soort voertuig is. Maar zodra het domein waarin je werkt gecompliceerder en realistischer wordt, worden deze modellen complexer en bijna onmogelijk te vormen. Bijvoorbeeld: wat gebeurd er wanneer een auto ook een soort eigenvermogen, te verzekeren object, etc. is. In dit geval heeft de auto dus meerdere overervingen nodig. Dat is niet alleen onmogelijk in sommige talen, zoals Java, maar indien het wel mogelijk is, eindig je vaak met complexe modellen die je alleen maar hoofdpijn bezorgen. 

In plaats daarvan, kun je één van deze technieken gebruiken, zodat je nooit meer inheritance nodig hebt:

Interfaces: het implementeren van interfaces geeft je polymorfisme zonder inheritance. Deze objecten bevatten normaal gesproken geen implementatie en een klasse kan een oneindig aantal implementeren

Delegation: door het implementeren van ‘class instance’ als een attribute, kun je alle onnodige methodes van de klasse die je niet gebruikt verbergen. Hiermee verminder je grotendeels de complexiteit. Dit betekent echter wel dat je meer code zal moeten schrijven.

Mixins: het principe van een mixin is simpel. Je wil klassen en objecten kunnen uitbreiden met nieuwe functionaliteit, zonder inheritance te gebruiken. Stel dat je twee gerelateerde functies zou hebben, genaamd 'find(id)' en 'findAll()', en je wil dat meerdere klassen in staat zijn om deze functies te gebruiken. Je wil natuurlijk geen inheritance gebruiken, maar delegation voegt weer onnodige code toe. Als de taal waarin je programmeert over deze optie beschikt, zou het er ongeveer zo uitzien:

// in sudo code

mixin CommonFinders {
  def find(id){ … }
  def findAll(){ … }
}
class AccountRecord implements BasicRecord with   CommonFinders { … }

Dit is helaas niet beschikbaar in Java, maar sinds Java 8 kunnen we interfaces definiëren met (public) default methodes. Hierdoor kunnen we methodes toevoegen met implementaties aan interfaces. In Java 9 is de mogelijkheid toegevoegd om private methods in interfaces te gebruiken, wat het mogelijk maakt om schone default methods te hebben. In Java kunnen we een mixin die een interface gebruikt op de volgende manier nastreven:

// in Java 9+ code

public interface CommonFindersMixIn {
  default Record find(String id) { … }
    default Record findAll() { … }


// some private methods
// private void example () { … }
}

class AccountRecord implements   BasicRecord, CommonFindersMixin { .. }

Eén probleem blijft bestaan. Omdat private attributes nog steeds niet toegestaan zijn binnen interfaces, beperkt dit de opties die je hebt wanneer je complexe methodes schrijft. In dit geval zal je dus geen andere keuze hebben dan delegation te gebruiken en dus nog een beetje meer code te moeten schrijven. 

Duplicatie en inheritance zijn niets meer dan anti-patterns. Ze hebben voordelen op de korte termijn, maar bezorgen je uiteindelijk alleen maar problemen. Clean code is niet alleen beknopt en zonder duplicatie, maar het vergroot ook geen concrete classes tenzij dit absoluut noodzakelijk is. 

Referenties
David Thomas and Andrew Hunt (2020): The Pragmatic Programmer. 
Michael Feathers (2005): Working Effectively with Legacy Code.
Nicolo Pignatelli (2018): Inheritance Is Evil. Stop Using It. 

Dupliceer geen bestaande code en betaal geen erfbelasting

Het hebben van een native app die beschikbaar is in de Playstore (Android) en de App Store (iOS) was gevoelsmatig lange tijd een must. Ten tijde van mijn opdracht bij de Politie kwam het nieuws naar buiten dat zij stoppen met de Politie-app die je via de appstores kon downloaden.

Uit onderzoek van de Politie bleek dat de burgers en ondernemers de Politie-app te weinig gebruiken tegenover de hoeveelheid geld en energie wat het kost om de app te ontwikkelen en onderhouden. De Politie geeft aan verder te gaan op de responsive website en de andere omnichannel mogelijkheden zoals social media en chat.

Dat brengt mij bij het onderwerp of je als organisatie wel een native app moet willen en of je ook kan kijken naar alternatieven zoals een hybride of PWA (web) app. Ook als front-end consultant krijg ik regelmatig de vraag wat je nou het beste kan doen. Daarom probeer ik je in deze blog post mee te nemen in bepaalde gedachten, zodat het je op weg kan helpen om de juiste keuze te maken.

Stel je staat als organisatie op het punt om een bepaald product en/of dienst te ontwikkelen, dan kan jij jezelf een aantal vragen stellen die mogelijk relevant zijn:

Wat moeten gebruikers op hoofdlijnen kunnen doen?

Wat en met welke frequentie gaan de gebruikers ermee aan de slag?

Welke securityeisen stel ik aan mijn (native) app?

Welke performance ervaring wil ik de gebruikers geven?

Hoe (her)bruikbaar moet het zijn met andere (web)applicaties?

Wie moet het (kunnen) ontwikkelen en met welke snelheid?

Natuurlijk, dit zijn niet alle vragen die jij jezelf kunt stellen. Het geeft je echter wel handvaten om na te denken zodat je weet welke keuze je kan maken. Deze vragen kan je meten door te weten wat het verschil is tussen een native, hybride of PWA app. 

Het verschil tussen native, hybride en PWA (web) apps

Native App
Een native app ontwikkel je voor 1 specifiek platform zoals iOS of Android, welke je beschikbaar maakt voor de specifieke appstore. Je kunt gebruik maken van alle native functionaliteiten die het mobiele apparaat heeft, zoals bijvoorbeeld het op de achtergrond kunnen gebruiken van de locatiegegevens of het sturen van push notificaties. Je hebt de mogelijkheid om de beste performance te bereiken en kunt de beste design en flow experience toepassen. Daar tegenover staan de ontwikkelkosten versus het aanbod in de markt. 

Hybride app
Een hybride app is nog steeds een app die je uiteindelijk beschikbaar maakt voor de specifieke appstores. Doordat je ontwikkelt in een bepaald soort schil heb je de mogelijkheid om te bepalen of je dit doet voor iOS, Android of voor beiden. Deze schil, wat een framework is zoals bijvoorbeeld React Native, Native Script of Ionic, geeft je toegang tot een beperkt aantal mogelijkheden van het mobiele apparaat. Voorbeeld hiervan zijn de NFC-chip of het werken met offlinedata. Je bent in staat om direct voor verschillende platformen te ontwikkelen en minimale verschillen door te voeren. Uiteindelijk kan je minder bereiken dan een native app, maar wat betreft ontwikkelkosten en de techniek gebaseerde frameworks kan het voordeliger en efficiënter zijn. 

PWA (web) app
Een Progressive Web App is een applicatie die je volledig kan ontwikkelen met webtechnieken zoals HTML, CSS en Javascript. De PWA is vanuit de browser benaderbaar en te installeren. Je kunt met een PWA beperkt gebruik maken van functionaliteiten zoals de camera, offlinedata of push notificaties. Het geeft je de indruk dat je een native app aan gebruiken bent. Naast de beperkte functionaliteiten kan het ook nog eens verschillen hoe deze te gebruiken zijn per platform. Kort gezegd kan je met minimale effort een webapp ontwikkelen.

Welke techniek kies je voor je app en in welke case?

Terug naar waar ik deze blog mee begon. De Politie-app verdwijnt uit de appstores met de hierboven genoemde redenen. Naar mijn inzien klinkt dat logisch als je deze meet aan de eerdere relevante vragen en de verschillen tussen een native, hybride en web apps. Of je dan direct helemaal geen app meer hoeft te hebben, dat betwijfel ik. Zeker voor de Politie lijkt het mij dat je ook de mogelijkheid moet hebben tot het hebben van een hybride app of PWA (web) app. Met als reden dat je een groot maatschappelijk belang hebt, maar niet de volledige native ervaring nodig hebt voor de dienstverlening.

Ter afsluiting van dit blog richt ik mij op twee cases die ik wil koppelen aan een technische keuzes.

Case 1 - Tijdens een festival wil je de timetable kunnen inzien. Daarnaast wil je de bezoekers bij een bepaalde locatie een badge laten verdienen voor een gratis drankje. 

In dit voorbeeld weet ik wat gebruikers moeten kunnen doen. Hieruit maak ik op dat het beperkte doelgroep is, maar wel een brede doelgroep. Om iedereen de mogelijkheid te geven wil je voor beide platformen (iOS en Android) iets hebben staan. Je wilt wel een zo goed mogelijke performance bereiken. Daarnaast wil je gebruik maken van de locatiegegevens en offlinedata. In dit geval zou ik een hybride app als eerste willen onderzoeken.

Case 2 – Als kleine organisatie zie ik dat gebruikers regelmatig maken gebruik van een mijn omgeving en ik wil deze permanent en makkelijk beschikbaar maken.

In dit voorbeeld zie je duidelijk terugkomen dat het om een kleine organisatie gaat en dat er al een mijn omgeving is. Het zijn minimale requirements, namelijk het makkelijker en permanent beschikbaar maken. Daarom zou ik als eerste stap nemen om te kijken hoe je dit kan hergebruiken zodat je tot een webapplicatie kan komen. De simpelste manier in deze lijkt een PWA (web) app. 

Het bepalen van welke keuze je moet maken hangt af van je doelgroep, de frequentie, de requirements en de kosten. Wil je hierover een keer brainstormen, dan kan je daarover altijd contact met mij opnemen via jeroen.burgers@cinqict.nl of via mijn Linkedin-profiel.

Weet jij welke keuze je moet maken als het gaat om een native, hybride of PWA (web) app? Lees snel ons blog.

Wanneer kies je voor een native, hybride of PWA (web) app?

CINQ ICT is een expert op het gebied van Data, DevOps en Development. Een van de expertises binnen de Development unit is Java. Binnen de Development unit hebben wij gecertificeerde professionals die graag een uitdagend project aan gaan.

Lees hier meer over de upgrade van Java 8 naar 11 die CINQ voor Topicus Pension & Wealth heeft uitgevoerd.

Onze laatste blogs