ericsysmin's DevOps Blog

Deploying Modules as an Ansible Role

As Ansible grows as solution for much of the DevOps community many partners and supported modules are hitting the community. However, all of us are being hit by a serious problem. Release Gap.

Release Gap is the difference of time between your modules being accepted into the Ansible core and the time you release a new feature or patch you want your customers to use.

At Avi we ran into this problem, and luckily Ansible has a solution. Roles. Using roles to deploy your modules helps you control your code and guarantee customers are using the latest tested modules you offer.

To do this we need to have a role structure as such.

However, users will need to include the role in their playbook.

However, there are some caveats. Your module names should never be the same as modules that someone else, or core uses. In our case we stuck with avi_<module-name>  for our modules.

A good way to look at the pipeline is the following.

Using this pipeline you can then import your modules into the core, but also pre-release or release modules at your own schedule and version, independent of Ansible release schedule. You can also allow users to upgrade their environments.

Users can then download your modules using the following command.

You can also specify version so your end users can control versions of your modules

The goal of this was to empower the partners, supported modules to be downloaded by customers without having to force customers to also upgrade Ansible itself which can affect other modules that are working for all playbooks.

Continue reading...

Pets vs. Cattle

Earlier I had mentioned about Pets vs Cattle, and one of my recent friends asked me what it actually means. Pets vs Cattle is a concept. Recently brought on by the advent of cloud computing and managing massive infrastructures which can be easily automated. Its extremely different than traditional systems administration, which was born from physical machines where you may need to purchase new hardware, build it, then deploy it within your datacenter.

Pets

First you give them a name. Then you installed services on that server, and if the server got corrupted or hardware failed you had to repair the computer, possibly rebuild the hard drive, fix corrupted filesystems, I could go on essentially you nursed it back to health. This is referred to as "taking care of a pet", you take care of it, you update, upgrade, and patch it. Some applications still need this attitude, but many in this decade do not! Now we've changed, and we with RESTful APIs can quickly spin up infrastructure, and build from scratch to a working machine in minutes.

Cattle

Now with cloud computing we are able to do amazing things. I can easily build a "golden image" from a running application, even build that image from scratch and use it in an autoscaled environment (something Netflix has done for years!). Using tools like Ansible, Puppet, Salt, and Chef, you can quickly build new infrastructure that is known to work. You can even use those tools to build a brand new image which can then be used to create 100 servers just with one command line entry. Instead of names these guys get numbers. All servers are essentially identical to each other. If a server dies, you issue a couple API calls (or not if you are using AWS Autoscaling or similar, as it does it for you if you want it to), and now you have replaced that server in your environment. If a cow is ill/dying you kill it, and get another. That's where this analogy originates.
Continue reading...