Have you ever wanted to set up continuous integration (CI) for .NET Core in a cloud-native way, but you didn’t know where to start? This article provides an overview, examples, and suggestions for developers who want to get started setting up a functioning cloud-native CI system for .NET Core.
We will use the new Red Hat OpenShift Pipelines feature to implement .NET Core CI. OpenShift Pipelines are based on the open source Tekton project. OpenShift Pipelines provide a cloud-native way to define a pipeline to build, test, deploy, and roll out your applications in a continuous integration workflow.
In this article, you will learn how to:
- Set up a simple .NET Core application.
- Install OpenShift Pipelines on Red Hat OpenShift.
- Create a simple pipeline manually.
- Create a Source-to-Image (S2I)-based pipeline.
Continue reading “Set up continuous integration for .NET Core with OpenShift Pipelines”
Red Hat OpenShift Serverless recently became GA, and with it came new options for application deployment. This article introduces one of those new options, Knative Serving. I provide an overview of OpenShift Serverless and Knative Serving, then show you how to deploy a Node.js application as a Knative Serving service.
What is OpenShift Serverless?
According to the OpenShift Serverless GA release:
OpenShift Serverless enables developers to build what they want, when they want, with whatever tools and languages they need. Developers can quickly get their applications up and deployed using serverless compute, and they won’t have to build and maintain larger container images to do so.
OpenShift Serverless is based on the Knative open source Kubernetes serverless project. While it has a few different parts, we will focus on deploying a serverless Node.js application as a Knative Serving service.
Continue reading “Deploying serverless Node.js applications on Red Hat OpenShift, Part 1”
Red Hat Marketplace is an online store of sorts, where you can choose the software that you want to install and run on your Red Hat OpenShift cluster. The analogy is a phone app store, where you select an app, and it’s automagically installed on your phone. With Marketplace, you simply register your cluster(s), select the software that you want, and it is installed for you. It could not be easier.
In this article, I show you how to install Couchbase Server Enterprise Edition on an OpenShift cluster. In my case, the cluster is running on Fedora 32 using Red Hat CodeReady Containers (CRC). Couchbase Server Enterprise Edition is currently available as a free trial, and CRC is also available at zero cost. This setup offers a no-risk way to try containers, Kubernetes, OpenShift, and, in this case, Couchbase. This is definitely “developers playing around with the software”-level stuff.
Continue reading “How to install the CouchbaseDB Operator for Red Hat OpenShift on your laptop using Red Hat CodeReady Containers and Red Hat Marketplace”
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”
JBoss Tools 4.14.0 and Red Hat CodeReady Studio 12.14 for Eclipse 4.14 (2019-12) are here and waiting for you. For this release, we focused on improving container-based development, adding tooling for the Quarkus framework, and fixing bugs. We also updated the Hibernate Tools runtime provider and Java Developer Tools (JDT) extensions, which are now compatible with Java 13. Additionally, we made many UI changes to platform views, dialogs, and toolbars.
Continue reading Red Hat CodeReady Studio 12.14.0.GA and JBoss Tools 4.14.0.Final: OpenShift and Quarkus updates
As part of the Open Data Hub project, we see potential and value in the Kubeflow project, so we dedicated our efforts to enable Kubeflow on Red Hat OpenShift. We decided to use Kubeflow 0.7 as that was the latest released version at the time this work began. The work included adding new installation scripts that provide all of the necessary changes such as permissions for service accounts to run on OpenShift.
Continue reading Installing Kubeflow v0.7 on OpenShift 4.2
In this article, we will see a similar pattern when writing the REST API in any known framework vs. writing an Operator using Kubernetes’ client libraries. The idea behind this article is not to explain how to write a REST API, but instead to explain the internals of Kubernetes by working with an analogy.
To follow along, you will need the following installed:
As a developer, if you have used the REST API with frameworks like Quarkus/Spring (Java), Express (Nodejs), Ruby on Rails, Flask (Python), Golang (mux), etc., understanding and writing an operator will be easier for you. We will use this experience with other languages or frameworks to build our understanding.
Continue reading “Operator pattern: REST API for Kubernetes and Red Hat OpenShift”
A previous article, Debugging applications within Red Hat OpenShift containers, gives an overview of tools for debugging applications within Red Hat OpenShift containers, and existing restrictions on their use. One of the restrictions discussed in that article was an inability to install debugging tool packages into an ordinary, unprivileged container once it was already instantiated. In such a container, debugging tool packages have to be included when the container image is built, because once the container is instantiated, using package installation commands requires elevated privileges that are not available to the ordinary container user.
However, there are important situations where it is desirable to install a debugging tool into an already-instantiated container. In particular, if the resolution of a problem requires access to the temporary state of a long-running containerized application, the usual method of adding debugging tools to the container by rebuilding the container image and restarting the application will destroy that temporary state.
To provide a way to add debugging tools to unprivileged containers, I developed a utility, called
oc-inject, that can temporarily copy a debugging tool into a container. Instead of relying on package management or other privileged operations,
oc-inject’s implementation is based on the existing and well-supported OpenShift operations
oc rsync and
oc exec, which do not require any elevated privileges.
This article describes the current capabilities of the
oc-inject utility, which is available on GitHub or via a Fedora COPR repository. The
oc-inject utility works on any Linux system that includes Python 3, the
ldd utility, and the Red Hat OpenShift command-line tool
Continue reading “Installing debugging tools into a Red Hat OpenShift container with oc-inject”