With nowadays virtualization technologies, low latency communications, CPU Power and The Cloud, the Infrastructure paradigm is being changed from the static old-fashion way of managing servers to a new standard automation way of deploying services.
Continue reading “Documentation as Code”
So, you’ve been told you need to build a Redis Server Cluster. First, if you don’t know what Redis is you are probably thinking, “What is this weird named thing and what do I need to do”. This guide will walk you through both in a way that will hopefully be easy to follow and be easy to repeat in the future.
While you can have more than three servers in a Redis cluster for the sake of simplicity, we will cover setting up a three server Redis cluster. In our three servers cluster, we will have two Redis servers with one Redis Sentinel with HAProxy to assist the Sentinel.
Much of this guide will work with a tested code stored in GitLab (https://gitlab.com/Kittell-Projects/RedHat/Redis) to make it easier to build the cluster. While this code is tested, it is suggested to build in a development environment first.
Continue reading “How To Setup A Redis Server Cluster on Red Hat”
When looking for installation instructions of Ansible under RHEL, I have always have found two ways:
- With epel-release (Which I don’t like just because I want to keep my system clean).
- From source code (Which I don’t like either for the same reason).
Continue reading “Managing Windows Updates with Ansible in Red Hat Enterprise Linux”
The content of the previous post discussed creating the open-vm-tools container’s Dockerfile and automating its started up via systemd with a unit file.
Continue reading “Containerizing open-vm-tools – Part 2: Atomic CLI and Converting to a Systems Container”
This year in Boston, MA you can attend the Red Hat Summit 2017, the event to get your updates on open source technologies and meet with all the experts you follow throughout the year.
It’s taking place from May 2-4 and is full of interesting sessions, keynotes, and labs.
This year I was part of the process of selecting the labs you are going to experience at Red Hat Summit and wanted to share them to help you plan your cloud and containers labs experience. These labs are for you to spend time with the experts who will teach you hands-on and how to get the most out of development with containers and in the Cloud using products like OpenShift Container Platform.
Each lab is a 2-hour session, so planning is essential to getting the most out of your days at Red Hat Summit.
As you might be struggling to find and plan your sessions together with some lab time, here is an overview of the labs, you can find the exact room and times in the session catalog. Each entry includes the lab number, title, abstract, instructors, and is linked to the session catalog entry:
Continue reading “Red Hat Summit 2017 – Planning your Cloud and Containers Labs”
While validating OpenShift Container Platform on a VMware platform the usage of Atomic OS was also a requirement. In the initial reference architecture, the decision was made to use Red Hat Enterprise Linux as the platform. This platform was then customized and the same packages as in Atomic were installed via Ansible and Red Hat Network.
Continue reading “Containerizing open-vm-tools – Part 1: The Dockerfile and constructing a systemd unit file”
The world is moving to microservices, where applications are composed of a complex topology of components, orchestrated into a coordinated topology.
Microservices have become increasingly popular as they increase business agility and reduce the time for changes to be made. On top of this, containers make it easier for organizations to adopt microservices.
Increasingly, containers are the runtimes used for composition, and many excellent solutions have been developed to handle container orchestration such as: Kubernetes/OpenShift; Mesos and its many frameworks like Marathon; and even Docker Compose, Swarm and SwarmKit are trying to address these issues.
But at what cost?
We’ve all experienced that moment when we’ve been working long hours and think “yes, that feature is ready to ship”. We release it into our staging environment and bang, nothing works, and we don’t really know why. What if you could consistently take the same topology you ran in your development workspace, and run it in other, enterprise grade, environments such as your staging or production, and expect it to always JUST WORK?
Continue reading “Container Orchestration Specification for better DevOps”