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.
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:
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
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.
Originally published at dzone.com.