In addition to a huge set of new features and improvements, the release of Red Hat JBoss Enterprise Application Platform 7.3 provides innovative packaging capabilities. In this article, I will highlight two of these new capabilities and demonstrate their benefits: splitting images into build versus runtimes, and configuration trimming with Galleon.
Continue reading JBoss EAP 7.3 brings new packaging capabilities
A previous article, Debugging applications within Red Hat OpenShift containers, gives an overview of tools for debugging applications within Red Hat OpenShift containers, and existing restrictions on their use. One of the restrictions discussed in that article was an inability to install debugging tool packages into an ordinary, unprivileged container once it was already instantiated. In such a container, debugging tool packages have to be included when the container image is built, because once the container is instantiated, using package installation commands requires elevated privileges that are not available to the ordinary container user.
However, there are important situations where it is desirable to install a debugging tool into an already-instantiated container. In particular, if the resolution of a problem requires access to the temporary state of a long-running containerized application, the usual method of adding debugging tools to the container by rebuilding the container image and restarting the application will destroy that temporary state.
To provide a way to add debugging tools to unprivileged containers, I developed a utility, called
oc-inject, that can temporarily copy a debugging tool into a container. Instead of relying on package management or other privileged operations,
oc-inject’s implementation is based on the existing and well-supported OpenShift operations
oc rsync and
oc exec, which do not require any elevated privileges.
This article describes the current capabilities of the
oc-inject utility, which is available on GitHub or via a Fedora COPR repository. The
oc-inject utility works on any Linux system that includes Python 3, the
ldd utility, and the Red Hat OpenShift command-line tool
Continue reading “Installing debugging tools into a Red Hat OpenShift container with oc-inject”
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
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”
For the past two years, Red Hat Middleware has provided a supported Node.js runtime on Red Hat OpenShift as part of Red Hat Runtimes. Our goal has been to provide rapid releases of the upstream Node.js core project, example applications to get developers up and running quickly, Node.js container images, integrations with other components of Red Hat’s cloud-native stack, and (of course) provide world-class service and support for customers. Earlier this year, the team behind Red Hat’s distribution and support of Node.js even received a “Devie” award from DeveloperWeek for this work, further acknowledging Red Hat’s role in supporting the community and ecosystem.
Red Hat Node.js experts at your fingertips
Red Hat collaborates in more ways than one with the fastest growing runtimes used in business-critical applications on the cloud by contributing to the community, being part of the Technical Steering Committee, and even participating and driving strategic initiatives to carve the future of Node.js. Combining this work with our Red Hat Enterprise Linux (RHEL) and OpenShift expertise, we can help you reach your goals of delivering and supporting business-critical applications on and off the cloud.
Continue reading “Red Hat support for Node.js”
In the past few years, the popularity and adoption of containers has skyrocketed, and the Kubernetes container orchestration platform has been largely adopted as well. With these changes, a new set of challenges has emerged when dealing with applications deployed on Kubernetes clusters in the real world. One challenge is how to deal with communication between multiple clusters that might be in different networks (even private ones), behind firewalls, and so on.
One possible solution to this problem is to use a Virtual Application Network (VAN), which is sometimes referred to as a Layer 7 network. In a nutshell, a VAN is a logical network that is deployed at the application level and introduces a new layer of addressing for fine-grained application components with no constraints on the network topology. For a much more in-depth explanation, please read this excellent article.
So, what is Skupper? In the project’s own words:
Skupper is a layer seven service interconnect. It enables secure communication across Kubernetes clusters with no VPNs or special firewall rules.
Continue reading “Skupper.io: Let your services communicate across Kubernetes clusters”
In the previous article, we introduced the Service Binding Operator and explained how it functions. In this article, we’ll look at a more advanced topic—custom environment variables—and walk through a typical usage scenario.
Continue reading Service Binding Operator: The Operator in action
Connecting applications to the services that support them—for example, establishing the exchange of credentials between a Java application and a database that it requires—is referred to as binding. The configuration and maintenance of this binding together of applications and backing services can be a tedious and inefficient process. Manually editing YAML files to define binding information is error-prone and can introduce difficult-to-debug failures.
Continue reading Introducing the Service Binding Operator
In the past few years, developers have addressed the challenge of evolving from monolith systems to microservices architecture. These days, we hear about the adoption of serverless systems.
Like many trends in software, there’s no one clear view of how to define serverless or how this approach offers added value for our software architecture. The perfect place to start with serverless systems and discover serverless capabilities is through a use case.
Continue reading “Move your APIs into the serverless era with Camel K and Knative”
Secure communication over a computer network is one of the most important requirements for a system, and yet it can be difficult to set up correctly. This example shows how to set up Red Hat AMQ Streams‘ end-to-end TLS encryption using a custom X.509 CA certificate on the Red Hat OpenShift platform.
You need to have the following in place before you can proceed with this example:
Continue reading “Set up Red Hat AMQ Streams custom certificates on OpenShift”
In an earlier article, Aaron Merey introduced the new elfutils
debuginfo-server daemon. With this software now integrated and released into elfutils 0.178 and coming to distros near you, it’s time to consider why and how to set up such a service for yourself and your team.
debuginfod exists to distribute ELF or DWARF debugging information, plus associated source code, for a collection of binaries. If you need to run a debugger like
gdb, a trace or probe tool like
systemtap, binary analysis tools like
pahole, or binary rewriting libraries like
dyninst, you will eventually need
debuginfo that matches your binaries. The
debuginfod client support in these tools enables a fast, transparent way of fetching this data on the fly, without ever having to stop, change to root, run all of the right
yum debuginfo-install commands, and try again. Debuginfo lets you debug anywhere, anytime.
We hope this opening addresses the “why.” Now, onto the “how.”
Continue reading “Deploying debuginfod servers for your developers”