In a previous article, I showed how easy it was to deploy a Node.js application during development to Red Hat OpenShift using the Nodeshift command-line interface (CLI). In this article, we will take a look at using Nodeshift to deploy Node.js applications to vanilla Kubernetes—specifically, with Minikube.
Continue reading Deploying Node.js applications to Kubernetes with Nodeshift and Minikube
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”
Containers are the new way of deploying applications. They provide an efficient mechanism to deploy self-contained applications in a portable way across clouds and OS distributions. In this blog post we’ll look at what OpenShift brings for .NET Core specifically.
Kubernetes and OpenShift
Kubernetes is the de facto orchestrator for managing containerized applications. Google open-sourced Kubernetes in 2014 and Red Hat was one of the first companies to work with Google on Kubernetes. Red Hat is the 2nd leading contributor to the Kubernetes upstream project.
OpenShift is an open-source DevOps platform that is built on top of Kubernetes. It integrates directly with your application’s source code. This enables continuous integration/continuous deployment (CI/CD) workflows. Tools are available to scale and monitor your applications. The OpenShift Catalog makes it easy to setup middleware and databases. OpenShift comes with comprehensive documentation to install and manage your installation. It can run on-prem and on public clouds such as AWS, GCP and Azure.
Continue reading “Using OpenShift to deploy .NET Core applications”
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”
Building a docker formatted container image for a Node.js application
There are 2 main strategies for building an image for a Node.js Application. The most common strategy is simply using a
Dockerfile with a base image of something like
FROM node:4-onbuild. Then do a
docker build. This will produce an image with your application in it, ready to be run. This strategy is known as the
Docker strategy in an OpenShift BuildConfig.
Another strategy is using the
s2i tool for taking the application source from a repository and producing the image. A typical command would be.
s2i build firstname.lastname@example.org/me/myrepo.git bucharestgold/centos7-s2i-nodejs:latest myapp. With this strategy, there is no explicit
Dockerfile. It is known as the
Source strategy in an OpenShift BuildConfig.
Continue reading “Installing Node.js dependencies with Yarn via s2i builds and OpenShift”