Skip to main content

Posts

Showing posts with the label devops

038: Infrastructure provisioning with Terraform

Terraform is an Infrastructure-as-Code framework that is used to provision network, storage and computing resources on (nearly) any Cloud environment. The weekly mood I am back from vacation while many colleagues are still on leave. It has the advantage for me to review my past achievements, potentially go back to some topics I had not yet well understood or remembered, and think about further plans. I realize how much difficult it is to build my network and catch-up with projects when working from home. Naturally, I spend more time reading than chatting, which has the consequence than I don't learn anybody or anything by hazard, only on purpose. Also, I wonder a bit about my goals and areas of focus which are still disparate between concrete use-cases and general practices.  I still have to get more confident with DevOps therefore I am now looking at Terraform. What is Terraform Terraform is an open-source infrastructure-as-code (IaC aka. "InfraCode") software tool cre...

029: From SCM to DevOps with GitHub Actions

Evaluation of GitHub Actions as the potential alternative (replacement or complement) to Jenkins for Continuous Integration (CI) in our organization. The daily mood Beside spending time reporting on my activities, I have the opportunity to backup one of our team lead with mentoring a student for about one month. He has already worked in part-time for about 3 years in our organisation, as a Java developer. He is now looking for a short engagement within the architecture team.  We agreed on the goal to create a document that is collecting all required informations around GitHub, and eventually run a small PoC/showcase. Git Git is a distributed version-control system for tracking changes in source code during software development. It was crated by Linus Torvalds in 2005 for development of the Linux kernel. It is a free software under GNU license. There are Git clients available for my different OS and code editors. And like for HTTP server there are tons of hosting providers and dist...

017: Auto-deploy Kubernetes resources with Flux

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

016: Continuous Release Cycle

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

014: GitOps implementation styles

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

013: Continuous Delivery with GitOps

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

008: Site Reliability Engineering

Site Reliability Engineering (SRE) is a particular approach to DevOps for keeping systems highly-available (HA) while continuously releasing features. The daily mood I enjoy my work a lot. However, I just start to realize how important it is to stay consistent and reflective in my ramp-up. I do have directions but nobody feeds me with a concrete planning and tasks, so that every new working day starts with a self-review, questioning and planning. In general, it is just so much important to read, learn and practice a lot now that i have time allocated to this, in order to be able to contribute later when I'll have more responsibility and less time.  One of my focus areas is the science of operationalization. I am making good progress in reading and understanding  Google SRE Book : 11/32 chapters covered so far, mainly introduction and principles. Introduction The  Site Reliability Engineer (SRE) role truely emerged at Google around 2003 while traditionnal sysadm...

007: Packaging Kubernetes applications with Helm charts

Helm is a template-based spec format for configuring, packaging and deploying  applications that consist in multiple resource objects to Kubernetes. The daily mood My last posts were about setting up a Kubernetes environment. We'll now learn the tooling. In general i am not yet much familiar with common developer productivity tools like  Z-Shell ,  Gists  and  Lints , but i assume this will come with the time. Now we are going to look into the packaging of Kubernetes applications. What is Helm Helm is a commonly used package manager for Kubernetes. It is not the only one option for managing your Kubernetes applications but the one which happens to reach critical mass at enterprise grade, just like Docker did for Containerization and Kubernetes for Orchestration. One of the reason for its great popularity is the Helm Hub , the official Helm public repository which is hosting tons of standard packages. At its core, Helm generates Kubernetes manifests out of...

004: Container orchestration with Kubernetes

Kubernetes is a Container Orchestrator able to run in distributed mode. It has become the default platform for operating scalable applications. The daily mood My primary focus is to become familiar with, and improve our current Continuous Delivery & Deployment (CD) process, a software development and operation engineering discipline that requires high level of automation in order to improve the pace of innovation and quality of production. Our organisation already uses  Kubernetes  intensively. In terms of CD, we are slowly transiting from a traditional operational model to the  GitOps  philosophy. In my previous post  I have setup a local Kuberntes cluster and some tooling. Now we are going to talk about Kubernetes concepts and create an example application from scratch.  What is Kubernetes Kubernetes  (K8s) is a distributed system written in Go and used for container orchestration, i.e. for configuration, deployment and operation of contain...