I have previously written about the configuration of the Ansible Dynamic Inventory for OCI. The aforementioned article focused on Debian, and I promised an update for Oracle Linux 7. You are reading it now.
The biggest difference between the older post and this one is the ability to use YUM in Oracle Linux 7. Rather than manually installing Ansible, the Python SDK and the OCI collection from Ansible Galaxy you can make use of the package management built into Oracle Linux 7 and Oracle-provided packages.
Warning about the software repositories
All the packages referred to later in the article are either provided by Oracle’s Extra Packages for Enterprise Linux (EPEL) repository or the development repo. Both repositories are listed in a section labelled “Packages for Test and Development“ in Oracle’s yum server. As per https://yum.oracle.com/oracle-linux-7.html, these packages come with the following warning:
Note: The contents in the following repositories are for development purposes only. Oracle suggests these not be used in production.
This is really important! Please make sure you understand the implications for your organisation. If this caveat is a show-stopper for you, please refer to the manual installation of the tools in my earlier article for an alternative approach.
I’m ok with the restriction as it’s my lab anyway, with myself as the only user. No one else to blame if things go wrong :)
Installing the software
You need to install a few packages from Oracle’s development repositories if you accept the warning quoted above. The first step is to enable the necessary repositories:
sudo yum-config-manager --enable ol7_developer_EPEL sudo yum-config-manager --enable ol7_developer
Once that’s done you can install the OCI Ansible Collection. This package pulls all the other RPMs I need as dependencies. The following output was generated on March 16, 2023:
[opc@dynInv ~]$ sudo yum install oci-ansible-collection ... --> Finished Dependency Resolution Dependencies Resolved ==================================================================================================== Package Arch Version Repository Size ==================================================================================================== Installing: oci-ansible-collection x86_64 4.15.0-1.el7 ol7_developer 19 M Installing for dependencies: ansible-python3 noarch 2.9.27-1.el7 ol7_developer_EPEL 16 M python3-jmespath noarch 0.10.0-1.el7 ol7_addons 42 k python36-jinja2 noarch 2.11.1-1.el7 ol7_developer_EPEL 237 k python36-markupsafe x86_64 0.23-3.0.1.el7 ol7_developer_EPEL 32 k python36-paramiko noarch 2.1.1-0.10.el7 ol7_developer_EPEL 272 k python36-pyasn1 noarch 0.4.7-1.el7 ol7_developer 173 k python36-pyyaml x86_64 5.4.1-1.0.1.el7 ol7_addons 205 k sshpass x86_64 1.06-1.el7 ol7_developer_EPEL 21 k Updating for dependencies: python36-oci-sdk x86_64 2.93.1-1.el7 ol7_addons 26 M Transaction Summary ==================================================================================================== Install 1 Package (+8 Dependent packages) Upgrade ( 1 Dependent package) Total download size: 62 M Is this ok [y/d/N]:
Once all packages are installed you should be in the position to test the configuration. The article assumes the OCI Python SDK is already configured. If not, head over to the documentation for instructions on how to do so.
Verifying the installation
Out of habit I run ansible --version once the software is installed to make sure everything works as expected. Right after the installation I tried, but I noticed that Ansible seemingly wasn’t present:
[opc@dyninv ~]$ which ansible /usr/bin/which: no ansible in (/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/opc/.local/bin:/home/opc/bin)
It is present though, and it took me a minute to understand the way Oracle packaged Ansible: Ansible/Python3 is found in ansible-python3 instead of ansible. A quick check of the package’s contents revealed that a suffix was added, for example:
[opc@dyninv ~]$ ansible-3 --version ansible-3 2.9.27 config file = /etc/ansible/ansible.cfg configured module search path = ['/home/opc/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules'] ansible python module location = /usr/lib/python3.6/site-packages/ansible executable location = /usr/bin/ansible-3 python version = 3.6.8 (default, Nov 18 2021, 10:07:16) [GCC 4.8.5 20150623 (Red Hat 4.8.5-44.0.3)] [opc@dyninv ~]$
An important detail can be found in the last line: the python version is reported to be 3.6.8, at least at it was at the time of writing.
Testing the Dynamic Inventory
Before going into details about the dynamic inventory, first I’d like to repeat a warning I had in my older post as well:
Remember that the use of the Dynamic Inventory plugin is a great time saver, but comes with a risk. If you aren’t careful, you can end up running playbooks against far too many hosts. Clever Identity and Access Management (IAM) and the use of filters in the inventory are a must to prevent accidents. And don’t ever use hosts: all in your playbooks! Principle of least privilege is key.
Ansible configuration
With the hard work completed and out of the way it’s time to test the dynamic inventory. First of all I need to tell Ansible to enable the Oracle collection. I’m doing this in ~/.ansible.cfg:
[opc@dyninv ansible]$ cat ~/.ansible.cfg [defaults] stdout_callback = debug [inventory] enable_plugins = oracle.oci.oci
Be careful though as this is the user’s global setting! A safer way is to include the configuration file in the repository where it is supposed to be used. This way no other project is affected. Since this is a new VM it doesn’t matter for me and I want to use the new host as one of the main provisioning systems anyway – every Ansible playbook to be run from here requires the dynamic inventory.
The next file to be created is the dynamic inventory file. It needs to be named following the Ansible convention:
filename.oci.yml filename.oci.yaml
You are only allowed to change the first part (“filename”) or else you get an error. The example file contains the following lines, limiting the output to a particular compartment and set of tags, following my own advice from above.
plugin: oracle.oci.oci
regions:
- eu-frankfurt-1
compartments:
- compartment_ocid: "ocid1.compartment.oc1..aaaa..."
fetch_hosts_from_subcompartments: false
hostname_format: fqdn
filters:
- defined_tags:
project:
name: "simple-app"
debug: False
The filter as defined by the filters: keyword is very important! It takes a list of possible filter criteria including defined tags used above. I want to be absolutely sure my inventory only returns those hosts tagged with my project designation, simple-app. That’s one of the reasons why tagging is so important in any cloud project.
With the setup complete I can graph the inventory:
[opc@dyninv ansible]$ ansible-inventory-3 --inventory dynInv.oci.yml --graph ... @all: |--@IHsr_EU-FRANKFURT-1-AD-2: | |--appserver1.app.simpleapp.oraclevcn.com | |--bastion1.bastion.simpleapp.oraclevcn.com |--@IHsr_EU-FRANKFURT-1-AD-3: | |--appserver2.app.simpleapp.oraclevcn.com |--@all_hosts: | |--appserver1.app.simpleapp.oraclevcn.com | |--appserver2.app.simpleapp.oraclevcn.com | |--bastion1.bastion.simpleapp.oraclevcn.com |--@ougdemo-department: | |--appserver1.app.simpleapp.oraclevcn.com | |--appserver2.app.simpleapp.oraclevcn.com | |--bastion1.bastion.simpleapp.oraclevcn.com |--@project#name=simple-app: | |--appserver1.app.simpleapp.oraclevcn.com | |--appserver2.app.simpleapp.oraclevcn.com | |--bastion1.bastion.simpleapp.oraclevcn.com |--@region_eu-frankfurt-1: | |--appserver1.app.simpleapp.oraclevcn.com | |--appserver2.app.simpleapp.oraclevcn.com | |--bastion1.bastion.simpleapp.oraclevcn.com |--@tag_role=appserver: | |--appserver1.app.simpleapp.oraclevcn.com | |--appserver2.app.simpleapp.oraclevcn.com |--@tag_role=bastionhost: | |--bastion1.bastion.simpleapp.oraclevcn.com |--@ungrouped:
Happy Automating!
Summary
It’s quite a time saver not having to install all components of the toolchain yourself. By pulling packages from Oracle’s yum repositories I can also count on updates being made available, providing many benefits such as security and bug fixes.
Martins Blog 