Skip to main content

About Chef Habitat

Chef Habitat is a workload-packaging, orchestration, and deployment system that lets you build, package, deploy, and manage applications and services without worrying about the infrastructure your application runs on, and without rewriting or refactoring the application if you switch infrastructure.

Habitat separates the platform-independent parts of your application—build dependencies, runtime dependencies, lifecycle events, and application codebase—from the operating system or deployment environment where the application runs, and bundles them into an immutable Habitat package. Packages are stored in Chef Habitat Builder (SaaS or on-prem), which acts as a package store similar to Docker Hub where you can store and download your application’s Habitat packages. Habitat Supervisor pulls packages from Habitat Builder and starts, stops, runs, monitors, and updates your application based on the plan and lifecycle hooks you define in the package. Habitat Supervisor runs on bare metal, virtual machines, containers, or Platform-as-a-Service environments. A package managed by a Supervisor is called a service. Services can be joined together in a service group, which is a collection of services with the same package and topology type that are connected together across a Supervisor network.

Components

Habitat Builder

Chef Habitat Builder is the core of Chef’s Application Delivery Enterprise hub. It provides a repository for all available Chef Habitat packages built by Chef and the supporting community, as well as search and other APIs for clients.

You can use Chef Habitat Builder as either a cloud-based or on-premises solution:

For more information, see the Chef Habitat Builder documentation.

Habitat package

A Habitat package is an artifact that contains the application codebase, lifecycle hooks, and a manifest that defines the application’s build and runtime dependencies. The package is bundled into a Habitat Artifact (.HART) file, which is a binary distribution of a given package built with Chef Habitat. The package is immutable and cryptographically signed with a key, so you can verify that the artifact came from the expected source. Artifacts can be exported to run in a variety of runtimes, such as containers, with no refactoring or rewriting.

Plans

A plan is the set of instructions, templates, and configuration files that define how you download, configure, build, install, and manage the lifecycle of an application artifact. The plan is defined in the habitat directory at the root of your project repository.

The habitat directory includes:

  • a plan file (plan.sh for Linux systems or plan.ps1 for Windows)
  • a default.toml file defining configuration settings used to render configuration templates
  • an optional config directory for configuration templates
  • an optional hooks directory for lifecycle hooks

You can create this directory at the root of your application with the hab plan init command.

For more information, see the Habitat plan documentation.

Services

A service is a Chef Habitat package that’s run and managed by a Supervisor. Services can be joined into a service group, which is a collection of services with the same package and topology type connected across a Supervisor network.

See the services documentation for more information.

Habitat Studio

The Chef Habitat Studio is a clean, self-contained, minimal environment where you can develop, build, and package software without relying on an upstream operating system distribution. All tools and dependencies included in the Studio are installed as Chef Habitat packages, which helps prevent unwanted dependencies from being used by your package.

See the Habitat Studio documentation for more information.

Habitat Supervisor

Chef Habitat Supervisor is a process manager that has two primary responsibilities:

  • A Supervisor runs your app’s services. It starts, stops, updates, and monitors the services according to your plan.
  • Supervisors can talk to each other. You can connect Supervisors together into a network and instruct them to send information to each other and take actions based on that information.

In the Supervisor, you can define topologies for your application, such as leader-follower or standalone, or for more complex applications that include databases. The Supervisor also allows you to inject tunables into your application, which lets you defer decisions about how your application behaves until runtime.

See the Habitat Supervisor documentation for more information.

When should I use Chef Habitat?

Chef Habitat lets you build and package your applications and deploy them anywhere without refactoring or rewriting your package for each platform. Everything the application needs to run is defined without assumptions about the underlying infrastructure.

This lets you repackage and modernize legacy workloads in place to increase manageability, improve portability, and migrate to modern operating systems or cloud-native infrastructure such as containers.

You can also build new applications and use Chef Habitat to manage deployment if you’re unsure which infrastructure your application will run on, or if business requirements change and you need to move to a different environment.

Next steps

Additional resources

Download

Learning

Community

Support

GitHub repositories

Thank you for your feedback!

×