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 this article, I’ll explore the “PLEG is not healthy” issue in Kubernetes, which sometimes leads to a “NodeNotReady” status. When understanding how the Pod Lifecycle Event Generator (PLEG) works, it is helpful to also understand troubleshooting around this issue.
What is PLEG?
The PLEG module in kubelet (Kubernetes) adjusts the container runtime state with each matched pod-level event and keeps the pod cache up to date by applying changes.
Continue reading “Pod Lifecycle Event Generator: Understanding the “PLEG is not healthy” issue in Kubernetes”
I recently assisted a client to deploy Elastic Cloud on Kubernetes (ECK) on Red Hat OpenShift 4.x. They had run into an issue where Elasticsearch would throw an error similar to:
Max virtual memory areas vm.max_map_count  likely too low, increase to at least 
According to the official documentation, Elasticsearch uses a
mmapfs directory by default to store its indices. The default operating system limits on mmap counts are likely to be too low, which may result in out of memory exceptions. Usually, administrators would just increase the limits by running:
sysctl -w vm.max_map_count=262144
However, OpenShift uses Red Hat CoreOS for its worker nodes and, because it is an automatically updating, minimal operating system for running containerized workloads, you shouldn’t manually log on to worker nodes and make changes. This approach is unscalable and results in a worker node becoming tainted. Instead, OpenShift provides an elegant and scalable method to achieve the same via its Node Tuning Operator.
Continue reading “Using the Red Hat OpenShift tuned Operator for Elasticsearch”
JBoss Tools 4.13.0 and Red Hat CodeReady Studio 12.13 for Eclipse 2019-09 are here and waiting for you. In this article, I’ll cover the highlights of the new releases and show how to get started.
Continue reading “New features in Red Hat CodeReady Studio 12.13.0.GA and JBoss Tools 4.13.0.Final for Eclipse 2019-09”
The new release of Red Hat OpenShift 4.2 has many developer-focused improvements. In that context, we have released a new version of OpenShift Connector 0.1.1, a Visual Studio (VS) Code extension with more improved features for a seamless developer experience. Developers can now focus on higher-level abstractions like their application and components and can drill down deeper to get to the OpenShift and Kubernetes resources that make up their application directly from VS Code.
Let’s take a deep tour of the new features with respect to OpenShift Connector.
Continue reading “OpenShift Connector: Visual Studio Code extension for Red Hat OpenShift”
This article demonstrates an application update scenario which leverages Red Hat OpenShift image streams together with standard Kubernetes native resources. It also shows how image streams automatically redeploy application pods after an update to their container image.
Best of all, Kubernetes resources enhanced with OpenShift image streams are still compatible with standard Kubernetes clusters. This fact enables the use of the same resource definitions to support multiple Kubernetes distributions, and at the same time take advantage of features unique to OpenShift.
At the end of this article, we present a few considerations around using image IDs and image name tags to manage your ability to roll back to previous versions of an application.
Continue reading “Using Red Hat OpenShift image streams with Kubernetes deployments”
Our first DevNation Live regional event was held in Bengaluru, India in July. This free technology event focused on open source innovations, with sessions presented by elite Red Hat technologists.
Kubernetes has become the de facto standard for hybrid cloud portable application architecture, and in this session, Burr Sutter shows why Kubernetes and Red Hat OpenShift provide the ideal solution for deploying and managing microservices in your organization.
Continue reading “DevNation Live Bengaluru: 9 steps to awesome with Kubernetes and Red Hat OpenShift”
Monitoring systems are usually composed of three layers: a database layer that hosts metrics data, a layer to display the stored metric data graphically in dashboards, and an alerting layer to send out notifications via methods such as email, on-call notification systems, and chat platforms. This article presents an overview of the components used in Red Hat OpenShift‘s Application Monitoring Operator, how to install them using the Operator, and an example of the Operator in action.
Continue reading “Understanding Red Hat OpenShift’s Application Monitoring Operator”
A couple weeks ago I was faced with the challenge of installing Red Hat 3scale and configuring its tenants using solely the command line — no GUI allowed. This is a rather interesting use case, so I decided to write this article and show how to do it with just seven commands!
(By the way, I also decided to include Red Hat Single Sign-On (SSO) in the mix because I want my APIs to use OpenID Connect (OIDC) for authentication. But I’ll leave those commands to a future article.)
Continue reading “Install Red Hat 3scale and configure tenants with 7 simple commands”
We are pleased to announce that Red Hat CodeReady Containers is now available as a Developer Preview. CodeReady Containers brings a minimal, preconfigured OpenShift 4.1 or newer cluster to your local laptop or desktop computer for development and testing purposes. CodeReady Containers supports native hypervisors for Linux, macOS, and Windows 10. You can download CodeReady Containers from the Red Hat CodeReady Containers product page.
CodeReady Containers is designed for local development and testing on an OpenShift 4 cluster. For running an OpenShift 3 cluster locally, see Red Hat Container Development Kit (CDK) or Minishift.
In this article, we’ll look at the features and benefits of CodeReady Containers, show a demo of how easy it is to create a local Red Hat OpenShift 4 cluster, and show how to deploy an application on top of it.
Continue reading “Red Hat OpenShift 4 on your laptop: Introducing Red Hat CodeReady Containers”