tripleo Featured

Using TripleO-Ansible, without TripleO, in Ansible Operations

Kevin Carter

Sep 14, 2019 • 6 min read

The TripleO project team has been embarking on developing Ansible roles for deploying and operating OpenStack clouds. While this is not new, over the last couple of months, we've re-ignited our simplification efforts and have focused on creating simple, well-tested tooling.

We started by collecting all of our Ansible tools into one place, creating documentation, and then testing. Throughout this last cycle, we've made excellent progress:

Lots of roles have been created or imported into the TripleO-Ansible project.
Heat templates targeting bare-metal have largely been converted to Ansible Roles.
Documentation generation has been created and published.
Testing has been implemented using Molecule.
All tests are run using role specific scenarios in Zuul CI.

These advancements are making TripleO easier to understand while also enabling more engineers to work on a single unified code-base. While these roles were developed with on-premises cloud infrastructure in mind, there's no restriction on how they could be used. In this post, I'll cover how the TripleO-Ansible roles can be consumed in an enterprise environment outside of a TripleO cloud.

Overview

The TripleO-Ansible roles have been packaged and are part of the TripleO Train release packages (OSP16). This package can be easily installed using either yum or dnf, depending on the system your running. In this tutorial, I am running CentOS 7 with the RDO package repository for access to the upstream OpenStack Train packages.

The roles can also be used directly from source, clone the repository, and set the role path accordingly.

Getting into it

From within the command prompt, the first thing we'll need to do is create our required repository.

At the time of this writing, the TripleO-Ansible package we need is not in the released RDO repository. To pull the latest package, we'll configure the system using the trunk repositories. Under normal circumstances, you would be able to install the release rpm noted in the RDO documentation.

Create the repository file.

$ sudo curl https://trunk.rdoproject.org/centos7-master/current/delorean.repo -o /etc/yum.repos.d/delorean.repo

With the repository file in place, ensure that the repository is disabled by default.

$ sudo sed -i 's/enabled.*/enabled=0/' /etc/yum.repos.d/delorean.repo

Now install ansible, tripleo-ansible and python-netaddr. These packages provide the system everything needed to consume to the TripleO-Ansible roles, plugins, and playbooks.

$ sudo yum install --enablerepo=delorean tripleo-ansible python-netaddr https://releases.ansible.com/ansible/rpm/release/epel-7-x86_64/ansible-2.8.5-1.el7.ans.noarch.rpm

The above command installs a known good version of Ansible from the upstream Ansible releases repository. While this package URL is optional, it does provide a simple way to install a stable release of modern Ansible.

With the packages installed, we're ready to get started:

The role path is: /usr/share/ansible/roles
The plugin path is: /usr/share/ansible/plugins
The built in playbook path is: /usr/share/ansible/ansible-playbooks

While the pathing is good to know, you, as an operator, do not need to do anything special to access the roles and plugins provided by the tripleo-ansible package. Everything is within the default Ansible search path, making it exceedingly simple to get started.

Building our first custom playbook

From within the users home folder we'll create our first playbook. This playbook will do the following:

setup a secure tty environment
setup sshd
add kernel options
load kernel modules
implement firewall rules
set the timezone
install & setup aide
install & setup tuned

Building our operator playbook piece by piece

Yes, the example playbook we're about to write is going to do a lot, but it won't require us to do much from within the playbook. The simple example playbook defines the host group, include the needed roles, and provide deployment-specific configuration to the roles.

Opening

Our simple playbook starts by targeting all hosts found within a given inventory and escalates privileges.

- name: Simple operations
  hosts: all
  become: true

Role includes

Our first role include secures our tty's by limiting all of the available tty's on the system. The only option we need to define is tripleo_ttys this option is a list.

- role: tripleo-securetty
  tripleo_ttys:
    - console
    - tty1
    - tty2
    - tty3
    - tty4
    - tty5
    - tty6

Our next role include ensures sshd is correctly configured on the system. While this role requires no user input, it does have several defaults available to it. In this case, we'll set two options to create a banner and the message of the day.

- role: tripleo-sshd
  tripleo_sshd_motd_enabled: true
  tripleo_sshd_banner_enabled: true

The kernel role also has additional defaults available to it, however, for our underlying use case, we'll just set a couple of kernel options.

- role: tripleo-kernel
  tripleo_kernel_sysctl_extra_settings:
    net.ipv6.conf.default.disable_ipv6: 
      value: 0
    net.ipv6.conf.all.disable_ipv6: 
      value: 0
    net.ipv4.ip_forward: 
      value: 1
    net.ipv4.ip_nonlocal_bind: 
      value: 1
    net.ipv6.ip_nonlocal_bind: 
      value: 1
    kernel.pid_max: 
      value: 1048576
    net.ipv4.neigh.default.gc_thresh1: 
      value: 1024
    net.ipv4.neigh.default.gc_thresh2: 
      value: 2048
    net.ipv4.neigh.default.gc_thresh3: 
      value: 4096
    fs.inotify.max_user_instances: 
      value: 1024

The module-load role loads all the listed kernel modules and ensures they're persistent.

- role: tripleo-module-load
  tripleo_modules:
    - name: ebtables
    - name: ip6table_filter
    - name: ip6_tables
    - name: ip_tables
    - name: ipt_MASQUERADE
    - name: ipt_REJECT
    - name: iptable_filter
    - name: iptable_mangle
    - name: iptable_nat
    - name: ip_vs
    - name: iscsi_tcp
    - name: nf_conntrack
    - name: nf_defrag_ipv4
    - name: nf_nat
    - name: nf_nat_ipv4

Defaults in this role variable provide for unique rules in the form of a hash: the key is used as a comment, and all comments are sorted, thereby determining the rule order. In this example, only port 22 is allowed.

- role: tripleo-firewall
  tripleo_firewall_rules:
    '003 accept ssh from all':
      proto: 'tcp'
      dport: 22

To ensure all systems are running on the same timezone, the timezone role is executed using UTC.

- role: tripleo-timezone
  tripleo_timezone: UTC

The aide role is used to setup basic intrusion detection rules.

- role: aide

The tuned role i used to ensure our servers are tuned for performance.

- role: tuned

Both of these roles have several options to configure the deployment based on the needs of a given environment, however, the defaults are batteries included and will do whats need to ensure a successful deployment.

The playbook rises

Now that the parts of the playbook are covered, glue them all together and run it.

- name: Simple operations
  hosts: all
  become: true
  roles:
    - role: tripleo-securetty
      tripleo_ttys:
        - console
        - tty1
        - tty2
        - tty3
        - tty4
        - tty5
        - tty6

    - role: tripleo-sshd
      tripleo_sshd_motd_enabled: true
      tripleo_sshd_banner_enabled: true

    - role: tripleo-kernel
      tripleo_kernel_sysctl_settings:
        net.ipv6.conf.default.disable_ipv6: 
          value: 0
        net.ipv6.conf.all.disable_ipv6: 
          value: 0
        net.ipv4.ip_forward: 
          value: 1
        net.ipv4.ip_nonlocal_bind: 
          value: 1
        net.ipv6.ip_nonlocal_bind: 
          value: 1
        kernel.pid_max: 
          value: 1048576
        net.ipv4.neigh.default.gc_thresh1: 
          value: 1024
        net.ipv4.neigh.default.gc_thresh2: 
          value: 2048
        net.ipv4.neigh.default.gc_thresh3: 
          value: 4096
        fs.inotify.max_user_instances: 
          value: 1024

    - role: tripleo-module-load
      tripleo_modules:
        - ebtables
        - ip6table_filter
        - ip6_tables
        - ip_tables
        - ipt_MASQUERADE
        - ipt_REJECT
        - iptable_filter
        - iptable_mangle
        - iptable_nat
        - ip_vs
        - iscsi_tcp
        - nf_conntrack
        - nf_defrag_ipv4
        - nf_nat
        - nf_nat_ipv4

    - role: tripleo-timezone
      tripleo_timezone: UTC

    - role: aide

    - role: tuned

This simple playbook will do everything we need to get our new server ready for production. Before executing the playbook create your inventory. For this example we'll execute the playbook on localhost.

ANSIBLE_HOST_KEY_CHECKING=false ansible-playbook -i localhost, simple-ops-playbook.yaml

The above command is passing in the environment variable ANSIBLE_HOST_KEY_CHECKING to the ansible-playbook command. While useful for local testing, its not recommended for production uses.

The playbook runs for about a minute or two. When completed, the system is ready. As you'll see in the output, the roles do quite a lot, making them robust, batteries included, resources.

PLAY RECAP ***************************************************************************************************************************************************************************************************************************************************
localhost                  : ok=70   changed=8    unreachable=0    failed=0    skipped=39   rescued=0    ignored=0


real    0m47.364s
user    0m11.689s
sys     0m5.710s

The TripleO-Ansible project is providing for a whole host of roles, plugins, and playbooks to deliver deployment and configuration tooling. From NFV configuration to setup, to managing podman containers, to preparing new servers for production workloads; the TripleO-Ansible project has something for everyone. Everything in tree is tested, documented, and built for the enterprise.

The flexibility of these roles allows them to be used in just about any environment or configuration supporting an enterprise application. While this playbook example is simple, the implementation details are anything but plain. Checkout what the roles provide, see how they can be configured to meet the needs of just about any deployment. All of the roles have sane defaults, prefixed options, and a consistent layout. The anatomy of the TripleO-Ansible code base makes it easy to understand and extend.

Wrap-up

In this post, I intended to show how easy it is to reuse the TripleO-Ansible roles outside of an OpenStack cloud deployment. While code can pull from anywhere, these tools provide peace of mind. Everything added to TripleO-Ansible represents a building block for enterprise cloud infrastructure. Which, in turn, provides confidence to operators that configuring systems with TripleO-Ansible will meet or exceed the standards of enterprise applications.

All of these roles are free, open-source, and well tested via Molecule and various scenario-based integration tests; all powered by Zuul CI. We have a long list of roles, plugins, and playbooks available in the TripleO-Ansible code repository and are adding more every day.

Get involved

If you're interested in using and contributing to any of thing in TripleO please join us online, share your experiences. New users and contributors are always welcome, and we're looking forward to collaborating with folks. The re-ignition of the TripleO-Ansible efforts is exciting, and we're looking forward to delivering the best possible developer, operator, and user experience as we build the future of our Radically Simplified Open Infrastructure built for enterprise scale.