The newbie cloud architect diary

Knative is a serverless framework for Service-Mesh and Event-Mesh architectures that make it easier to run elastic applications in Kubernetes. The daily mood I am just starting to realise how much my work life has changed with my "new" job. No more technical marketing, only questionable facts. No more Business trips, only Home-office. No more telephone calls, only Slack chats. No more productivity tools like Trello  and Todoist , only "old-school"  Jira projects. There are also things that didn't change, like daily concerns about wether I am doing the right thing at the right time in order to perform as an employee, while protecting my work-life-balance. They are actually days in and days out, which people might count so or so... Provided that my organisation is currently pivoting its business and technology, automation is the key. Today is our 2nd post around Cloud native and we are looking at Serverless in the context of Microservices and Kubernetes, or the...

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

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

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

Skaffold is a client-only tool that watches changes on your local file system for automatically deploying to a local or remote Kubernetes cluster. The daily mood I heard several times that Flux may not offer the best developer experience. On one hand it might not fullfill all our requirements as per our Helm custom plugin. On the other hand despite it is fairly easy to use, it might ask developers and DevOps engineers for too much delegation to the operator running "behind the scenes", without offering a clear feedback loop. Today we are looking at Skaffold, a more developer-friendly tool. What is the particularity of Skaffold Skaffold  follows a declarative approach but is not a pure GitOps implementation since Git is not the single-version-of-the-truth but a local copy of it. The project was started 2y ago, is backed by Google and actually used behind their cloud-based IDE Cloud Code  (IntelliJ/VSC as-a-Service). Setup Download Skaffold command-line and add it to your P...

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

Software Development Lifecycle (SDLC) management is an old topic that is hot again for DevOps teams in charge of operating applications in Kubernetes. The daily mood According to the famous book Accelerate  by Nicole Forsgren, Jez Humble and Gene Kim, we are often looking at automation as an opportunity to improve both development velocity and operational reliability. We know what works and what doesn't work, yet we often don't know well enough the methods and discipline to make it lean and consistent. I need to build my own mindset about our path towards GitOps. I just looked at some  Dzone contributions from vamp.io and split.io around the concept of Continuous Release Cycle. * Deployment approaches Conitnuous Deployment : New versions are automatically rolled-out as they are available. Ideally with no risk but this is extremely hard to achieve, therefore it doesn't get any credit. Continuous Delivery : New versions are submitted to manual deployment approval as...

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

This article dresses a naive picture and history of Continuous Delivery (CD), while introducing GitOps as the best operational model for Kubernetes. The daily mood My manager introduced me the different tracks we are working on. Fortunately I am free to organise my time and directions for ramping-up. For now I have enough backlog with Kubernetes, Helm and Continuous Delivery. Still I hope that he can support my integration within the team, its initiatives and accountability. CD: A retrospective Software delivery has always been a tedious and time-consuming process. In the old times developers were sending an application archive per e-mail to the administrator of an application server, along with database creation statements and application parameters. Developers were potentially using distributed version control (ex. SVN, Git), build and dependency management tools (ex. Maven, Gradle). But they had no idea of how the production environment is configured. Admins were potentially using ...

Traefik is an open-source HTTP reverse proxy and load balancer that is easy to use.  Let Traefik point at your orchestrator and you are ready to go. The daily mood A fellow peer explained me our approach to Software deployment . Instead of getting lost in tons of infromation sources, it is such a high value to get told about the history, as well as to get idiot questions answered. In this case, that opportunity definitely raised my degree of understanding, comfort and motivation. Project history Following to our adoption of Helm for immutable Kubernetes packaging, our SRE team leveraged known tools for configuration management ( Ansible ) and pipeline automation ( Jenkins ). In a few years our platform grew to a hundred of services developped by 12 teams, staging accross 4 environments and different Cloud imfrastructure providers. At some point, we not only needed more DevOps automation, but also process standardization and parametrization (e.g. via templating). Ansible ...