Welcome to Yet Another Useless Blog
Well we hope the articles here are not totally useless :)
Who are we, you might ask. We (Thomas Jungbauer and Toni Schmidbauer) are two old IT guys, working in the business since more than 20 years. At the moment we are architects at Red Hat Austria, mainly responsible helping customers with OpenShift or Ansible architectures.
The articles in this blog shall help to easily test and understand specific issues so they can be reproduced and tested. We simply wrote down what we saw in the field and of what we thought it might be helpful, so no frustrating searches in documentations or manual testing is required.
If you have any question, please feel free to send us an e-mail or create a GitHub issue
Recent Posts
Configure App-of-Apps
Thomas Jungbauer
In the article Install GitOps to the cluster OpenShift GitOps is deployed using a shell script. This should be the very first installation and the only deployment that is done manually on a cluster. This procedure automatically installs the so-called App-of-Apps named Argo CD Resources Manager which is responsible for all further Argo CD Applications and ApplicationSets. No other configuration should be done manually if possible.
This article will demonstrate how to configure the App-of-Apps in an easy and declarative way, using ApplicationSet mainly.
OpenShift Data Foundation - Noobaa Bucket Data Retention (Lifecycle)
Data retention or lifecycle configuration for S3 buckets is done by the S3 provider directly. The provider keeps track and files are automatically rotated after the requested time.
This article is a simple step-by-step guide to configure such lifecycle for OpenShift Data Foundation (ODF), where buckets are provided by Noobaa. Knowledge about ODF is assumed, however similar steps can be reproduced for any S3-compliant storage operator.
Setup OpenShift GitOps/Argo CD
„If it is not in GitOps, it does not exist“ - is a mantra I hear quite often and also try to practice at customer engagements. The idea is to have Git as the only source of truth on what happens inside the environment. That said, Everything as Code is a practice that treats every aspect of the system as a code. Storing this code in Git provides a shared understanding, traceability and repeatability of changes.
While there are many articles about how to get GitOps into the deployment process of applications, this one rather sets the focus on the cluster configuration and tasks system administrators usually have to do.
GitOps - Choosing the right Git repository structure
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.
Copyright © 2020 - 2024 Toni Schmidbauer & Thomas Jungbauer