Among other improvements and bug fixes in the
vscode-xml extension 0.15.0 release, you can now run the extension without needing Java. We know the Java requirement discouraged many people from trying the extension. We have included a new setting, Prefer Binary (
xml.server.preferBinary) that lets you choose between the Java server and the new binary server. We’re excited to remove the Java restriction from Red Hat’s XML extension for Visual Studio Code in
vscode-xml 0.15.0. Keep reading to find out how we did it.
Continue reading No more Java in vscode-xml 0.15.0!
It has been quite a year for Arm Ltd., the firm that designs reduced instruction set computing (RISC) architectures for computer processors. The news that Arm-based computers will be important for the foreseeable future has even reached the mainstream media. At the end of 2019, Amazon Web Services announced Arm-based Graviton2 servers. In June 2020, Apple announced its plans to move Macintosh computers over to Apple silicon—which means Arm.
Continue reading How Red Hat ported OpenJDK to 64-bit Arm: A community history
Operators are one of the ways to package, deploy, and manage application distribution on Red Hat OpenShift. After a developer creates an Operator, the next step is to get the Operator published on OperatorHub.io. Doing this allows users to install and deploy the Operator in their OpenShift clusters. The Operator is installed, updated, and the management lifecycle is handled by the Operator Lifecycle Manager (OLM).
In this article, we explore the steps required to test the Operator’s OLM integration. For demonstration, we use a simple Operator that prints a test message to the shell. The Operator is packaged in the recently introduced Bundle Format.
Continue reading “Operator integration testing for Operator Lifecycle Manager”
Red Hat CodeReady Workspaces 2.5 is now available. This article introduces support for IBM Power Systems and the new single-host mode in CodeReady Workspaces 2.5. We also briefly discuss support for Red Hat OpenShift 4.6 and language updates in this release.
Note: CodeReady Workspaces 2.5 is available on Red Hat OpenShift 3.11 and Red Hat OpenShift 4.5 and higher.
About CodeReady Workspaces
CodeReady Workspaces (CRW) is based on Eclipse Che, an open source project. CodeReady Workspaces significantly improves developer productivity with near-instant onboarding and consistent, production-like development environments. Developers can use CodeReady Workspaces for cloud-native development on Red Hat OpenShift and other types of development.
Continue reading “Support for IBM Power Systems and more with Red Hat CodeReady Workspaces 2.5”
Welcome to the second part of this series introducing Ansible collection for JCliff. This new extension is designed for fine-tuning WildFly or Red Hat JBoss Enterprise Application Platform (JBoss EAP) configurations using Ansible. In Part 1, we installed JCliff and its Ansible collection and prepared our environment. We set up a minimal, working playbook for installing JCliff on the target system. In this article, we will focus on configuring a few of our WildFly server’s subsystems.
Continue reading WildFly server configuration with Ansible collection for JCliff, Part 2
This three-part series guides you through using Ansible to fine-tune a WildFly or Red Hat JBoss Enterprise Application Platform (JBoss EAP) server configuration. We will use the most recently released version of the Ansible collection for JCliff to extend Ansible’s capabilities. The JCliff collection supports configuring several of the application server subsystems directly from Ansible.
In Part 1, we will mostly focus on the groundwork and discuss all the steps required to be able to use JCliff within Ansible. Once properly installed, we’ll use JCliff to configure WildFly’s
system_props subsystem, which lets us declare system variables in WildFly’s server configuration. Once we have that foundation in place, we’ll begin exploring more interesting configurations in Part 2 and Part 3.
Note: See the Ansible documentation for more about Ansible collections.
Continue reading “WildFly server configuration with Ansible collection for JCliff, Part 1”
In this article, you’ll learn how to deploy Microsoft SQL Server 2019 on Red Hat OpenShift. We’ll then use SQL Server from an ASP.NET Core application that is also deployed on OpenShift. Next, I’ll show you how to connect to SQL Server while working on the application from your local development machine. And finally, we’ll connect to the server using Azure Data Studio.
Continue reading Using Microsoft SQL Server on Red Hat OpenShift
Red Hat CodeReady Workspaces 2.4 is now available. For this release, we focused on adding support for IBM Z and improving the IDE editor and configuration elements.
Continue reading Support for IBM Z and more in CodeReady Workspaces 2.4
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”