Habitat is a powerful application automation framework that enables organization to build, deploy, and manage their applications consistently no matter where they’re deployed. When you build your application in Habitat, the artifact you create can be deployed on-prem or in the cloud, and on traditional infrastructure or containers. Regardless of where that application is deployed, Habitat provides a unified workflow for configuration updates, service discovery, update strategies, and more!
In a recent episode of Channel 9’s Azure Friday show, I had the opportunity to chat with Microsoft’s Donovan Brown about what makes Habitat tick. We talked shop, geeked out about automation, and presented a quick demonstration of how application changes can be easily tested locally and promoted to a live environment in Microsoft Azure with the push of a button.
If you’d like to learn more about the application we were working with, the source code is available in our National Parks GitHub repository. In the project README, you’ll find instructions for launching the application locally via the Habitat studio. There are also a variety of Terraform configuration files, including the Azure templates used to spin up the stack I presented in the video.
Launching via Terraform uses the habitat provisioner in Terraform to deploy our national-parks artifacts into three virtual machines:
Initial Peer
This VM isn’t running any components of our application, but is responsible for being an “initial peer” that our services can use to join a supervisor ring, and start collecting information about their neighbors. Check out the Habitat documentation for more information on permanent peers.
Mongodb
Responsible for hosting a single DB instance, built off of the np-mongodb habitat package. One key thing that’s worth noting here is that Habitat lets you define dependencies within a plan file, so np-mongodb itself is only concerned with how to load the appropriate data into the database, but uses the upstream core/mongodb package to install the database itself, without needing to re-implement those steps.
National-Parks
This VM is running our actual application. As with np-mongodb, the national-parks plan is able to depend on upstream habitat artifacts for its dependencies for build (e.g. maven) and run (e.g. JRE, Tomcat), and only needs to define how to build and run its application code. As noted in the presentation, rather than hardcoding information about its database into the config, it’s instead configured to “bind” to the “np-mongodb.default” service within its supervisor ring. This means that even if our database is destroyed and replaced with a new instance, or if we deploy a cluster rather than a standalone instance, the application can independently update its configurations as needed via the information shared by all members of the ring!