Automate workshop setup with Ansible playbooks and CodeReady Workspaces

Automate workshop setup with Ansible playbooks and CodeReady Workspaces

At Red Hat, we do many in-person and virtual workshops for customers, partners, and other open source developers. In most cases, the workshops are of the “bring your own device” variety, so we face a range of hardware and software setups and corporate endpoint-protection schemes, as well as different levels of system knowledge.

Continue reading Automate workshop setup with Ansible playbooks and CodeReady Workspaces

Share
A developer-centered approach to application development

A developer-centered approach to application development

Do you dream of a local development environment that’s easy to configure and works independently from the software layers that you are currently not working on? I do!

As a software engineer, I have suffered the pain of starting projects that were not easy to configure. Reading the technical documentation does not help when much of it is outdated, or even worse, missing many steps. I have lost hours of my life trying to understand why my local development environment was not working.

An ideal scenario

As a developer, you have to meet a few prerequisites before contributing to a project. For instance, you must agree to the version-control requirements, and you need to know how to use the project IDE, how to use a package manager, and so on.

But nothing more. You don’t need to learn a poorly documented, made-in-house framework just to satisfy the ego of an architect who wanted to reinvent the wheel. You don’t need to run an external virtual machine to emulate the production environment. As a developer, you are free to invest your time in improving the code and adding value to the product.

A developer-centered approach to application development

My goal with this article is to describe strategies for building an Angular 8 application in a way that centers the developer experience.

Continue reading “A developer-centered approach to application development”

Share
Build a simple cloud-native change data capture pipeline

Build a simple cloud-native change data capture pipeline

Change data capture (CDC) is a well-established software design pattern for a system that monitors and captures data changes so that other software can respond to those events. Using KafkaConnect, along with Debezium Connectors and the Apache Camel Kafka Connector, we can build a configuration-driven data pipeline to bridge traditional data stores and new event-driven architectures.

This article walks through a simple example.

Continue reading “Build a simple cloud-native change data capture pipeline”

Share
Improved schema binding and more in Red Hat XML extension for VS Code 0.12.0 and LemMinX

Improved schema binding and more in Red Hat XML extension for VS Code 0.12.0 and LemMinX

The latest update of the Red Hat XML extension for Visual Studio Code (VS Code), version 0.12.0, is packed with bug fixes and new features. It includes the new version of the underlying Eclipse LemMinX XML language server. In this update, we streamlined the process of writing XML Schema Definitions (XSD) and Document Type Definitions (DTD). We also added shortcuts to bind XML documents to either of these types of XML grammar.

Continue reading Improved schema binding and more in Red Hat XML extension for VS Code 0.12.0 and LemMinX

Share
Install Apache Tomcat and deploy a Java web application on Red Hat OpenShift

Install Apache Tomcat and deploy a Java web application on Red Hat OpenShift

If you are new to OpenShift, then you might want to install Apache Tomcat on top of it for simpler experimentation. This article guides you through installing Apache Tomcat from a Docker image and then using it to deploy a Java web app on Red Hat OpenShift. I also show you how to access the Tomcat management console on OpenShift.

To follow the examples, you must have an OpenShift account. We will use the OpenShift command-line interface (CLI) for this demonstration, so be sure to install the CLI (oc) before you begin.

A note about the sample application: You will need a Java web application to use for the deployment example. I am using the Sample Java Web Application from the OpenShift Demos GitHub repository. It is a simple application that is useful for understanding basic concepts. You may use the provided sample or choose your own application to work with.

Continue reading “Install Apache Tomcat and deploy a Java web application on Red Hat OpenShift”

Share
Develop Eclipse MicroProfile applications on Red Hat JBoss Enterprise Application Platform Expansion Pack 1.0 with Red Hat CodeReady Workspaces

Develop Eclipse MicroProfile applications on Red Hat JBoss Enterprise Application Platform Expansion Pack 1.0 with Red Hat CodeReady Workspaces

This article builds on my previous tutorial, Enable Eclipse MicroProfile applications on Red Hat JBoss Enterprise Application Platform 7.3. To follow the examples, you must have Eclipse MicroProfile enabled in your Red Hat JBoss Enterprise Application Platform Expansion Pack (JBoss EAP XP) 1.0.0.GA installation, via Red Hat CodeReady Studio. See the previous article for installation instructions.

In this article, we will use the installed MicroProfile-enabled image to set up a JBoss EAP XP quickstart project in Red Hat CodeReady Workspaces (CRW). You can also apply what you learn from this article to develop your own applications using CodeReady Workspaces.

Note: For more examples, be sure to see the video demonstration at the end of the article.

Continue reading “Develop Eclipse MicroProfile applications on Red Hat JBoss Enterprise Application Platform Expansion Pack 1.0 with Red Hat CodeReady Workspaces”

Share
Kourier: A lightweight Knative Serving ingress

Kourier: A lightweight Knative Serving ingress

Until recently, Knative Serving used Istio as its default networking component for handling external cluster traffic and service-to-service communication. Istio is a great service mesh solution, but it can add unwanted complexity and resource use to your cluster if you don’t need it.

That’s why we created Kourier: To simplify the ingress side of Knative Serving. Knative recently adopted Kourier, so it is now a part of the Knative family! This article introduces Kourier and gets you started with using it as a simpler, more lightweight way to expose Knative applications to an external network.

Let’s begin with a brief overview of Knative and Knative Serving.

Continue reading “Kourier: A lightweight Knative Serving ingress”

Share
Migrating a namespace-scoped Operator to a cluster-scoped Operator

Migrating a namespace-scoped Operator to a cluster-scoped Operator

Within the context of Kubernetes, a namespace allows dividing resources, policies, authorization, and a boundary for cluster objects. In this article, we cover two different types of Operators: namespace-scoped and cluster-scoped. We then walk through an example of how to migrate from one to the other, which illustrates the difference between the two.

Namespace-scoped and cluster-scoped

A namespace-scoped Operator is defined within the boundary of a namespace with the flexibility to handle upgrades without impacting others. It watches objects within that namespace and maintains Role and RoleBinding for role-based access control (RBAC) policies for accessing the resource.

Meanwhile, a cluster-scoped Operator promotes reusability and manages defined resources across the cluster. It watches all namespaces in a cluster and maintains ClusterRole and ClusterRoleBinding for RBAC policies for authorizing cluster objects. Two examples of cluster-scoped operators are istio-operator and cert-manager. The istio-operator can be deployed as a cluster-scoped to manage the service mesh for an entire cluster, while the cert-manager is used to issue certificates for an entire cluster.

These two types of Operators support both types of installation based on your requirements. In the case of a cluster-scoped Operator, upgrading the Operator version can impact resources managed by the Operator in the entire cluster, as compared to upgrading the namespace-scoped Operator, which will be easier to upgrade as it only affects the resource within its scope.

Continue reading “Migrating a namespace-scoped Operator to a cluster-scoped Operator”

Share
Introducing the Red Hat build of the OpenJDK Universal Base Images—now in Red Hat Enterprise Linux 8.2

Introducing the Red Hat build of the OpenJDK Universal Base Images—now in Red Hat Enterprise Linux 8.2

With the recent release of Red Hat Enterprise Linux 8.2, we also added the first Red Hat build of OpenJDK Universal Base Images. These General Availability (GA) images for OpenJDK 8 and OpenJDK 11 set a new baseline for anyone who wants to develop Java applications that run inside containers in a secure, stable, and tested manner.

In this article, we introduce the new OpenJDK Universal Base Images and explain their benefits for Java developers. Before we do that, let’s quickly review what we know about UBIs in general.

About Universal Base Images

Red Hat Universal Base Images (UBIs) are:

OCI-compliant container base operating system images with complementary runtime languages and packages that are freely redistributable. Like previous base images, they are built from portions of Red Hat Enterprise Linux (RHEL). UBI images can be obtained from the Red Hat container catalog and be built and deployed anywhere.

In other words, UBIs help application developers reach the secure, stable, and portable world of containers. These images are accessible using well-known tools like Podman/Buildah and Docker. Red Hat Universal Base Images also allow users to build and distribute their own applications on top of enterprise-quality bits that are supportable on Red Hat OpenShift and Red Hat Enterprise Linux.

Continue reading “Introducing the Red Hat build of the OpenJDK Universal Base Images—now in Red Hat Enterprise Linux 8.2”

Share
Debugging GraalVM-native images using gdb

Debugging GraalVM-native images using gdb

The GraalVM project includes, amongst other capabilities, a component called GraalVM Native Image. GraalVM Native Image supports the delivery of Java applications as shrink-wrapped, self-contained, standalone executables, commonly referred to as Java-native images. Native images often have a smaller footprint and faster startup time compared to running the same application in the traditional way on the JVM. This is often a win for short-running applications or small, container-based services. The trade-off is usually lower peak performance for long-running programs, and higher garbage collection overheads and latencies for programs with large amounts of resident data.

We are especially interested in GraalVM-native images as an alternative back-end delivery option for applications based on Quarkus. The Java team has worked hard to ensure that Quarkus is well integrated with GraalVM Native Images. In the process, they have found that one important usability issue is the ability to debug the delivered native image.

Continue reading “Debugging GraalVM-native images using gdb”

Share