.jpg)
In the first installment of Automation Tales, Chris Smith had to find a way to automate virtual server deployment when his company, Knuten Valve, acquired another firm. He used Ansible scripts and other tools to accomplish the automation goal.
Just a few weeks later, Chris was beginning to develop a team to move his first DevOps application up into the cloud.
His goal was to get his DevOps project off of the ground as quickly as he can. Based on everything that he has read, he knew his engineering team didn’t necessarily have fundamental knowledge of developing code. At first he considered letting them take the reins and just go at it but after some thought he decided to talk with his peers on the application development side to get their recommendation.
Chris began his day by calling Drew, one of his peers in the Enterprise Application side of the company. Drew referred him to Becky, a Release Engineer with 15 years of experience in the Enterprise Application group.
She popped into Chris’s office and asked what he was trying to accomplish.
Chris answered, “As part of our Cloud-ready Initiative, I have been asked to start evaluating the cloud. The Cloud’s benefit, of course, is we can spin things up extremely fast. The Cloud’s downside is that you need to manage resources to keep costs in control. You’re paying for the resources you spin up even when you stop using them.”
“So, what I really need,” he continued, “is help accelerating the knowledge transfer as fast possible to help a couple of my guys to develop an infrastructure as code pipeline.”
Becky suggested starting with Pair Programming, an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.
What this will do is enable everyone to assist in closing the gap between writing scripts and actually writing code that can be used for more than a point solution, writing internal unit tests, and sharing best practices.
“Based on my understanding,” Becky said, “we are looking to store the code in a git repository, use the full stack of Ansible, and use lint for compliance tracking. How about using an Ansible Molecule to allow the Ansible playbooks be tested on the developer systems verse having to go off and manually build and maintain the systems another VMware or cloud instance.”
Once Chris’s team began pair programming, the next step was creating a standard development laptop build using Ansible, Git, Molecule, lint, slack. Becky was explaining that she preferred to develop on her own machine. She has found in the last several months the Ansible project has adopted lint and Molecule. Lint is a tool that helps drive best practices, style, tidy up any extra whitespaces, and identify any syntax issues faster, allowing processing of the role to fail faster.
Molecule is designed to aid in Ansible role testing. It provides the capability to create multiple instances, operating systems and distributions, virtualization providers, testing frameworks, and testing scenarios. Becky explained it will help dynamically deploy new infrastructure for each test. The team could deploy infrastructure on multiple platforms such as Azure, Docker, AWS EC2, OpenStack and much more.
Chris, Becky, and other team members will continue to dig deeper into Molecule, Docker, and other tools, so stay tuned.
About the author
Scott Perkins is a Cloud Architect for LRS IT Solutions. Holding multiple certifications for both Storage and Cloud. Scott has many years of experience implementing solutions.