OpenShift Container Platform Archives

Debugging applications within Red Hat OpenShift containers

By Serhei Makarov January 9, 2020January 7, 2020

When debugging an application within a Red Hat OpenShift container, it is important to keep in mind that the Linux environment within the container is subject to various constraints. Because of these constraints, the full functionality of debugging tools might not be available:

An unprivileged OpenShift container is restricted from accessing kernel interfaces that are required by some low-level debugging tools.

Note: Almost all applications on OpenShift run in unprivileged containers. Unprivileged containers allow the use of standard debugging tools such as gdbserver or strace. Examples of debugging tools that cannot be used in unprivileged containers include perf, which requires access to the kernel’s perf_events interface, and SystemTap, which depends on the kernel’s module-loading functionality.

Debug information for system packages within OpenShift containers is not accessible. There is ongoing work (as part of the elfutils project) to develop a file server for debug information (debuginfod), which would make such access possible.
The set of packages in an OpenShift container is fixed ahead of time, when the corresponding container image is built. Once a container is running, no additional packages can be installed. A few debugging tools are preinstalled in commonly used container base images, but any other tools must be added when the container image build process is configured.

To successfully debug a containerized application, it is necessary to understand these constraints and how they determine which debugging tools can be used.

Continue reading “Debugging applications within Red Hat OpenShift containers”

Autoscaling Red Hat Fuse applications with OpenShift

By Chandra Shekhar Pandey November 11, 2019November 8, 2019

In this article, we demonstrate Red Hat OpenShift’s horizontal autoscaling feature with Red Hat Fuse applications. The result is a Spring Boot-based application that uses the Apache Camel component twitter-search that searches Twitter for tweets based on specific keywords. If traffic or the number of tweets increases, and this application cannot serve all requests, then the application autoscales itself by increasing the number of pods. The ability to serve all requests is monitored by tracking this application’s CPU utilization on a particular pod. Also, as soon as traffic or CPU utilization is back to normal, the number of pods is reduced to the minimum configured value.

There are two types of scaling: horizontal and vertical. Horizontal scaling is where the number of application instances or containers is increased. Vertical scaling is where system resources like CPU and memory are increased at the running application’s or container’s runtime. Horizontal scaling can be used for stateless applications, whereas vertical scaling is more suitable for stateful applications.

Continue reading “Autoscaling Red Hat Fuse applications with OpenShift”

How to reduce Red Hat Fuse image size

By Pramod Padmanabhan October 10, 2019October 8, 2019

Red Hat Fuse is a leading integration platform, which is capable of solving any given problem with simple enterprise integration patterns (EIP). Over time, Red Hat Fuse has evolved to cater to a wide range of infrastructure needs.

Fuse on Red Hat OpenShift
Fuse standalone

For more information on each of these, check out the Red Hat Fuse documentation. The Fuse on Red Hat OpenShift flavor uses a Fuse image that has runtime components packaged inside a Linux container image. This article will discuss how to reduce the size of the Fuse image. The same principle can be used for other images.

Continue reading “How to reduce Red Hat Fuse image size”

4 steps to set up the MQTT secure client for Red Hat AMQ 7.4 on OpenShift

By Chandra Shekhar Pandey September 25, 2019September 24, 2019

In this article, we show how to set up Red Hat AMQ 7.4 on Red Hat OpenShift. Also, we show how to connect the external Message Queuing Telemetry Transport (MQTT) secure client to the AMQ 7.4 platform. MQTT is a Java-based client that uses the Eclipse Paho library and can publish and consume messages from Red Hat AMQ 7.4 Broker on OpenShift using secure transport. These commands and code have been verified with OpenShift 3.11.

Continue reading “4 steps to set up the MQTT secure client for Red Hat AMQ 7.4 on OpenShift”

Getting started with Tekton on Red Hat OpenShift

By Huub Daems July 19, 2019October 21, 2019

I recently heard about Tekton as an alternative for Jenkins on Red Hat OpenShift. What got my attention was that Tekton uses Operators as building blocks, and Operators are something I am also interested in. I don’t want to get ahead of myself, though; so we’ll start with installing Tekton on Red Hat OpenShift. Installing on Kubernetes is also possible, but for now the focus is on OpenShift.

Continue reading “Getting started with Tekton on Red Hat OpenShift”

Easing application development on Red Hat OpenShift with odo

By Jorge Morales Pou May 2, 2019July 16, 2019

Have you ever developed applications on a platform like Red Hat OpenShift?

I’m a Java developer with more than 15 years of coding experience, and although I’ve been working with OpenShift for more than three years now, I haven’t found it especially easy to use as a day-to-day development platform. Why? There are many reasons, but the key ones involve complexity and speed. In this article, I’ll explain further and provide an introduction to the odo command-line tool.

Continue reading “Easing application development on Red Hat OpenShift with odo”

Using Quiver with AMQ on Red Hat OpenShift Container Platform

By Gareth Healy April 24, 2019September 3, 2019

As part of the Red Hat UKI Professional Services team, I have worked with several customers who are implementing AMQ Broker on Red Hat OpenShift Container Platform (OCP). One question customers typically ask is, “How do we validate that the AMQ configuration is correct for our scenario?” Previously, I would have suggested one of the following:

These tools can give you indicators around:

Is the broker up and running? That is, can it receive/publish messages for this configuration?
Can the broker handle a certain performance characteristic? That is, what is my minimum publish rate per second for this configuration?
And much more.

The problem with these tools is that you cannot choose the client technology. This could lead to real-world differences and limited technology choices, which in turn might lead you down the wrong technology path. In other words:

Do you get the same performance from JMeter versus the AMQ clients you would use in production? Are you comparing like for like? Apples with apples?

So, what do I think is the answer? Quiver [1]. In this article, I’ll provide an overview and demo of using Quiver with Red Hat AMQ on Red Hat OpenShift. If you’re looking for more information on Red Hat AMQ and how it can help, check out this webinar.

Continue reading “Using Quiver with AMQ on Red Hat OpenShift Container Platform”

Red Hat OpenShift 3.11 disconnected installation using Satellite Docker registry

By Mohammad Ahmad April 8, 2019April 3, 2019

In this article, I will discuss the prerequisites and requirements for the successful implementation of Red Hat OpenShift 3.11 disconnected installation using Red Hat Satellite as the local Docker registry, which I have been able to do with the support of my colleagues. I also discuss adjustments that may be required post install.

This work is based on the following references:

Continue reading “Red Hat OpenShift 3.11 disconnected installation using Satellite Docker registry”

Announcing Red Hat CodeReady Studio, the latest evolution of Red Hat Developer Studio

By Bob Davis April 2, 2019September 3, 2019

Red Hat has been shipping a distribution of Eclipse IDE for years now, including all of the great features of Eclipse along with the add-ons, plugins, and tooling that make working with our products easy and enjoyable. These distributions have gone by different names over the years to indicate how they fit into the Red Hat ecosystem, and to tap into the trust that developers have when they think about Red Hat and what a Red Hat product means for them: it’ll be reliable; it’ll have a published lifecycle; it’s built from source; and if you submit a bug, we’ll fix it (and give the fix to the community). This change is no different.

Red Hat CodeReady Studio is the latest evolution of Red Hat Developer Studio, which itself was an evolution of JBoss Developer Studio. We’re proud to include our distribution of Eclipse IDE in the expanding CodeReady portfolio. Based on the latest Eclipse 4.11, with the latest additions of JBoss Tools and end-to-end testing that ensures everything works as expected, developers can count on the same great experience they’ve grown used to. With tools for working with Fuse and other middleware products and connectors for Red Hat OpenShift that enable super-fast, container-native “inner loop” development cycles, CodeReady Studio is absolutely one of the best desktop IDEs an enterprise Java^TM developer can use.

Continue reading “Announcing Red Hat CodeReady Studio, the latest evolution of Red Hat Developer Studio”

IoT edge development and deployment with containers through OpenShift: Part 1

By Alessandro Arrichiello January 31, 2019September 3, 2019

Usually, we think about IoT applications as something very special made for low power devices that have limited capabilities. For this reason, we tend to use completely different technologies for IoT application development than the technology we use for creating a datacenter’s services.

This article is part 1 of a two-part series. In it, we’ll explore some techniques that may give you a chance to use containers as a medium for application builds—techniques that enable the portability of containers across different environments. Through these techniques, you may be able to use the same language, framework, or tool used in your datacenter straight to the “edge,” even with different CPU architectures!

We usually use “edge” to refer to the geographic distribution of computing nodes in a network of IoT devices that are at the “edge” of an enterprise. The “edge” could be a remote datacenter or maybe multiple geo-distributed factories, ships, oil plants, and so on.

Continue reading “IoT edge development and deployment with containers through OpenShift: Part 1”

Blog Articles