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.
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
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:
- The plugin path is:
- The built in playbook path is:
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.
Our simple playbook starts by targeting all hosts found within a given inventory and escalates privileges.
- name: Simple operations hosts: all become: true
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
aide role is used to setup basic intrusion detection rules.
- role: aide
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-playbookcommand. 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.
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.
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.