Habitat lets you build your packages, , offering a form of independent package repository that you can roll out to any production environment. The core concept of Habitat is a file that contains details needed for Habitat to build a package, and there are you can add to one. Fortunately there a suite of tools to help take the drudgery out of defining a plan file, including for Linux, macOS, and Windows. but also supplies thousands of its own plan.sh a large number of variables a CLI tool 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, , 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. log in to the service Build your package by clicking the button under the 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: Build latest version Build Jobs 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 file. plan.sh You define what a package can share with , for example, the port: pkg_exports pkg_exports=(   [port]=app.port ) And what a package can consume from other packages with or : pkg_binds 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 in JavaScript. dotenv 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 .

Too Long; Didn't Read

Making security fun one episode at a time

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

Too Long; Didn't Read

Chris Chinchilla

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

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

Too Long; Didn't Read

Chris Chinchilla

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES