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”
Today I want to talk about the demo we presented @ OpenShift Container Platform Roadshow in Milan & Rome last week.
The demo was based on JBoss team’s great work available on this repo:
Continue reading “OpenShift and DevOps: The CoolStore Microservices Example”
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”