Latest posts

A quick glance at Blazor WebAssembly
A quick glance at Blazor WebAssembly
· โ˜• 12 min read

In 2018, 👿 Microsoft released its new framework, Blazor, which tease MVVM capabilities through component-oriented AJAX or WebAssembly application builds. 4 years later (and with many improvements & versions), what is the current state of Blazor?

In this article, I’ll share with you my experiences with Blazor WebAssembly, the pros, the cons, the whatnot.

TL;DR; If you’re not already a fluent ASP.NET developer, I’m not sure that you want to use it. If you are, then maybe Blazor might be an interesting choice.


CentOS8 Firewalld Tips
· โ˜• 1 min read
Tracking down requests denied by firewalld is an important plus to be both strict and precise about what to allow. This small copy-pasta might help you.

Scaling up
· โ˜• 3 min read

Your setup is running, everything runs smoothly, and suddenly, ‼️ nothing is responding: your cluster is overloaded.

Well, I hope you’ll expand your cluster capacity before it happens. It’s always really bad and stressful to do maintenance because of downtime.

Hopefully, here comes the real huge advantage of kubernetes: it is meant to scale, up, and down. So, assuming you have followed the full guide so far, let’s review together how to add some juice to our cluster ⚡.


Quality Of Life improvements to kubernetes
· โ˜• 5 min read

Kubernetes is…. Quite a thing, to say the least ! 😅 Even if their conceptors did a great job at making the kubectl cli as usable as possible, it can sometimes be a pain to be productive with it, read outputs, or do repetitive tasks. That’s why I wrote this small Quality of life improvements post: to regroup some install steps you might have missed, give you some useful 3rd party tools or maybe even give you tips a step ahead.


Protect monitoring with authentication
· โ˜• 2 min read

Now that we have our authentication service up and running, we can protect our dashboards installed in the step  06 - Monitoring: See what is going on using our Keycloak OpenID Connect provider. Here is a diagram on how authorization will be managed:

Authorization graph

Traefik dashboard

TODO

Kibana

TODO

Kube dashboard

Again, we are going to set up a new instance of  louketo-proxy.


Administrate the cluster with authentication
· โ˜• 7 min read

Create the realm and the client

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
REALM_URL="https://keycloak.{{cluster.baseHostName}}/auth/realms/{{apiServer.realmName}}"
# Log in
TOKEN_RESPONSE="$(curl \                           
        -d "grant_type=password" \                                
        -d "client_id={{apiServer.clientId}}" \
        -d "client_secret={{apiServer.clientSecret}}" \
        -d "username=admin-user" \
        -d "password=admin-user" \
        $REALM_URL/protocol/openid-connect/token)"
# Extract the access token
ACCESS_TOKEN="$(echo "$TOKEN_RESPONSE" | jq '.access_token' -r)"
# Check token
curl \
        --user "{{apiServer.clientId}}:{{apiServer.clientSecret}}" \
        -d "token=$ACCESS_TOKEN" \
        $REALM_URL/protocol/openid-connect/token/introspect -k

Set up certificates

Generate the certificates

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
mkdir certs
cd certs
# CA part (Certificate Authority)
# Generate the CA (Certificate Authority) private key
openssl genrsa -out ca.key 2048
# Generate the CA (Certificate Authority) certificate
openssl req -new -x509 \
        -subj "/C={{countryCodeIso3166_1_alpha_2}}/ST={{State}}/O={{companyName}}/CN={{cluster.baseHostName}}" \
        -addext "subjectAltName = DNS:{{cluster.baseHostName}}" \
        -key ca.key -out ca.crt
# # Import the CA (Certificate Authority) in the truststore, so that certificates signed by our authority are considered as trusted
# keytool -import -file ca.crt -keystore ca.truststore -keypass PASSWORD -storepass PASSWORD

# Keycloak part
# Generate the keycloak's private key
openssl genrsa -out keycloak.key 2048
# Generate the keycloak's CSR (Certificate Signing Request)
openssl req -new \
        -subj "/C={{countryCodeIso3166_1_alpha_2}}/ST={{State}}/O={{companyName}}/CN=kube-keycloak.{{cluster.baseHostName}}" \
        -addext "subjectAltName = DNS:kube-keycloak.{{cluster.baseHostName}}" \
        -key keycloak.key -out keycloak.csr
# Sign the CSR using our custom CA
openssl x509 -req \
        -days 3650 \
        -extfile <(printf "subjectAltName=DNS:kube-keycloak.{{cluster.baseHostName}}") \
        -CA ca.crt -CAkey ca.key \
        -in keycloak.csr -out keycloak.crt

Finally, inspect your keycloak’s certificate.


Setup cluster's authentication
· โ˜• 10 min read

Here is a graph of the RBAC setup we are going to implement:

RBAC

1. Setup keycloak

We’ll use keycloak to proxy our authentication for all monitors, using a single realm. You may use several realms in real-life situations. This is probably the tough part, and you may tweak heavily the following guide. Moreover, I may forgot to write some instructions, or somes are heavily linked to your very own setup.


Monitoring: See what is going on
· โ˜• 18 min read

Well, things are getting real and are on the point to become quite complex. So we’ll setup (super unsafe) dashboards to see what is going on easily. After all, we have nothing critical for now, but we might get troubles soon. And, don’t worry, we’ll make it safe just after that.

1. Traefik dashboard: monitoring routes

The traefik dashboard will help us in the diagnostics of our ingress routes and traefik-related stuff. For this, we need to:


Make things persistent
· โ˜• 6 min read

As you may know, docker (and thus, kubernetes) does not persist anything by default. That means that everytime you restart a pod (container), it is in the exact same state as it was at its first execution, except for the mount points. Those mount points are real hard drive directories injected into your pod. Some apps we’ll setup later will require to persist data, and, more generally, when you’ll run real applications on your own, they will probably use a database or something.


Make services reachable from the world
· โ˜• 5 min read

Now that you have a router installed, you have to pass requests on your server to it. This setup use a single entry point directly binding some ports on the host server.

1. Make a static and previsible configuration

As you may have noticed in the step  Kickstart the cluster , the metallb configuration use only dynamic adresses. But for the reverse proxy to work, we’ll need to be sure that our traefik router has a constant IP in your VPN. For this, modify your metallb configuration using the new  kubernetes/metallb-configmap.yaml template. This new configuration declares a new address pool named frontend with a single IP in it.