On April 23, Node.js released its latest major version with Node.js 12. Because this is an even-numbered release, it will become a Long Term Support (LTS) release in October, code-named Erbium.
This release brings a host of improvements and features, which this blog post isn’t going to cover. Instead, I will focus on how to start using this new release today on Red Hat OpenShift. If you’re interested in more about the various improvements and new features, check out the articles listed at the end of this post.
Continue reading “Use Node.js 12 on Red Hat OpenShift today”
Welcome back to the final part of this multipart series about deploying modern web applications on Red Hat OpenShift. In the first post, we took a look at how to deploy a modern web application using the fewest commands.
In the second part, we took a deeper look into how the new source-to-image (S2I) web app builder works and how to use it as part of a chained build.
This third and final part will take a look at how you can run your app’s “development workflow” on OpenShift.
Continue reading “Modern web applications on OpenShift: Part 3 — Openshift as a development environment”
How do YOU get your Java apps running in a cloud?
First you grab a cloud from the sky by, for example, (1) Getting started with a free account on Red Hat OpenShift Online, or (2) locally on your laptop using Red Hat Container Development Kit (CDK) or upstream Minishift on Windows, macOS, and Linux, or (3) using
oc cluster up (only on Linux), or (4) by obtaining a login from someone running Red Hat OpenShift on a public or on-premises cloud. Then, you download the oc CLI client tool probably for Windows (and put it on your PATH). Then you select the Copy Login Command from the menu in the upper right corner under your name in the OpenShift Console’s UI, and you use, for example, the
oc status command.
Great—now you just need to containerize your Java app. You could, of course, start to write your own Dockerfile, pick an appropriate container base image (and discuss Red Hat Enterprise Linux versus CentOS versus Fedora versus Ubuntu versus Debian versus Alpine with your co-workers; and, especially if you’re in an enterprise environment, figure out how to have that supported in production), figure out appropriate JVM startup parameters for a container, add monitoring, and so.
But perhaps what you really wanted to do today is…well, just get your Java app running in a cloud!
Read on to find an easier way.
Continue reading “Building Java 11 and Gradle containers for OpenShift”
Red Hat OpenShift implements .NET Core support via a source-to-image (S2I) builder. In this article, we’ll take a closer look at how you can use that builder directly. Using S2I, you can build .NET Core application images without having to write custom build scripts or Dockerfiles. This can be useful on your development machine or as part of a CI/CD pipeline.
Continue reading “Building .NET Core container images using S2I”
In the previous article, we took a quick look at a new source-to-image (S2I) builder image designed for building and deploying modern web applications on OpenShift. While the last article was focused on getting your app deployed quickly, this article will look at how to use the S2I image as a “pure” builder image and combine it with an OpenShift chained build.
Continue reading “Modern web applications on OpenShift: Part 2 — Using chained builds”
In this multi-part series, we will take a look at how to deploy modern web applications, like React and Angular apps, to Red Hat OpenShift using a new source-to-image (S2I) builder image.
Continue reading “Modern web applications on OpenShift: Part 1 — Web apps in two commands”
Red Hat OpenShift supports two workflows for building container images for applications: the source and the binary workflows. The binary workflow is the primary focus of the Red Hat OpenShift Application Runtimes and Red Hat Fuse product documentation and training, while the source workflow is the focus of most of the Red Hat OpenShift Container Platform product documentation and training. All of the standard OpenShift Quick Application Templates are based on the source workflow.
A developer might ask, “Can I use both workflows on the same project?” or, “Is there a reason to prefer one workflow over the other?” As a member of the team that developed Red Hat certification training for OpenShift and Red Hat Fuse, I had these questions myself and I hope that this article helps you find your own answers to these questions.
Continue reading “Source versus binary S2I workflows with Red Hat OpenShift Application Runtimes”
Container images usually come with pre-defined tools or services with minimal or limited possibilities of further configuration. This brought us into a way of thinking of how to provide images that contain reasonable default settings but are, at the same time, easy to extend. And to make it more fun, this would be possible to achieve both on a single Linux host and in an orchestrated OpenShift environment.
Source-to-image (S2I) has been introduced three years ago to allow developers to build containerized applications by simply providing source code as an input. So why couldn’t we use it to make configuration files as an input instead? We can, of course!
Continue reading “Flexible Images or Using S2I for Image Configuration”
I like Node.js and I like Docker. While I am not an expert on either, I do pretend to be one at work.
Lately, I’ve been looking at Openshift CDK and how I can develop Node.js apps against it. Specifically, I was looking at the MSA Hello World Demo and the Bonjour microservice.
I also recently wrote about setting up a CDK environment on a freshly re-installed MacBook Pro. I would check it out; it’s some good writing.
My initial goal was to figure out how to “containerize” a Node.js application and then put it on my local openshift VM, but when I started to look at it little deeper, I found a few different ways of doing it. Hopefully, this post will go into the different ways.
Continue reading “Node, S2I and Docker”