We are pleased to announce the winners of the 2019 Red Hat EMEA Training Partner Awards. The awards were presented at the Red Hat EMEA Partner Conference, which took place from June 25-27, 2019 in Prague, Czech Republic.
In this blog post, originally posted on Ales Nosek – The Software Practitioner, I am going to talk about how I installed OpenShift 4.1 on a Fedora laptop with 16 GB of RAM. If you are interested in deploying your own OpenShift instance whether for evaluation or testing please follow along with me.
This article is the first in a series of three articles which share my experience with troubleshooting the performance of Vert.x applications. The first article, originally posted on Ales Nosek – The Software Practitioner, provides an overview of the Vert.x event loop model, the second article covers techniques to prevent delays on the event loop, and the third article focuses on troubleshooting of event loop delays.
Programming with Vert.x requires a good understanding of its event loop model. From what I saw in practice, delayed or blocked event loop threads are the number one contributor to performance problems with Vert.x applications. But don’t worry. In this article, we are going to review the event loop model.
The newly released Red Hat Certified Engineer (RHCE) exam (EX294) updated to Red Hat Enterprise Linux 8 allows candidates to demonstrate they have the skills to manage and configure multiple systems using state of the art automation tools. Including Red Hat Ansible Engine in this test came as a result of increasingly more IT organizations facing challenges related to scaling infrastructure and efficiently turning to Red Hat Ansible Automation as a common language to automate across different functions. As a result, system administrators need to understand more than how to deploy, configure, and manage an operating system—they need to know how to automate functions and how to make the automation itself scalable.
Disclaimer: the high-level architecture solution and the related demo code is an opinionated implementation to solve the problem described here. The author believes that DevOps is not about tools and frameworks, but a mindset and cultural change for teams. This is an implementation that aims to help a team on the DevOps journey of increasing shared understanding within traditional Development and Operation teams.
There are some challenges while adopting a PaaS Platform like OpenShift in an organization. Traditional IT teams have operated in silos where responsibilities for different parts of the Product lifecycle were distributed to different teams, for example, a development team and a release or production team. The teams’ domain of knowledge is, traditionally, limited to the activities they perform for their part of the chain of work and communication between these teams lacked flow or was done using ticketing systems that increase handoffs.
This post was originally published on the ETI blog here.
So – you want to stop your OpenShift cluster? There are many reasons why you may want to stop your OpenShift cluster. Maybe you have an annual disaster recovery test where you shut down a whole datacenter. Perhaps you want to do some maintenance to your infrastructure or the hypervisor or storage that your cluster is hosted on. It’s not an uncommon to need to be able to do this, so I have collated some of the best practices I have experienced across a multitude of environments, both large and small.
Here is the process that I recommend to use as a best practice in order to stop and start your OpenShift cluster(s). Following this process will give you the best chance of a trouble free maintenance window. As with all things, you should exercise care with this process on your important clusters. Try it on an unimportant environment first and see if it is a good fit for you.
Important: This process will cause an outage to any application workload running on the cluster until the cluster is fully started. The cluster itself will be unavailable until manually started. Care should be taken to run this process only on appropriate environments. It is recommended to have backups available of your environment.