Chef Automation for Infrastructure Management

Infrastructure management has come a long way. (Mostly) gone are the days of manual configurations and deployments, when using SSH in a "for" loop was a perfectly reasonable way to execute server changes. Automation is a way of life.

Configuration management tools like Chef, Puppet, and Ansible — once on the bleeding edge — are now used by most enterprises. With infrastructure automation, you get a central place for managing all of your systems, networks, and devices — both on-prem and in the cloud — so you can deploy infrastructure and applications faster, without sacrificing reliability.

Infrastructure-as-Code: Testing and Monitoring

In my last post, I talked about the evolution of Infrastructure-as-Code and its role in modern software development. To recap, let's take a quick look back at what an IaC process establishes: in a nutshell, IaC is a methodology that enables you to manage your servers and deploy your applications purely through code. Through some configuration language saved to a file, you define the resources and packages that servers need. These files can be checked into source control, and establish consistent behavior for your application across all of its environments, whether that's production, staging, or a local dev machine. A basic IaC workflow might look something like this:

Essentially, you come up with a top-level design of your infrastructure: what are you trying to achieve, and what services do you need to provide? You declare the dependencies that your applications need, everything from disk partitions, system packages, dependent services, and so on (e.g., if I have a web application, it depends on Apache, Memcache, and MySQL, to name a few). In parallel to that, you'd typically be writing code to provision your infrastructure as well, whether that's cloud resources or virtual machines on bare metal. That code is then reviewed and deployed into the world. Over time, as your application grows and its requirements change, these steps are iterated on over and over again.

Infrastructure-as-Code: Evolution and Practice

As infrastructure has evolved and matured over the last decade, the way in which we build and deploy that infrastructure has — for the most part — kept pace. As the velocity of deployments increased, and practices such as continuous deployment and delivery became the norm, it became critical that we manage infrastructure and deploy applications in a similar way.

From this need arose "Infrastructure-as-Code" (IaC), the management of infrastructure (and everything therein, from networks to VMs to load balancers) that provides the foundation for your apps. By deploying and codifying your deployments in the same way, you establish one framework — one source of truth — for the state of configuration for everything from your infrastructure to your applications. As Jesse Robins and John Allspaw put it in Web Operations, IaC lets you: "Enable the reconstruction of the business from nothing but a source code repository, an application data backup, and bare metal resources."

Monitoring Kubernetes and Docker (Part 2): Prometheus

In part one of this series, I discussed the rise of microservice architecture and the reliance on Kubernetes and Docker for container orchestration and management. I also shared some of the challenges these new technologies present and what sources of data we need in order to effectively monitor our Kubernetes environments. In my concluding comments, I mentioned that Prometheus provides an excellent starting point for collecting and analyzing this data. In this post, I’ll give a brief overview of Prometheus, illustrate how to collect Kubernetes data with Prometheus, and discuss some of the pros and cons of the Prometheus approach.

In the next installment of this series, I’ll address some of those cons, illustrating how Sensu and Prometheus are complementary.