The KAUST Information Technology Department blog
01 July, 2020
Docker Containers (Containers from now on) have taken the technology community by storm. They have become an important building block for developers, as well as, system administrators. Containers (among other things) helped accelerate a cultural shift to merge these two once siloed teams allowing them to join forces and become what is now known as DevOps. Tech companies figured out that creating multi-disciplinary teams who shared practices, tools, and skills improved how they delivered services and products to their customers. Thanks to this cultural shift, they started releasing new software features multiple times a day; big tech companies like Netflix, even one thousand times a day. Google starts more than one billion containers a week. Let that sink in for a moment.
This new efficient team now owns “the product” from start to end. The product could be a news feed, a search bar, or other similar components; a smaller service contained in the bigger picture. Teams now are fully accountable, and they enjoy this responsibility as they get to decide what goes into “their” product. This is one of the most important paradigm shifts brought to us by DevOps culture. The other big one is the “no blame game”. Disasters happen. Issues occur even though we have multiple eyes looking at shared code now. We all know that nobody in their right mind would cause production to fail on purpose. That is why not being afraid to make errors is important. That is how innovation happens. DevOps teams get together to perform a blameless analysis of what went wrong and how to try preventing it from happening again in the future. A key factor is that team members feel safe to share. Transparency is key. Learning from these blameless meetings allows teams to incorporate changes back into the product that improve it. One more DevOps principle: Keep improving your product. Try to automate yourself out of the job.
GitOps is the art and science of using Git pull requests (well merge requests, since here in KAUST we offer GitLab) to manage infrastructure provisioning and software deployment. Your Git repository becomes your sole source of truth. Your Git repository holds declarative descriptions of the infrastructure desired in production and an automated process to make the production environment match the described state in the repository. You deploy a new application or update an existing one by just updating your repository, the automated process takes care of everything else. It is like having cruise control for managing your applications in production.
GitOps is a paradigm that sets you free from IT Operations. You setup a GitLab pipeline that does continuous everything. Continuous everything includes but is not limited to: linting, integration (CI), testing, security scanning, analytics, governance, deployment (CD).
GitOps combines Git with Kubernetes’ (Kubernetes is a container-orchestration system for automating application deployment, scaling, and management) convergence properties and serves as an operating model for developing and delivering Kubernetes-based infrastructure and applications. GitOps empowers developers to take on operations in a way that says, “You own it, you ship it!” and graduates from being a slogan everyone chants at tech conferences to a reality that can be executed day in and day out.
IT Research Computing started its DevOps journey a little more than three years ago. Now the team started evolving into a GitOps shop. The team went from writing its first (shaky!) pipelines to helping many researchers in KAUST publish their work by creating pipelines for them in GitLab. These researchers can now easily deploy their work, sharing it with the entire world without having to engage IT Research Computing to push changes. They own it, they ship it!
Our first automation project was creating Linuxbrew recipes. We wanted our users to have the ability to easily install software packages on their own. That is how we stumbled upon Spack. We install all our scientific application stack using the power of Spack – spack install <package name>. We write our own Spack recipes (like we do for Linuxbrew) if they do not exist on the official Spack repo. We also push them to upstream to contribute back to the global community. Another reward of a true DevOps culture.
Our real first GitOps success as a team was managing physical and remote workstations through one GitLab repository. This project is where we go the whole nine yards. We started linting (you want to be sure all files meet criteria we agreed upon), testing (by spinning up virtual machines on the fly), analyzing (by collecting data in our Elasticsearch cluster), announcing (by sending messages to our Slack channel), and deploying our code to all managed workstations. Nowadays any fix, update, new feature is just a merge request away. We own it, we ship it!
Our automation projects cover a remarkably diverse nature of tasks. Here is a non-exhaustive list of these projects:
workstations – one repository to rule them all
spack-kaust – to integrate upstream Spack with our recipes
kmat – our famous MATLAB HPC Add-on
e-forms – forms used to request our services; they're available from IT web site
slack – track how we help our users on our Slack workspace
APF – Automated Patching Framework we use to patch (without human intervention!) more than four hundred servers that we manage
coronavirus – KAUST's WordPress Corona Virus website
CBRC – this research center decommissioned more than forty virtual machines replacing them with more than seventy containers on our Kubernetes cluster
thelens – The Lens WordPress website
hr – new HR WordPress website
taqadam – Innovation & Economic Development new TAQADAM WordPress web site
jane – Django-based seismic website for Dr. Laura Parisi who is a Research Scientist in Prof. Martin Mai’s group
wormbuilder – Shiny App website for Dr. Amhed Velaquez who is a Postdoctoral Fellow in Prof. Christian-Froekjaer Jensen’s group
igulf – website built by Core Labs & Prof. Ibrahim Hoteit
mvapp – Shiny App website for Dr. Magdalena Julkowska who is a Postdoctoral Fellow in Prof. Mark Tester’s group
tcscatlas – Shiny App website for Dr. Robert Lehmann who is a Research Scientist in Prof. Jesper Tegner’s group
Reading thus far, you might have wondered what the bottom line for you is. How does GitOps help your research? Let us try to answer just that.
You can reproduce the same results over and over. You will always be confident that results will not skew in the future because of changes to libraries, system components, operating system updates. Containers allow you to freeze your code in time. Imagine your code running on R 3.3 while your box has R 3.6. Thanks to containers you avoid “dependency hell”.
Once you created a container, you or whomever you share it with can run it anywhere if you have a Docker runtime of the same type you built it for. You create predictable environments that are isolated from all other applications running on the hosting target.
Eliminate the “it works on my computer” problem for the last time. This means that you leave KAUST but who stays behind can still use/update your code without having to go through a nightmare. You peers and your PI will thank you ;)
Today IT Research Computing is using its GitOps knowledge and ability to automate IT workflows. This same knowledge and expertise are being passed on to KAUST researchers so they can easily deploy their web sites/workloads using automated pipelines without depending on IT for future changes, fixes, and/or improvements.
Reach out today to schedule your personalized session to start automating your workflows.
https://docs.microsoft.com/en-us/azure/devops/learn/what-is-devops
https://www.weave.works/blog/gitops-operations-by-pull-request
https://about.gitlab.com/blog/2020/04/17/why-gitops-should-be-workflow-of-choice/
https://www.linode.com/docs/applications/containers/when-and-why-to-use-docker/
https://www.r-bloggers.com/why-use-docker-with-r-a-devops-perspective/
Article written by: Antonio Arena
