The newbie cloud architect diary

FluxCD GitOps operator supports Kustomize for dynamically featuring Kubernetes resources includind HelmRelease. This post is about auto-deployment. The daily mood Another week is over and I have made good progress on this project around Helm chart deployment automation. As described in my last posts, we've been using Flux Helm Operator for abstracting Helm installation, and Kustomize for building custom configurations.  Now we will look at how Flux can integrate with Kustomize. At the end we'll actually get a picture which is not common, indeed we'll use FluxCD GitOps operator in conjonction with Helm operator, but disconnected from each other. Like for a connected mode, the solution should allow to automatically and bi-directionnaly sync a configuration change either in the Git repo (Flux HelmRelease + Kustomize), or on the Kubernetes cluster (Released Helm charts). Requirements An empty Git repository Assets from my previous post on Flux Helm Operator + Kustomize A Kuber...

FluxCD GitOps operator supports Kustomize for dynamically featuring Kubernetes resources includind HelmRelease. This post is about solution analysis. The daily mood My manager looked at my current activity on Helm deployment toolchain, and latest findings as described in my  previous post on Flux Helm Operator + Kustomize .  He seems to generally support my directions and approach, but also raised some concerns and questions that I shall answer in this solution draft. Context We currently operate hundreds of services in Kubernetes clusters . Without claiming to have a Microservice architecture, we generally try to design small-sized standalone components that communicate through HTTP. We also try to develop and test with agility ( Scrum ), create immutable deliveries ( Maven artifacts , Docker images , Helm charts ), use resilient infrastructure, operationalise for reliability. Our services are actually shared by a dozen of different teams, combined via logical stacks on...

FluxCD GitOps operator supports Kustomize for dynamically featuring Kubernetes resources including HelmRelease. This post is about parametrization. The daily mood I got in touch with another team mate, also well aware of, and willing to help on Helm deployments. He gave me some precious pointers on our current solution (based on Ansible) which allowed me some additional level of understanding. He also pointed out that following to the past PoC on Flux, HelmReleases were introduced as the future solution, but had the negative effect to make life even more complicated for developers, and configurations even more replicated by SRE. He suggested myself to study the possibility of using Kustomize to feature HelmReleases, so that replications can be avoided. In fact I had not yet considered Helm and Kustomize as a potential fit so far, except if we wanted to render Kubernetes resources first, then configure them as described in this article . I realised about how many different tools we were...

Kustomize is a native, declarative, template-free and comprehensive approach to composition, customisation and patch of any Kubernetes resource. The daily mood We had another meeting with developers on Friday afternoon about the migration project I had been involved in a week ago. We talked about the use of a Kubernetes DEV cluster offering a Hybrid deployment mode (as discussed in a  previous post ). I learnt about significant limitations due to natural differences in the architecture and components between DEV and PROD, which confused me a bit. At the end unfortunately, I will not be able to support this initiative actively, and rather let the experts proceed. Regarding my work, I realised that it was not convenient to share and read larger pieces of code within my posts so I created a GitHub account dedicated to this blog , and will try to catch up with all previous assets soon. Since I was already using a personal GitHub account and want this blog to stay anonymous for now, I f...