The latest cloud infrastructure announcements, technical solutions, and enterprise cloud insights.

Latest Updates on Oracle Ansible Modules and Comparison with Terraform

Gaurav Jain
Product Lead, Developer Experience

Today, we’re giving you two more reasons to use Ansible to manage your Oracle Cloud resources:

Ansible and Ansible Modules

Ansible is an Infrastructure-as-code automation tool that provides an easy way to provision and configure your infrastructure resources. Ansible modules are a discrete unit of code made available by providers such as Oracle. You can execute these modules from the command line or in a playbook task on the target node to make the desired provider-specific infrastructure changes.   

Should I Use Ansible? Or Should I use Terraform? 

The answer is... Yes. On a serious note, let's first compare these two tools.

  Ansible Terraform
Type Primarily configuration management but can do orchestration too Orchestration
Infrastructure Mutable Immutable
Language Procedural Declarative
State Management No Yes



Terraform is a powerful infrastructure orchestration tool (and arguably the most popular one today) but as Hashicorp puts it: "Terraform is not a configuration management tool." On the other hand, Ansible is primarily as a configuration management tool with some orchestration capabilities.  


In a mutable infrastructure, you update and modify your existing infrastructure to make the desired change. In the popular Pets vs Cattle analogy, these infrastructure components are your pets. You live with them, name them ,and watch them grow up. 

In an immutable infrastructure paradigm, you never modify the existing infrastructure. To make a change, you tear them down and create a new set of infrastructure. They are your cattle. If you don't like the way they are, you simply replace them with the other ones.  


Terraform follows a declarative language while Ansible modules follow procedural language. To explain the difference, let's assume you want a total of 10 compute instances. In the case of Terraform, you will declare a final count of compute (10) and it will take care of the outcome. If you initially had five instances, Terraform  creates an additional five instances. But if you had 15 instances, it destroys five. 

With Ansible, you define the exact number of instances to be created. So if you want to have 10 instances, you first query the current instance count and then ask for the desired number of new instances.   

State Management

Terraform stores the state of your environment in a state file while Ansible does not have the equivalent concept. Instead, you use the inventory feature to get the real-time status of your environment.    

The tools have the following characteristics in common:

  • They're both open source.

  • They have strong community participation and popularity.

  • Neither follows the primary-replica architecture, reducing the pain related to managing the management tool.

Coming back to the original question of which tool to select, the answer depends! We ask our customers to assess their requirements and pick the right tool based on their need and skill-set. Broadly, we have observed two types of user segments.

The first type of customer uses both the tools together for their respective strengths. They provision the infrastructure using Terraform and then leverage the Ansible Inventory feature to manage the configuration.

The second type of customer prefers to use only Ansible for one or more of the following reasons:

  • They want to use a single tool for configuration and orchestration to minimize complexity.
  • Ansible is Python-based.
  • They don't want to manage the state file.

On the topic of selecting the right tool, you may also consider, Resource Manager, our managed Terraform-as-a-service. In addition to the state-management benefit, it provides additional benefits such as native integration with other Oracle cloud service, drift detection, and resource discovery.

What is New with Oracle Ansible Modules?

Glad you asked! We are announcing two useful user benefits. 

Ansible Support for All Oracle Cloud Resources

We enabled Ansible support for Oracle Cloud two years ago. Since then Ansible usage among Oracle customers has grown gradually and significantly. This growth mirrors the broader market trend where Ansible has become the most preferred configuration management tool. Until now, we provided support for only a selected set of Oracle Cloud resources, but you asked for more, and we heard you!

You can now manage all your Oracle Cloud resources using Ansible. Support is available for all the Oracle Cloud services and features released by June 2020. We’re continuing to add support for more services and features as they’re released.

Ansible Collection is Generally Available

Last year, Ansible released Collections as part of the Ansible 2.9 release. Ansible Collection is an easy way to provision and manage resources in Oracle Cloud. Today, we’re announcing the availability of Oracle Cloud Infrastructure Ansible Collection. With this launch, you can install and manage Collection much more easily. The new collection also address other challenges such as difficulty in code sharing for many plugins and plugin/role name collisions. 

The Oracle Cloud Ansible Collection replaces the legacy Oracle Cloud Ansible modules.

Deprecation of Legacy Modules

With the release of the new collection, the legacy Oracle Cloud Ansible modules are available only in the maintenance mode. We’re not adding support for new features. Also, we’re fixing only critical bugs. Beyond mid-2021, the legacy modules deprecate. If you transition from the legacy modules to the new collection modules, expect a few breaking changes. Refer to the Migration Guide as you plan to migrate.


You can install the Oracle cloud collection from Ansible Galaxy using the following command:

$ ansible-galaxy collection install oracle.oci

Collection is supported in Ansible 2.9+. To update the modules to the latest version, use the install --force flag.

For the detailed instructions, see Getting Started with Oracle Cloud Infrastructure and Ansible


Join the discussion

Comments ( 1 )
  • Michael Glasgow Wednesday, September 2, 2020
    This article seems to claim that Ansible's configuration language is inherently procedural. On the contrary, the language itself is declarative, and best practice docs always encourage playbook authors to "think declaratively".

    What is true is that it does not enforce a declarative paradigm. There are modules such as "shell" and "command" which can be abused to invoke arbitrary and non-idempotent commands, with all the deleterious effects on maintainability intact. And when writing your own custom modules, it's trivial to design the interface in a procedural way since Ansible lets you pass any data you want. Basically, it gives you enough rope to hang yourself.

    But that's a different claim from the one that the configuration language is inherently procedural. In what way is this not declarative:

    name: chrony
    enabled: yes
    state: started

    I think the intent here is to convey that this particular Ansible module suite has a procedural interface when creating new resources, because Ansible lacks Terraform features such as state tracking which simplify the declarative specification of new virtual resources.
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha