devopsy.kinsta.cloud

Tag: ansible

  • Red Hat Adds Managed Ansible Service on Azure

    Red Hat Adds Managed Ansible Service on Azure

    Red Hat today announced general availability of a managed instance of the Red Hat Ansible Automation Platform on the Microsoft Azure cloud.

    Announced at the Red Hat Summit 2022 event, this offering makes it possible to deploy the control plane for Ansible on the Microsoft Azure cloud as an alternative to existing support for Amazon Web Services (AWS) or an on-premises IT environment.

    In addition, in version 2.2 of the Ansible Automation platform, Red Hat is previewing support for content signing technology that automatically validates content to improve overall security.

    Thomas Anderson, vice president of Ansible for Red Hat, said this managed service enables IT teams to take advantage of integrated Microsoft billing in addition to the latest features and content provided for the platform and other capabilities that have been added to optimize Microsoft Azure environments.

    The open source Ansible platform has been gaining traction as an automation framework that enables IT teams to declaratively automate tasks. It requires less programming expertise than rival automation frameworks, which Anderson said is the primary reason so many third-party vendors have adopted Ansible to automate a range of IT tasks.

    The challenge many organizations encounter today is managing multiple islands of automation across multiple clouds and on-premises IT environments. Ansible presents IT teams with the ability to begin unifying all those islands under a single framework, said Anderson.

    It’s not clear to what degree DevOps teams that have embraced rival automation frameworks might be willing to replace them with Ansible. However, as more IT teams embrace automation to make up for shortages of IT personnel, it’s apparent that Ansible is being used across a wide range of IT disciplines spanning everything from DevOps to network management.

    Regardless of the approach, the need to automate as many tasks as possible is becoming critical as IT environments grow increasingly more complex. Many of the scripts that IT teams created on their own simply don’t scale. More challenging still, they are not often documented, so every time the IT professional that created that script leaves the organization it becomes difficult to maintain that scripting code.

    In the longer term, of course, automation frameworks will be increasingly infused with machine learning algorithms capable of learning the unique nuances of individual IT environments. It’s not likely those algorithms will replace the need for IT professionals any time soon. However, rather than resisting automation, more IT professionals have concluded that the tasks required are simply too challenging to manually perform. Many will conclude they simply prefer to work for organizations that have a consistent approach to IT automation that makes it feasible for them to manage a wide range of IT tasks.

    One way or another, IT automation is becoming a standard capability that now goes well beyond the scope of a few isolated DevOps workflows. The issue is finding a way for IT professionals with varying skill levels to collaborate across a common framework that is both easily accessible and highly extensible.

  • Red Hat Brings Ansible Automation to Microsoft Azure Cloud

    Red Hat Brings Ansible Automation to Microsoft Azure Cloud

    Red Hat this week announced that a private preview of the Red Hat Ansible Automation Platform is now available on the Microsoft Azure Cloud.

    Tom Anderson, vice president of Red Hat Ansible automation, said making the Red Hat instance of the open source automation framework available on Azure is the first step toward making it possible for IT teams to use the IT automation framework across multiple clouds.

    The goal is to make it simpler for IT teams to bridge multiple IT environments using a common framework to automatically configure everything from operating systems to security platforms across a hybrid cloud computing environment.

    Ansible is emerging as a de facto standard for automating IT environments largely because it provides an IT team with a declarative approach to automating IT processes. An IT team can write a playbook that describes their desired state for a platform without having to know anything about its current state.

    Interest in IT automation has soared as the number of workloads being deployed in the cloud and on-premises IT environments have steadily increased. The simple truth is that many organizations can’t keep pace with the rate at which applications are built and deployed because they are unable to hire and retain enough IT staff. The challenge is that writing a playbook to automate any IT process requires a fair amount of expertise that many organizations lack. There are, however, now large numbers of existing templates that organizations can reuse.

    Anderson also noted that security concerns will also force the IT automation issue. Many of the application workloads running in cloud computing environments are misconfigured because they were provisioned by developers that have little to no security expertise. A playbook greatly reduces the chances an application workload will be misconfigured in the cloud without having to turn every developer into a security expert, Anderson explained.

    Ultimately, IT automation frameworks reduce the level of friction that often exists between developers and the rest of the IT operations team in a way that actually serves to increase developer productivity, added Anderson.

    Regardless of how IT organizations automate IT processes, it’s now a question of the rate at which that goal will be achieved rather than if. DevOps teams, of course, have always been at the forefront of automation, but now it’s clear that as IT environments become more complex, IT organizations are embracing automation more aggressively. Most of those initial efforts are focused on repetitive, tedious and manual IT tasks, but the potential to automate IT processes at levels of unprecedented scale has never been greater.

    In fact, many organizations may soon discover it’s difficult to retain IT professionals without investing in automation. After all, the most talented IT professionals will not want to work for an organization that requires them to always manually configure IT resources. Many IT teams might also discover that automation frameworks like Ansible are the gateway to embracing additional DevOps best practices. The challenge, of course, is finding the time to get started automating processes when there are so many immediate issues that IT teams can’t ignore.

  • Red Hat Extends Scope of Ansible Automation Ambitions

    Red Hat Extends Scope of Ansible Automation Ambitions

    During the online Ansiblefest, Red Hat announced the availability of a preview edition of Red Hat Ansible Automation Platform 2 that is intended to make it easier to automate IT processes at scale.

    Richard Henshall, senior manager for Ansible product management at Red Hat, said previously most IT teams have been automating individual processes, but as organizations become more adept at creating playbooks to automate processes, they now need to find ways to manage multiple automations that are often dependent on one another.

    Ansible Automation Platform 2 also enables IT teams to automate processes that span both monolithic as well as cloud-native applications based on containers using an automation controller, formerly known as Ansible Tower, that is more tightly integrated with Red Hat OpenShift, an application development and deployment platform based on Kubernetes, using Red Hat Operator tools. There is also an automation mesh capability that connects disparate automation components together and provides status checks.

    Ansible Automation Platform 2 also introduces automation execution environments within Ansible Engine that make it possible to create self-contained automation spaces that can be easily replicated and repeated across an organization.

    Red Hat also includes an automation content navigator to helps teams validate that automation content is working as it should across even the largest environments, along with updates to the Red Hat Insights analytics service that enable issues that might occur with automation controllers to be surfaced and eliminated by automatically applying policies.

    Henshall said going forward, IT teams should expect to see Red Hat focus more on enabling events to be the catalyst for triggering automation. Today, most automated processes begin with an IT administrator triggering the process. However, as digital business transformation initiatives mature, it’s become apparent there will be a need to trigger automation when specific events occur.

    Henshall said while there are still many organizations that are just starting to automate IT processes, there are also many that are entering the next phase of maturity. As such, they now require an automation platform that makes it simpler to manage automation at scale.

    In general, Ansible is designed to make it possible for developers and IT operations teams alike to declaratively create automation without much programming expertise required. However, creating a playbook that works reliably still requires a deep understanding of the processes that are being automated. Most IT teams would be well advised to closely monitor processes when they are first automated to make sure they are performing tasks as anticipated.

    Ultimately, it’s now a question of when rather than if most IT processes will be automated. DevOps teams, of course, have always been at the forefront of automation, but now it’s clear that as IT environments become more complex—with the rise of both the cloud and edge computing platforms—enterprise IT teams need to embrace automation more aggressively. The biggest barrier to automation is simply finding someone who has the passion to automate a process to lead the charge, said Henshall.

    Naturally, most of those efforts will initially focus on repetitive, tedious and manual IT tasks, but the potential to automate IT processes at levels of unprecedented scale has never been greater.

  • Keys to the Kingdom: Protect Your Server from Hackers

    Keys to the Kingdom: Protect Your Server from Hackers

    Automation and DevOps undeniably improve the agility and responsiveness of IT. Most of us have taken up at least a bit of the wave of automation that DevOps and Agile have brought to our door, and many are far along on their DevOps journey.

    But every once in a while, we need to look back and lend a hand to those still coming. The fact of the matter is that sometimes we forget to warn those who are new to massive automation about some serious issues.

    It is intuitively obvious, if you think about security at all, that putting together a command and control server—we’ll use Ansible in this blog, but any tool that can roll out applications to a collection of servers—creates a big screaming target for any hacker that gets into your infrastructure. You cannot assume that will never happen, so organizations need to think about protective systems/architectures early, or spend more time patching things up. Remember, the more you build, the more weight there is to making major changes.

    For starters, severely limit access to the command and control machine. It belongs on a management subnet/VLAN with only a few access points. The servers it is managing absolutely should not have access back to the command and control server. If they do, any one of them getting controlled will provide a pathway to all of them getting controlled.

    Next up, early on there were quite a few debates/discussions about which user accounts should be able to run command and control scripts (Playbooks in Ansible). Eventually, the bulk of the community settled on each individual running them, not a single generic user with a name like “ansibledeploy.” Some still use a central user, but the majority wants the ability to track down the leak that individuals running commands allow—searching for strange/uncommon command execution in logs will cough up which account got compromised and allow for rapid response—which outweighs centralization.

    Third, learn and use the security features available in your application. Ansible offers Ansible Vault to allow encryption of playbooks. Since many playbooks require root access, encryption allows those playbooks to hide root access. Use of Ansible Vault has grown over time, and there are excellent tutorials out there to help use it to lock down command and control. Your product will have a similar tool, because putting root passwords in plain text, all over the disk, is just not acceptable.

    In the Ansible Galaxy/Github repositories, you can find excellent roles to help in your quest to lock things down. Geerlingguy is one of the most popular, and his Ansible Role – Security is excellent if you follow the caveats he provides in the readme.

    This is simply an advisory, not a step-by-step solution set. Overall, just remember that putting together a command and control server makes a tempting target. And like Geerlingguy points out in his readme, your security is your concern.

    Look at where the server can be accessed from, who can access it, where sensitive data bits such as passwords are stored—hint: plain text passwords in files went out of fashion when mainframes were hooked up to LANs—and how to protect all of the above. It’s been done, there are plenty of resources to help in your given environment. Take the time to look them up and implement relevant suggestions.

    After all, I won’t get a call in the dead of night if your servers are all taken over, you will. Do everything you can to avoid getting that call. And keep rocking. Everyone remote working has made many organizations more susceptible to all forms of attack, don’t let your guard down.

  • Red Hat Ansible Certified Content for IBM Z now available for developers

    These new Ansible modules join other recent additions to DevOps tooling for z/OS on IBM Z.

    The entire IBM Z platform is rapidly evolving, with major advances coming across Linux on Z, LinuxONE, and z/OS. Hybrid multicloud demands consistency and agility from all of these platforms. Validation of dozens of open source projects for Linux on Z and LinuxONE has been a boon for developers and DevOps practitioners alike.

    That’s why I’m pleased to announce the availability of the Red Hat Ansible Certified Content for IBM Z, which includes the z/OS Core Collection and is now available on Ansible Galaxy and Ansible Automation Hub as a supported, certified collection by Red Hat.

    This is an important step forward in enabling z/OS to participate in an Ansible-based enterprise automation strategy in exactly the same way that the rest of your environments do. Leveraging Ansible to automate z/OS brings consistency across the hybrid multicloud environments and enables z/OS to transparently participate in your infrastructure.

    These new Ansible modules join other considerable developments in DevOps tooling support for z/OS on IBM Z systems. You can now use modern IDEs like Visual Studio Code and the Eclipse Che platform, employing familiar tools to code in COBOL and PL1 for IBM z/OS. IBM Dependency Based Build (DBB) enables building z/OS source code files with Jenkins and Git, and can be staged on generic artifact repositories like Artifactory or Nexus for deploying as part of a standard CI/CD pipeline. For rapid integration of Linux-based software and workloads in support of z/OS applications, check out the z/OS Container Extensions (zCX), which support Docker containerized workloads directly on z/OS.

    All of these DevOps tools that are now available on IBM Z more closely align development pipelines with those being used throughout an organization. IBM Distinguished Engineer Rosalind Radcliffe described application modernization efforts on IBM Z, saying “development from a pipeline perspective, the CI/CD coordinator, the SCM deployment tool, is identical whether or not I’m doing Java, COBOL, Node, C#. It doesn’t matter.”

    When you also add Red Hat OpenShift, which was recently made available for Linux on IBM Z, having Ansible-based provisioning on z/OS offers great value to your organization. It provides IBM Z users the ability to seamlessly unite workflow orchestration with configuration management, provisioning, and application deployment in one easy-to-use platform, regardless of operating system.

    Looking beyond your IBM Z environments, you may already be using a cloud-based deployment managed by Ansible. In a hybrid infrastructure that includes IBM Z, Ansible can manage your traditional cloud-based workloads, as well as your workloads on IBM Z, furthering the goal to build smart, build secure.

    Ready to dive in? Try out this IMS provisioning example to get started.

    Next steps

    • To learn more about DevOps on IBM Z, visit the DevOps section of the Mainframe DEV blog to see the latest developments.
    • Check out the new Z DevOps Talks podcast for lighthearted but deeply technical discussions with key players in the DevOps for IBM Z sphere.
      • Their first podcast features Rosalind Radcliffe, IBM Distinguished Engineer and Chief Architect for DevOps for z Systems at IBM.
      • The February 11th episode covers Ansible for z/OS with Kyle Charlet, IBM Distinguished Engineer working on Ansible modules and more.
  • DevOps at Longtail UX

    DevOps at Longtail UX

    Longtail UX is an Australian SaaS startup that boosts traffic to e-commerce sites by automating the selection of relevant long-tail search terms and the creation of custom landing pages for each of those terms.

    The company has fully embraced the Infrastructure-as-Code approach, according to Troy Jendra, senior systems architect at Longtail UX.

    By using Terraform and Ansible for automation, “we can release whenever we want,” said Jendra. In practice, that can be at intervals between two minutes and as long as necessary at the other extreme.

    Jendra said he had not used Ansible before joining Longtail UX. He used Puppet in a previous role, but found it “painful.”

    “Ansible was a breath of fresh air,” confessed Jendra. It makes it easier to write configurations, and uses fewer CPU cycles because it does not need to run continuously. He explained that Terraform’s role is to spin up sufficient infrastructure so Ansible can run.

    A recent project added support for CJK (Chinese, Japanese, Korean) characters to Longtail UX as part of a push into the Asia market, and that made it necessary to clone part of the infrastructure. Thanks to Ansible and Terraform, that task was easy to perform and completed in just half an hour. Thus, Longtail UX brought the new capability to market more quickly than would otherwise have been possible.

    Ansible and Terraform together form “a cornerstone of our disaster recovery plans,” said Jendra. Fully automating recovery to improve on the current worst-case time of a few hours would take more time and effort than justified.

    Apart from that, “it’s important to automate as much as we can,” said Andreas Dzumla, Longtail UX co-founder and CEO.

    Avoiding Vendor Dependence

    Even though Longtail UX runs on AWS, a deliberate decision was taken to avoid the vendor-dependency that would come from using AWS-specific services, such as AWS CloudFormation, in place of Terraform.

    For the same reason, the company keeps things as simple as possible and sticks to AWS basics, such as EC2. It has recently started using Spot Instances to reduce the cost of running certain batch processes.

    Jendra keeps a watching brief on AWS Lambda, and while the company does not currently have a use case he does see a time when it will jump from EC2 to Lambda.

    “We’re pretty locked into AWS,” he admitted. However, the company uses AWS-specific services only where the benefits clearly outweigh the lack of portability. He likened the situation to 1990s attitudes toward using Microsoft-specific technologies.

    Growth

    The adoption of Kubernetes is not on the cards due to the relatively small size of Longtail UX’s DevOps team.

    “We’ve doubled the size of our development team in the last six months,” said Jendra. It now comprises seven developers, a project manager and himself.

    Dzumla expects it will double again in the next 12 months.

    Jendra predicts that improvements to Longtail UX’s development stack will make it easier to on-board new hires.

    “We currently utilize a Vagrant/VirtualBox dev stack (hooked into the aforementioned Ansible configuration), but find that very rough around the edges, and I only see it get worse as more attention is focused on Docker,” said Jendra.

    DevOps is a philosophy, not a role, he emphasized. “Either everyone is doing DevOps or it doesn’t work.”

    Fortunately, that understanding goes to the top of the company.

    “Everyone needs to pitch in,” said Dzumla. “We do a lot of things that haven’t been done before, so we need senior people who don’t merely expect to do what they’re told.”

    — Stephen Withers

  • Red Hat Unveils Ansible Platform

    Red Hat Unveils Ansible Platform

    At the AnsibleFest 2019 conference, Red Hat this week announced the general availability of the Red Hat Ansible Automation Platform that combines several IT automation technologies into a single subscription.

    Built on top of Red Hat Ansible Engine, the platform also includes Red Hat Ansible Tower, a management console, and Red Hat Network Automation, an instance of Ansible designed to automate the management of network resources.

    Red Hat is also providing access to a software-as-a-service (SaaS) analytics application that enables IT teams to monitor how deeply Ansible has been adopted within any IT environment. That application also provides access to Ansible Content Collections, a packaging format that streamlines the management, distribution and consumption of Ansible content, and Automation Hub, a repository for certified content packaged using Ansible Content Collections.

    Richard Henshall, product manager for Red Hat Ansible Automation, said with this offering Red Hat is trying to make it easier for enterprise IT organizations to implement Ansible at scale. Most of the time the Ansible framework is adopted from the bottom up within an IT organization. Red Hat Ansible Automation is intended to make it easier for enterprise IT organizations to centrally deploy and manage all their instances of Ansible, he said.

    Although it’s not possible to know how many instances of the open source IT automation framework have been installed, Henshall noted there are already more than 4 million Ansible nodes that are tied to a paid support subscription from Red Hat. Most of those instances involve organizations that have adopted a declarative IT automation framework as part of their overall DevOps strategy, he said. While IT organizations don’t necessarily have embrace DevOps to employ Ansible, Henshall said there is a strong correlation.

    Much of that success can be tied to the fact that as a declarative framework Ansible doesn’t require IT operations teams to learn how to program to manage IT operations at scale. That approach has allowed IT teams to adopt the open source framework to meet the demands for more agile approaches to managing IT infrastructure stemming from developers who have embraced best DevOps practices.

    In addition, IT infrastructure vendors such as Cisco Systems, NetApp and F5 Networks have begun to embed Ansible within their server, storage and networking platforms. As those vendors sell the latest edition of their offerings, the number of IT organizations exposed to Ansible should begin to substantially increase.

    Henshall said the biggest issue now is expanding the scope of Ansible deployments. Most organizations initially wind up using Ansible to automate disaster recovery before moving on automate additional existing processes. Red Hat is now trying to encourage those teams to create new processes that previously would not have been possible without an IT automation framework, he said.

    Ansible may not be a de facto standard in the enterprise just yet, but it’s well on its way. Of course, there are still many IT professionals for one reason or another still tend to resist relying on IT automation frameworks. There are also several rival IT automation frameworks that have been embraced by DevOps teams. But when it comes IT automation, it’s clear Ansible is starting to emerge as the path of least resistance.

    — Mike Vizard

  • Cisco Extends Ansible Support to Advance DevOps

    Cisco Extends Ansible Support to Advance DevOps

    Cisco Systems announced today that it is further embracing the open source Ansible automation framework on its storage area network (SAN) platform as part of an effort to extend best DevOps practices to IT infrastructure. The latest version of the Cisco MDS 9700 platform modules automates tasks such as VSAN configuration, device-alias and zoning configuration.

    Adarsh Viswanathan, product manager for data center storage at Cisco, said the company has embraced the Ansible framework because it’s an open framework that is now being adopted by enterprise IT organizations to manage infrastructure in a more adroit fashion. The rise of cloud-native applications being developed with DevOps processes not only result in more applications accessing a common pool of data, but also require changes to be made dynamically to the underlying storage platform.

    Cisco is adding support for 64G-line cards when they become available along with support for non-volatile memory express (NVMe) and All-Flash arrays. Cisco has also extended its SAN Analytics software to add support for the NVMe/Fibre Channel protocol along with existing support for SCSI/Fibre channel.

    Viswanathan said support for Ansible will make it simpler for IT organizations to embrace automation at scale. Cisco has previously embraced open application programming interfaces (APIs), OpenStack and Python-based scripts. Ansible takes those efforts to a higher level by make available a declarative framework that doesn’t necessarily require IT operations teams to develop programming expertise, said Viswanathan.

    IT operations teams are coming under increased pressure to provide developers with an IT experience that rivals cloud service providers. Frameworks such as Ansible make it possible for IT operations teams to make IT resources available on-demand to developers using IT infrastructure residing in an on-premises environment.

    Friction between developers and IT operations teams is rising as DevOps processes are employed more widely within enterprise IT environments. Many of those developers have alternatively turned to cloud service providers to build and deploy their applications. However, many organizations still need to deploy applications once they move into a production environment hosted in a local data center. In fact, more than 70% of enterprise applications still run in a local data center a decade after the initial rise of cloud computing. IT operations teams that manage those on-premises IT environments need to provide developers with access to resources they can easily scale up and down as required.

    Cloud-native applications based on microservices will further challenge IT operations teams as the number of application services trying to share a limited set of IT infrastructure resources only increases. In the case of Cisco, those limited resources are rack-based servers attached to SANs such as the Cisco MDS 9700.

    Of course, not every IT operations team is going to embrace DevOps processes overnight. Instead, many of them will be exposed to frameworks such as Ansible as they upgrade servers and storage over time. The one thing that is certain is developers will continue to apply pressure to make that transition sooner than later as more organizations continue to appreciate the extent to which they now depend on software to innovate.

    — Mike Vizard

  • Morpheus Data Simplifies Management of Ansible and Kubernetes

    Morpheus Data Simplifies Management of Ansible and Kubernetes

    Morpheus Data is moving to make it easier to adopt and manage both Ansible and Kubernetes. Its Morpheus 4.0 update, announced today, includes a distribution of Kubernetes as well as tighter integration with the open source Ansible automation framework.

    Brad Parks, vice president of marketing and business development for Morpheus Data, said in the case of Ansible, Morpheus 4.0 will eliminate the need for some organizations to employ Ansible Tower, a web-based console and application programming interface (API) used to manage instances of Ansible. The goal is to make it easier for organizations to take advantage of the declarative Ansible automation framework without having to master all the low-level minutiae currently required to deploy and manage it, he said.

    Morpheus 4.0 also makes it possible to view real-time job status updates and detailed log output and execute phased-based and operational workflows using multiple playbooks and brings governance, auditing and reporting tools to Ansible. Morpheus 4.0 also makes it possible to configure Ansible to run over the Morpheus secure agent communication bus, allowing playbooks to be applied to instances where SSH/WinRM access may not be feasible due to security constraints. Available on both Linux and Windows platforms, Ansible also can employ that bus to query secrets securely from the Morpheus Cypher service for storing application secrets.

    In a similar vein, Morpheus Data is also moving to automate the deployment and management of Kubernetes, an open source container orchestration engine developed under the auspices of the Cloud Native Computing Foundation (CNCF).

    By including a distribution of Kubernetes in Morpheus 4.0 that has been certified by the CNCF, Parks said Morpheus Data now makes it possible to federate the management of Kubernetes clusters across a hybrid cloud computing environment. DevOps teams can employ either the distribution of Kubernetes provided by Morpheus Data or Morpheus to provision instances of Kubernetes services provided by public cloud service providers such as Amazon Web Services (AWS), Microsoft and Google.

    Morpheus 4.0 also makes it possible to securely share and govern resources using role-based access controls, optimize resource allocation using analytic tools and audit, monitor and manage logging. DevOps teams also have the choice of provisioning applications using either Morpheus or the Helm templates made available by the CNCF.

    As Kubernetes moves into the enterprise, Parks said IT organizations will need a management framework that can automate the provisioning of application stacks on any combination of legacy virtual machines, Kubernetes clusters and bare-metal servers. Rather than be required to acquire and master separate tools for each platform, Morpheus 4.0 provides a management platform that allows a single DevOps team to manage multiple platforms more easily, he said. As an enterprisewide orchestration and automation platform, Morpheus is designed from the ground up to eliminate the need for DevOps teams to create complex playbooks by providing out-of-the-box integration with wide a variety of IT platforms, Parks added, noting Morpheus 4.0 also now includes Morpheus Jobs, a tool through which jobs can be scheduled or run ad-hoc using Bash, PowerShell, HTTP, Ansible, Chef, Puppet, Groovy, Python, jRuby or JavaScript.

    The number of organizations attempting to unify the management of multiple platforms is expected to increase significantly in the months and years ahead as the number of cloud platforms being employed increases. The challenge those organizations will face involves not only what tools to employ to achieve that goal, but also defining the DevOps processes capable of spanning a hybrid cloud computing environment.

    — Mike Vizard

  • Red Hat Adds Support for Nested Workflows to Ansible Automation Framework

    Red Hat Adds Support for Nested Workflows to Ansible Automation Framework

    Red Hat today announced it is adding support for nested playbooks created using the open source Ansible automation framework within one another, which, in turn, will make it easier to automate complex IT processes.

    Bill Nottingham, product manager for Ansible, said the goal is to enable DevOps teams to reuse existing Ansible playbooks to kick off a series of nested IT jobs and workflows using version 3.4 of Ansible Tower, the console Red Hat provides for creating and managing Ansible playbooks.

    Version 3.4 of Ansible Tower also now makes it possible to slice an IT job into a series of smaller jobs that can be distributed across a cluster to accelerate execution. That capability makes it possible to scale out the processing of an Ansible playbook, he said.

    Finally, Red Hat also announced that Ansible Tower. 3.4 is now able to run on Red Hat Enterprise Linux in Federal Information Processing Standard (FIPS) compliant mode.

    Nottingham said Red Hat expects the ability to reuse Ansible playbooks within a set of nested processes will encourage IT organizations to create more playbooks now that it’s easier to reuse them as a set of modular components. IT organizations can even make launching jobs dependent on the completion of other jobs using a scheduling mechanism within Ansible Tower, he added.

    Although adoption of IT automation frameworks has been uneven, the last few years has seen IT organizations rely more on them to manage tasks as IT environments become more complex. That level of complexity will only increase as IT organizations deploy more applications that are based on microservices created using containers that need to be updated frequently. IT automation frameworks also go a long way toward making up for what has become a chronic shortage of skilled IT administrators. That capability is especially critical as both the number of applications and the rate at which they are being updated continue to accelerate.

    Most IT administrators have limited programming skills, which is why a declarative approach to IT automation in the form of an Ansible open source project has been gaining significant traction. In fact, thanks to automation, traditional IT metrics such as the number of servers being managed per administrator increasingly are becoming obsolete.

    It may take a little while longer before IT automation frameworks are the rule than the exception. But as the IT community now approaches the end of the second decade of the 21st century, reliance on manual processes that were developed at the end of the last century is no longer viable in this era of distributed workloads. In fact, regardless of where applications are deployed, the expectation in the DevOps era is that existing IT operations teams will be able to manage them without having to hire additional IT administrators.

    — Mike Vizard