Learn Chef - Chef Habitat

#Introduction

In episode 16 you extended Chef with custom resources and handlers. Server configuration automation is now complete, but there is one layer missing: the application itself. In episode 17 we discuss Chef Habitat — a framework for packaging, running, and managing applications. Unlike Chef Infra, which manages servers, Habitat packages an application together with its runtime into an artifact that can run anywhere.

The goals of this episode:

• Understand the concepts of origin, plan, and artifact.
• Build packages with hab pkg build.
• Run applications with a supervisor and service topologies.
• Combine Habitat applications with Chef-managed servers.

#Habitat Core Concepts

Habitat introduces several key terms:

• Origin — the package ownership namespace, tied to a signing key.
• Plan — the definition file for how a package is built (plan.sh).
• Artifact — the build result in .hart format, containing the application and its dependencies.
• Supervisor — the runtime that runs and supervises services.
• Service group & topology — how services communicate and coordinate with each other.

#Writing a Plan

The plan is the heart of Habitat. A minimal example:

pkg_name=hello-world
pkg_origin=myorigin
pkg_version="1.0.0"
pkg_maintainer="Arman <arman@example.com>"
pkg_deps=(core/nginx)
pkg_exports=(port=server.port)
 
do_build() {
  cp -r ../assets/* "${pkg_prefix}/"
}

The do_build() function copies assets into the package prefix. Habitat provides many other hooks, such as do_install, do_prepare, and lifecycle hooks that run when the supervisor starts a service.

#Building an Artifact

Before building, generate the signing key for the origin:

hab origin key generate myorigin
hab plan init myorigin hello-world
hab pkg build habitat

The build produces a .hart artifact in the results/ directory:

ls -la results/
hab pkg install results/myorigin-hello-world-1.0.0-*.hart
hab pkg export docker results/myorigin-hello-world-1.0.0-*.hart

#Supervisor and Service Topologies

The supervisor watches over services: starting processes, restarting them on failure, managing runtime configuration, and connecting service groups via binds.

hab sup run
hab svc load myorigin/hello-world --group production

Topologies define how members of a service group coordinate:

The leader is elected automatically by the supervisor; when the leader dies, the supervisor elects a replacement.

#Integration with Chef-Managed Servers

Chef and Habitat complement each other. Chef manages the server — system packages, users, certificates, firewall — while Habitat runs the application as a service. The chef-habitat cookbook provides ready-to-use resources:

hab_package "myorigin/hello-world" do
  version "1.0.0"
end
 
hab_sup "default" do
  topology "leader"
end
 
hab_service "myorigin/hello-world" do
  group "production"
  bind "backend:backend.app"
end

With this pattern, the node's run list only needs to include recipe[my_app::habitat]; during converge, the supervisor loads and runs the application. You still use InSpec to verify the service:

control "hello_world_is_running" do
  describe port(8080) do
    it { should be_listening }
  end
end

#Conclusion

In this episode 17 you got to know Chef Habitat: the concepts of origin and plan, building artifacts with hab pkg build, origin key signing, the supervisor with hab sup run, service topologies, and integrating Habitat applications on top of Chef-managed servers.

Key takeaways:

• Plans define how an application is built.
• .hart artifacts are complete, signed packages.
• The supervisor watches over and starts services automatically.
• Topologies determine how service group members coordinate.
• Chef + Habitat work together: Chef manages servers, Habitat manages applications.

In the next episode, episode 18, we go deeper into the testing layer touched on in episode 15: Test Kitchen & Integration Testing — writing kitchen.yml, choosing a driver, writing InSpec verification, and integrating it into CI. See you in episode 18!