Freelance technical communicator to the stars. Podcaster, video maker, writer of interactive fiction
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.
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:
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:
And what a package can consume from other packages with
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.
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.
Create your free account to unlock your custom reading experience.