Plans in Chef Habitat

Pre-requisites

Installing Habitat

In Linux, Chef can be installed by typing the following command on the command line.

curl https://raw.githubusercontent.com/habitat-sh/habitat/main/components/hab/install.sh | sudo bash

In Mac OS, Chef can be installed with the help of Homebrew by running this command

brew tap habitat-sh/habitat
brew install hab

In Windows, Chef can be installed using Chocolatey.

choco install habitat

Origin in Chef Habitat

A space in Chef Habitat where you can store, build and share the packages is known as Origin. It is a unique feature of Chef Habitat Builder. Though you can delete and modify the packages, renaming of packages is not permitted.

A classic example of Origin in chef habitat is the “core” origin which is maintained and managed by the maintainers of the Chef habitat Builder.

Users can create an origin by using the following command-

hab origin create <origin>

Packages in Chef Habitat

After the completion of the origin setup, the build script starts. You can now start uploading your package in the Chef Habitat Builder or access the package locally.

There are several ways to build the packages. It can be done manually using the Graphical user interface service or the Habitat Studio.

If the user intends to use builder, he should follow the following steps:

• Log in to the service
• Create an “origin.”
• Add integration points to it.

Remember that the sources of the package can be GitHub repositories only. Users can amend this later.

Build your package using the Build latest version button after these steps.

Check out most important Git Interview Questions here.

Plans in Chef Habitat

In Chef Habitat, Plans intend to formulate a flow of how an application is built, deployed, and managed.

Plans look like this-

(plan.sh file)

pkg_name=xyz
pkg_version=3130000
pkg_origin=core
pkg_license=('Public Domain')
pkg_maintainer="The Chef Habitat Maintainers <humans@habitat.sh>."
pkg_description="Description of XYZ."
pkg_upstream_url=https://www.xyz.org/
pkg_source=https://www.xyz.org/2016/${pkg_name}-autoconf-${pkg_version}.tar.gz
pkg_filename=${pkg_name}-autoconf-${pkg_version}.tar.gz
pkg_dirname=${pkg_name}-autoconf-${pkg_version}
pkg_shasum=e2797026b3310c9d08bd472f6d430058c6dd139ff9d4e30289884ccd9744086b
pkg_deps=(core/glibc core/readline)
pkg_build_deps=(core/gcc core/make core/coreutils)
pkg_lib_dirs=(lib)
pkg_include_dirs=(include)
pkg_bin_dirs=(bin)

Writing Plans

The plans must include a plan.ps1 or a plan.sh file. The developer can consist of both files if Linux and windows are targeted simultaneously. To create a plan, Follow these steps-

1. Download the hab CLI and follow the instructions in the official documentation.
2. Run hab CLI setup
3. Create a plan using hab plan init

For defining a plan in case of multiple platforms, the structure would look like this

app_root/

└── habitat/

        plan. sh

        plan.ps1

Build time Workflow

Specific steps need to be included in the plan file for installation and configuration. These steps define how you will install your application files into a package.

• Create a package identifier

The origin is used to set privacy rules, store packages, and collaborate with fellow developers. To build artifacts for an origin, it is necessary to have information about its private key. Origin keets are kept in $HOME/.hab/cache/keys when running as a non-root user and /hab/cache/keys when running as a root.

Standard naming conventions are used to declare the name of your package.

 

• Add the information about licensing and details of the contact

The developer should provide the contact information, and most importantly, the User should update the value of pkg_license. The value should indicate the type of license assigned to the package.

 

• Download the source files

            Add the source of your file in pkg_source. Chef habitat allows obtaining files

            from Github. An example of performing this operation is-

In the case of Linux,         

do_download() {
  export GIT_SSL_CAINFO="$(pkg_path_for core/cacerts)/ssl/certs/cacert.pem"
  git clone https://github.com/chef/chef
  pushd chef
  git checkout $pkg_version
  popd
  tar -cjvf $HAB_CACHE_SRC_PATH/${pkg_name}-${pkg_version}.tar.bz2 \
      --transform "s,^\./chef,chef-${pkg_version}," ./chef \
      --exclude chef/.git --exclude chef/spec
  pkg_shasum=$(trim $(sha256sum $HAB_CACHE_SRC_PATH/${pkg_filename} | cut -d " " -f 1))
}

In the case of Windows-

Function Invoke-Download {
  git clone https://github.com/chef/chef
  pushd chef
  git checkout $pkg_version
  popd
  Compress-Archive -Path chef/* -DestinationPath $HAB_CACHE_SRC_PATH/$pkg_name-$pkg_version.zip -Force
  $script:pkg_shasum = (Get-FileHash -path $HAB_CACHE_SRC_PATH/$pkg_name-$pkg_version.zip -Algorithm SHA256).Hash.ToLower()
}

• Define Dependencies

There are generally two types of dependencies, runtime, and build-time.

The developer must declare build dependency in pkg_build_deps and any run dependencies in pkg_deps.

Plan Quickstart

While the developers work with Plans, it is essential to include a plan. Sh or plan.ps1 file in the root directory of the planning context. Both these files are included when the application targets both Linux and Windows.

The first requirement is to create a plan. The simple way to do this is hab plan init subcommand. This command creates a directory known as plan context that includes many plan and configuration files and hooks.

Any environment variables you will set will be used to populate pkg_* variables.

To auto-populate the pkg_* variables,

env pkg_svc_user=someuser pkg_deps="(core/make core/coreutils)" \
   pkg_license="('MIT' 'Apache-2.0')" pkg_bin_dirs="(bin sbin)" \
   pkg_version=1.0.0 pkg_description="foo" pkg_maintainer="you" \
   hab plan init yourplan

Now you can modify the plan file according to your needs.

Plan Contents

The best practice to create a plan depends on the user and requirements.

Package Metadata 

Package Metadata describes the content to the user. It gives additional information about the author, version, and repositories.

These guidelines need to be followed strictly:

• pkg_description
• Pkg_license should be in SPDX format
• pkg_name
• pkg_origin must be set to core
• pkg_source
• pkg_upstream_url
• pkg_version must be the complete version number of the software

Package Naming Conventions  

The value of the name should be the same as the project, and the directory's name should be the same as the repository name. Each package is identified by a unique string containing four sub-strings separated by a forward slash (/).

`origin`/`name`/`version`/`release`

Plan Basic Settings  

A core plan demands the following-     

• pkg_name is set
• pkg_origin is set
• pkg_shasum is set
• pkg_description is set        

README.md 

A file should also contain basic information about the maintainer, its uses, and step-by-step detail on how to follow up with the application.

The official documentation may come in handy for more information on Plan Contents.

Scaffolding

Scaffoldings are designed to carry out automated builds for the application. They create the essential application lifecycle hooks and add runtime dependencies. Scaffolding also ensures reliability.

• Ruby, Gradle, and Node.js are supported for carrying out the scaffolding.
• A package must contain a lib/scaffolding.sh file for scaffolding tasks.

Binary Wrapper

Using a Binary wrapper, you can write plans for these binary artifacts without extensive handling.

A Chef habitat build has various phases like download, verification, unpacking, installation, etc. There is a feature of overriding these phases according to the user.

The following example shows the way to override the do_build and do_install phases-

(...)
do_build() {
  return 0
}

 

do_install() {
  mkdir -p $pkg_prefix/bin
  cp $PLAN_CONTEXT/bin/hello_codingninjas $pkg_prefix/bin/hello_codingninjas
  chmod +x $pkg_prefix/bin/hello_codingninjas
}

Relocating Library Dependencies

Many binaries' hardcode dependencies on the Linux Operating System to /lib and /lib64. In this way, the guarantee of isolation is not provided.

So, to relocate the dependencies, we use patchelf(1) utility within a plan.

patchelf --interpreter "$(pkg_path_for core/glibc)/lib/ld-linux-x86-64.so.2" \
  "${pkg_prefix}/bin/somebinary"

In some situations, the above method does not work. This situation arises because of the version difference between the glibc software and the glibc Chef habitat Package. In this case, you have to rely on the default dependencies.

You can see the patchelf documentation for more reference.

Frequently Asked Questions 

What are dependencies? 

When a software segment is dependent on another, it is referred to as a dependency.

What is the benefit of writing plans? 

They give a flow of how to work with applications from building to deployment.

What is $pkg_prefix? 

It signifies the absolute path of the package.

Where can you find your plan file?

The plan file is found in the Habitat Directory.

What is Chef Habitat Builder?

Chef Habitat Builder provides package storage, search, and an API for clients.

Conclusion

In this blog, we studied the Plans in Chef Habitat. We discussed various Subtopics like writing plans, scaffolding, Working with Binary wrapper packages, and overriding.

For more information on Chef Habitat, Refer to-.

• DevOps Interview Questions - Coding Ninjas Coding Ninjas Studio
• Ansible Interview Questions 
• Ansible vs. Chef
• Policies in Chef Infra
• Containers Concept in Chef Habitat

Refer to our guided paths on Coding Ninjas Studio to learn more about DSA, Competitive Programming, JavaScript, System Design, etc. Enroll in our courses and refer to the mock test and problems available. Take a look at the interview experiences and interview bundle for placement preparations.

Happy Coding!