Imagine this scenario: Your cool microservice works fine from your local machine but fails when deployed into your Red Hat OpenShift cluster. You cannot see anything wrong with the code or anything wrong in your services, configuration maps, secrets, and other resources. But, you know something is not right. How do you look at things from the same perspective as your containerized application? How do you compare the runtime environment from your local application with the one from your container?
If you performed your due diligence, you wrote unit tests. There are no hard-coded configurations or hidden assumptions about the runtime environment. The cause should be related to the configuration your application receives inside OpenShift. Is it time to run your app under a step-by-step debugger or add tons of logging statements to your code?
We’ll show how two features of the OpenShift command-line client can help: the
oc run and
oc debug commands.
Continue reading “Troubleshooting Red Hat OpenShift applications with throwaway containers”
One of the cool things about separating the container runtimes into different tools is that you can start to combine them to help secure one other.
Lots of people would like to build OCI/container images within a system like Kubernetes. Imagine you have a CI/CD system that is constantly building container images, a tool like Red Hat OpenShift/Kubernetes would be useful for distributing the load of builds. Until recently, most people were leaking the Docker socket into the container and then allowing the containers to do
docker build. As I pointed out years ago, this is one of the most dangerous things you can do. Giving people root access on the system or sudo without requiring a password is more secure than allowing access to the Docker socket.
Because of this, many people have been attempting to run Buildah within a container. We have been watching and answering questions on this for a while. We have built an example of what we think is the best way to run Buildah inside of a container and have made these container images public at quay.io/buildah.
Continue reading “Best practices for running Buildah in a container”
When we announced Red Hat Enterprise Linux 8 in May, we also announced that all RHEL 8 base operating systems images, and many new RHEL 7 ones, would be available under the new Universal Base Image End User License Agreement (EULA). If UBI is new for you, this article summarizes UBI, explains why you’d want to use it, and supplies a set of resources to get you started with UBI. And, if you have questions, we just published a brand new UBI FAQ.
Continue reading “Red Hat Universal Base Image: How it works in 3 minutes or less”
More and more CPUs implement new features with instructions that are executed as NOPs (no-operation instructions) on previous CPU generations. This results in some challenges for operating system builders, particularly in the area of legacy software support.
Continue reading “Guidelines for instruction encoding in the NOP space”
As a software developer, it’s often necessary to access a relational database—or any type of database, for that matter. If you’ve been held back by that situation where you need to have someone in operations provision a database for you, then this article will set you free. I’ll show you how to spin up (and wipe out) a MySQL database in seconds using Red Hat OpenShift.
Continue reading “MySQL for developers in Red Hat OpenShift”
One of the things I enjoy most about using Red Hat OpenShift is the Developer Catalog. The Developer Catalog is a central location where a team working with Red Hat OpenShift can encapsulate and share how application components and services are deployed.
The Developer Catalog is often used to define an infrastructure pattern referred to as a builder image. A builder image is a container image that supports a particular language or framework, following best practices and Source-to-Image (s2i) specifications.
The OpenShift Developer Catalog provides several standard builder images supporting applications written in Node.js, Ruby, Python, and more. And while the Developer Catalog has many easy ways to get started deploying several supported languages, the catalog is also flexible in allowing you to add your own builder images to support an infrastructure pattern that is not preloaded in the catalog.
Continue reading “Using a custom builder image on Red Hat OpenShift with OpenShift Do”
Minikube has a feature called add-ons, which help in adding extra components and features to Minikube’s Kubernetes cluster.
The registry add-on will deploy an internal registry, which can then be used to push and pull Linux container images. But at times, we might wish to mimic push and pull to different registries (i.e., using aliases for container registry). In this article, I will walk you through the steps required to achieve the same.
Continue reading “Deploying an internal container registry with Minikube add-ons”
Cloud-native environment architecture can be challenging to understand. To help make sense of it for application developers and software/system architects, I will attempt to explain the various parts and how they work together. Toward this end, I find it helpful to think about the architecture in four separate layers: application software development, service scaling, application network, and container orchestration platform.
In this article, I will describe the first technology layer: application software development. I drew the following diagram to make these concepts easier to visualize.
Continue reading “Introduction to cloud-native application environment architecture”
You’ve created a container image that has all the packages that you and your team need to do something useful, or maybe you’ve built a public image that anybody can use. But, what if that image contains packages with known security vulnerabilities? Regardless of the severity of those vulnerabilities, you’ll want to learn more and take steps to mitigate them as soon as possible.
Fortunately, your team uses Quay.io* as your registry. When you push an image to Quay.io, it automatically runs a security scan against that image.
Continue reading “Using Quay.io to find vulnerabilities in your container images”
In the fifth and final part of this series, we will look at exposing Apache Kafka in Strimzi using Kubernetes Ingress. This article will explain how to use Ingress controllers on Kubernetes, how Ingress compares with Red Hat OpenShift routes, and how it can be used with Strimzi and Kafka. Off-cluster access using Kubernetes Ingress is available only from Strimzi 0.12.0. (Links to previous articles in the series can be found at the end.)
Continue reading “Accessing Apache Kafka in Strimzi: Part 5 – Ingress”