In January 2016, I published the first-ever episode of the Full Stack Journey podcast. In October 2023, the last-ever episode of the Full Stack Journey podcast was published. After almost seven years and 83 episodes, it was time to end my quirky, eclectic, and unusual podcast that explored career journeys alongside various technologies, products, and open source projects. In this post, I wanted to share a few thoughts about saying goodbye to the Full Stack Journey.
First and foremost, let me say that I really enjoyed being the host of the Full Stack Journey podcast—far more than I expected I would, if I’m honest. While I didn’t love the logistics of producing a podcast, I did love getting to talk with folks, hear their stories, and learn about new things. So, while part of me is thankful to have a little less work to do, another part—a larger part—is sad to see it end.
That being said, some of you are probably wondering why it ended. I mentioned that I didn’t enjoy the logistics of producing a podcast; specifically, I didn’t enjoy audio editing. Some folks like it, but I didn’t. It was truly a chore for me. That was Continue reading
Over time, application owners find themselves compelled to continuously refine their applications and the underlying infrastructure to enhance the products they deliver, whether to internal or external customers. These modifications inevitably lead to changes in the configuration of both applications and infrastructure. While some of these changes may be benign, others can unintentionally steer the systems away from their securely configured state, a phenomenon commonly referred to as "configuration drift." Left unaddressed, the extent of this drift can introduce substantial risks to the organization.
Traditionally, agent-based automation configuration management tools have been favored as the primary solution for tackling configuration drift.
However, is this approach genuinely the most effective strategy?
According to AWS's well-architected framework, the concept of a Fault Isolation Zone (FIZ) is crucial, characterized by isolation boundaries like Availability Zones (AZ), Regions, control planes, and data planes. While this concept is centered in a cloud context, the principles behind FIZ remain relevant in traditional data centers and at the network edge. The core idea is to minimize the impact of errors, particularly human misconfigurations, that can propagate beyond a defined Fault Isolation Zone.
Are misconfigurations resulting from human error still a matter of concern?
Infrastructure automation is an area where systems administrators and IT operations teams can see some of the biggest benefits from automation, including time savings, reducing tedious manual work, and improving the overall health of their systems. In this blog, I've identified the top 5 infrastructure automation use cases for Ansible Automation Platform that you can deploy in your own environment, and I've incorporated new capabilities like Event-Driven Ansible to make managing your infrastructure even easier.
Before you get started with any automation project, we typically recommend using automation analytics to plan and predict the potential cost savings to help prioritize which automation projects will deliver the biggest time and cost savings.
Then you can use Ansible Automation Platform to create a workflow to build or configure a cloud or datacenter instance for RHEL, while using surveys to gather additional user input to enable further customization to meet any system requirements. You can even introduce an IT service management ticketing option, then review the job success and confirm service availability.
Watch this video to see it in action:
Ongoing Continue reading
The use of Event-Driven Ansible to enable fact gathering from events is considered a “Getting Started” type of use case, but it can be extremely powerful. This use case is simple and it is what we consider a “Read Only” type of action, meaning that we are not making any changes, but we are using the event to trigger a fact gathering process which we can later publish to the IT Service Management system.
The benefit with this is we are able to provide consistent automated troubleshooting and fact gathering which is used to enrich the ticketing systems, so when our engineers have a look at the incident, they have all the information they need to decide on the next steps to resolve the issue or situation. This can potentially save many hours of toil and ultimately save an organization money from reduced down time and faster resolutions. But, we are assuming that our technical teams will know what to do with this event data.
What if we could assist with filling the gap when an incident takes place, and we could receive information or even options on how to resolve the issues? This is where we could use Continue reading
CVE-2023-20198
Reference: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxe-webui-privesc-j22SaA4z
Cisco recently published an advisory pertaining to an active exploitation of a previously unknown vulnerability in the web UI feature of Cisco IOS XE Software when exposed to the internet or to untrusted networks. This vulnerability allows a remote, unauthenticated attacker to create an account on an affected system with privilege level 15 access. The attacker can then use that account to gain control of the affected system.
In this blog, I will discuss a simple playbook that can help network admins quickly identify and remediate affected devices. To add additional capabilities for a large production environment, Red Hat Ansible Automation Platform could enhance the playbook run with additional capabilities (ticketing integrations, roles based access, workflow, self service, etc.).
All Cisco IOS-XE based products are potentially at risk. The example playbook is located here.
In the example playbook we will explore its functionality using one of the Cisco Sandbox always-on routers
The following portion of the playbook will determine the HTTP Server Configuration and print the results.
Cisco strongly recommends that customers disable the HTTP Continue reading
This blog is co-authored by Tomas Znamenacek and Hicham (he-sham) Mourad
We’re so excited to introduce you to the newest addition to Red Hat Ansible Automation Platform on Microsoft Azure – The new landing page! Now with new deployments, a single web page that consolidates all you need to know about Ansible Automation Platform on Azure, how to get started, as well as links to the Ansible Automation Platform applications, is now accessible.
Upon arriving at this getting started landing page, you will see three tiles on the overview page. You have the ability to launch each of the following Ansible applications from the tiles: automation controller, private automation hub, and automation analytics, as well as a direct link to the managed Azure product documentation.
The bottom portion of the overview page sets you up for success by providing links to all the enablement content you need. It specifically provides links to Ansible Automation Platform on Azure Knowledge Base articles, documentation, and how to contact and request support.
Another important area is the “Managed Azure Maintenance and Feature Updates” that provides the link to the maintenance updates and feature releases to Ansible Automation Platform on Azure. Stay Continue reading
by Simen A.W. Olsen
Pulumi recently shipped Pulumi ESC, which adds the “Environment” tab to Pulumi Cloud. For us at Bjerk, this means we can move secrets into a secrets manager like Google Secrets Manager. Let me show you how we did it!
We are already rotating secrets with our own CLI tool, which works fine, meaning we are getting notifications in our Slack channel—which everyone tends to ignore until something real breaks. If you are curious how we are handling it today, we are using our own NPM package that throws an exception if a secret has expired. To ensure everything works smoothly, we utilize a GitHub Actions workflow that is scheduled to run daily for drift checking.
The secrets are shared between stacks using StackReferences, which has served us well.
One issue with our current setup is that we publicly store encrypted secrets in our repository. Previously, we’ve thought of using Google Secrets Manager with the GetSecret
function. That comes with its own territory, such as permissions to the secret and managing those permissions—not to mention that we already use multiple secret managers/vaults.
Now, with Pulumi ESC, it’s time to pick this Continue reading
Event-Driven Ansible became generally available in Ansible Automation Platform 2.4. As part of the release, Red Hat Insights and Ansible teams collaborated to implement and certify a Red Hat Insights collection integrating Insights events as a source of events for Ansible Automation Platform. This provides a consistent way to receive and handle events triggered from Insights to drive and track automation within the Ansible Automation Platform. The collection is available for installation on Ansible automation hub.
In this article, we explore how to get, configure and use the Red Hat Insights collection for Event-Driven Ansible, and provide an end-to-end example of an automation flow using Ansible Automation Platform and its Event-Driven Ansible functionality. Our goal is to automate the creation of a ServiceNow incident ticket with all relevant information when malware is detected by Insights on one of our Red Hat Enterprise Linux (RHEL) systems. We show how we can track and audit all automation from the Event-Driven Ansible controller as part of Ansible Automation Platform.
In a previous article, we looked at exposing and consuming Insights events to drive automation with Event-Driven Ansible. We validated that events triggered Continue reading
In a previous blog, I announced the tech preview of containerized Red Hat Ansible Automation Platform. With that we introduced a new feature to enable you to pre-seed configuration and content at installation time. This blog will take you through how that works.
At Red Hat, we are very lucky to have some super talented people. Some of these great folks have worked tirelessly on producing Ansible Content Collections for managing configuration within the platform. Using this as the foundation, we have wrapped enablement around that to provide a fully automated way of doing this, in a seamless fashion.
Many people today already use a configuration-as-code (CaC) approach to managing the platform and laying down standards for their users. If that’s your case, then this simply extends and simplifies this capability.
If this is a new concept to you, then these examples may be of interest:
Ansible validated content is a set of collections containing pre-built YAML content (such as playbooks or roles) to address the most common automation use cases. You can use Ansible validated content out-of-the-box or as a learning opportunity to develop your automation skills. It's a trusted starting point to bootstrap your automation: use it, customize it and learn from it!
This content is curated by experts like the Red Hat Automation Community of Practice so:
Ansible Automation Platform is a trusted delivery system to access and leverage Ansible validated content in your organization.
To do this there are a few short steps. Let’s walk through these together.
As part of your Ansible Automation Platform on cloud, you will also have a private automation hub. This is your own internal automation content Continue reading
In the realm of automation, the ability to respond to events in real-time is a game-changer. At Red Hat, we've been pioneering in this space with Event-Driven Ansible, which can consume messages from various sources like AWS Simple Queue Service (SQS), Azure Service Bus, and Kafka to trigger automated actions. Today, we're excited to delve into a powerful integration pattern involving AWS Lambda, AWS SQS, and Event-Driven Ansible.
Imagine this: A SaaS application sends a webhook POST request. This request triggers a Lambda function, which validates an API key or other payload data, filters the payload, and sends a message to SQS. Event-Driven Ansible subscribes to the queue, consumes the message and triggers an automated action. Let's explore this workflow in detail.
Here's a visual representation of the workflow with AWS Lambda and AWS SQS:
Ideally, in this model, webhook POSTs should selectively be sent to the SQS queue. Rulebooks within Event-Driven Ansible have the ability to validate that a key within the header contains the specified value – but that means the message is already on my queue. I want to stop that from happening. In this case, my Lambda function should be able to validate Continue reading
The Ansible Contributor Summit is a full day working session for community contributors to interact with one another and meet with the Ansible development teams behind the projects like AWX, Galaxy NG, Molecule, Ansible Lint and Event-Driven Ansible. We will discuss important issues affecting the Ansible Community and help shape the future of collaboration.
We are happy to have the opportunity to do a second Contributor Summit this year, and this time it will be part of DjangoCon US 2023 in Durham, NC. Our previous experience co-locating the Contributor Summit with another related event was in February in Ghent, Belgium as part of CfgMgmtCamp 2023. It was so successful, we wanted to do it again with another great match.
We will be meeting in the "Bull City", the home of Ansible itself and the inspiration for our beloved mascot, Ansibull. In case you didn't know, the Ansible office overlooks the Durham Bulls Athletic Park, and this mixed with Ansible word play is why you might see mentions of bulls and Ansibulls in Ansible land.
If you can't attend the event in person in Durham, worry not! Ansible Contributor Summit is a hybrid event, Continue reading
We’re excited to announce something that we’ve been working on for a while now, the technical preview of a containerized Red Hat Ansible Automation Platform solution.
Currently, this will allow you to install and run containerized automation controller, Ansible automation hub, and the Event-Driven Ansible controller services on just one or more underlying RHEL hosts on x86_64 and ARM64 architectures. This does not require a kubernetes-based platform, as it just uses native RHEL podman on top of a RHEL host.
As Ansible Automation Platform evolved, we added more services and components into the stack. Over time, the increasing complexity and inter-dependencies between these components have introduced new challenges in terms of maintenance, installation, and support. They have also opened up opportunities for growth and innovation.
Containerized Ansible Automation Platform is the first step towards a more streamlined and improved platform management experience, incorporating our future vision and strategy.
Just containerizing existing services was not enough for us, so we set some goals to provide:
For awhile, the Red Hat Ansible team behind the components Ansible automation hub and Ansible cloud automation hub at console.redhat.com have been on a special ops mission to enhance the galaxy_ng code base that serves the aforementioned components to also serve galaxy.ansible.com, with the intention of replacing galaxy.ansible.com with a fresh code base.
The current Galaxy service has been running at galaxy.ansible.com for many years and is hugely successful in the community. It drives and nurtures Ansible adoption by sharing prebuilt Ansible content that solves many automation challenges.
One of the statistics we are most proud of are the contributions of 33,965 individual automation answers by the community in either Ansible Content Collections or Ansible Roles. Some of the top ranking automation content includes AWS, VMware, Linux, and Windows. Community users are able to download content for free, self-supported and interact with authors via GitHub for any further help or enhancements.
For awhile, the Red Hat Ansible team behind the components Ansible automation hub and Ansible cloud automation hub at console.redhat.com have been on a special ops mission to enhance the galaxy_ng code base that serves the aforementioned components to also serve galaxy.ansible.com, with the intention of replacing galaxy.ansible.com with a fresh code base.
The current Galaxy service has been running at galaxy.ansible.com for many years and is hugely successful in the community. It drives and nurtures Ansible adoption by sharing prebuilt Ansible content that solves many automation challenges.
One of the statistics we are most proud of are the contributions of 33,965 individual automation answers by the community in either Ansible Content Collections or Ansible Roles. Some of the top ranking automation content includes AWS, VMware, Linux, and Windows. Community users are able to download content for free, self-supported and interact with authors via GitHub for any further help or enhancements.
The Ansible Contributor Summit is a full day working session for community contributors to interact with one another and meet with the Ansible development teams behind the projects like AWX, Galaxy NG, Molecule, Ansible Lint and Event-Driven Ansible. We will discuss important issues affecting the Ansible Community and help shape the future of collaboration.
We are happy to have the opportunity to do a second Contributor Summit this year, and this time it will be part of DjangoCon US 2023 in Durham, NC. Our previous experience co-locating the Contributor Summit with another related event was in February in Ghent, Belgium as part of CfgMgmtCamp 2023. It was so successful, we wanted to do it again with another great match.
We will be meeting in the "Bull City", the home of Ansible itself and the inspiration for our beloved mascot, Ansibull. In case you didn't know, the Ansible office overlooks the Durham Bulls Athletic Park, and this mixed with Ansible word play is why you might see mentions of bulls and Ansibulls in Ansible land.
If you can't attend the event in person in Durham, worry not! Ansible Contributor Summit is a hybrid event, so you will Continue reading
Today, we're delighted to announce the launch of the new Ansible Community Forum - a single starting point for questions and help, development discussions, events, and much more. Everyone is invited, whether you are an Ansible user, contributor or developer, we are all community! Register here to join us!
Screenshot of the forum's main page
For those who are familiar with forums, we hope you'll feel right at home. For those who may be new, please don't worry! We have a list of tips & tricks here, and you're always welcome to check the guides and post in the feedback section to help us shape our online community.
Forums are only successful if they are used. To make that happen, the Ansible Community Team is looking to make this the real home of the Ansible Community - a place for users to get help, to find an event or local meetup, and a jumping-off point for development and contribution discussions. That means we need you to come and participate! Tell us what you're up to, post your thoughts or your questions, sign up for an event or two.
The Ansible Community is global, Continue reading
Appropriately tagging resources on AWS is an important part of effectively managing infrastructure resources for many organizations. As such, an infrastructure as code (IaC) solution for AWS must have the ability to ensure that resources are always created with the appropriate tags. (Note that this is subtly different from a policy mechanism that prevents resources from being created without the appropriate tags.) In this post, I’ll show you a couple of ways to assign tags by default when creating AWS resources with Pulumi. Code examples are provided in Golang.
There are at least two ways (perhaps more) of handling this with Pulumi:
Each approach has its advantages and disadvantages, so there isn’t—in my opinion, at least—a definitive “best way” to doing this. The best way for you will depend on your specific circumstances.
In both cases, the solution involves modifying the configuration of the resource provider Pulumi uses to provision AWS resources. Pulumi supports the notion of both default providers and explicit providers. The former are created automatically and are configured via the stack configuration. (In fact, using stack configuration is currently the Continue reading
Today, we're delighted to announce the launch of the new Ansible Community Forum - a single starting point for questions and help, development discussions, events, and much more. Everyone is invited, whether you are an Ansible user, contributor or developer, we are all community! Register here to join us!
Here is a screenshot of the forum's main page:
For those who are familiar with forums, we hope you'll feel right at home. For those who may be new, please don't worry! We have a list of tips & tricks here, and you're always welcome to check the guides and post in the feedback section to help us shape our online community.
Forums are only successful if they are used. To make that happen, the Ansible Community Team is looking to make this the real home of the Ansible Community - a place for users to get help, to find an event or local meetup, and a jumping-off point for development and contribution discussions. That means we need you to come and participate! Tell us what you're up to, post your thoughts or your questions, sign up for an Continue reading
Welcome to Technology Short Take #170! I had originally intended to get this published before the long Labor Day weekend, but didn’t quite have it ready. So, here you go—here’s your latest collection of links from around the internet focused on data center and cloud-related technologies. I hope that you find something useful here.
kube-proxy
.