ANSIBLE AUTOMATION IS POWERFUL
- Automate your Linux and Windows environments, your network, your clouds, and your applications. Ansible Automation brings these pieces together.
- Do more than just configuration management server by server. Orchestrate your entire IT landscape.
- Use Ansible Automation modules to automate existing tools, programs, and scripts under one umbrella.
RED HAT ANSIBLE TOWER
Part of the Red Hat Ansible Automation product family, Red Hat Ansible Tower is an enterprise framework for controlling, securing, and managing your automation with a user interface (UI) and a representational state transfer (RESTful) application programming interface (API). It integrates with your existing IT stack and brings it together in an automated fashion. Ansible Tower provides the control, knowledge, and delegation to help your organization automate your entire IT landscape and your critical business processes.
- Automate your enterprise IT landscape. Focus on automation jobs and their results, instead of single, isolated nodes.
- Manage your automation at scale. Assign resources to cover heavy duty teams or set up distant nodes to integrate your remote datacenter.
- Integrate via the API. Enhance your existing, established tools by joining them with Ansible Tower.
- Automate with the business processes of your enterprise—instead of maintaining divisions.
KNOWLEDGE
- Have one central place to command the automation.
- Review results. See who accessed what, which automation worked on what piece of IT, and analyze the results.
- Gain a window into your IT landscape with a detailed history of each step of automation.
DELEGATION
- Bring together separate teams. Let your developers use automation, but ensure proper access rights and secure passwords.
- Provide automation as self-service tasks to other groups.
- Chain multiple automation pieces together via workflows.
PUPPET ENTERPRISE
Two main differences separate Ansible Automation and Puppet Enterprise: complexity and integration.
COMPLEXITY
Before you start automating your infrastructure, Puppet wants you to first provide a detailed description of your present infrastructure and how you want it to be in the future. Creating that description or model requires a large investment of time to analyze and implement the individual components to get it right before any real automation is started.
As organizations look to expand automation across an enterprise, the individuals who have the needed expertise are rare and expensive. The more an organization has these divisions, the greater the difficulty to adopt Puppet across the enterprise—though this cross-departmental automation offers the greatest rewards to an organization.
Additionally, the infrastructure description itself has to be written in Puppet’s native language, which is closely related to the programming language, Ruby. Before any automation can begin, internal teams or external consultants must be trained in this language, which can take weeks. As a result, companies using Puppet tend to have small, dedicated teams of experts running the automation, which prevents enterprise-wide automation of technical business processes.
INTEGRATION
For Puppet, automation is focused on the automated node—and is based on a set of automated servers. And the web interface to Puppet, the Puppet Enterprise console, is node-centric. However, in the journey to an automated enterprise, this approach should only be the first step. Automation needs to integrate the servers and virtual machines (VMs) with the applications running on top, with internal and external services and cloud platforms. An automated IT landscape requires the integration of all components in combined workflows, but Puppet lacks this requirement as it mainly focuses on nodes.
Also, the main Puppet infrastructure and automation model requires that agents run on managed environments. The agent and all of its dependencies—around 20 packages on Red Hat Enterprise Linux® —needs to be installed on every target node, requiring additional security checks and rules. Additionally, having an agent makes it hard to incorporate objects which cannot run agents: be it third-party web services, be it your application APIs or networking devices where a Puppet agent is not available or not allowed to run. Even when this agent-centric approach was softened a bit as Puppet introduced Bolt, an agent-less task runner, the general approach of Puppet and the corresponding tooling is still solely focussed on managed nodes and not on automated infrastructure.