Habitat from Chef: Build, Deploy, and Manage Your Cloud Services
Chef recently introduced the Habitat tool, bringing Chef's advantages to automation and continuous integration. Learn about the suite of tools that make it possible.
Join the DZone community and get the full member experience.Join For Free
Chef is an established name in infrastructure and DevOps world, turning the concepts of your infrastructure into code that you can version control and collaborate on. Recently the Chef team introduced a new tool, Habitat, that brings that Chef magic to a busier space, that of application automation and continuous integration.
Habitat lets you build your packages, but also supplies thousands of its own, offering a form of independent package repository that you can roll out to any production environment. The core concept of Habitat is a plan.sh file that contains details needed for Habitat to build a package, and there are a large number of variables you can add to one. Fortunately there a suite of tools to help take the drudgery out of defining a plan file, including a CLI tool for Linux, macOS, and Windows.
Create a Plan
Inside the directory of a project, you’d like to enable Habitat for, issue the following command, and Habitat will attempt to set up a plan for you:
hab plan init
I tried running this command in an existing Node.JS project and Habitat generated the following plan file:
pkg_name=express-node-mongo-skeleton pkg_origin=chrischinchilla pkg_version="0.1.0" pkg_scaffolding="core/scaffolding-node"
The above is a simple plan file, and Habitat allows you to set complex variables and use logic and iteration, find more details in the Habitat documentation on plans.
There are a couple of different ways to build your packages, using the GUI based builder service, or manually using Habitat studio.
To build a package with the builder, log in to the service, create an ‘origin’ and add integration points to it, which are currently the Docker Hub (DH), or the Amazon Container Registry (ACR). The source of your packages can only be GitHub repositories, as Habitat leverages a small application that watches for changes in the repository you specify. Maybe there will be other sources for your packages in the future.
Build your package by clicking the Build latest version button under the Build Jobs tab, or whenever you push changes to the master branch. If you configured an integration to the DH or ACR, then you can always find an up-to-date version of your package there, or you can install one manually on any platform with habitat installed using the following command:
hab install chrischinchilla/express-node-mongo-skeleton
And by default, any package you create is publicly available to any other habitat user.
The studio is a virtual environment that runs inside a Docker container where you can iteratively build, test and run packages and export them to a container registry. Inside of your source folder, fire up Habitat Studio, which is a self-contained, minimal shell environment in which you can develop, build, and package software free from any dependencies that are not specified by your application’s plan.
hab studio enter
Inside studio, run:
And studio will start downloading dependencies for you to test your application. When you’re ready to release, export the package:
hab pkg export chrischinchilla/express-node-mongo-skeleton
Of course, modern applications rarely run in isolation, to allow habitat packages to share resources with each other, you define what is shareable in the plan.sh file.
You define what a package can share with
pkg_exports, for example, the port:
pkg_exports=( [port]=app.port )
And what a package can consume from other packages with
pkg_binds=( [port]=app.port )
var port =process.env.PORT
You can run your packages as Docker containers in any of the myriad ways possible, including Docker Compose, and sharing bound variables between them. The same applies to running habitat-powered containers on ACR; you can run any package you create as a container and share details between them by using environment variables.
One of the biggest issues I had with Habitat was understanding what it is capable of. Its feature set is so rich, exploring what is fully possible is hard. I reached out to the community to ask for a summary of what they designed Habitat for and received a similar answer.
@habitatsh is a pretty unique framework of tools. Since they touch the app lifecycle end-to-end there aren't many other tools out there to compare it to. It has some cross-over with bazel and spinnaker, but also some cross over with consul, travis and a bunch of other stuff!— Ian Henry (@Eeyun___) December 12, 2017
Habitat merges functionality from build systems, CI tools, service discovery and more. The project is in early days, so I suggest you run test projects before moving all your tooling over, but I would love to hear your thoughts on the tool and how it might help you.
Opinions expressed by DZone contributors are their own.