When it comes to the container world, it is common to have an application deployed to a cluster that needs to be secured. In this article, I will show you how to enable HTTPS and SSL termination for a Quarkus application that is running in Red Hat OpenShift.
Continue reading How to enable HTTPS and SSL termination in a Quarkus app
DevNation Tech Talks are hosted by the Red Hat technologists who create our products. These sessions include real solutions plus code and sample projects to help you get started. In this talk, you’ll learn about cloud-native modernization from Daniel Oh and Burr Sutter.
Are you familiar with the tight coupling of applications with their underlying platform that makes change hard? Or, coupling that creates a lack of scalability, performance, and flexibility for existing applications built with legacy technology? How about the fact that re-architecting applications cannot be done overnight?
Continue reading “Cloud-native modernization or death? A false dichotomy”
This article is a quick look at two exciting updates in the new Open Liberty 220.127.116.11 release. First, you can now use the Kerberos authentication protocol to secure Java Database Connectivity (JDBC) data sources. I’ll introduce the new
kerberos configuration element in Open Liberty’s
server.xml and show you how to use the Kerberos protocol to secure a data source.
Continue reading Open Liberty 18.104.22.168 brings Kerberos authentication and Thanos support in Grafana dashboards
In this article, I will introduce helpful, common tips for managing reliable builds and deployments on Red Hat OpenShift. If you have experienced a sudden performance degradation for builds and deployments on OpenShift, it might be helpful to troubleshoot your cluster. We will start by reviewing the whole process, from build to deployment, and then cover each aspect in more detail. We will use Red Hat OpenShift 4.2 (Kubernetes 1.14) for this purpose.
Continue reading “How to maintain stable build and deployment performance on Red Hat OpenShift”
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”