I’ve been a geek for the vast majority of my life. My family got our first computer when I was 13 (a Commodore 64 to date myself). I started my “programming” journey by typing in pages and pages of code from the C64 magazine. Along the way I learned how to debug what I’d typed in, developed a pretty good grasp of basic before I ever had my first computer class and learned the importance of the old adage “save early, save often” (that was a particularly painful lesson).
Over the years, I’ve made a career out of developing web sites and apps for all sizes of companies. As most developers will attest, ancillary to developing apps is some level of knowledge on to get those apps hosted. After all, you can have the best app in the history of mankind, but if you can’t host it where other people can see/use it, it’s worthless. You get comfortable web server software, possibly some hardware and networking, and generally how the http request/response cycle works. Some even go as far as to figuring out how to automate a the whole process of deploying changes and updating environments.
Every part of that entire process is interesting to me. I don’t do so much on the development side any more, mainly focusing on finding, testing and using open source projects that fill some need. However, I love the idea of self-hosting these apps on the hardware I have in my basement. That includes setting up networking, configuring the hosting environment (currently a 6-node Docker Swarm hosted across 2 Dell physical servers) figuring out how to deploy them (Docker makes that a lot easier these days), and deciding if the apps create value and fill some need I have (or at least think I have).
Lately the automation piece of this hobby has led me to learn Ansible and, to a lesser extent, Terraform. Using those two pieces of technology, in less than 10 minutes, I can tear down and rebuild my entire application hosting environment (remember, 6 virtual servers hosting a Docker Swarm across 2 physical machines) and have it ready to start deploying applications to. Then, these application stacks can be deployed by Ansible in a repeatable, automated fashion.
Being able to automate my infrastructure gives me 3 HUGE benefits. Firstly, it is wicked fast to deploy. Machines are much faster at these types of tasks than humans. Literally the Ansible role will be finished before I ever get the first VM ready to boot for the first time using the manual, point-and-click method. And, lest you’ve forgotten from the two paragraphs above, I’d have to do all those steps 6 separate times.
Secondly, I can rely on the VMs for the Swarm and the application stacks being deployed the same way every single time. There’s no danger that I get interrupted midway through the setup cycle on one of the VMs and miss a step. The same tasks are executed in the same order every time the Ansible role is run. Additionally, the tasks are created to be idempotent meaning that you can run the Ansible roles on your existing infrastructure and if a task has already been completed, it will be skipped and Ansible will move on to the next task. An example here might be making sure that an entry is in the VM’s host file. You wouldn’t want it added every time you ran the role. Instead you’d want the role to only add it if the line didn’t already exist.
Lastly, because the instructions that we send to Ansible are just text files, I can version them in a source control system just like any other app code that I write. People refer to this as “infrastructure as code” and it is absolutely required if you want to build a solid automated process to deploy your infrastructure. You get all the benefits of versioning and off-site storage in case a disaster were to happen (assuming you push to a private repo somewhere like GitHub, GitLab or BitBucket).
- name: ensure /var/data exists file: path: /var/data state: directoryI’m currently exploring how I can use Ansible in other areas outside my Docker Swarm and the applications it hosts. One thing I’m researching right now is how to use Ansible to push configuration changes to all the Cisco managed ethernet switches. Another is to automate adding home automation devices to my HomeBridge instance as I install additional hardware around my house. More info on my home automation obsession will be coming in later posts.
I’ll close by saying that, while I’m talking about this in terms of my home lab, obviously these tools are used by companies around the world today. I don’t get to do these kinds of things for my company in my day job so having an outlet that I can play and test with these things at home lets me learn about things that interest me that other departments take care of at work. However, having at least the familiarization and basic understanding of these tools has helped me on more than one occasion at work to be able to contribute to projects where I would have been clueless during the discussion otherwise.