For a long time, IT operation and maintenance has been a labor-intensive matter within the enterprise. With the continuous popularization of a large number of virtualized applications, private clouds, and containers, the pressure inside the
data center is increasing. Traditional automation tools are often oriented to a specific type of objects in the data center, such as operating systems, virtualization, and network equipment. The automated operation and maintenance tools are often different. So, is there a unified automated operation and maintenance tool at the data center level?
The answer is Ansible. Compared with traditional automation tools (such as Puppet), Ansible has obvious advantages:
Simple, is a high-level scripting language, not a standard language.
There is no need to install an agent, which is divided into management nodes and remote managed nodes through SSH authentication.
The management range is wide, not only the operating system, but also all kinds of virtualization, public cloud, and even network equipment.
Next, this article will introduce Ansible, an open source IT automation operation and maintenance tool, and let you understand the actual role of Ansible through experimental scenarios.
Introduction to Ansible
Ansible is a simple IT automation engine. Recently, Ansible is a very popular open source project on Github, you can see the number of Star, Fork, and commits for the project below.
So, which
data center objects can Ansible manage (manage)? By looking at Ansible's modules (Modules, which will be described in detail later), we can see that it supports almost all automation of data centers, including (not limited to):
Operating system level: From Linux (physical machine, virtual machine, cloud environment), Unix, to Windows.
Virtualization platforms: VMware, Docker, Cloudstack, LXC, Openstack, etc.
Commercial hardware: management of F5, ASA, Citrix, Eos and various server equipment.
System application layer: Apache, Zabbix, RabbitMQ, SVN, GIT, etc.
Red Hat solutions: Openshift, Ceph, GlusterFS, etc., support one-click deployment and configuration of almost all Red Hat solutions.
Cloud platforms: IBM Cloud, AWS, Azure, Cloudflare, Red Hat CloudForms, Google, Linode, Digital Ocean, etc.
Next, let's take a look at the related components of Ansible and see how it manages the objects in the
data center.
Ansible components
The core components of Ansible include: Modules, Inventory, Playbook, Roles and Plugins.
Modules
When we write Shell on Linux, we need to call Linux operating system commands, such as ls, mv, chmod, etc .; when writing POJO, we need to call Java related patterns. Linux system commands are called modules for Shell and Java Pattern for POJO. Modules are modules that are called when using Ansible for automated tasks. While working, Ansible first connects (by default, via SSH) to the managed nodes (may be servers, public clouds, or network devices, etc.), then pushes Modules to these nodes, executes these Modules, and deletes Modules after completion.
Modules are Ansible's core assets. With Modules, we can call these Modules to complete the automation tasks we want to perform. For example: selinux-Change policy and state of SELinux. The role of this Module is to configure SELinux mode and strategy. We can configure RHEL / CentOS SELinux mode (eforcing, permissive or disabled) by calling this module. The number of Modules in the community is very large, the coverage is very wide, and it is growing at a rapid rate.
Inventory
Inventory is the list of objects that Ansible wants to manage. In the list, you can also configure grouping information, etc.
Let's say that Modules are the modules that we call when we use Ansible for automated tasks. Then Playbook is the script (YAML format) of Ansible automated tasks.
Roles
Roles is the main mechanism for dividing Playbook into multiple files. This simplifies writing complex Playbooks and makes them easier to reuse. Roles can decompose Playbook into reusable components.
Plugins
Plugins are codes that enhance the core functions of Ansible. Ansible comes with many convenient plug-ins, if these plug-ins are not enough, we can write our own plug-ins.
Plugins and Modules work together to perform the actions of the automated tasks required by the Playbook task. When we use Modules, if we need to call Plugins, Action Plugins will be automatically executed by default.
Examples of Selinux Module mentioned above. Writing the Playbook is to call Selinux Modules to complete the configuration of the RHEL / CentOS SElinux mode, which is an action. This requires Selinux Modules to call Action Plugins together.
Plugins have many roles. For example, the role of Cache Plugins is to implement a back-end caching mechanism, allowing Ansible to store the collected inventory source data.
