Ansible — My first attempt at automating devops.
When I set out to build memms with the team at kohactive we had a goal of launching our MVP in a day. We are strong believers of the MVP/MLP, and wanted to use it as an experiment to see how quickly we could launch a product that people would love.
We decided in order to focus on what made our product great, we would launch our app and run it on heroku. If you’ve been living under a rock for the last 5–10 years, heroku is a IaaS platform that lets you easily deploy your application with a simple git push and helps to encourage best practices such as configuration via environment variables. We also opted to host our database on their Postgres offerings, and enabled the RedisToGo addon to handle our sidekiq queues.
Our early development / beta environment was totally free, but I will admit we cheated a bit. We basically had 1 free postgres db, free tier RedisToGo, and 1 free web dyno. We also had a clone of our app running as our sidekiq worker and let them share a Redis and Postgres URL, thus the “cheating”.
This was great until we decided we wanted to share our creation with the world. We did what normal people do and we scaled our resources. We moved to the cheapest paid DB tier, the small RedisToGo plan, and we scaled to 2 web dynos and 1 worker dyno and brought sidekiq back under our main app. It all just worked and it was great.
As a 100% bootstrapped startup with no revenue yet we quickly realized we were paying a lot for what we were getting. Our bill for our simple infrastructure was just south of $200/mo. While not a bank breaker, we currently were charging nothing for our service and every user we have costs us $2–3 dollars already. In order to keep costs low when we did start offering premium plans we wanted to lower our costs as much as possible without sacrificing any of the things that made our heroku stack great.
In a number of our other projects we had already been using DigitalOcean and they are very cost effective. We thought we could start with 5–10$ app servers and just keep adding more as we needed them. Scaling and load-balancing is another thing we have had plenty of experience with, but again these were problems we didn’t want to tackle before we had released our MVP.
We wanted the ability to cleanly provision new resources without having to rely heavily on pre-built, quickly outdated images that would need constant reconfiguration and manual updates every time something needed to be changed.
We looked at all the hot devops platforms. Chef, Puppet, Salt and Ansible. We started with opinion we wanted chef, but after looking into what systems like Chef or Puppet actually require, they seemed like overkill.
Most of the systems used an agent or a client that needed to be installed on every box. This seemed like an anti-pattern since our goal was provision all the instances entirely through what ever platform we chose. Puppet and Chef were dismissed for this reason, I am sure there are workarounds or solutions that make these better options, but we did not have time to learn these ecosystems.
We finally landed on Ansible and couldn’t be happier. Ansible is an agentless take on infrastructure automation. Everything is done over SSH and all tasks are defined in yml files. These yaml files are refered to as playbook and they are easy to write. Ansible also shipped with a module for nearly everything we needed.
Modules are plugins that provide a friendly yaml DSL for interacting with different system. We use CentOS7 so we use the yum modules for package management. The cool thing is if you use Ubuntu, you can just switch to the apt module. Modules allow us to do everything from user creation, ssh key creation, package management, firewall rule management, uploading files based on templates, service management, and postgresdb provisioning to managing cloud instance in ec2 or digital ocean. We use digital ocean now but may migrate in the future. Ansible will make it incredibly easy to move to a different host if needed.
Previously where migrating an image from Amazon to Digital Ocean might seem impossible, we can change a few lines in a playbook and spin up digital ocean droplets instead of amazon instances.
If you are like us and are tired of paying heroku prices when it would be just as easy to host with digitalocean. Check out our opensource rails playbooks
and feel free to send PRs or open issues.
