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...

Flux Helm Operator supports the automated deployment of Helm charts to Kubernetes while maintaining compliance with the GitOps operational model. The daily mood I watched a bit the  DockerCon 2020 . Although most talks are addressed to a C-Level or beginner audience, I found some interesting pointers around application packaging, integration and delivery. Among others, I will definitely have a look at KubeStack  which seems to be able to solve some problems around GitOps.  My today's goal is to have a look at Flux for automating Helm chart deployments. Source: Revelry.co / Bitnami Requirements Same as in this  previous post about Flux without Helm. Installation steps Delete previous objects kubectl delete namespace flux kubectl delete clusterrole flux Add new Helm repository helm repo add fluxcd https://charts.fluxcd.io Apply HelmRelease CRD to the cluster kubectl apply -f https://raw.githubusercontent.com/fluxcd/helm-operator/master/deploy/crds.yaml Create Flux na...

Flux is a GitOps Operator for Kubernetes which supports both Git sync, automated deployment and rollback, so that deliveries can go faster and safer. The daily mood I had the opportunity to attend to a meeting with developers about the plan to migrate one of our applications. They might need the support of our team. I really enjoyed the topics discussed even though I felt a bit overloaded with developer jargon, specific acronyms and historical details.  Back to my ramp-up, we already introduced what is Flux in a previous post, a typical GitOps implementation for K8s. In this test use-case, the developer basically commits something to his branch and the cluster just takes care of the rest i.e. updates the application on the cluster. Basic requirements K8s client and cluster (ex. our local minikube or microk8s) Git client and repo (ex. empty project in GitHub) K8s application (ex. our nginx application from previous post ) Installation steps Setup Flux command-line tool ( ...

This article discusses different approaches and solutions around GitOps application delivery for Kubernetes and our path towards the adoption of Flux. The daily mood I requested access to our LucidCharts. Wit this I expect to be able to review any existing chart of our delivery process, and finally be able to create new ones. In the mean time I am looking for available industry solutions and practices around Continous Delivery in Kubernetes. Hereby I found the Manning book GitOps and Kubernetes of a great source of understanding and inspiration. GitOps implementation Basically GitOp supports both  Pull - and  Push -based approach, provided that configuration changes happens either in Git via InfraCode, or on the cluster via new image tags, rather than through the action of a human operator. GitOps can be implemented using existing technology or new emerging tools, thus with some slight differences in the approach, structure and infrastructure support. Poc Our team already ran...