Red Hat CodeReady Containers (CRC) is the quickest way for developers to get started with clusters on Red Hat OpenShift 4.1 or newer. CodeReady Containers is designed to run on a local computer. It simplifies setup and testing by emulating the cloud development environment locally with all of the tools that you need to develop container-based applications.
Red Hat Marketplace is an open cloud marketplace that makes it easy to discover and purchase the certified, containerized tools you need to build enterprise-first applications. It was created to help developers using OpenShift build applications and deploy them across a hybrid cloud. Red Hat Marketplace works on any developer workstation that is running CodeReady Containers.
This article guides you through the steps of setting up Red Hat Marketplace and installing containerized products in your local CodeReady Containers-based OpenShift clusters.
Continue reading “Install Red Hat OpenShift Operators on your laptop using Red Hat CodeReady Containers and Red Hat Marketplace”
Imagine an information technology (IT) world where everything is ideal: Every company has switched over to cloud-native applications, every application is containerized, everything is automated, and the IT people see that the world is good. Things are not so ideal in the real world, though, as we know. Applications remain tightly coupled with traditional virtual machine (VM) resources such as software libraries and hardware resources. The effort to migrate them from VMs to containers seems insurmountable, requiring years of dedicated spending and hours from developers and software architects.
The dilemma is that companies want all of their applications to eventually run on containers, but they also need to support applications running on VMs until that glorious shift happens. Given that application migration from VMs to containers will happen over the long haul, some companies are exploring a lift-and-shift approach. In theory, lift-and-shift would let us migrate tightly-coupled legacy applications to a container platform like Red Hat OpenShift. Rather than rewriting application code, developers would simply write interfaces (essentially, code with patterns) that are compatible with the existing structure.
Unfortunately, this scenario is unrealistic for legacy projects involving hundreds of application modules and packages. Therefore, it is logical to ask: What if there was a way to support existing applications running on virtual machines and new applications running on containers in one unified container-based platform?
Luckily, there is a way: Use a Kubernetes-based platform like OpenShift.
In this article, I introduce OpenShift Virtualization, a feature for Red Hat OpenShift Container Platform (OCP). OpenShift Virtualization allows you to run and manage virtual-machine workloads alongside container workloads.
Note: As of version 2.4 when CNV went GA, Container-Native Virtualization was renamed OpenShift Virtualization.
Continue reading “Enable OpenShift Virtualization on Red Hat OpenShift”
In Red Hat Enterprise Linux (RHEL) 8, the userspace utility program
iptables has a close relationship to its successor,
nftables. The association between the two utilities is subtle, which has led to confusion among Linux users and developers. In this article, I attempt to clarify the relationship between the two variants of
iptables and its successor program,
Continue reading iptables: The two variants and their relationship with nftables
For many years, application developers who wanted to create desktop applications for Linux had to build their applications not just for a particular Linux operating system, but for a particular version of that operating system. Whether it was on the server-side or the desktop, developers wanted to create applications that reliably worked the same in development and production environments. They wanted to upgrade the production environment without having to rebuild and revalidate every running application.
Continue reading Introducing the Red Hat Flatpak runtime for desktop containers
The Java community has demonstrated time and time again its ability to evolve, improve, and adapt to meet the needs of its developers and users. Even after 25 years of language and framework choices, Java has consistently ranked in the top languages in use today due to its strong track record and capabilities in enterprise use cases. Red Hat has long been a strong leader in Java and open source software development and remains committed to being at the forefront of Java as it continues to evolve.
Today, Red Hat and the GraalVM community jointly established a new downstream distribution of GraalVM, called Mandrel. This distribution will power the Red Hat build of Quarkus, a recently announced addition to Red Hat Runtimes. This article explains what Mandrel is and why it is necessary.
Continue reading “Mandrel: A community distribution of GraalVM for the Red Hat build of Quarkus”
I’ve had many proud moments in my role here at Red Hat over the years. Examples include when we released the first version of WildFly, when we acquired the Camel team, when we worked with other vendors to create Eclipse MicroProfile, the great work the Strimzi team did to get into the Cloud Native Computing Foundation, our entire Red Hat Managed Integration effort, Kogito, and the list goes on. I feel like I add to this list of examples on an almost weekly basis.
Well, I can now update this list with the first product release of Quarkus, formally called the Red Hat build of Quarkus. (You can also find more support options on the Quarkus project site.) It should come as no surprise that Quarkus is on this list. I suppose what might surprise some people is that Quarkus is only just a product now. Given all of the activities since we officially launched the Quarkus project in 2019, you could be forgiven for thinking it was already a product.
Continue reading “The road to Quarkus GA: Completing the first supported Kubernetes-native Java stack”
Red Hat Software Collections 3.5 and Red Hat Developer Toolset 9.1 are now available for Red Hat Enterprise Linux 7. Here’s what that means for developers.
Red Hat Software Collections (RHSCL) is how we distribute the latest stable versions of various runtimes and languages through Red Hat Enterprise Linux (RHEL) 7, with some components available in RHEL 6. RHSCL also contains the Red Hat Developer Toolset, which is the set of tools we curate for C/C++ and Fortran. These components are supported for up to five years, which helps you build apps that have a long lifecycle as well.
Continue reading “Red Hat Software Collections 3.5 brings updates for Red Hat Enterprise Linux 7”
It isn’t always easy to understand how Open vSwitch (OVS) cycles are spent, especially because various parameters and configuration options can affect how OVS behaves. Members of the Open vSwitch community are actively working to understand what causes packets drops in Open vSwitch. Efforts so far have included adding a custom statistic for vHost TX retries, tracking vHost TX contention, and adding a coverage counter to count vHost IRQs. We are particularly interested in the user space datapath that uses the Data Plane Development Kit (DPDK) for fast I/O.
Adding these statistics is an ongoing effort, and we won’t cover all of the corners. In some cases, the statistics leave doubts about what is causing a behavior.
In this article, I will introduce a new counter we’ve added to learn more about contention in the vHost transmission path. I’ll also show you how to use the new counter with
perf, and I’ll discuss what’s next for our ongoing efforts.
Continue reading “Debugging vHost user TX contention in Open vSwitch”
In previous posts, Stack Clash Mitigation in GCC — Background and Stack Clash mitigation in GCC: Why -fstack-check is not the answer, I hopefully showed the basics of how stack clash attacks are structured and why GCC’s existing
-fstack-check mechanism is insufficient for protection.
So, what should we do? Clearly we want something similar to
-fstack-check, but without the fundamental problems. Enter a new option:
The key principles for code generation to prevent a stack clash attack are:
Continue reading “Stack clash mitigation in GCC, Part 3”
On April 21st, Node.js released its latest major version with Node.js 14. Because this is an even-numbered release, it will become a Long Term Support (LTS) release in October 2020. This release brings a host of improvements and features, such as improved diagnostics, a V8 upgrade, an experimental Async Local Storage API, hardened the streams APIs, and more.
While Red Hat will release a Universal Base Image (UBI) for Node.js 14 in the coming months for Red Hat OpenShift and Red Hat Enterprise Linux, this article helps you get started today. If you’re interested in more about Node.js 14’s improvements and new features, check out the article listed at the end.
Continue reading “Use Node.js 14 on Red Hat OpenShift”