ericsysmin's DevOps Blog

How to loop blocks of code in Ansible

How to loop blocks of code in Ansible

In this blog post I will cover how we can loop groups/blocks of tasks within Ansible. Currently using - block: will not work. However you can use - include_tasks: my_grouped_tasks.yml to loop a group of tasks. Within that tasks file you can use {{ item }} on each of your tasks and It will copy from the item during the loop. At Avi Networks we’ve used this for much of our internal task groupings which have items that depend on creation of each other and cannot independently run loops without causing issues.

In the following I have some visual representations to show what the goal origianlly was, and how you can accomplish it.

PROBLEM:

SOLUTION:

This will effectively do a loop over your multiple tasks. I know it’s a bit annoying, but this is currently the only working solution to looping over blocks of tasks.

Continue reading...

Integrating Zabbix w/Slack for Channel Notifications

I’ve been using Slack and Zabbix now for a few years, and figured since there’s not too many guides out there on how to integrate the two easily. I know there are a few examples so far, but this is what’s worked best for me.

First I use this script, and put it in your alertscripts directory, ex.   /usr/lib/zabbix/alertscripts .

Notice there’s no field for credentials. That’s because over time I found it easier to deploy with a configuration file that was in yaml format.

Make sure you create an API token for slack by creating a Slack App, then using it’s Verification Token. Hopefully in the future I revisit this and make use of the Client ID, Client Secret, Signing Secret configuration.

So to provide that file we need to create the following in your zabbix configuration directory ex.  /ext/zabbix/slack.yml .

This makes it easier at least for me to deploy and separate configuration from the script itself.

Next steps include creating the Slack Media Type.

Navigate to Administration > Media types

Select “Create media type”, and fill out the following:

 

Don’t forget to save!

Your first value is going to be “Channel” the rest fill in the message details.

Continue reading...
Using Avi Ansible modules to Patch your Avi Controller

Using Avi Ansible modules to Patch your Avi Controller

So I’ve been working for a company called Avi Networks for a while now. Working on customer deployments, internal devops automation, customer migrations, and tons of other projects including getting Avi to have the largest module library available out of any load balancer on the market. Well, today were going to show how to use Avi’s Ansible modules to patch your Avi Controller. It’s easy, here’s how.

This will also wait for the controller to come back up 🙂

Continue reading...

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...

Been a while…

Sorry everyone, I’ve been gone for a while. I’ve been super busy at this company Avi Networks. I’ve been here for 2 years, and it’s been growing fast. However, I’m back in the DevOps/SRE realm of things, which will allow me to once again share some of my insights on the world of automation, containers, scripting, and other cool workarounds to get things working the way you want.

I’m probably going to make a few changes in the next few weeks to this blog to get it running again, and move the commenting system over to something that I won’t have to manage and prevent spam. I’ve manually had to approve a lot of comments, and that doesn’t scale, obviously. lol

Continue reading...