This guest blog is by George Kontridze, Production Engineer at Bugsnag. Bugsnag is an automated production error monitoring tool, supporting over 50 different platforms. Bugsnag provides open-source libraries for most popular programming languages which make it very easy for customers to integrate Bugsnag into their workflow. Once integrated, Bugsnag automatically detects application exceptions and provides the data and tooling to prioritize and fix errors with the greatest user impact.
At Bugsnag part of the challenge we face is the fast pace of iteration; be it external, connecting with an API to make a new integration available to our customers, or internally to regularly provisioning and scale a cluster of machines to run our services as our system’s performance characteristics evolve.
As our product evolves, it becomes incredibly important to put the tools in place to help us evolve the infrastructure that runs our services. The time and effort we invest in these tools are also quite valuable to us, so we need to choose wisely.
On the infrastructure side of things, we need to be able to ship configuration changes in production. We do configuration changes for existing resources or to add new resources. Regardless, we need to be able to do this with ease and high visibility. This is where the HashiCorp toolset comes into play.
It’s important for us to be able to quickly and reliably test configuration changes to our infrastructure and then push them into production. Changes may include a node-local configuration update or integrating an entirely new cloud service which requires setting up multiple interdependent resources. We require any changes to be tested efficiently and avoid manual, error-prone methods.
Our setup with HashiCorp Vagrant, Packer, and Terraform
Using Vagrant to launch local VMs for testing quickly
We use Vagrant to quickly launch virtual machines on our developer laptops to test configuration changes against a fresh Linux system. The integration of Vagrant with Chef’s test toolkit, Kitchen, fits into this workflow. After making cookbook changes, we run “kitchen converge” to easily see whether it’s applied correctly or if it breaks the Chef run.
Using Packer to create reproducible machine images from source configuration
Sometimes, we need to be able to launch VM instances into production quickly in order to support increased load during a spike window when our customers send us a high amount of traffic. Packer saves us time by creating reproducible images to launch identical VMs. Using Packer we bake the initial Chef run into the image to create a VM meaning the image is ready for work upon creation. This saves us the few minutes it takes for the initial Chef run when launching an instance, which has a big impact when we need to scale quickly.