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. One of the components you will need – oci-ansible-collection – requires Python 3, so there is no need to install Ansible with support for Python 2.
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 I can install the OCI collection. This package pulls all the other RPMs I need as dependencies.
[opc@dynInv ~]$ sudo yum install oci-ansible-collection ... --> Finished Dependency Resolution Dependencies Resolved ================================================================================== Package Arch Version Repository Size ================================================================================== Installing: oci-ansible-collection x86_64 2.19.0-1.el7 ol7_developer 6.6 M Installing for dependencies: ansible-python3 noarch 2.9.18-1.el7 ol7_developer_EPEL 16 M python3-jmespath noarch 0.10.0-1.el7 ol7_developer 42 k python36-asn1crypto noarch 0.24.0-7.el7 ol7_developer 179 k python36-cryptography x86_64 2.3-2.el7 ol7_developer 501 k python36-idna noarch 2.10-1.el7 ol7_developer_EPEL 98 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.1.2-1.0.2.el7 ol7_developer 198 k python36-six noarch 1.14.0-2.el7 ol7_developer_EPEL 33 k sshpass x86_64 1.06-1.el7 ol7_developer_EPEL 21 k Transaction Summary ================================================================================== Install 1 Package (+12 Dependent packages) Total download size: 25 M Installed size: 233 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.18 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, Mar 9 2021, 15:08:44) [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
The next file to be created is the dynamic inventory file. It needs to be named following the Ansible convention:
filename.oci.yml.
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
hostname_format: "fqdn"
filters:
defined_tags: { "project": { "name": "simple-app" } }
regions:
- eu-frankfurt-1
compartments:
- compartment_ocid: "ocid1.compartment.oc1..aaa...a"
fetch_hosts_from_subcompartments: true
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.
