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”
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”
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”
Container-native development is primarily about consistency, flexibility, and scalability. Legacy Application Lifecycle Management (ALM) tooling often is not, leading to situations where it:
- Places artificial barriers on development speed, and therefore time to value,
- Creates single points of failure in the infrastructure, and
- Stifles innovation through inflexibility.
Ultimately, developers are expensive, but they are the domain experts in what they build. With development teams often being treated as product teams (who own the entire lifecycle and support of their applications), it becomes imperative that they control the end-to-end process on which they rely to deliver their applications into production. This means decentralizing both the ALM process and the tooling that supports that process. In this article, we’ll explore this approach and look at a couple of implementation scenarios.
Continue reading “Application lifecycle management for container-native development”
In this fourth article of our series about accessing Apache Kafka clusters in Strimzi, we will look at exposing Kafka brokers using load balancers. (See links to previous articles at end.) This article will explain how to use load balancers in public cloud environments and how they can be used with Apache Kafka.
Continue reading “Accessing Apache Kafka in Strimzi: Part 4 – Load balancers”
In the third part of this article series (see links to previous articles below), we will look at how Strimzi exposes Apache Kafka using Red Hat OpenShift routes. This article will explain how routes work and how they can be used with Apache Kafka. Routes are available only on OpenShift, but if you are a Kubernetes user, don’t be sad; a forthcoming article in this series will discuss using Kubernetes Ingress, which is similar to OpenShift routes.
Continue reading “Accessing Apache Kafka in Strimzi: Part 3 – Red Hat OpenShift routes”
This article series explains how Apache Kafka and its clients work and how Strimzi makes it accessible for clients running outside of Kubernetes. In the first article, we provided an introduction to the topic, and here we will look at exposing an Apache Kafka cluster managed by Strimzi using node ports.
Specifically, in this article, we’ll look at how node ports work and how they can be used with Kafka. We also will cover the different configuration options available to users and the pros and cons of using node ports.
Continue reading “Accessing Apache Kafka in Strimzi: Part 2 – Node ports”
Strimzi is an open source project that provides container images and operators for running Apache Kafka on Kubernetes and Red Hat OpenShift. Scalability is one of the flagship features of Apache Kafka. It is achieved by partitioning the data and distributing them across multiple brokers. Such data sharding has also a big impact on how Kafka clients connect to the brokers. This is especially visible when Kafka is running within a platform like Kubernetes but is accessed from outside of that platform.
This article series will explain how Kafka and its clients work and how Strimzi makes it accessible for clients running outside of Kubernetes.
Continue reading “Accessing Apache Kafka in Strimzi: Part 1 – Introduction”
If you weren’t lucky enough to attend the recent Red Hat Summit or you went but couldn’t make it to all the container-related sessions, worry not. We teamed up with Scott McCarty, Principal Technology Product Manager–Containers at Red Hat, to bring you an overview of what you missed.
Choosing the right container base image for your applications
The Red Hat Universal Base Image (UBI) gives you three options for building containers with the full power of Red Hat Enterprise Linux (RHEL) underneath. The goal is to create the smallest possible image that fully supports your application. You select a base image depending on the application you’re packaging in a container. For example, if you have a Golang or .NET application, all of that application’s dependencies are built in. That means you can use the minimal image (
ubi-minimal), which contains
microdnf, a package manager that only supports install, update, and remove functions. It also includes, well, a minimal set of tools.
Continue reading “Container-related content you might have missed at Red Hat Summit”