Ansible Tower Cluster Configuration Guide

Ansible-Tower-Logotype-Large-RGB-FullGrey-300x124_0

Overview

In this article we will setup and configure an Ansible Tower cluster on Red Hat Enterprise Linux (RHEL). If you are interested in a single all-in-one deployment, I have already documented this here.

Ansible Tower clustering replaces the traditional active/passive with an active/active configuration. It provides not only HA but scalability as well. Ansible Tower has two critical components: Tower instances running API/Scheduler and the database. RabbitMQ is used for communication between the Tower instances.

Continue reading

Ansible Getting Started Guide

ansible-logo

Overview

Automation is one of the most critical areas of improvement in most organizations. Today, most companies are in the process or re-inventing themselves in one way or another to add software development capabilities and as such, take full advantage of the digitalization of everything. Software development release cycles are changing in order to release faster. Continuous delivery, where every change is potentially it’s own release is becoming the new standard. Infrastructure is following suit, after all, continuous delivery is not about just software changes but all changes and infrastructure plays a key roll. For any of this to work of course, 100% automation is required. To achieve that goal, an automation language that is easy and applicable to development and operations is needed. Ansible is that language and if you are not on-board yet, now is your chance not to miss the train because it is leaving the station. Ansible is easy, Ansible is powerful and Ansible is flexible. This guide will show that and get you up and running with Ansible before your coffee gets cold.

Continue reading

OpenShift: Accessing External Services using Egress Router

openshift-logotype-svg

Overview

Egress traffic is traffic going from OpenShift pods to external systems, outside of OpenShift. There are two main options for enabling egress traffic. Allow access to external systems from OpenShift physical node IPs or use egress router. In enterprise environments egress routers are often preferred. They allow granular access from a specific pod, group of pods or project to an external system or service. Access via node IP means all pods running on a given node can access external systems.

Continue reading

OpenStack 11 (Ocata) Lab Installation and Configuration Guide

rdo

Overview

In this article we will focus on installing and configuring OpenStack Ocata using RDO and the packstack installer. RDO is a community platform around Red Hat’s OpenStack Platform. 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 installing the OpenStack Liberty release, configuring networking, security groups, flavors, images and are other OpenStack related services. The outcome is a working OpenStack environment based on the Ocata release that you can use as a baseline for testing your applications with OpenStack capabilities.

Continue reading

OpenShift 3.6 Fast Track: Everything You Need, Nothing You Don’t

Logotype_RH_OpenShiftContainerPlatform_wLogo_CMYK_Black

Overview

OpenShift Container Platform 3.6 went GA on August 9, 2017. You can read more about the release and new features here. In this article we will setup a standard non-HA environment that is perfect for PoCs or labs. Before we begin, let’s explain OpenShift for those that may be starting their OpenShift journey today. OpenShift is a complete container application build + run-time platform built on Kubernetes (Container Orchestration) and Docker (Container Packaging Format). Organizations looking to adopt containerization for their applications need of course a lot more than just technology, (Kubernetes and Docker), they need a real platform. OpenShift provides a service catalog for containerized applications, huge selection of already certified application runtimes + xPaaS services, a method for building containerized applications (source to image), centralized application logging, metrics, autoscaling, application deployments (Blue-Green, A/B, Canary, Rolling), integrated Jenkins CI/CD pipelines, integrated docker registry, load balancing / routes to containerized apps, multi-tenant SDN, security features (SELinux, secrets, security context), management tooling supporting multiple OpenShift environments (CloudForms), persistent storage (built-in Container Native Storage), automated deployment tooling based on Ansible and much, much more. OpenShift is a platform that runs on any infrastructure, from bare-metal to virtualization to public cloud (Amazon, Google, Microsoft), providing portability across cloud infrastructure for containerized applications. All of these things together is what truly enables organizations to move to DevOps, increase application release cycles, speed up innovation cycles, scale efficiently, gain independence from infrastructure providers and deliver new capabilities faster with more reliability to their customers.

Continue reading

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

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

OpenShift Showback Reporting using CloudForms

openshift_logo plus_sign  cf_logo

Overview

One of the most important capabilities of any platform in today’s service driven, pay-as-you-go economy is metering and showback. Without a solid understanding of costs, organizations are in fact unable to provide services. With containers, metering and showback becomes more challenging. If we think about containers simply being processes, then we are basically needing to meter and perform showback at that level of granularity. In addition since OpenShift uses Kubernetes for container orchestration, there are additional concepts that are new. For example, one more more containers run together in what Kubernetes refers to as a Pod. Next Pods are extremely dynamic and their lifetime very short. All of this make metering and showback anything but straight-forward. Thankfully OpenShift and CloudForms have the solution.

Continue reading