The KISS Blog
Welcome! For the most part our goal is to share with you some of the more interesting projects we work on, technical lessons learned, or otherwise things we find interesting related to technology. For now there is no ability to comment on posts though this may change in the future. Feel free to Contact Us directly with any questions or suggestions.
Hello all and welcome to the KISS IT blog! Today I bring you a relatively short post announcing a new Ansible module I developed due to the functionality not already existing in the core or extras Ansible modules. I was recently asked to build a deployment task that included updating files in an S3 bucket that are then served via a CloudFront distribution for CDN functionality. Updating the files in S3 using Ansible was trivial but then I realized that Ansible provided no functionality to clear the caches for the files in question. I decided to use this as an opportunity to create my first module for Ansible knowing that what I needed a very straightforward task.
The module is named cloudfront_invalidate and can be found on our Github account: https://github.com/kissit/ansible-cloudfront-invalidate
Welcome back to the KISS IT blog! Sorry for the extended hiatus but we've been very busy. Today we're bringing you a post covering a recently created tool we've added to our arsenal, Ansi-strano. Ansi-strano is a Capistrano like deployment process using Ansible that ties the power of Ansible's inventory management and automation with a release process similar to that of Capistrano.
Here at KISS, we prefer simple, automated deployment processes that result in the same tasks being performed exactly the same for each deployment run. More recently it seems as though there is a trend towards using "Containers" and "Immutable Infrastructure" as a crutch to solve problems with inconsistent deployments. I say crutch because I'm not sure why this is considered easier and less error prone. With a solid automated deployment process all deployments can be done safely and reliably all day long without impact to users.
In our last Ansible post I covered how you can leverage Ansible to perform configuration management tasks on AWS. In this our final post in the planned series on Ansible, I will cover how to build a playbook that can be used to (re)build your Nagios configuration any time your AWS environment changes instead of having to manually update Nagios to reflect new or removed instances running monitored services.
Here at KISS, our go-to environment availability monitoring tool is Nagios. While it definitely is not the flashiest of tools, it does one thing and does it well...monitoring. One of its most attractive features is its simplicity and ability to be extended to do anything you may want. I say anything because to date there has not ever been a case where I needed to monitor a system or service that was not possible either out of the box or by writing a simple plugin script. However, one of the downsides is if you have a fast changing environment, which is typical in the cloud, it becomes a constant battle to ensure your monitoring configuration matches your current state of affairs. As we began using Ansible for more and more tasks, I decided it was time to see what could be done to have a single command to re-build an entire Nagios configuration using EC2 tags so as to not have to add and remove configuration manually every time a change occurs.
All of the following is also located in our Github repository found here: https://github.com/kissit/kiss-ops/tree/master/ansible
In our last Ansible post I covered how to create new AWS EC2 instances using Ansible. Today I will cover how you can use Ansible to both manage and automate your configuration management needs in you AWS environment. While the examples shown below are specific to an AWS cloud environment, the concepts used are the same for any type of infrastructure and can be used in a similar fashion on other cloud platforms as well as your private server infrastructure.
Today's examples will focus on installing and configuring Apache and PHP on two separate web server pools. However, for the most part, any Unix system/service can be managed this way so long as they are configurable via a standard text file.
Before continuing any further, please note that all of the files created below can be found here for reference: https://github.com/kissit/kiss-ops.
I recently ditched our Comcast Business internet connection for Verizon FIOS in search of a more reliable provider. For well over a year I had seen intermittent high levels of packet loss with Comcast. One modem/router later and several technicians checking from the pole to the building resulted in everything looking fine in terms of signal strength according to them, but getting them to investigate further down the line seemed impossible. So since my contract was almost up I decided to give FIOS a try. Back when I originally switched from Comcast residential to business I had begged and pleaded for them to just allow me to use my own modem with my existing setup of my CentOS 6 server acting as the network gateway instead of their equipment but that was apparently not possible. With FIOS, thats one added bonus I get back is the ability to just get an ethernet connection straight to the public. However, since I've now switched my internal infrastructure to FreeBSD it was time to learn how to configure it as my gateway system for the network. Turns out, it was much simpler than I remember CentOS being.