Aller au contenu principal

· 4 minutes de lecture
Maxime

What's new

Well... i kinda change everything... again.

LAYERING OVER HEAVEN

In a attempt to fix some of the problem i had with my previous setup, i decided to change everything. I'm still using the same tools, but i'm using them differently.

What was the kind of problem if encoutered:

  • During some deployment, some helm chart were locking all the deployment process due to a missing secret or other stuff. This was due to the fact that my depency were not well defined and that i was deploying a lot of stuff at the same time.
  • One of the probleme was that Zitadel was needed by a lot of other stuff like Harbor, Sonarqube... well all the app that use the SSO. So if Zitadel was not ready, the deployment of all the other app was failing and then kind of interupted the deployment process.
  • well... let's talk about tekton, the version used was not the latest and during the upgrade everything broke down due to incompatible change. So i decided to upgrade everything to the latest version. During the upgrade the webhook of tekton refused to stop and overloard the cluster. So i had to force delete the webhook and broke the cluster.

GitOps

The choice has been made to keep it but to change the deployment order/dependency and process. A layering process has been put in place. The idea is to have a layering of the deployment. Each layer is a set of application that are deployed together. The layer are deployed in order of requirement. The layer are:

CNI

What is a CNI ? Well it's a Container Network Interface and it's used to create network for container. I'm using Cilium as my CNI. It's a really good CNI and it's working really well. I'm using it in BGP mode, so i can have a really good network and i can use it to connect my cluster to my home network if needed. The setup is actually really easy but not complete at the moment. What i'm missing:

  • Setup the Service Mesh
  • Setup the Monitoring
  • Setup the Gateway Api - Doc

CSI

What is a CSI ? Well it's a Container Storage Interface and it's used to create storage for container. I'm using Longhorn as my CSI. It's a really good CSI and it's working really well. I'm also using it to backup my data.

Gateway Api

During my search for more observability and security, i found the Gateway Api relatable has a Ingress Killer. Why does the Ingress should be replaced by the GateWay Api? The Gateway Api is more compatible with the CNI and Service Mesh. It's also more secure and flexible by being more configurable. If you want to know more click on the link above.

Upgrade

In order to facilitate my upgrade process, i setup Renovate to handle the upgrade of my dependencies. It's really easy to use and it's working really well. I just need to execute the renovate job daily and it create PR when needed and merge it when i think it's ok.

Well we need everything to be up to date, so i upgraded everything to the latest version available like

  • No Upgrade this time

While working on the upgrade part, i ended up thinking that setting up Changelog would be a good thing. So i'm thinking of including cog.

Next to do

  • Setup the Service Mesh #71
  • Setup the Monitoring/Overservability of Cilium #71
  • Migrate to the Gateway Api #70
  • Slowly secure the Harbor Cache #55
  • Include KEDA and the PodAutoScaller #17
  • Préparer l'ajout de nouveaux uttilisateurs #72
  • Travailler sur un un équivalent a Tibco BW en passant possiblement par Knative #69

While i was upgrading everything it become obvious that i need to upgrade my use of Github. Then i moved from the old Github Dashboard to the new one. Event if i wasn't writing the doc, i was still working on the project and updating the dashboard and issues.

· 2 minutes de lecture
Maxime

What's new

During the night i finnaly found a way to automate Sonarqube with the help of... Oauth2Proxy and Terraform !!!!

Automate me

So it's the turn of Sonarqube to be automated with... terraform again. I love this tool ! So what does the automation and upgrade does ?

  • Separate Sonarqube from it's database with two helm release
  • Setup Oauth2Proxy to handle the authentication of Sonarqube and ignore path that doesn't need authentication
  • Setup the ingress to handle the authentication and the path to Sonarqube/Oauth2Proxy
  • Automate the configuration of Sonarqube with TF
  • Automate the creation of Sonarqube secret with TF
  • RollBack to the previous version of Sonarqube from 10 to 9.9

Upgrade

In order to facilitate my upgrade process, i setup Renovate to handle the upgrade of my dependencies. It's really easy to use and it's working really well. I just need to execute the renovate job daily and it create PR when needed and merge it when i think it's ok.

Well we need everything to be up to date, so i upgraded everything to the latest version available like

  • No Upgrade this time

While working on the upgrade part, i ended up thinking that setting up Changelog would be a good thing. So i'm thinking of including cog.

Next to do

  • Setup Changelog

While i was upgrading everything it become obvious that i need to upgrade my use of Github. Then i moved from the old Github Dashboard to the new one. Event if i wasn't writing the doc, i was still working on the project and updating the dashboard and issues.

· 2 minutes de lecture
Maxime

One mont later, what happened ?

What's new

During the past month another project had my focus, the rewrite of my Rust Template with in the TDD/DDD way. I'm still working on it, but i was feeling the need to do something else. So i decided to get back to my GitOps project and to do some cleanup and upgrade.

Automate me

Who's turn ? it's Wireguard's turn to be automated with... terraform again. I'm starting to like this tool, it's really easy to use and to understand. And it's really powerfull. So what does the automation and upgrade does ?

  • Create the Wireguard configuration (Peer, Interface, ...)
  • Create a secret with each peer (Server, Client1, ...)
  • Include AdGuard Home and the hability to access the Kubernetes internal DNS.
  • Build my own image of Wireguard to handle exposing metrics to Prometheus.

Upgrade

In order to facilitate my upgrade process, i setup Renovate to handle the upgrade of my dependencies. It's really easy to use and it's working really well. I just need to execute the renovate job daily and it create PR when needed and merge it when i think it's ok.

Well we need everything to be up to date, so i upgraded everything to the latest version available like

  • Terraform Zitadel from v1.0.0-alpha.18 to v1.0.0-alpha.19
  • Terraform Harbor from v3.9.4 to v3.10.1
  • Terraform Kubernetes from v2.22.0 to v2.23.0
  • Helm Release Loki from v4.6.1 to v5.14.1
  • Helm Release Tempo from v1.3.1 to v1.5.0
  • Helm Release Postgres from v12.6.5 to v12.8.3
  • Helm Release Redis from v17.13.2 to v17.15.5
  • Container Buildkit from v0.10.6 to v0.12.1 (and caching with harbor)

While working on the upgrade part, i ended up thinking that setting up Changelog would be a good thing. So i'm thinking of including cog.

Next to do

  • Setup Changelog
  • Setup Cog
  • Automate Sonarqube #52 that would end the automation of Zitadel #44

While i was upgrading everything it become obvious that i need to upgrade my use of Github. Then i moved from the old Github Dashboard to the new one. Event if i wasn't writing the doc, i was still working on the project and updating the dashboard and issues.

· 3 minutes de lecture
Maxime

Well it's been a little more than a year since the last post. I've been busy with a lot of things and I didn't have the time to write anything. But I'm back and I will try to write more often. If you are reading this, thank you for your interest in my blog about the GitOps project. I hope you will find it useful.

What's new

hmmm... Everything ? In the past few day, i just graduated from my Master degree, and just got my first job out of studie. This project never stopped, but i didn't have enough time to write about it.

The goal is stil the same, having a fully automated kubernetes cluster, with a GitOps approach. Will following some Good practice.

Auth me now

One of the most nerf wrecking change was to kick out the old auth system Keycloak and replace it with Zitadel.

Why the change ? Zitadel bring the hability to fully automate (except SAML) the auth process and to create each application with a terraform "CronJob".

The pros of automating the auth process is that you dont need to create each thing by hand, and you can easily create a new application with a simple terraform file. And you are sure that whats automated will be the source of truth thought time.

At the moment i didn't find any cons, except for the huge amout of ram that CochroachDB need to run when considering Keycloak use Postgresql. (The saml part is not a cons, it's just not implemented yet).

Automate me

With the new auth system, i was able to automate the oidc setup for each application. But by discovering Zitadel, i also discoverd Terraform.

It allow me to:

  • Automate the oidc setup for each application (Grafana, Gitea, Harbor, WIP: Sonarqube, Oauth2Proxy, ...)
  • Automate Harbor (Project, Robot account, Configuration, ...)
  • Automate some simple step (creation of Kubeconfig)
  • Automate Sonarqube (WIP)
  • Automate Minio (WIP)

Upgrade

Well we need everything to be up to date, so i upgraded everything to the latest version available like

  • Gitea (need to be done manually, because each upgrade break everything) (1.18 -> 1.20)
  • Tekton (Just an upgrade of the CRD)
  • Harbor (automated)
  • Haproxy (0.14.2 -> 0.14.4)
  • CertManager
  • Tempo (replace Jaeger because it's easier to use)
  • Flux (0.41.2 -> 2.0.1)

Next to do

While i was upgrading everything it become obvious that i need to upgrade my use of Github. Then i moved from the old Github Dashboard to the new one. Event if i wasn't writing the doc, i was still working on the project and updating the dashboard and issues.

· Une minute de lecture
Maxime

Has of today this doc is being created in order to record why on how the GitOps paradigm is being used to manage the Weebo kubernetes cluster.