Author Archives: Roger Lopez
Author Archives: Roger Lopez
As Red Hat Ansible Automation Platform enables teams and organizations to drive their automation from across the cloud and on-premise, keeping Ansible Automation Platform healthy with the ability to monitor key metrics becomes paramount.
This blog post demonstrates how to monitor the API metrics provided by an Ansible Automation Platform environment when deployed within Red Hat OpenShift.
Prometheus is an open source monitoring solution for collecting and aggregating metrics. Partner Prometheus’ monitoring capabilities with Grafana, an open source solution for running data analytics and pulling up metrics in customizable dashboards, and you get a real-time visualization of metrics to track the status and health of your Ansible Automation Platform.
Expect to be fast-tracked to a deployment of Ansible Automation Platform that is monitored by Prometheus paired with a Grafana Ansible Automation Platform dashboard showing those metrics in real time.
This blog will guide you through:
When managing infrastructure, there are times when a dynamic inventory is essential. Kubernetes is a perfect example of this where you may create multiple applications within a namespace but you will not be able to create a static inventory due to Kubernetes appending a systems-generated string to uniquely identify objects.
Recently, I decided to play with using a Kubernetes dynamic inventory to manage pods, but finding the details on how to use and apply it was a bit scarce. As such, I wanted to write a quick start guide on how you can create an Ansible Playbook to retrieve your pods within a namespace and generate a Kubernetes dynamic inventory.
This is much easier to do when you take advantage of the kubernetes.core.k8s_info module.
In my example, I’m going to take advantage of using my existing ansible-automation-platform namespace that has a list of pods to create my dynamic inventory. In your scenario, you’d apply this to any namespace you wish to capture a pod inventory from.
When creating your inventory, the first step is to register the pods found within a particular namespace. Here’s an example of a task creating an inventory within the ansible-automation-platform Continue reading
One of the great advantages of combining GitOps with Ansible is that you get to streamline the automation delivery and the lifecycle of a containerized application.
With the abilities of GitOps we get to:
Combine the above with Ansible and you have everything you need to accomplish configuration consistency for a containerized app anywhere that you automate.
That leads us to, “how do we combine Ansible and GitOps to manage the lifecycle of a containerized application?”
Simple. By creating an Ansible workflow that is associated with a Git webhook that is part of my application’s repository.
What is a Git webhook you ask?
Git webhooks are defined as a method to deliver notifications to an external web server whenever certain actions occur on a repository.
For example, when a repository is updated, this could trigger an event that could trigger CI builds, deploy an environment, or in our case, modify the configuration of our containerized application.
A webhook provides the ability to execute specified Continue reading
With increased adoption of container automation, IT organizations continue to expand their requirements when it comes to deploying and managing their Kubernetes clusters. As such, we at Red Hat continue to add new features and capabilities to meet those demands by announcing the availability of kubernetes.core version 2.3, our Red Hat Ansible Certified Content Collection for Kubernetes and Helm.
In this blog post, we’ll go over what’s new and what’s different in this release of our Kubernetes Collection.
With the release of kubernetes.core 2.3, we introduce the k8s_taint module. This module provides the ability for a Kuberentes node to repel a pod or set of pods from being scheduled unless they have a matching toleration. This establishes that with taints and tolerations in place, pods are not scheduled onto inappropriate nodes.
This feature is quite useful when you are trying to ensure exclusivity of a particular set of nodes (only allow a particular group of users access) or you want to provide particular nodes with special hardware (such as GPUs) to only run pods that require the use of the specialized hardware and keep out the pods that don’t require Continue reading
With the release of Red Hat Ansible Automation Platform 2.1, we are proud to deliver the latest reference architecture on the best practices for deploying a highly available Ansible Automation Platform environment.Why are you going to love it?
This reference architecture focuses on providing a step-by-step deployment procedure to install and configure a highly available Ansible Automation Platform environment from start to finish.
But there’s more!
Aside from the key steps to install Ansible Automation Platform, it incorporates key building blocks to optimize your Ansible Automation Platform environments, including:
The reference architecture consists of two environments of Ansible Automation Platform: Ansible Site 1 and Ansible Site 2 for high availability. Site 1 is an active environment while Site 2 is a passive environment. Each site consists of the following:
Pre-plan your automation savings with Red Hat Insights for Red Hat Ansible Automation Platform
Enterprise organizations understand that to be leaders in their industries, they must change the way they deliver applications, improve their relationships with customers and gain competitive advantages.
Positioning those advantages to have a positive return on investment often starts with proper planning and automation.
But what does proper planning of your automation even look like?
For some enterprises, proper planning includes reducing automation costs. For others, it’s reducing time spent to open new opportunities.
With this in mind, Red Hat is excited to introduce Automation Savings Planner, a new enhancement that puts automation planning in the forefront within the hosted services on console.redhat.com.
The Automation Savings Planner is designed to provide a one stop shop to plan, track and analyze potential efficiency improvements and cost savings of your automation initiatives.
Users can create an automation savings plan within Red Hat Insights for Red Hat Ansible Automation Platform by defining how long and often the work is done manually, as well as a list of tasks needed to successfully automate this job.
Once defined, you can integrate your newly Continue reading