ansible
VMworld Europe Hackathon: Preparation
We are getting closer to VMworld Europe and the Hackathon that goes with it. For team Automation for All, this means we are getting prepared to have a lot of fun on Monday.
The goal of this post is to give an overview of the requirements of working with Ansible and how to properly setup your environment.
As a first tip, the best thing to do as preparation, is to look at all the available VMware focused standard modules in Ansible. A full list can be found here. The vsphere_ modules are being deprecated and should not be used.
VMworld Europe Hackathon: Introducing team Automation for All
In a week, VMworld Europe 2017 kicks off and as tradition dictates, VMware is organising a Hackathon on Monday night. As part of that, a bunch of us have started a team to do something cool with Ansible during that Hackathon (team 4 on the list).
The first and foremost goal of our team is to have fun and enjoy a good evening with like-minded people. If, during all of that fun, beer drinking, chocolate eating and overall banter, we also manage to build something interesting, all the better!
The team
The team consists of some interesting and experienced people with great backgrounds:
If you want to meet the team, join us on our VMware {code} Hackathon-Europe Slack channel!
The goal
There are two potential goals that we could go for as a team:
- Develop a new Ansible module to do something in a vSphere environment, for instance deploying an OVA.
- Creating Ansible roles to automate a deployment of a vSphere product, for instance vSphere Integrated Containers.
Let’s dive in each of those options a little deeper.
Ansible roles to deploy Shorewall, Shorewall6 and DHCP server
Lately I’ve been looking into Ansible, a configuration management tool like Puppet or Chef. There is no specific reason why I’m using Ansible instead of the other possibilities, except that it seemed to be easier. One of the big advantages is that you do not need to install software on each managed host if you don’t want to. The whole system is Push, altho a Pull system is available.
Ansible uses modules, roles and playbooks. Modules are written in python and are used as building blocks of roles. They represent actions which can be taken on a host, like installing a package, making sure a file is present, … There is a whole list of standard modules on the Ansible documentation. Of course you can write your own modules to do more complex stuff, I recently wrote a module which checks out a WordPress application from a git repository and sets it up in a Plesk created vhost. I did this before I really got a feel for playbooks and roles in Ansible, because i’m sure that almost all steps in that module could be done using the default modules.
Roles use modules to setup certain server roles or configurations on hosts. For instance, you can create a role to install Apache or Nginx. Roles are a list of module actions which are executed in order. If one step fails for a host, the next step won’t be run for that host, but it does continue for other hosts. Roles should be limited to setting up a single server role. If you want to setup multiple items, like a LAMP stack, you should use playbooks.
Playbooks are a set of roles that needs to be present on one or more hosts. You could create a playbook which installs Apache, MySQL and PHP. This will probably call a couple of roles like one to install and setup Apache, another to install and setup MySQL and another to make sure PHP is installed and configured properly. This playbook, and others, are available as examples provided by Ansible Works.
Recently Ansible Works created a role exchange website called Ansible Galaxy. This gave me the idea to get a bit more serious and create a couple of roles which I would find interesting.
dhcp_server
Dhcp_server is a role which installs and configures a DHCP server on a host. It is capable of setting up the full capabilities of the standard DHCPv4 server in Ubuntu, Debian, CentOS, RHEL and Fedora.
For more details on the dhcp_server role, you can either visit the Ansible Works role page, or go directly to the GitHub page.
shorewall_simple & shorewall6_simple
Shorewall_simple is a role which installs Shorewall on a host and configure it. It is intended for simple setups, it can cope with multiple interfaces, but it is not capable in being used in a router or NAT gateway. For that a shorewall_full role is in development.
It is a role which is perfect to protect a single host with a firewall, controlling both incoming and outgoing packets. It provides the full use of policies and rules for a single host, even with multiple interfaces. So it is capable of setting up the standard rules like ACCEPT, REJECT and DROP, but also stuff like REDIRECT and DNAT (altho you wouldn’t really need that last one on a single host).
Shorewall6_simple is very similar to shorewall_simple, except it’s intended to install and configure Shorewall6, the IPv6 variant of Shorewall.
If you want to use this role, be aware that you are configuring a firewall on a remote server. If something goes wrong, you might have locked yourself out of your server and you might need to get direct access to the console of the server (which might be in a remote, difficult to reach, datacenter).
For more details on the shorewall_simple role, you can either visit the Ansible Works role page, or go directly to the GitHub page.
For more details on the shorewall6_simple role, you can either visit the Ansible Works role page, or go directly to the GitHub page.
shorewall_full & shorewall6_full
Shorewall_full and shorewall6_full are not released yet and are in full development. The aim of these roles is to provide a fully configurable Shorewall or Shorewall6 setup, which can be used in routers, nat gateways, VPN servers, …
