Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Habitat from Chef: Build, Deploy, and Manage Your Cloud Services

DZone's Guide to

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.

· DevOps Zone ·
Free Resource

Can you release faster without sacrificing quality? See how with our free ebook Strategies for a Successful Test Automation Project and a free trial of Ranorex Studio today!

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.

Build Package

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.

Integration page

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.

Builds page

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:

build

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

Studio output

Connecting packages

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 or pkg_binds_optional:

pkg_binds=(
[port]=app.port
)

You can even access these binds from within your code using environment variables and packages for your language that access them such as dotenv in JavaScript.

var port =process.env.PORT

Running packages

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.

Exploring further

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.

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.

Get your test automation project off to the right start. Download your free test planning template and a 30-day no-obligation trial of Ranorex Studio today!

Topics:
chef ,cloud ,deployment ,continuous delivery ,devops

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}