We as Java developers are often busy working on our applications by optimizing application memory, speed, etc. In recent years, encapsulating our applications into lightweight, independent units called containers has become quite a trend, and almost every enterprise is trying to shift its infrastructure onto container technologies like Docker and Kubernetes.
Kubernetes is an open source system for automating deployment, scaling, and management of containerized applications, but it has a steep learning curve, and an application developer with no background in DevOps can find this system a bit overwhelming. In this article, I will talk about tools that can help when deploying your Maven applications to Kubernetes/Red Hat OpenShift.
Continue reading “Introduction to Eclipse JKube: Java tooling for Kubernetes and Red Hat OpenShift”
Open Virtual Network (OVN) is a project born as a sub-component of Open vSwitch (OVS), which is a performant, programmable, multi-platform virtual switch. OVN allows OVS users to natively create overlay networks by introducing virtual network abstractions such as virtual switches and routers. Moreover, OVN provides methods for setting up Access Control Lists (ACLs) and network services such as DHCP. Many Red Hat products, like Red Hat OpenStack Platform, Red Hat Virtualization, and Red Hat OpenShift Container Platform, rely on OVN to configure network functionalities.
In this article, I will cover the OVN unidling issue and how the proposed solution can be used to forward events to a CMS (e.g., OpenStack or OpenShift).
Continue reading “Open Virtual Network unidling”
The Eclipse Che 7.6.0 release provides a new stack for Apache Camel K integration development. This release is the first iteration to give a preview of what is possible. If you like what you see, shout it out, and more will surely come.
This article details how to test this release on a local instance deployed on minikube. The difference with a hosted instance is that we avoid the prerequisites involving Camel K installation in the cluster and specific rights for the user.
Continue reading “Apache Camel K development inside Eclipse Che: Iteration 1”
In a previous article, I showed how to get Red Hat CodeReady Workspaces 2.0 (CRW) up and running with a workspace available for use. This time, we will go through the edit-debug-push (to GitHub) cycle. This walk-through will simulate a real-life development effort.
To start, you’ll need to fork a GitHub repository. The
Quote Of The Day repo contains a microservice written in Go that we’ll use for this article. Don’t worry if you’ve never worked with Go. This is a simple program and we’ll only change one line of code.
After you fork the repo, make note of (or copy) your fork’s URL. We’ll be using that information in a moment.
Continue reading “Editing, debugging, and GitHub in Red Hat CodeReady Workspaces 2”
In this article, we take a look at user flow improvements for deploying applications in Red Hat OpenShift 4.3‘s Developer perspective. You can learn more about all of the developer-focused console improvements in the OpenShift 4.3 release article here. Since the initial launch of the Developer perspective in the OpenShift 4.2 release, we’ve had frequent feedback sessions with developers, developer advocates, stakeholders, and other community members to better understand how the experience meets their needs. While, overall, the user interface has been well received, we continue to gather and use the feedback to enhance our flows.
Continue reading Deploying applications in the OpenShift 4.3 Developer perspective
In this article, we look at the various ways .NET Core is made available on Red Hat platforms. We start with an overview of the available platforms, and then show how to install .NET Core on each of them.
Continue reading .NET Core on Red Hat platforms
The developer experience is significantly improved in the Red Hat OpenShift 4.3 web console. If you have used the Developer perspective, which was introduced in OpenShift 4.2 Console, you are probably familiar with our streamlined user flows for deploying applications, the new Topology view, and the enhanced experience around OpenShift Pipelines powered by Tekton and OpenShift Serverless powered by Knative. This release continues to improve upon the features that were introduced in 4.2 and introduces new flows and features for the developer.
Continue reading What’s new in the OpenShift 4.3 console developer experience
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”
We are pleased to announce an improved software certification for Red Hat partner products built for Red Hat Enterprise Linux 8 (RHEL 8). This new RHEL software certification validates the use of common best practices, improves joint supportability, and promotes your product in the new Red Hat Ecosystem Catalog.
What is this certification?
This certification now features a partner executable test suite that produces results that are then reviewed by Red Hat. Your non-containerized software is certified when the test results show successful interoperability with Red Hat Enterprise Linux 8 in a secure, supportable manner using best practices. Once verified, you can promote your product(s) in the Red Hat Ecosystem catalog.
In addition, Red Hat will grant partners a complimentary Limited membership to TSANet for collaborative customer case management to improve their ongoing user experiences.
Continue reading “Introducing new Red Hat Enterprise Linux certification for software partner products”
As an architect in the Red Hat Consulting team, I’ve helped countless customers with their integration challenges over the last six years. Recently, I had a few consulting gigs around Red Hat AMQ 7 Broker (the enterprise version of Apache ActiveMQ Artemis), where the requirements and outcomes were similar. That similarity made me think that the whole requirement identification process and can be more structured and repeatable.
This guide is intended for sharing what I learned from these few gigs in an attempt to make the AMQ Broker architecting process, the resulting deployment topologies, and the expected effort more predictable—at least for the common use cases. As such, what follows will be useful for messaging and integration consultants and architects tasked with creating a messaging architecture for Apache Artemis, and other messaging solutions in general. This article focuses on Apache Artemis. It doesn’t cover Apache Kafka, Strimzi, Apache Qpid, EnMasse, or the EAP messaging system, which are all components of our Red Hat AMQ 7 product offering.
Continue reading “Architecting messaging solutions with Apache ActiveMQ Artemis”