Linux

It’s a PaaS: Vanilla Kubernetes vs OpenShift on OpenStack Lab Setup Guide

Posted by

0

Kubernetes-logo is_not_4 OpenShift-LogoType.svg

Overview

Often a lot of people seem to confuse Kubernetes with OpenShift or a platform-as-a-service (PaaS). Kubernetes is of course on it’s own, not. It is an orchestration layer or technology for containers but a lot is missing to really call it a platform. OpenShift is Red Hat enterprise Kubernetes platform. It contains Kubernetes but also a whole lot more which make it a true platform. So which is right for you? It depends a lot on your requirements and what you are trying to achieve. The purpose of this article is to setup an environment for running a workshop that compares the Kubernetes experience with OpenShift in order to gain more insight and understanding in what you may actually need. Many people sit down with slides or at a whiteboard, but I really find that is not adequate and you really need to experience it, first hand.

Continue reading →

OpenStack 14 (Rocky) Lab Installation and Configuration Guide for Hetzner Root Servers

Posted by

0

rdo

Overview

In this article we will focus on installing and configuring OpenStack Rocky using RDO and the packstack installer. RDO is a community platform around Red Hat’s Enterprise OpenStack Distribution. It allows you to test the latest OpenStack capabilities on a stable platform such as Red Hat Enterprise Linux (RHEL) or CentOS. This guide will take you through setting up Hetzner root server, preparing environment for OpenStack, installing the OpenStack Rocky release, adding a floating ip subnet through OVS, configuring networking, security groups, flavors, images and are other OpenStack related services. The outcome is a working OpenStack environment based on the Rocky release that you can use as a baseline for testing your applications using OpenStack capabilities. The installation will create an all-in-one deployment however you can use this guide to create a multi-node deployment as well.
Continue reading →

OpenStack 13 (Queens) Lab Installation and Configuration Guide for Hetzner Root Servers

Posted by

2

rdo

Overview

In this article we will focus on installing and configuring OpenStack Queens using RDO and the packstack installer. RDO is a community platform around Red Hat’s Enterprise OpenStack Distribution. It allows you to test the latest OpenStack capabilities on a stable platform such as Red Hat Enterprise Linux (RHEL) or CentOS. This guide will take you through setting up Hetzner root server, preparing environment for OpenStack, installing the OpenStack Queens release, adding a floating ip subnet through OVS, configuring networking, security groups, flavors, images and are other OpenStack related services. The outcome is a working OpenStack environment based on the Queens release that you can use as a baseline for testing your applications using OpenStack capabilities. The installation will create an all-in-one deployment however you can use this guide to create a multi-node deployment as well.
Continue reading →

OpenStack 12 (Pike) Lab Installation and Configuration Guide with Hetzner Root Servers

Posted by

0

rdo

Overview

In this article we will focus on installing and configuring OpenStack Pike using RDO and the packstack installer. RDO is a community platform around Red Hat’s Enterprise OpenStack Distribution. It allows you to test the latest OpenStack capabilities on a stable platform such as Red Hat Enterprise Linux (RHEL) or CentOS. This guide will take you through setting up Hetzner root server, preparing environment for OpenStack, installing the OpenStack Pike release, adding a floating ip subnet through OVS, configuring networking, security groups, flavors, images and are other OpenStack related services. The outcome is a working OpenStack environment based on the Pike release that you can use as a baseline for testing your applications using OpenStack capabilities. The installation will create an all-in-one deployment however you can use this guide to create a multi-node deployment as well.
Continue reading →

Containers in Large IT Enterprises

Posted by

0

thinkstockphotos-464267243-100668861-large

Overview

As this will be the last article of 2017 I wanted to do something different and get away from my typical how-to guides (rest assured I will continue doing them in 2018). Over the past year, I have engaged in a lot of conversation with many large organizations looking to adopt or increase their container footprint. In this article I will share my thoughts on what I have learned from those discussions. We will discuss the impact of containers in large IT organizations. Understand the difference between container technology and container platform. Look into the integration points a container platform has into the existing IT landscape and finally discuss high-level architectural design ideas.

This article should serve as a good starting point for IT organizations trying to understand how to go about adopting container technology in their organization.

Continue reading →

Keep Your Servers and Run Your Applications Forever with Red Hat Virtualization powered by KVM

Posted by

2

KVM-tuchaplus_signWindow4NTserver

Overview

This article was written by myself and fellow colleague Götz Rieger. Often one of the most challenging problems we are facing today is both absorbing and leading change. Software defined-everything has taken over and is leveling the playing field, de-marginalizing staunch competitive advantages and nothing is safe anymore. Develop great applications and thrive or become irrelevant is the mantra facing many organizations. In such environments it is important to innovate constantly, delivering new capabilities at an ever increasing speed. In order to do so, new practices (DevOps), values (Agile) and of course technology (Containers) are being implemented.

Today it seems almost everyone is focused on “the new” software-defined whatever, when in reality change happens at different levels and different speeds. Gartner tried to summarize this with “mode 1 vs mode 2” but that trivializes things too far. It comes down to application lifecycles which dictates dependency on change.  What if certain software doesn’t need to change? What if it has a purpose and is already doing it’s job function? What if the software cannot be ported to a new operating platform? What do you do then? The answer surprisingly, is maybe nothing? Maybe we let those applications live well beyond their intended support lifecycles. Consider the old programs in the Matrix, some found a way to survive and were not killed. These were also some of the most important, powerful programs.

Virtualization has enabled us to let x86 platforms essentially run forever or at least well beyond their support lifecycles (hardware and software). If we consider outdated Cobol applications on UNIX or Windows platforms like NT, XP and 2003; they haven’t been supported for years. Applications running on these platforms might are not able to migrate for whatever reason, else they would have already done so. If we think about it, this is in fact a very valid use case for virtualization. There are of course other considerations that are important, like isolation (since these applications are not receiving patches) but assuming that is handled, why not? If it ain’t broken and doesn’t need to change, why fix it?

In this article we will look at how to run Windows NT Server (an operating system that hasn’t been supported since 2004) on KVM and Red Hat Virtualization powered by KVM.

Continue reading →

Explaining OpenStack Cinder Types and Scheduler

Posted by

0

openstack-logo-2016

Overview

OpenStack Cinder is responsible for handling block storage in the context of OpenStack. Cinder provides a standard API and interface that allows storage companies to create their own drivers in order to integrate storage capabilities into OpenStack in a consistent way. Each storage pool exposed to OpenStack Cinder is a backend and you can have many storage backends. You can also have many of the same kind of storage backends. In this article we will look at two advanced features Cinder provides: types and the scheduler.

Cinder types essentially allow us to label Cinder storage backends. This allows for building out storage services that have expected characteristics and capabilities. The Cinder driver exposes those storage capabilities to Cinder.

The Cinder scheduler is responsible for deciding where to create Cinder volumes when we have more than one of the same kind of storage backend. This is done by looking at the filter rules in order to identify the most appropriate storage backend. More about filter rules can be found here.

Continue reading →