OpenShift
GitOps - Choosing the right Git repository structure
Thomas Jungbauer
One of the most popular questions asked before adopting the GitOps approach is how to deploy an application to different environments (Test, Dev, Production, etc.) in a safe and repeatable way.
Each organisation has different requirements, and the choice will depend on a multitude of factors that also include non-technical aspects.
Therefore, it is important to state: "There is no unique “right” way, there are common practices".
Introducing the GitOps Approach
When managing one or more clusters, the question arises as to how cluster configurations and applications can be installed securely, regularly, and in the same way. This is where the so-called GitOps approach helps, according to the mantra: "If it is not in Git, it does not exist".
The idea is to have Git as the only source of truth on what happens inside the environment. While there are many articles about how to get GitOps into the deployment process of applications, this series of articles tries to set the focus on the cluster configuration and tasks system administrators usually have to do, for example: Setup an Operator.
Running Falco on OpenShift 4.12
Toni Schmidbauer
As mentioned in our previous post about Falco, Falco is a security tool to monitor kernel events like system calls or Kubernetes audit logs to provide real-time alerts.
In this post I'll show to customize Falco for a specific use case. We would like to monitor the following events:
- An interactive shell is opened in a container
- Log all commands executed in an interactive shell in a container
- Log read and writes to files within an interactive shell inside a container
- Log commands execute via `kubectl/oc exec` which leverage the
pod/execK8s endpoint
Quay Deployment and Configuration using GitOps
Installing and configuring Quay Enterprise using a GitOps approach is not as easy as it sounds. On the one hand, the operator is deployed easily, on the other hand, the configuration of Quay is quite tough to do in a declarative way and syntax rules must be strictly followed.
In this article, I am trying to explain how I solved this issue by using a Kubernetes Job and a Helm Chart.
Setting up Falco on OpenShift 4.12
Falco is a security tool to monitor kernel events like system calls to provide real-time alerts. In this post I'll document the steps taken to get Open Source Falco running on an OpenShift 4.12 cluster.
UPDATE: Use the falco-driver-loader-legacy image for OpenShift 4.12 deployments.
How to force a MachineConfig rollout
While playing around with Falco (worth another post) I had to force a MachineConfig update even so the actual configuration of the machine did not change.
This posts documents the steps taken.
Introduction to a Secure Supply Chain
The goal of the following ("short") series is to build a secure CI/CD pipeline step by step using OpenShift Pipelines (based on Tekton). The whole build process shall pull and build an image, upload it to a development environment and subsequently update the production environment.
The main focus here is security. Several steps and tools shall help to build and deploy a Secure Supply Chain.
The whole process is part of a Red Hat workshop which can present to your organization. I did some tweaks and created a step-by-step plan in order to remember it … since I am getting old :)
Step 1 - Listen to Events
In this first step, we will simply prepare our environment to be able to retrieve calls from Git. In Git we will fork a prepared source code into a repository and any time a developer pushes a new code into our repository a webhook will notify OpenShift Pipelines to start the pipeline. Like most pipelines, the first task to be executed is to fetch the source code so it can be used for the next steps. The application I am going to use is called globex-ui and is an example webUI build with Angular.
Copyright © 2020 - 2025 Toni Schmidbauer & Thomas Jungbauer