Operations | Monitoring | ITSM | DevOps | Cloud

The Docker infrastructure abstracts a lot of aspects of the creation of images and running them as containers, which we usually do not know about nor interact with. One of those aspects is the handling of the filesystem inside the container. This post is a case study on how we discovered that writing large amounts of data inside a container has side effects with memory caching. Initially, we thought that we had an issue with our source code, but this was never the case.

The conversation usually starts with a question like “should we let ArgoCD/Flux/whatever synchronize the actual state automatically whenever the desired state changes in Git?” Truth be told, the question is usually not that elaborated, and it is more like “should I enable the auto-sync feature?” But, I wanted to save you from follow-up questions that help me better understand what that means, so I gave you a more extended and more precise version of the inquiry.

Managing dependencies across multiple repositories and implementing updates to multiple repositories at the same time can be a time consuming and error-prone task. Thus, organizations have taken the approach of managing multiple projects in the same repository, called a Monorepo. The benefits of using a Monorepo become clear with the right tooling. One of those tools is Lerna, which can be used to manage Node-based Monorepos.

When getting started with Kubernetes and Helm, the process across the release life cycle can feel like a black-box; having to follow debugging processes to understand what is going on behind the scenes. Helm hooks can help with that. This post provides an overview of: If you are new to Helm, we suggest to check-out our previous tutorial first and then come back to learn more about Helm hooks. Hooks perform a single action at a specified point during the release life cycle.

Are you a ninja? It’s a silly question. I know that you are most likely not a real ninja. But you might be considering yourself a ninja of software engineering. “What does Viktor mean by that?” I’m glad you asked. Ninjas appear, perform the mission, and disappear without leaving a trace behind. “Why is Viktor talking nonsense? What does that have to do with software engineering?” Again, I’m glad you asked.

Helm is an application package manager for Kubernetes. Using Kubernetes can often be overwhelming to maintain resources. Since Kubernetes is configured by YAML files, the more complex your application becomes, the more difficult it will be to navigate and make changes to the respective files; think about lots and lots of repetitive YAML files. A scenario that makes every developer cringe. Helm can help you solve this.

The GitHub Container Registry has just been announced by GitHub and is supported natively on Codefresh like any other Docker repository. Codefresh provides multiple options to connect to Docker Container Registries, one of which is GitHub Container Registries. Currently, GitHub plans to include the GitHub Container Registry within the pricing model of GitHub packages. In comparison, Docker Hub has added rate limits to free accounts.

We are about to install and manage Argo CD through a CD pipeline. “Why would we do that? We can just as well accomplish that through a command like kubectl apply or helm upgrade --install.” I’m glad you asked. The primary objective of Argo CD is to help us apply GitOps processes when deploying applications. It is directing us towards the world in which everything is defined as code, and all code is stored in Git.

There are many articles and videos about practicing Continuous Delivery (CD) with applications, but not nearly as many for infrastructure. The same can be said for GitOps applied to infrastructure. That is a bit strange given that applications and infrastructure are almost the same today. Both are defined as code, and everyone stores code in Git repositories. Hence, GitOps is just as good of a fit for infrastructure as for anything else.

There are many articles and videos about practicing Continuous Delivery (CD) with applications, but not nearly as many for infrastructure. The same can be said for GitOps applied to infrastructure. That is a bit strange given that applications and infrastructure are almost the same today. Both are defined as code, and everyone stores code in Git repositories. Hence, GitOps is just as good of a fit for infrastructure as for anything else.