Ansible in GCP

Ansible in GCP

25 May 2022

Ansible-in-GCP-image2-1024x576

Ansible, by Red Hat, is a simple automation language that can perfectly describe an IT application infrastructure on GCP including virtual machines, disks, network load-balancers, firewall rules & more. Since 2012, Ansible has been run by Red Hat Inc.. It’s an open-source project with a core configuration management tool. However, a few commercial extensions are also available like Ansible Tower.

Ansible + Google have been working together on a set of auto-generated Ansible modules designed to cover the entirety of the Google Cloud Platform (GCP) consistently & comprehensively. Approximately twice a year, Ansible releases a new major release. The core application evolves conservatively, valuing simplicity in language design and setup.

What is Ansible?

Ansible is an open-source platform used for automation and for various operations such as configuration management, application deployment, task automation & IT orchestration. Ansible is easy to set up & it is efficient, reliable & powerful. It runs on Linux, Mac, or BSD. It has an enterprise edition called Ansible Tower, apart from the free version.

Ansible’s architecture is agentless & serverless, and it supports modules for managing Windows and UNIX-like hosts. For conducting the configuration tasks, It depends on SSH/PowerShell sessions.

Why must one go for Ansible?

Ansible-in-GCP-image3

Ansible is an IT automation tool. It can configure systems, deploy software & orchestrate more advanced IT tasks such as continuous deployments or zero downtime rolling updates.

Ansible’s main goals are simplicity & ease-of-use. It also has a strong focus on security & reliability, featuring a minimum of moving parts, usage of OpenSSH for transport (with other transports & pull modes as alternatives) & a language that is designed around auditability by humans–even those not familiar with the program.

Ansible manages machines in an agent-less manner. As daemons are uninstalled, there is never a question of how to upgrade remote daemons or the problem of not being able to manage systems. Since OpenSSH is one of the most peer-reviewed open source components, security exposure is greatly reduced. Ansible is decentralized–it relies on the existing OS credentials to control access to remote machines. If needed, Ansible can easily connect with Kerberos, LDAP & other centralized authentication management systems.

Top 4 Features of Ansible

Ansible-in-GCP-image5-1024x278

  1. Agentless: This is the biggest advantage of Ansible. Being agentless diminishes the efforts involved in installing & managing an agent.
  2. Re-entrant: This is a most important & notable feature added in Ansible, which lessens the effort that goes into script re-entrant. Just need to re-run Ansible & the problem gets fixed!
  3. Infrastructure as Code: It acts as a single tool for all DevOps tasks as it defines the infrastructure in the Ansible playbook & commits to source control.
  4. It’s a lightweight tool preferable for quick deployment abilities. Moreover, it is user-friendly, to begin with. The complete management of the servers can be performed with just a little configuration.

7 Basic Ansible Concepts

Ansible-in-GCP-image1

These concepts are common to all use cases of Ansible. It’s important to understand them to use Ansible for any kind of automation. This basic introduction provides the background only.

  1. Control nodes:
    Any machine with Ansible installed can execute Ansible commands & playbooks by invoking the ansible or ansible-playbook command from any control nodes. Any computer that has a Python installation can be used as the control nodes – laptops, shared desktops, and servers can all run Ansible. However, Windows machines cannot be used as the control nodes. It’s possible to have multiple control nodes too.
  2. Managed nodes:
    These are the network devices (and/or servers) that can be managed with Ansible. Managed nodes are also sometimes called “hosts”. On managed nodes, Ansible is not installed.
  3. Inventory:
    A list of managed nodes. A “host file” is also called as an inventory file. The inventory can also specify information like IP address for each managed node. An inventory can also organize managed nodes, creating & nesting groups for easier scaling.
  4. Collections:
    Collections are a distribution format for Ansible content that can include playbooks, roles, modules & plugins. One can install & use collections through Ansible Galaxy.
  5. Modules: The units of code Ansible executes. From administering users on a specific type of database, each module has a particular use to managing VLAN interfaces on a specific type of network device. One can invoke several different modules in a playbook or a single module with a task. Modules are grouped in collections, starting in Ansible 2.10.
  6. Tasks: The units of action in Ansible. With an ad hoc command, one can execute a single task.
  7. Playbooks: Ordered lists of tasks, saved so that one can run those tasks in that order repeatedly. Playbooks can include tasks as well as variables. Playbooks are written in YAML & are easy to read, write, share and understand.

Ansible vs Terraform: Key Differences & Comparison of Tools

Ansible-in-GCP-image6-1024x624

Both Ansible & Terraform are DevOps tools, but how do these DevOps tools differ? Shortly, Terraform is an open-source, Infrastructure as Code platform, however, Ansible is an open-source configuration management tool focused on the configuration of that infrastructure.

It is often a topic of discussion about whether one should use Ansible or Terraform for infrastructure management. Fortunately, there is an answer that lies in the gray area.

Similarities

At a very high level, given the capabilities of both the products, Ansible & Terraform come across as similar tools. Both of them are capable of provisioning the new cloud infrastructure & configuring the same with required application components.

Both Ansible & Terraform are capable of executing remote commands on the virtual machine that is newly created. This means, both the tools are agentless. It’s not required to deploy agents on the machines for operational purposes.

Cloud provider APIs are used by Terraform to create infrastructure and basic configuration tasks are achieved using SSH. The same goes with Ansible too – it uses SSH to perform all the required configuration tasks. The “state” information for both of these does not require a separate set of infrastructure to manage, thus are masterless.

Differences

The broadest similarities of the two tools were mentioned in the previous section. It sounds like both Ansible & Terraform are capable of provisioning and configuration management, at a high level. A deeper dive into them, however, makes us realize the benefits of one over the other in certain areas.

Both the tools are great in their own ways, in general. When it comes to infrastructure management, they both have an overlap of functions. Infrastructure management broadly encompasses 2 aspects – orchestration & configuration management.

Ansible & Terraform have their own ways of managing both – with strong and weak points when it comes to overlaps. Hence, it is important to delve into some details of both the tools to make a “perfect” choice or a combination with boundaries.

Conclusion

Ansible-in-GCP-image4

The Ansible open source community is one of the vibrant, fast-moving places that strives to get things done. While Google thrives in open source, it also understands the reliability needs of its users to safely run their infrastructure. Google Engineering actively builds Ansible modules, contributes code and documentation & helps users deliver their solutions with GCP.

Till now, Terraform works best with orchestration & Ansible is great at configuration management and it’s idempotent.

Of course, they do have the capabilities to perform each other’s tasks, although in a limited manner. In such a situation, rather than making a firm choice, it is better to leverage both tools for infrastructure management, based on their respective strengths.

The answer for the question “which tool to use?” is – it depends. It depends entirely on how the infrastructure management process is currently shaped. It is important to find the right balance of orchestration & configuration management to assign clear responsibilities to the respective tools.

Request a quote