In this article we start a new journey, automated infrastructure in the on-premise datacenter. We will deploy OpenShift 4.2 on OpenStack. As I am sure you are aware, OpenShift is Red Hat’s enterprise kubernetes platform. Kubernetes is of course the brains but by itself is not a platform. OpenShift brings with kubernetes, monitoring, aggregate logging, container registry, security, automated deployment/upgrade, developer experience, huge middleware tooling built around JBoss, serverless frameworks, ISTIO (service mesh), CI/CD integration and the key word “ENTERPRISE“.
In this article we will focus on installing and configuring OpenStack Stein 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 Stein 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 Stein 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.
In this article I will explain how to create your own custom RHEL 8 image for hetzner root servers. Hetzner offers new and used physical servers on a per/month basis (https://www.hetzner.de/sb). They offer extremely competitive pricing. These servers are perfect for demo or lab environments where you are operating your own platform and want it running 24/7!
Hetzner unfortunately does not offer RHEL images however, does provide a means for bringing your own image. A colleague of mine, Ingo Boernig, already shared a blog on how to do this for RHEL 7.5. This article with cover RHEL 8.0.
Over the last few years CI/CD (Continuous Integration/Continuous Deployment) thanks to new technologies has become a lot easier. It should no longer be a major thorn in the side of developers. Many are moving to cloud platforms which has CI/CD built-in (Azure DevOps for example), others are using Kubernetes which clearly reduces a lot of the complexity around CI/CD. Still at many organizations I see Jenkins or other complex and often homegrown tooling. I certainly recognize this tooling was needed but in 2019 there are better, more streamlined options. Now I get it, our butler Jenkins has served us well, for many years, he has become part of our family. But just like the famous Butler, Alfred from Batman, he has gotten old and likely it is time to look into retirement.
In this article we will discuss and demonstrate how to use Ansible Tower and GitHub for CI/CD.
Microsoft has wasted little time getting value out of their GitHub acquisition. They have now fully integrated GitHub and authentication into an already powerful DevOps platform called “Azure DevOps”. I have until this moment had zero enjoyment, setting up and maintaining CI/CD tooling usually involving some form of our dear butler, Jenkins. Nothing wrong with our old Jenkins but let’s face it, he is just overhead at this point, better to just put him to rest, he has earned it.
Azure DevOps has the following value:
It’s in the cloud, consumed as-a-service
Completely Integrated with GitHub
It is free
Authentication using GitHub user
Don’t need to use it with Azure
Supports basically every language, I am doing CI/CD with Go
Simple yaml to configure no Groovy/DML Jenkins horror
Yaml pipeline files auto-generated for your language (just needs minor tweaks)
Your code is built, unit tests are run, you can do acceptance tests and it is setup in a few minutes
Java has been around a really, really long time. Certainly it continues to evolve and has evolved. Java has always been a “can do anything” programming language. It has more frameworks and middleware than there are stars in the sky. It is portable anywhere and of course probably 8 out of 10 developers today know Java to some degree. Given all of this though is Java the path forward?
Looking forward I think the clear trend is microservices and beyond. Therefore the question is a lot simpler, is Java the best path forward for microservices?
Immediately after Solomon Hykes first showed Docker to the public at PyCon in 2013, in his now famous “docker run demo”, IT folk started asking, what does this mean for virtualization? We only spent the previous 10-15 years virtualizing, seemingly everything, so understandably people were slightly apprehensive. Industries had been built and careers established, clearly virtualization would be an important part of the future and not simply replaced, right?
In this article we will aim to understand the value of virtualization in a container-driven world, explore the current virtualization capabilities in Kubernetes and get started with Container Native Virtualization (Kubevirt) using Red Hat’s Kubernetes enterprise distribution, OpenShift.