Chef Interview Questions

The following Chef interview questions and answers presented by us will cover a wide range of basic-level topics associated with Chef, ones as the architecture of Chef, what Chef Supermarket and its different search indexes are, the occurrences in Chef Client run and many more. Rest assured, going through these Chef interview question-answer sets will help you realise your dream as to either be a Chef Developer, Full Stack engineer, or other top profiles. Practising these assisted by experts who will prepare you completely for your next Chef interview.

  • 4.4 Rating
  • 50 Question(s)
  • 30 Mins of Read
  • 12573 Reader(s)

Intermediate

Chef architecture

Chef architecture has three main components, Chef server, Chef node, and Chef workstation. At the workstation, code for provisioning and managing the infrastructure is created and tested. This code is implemented as recipes and a collection of recipes is known as a cookbook. Once the cookbook is ready, it is pushed to the Chef server from the workstation. We use the “knife” command-line tool or Berkshelf” to upload the cookbook. Chef Server typically acts as a hub for the infrastructure code. Chef node could be any system that is managed by Chef. It could be an actual or virtual or cloud machine.

Chef nodes communicate with the Chef server using an application called “chef-client”.Chef architecture works on pull configuration that means we don’t have to perform any actions on the Chef server to push the configurations to Chef nodes.“The chef-client” pulls down all the data needed for the Chef node to meet the desired criteria. This is also referred to as Chef run. During Chef run, a tool called OHAI collects the current status of the attributes of the node.

Chef:

  • Has a client and server architecture. Apart from a Chef Client and Server, there is one another important component called a Chef Workstation.
  • The Chef workstation and Chef client could be windows or Linux/Unix machines, but the Chef server supports only Linux/Unix.
  • The Chef configuration management tool is in the market for a long time hence is stable, mature and has good community support
  • Chef uses the pull configuration
  • Chef uses an imperative language written using the ruby DSL (Domain Specific Language)
  • Chef uses a command-line tool called knife for communication.
  • Ideal for developers with advanced programming skills

Puppet:

  • Has an agent/master architecture.
  • Puppet agent supports both Windows and Linux/Unix whereas puppet master support only Linux/Unix
  • Puppet is also in the market for a long time hence is stable, mature and has good community support
  • Puppet also uses the pull configuration
  • Puppet uses a declarative language written using the puppet DSL (Domain Specific Language)
  • Puppet uses SSL (Secure sockets layer) for communication
  • Ideal for developers with less programming skills

Ansible:

  • Ansible is agentless where no software needs to be  installed on client systems.
  • Ansible server supports only Linux/Unix
  • Ansible is a new player in the market but shows a promising growth trend
  • Ansible uses the push configuration
  • Ansible uses YAML (Ain’t Mark-up Language)
  • Ansible uses SSH(Secure socket shell) for communication
  • Ideal for developers with basic programming skills

Test Kitchen is an in-built Chef tool to test your recipes in a sandbox environment before moving it to production. We know that Chef does the provisioning and managing of infrastructure through code. A defect in the code can even change the production environment so we need an isolated environment where we can test our infrastructure code without worrying about the after-effects and the Test kitchen provides this. The test kitchen also helps us to test our infrastructure code on any platform by creating an instance with the respective OS. System tests using InSpec is often performed using Test kitchen as it helps us to test all actions in a sandbox environment. For eg: installation of the “Apache “ server on a Windows system is tested in Test kitchen by actually installing it on a provisioned Windows system.

.kitchen.yml created while generating a cookbook is the configuration file for the Test Kitchen. The test kitchen creates a sandbox environment using vagrant or docker.  We can create multiple kitchen instances using a single .kitchen.yml file. The Test Kitchen is now often used in the CI pipeline of the applications to run the tests faster.

Chef Supermarket is a repository for cookbooks shared publicly. It’s a repository similar to GitHub. We can have two types of supermarket, private and other public. Public Chef Supermarket is hosted by Chef Software. We can find many general cookbooks like for eg: Nginx in public Chef supermarket. If any of the publicly shared cookbooks meet our requirements we can use them from the supermarket. We often come across situations where we need to modify the behavior of community cookbooks to achieve our requirements. This could be done by creating wrappers. So Chef supermarket is a central repository where one can share, download or collaborate on cookbooks.

Many companies prefer to create a private supermarket to share their company-specific cookbooks internally. Organisations whose cookbooks have security-related data prefer to only use private Chef Supermarket. They install a private supermarket by using “supermarket-omnibus-cookbook” available in Chef public supermarket. Retrieval of a cookbook in a private supermarket is faster compared to the public supermarket as we have fewer cookbooks to search from and due to its proximity.

Chef Client Run (CCR) is performed on each node by following several steps to ensure that the Chef node reaches its desired state. The different steps include

  1. Get node data – Here the "client.rb" file present in Chef node is read and retrieves the Chef node data through the OHAI processes. The most important data acquired here is the node name.
  2. Authentication – Authenticates the Chef node with the Chef server using the RSA private key.    
  3. Get and rebuild the node object - Once authenticated the node object is pulled down from the Chef Server and then rebuilt. If it is the first client run no node object will be present on Chef Server.
  4. The run list expanded - Run list of the rebuilt node object is expanded to get a complete list of roles and recipes that will be applied to Chef node.    
  5. Sync cookbooks - The Chef node also checks with the server for all the cookbooks required to perform the run list. If the cookbooks don’t match with the ones already cached in the node through previous client runs, then the changed files or new files are downloaded.
  6. Reset node object - All attributes in the node object is set according to attribute precedence.    
  7. Load cookbooks and collect resources – The cookbooks are then loaded to the memory, analyzed closely and all the resources required to perform the operations are collected.    
  8. Converge – This is where the actual execution of the resources collected takes place on the Chef node.    
  9. Update node object - Node object in the Chef server is updated with the node object built during the Chef Client run.
  10. Chef run wait - Chef client run waits for the next time it’s run. 

The “kitchen test” command is used to fully test the cookbooks in a CI/CD pipeline and is an elaborate process consisting of creating a new instance, converging it, verifying and then destroying the instance. Since this is an elaborate process it is not suited to be used in the development phase of a cookbook. "kitchen converge" and "kitchen verify" commands are more useful for the cookbook development phase.

“Kitchen converge” applies the cookbook to the existing sandbox environment. It will install the chef-client, load the cookbooks and other necessary files and goes ahead with the first Chef client run using kitchen.yml attributes. “Kitchen converge” has two types of return codes. A zero denotes success and a non zero value denotes failure at any step. If “kitchen converge” fails, try to delete the kitchen instance with “kitchen destroy” command and then run “kitchen converge” once again.

“Kitchen verify” helps in validating the state of the kitchen instance against test suites specified in .kitchen.yml file. Often "kitchen converge" and "kitchen verify" are frequently used to develop infrastructure code using Test Driven Development.

“metadata.rb” file is at the top level of every cookbook directory and gets created as soon as a cookbook is created. (For JAVA programmers the concept is similar to a constructor getting created when an object is created!) It specifies all the dependencies required to correctly deploy a cookbook to its nodes. The Chef server compiles this metadata.rb file into metadata.json file and stores it. We can edit the metadata in the metadata.rb file and should be recompiled every time by the Chef server for the changes to be implemented. Metadata.rb file is compiled when

  1. a cookbook is uploaded to the Chef server
  2. when the cookbook metadata knife subcommand is run and
  3. when "knife cookbook create" subcommand is run, then the knife creates metadata.rb file automatically.

Metadata.rb files have entries under ‘depends’ keyword which specifies the different dependencies required to successfully deploy the cookbook in a specific node. If these dependencies are not given properly we may often face errors while deploying cookbooks and Chef nodes would not be configured as expected. Apart from "depends", we have other details given in the metadata.rb file like license, version, gem, etc. which can be parametrized using different operators (=,>=, >, etc)

From Chef 0.10, a ‘chefignore’ file is used to ignore unwanted temporary files like swap files, version control files, build data files, etc while uploading to the Chef server. This file is could be available at any of the subfolders of your cookbook repository. This file helps us to stop uploading unwanted files or confidential files to Chef Server.

For eg: while using Vim editor, it leaves behind swap files. These are of no use in reusing the uploaded cookbooks. These will get uploaded into the Chef Server unless specified in the chefignore file. The following entry in the chefignore file stops all swap files created by Vim editor being uploaded. This helps us to stop accidentally uploading these swap files which is not related to the cookbook and not required for the correct functioning of the cookbook.

# vim
*.sw[a-z]

Chefignore file can use *,** and? wildcards to specify the ignore patterns in chefignore file. The pattern matching in the file is concerning

  • root of the cookbook
  • Relative directory names

The different search indexes for node data in Chef Server are as follows:-

  1. Data bags: Data bags are like a container where global data is stored and shared across the Chef nodes and these data are accessible by Chef Server. Data bags are used to securely store information like admin credentials etc in the form of JSON files. These are indexed and are loaded in a Chef search.
  2. Environment: We at times want our nodes to converge to a testing environment or maybe to a production environment so that admins can know in which stage of the code development, the node is included. Environment details are also updated in Chef Server and could be searched for. “_default” is the default environment for any Chef node. Multiple environments could be added and worked upon.’
  3. Node: Node is a system that we want to be configured and maintained using Chef Infra Client. The node could be a physical server or a virtual machine or a cloud machine. Details of the node are also updated in Chef Server and searched upon.
  4. Role: Role is used for defining certain patterns or processes across all Chef nodes. Multiple configurations of the nodes at a different time could be achieved in Chef using the “roles” feature.

Recipes are the basic configuration element in any organisations. Its a programmatic representation of the desired state of the nodes. Usually written in ruby with Chef Domain Specific Language (DSL), these specify all the standards (policies) or updates that the nodes should follow. Recipes are often a collection of resources that are the building blocks of the infrastructure of any organisations.

Cookbooks are a collection of recipes. Apart from recipes, cookbooks contain other elements like metadata, attributes, libraries, resources, templates, and tests which helps the nodes to achieve their desired state. Cookbooks can be created by Chef commands or by the Chef command-line tool called Knife. The cookbooks are the fundamental units of chefs and are uploaded to the Chef Servers and then read and deployed by the Chef Clients at the nodes. Cookbooks are standalone entities that could be transferred easily between the Chef server and node. It typically implements a scenario of infrastructure and has everything required for the scenario. Cookbooks could be version controlled and hence help the development team to collaborate and share cookbooks.

The “knife upload” command is used to upload the cookbooks to the Chef server. It does not help in managing the cookbook dependencies. So knife command is not chosen for very complicated and large cookbooks with dependencies that in turn might be dependent on others and so on. For eg: Assume that a cookbook called “my-app” depends on community cookbook “nginx” which in turn depends on another community cookbook “ohai”. When we try to upload “my-app” to Chef Server using the “knife upload” command, we have to make sure all other dependent cookbooks are uploaded manually to Chef Server. This problem is solved using “berkshelf upload”

Berkshelf command is similar to knife command and helps to upload cookbooks to Chef Server. But it also helps in the management of cookbooks outside of Chef repository. This is quite useful in case of large and complex cookbooks with lots of dependencies. “berkshelf upload” will upload all dependent cookbooks to the Chef server automatically. All the dependent cookbooks are fetched using the “berks install” command of the Berkshelf tool.

InSpec is an in-built testing framework for testing and auditing infrastructure in Chef. A sample InSpec test to verify whether “Nginx” server is installed and running in a system could be written as follows:

```control 'Nginx-install-1.0' do
     title 'Check if nginx is installed'
     describe package 'nginx' do
      it { should be_installed }
     end
   end  
   control 'Nginx should be running' do
     describe service 'nginx' do
   it { should be_running }
     end
   end```

Main components of InSpec tests are:

  • Control: A requirement is defined inside a control block
  • Title: Title defines the metadata of the control block describing the importance of the requirement.
  • Resource: Resources are the basic building blocks of infrastructure. A control block may have multiple resources. Resources could be anything like file, package, service, etc.
  • Describe: Tests for a particular resource is grouped into a describe block. A control block should have a minimum one describe block. A describe block is defined within a “do end” block
  • It or its: Each line starting with "it" or "its" is a test to access resource-specific matcher. “should be_installed” and “should be_running” are in-built methods in DSL to verify whether the package is installed and whether the service is running.

Chef Client run could be performed in the following modes:

  1.  Local mode: In this mode, we can run the Chef Client against the local Chef repository mimicking the behaviour as if it was running against a Chef Server. This is achieved through ‘Chef zero’ (previously a standalone tool)which acts as a lightweight Chef Server. Running in local mode is the easiest way to quickly test and verify the infrastructure code, though this has some disadvantages of not testing the authentication or security checks which are needed when we connect to the actual Chef Server
  2.  Why run mode: Why run mode gives you a preview of what will happen on your node when you perform Chef Client run. In why run mode no actual modifications are done on your node. This mode follows the principle of no-op(no operation). All actions that happen in normal Chef Client run is performed until the actual configuration of the node.
  3.  Run in FIPS (Federal Information Processing Standards) mode: Chef Client run can be performed in FIPS mode to follow the FIPS standards. Any violation of these standards will throw a run exception.
  4.  Run as a service/daemon: In this mode, we can make the Chef Client run happen in our desired time intervals. Chef Infra Client cookbook from GitHub repository is used to perform Chef Client run.
  5.  Run with elevated privileges: When we are trying to configure nodes with different OS like Windows or Linux we often run into some errors while performing Chef Client run, this is mostly due to the access privileges on these systems. The client run solves this issue by providing the ability to run the Chef Client with root access rather than by a local system user
  6.  Run as a non-root user: This mode is helpful when multiple teams (devs, administration, etc) are involved in your infrastructure development and not everyone needs the same amount of accesses. You can limit the access and make the Chef Client run as a non-root user.

We can update the Chef run lists with the below two options:

 A) The Chef run list can be updated using the knife commands:  Knife is a command-line utility tool that securely communicates to the Chef Server. We have different commands for adding, removing and setting recipes in the run list.

For eg: 

```knife node run_list add <NODE_NAME> <RUN_LIST_ITEM> (options)``` commands could be used to add a recipe or a role in the run list of a node.

Similarly 

```knife node run_list remove <NODE_NAME> <RUN_LIST_ITEM> (options)```  command could be used to remove from the run list.

We can also specify the run list for a node while bootstrapping the node using the “knife bootstrap” command.

B) We can also update the run list of a node through the Chef management console. The Chef Management Console is a GUI interface through which we can manipulate the Chef run list. But it should be noted that as per the latest updates on Chef this interface is soon to be depreciated, and replaced with Chef Automate.

Unit tests are easy to run simpler tests used to test a single unit or component of the infrastructure. Chef uses ChefSpec, an in-built testing framework to write unit tests for the infrastructure. In the infrastructure point of view unit tests are verified on the resource collection created during the Chef Client run and not by actually configuring the node.

For eg: If we want to write a unit test to verify if the “Apache” package is installed, no actual installation of the Apache server is tested but just verifies if the package “Apache” is added to the resource collection list. Resource collection will have a list of all actions that will be performed in the actual Chef Client run.

Integration tests in Chef's perspective are system tests where tests are performed by provisioning a new system and configuring the system to our requirements. This takes a lot of time as we have to perform the actual configuration of the provisioned system. System tests are also a costly affair compared to unit tests as we need to provision a new system exclusively for testing purposes.

“file” resources in Chef are used to manage files in a Chef node during a chef-client run . A sample file resource is as follows:

```file ‘/tmp/index.html’ do
     content 'Hello World'
   end```

“file” resource has a name field that defines the resource block. In the above example ‘/tmp/index.html’ defines the name of the file which is managed by Chef with the path. Various actions performed by file resource is as follows:

  • create : creation of a file
  • delete : Delete a file
  • touch : Changes the access time and modified time of the file
  • nothing : Do no action unless notified by other resource
  • create_if_missing : Create a file only if the file is not present in Chef node

“cookbook_file” resource is used to copy files from the “files” folder of the Chef cookbook to a path in Chef node during a chef-client run. Sample “cookbook_file” is specified as below:

```cookbook_file '/var/index.php' do
source 'index.php'
action :create
  end```

Here file “index.php” from “files” folder in the cookbook is copied to “index.php” file in “/var” path in Chef node. If file not present it’s created at the path.If the file is present and if the checksum of the “index.php” file matches the “index.php” file in the cookbook of Chef Server, no file transfer is performed.

“template” resources are used to dynamically generate static files from an embedded Ruby template placed in the “templates” folder of a cookbook. For eg:

```template '/etc/motd' do
     source 'motd.erb'
 end```

“/etc/motd” is the location at which a new file is created on Chef node during a chef-client run  based on the template file “motd.erb” placed in the “templates” folder of the cookbook.A template file may contain Ruby statements and expressions unlike in “file” resource or “cookbook_file” resource.

Attributes define a node! In other words, it’s a characteristic of your node when it runs in a specific role under a specific environment against a specific cookbook or recipe. Hence attributes can be found in all these Chef components such as roles, environment, cookbooks and even as a separate set called “attribute files”. The different types of attributes available in the chef are:-

  1. default: This is the most generic type of attribute and also the one with the lowest precedence. These are largely used in cookbooks so that nodes remain the same way as they are and function further. At the start of every Chef Client run, the default attributes are reset automatically
  2. force_default: As the name suggests with the use of these attributes, the default attributes are forced to take up the new values assigned to them. The use of force_default attributes comes when we want our nodes to run in a different role or environment.force_default attributes defined in a cookbook have higher precedence than default attributes defined in a role or environment.
  3. normal: Unlike default attributes, these are not reset during a new Chef Client run. They just persist in the node object.
  4. override: Generally found in recipes and are used to override any default, force_default or normal attributes. These are also reset before a    Chef Client run.
  5. forced_override: These attributes make sure that the override attributes defined in a cookbook are forced to take up the new values assigned to them.
  6. automatic: These attributes are defined by Ohai to mainly understand the state of the node at the beginning of a Chef Client run. These have the highest precedence

In the Chef architecture, we have multiple Chef nodes managed by a Chef Server. Hence care must be taken to authenticate a Chef node with Chef Server. No stranger nodes should be able to send requests to Chef Server. So we use the “knife ssl fetch “ command to copy the self-signed SSL certificate of Chef Server to the trusted certificates directory in a respective node or a Chef Workstation. Only nodes or workstations with a valid SSL certificate could communicate with Chef Server without any errors. The URL for Chef Server is often specified in “client.rb” file in Chef node and “knife.rb” file in Chef Workstation. We can override this setting by supplying the URL of any Chef Server when the “knife ssl check” and “knife ssl fetch” command is run

“Knife ssl check” command is used to verify if the SSL certificate has a valid X.509 certificate property. “knife ssl check” and “knife ssl fetch” could be used to troubleshoot communication errors with Chef Server. This process is not valid for verifying communication with Hosted Chef Servers.

execute resources in Chef is used to execute a single command. All commands executed via execute resources are not idempotent and are specific to the environment in which it’s run. We need to use guards like “not_if”, “only_if” to make the execution of the resource idempotent. During a Chef Client run, guards property verifies the state of the Chef node. "execute" resources could be run alone or in combination with other in-built Chef resources like templates, etc. "execute" resources could be used when we need to reuse existing shell scripts for infrastructure configurations. We need to specify the command to run the shell script in "execute" resource block.

For eg:

```execute 'apache_test' do
     command '/usr/apachectl configtest'
end```

“apache_test” is the name provided for the "execute" resource block. The actual command run is “/usr/apachectl configtest”.

Execute resource could have only two actions, nothing and run. If the action specified is "run", the command provided is executed. If the action specified is nothing, the command provided in the "execute" block is prohibited from running. script resource is often confused with execute resource. Script resource is used to execute a script using an interpreter provided like bash etc

Chef nodes in your infrastructure may perform different roles at different times. For eg: Few of the Chef nodes would be web servers and one would be a load balancer. Grouping of the nodes into web servers and load balancer could be achieved in Chef using “roles” feature. The roles are defined through the role attributes. You can assign roles to your identical servers and all of them can go ahead and run the same run list mapped to the corresponding role. This helps in avoiding the process of running run lists manually on each node each time when you have many nodes performing the same function.

For configuring a new role for our node, we can make use of Knife commands. As a prerequisite, any previous roles or recipes on the run list can be removed using the “knife node run-list remove” command and then we can go ahead and add our newly added role using the “knife node run-list add role” command. The role attributes could only be defined as either ‘default’ or ‘override’ attributes. When a Chef Client run happens, the role attributes are matched against the attributes present on the node and if it takes precedence over default attributes, new settings are applied.

Bootstrap is the process by which the Chef Client is installed on the Chef nodes. Chef nodes could be physical, virtual or cloud machine. The bootstrap process can be done in two ways:

  1. Using the “knife bootstrap” sub-command

The “knife bootstrap” command is issued from the Chef workstation. The command first creates an SSH connection with the node then installs the Chef Client along with all its dependencies on the node. This command also generates keys and register the node with Chef Server. In earlier versions of Chef Client, "ORGANIZATION-validator.pem" file was used to authenticate the Chef node with the Chef Server during the first Chef Client run. Starting from Chef Client 12.1, "USER.pem" file could be used to authenticate the new Chef node. This process is also known as “validatorless bootstrap”.

  1.  Manual install in the node directly

We need to login to the Chef node and manually install the chef-client. Once it’s installed we need to manually set up the connection with the Chef Server.

Unattended Installs are often done on Chef nodes created in AWS Auto Scaling, AWS CloudFormation, Rackspace Auto Scale, and PXE. Chef Client is installed without SSH connection on the Chef nodes.

Security is an important feature in infrastructure management, in Chef this could be achieved through data bags. While preparing recipes for setting the different nodes we might need to provide some sensitive data as well for example like authorization credentials. It is not a good practice to hard code them as this may lead to many security risks. It is here where we can make use of data bags. Data bags are places where we can save these important data, the data gets stored in JSON format (Key-value pairs).

Data bags are indexed hence can be called whenever required by the recipes or cookbooks through a search. The data bags are encrypted and hence the contents of the data bags can be accessed only by having a decrypting key, this is how data bags give security to the chef infrastructure. Other than encryption strategies, a Chef Data Bag can be secured using a ‘Chef Vault’. Data bags can be created through the commands in the knife utility tool or manually. Data bags could be considered as a method to store global data shared across nodes.

Setting up environments is an important part of infrastructure management. We know that for the successful development of any product we need different environments like a development environment, testing environment, production environment, etc. The concept of environments in Chef is the extrapolation of the same. We at times want our Chef nodes to converge to a testing environment or a production environment configurations. Hence we can have a particular configuration for a testing environment and different configuration for the production environment. This switching of node behaviour is achieved through Chef environment settings. Environments help administrators to easily identify the stage where the particular node is a part of.

If we don’t declare any environments the Chef assumes the nodes to be in “_default” environment. Minimum one environment exists in an organisation. Environment attributes have higher precedence than default attributes of a node. Environment data could be stored in Ruby format or JSON format. An environment could be created as follows:

  • Using Chef Management console at Chef Server
  • Using the knife tool
  • Creating a ruby file in an environments subfolder of chef-repo
  • Creating a JSON file in chef-repo
  • Using Chef Infra Server REST API

Chef Software hosts a repository for general-purpose community cookbooks called Chef Supermarket. Hence Chef users can use these designed and tested cookbooks wherever possible which in turn will reduce the infrastructure development time. But often we come across situations where we need to tweak the community cookbooks for our requirement i.e where wrapper cookbooks are created. Wrapper cookbooks are similar to normal cookbooks but they use recipes from other cookbooks also.One another scenario where wrapper cookbooks are created is where you have a large number of baseline cookbooks and we need to organise them for maintainability.

We create wrapper cookbooks and put in external recipes from other cookbooks for our use. This could be achieved by modifying

  1. metadata.rb file to include details about all dependent cookbooks. All dependent cookbooks are specified in “depends” directive
  2. Using ‘include_recipe‘ directive in a recipe to include external recipes from other cookbooks

Wrapper classes can be further customized to your needs through some simple attribute changes. Attribute definitions and run lists of the nodes could also be version controlled using wrapper cookbooks.

chef-repo in your Chef Workstation is a directory that holds all details about cookbooks, environments, roles, and data bags.chef-repo is like source code and need to be synchronized with version control system like Git.chef-repo has following directories and files

  • .chef folder is a hidden folder that stores all validation files required for authentication between Chef node, Chef Server and Chef Workstation.
  • cookbooks folder to store all cookbooks used by Chef Client to configure Chef nodes. While using "knife upload" cookbooks from this folder are updated to the Chef Server
  • data_bags folder to store all data bags created for an organisation. A single data bag creates a subfolder with a JSON file.
  • environments folder is used to store all details about various environments available in the Chef Server.
  • roles folder contain all definitions of various roles available in the Chef Server.
  • Chefignore file is used to ignore unwanted files like swap files, version control data, build output data so that these details don't get uploaded to Chef Server. Wild cards like ?*,** could be used to specify ignore patterns in chefignore files. This file could be located on any sub-folders in chef-repo.

Advanced

Chef-apply is an in-built utility in Chef development kit. It helps to run a recipe from the command line. The basic syntax for chef-apply is as follows:
chef-apply test.rb, where test.rb is the recipe which is run.
chef-apply with “-e” option could be used to execute a resource. For eg:
chef-apply -e "package 'nginx'" installs ‘nginx’ package.chef-apply could be run in a why-run mode where everything of a chef-client run is performed except modification of the system.
chef-client is an agent that is run on every node to modify the node so that it attains the desired state. chef-client applies cookbook on to any node managed by Chef Server. During a Chef Client run the following activities take place

  • Registering a node with Chef Server
  • Synchronising cookbooks to be run on Chef node
  • Rebuilding node objects retrieved from Chef Server. In the case of the first Chef Client run, there won't be any node object from Chef Server.
  • Compiling resource collection
  • Performing all actions on the node to configure the node to the desired state.

During Chef Server creation, you are asked to download Starter kit to Chef Workstation. After downloading, unzip the starter kit and move it to your desired path. Every Time the Starter Kit is downloaded, a new key pair is created and resets the older one. Starter Kit has all the configuration details for communicating with Chef Server. It helps us to create a folder structure for developing cookbooks. Main directories present in Starter Kit would be as follows:

  • chef-repo: All details like cookbooks, roles, environments, data bags are all stored in chef-repo. Whenever Chef client is run on the local mode, it looks for chef-repo path and all paths are relative to chef-repo.chef-repo is like a source code which is usually in sync with a version control system such as Git. Hence all modifications done in the chef-repo could be tracked down.
  • .chef folder : .chef folder is a hidden folder found in chef-repo directory . It has a knife configuration file and .pem files used as secret authentication key files. All configurations for knife commands are present in knife configuration files.

Whenever a cookbook is modified, the new version details of the cookbook is updated in “metadata.rb” file and then uploaded to Chef Server using knife upload or berkshelf upload. There are 3 ways in which the new cookbook would be applied to the desired Chef nodes.

  • We can run chef-client with latest cookbooks from Chef Server on all nodes or specific nodes using “knife ssh” command. For eg:
    knife ssh '*:*' 'sudo chef-client'
  • SSH into the respective node where you want to run the latest cookbook and run the chef-client .chef-client picks up the latest cookbook in the Chef Server unless otherwise specified as a cookbook restriction says for eg: in an environment.
  • chef-client could be run as a daemon or service at a specified time. Chef Infra Client cookbook available in GitHub repository could be used for this purpose.chef-client with “USR1” option could be used to trigger chef-client and do the node convergence. Apart from making a chef-client run, a service we can utilise Cronjob to run it often.

Handlers are used to solve different situations that arise during a Chef Client run. There are 3 types of handlers in Chef.

  • Exception: Exception handler is invoked whenever a situation arises where the Chef Client fails. A recipe with “chef_handler” resource is added to the run list of a node which gets loaded first on every Chef Client run.
  • Report: Report handlers are used when Chef Client run succeeds and then wants to report back more information about the successful run. These are loaded first on every Chef Client run by adding a recipe with “chef_handler” resource on the nodes run list.
  • Start: Start handlers are used to trigger events at the start of a chef-client run. These could be loaded first on every Chef Client run by adding the “start_handlers” in the “client.rb” file. If we are using chef-client cookbook start_handlers are installed using the “chef_gem” resource. Hence, “start_handlers” will be present on the node before a chef-client run.

Exception and report handlers provide a wide range of information about the Chef Client run and these data could be used for analysis across the organizations.

Ohai in Chef is used to detect Chef node attributes and these are provided to chef-client during the Chef Client run. Ohai collects details about various platforms, network data, memory data, CPU data, kernel data and other configuration details. All these attributes collected are automatic attributes that are not changed even after Chef Client run. Automatic attributes are having higher precedence overall default, override, force-default and normal attributes. Ohai gets installed with the Chef Client installation.

The ohai resource is available in Chef to reload the configuration of a node. These are often used to refer back system attributes that are changed by a recipe like a recipe that creates a new user during a Chef Client run. The syntax is as follows : 

ohai 'name' do
plugin   String
action   Symbol # defaults to reload if not specified
end

where:

  • ohai is the resource executed.
  • name is the resource block name.
  • action is performed to bring the node into the desired state.
  • a plugin is the property of the resource.

Foodcritic is an open-source tool used to detect common problems in our cookbooks like style, syntaxes, best practices, correctness etc. Foodcritic validates the Ruby code written in cookbook against several rules and creates a list of violations without running a Chef Client run. List of rules is available in Foodcritic website.

A foodcritic is often run from chef-repo with the name of the cookbook whose correctness we are going to verify. The correctness of the intention of the recipes in the cookbook is not checked instead the structure and syntax of the cookbook are checked. Whenever a Foodcritic detects violation it doesn't typically mean a change of code. For eg: Assume that rule number “FC003” defines a scenario where recipe uses a search method to get relevant data from the Chef Server. The rule suggests that an error may occur in the cookbook when the Chef Server is unavailable. We only bother to adopt this rule only if chef-solo is a part of our project workflow as chef-solo doesn’t work with Chef Server.

Food critic could also be used with Continuous Integration servers like Jenkins and Travis thus enabling automated checking within the delivery pipeline of our project.

ChefSpec is an in-built testing framework for testing resources and recipes. It’s a part of Chef Development Kit. Usually, unit tests are written in ChefSpec and is an extension of Behavior Driven Development framework called RSpec for Ruby.

A sample unit test to check if “Nginx” package is installed or not is written as follows:

describe 'nginx::default' do
 context 'When all attributes are default, on Ubuntu 16.04' do
      let(:chef_run) do
      runner = ChefSpec::ServerRunner.new(platform: 'ubuntu', 
version: '16.04')
      runner.converge(described_recipe)
      end

      it 'install a package' do
      expect(chef_run).to install_package('nginx')
      end
end

where 

  • describe block denotes a scenario
  • context block defines test within tests and each context block is executed individually.
  • ChefSpec::ServerRunner is used to simulate Chef Client run without actually configuring anything. In our example without actually installing “Nginx” server
  • “It” is where we actually write the test using the Ruby DSL.

Custom resources in Chef are add on resources transported as a pat of cookbooks and used by Chef Client. These are reusable in the same way as pre-defined resources in Chef. Custom resources are kept as a separate Ruby file in the resources folder of a cookbook. For eg: Assume that we need to create a custom resource called “website” that make use of in-built resources of Chef like file, package and service resources.
“website.rb “ file looks as follows:

property :home, String, default: '<h1>Welcome!</h1>'
action: create do
  package 'nginx'

  service 'nginx' do
        action [:enable, :start]
  end

  file '/var/www/html/index.html' do
          content new_res.homepage
  end
end
action :delete do
  package 'nginx' do
       action :delete
  end
end

Where

  • “Home” is the property that sets the default value “Welcome!” for index.html file.
  • The new resource has two actions, to create and delete. Create is the default action.

The website resource is named after the cookbook name and the file name in the resources folder. Hence if the name of our cookbook is “sample” our custom resource is defined as “sample_website” and could be used in the cookbook as follows:

sample_website 'nginx' do
  home '<h1>Welcome to the Sample
 website!</h1>'
end

“Knife supermarket download” command is used to download the cookbook available in Chef Supermarket be it private or public supermarket.

The cookbooks downloaded are in the form of tar.gz files and are downloaded to the current working directory. If the specified cookbook is deprecated in the Chef Supermarket the user is notified the same and provides the details of the most recent version of the non-deprecated cookbook. For eg :
knife supermarket download httpd 
downloads “httpd “cookbook from Chef Supermarket.

“knife supermarket install “ command is used to communicate with cookbooks in public or private Chef Supermarket. The downloaded cookbooks are installed in the local git repository unlike in the case of “knife supermarket download” command.“knife supermarket install “ command does the following steps

  • A new vendor branch is created for the cookbook 
  • The cookbook is downloaded in tar.gz format and then untarred and committed to the vendor branch creating a tag
  • The new branch is automatically merged with the master branch. This helps the Chef practitioner to modify the community cookbook in the master branch but still can pull down newer versions of the community cookbook available in Chef Supermarket

Hence this command allows updated upstream versions to be used without losing the local modifications done to the cookbook.

Chef Node is any physical, virtual or cloud machine configured by Chef Client and managed by Chef Server. A “chef-client run” is used to describe a series of steps the chef-client performs when it is configuring a node. During a chef-client run, the specified node is registered with Chef Server. This is done to avoid unwanted requests to be sent to Chef Server from chef-clients. Every request initiated by chef-client is authenticated using Chef Server API and a private key stored in “/etc/chef/client.pem” file in Chef Node.

During the first chef-client run on any node, the node won’t have the private key hence private key specified in the chef-validator placed in “/etc/chef/validation.pem” file is used. If chef-validator is unable to send an authenticated request to Chef Server the chef-client run will fail. After the node gets registered with the Chef Server chef-client attains a “client.pem” private key which will be used for all future authentication requests to the Chef server.chef-validator is not used after the initial chef-client run and hence could be deleted.

Best practices in developing a cookbook are to use 

  • Usage of platform resources instead of custom ones
  • Usage of community resources without creating a new one

These techniques help us to reduce the debugging effort greatly.

Main debugging techniques used to detect defects in recipes and chef-client runs are

  • Use Empty run-list

Run Chef Client with an empty run list. This helps us to make sure that the chef-client run failure is not due to the recipes added in the run list. We are also now sure that the failure is due to the configuration settings of Chef Client. chef-client run failure could also occur due to permission issues of the user at Chef Server and also on the node where Chef Client is run.

  • Verbose logging with knife

A built-in verbose logging of knife with “-v” option could be used to log messages

  • Chef Client verbose logging

Chef Client could be run with verbose logging by using the “-l” option. “-L” option could also be used to specify the location of the log file.

  • Log resource

log resource could be used to log the debug messages while running the Chef Client. This resource is also built into resource collection and run during the convergence phase. If we want to add log entries that are not added to the resource collection, use Chef:: Log. A sample log resource looks as below:

log 'mtr' do
  message 'A info message added.'
  level :info
end

Where
“log” is the resource used
“mtr” is the name of the resource block
“message” and “level” are properties of the log resource defining the message logged and it’s level.

Test-Driven Development is a DevOps practise where code is developed just to make a failing test pass. It follows a red, green, refactors cycle. In the case of Infrastructure point of view, we first write a test and see it fail. Then write the code to make the test pass and then refactor if required. TDD helps to create high quality, simpler code with high modularity.

In Chef, Test Kitchen helps us to perform TDD. We first write the InSpec test and run “kitchen verify” command to perform the test. If the test fails, enough code is written to make the test pass. We converge the node to the desired state using “kitchen converge” command. Then again “kitchen verify” command is run to verify if the test has passed. Then the code is refactored if required when all tests have passed. In places where CI/CD is used, we can use “kitchen test “ command to invoke creation of kitchen instance, converging and verifying and at last destroyed the kitchen instance. Hence helping us to detect the defects very easily and in the early stages of project development.

A cookbook is versioned whenever there is a third party component change, a bug fix, the addition of new features or improvements to existing cookbook. This helps us to easily organise the cookbook and let us know which version of the cookbook has what functionalities. This also helps us to specifically update a version of the cookbook to Chef Server and use it for chef-client runs.

A cookbook version is in the format “a.b.c” where a, b, c are decimal numbers. “a”, “b”, “c”  represents major, minor and patch versions respectively. For eg: 1.1.2 version represents major and minor release version “1” with patch version “2”.Versions like “1.2a.3” or “1.2.3.4” or “3” are not allowed.

A version restriction could be attained by combining a cookbook version with an operator. Following operators are used

= : Equals
>: Greater than
< : Less than
< =: Less than and equal to
> =: Greater than and equal to
~>: approximately greater than. For eg: ~> 3.2.5 denotes cookbooks greater than and equal to 3.2.5 but less than 3.3.0 

 Cookbook versions are specified in the “metadata.rb” file located at the top of our cookbook.

include_recipe method is used to include one or more recipes from cookbooks. It might be recipes from the same cookbook or dependent cookbooks. The syntax for the include_recipe method is as follows:

include_recipe <Recipe name with the cookbook>
For eg :  
include_recipe 'apache2::mod_ssl' 

includes all resources from the “mod_ssl.rb” file in “apache2” cookbook to our current recipe where the “include_recipe” directive is specified. If same recipes are included multiple times using “include_recipe” directive method, only the first is included and rest is neglected.”include_recipe” directive is considered better practice than specifying the recipe in the run list especially when one cookbook depends on another cookbook. This also lessens the burdens of running the dependent cookbooks first by specifying it first in the run list of every Chef node. 

In the case of wrapper cookbooks “include_recipe” directive is used to include functionalities from the dependent cookbooks. If it’s not specified but the dependent cookbooks are specified in the depends section of “metadata.rb” file, an error occurs.

Libraries store arbitrary Ruby code that could be reused across the recipes within any cookbook that depends on the library. This is often located in the library folder of our cookbooks. First and the foremost usage of libraries are to provide helper methods that reduce the code duplication and also provide a mechanism to hide the implementation logic in the recipes. Libraries get loaded first when the Chef loads our cookbooks.It make use of  “ load_libraries_from_cookbook” method from the “Chef::RunContext::CookbookCompiler” class. Typical use cases of libraries are 

  • For creating modules containing methods used in our recipes. Functions are defined inside a module which is in-turn included in our recipes as a mixin. This is done by including module namespace in our recipe using “include” keyword and hence making all methods defined in the module available to recipes as if declared locally.
  • Libraries extend Chef’s core classes and even helps in overriding their methods. For eg: if we need to modify a method in Chef:: Node class, you can define the method in a library.
  • Facilitates the creation and implementation of heavyweight resources and providers.

Policyfiles are used to combine the advantages of roles and environment with Berkshelf.In usual Chef Workflow, the versions and the locations of cookbooks being used by a Chef Client are updated in “metadata.rb” file and “Berksfile”. Often this is a tedious task and a small error in these files make Chef Client apply the wrong cookbook and converged node would not acquire the required state. These problems could be solved by using a single document called Policyfiles to get the specific cookbook revisions and recipes that Chef Infra Client would apply. Policyfiles are applied on a group of nodes, cookbooks or settings. The syntax for a Policyfile.rb file is as follows:

name "name"
run_list "ITEM", "ITEM", ...
default_source :SOURCE_TYPE, *args
cookbook "NAME" [, "VERSION_CONSTRAINT"] [, SOURCE_OPTIONS]

where 

  • “name” is the name of the policy
  • “run_list “ is the list of recipes applied by Chef Client on all nodes associated with the policy
  • “default_source” specifies the location of the cookbook
  •  “cookbook” defines the name of the cookbook and version constraints. An alternate source path for the cookbook could also be specified here.

Chef shell is an interactive tool to work with resources. It helps to do REPL with the resources.chef-shell provides an easy method to test resources interactively rather than uploading our cookbook to Chef Server and applying it on Chef nodes. Breakpoints could be added on to the recipe execution using chef-shell.chef-shell could be used in three modes

  • Standalone mode runs Chef with nothing loaded but interactively. This is the default behaviour of chef-shell if nothing specified.
  • Solo mode runs chef-shell as the chef-solo client. This mode is enabled by using “-s” or “--solo” command-line flag. This mode loads all cookbooks as in the case of chef-solo and uses any JSON file provided with “-j” command-line option.
  • Client mode makes chef-shell to run as in the case of chef-client on the host. This mode is invoked by “-z” or “--client” command-line flag.chef-shell uses local client configuration to connect to Chef Server and download the relevant run_lists, attributes or cookbooks. We can override the server URL in the client configuration by providing “-s” command-line option. “-c” command-line option could also be used to use a different configuration file for chef-shell.

Berkshelf is the dependency manager that comes with the Chef Development Kit. Whenever you create a cookbook say for eg with “chef generate cookbook” command a file called Berksfile is created on top of the cookbook directory. This file contains the source path for all cookbooks. Assume that you created a new cookbook called “my-app” which depends on another community cookbook “nginx” from public Chef Supermarket. The typical steps we follow are:

  • The details about the dependent cookbooks are updated in the “metadata.rb” file.
  • The default recipe in the “my-app” cookbook is having an entry for including recipes from the community cookbook using “include_recipe” directive 
  • Run “berks install “command to install all the dependent cookbooks in ~/.berkshelf/cookbooks default path. Another file called Berksfile.lock is created that has the exact version of all cookbooks installed by Berkshelf. This avoids unwanted mixing up of different versions of dependent cookbooks while sharing the “my-app” cookbook.
  • The “my-app” cookbook along with its dependency cookbooks are uploaded into Chef Server using “berks upload” command
  • Chef-client applies the relevant cookbooks on different Chef Nodes.

“chef_gem” and  “gem_package” resources are used to install Ruby gems. Every system where Chef Client is installed has two versions of Ruby running. One is a system-wide instance of Ruby and the other is the one available only with Chef Client. “chef_gem” resource is used to install Ruby into Chef Client instance of Ruby and “gem_package” resource to install Ruby into a system-wide instance.

gem_package resource has a property called “gem_binary” property that is used by Chef Client to detect the environment settings and then install the gems.          "chef_gem" resource is having all properties and options as that of “gem_package” resource except the “gem_binary” property.”chef_gem” resource always uses “CurrentGemEnvironment” where the Chef Client is running.

“chef_gem” resource has additional functions of 

  • Running its actions immediately before the convergence of the node. This allows the gem to be used in the recipe just after it’s installation.
  • Gems are made aware of the changes so that they could be used immediately by running “Gem.clear_paths”.

The attributes that should not be saved by the node is called Blacklisted attributes. These are defined in the client.rb file. Attributes are blacklisted based on attribute types. “automatic_attribute_blacklist “ defines a hash that blacklists automatic attributes. Similarly “default_attribute_blacklist”, “normal_attribute_blacklist” and “override_attribute_blacklist” are hashes that blacklist default attributes, normal attributes and override attributes respectively. The best practice is to use “automatic_attribute_blacklist “ as automatic attributes generate most data after an Ohai run. For eg:

automatic_attribute_blacklist ['filesystem']

could be used to blacklist only ‘filesystem’ attributes in the below sample attribute data

{
  "filesystem" => {
    "/dev/disk0s2" => {
      "size" => "10mb"
    }
}
}

All other automatic attributes are saved by the node. 

The attributes that are needed to be saved by a node are called Whitelist attributes.

These are also defined in the client.rb file. Similar to blacklist attributes, attributes are also whitelisted using attribute type.”automatic_attribute_whitelist”, “default_attribute_whitelist”, “normal_attribute_whitelist”, “ override_attribute_whitelist” are hashes used to whitelist automatic, default, normal and override attributes respectively. For eg:

automatic_attribute_whitelist ['network/interfaces/'] 

could be used to whitelist only network attributes among the automatic attributes generated like below:

{
"network" => {
    "interfaces" => {
      "eth0" => {...},
      "eth1" => {...},
    }
  }
}

chef-solo is a command where Chef Client is run in a way that it doesn’t require Chef Server to get the required cookbooks.chef-solo make use of the local mode of the chef-client run. It doesn’t require authorisation as in the case of Chef Servers. It also doesn’t provide a centralised distribution of cookbooks or centralised API to interact with infrastructure components. Cookbooks could be loaded from two different locations i.e from a local directory or a URL where the tar.gz archive is present. In chef-solo, the node objects are stored in the form of JSON files in a local disk rather than as node objects in Chef Server. For eg:

chef-solo -c ~/solo.rb -j ~/node.json -r  http://www.sample.com/chef-solo.tar.gz

runs chef-solo with solo.rb configuration file using node.json file and retrieves cookbook from the http://www.sample.com/chef-solo.tar.gz URL.

The basic workflow for chef-solo is as follows:

  • Chef Workstation should have “solo.rb” and “node.json” file inside the chef-repo directory
  • Add “solo.rb” and “node.json” to the git repository
  • Create or download the cookbooks from Chef Supermarket 
  • Commit and push the files to git repo
  • If you want to run chef-solo in a Chef Node, 
    • Login to the chef node where the chef-solo is going to be run
    • Clone the chef-repo from git with the relevant cookbooks that need to be applied on the Chef node
    • Run the “chef-solo” command by specifying “solo.rb” file and “node.json” file to be used.

Ohai framework provides a  mechanism to create our own customised plugins to get more details about a Chef Node. For eg: if we want to find out if a Chef node is a virtual machine or not, no Ohai plugin gathers this information so we need to create a plugin for the same. Ohai makes uses of Ruby-based DSL to create plugins. Ohai plugins are usually kept in “lib/ohai/plugins” directory in the repository. A sample Ohai plugin will look like below:

Ohai.plugin(:Sample) do 
  provides "level" 
  collect_data do 
    level 100 
  end
end

where 

  • name of the plugin “Sample” is passed to Ohai.plugin method
  • “provides” method has a list of attributes our plugin provides. Here “level” is the attribute provided.
  • “collect_data” block is executed when a plugin is run by Ohai. In our example, the “level” attribute is set as 100.

Ohai plugins are tested in IRB Ruby shell. This helps us to run plugins without performing actual Chef Client runs or configuring nodes. After testing is complete and we need to run the plugins we have to specify the path of the new plugin by specifying Ohai::Config[:plugin_path] << /location/of/plugins line in client.rb or solo.rb file. This helps Ohai to load the plugins  correctly

kitchen.yml file is the configuration file for the Test Kitchen. All details needed to create a sandbox environment for testing our infrastructure using Chef is included in .kitchen.yml file

Syntax of a .kitchen.yml file is as follows:

The basic structure of a .kitchen.yml file is as follows:

driver:
  name: driver_name

provisioner:
  name: provisioner_name

verifier:
  name: verifier_name

transport:
  name: transport_name

platforms:
  - name: platform-version
    driver:
      name: driver_name

suites:
  - name: suite_name
    run_list:
      - recipe[cookbook_name::recipe_name]

where

  • driver_name is the name of the driver used to create kitchen instances. For eg: kitchen-Dokken is used to create instances using Docker.
  • provisioner_name is used to denote how Chef Client is simulated in testing either as chef-solo or chef-zero.
  • verifier_name denotes the tool used to run the tests. Usually, InSpec is used.
  • transport_name specifies the transport used to execute commands on the kitchen instance. Normally ssh is used.
  • platform section in .kitchen.yml specifies the type and version of the kitchen instance created.
  • suites_name represents the test suite run on the kitchen instance and it contains a run_list applied which is the list of recipes applied.

Cookstyle is an in-built  linting tool that checks for 

  • Best practices and style conventions
  • Source code uniformity
  • Metrics like in “line length” and functional size

Cookstyle is based on RuboCop Ruby linting tool.

Cookstyle is run from the command line against a cookbook and verifies all the Ruby files in the cookbook. Cookstyle is run as 

cookstyle <cookbook path> and the output is provided via standard output on the terminal.

The output gives us information about the number of files present and verified, defects detected and place of defects. The result of the verification of the files is shown below:

  • . - No issues found in the file
  • C - Convention issue in the file
  • W - Warning issue in the file
  • F - Fatal error in the file
  • E - Error in the file 

Autocorrection facility is available for files with cookstyle warnings but care must be taken not to alter the functionality of the code after using auto-correction. Default settings in the cookstyle could be overridden by .rubocop.yml file in a cookbook.

Frozen cookbooks are those cookbooks which cannot be re-imported or modified. Hence the frozen cookbooks would not even be accidentally modified. For eg:  This method helps us to protect our production environments from being modified while testing changes made to the development infrastructure. We can freeze a cookbook as follows:

  • Use “--freeze” option while uploading the cookbook to Chef Server using “knife upload” command. Once a cookbook is frozen it could be updated only by using “--force” option with “knife upload” command and if the “--force” is not specified an error message would be returned.
  • “berkshelf upload” command automatically makes the uploaded cookbook frozen. To stop freezing of the cookbook we could use the option “--no-freeze”. Similar to a knife, “bookshelf upload” has an option “--force” to update the frozen cookbooks.   Another option called “--halt-on-frozen” exits the “berkshelf upload” command with a non-zero exit code if the same version of the cookbook is present in Chef Server.

Description

Chef, a company and the creator of a configuration management tool, is an automation tool that presents a way to explain infrastructure as code. Infrastructure as code (IAC) indicates managing infrastructure by writing code (Automating infrastructure) rather than using manual processes. It can also be termed as programmable infrastructure. Chef uses a pure-Ruby, domain-specific language (DSL) for writing system configurations. is written in Ruby and Erlang. It utilises a pure-Ruby, domain-specific language (DSL) for writing system configuration "recipes". Chef is proficient in streamlining the task of configuring and maintaining a company's servers and integrating with cloud-based platforms such as Internap, Amazon EC2, Google Cloud Platform, Oracle Cloud, OpenStack, SoftLayer, Microsoft Azure, and Rackspace to automatically provision and configure new machines. Chef’s versatile and affordable features make it a favourite in providing solutions for both small and large scale systems.

Chef’s business is expanding exponentially with annual recurring revenue increase expediting as the company scales. More than half of the Fortune 50 has Chef as one of their prime applications and 80 per cent of Chef’s revenue comes from enterprise businesses.

Top companies like HP, Amazon Web Services, Hewlett-Packard, Facebook, IBM, Microsoft, Oracle and Cisco use Chef as one of the software in their workflow and are in pursuit of Chef Developer and Full Stack engineers. 

None of us can consider Interviews as a piece of cake. However, it becomes easy to handle your interviews if you are prepared with these Chef interview questions for experienced and freshers to help you in pursuing your dream career. Responding quickly and effectively to questions asked by the employers is a must in an interview. As these interview questions on Chef are very obvious, your prospective recruiters will anticipate you to be able to answer the same. These Chef interview questions and answers will boost your spirit required to ace the interview.

These Chef programming interview questions will help you to get your dream job either in Data Science, Machine Learning or just Chef coding. These Chef interview questions and answers for experienced professionals will undoubtedly raise your confidence to handle any relevant interview and will prepare you to answer the most difficult questions in the most ideal way. Suggested by experts, these Chef developer interview questions have proven to be of great value.

Both the job aspirants and even the recruiters may refer to these Chef basic interview questions in order to know the appropriate questions they need to assess a candidate.

Make a mark in your career with the next Chef interview. Create your own destiny and all the best.

Read More
Levels