For the past year and a half or so, Red Hat Middleware has provided a supported Node.js runtime on OpenShift as part of Red Hat OpenShift Application Runtimes (RHOAR). Our goal has been to provide rapid releases within a week or two of the upstream Node.js core project, booster applications to get developers up and running quickly, and, of course, provide world-class service and support for customers.
This past week at the DeveloperWeek 2019 conference in San Francisco, that focus and dedication paid off as Red Hat was awarded a “Devie” award in the category of “Code Frameworks and Libraries.” I couldn’t have been more thrilled to accept the award on behalf of our team.
Continue reading “Node.js for Red Hat OpenShift Application Runtimes wins a Devie award”
In this article, I’ll give you a quick tour of how to use the new MicroProfile Starter (Beta) site to generate, download, and build a Maven-based MicroProfile project with just a few clicks. Using this online project generator, you choose the MicroProfile version and server (such as Thorntail) that you want your project to be based on. Then you’ll be able to choose what example code to include in your project to see how to use the APIs that are part of the MicroProfile specifications such as Config, Health Check, Metrics, CDI, and more.
Continue reading “Jumpstart your microservices development with MicroProfile Starter (Beta)”
I was asked recently on Twitter to better explain Podman and Buildah for someone familiar with Docker. Though there are many blogs and tutorials out there, which I will list later, we in the community have not centralized an explanation of how Docker users move from Docker to Podman and Buildah. Also what role does Buildah play? Is Podman deficient in some way that we need both Podman and Buildah to replace Docker?
This article answers those questions and shows how to migrate to Podman.
Continue reading “Podman and Buildah for Docker users”
Red Hat CodeReady Workspaces provide developers with containerized development environments hosted on OpenShift/Kubernetes. DevOps teams can now use a hosted development environment that’s pre-built for their chosen stack and customized for their project.
CodeReady Workspaces can help you rapidly onboard developers for your project as everything they need to develop is running in a containerized workspace. In this post, we’re going to use CodeReady Workspaces to get up and running quickly with an existing open source project, Peak. Peak is a multi-container Kubernetes application for performance testing web services, and it allows you to create distributed performance tests using the Kubernetes Batch API for test orchestration. We’ll make some modifications to Peak’s Flask front end, a stateless web interface that interacts with a Falcon RESTful API to return data about performance tests. You won’t need the complete Peak application deployed, though if you like, you can find steps to deploy it to OpenShift here.
To follow along you’ll need a Red Hat OpenShift Container Platform 3.11 environment. You can use the Red Hat Container Development Kit on your Windows, macOS, or Linux laptop or a hosted Red Hat OpenShift instance to do it on online.
Continue reading “Creating a containerized Python/Flask development environment with Red Hat CodeReady Workspaces”
The ISO C++ standards meeting in November 2018 was held in San Diego, CA. As usual, Red Hat sent three of us to the meeting: me (for the Core Language Working Group), Jonathan Wakely (for the Library Working Group [LEWG]), and Thomas Rodgers (for the Concurrency and Parallelism Study Group [SG1]). I felt the meeting was productive, though some features that had been expected to make it into C++20 are now in question.
Here are new C++ features accepted at the meeting:
Continue reading “November 2018 ISO C++ meeting trip report (Core Language)”
This is the second half of my series covering how to use Red Hat CodeReady Workspaces to develop a Java Enterprise Edition (now Jakarta EE) application using Red Hat JBoss Enterprise Application Platform (JBoss EAP) in the cloud on Red Hat OpenShift/Kubernetes. In the first part, we saw how to:
- Bring your own tools by extending Red Hat’s provided stacks
- Register your own stack within Red Hat CodeReady Workspaces
- Create your workspace using your stack and embedding your JEE project located on a Git repository
For this second part, we’ll start configuring the workspace by adding some helpful settings and commands for building and running a JBoss EAP project. We’ll then see how to use the local JBoss EAP instance for deploying and debugging our application. Finally, we’ll create a factory so that we’ll be able to share our work and propose an on-demand configured development environment for anyone that needs to collaborate on our project.
Continue reading “Streamline your JBoss EAP dev environment with Red Hat CodeReady Workspaces: Part 2”
Developing Apache Camel and Red Hat Fuse applications inside VS Code is improving! In my previous articles, I’ve mentioned that Camel URI completion is available in VS Code for XML and Java DSL. By leveraging several VS Code extensions, it is now possible to have an end-to-end development experience. The Camel tooling currently available in VS Code is primarily targeting Spring Boot– based Camel applications. The tooling covers the development process from creating a Camel project, testing, and debugging it locally, to automatically-rebuilding and redeploying it on your local OpenShift/Kubernetes instance when you make changes.
There are several ways to leverage the VS Code tooling. I will show the process which I believe is the easiest one to get started with.
Continue reading “Using VS Code to develop Spring Boot-based Camel and Red Hat Fuse projects”
Recently the Eclipse Che community has been working to make Eclipse Theia the default web IDE for Eclipse Che 7. We’ve added a plugin model to Eclipse Theia that is compatible with Visual Studio Code (VS Code) extensions. Che 7 users will eventually be able to take advantage of extensions that have been written for VS Code in their cloud-based developer workspaces. It’s worth pointing out the popularity of VS Code extensions. Red Hat has contributed extensions covering Java, XML, YAML, OpenShift, and dependency analytics. The Java extension provided by Red Hat has been downloaded over 10 million times!
If you aren’t familiar with Eclipse Theia, Che 6 and earlier used a GWT-based IDE. While it is possible to develop and use plugins in that environment, it is cumbersome. Coming from tools like VS Code, developers expect to be able to customize and extend their workspaces at runtime. Eclipse Theia is an extensible open-source framework to develop multi-language IDEs using state-of-the-art web technologies. Moving to Theia as the default IDE for Che 7 provides a foundation to enrich the developer workspaces in Che. See the series of articles by Stevan LeMeur for more information about what’s coming in Che 7.
This article explains why we decided to add the new plugin model to Eclipse Theia and the benefits for Eclipse Che 7 developer workspaces. I also cover how the new plugin model differs from the existing Theia extension model.
Continue reading “Extending Eclipse Che 7 to use VS Code extensions”
It has been just one month since the announcement of the release of Red Hat CodeReady Workspaces 1.0.0 Beta. Because the cloud/browser-based IDE may be full of promises, developers are usually suspicious, considering them as toys for occasional coders but not suitable for software craftsmen. But you’ll quickly see that Red Hat’s offering can be a good companion for building tailor-made environments.
The goal of this two-part series is to give a walk-through of using Red Hat CodeReady Workspaces to develop a Java EE (now Jakarta EE) application using Red Hat JBoss Enterprise Application Platform (JBoss EAP). I’ll give you details on how to bring your own tools, configure your workspace with helpful commands for JBoss EAP, and share everything so you can easily onboard new developers.
Continue reading “Streamline your JBoss EAP dev environment with Red Hat CodeReady Workspaces: Part 1”
People associate running pods with Kubernetes. And when they run containers in their development runtimes, they do not even think about the role pods could play—even in a localized runtime. Most people coming from the Docker world of running single containers do not envision the concept of running pods. There are several good reasons to consider using pods locally, other than using pods to naturally group your containers.
For example, suppose you have multiple containers that require the use of a MariaDB container. But you would prefer to not bind that database to a routable network; either in your bridge or further. Using a pod, you could bind to the
localhost address of the pod and all containers in that pod will be able to connect to it because of the shared network name space.
Continue reading “Podman: Managing pods and containers in a local container runtime”