Ansible vs Puppet

Ansible and Puppet are the configuration management systems (SCM) needed to build repetitive infrastructures.

Ansible is easy to use, has an agentless architecture (does not require the installation of an agent / client on the target system) and a YAML-like DSL, written in Python and easily expanded by modules. Usually manages Linux configurations.

Puppet has a client-server architecture (periodically polls the server to make changes to the configuration made by the network administrator), is written in Ruby and has a Ruby-like DSL. This application allows you to centrally manage the configuration of software installed on multiple computers.

The article compares the advantages and disadvantages of these SCMs.



Compared with the 90s, nowadays system administrators and developers have to manage a significantly larger number of servers that host a lot more applications. The reason for this is the exponential growth of computing for organizations and companies associated with the advent of new technologies such as virtualization and cloud computing.

Thus, tools such as Puppet and Ansible quickly become necessary components of managing a large number of servers, for example, in data centers. They are called Configuration Management Tools (CM) and Remote Execution (RE) and are often used with software update tools. These useful applications allow, for example, a network administrator to perform actions on several servers at the same time, deploy several applications with one click, which greatly simplifies the configuration and maintenance of tens, hundreds or even thousands of servers.

Ansible vs. Puppet: A Brief Review


Puppet is one of the most famous brands in the CM market. It exists since 2005, which for CM tools is tantamount to existence since the inception of mankind. Many big names such as Google, Reddit, Dell, PayPal, Oracle, Los Alamos Labs, and Stanford University manage their data centers with Puppet. Having such customers on board always gives the product a certain level of confidence. Puppet also boasts the most mature interface and work on all major operating systems - Linux, Windows, Unix and even Mac OS X. Following the model created by various versions of Linux, this open source application is developed in Ruby. However, there is a solid, well-established PuppetLabs support and sponsorship company,offering professional support and a commercial corporate version of the software.

Puppet also offers a simple installation procedure and several tools for tasks such as rapid deployment to client servers. In addition to the GUI, there is a Ruby-based CLI. In fact, for most advanced tasks, you most likely will have to depend on the CLI, and the GUI is the interface for viewing, managing and monitoring. This means that in addition to working as a system administrator, you will need to learn Ruby.



You might think: “It all sounds great! Are there any downsides, or is it worth going and buying Puppet right now? ”.. The debate about using this SCM on specialized CM forums is that Puppet, like many other software giants, has been a victim of its own success and size. “Nimble” and “agile” are not words that can be used to describe Puppet's work. Users report bugs that take too long to fix and ignore new requests. There is also some dissatisfaction with the fact that PuppetLabs is persistently pushing its customers to accept the commercial version. Finally, although Puppet supports both pure Ruby and its configured DSL on the CLI, support for Ruby alone is deprecated. This is bad news for those who only studied Ruby, not DSL.

Ansible bypassed Puppet, capturing the largest market share in the configuration management industry - 26.5%. It is followed by Microsoft System Center CM (21.8%) and Puppet (12%).



It is also an open source product that was released in 2012 and has since been supported by AnsibleWorks. It was developed in Python rather than Ruby, which makes it spiritually closer to Salt (another new CM tool) than Puppet. Another advantage of Python is that it is built into most Unix and Linux applications, so SCM written in this language installs and works faster.

Ansible's unique marketing ploy lies in its easy and quick deployment. In fact, this system does not even use deployed agents to communicate with the master client; instead, all functions are performed through SSH. For those configurations that do not support root SSH, Ansible can run “sudo” as root. Ansible can be launched from the CLI without using configuration files for simple tasks, such as checking the operation of the service or starting updates and reboots. For more complex tasks, Ansible configuration is handled using YAML syntax in configuration files called “playbooks”. Ansible commands can be written in almost any programming language and distributed as universal JSON modules, which is clearly an advantage over the choice of one specific language.

Ansible has become more popular with a new approach to traditional configuration tasks, and many companies use it to deploy large data centers.

The Ansible community of enthusiasts is working hard to build on its success by increasing the number of supported devices, integrating better Windows support, improving the ecosystem, and so on.

Ansible vs. Puppet: Installation Difference


The differences between Ansible or Puppet become apparent from the moment the systems are installed. Since they follow different architectural paradigms, their setting is significantly different. So, Ansible has the explicit goal of making the setup process as simple as possible, which is reflected in the user experience.



To configure Ansible, you first need to designate one node as the control node. In fact, any of your nodes can be a management node. You can install Ansible on this node using the latest Ansible package from the package repositories of your distribution, with no need to configure client software on other nodes. Just create an SSH key pair on your management node, and then copy them to the other nodes. Next, create an inventory file for Ansible nodes - usually on Linux OSs like Red Hat Linux, Ubuntu, and Debian this happens in / etc / ansible / hosts. You are now ready to use Ansible to launch the PlayBook on both your host and the rest of the network infrastructure.Ansible will use SSH connections with your control node to trigger PlayBook-based configuration management.

Setting up Puppet looks a little more complicated, but there is a lot of documentation on the Internet that will help in a difficult case. First, you will need to configure the master and agent nodes so that they have the same time and time zone. Then you need to go to the master server with root privileges and install the Puppet server software. Next, you need to configure the Puppet wizard file / etc / hosts to connect all managed clients, start the PuppetServer service and put it in “enable” mode to receive client connections on port 8140. Since Puppet relies on client software, you will need to install Puppet software agents on each of them.

In addition, you will need to add the IP address of the master server in / etc / hosts so that the client can connect to it. To do this, you must start and enable the Puppet agent service on each client, and then generate SSL certificates, since this CM system uses HTTPS for master client communication.

In both cases, it will be necessary to strengthen the security of the server to exclude the possibility of unauthorized connections.

Ansible vs. Puppet: scalability and configuration transport mechanism


Both SCMs scale well, but use different configuration transport mechanisms to achieve this. In fact, regardless of whether you need to manage several hundred or tens of thousands of nodes, there are tricks and strategies that you can use on each platform to conveniently scale to the desired level.



Ansible uses the smart transport mechanism by default, which is based on trusted SSH certificates. Ansible will first analyze PlayBooks and identify affected infrastructure elements. She will then open an SSH connection and create a temporary directory. After closing this connection, Ansible opens a second connection to copy over the Ansible module code and Ansible template code. Ansible will close this connection before opening the third, final connection to execute the code. This setting will serve most purposes, but it can be changed as the infrastructure scales.

The first function that Ansible can use is called ControlPersist, and it relies on persistent, persistent sockets to reduce the time it takes to exchange handshakes that are needed for multiple connections. Ansible also supports pipelining, a configuration that reduces the number of connections required from three to one. Finally, Ansible can be configured to handle more inventory nodes at the same time by setting up the forks variable in the configuration of this system. By default, this value is 5, but you can set a higher value to speed up processing.



The Puppet transport mechanism is HTTPS, which is managed using SSL certificates. One Puppet server handles configuration requests for an entire list of Puppet clients. Each client sends Puppet facts to the master server along with a request to the Puppet directory, after which the master server sends this directory in response. The client then processes the directory, checking each software resource with the required configuration state specified in the directory. If the resource is not in the desired state, the Puppet client will update the resource on this computer and, after the update is completed, will send a report on the completed configuration change to the Puppet server.



Notably, the Puppet processing model allocates a JRuby thread from the thread pool to handle each incoming client connection. As the number of nodes increases, Puppet scaling can be optimized by increasing the number of JRuby threads available in the pool. This can be done by setting the Puppet “max-active-instances” configuration parameter higher than the default value, which is 1. As a rule, this value is assumed to be equal to the number of processor cores of your computer, but keep in mind that this will require more CPU memory used RAM RAM. As a general rule, you will also need to set a higher “maximum heap size” for the JVM of your Puppet server to ensurethat your additional JRuby threads can be allocated without a Java out of memory error. Caution is required when making this setting, as this may result in loss of performance.

CM Ansible Code Example


For everyday configuration work, writing Ansible code is surprisingly simple due to a combination of two factors: the use of the YAML format for PlayBooks and the declarative style of configuration management that cuts off “sharp corners”. This is important to quickly improve the performance of DevOps commands and ensure that your code is manageable even for complex configuration tasks.

Ansible code is idempotent. This means that you can safely run PlayBook for system components again and again without messing up your servers. Ansible will only change the configuration of software resources on servers where it is outside the desired state. For example, if your PlayBook needs to install a package and create a specific configuration file on disk, Ansible will install only that package and create the configuration file that was specified when the PlayBook was first launched on the host. Subsequent launches of the PlayBook automatically leave the package intact until there is any change that removes or modifies the specified file or package configuration. This keeps your nodes in a predictable, deterministic state with very little or no chance of configuration drift.

The following is an example Ansible PlayBook code that installs the Tomcat web server on your sites. This example is taken from the official Ansible examples repository , which you should look through to better familiarize yourself with the Ansible idiomatic style:

---
- name: Install Java 1.7
yum: name=java-1.7.0-openjdk state=present

- name: add group "tomcat"
group: name=tomcat

- name: add user "tomcat"
user: name=tomcat group=tomcat home=/usr/share/tomcat createhome=no
become: True
become_method: sudo

- name: Download Tomcat
get_url: url=http://archive.apache.org/dist/tomcat/tomcat-7/v7.0.61/bin/apache-tomcat-7.0.61.tar.gz dest=/opt/apache-tomcat-7.0.61.tar.gz

- name: Extract archive
command: chdir=/usr/share /bin/tar xvf /opt/apache-tomcat-7.0.61.tar.gz -C /opt/ creates=/opt/apache-tomcat-7.0.61

- name: Symlink install directory
file: src=/opt/apache-tomcat-7.0.61 path=/usr/share/tomcat state=link

- name: Change ownership of Tomcat installation
file: path=/usr/share/tomcat/ owner=tomcat group=tomcat state=directory recurse=yes

- name: Configure Tomcat server
template: src=server.xml dest=/usr/share/tomcat/conf/
notify: restart tomcat

- name: Configure Tomcat users
template: src=tomcat-users.xml dest=/usr/share/tomcat/conf/
notify: restart tomcat

- name: Install Tomcat init script
copy: src=tomcat-initscript.sh dest=/etc/init.d/tomcat mode=0755

- name: Start Tomcat
service: name=tomcat state=started enabled=yes

- name: deploy iptables rules
template: src=iptables-save dest=/etc/sysconfig/iptables
when: "ansible_os_family == 'RedHat' and ansible_distribution_major_version == '6'"
notify: restart iptables

- name: insert firewalld rule for tomcat http port
firewalld: port=/tcp permanent=true state=enabled immediate=yes
when: "ansible_os_family == 'RedHat' and ansible_distribution_major_version == '7'"

- name: insert firewalld rule for tomcat https port
firewalld: port=/tcp permanent=true state=enabled immediate=yes
when: "ansible_os_family == 'RedHat' and ansible_distribution_major_version == '7'"

- name: wait for tomcat to start
wait_for: port=

This specific Ansible task downloads and installs Apache Tomcat along with the dependent Java JDK 1.7, and then configures, starts, and installs Tomcat. As you can see from this example, Ansible-driven files can contain Jinja templates, which simplifies the calculation of values ​​and makes your configuration more flexible. YAML code is easy to read and write for both system administrators and developers. This leads to the fact that Ansible is becoming an affordable configuration management system for both advanced and novice users.

CM Puppet Code Example


The subject-oriented language Puppet is based on Ruby, but its syntax is much closer to imperative C-style languages ​​like Perl, Java, and C ++. This approach is an intermediary between developers familiar with Ruby and those who may not be familiar with this language. As a result, you may not need to know Ruby at all to learn and use Puppet DSL productively.
This is an example of a Puppet manifest from the PuppetLabs MySQL Puppet Module repository that installs and configures the MySQL client package:

# @summary
#     Installs and configures the MySQL client.
#
# @example Install the MySQL client
#     class {'::mysql::client':
#         package_name => 'mysql-client',
#         package_ensure => 'present',
#         bindings_enable => true,
#     }
#
# @param bindings_enable
#     Whether to automatically install all bindings. Valid values are `true`, `false`. Default to `false`.
# @param install_options
#     Array of install options for managed package resources. You must pass the appropriate options for the package manager.
# @param package_ensure
#     Whether the MySQL package should be present, absent, or a specific version. Valid values are 'present', 'absent', or 'x.y.z'.
# @param package_manage
#     Whether to manage the MySQL client package. Defaults to `true`.
# @param package_name
#     The name of the MySQL client package to install.
#
class mysql::client (
    $bindings_enable = $mysql::params::bindings_enable,
    $install_options = undef,
    $package_ensure = $mysql::params::client_package_ensure,
    $package_manage = $mysql::params::client_package_manage,
    $package_name = $mysql::params::client_package_name,
)  inherits mysql::params {
    
    include '::mysql::client::install'

    if $bindings_enable {
        class { 'mysql::bindings':
            java_enable => true,
            perl_enable => true,
            php_enable => true,
            python_enable => true,
            ruby_enable => true,
        }
    }

# Anchor pattern workaround to avoid resources of mysql::client::install to
# "float off" outside mysql::client
anchor { 'mysql::client::start': }
-> Class['mysql::client::install']
-> anchor { 'mysql::client::end': }
}

An important advantage of Puppet is that, unlike the imperative programming languages ​​listed above, Puppet DSL is declarative, in some ways similar to XML, as well as the YAML code from the Ansible code example above. The declarative approach of both Puppet and Ansible is really traced in both code examples. In terms of coding, they are similar and closer to each other than tools like Chef. However, the declarative language Puppet also provides Ruby-like constructs such as conditional expressions and iterations, which again is a compromise for Ruby users and those who do not speak the language.

Ansible vs. Puppet: Ease of Use


For the development team, ease of use should be an important part of evaluating SCM. Given that Ansible developers are focusing a lot of effort on the ease of use of the system, there are no competitors in this. Configuring, programming, and managing the nodes provides a very simple interface to both development engineers and system administrators.

This does not mean that Puppet is difficult to use, it’s just that this system behaves confidently while you follow the proposed method of automation of its infrastructure. In this area, Puppet is pretty strong, explicitly modeling each resource and providing users with modules with standard behavior that are efficiently used in your manifests.

In terms of user learning, both platforms are easy to use, but Ansible has a slight advantage. It's easy to achieve a declarative YAML style, so Ansible code is never too complicated. Meanwhile, Puppet has come to recognize some of the problems associated with combining data and code in the same source files. This led to the advent of Puppet Hiera, a storage solution that uses the YAML format to store key-value pairs of configuration data. Hiera goes a long way towards simplifying and optimizing the Puppet DevOps experience. The YAML format has proven to be quite popular for configuration management, with Salt from SaltStack also using this format.
Both SCMs have the ability to validate and test your CM, from syntax checking to integration of infrastructure-as-code.

Ansible vs. Puppet: licensing and implementation costs





As open source tools, Ansible and Puppet have much in common in their licensing policies.

Ansible's open source release is completely free. Companies that need more guarantees of security, stability and reliability are encouraged to upgrade to Ansible Engine, the enterprise-class product that ships with Red Hat Linux. Ansible Engine license costs typically range from $ 47.50 to $ 70 per year per node and depend on your preferred configuration.

If you need technical support with quick troubleshooting, you should use the corporate version. The Ansible Tower Large Enterprise Management Tool is available as a service package and provides your company with more training, management, and job scheduling capabilities through a graphical control panel.

Like Ansible, the open source Puppet release is available for free. For additional corporate features and technical support, organizations can upgrade to Puppet Enterprise, which costs from $ 112 to $ 199 per year per node. Puppet Enterprise offers a package of several tools, including reporting and monitoring the status of the enterprise infrastructure.

Ansible vs Puppet: Community


Puppet, released in 2005, is an older DevOps tool, so it had more time to create its own community and user base. Nevertheless, Ansible, launched in 2012, thanks to its new approach, was able to attract an even larger audience and create a very dynamic community of developer enthusiasts and users. Puppet users include companies such as Uber, Salesforce, and Paypal, while the Ansible community includes companies such as Digital Ocean, 9GAG, and TypeForm.

If we compare such an important indicator of the development of open source products as the number of contributors participating in the development on GitHub, Ansible with more than 4,800 contributors is far superior to Puppet with its 527 contributors to the development of the product. The development of Ansible in recent years has been so fast that it has spawned the creation of a separate "galactic" repository of Ansible Galaxy . This means that the Ansible community strives to share its code, thereby contributing to the further development of the product.

Meanwhile, the Puppet community, which is developing more slowly and steadily, has created an infrastructure to make it easier to find solutions to meet your SCM needs. Puppet Forge provides modules for common configuration management tasks for the Puppet community.

Both systems have first-class tools for monitoring the life cycle of a configuration management project through the command line. Both Puppet and Ansible integrate well with other widely used DevOps systems such as Docker, Kubernetes and Jenkins, and AWS and Azure cloud computing platforms.

Ansible vs Puppet: which is better?


In this matter, the choice is yours. The declarative style of both Ansible and Puppet means that these tools have much more in common than other configuration management systems. However, to make the best choice, you need to pay special attention to how the needs of your team are combined with the design and advantages of a particular SCM.
Ansible is better suited for those who are interested in YAML-style configuration and share Ansible's philosophy of being as simple as possible while managing a large pool of machines quickly and simultaneously. In addition, this philosophy focuses on using existing SSH functions instead of creating user agents.

Puppet is more suitable for teams that prefer DSL, which models system resources in a consistent, repetitive manner. This is exactly what Puppet DSL does, along with a whole ecosystem of tools to make large teams predictable and easy.

If you know exactly which configuration management principles best suit your needs, choosing between Puppet and Ansible will not be a problem for you.

findings


To facilitate your choice, we suggest that you familiarize yourself with the main advantages and disadvantages of both systems.



A bit of advertising :)


Thank you for staying with us. Do you like our articles? Want to see more interesting materials? Support us by placing an order or recommending to your friends, cloud VPS for developers from $ 4.99 , a unique analog of entry-level servers that was invented by us for you: The whole truth about VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps from $ 19 or how to divide the server? (options are available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).

Dell R730xd 2 times cheaper at the Equinix Tier IV data center in Amsterdam? Only we have 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV from $ 199 in the Netherlands!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - from $ 99! Read about How to Build Infrastructure Bldg. class c using Dell R730xd E5-2650 v4 servers costing 9,000 euros for a penny?

All Articles