Kitchen - The CLI Tool

kitchen converge 

To converge one (or more) instances, use the converge subcommand. The list of platforms in the kitchen.yml file is the basis for instances. The Chef Infra Client will be installed using the Chef installer on an instance, the cookbook files and basic settings will be uploaded, and a Chef Infra Client run will be launched using the run-list and attributes supplied in the kitchen.yml file.

Test Kitchen will omit pointless procedures. For instance, Test Kitchen won't reinstall Chef Infra Client if it is already present on the sample. Test Kitchen will always upload the recipe files and the bare minimum of settings. This guarantees that cookbook testing is carried out correctly.

Test Kitchen uses the pursuing exit codes:

• 0 indicates a successful operation.
• Any value other than zero indicates failure in at least one aspect of the procedure.

Generally, use the test subcommand to check the consistency of a cookbook from beginning to end. When creating a cookbook regularly, use the converge and validate subcommands.

Syntax

The syntax for this subcommand is as follows:

kitchen converge PLATFORMS (options)

Options

The options for this subcommand are as follows:

• -c, --concurrency: the number of concurrent connections permitted. By default, the value is 9999.
• -l, --log-level: the amount of logging that will be recorded in a log file. Options: debug, info, warn, error, and fatal (in order of importance). Info is the default value.
• PLATFORMS: Run the kitchen.yml file's Test Kitchen against one or more platforms listed. Run Test Kitchen across all platforms using all. You can combine two or more platforms into one run using a Ruby regular expression.

- name: centos-7
- name: centos-8
- name: fedora-latest
- name: ubuntu-1604
- name: ubuntu-1804

For instance, if a kitchen.yml file contains the following, Test Kitchen would be run against CentOS 7, Ubuntu 16.04, and Ubuntu 18.04 using the regular expression (04|7). Using the regular expression (ubuntu), Test Kitchen would be run on Ubuntu-1604 and Ubuntu-1804. Test Kitchen would only be run against fedora-latest if the regular expression (fedora) was used. The default value is all.

kitchen create 

To create one or more instances, use the create subcommand. Instances are determined using the kitchen.yml file's list of platforms and suites.

Syntax

The syntax for this subcommand is as follows:

kitchen create PLATFORMS (options)

Options

The options for this subcommand are as follows:

• -c, --concurrency: the number of concurrent connections permitted. By default, the value is 9999.
• -l, --log-level: the amount of logging that will be recorded in a log file. Options: debug, info, warn, error, and fatal (in order of importance). Info is the default value.
• PLATFORMS: Run the kitchen.yml file's Test Kitchen against one or more platforms listed. Run Test Kitchen across all platforms using all. You can combine two or more platforms into one run using a Ruby regular expression. For instance, if a kitchen.yml file contains the following: 

- name: centos-7
- name: centos-8
- name: fedora-latest
- name: ubuntu-1604
- name: ubuntu-1804

Test Kitchen would be run against CentOS 7, Ubuntu 16.04, and Ubuntu 18.04 using the regular expression (04|7). Using the regular expression (ubuntu), Test Kitchen would be run on Ubuntu-1604 and Ubuntu-1804. Test Kitchen would only be run against fedora-latest if the regular expression (fedora) was used. The default value is all.

kitchen destroy 

If you want to remove one (or more) instances, use the destroy subcommand. Instances are determined using the kitchen.yml file's list of platforms and suites.

Syntax

The syntax for this subcommand is as follows:

kitchen destroy PLATFORMS (options)

Options

The options for this subcommand are as follows:

• -c, --concurrency: the number of concurrent connections permitted. By default, the value is 9999.
• -l, --log-level: the amount of logging that will be recorded in a log file. Options: debug, info, warn, error, and fatal (in order of importance). Info is the default value.
• PLATFORMS: Run the kitchen.yml file's Test Kitchen against one or more platforms listed. Run Test Kitchen across all platforms using all. You can combine two or more platforms into one run by using a Ruby regular expression. For instance, if a kitchen.yml file contains the following:

- name: centos-7
- name: centos-8
- name: fedora-latest
- name: ubuntu-1604
- name: ubuntu-1804

Test Kitchen would be run against CentOS 7, Ubuntu 16.04, and Ubuntu 18.04 using the regular expression (04|7). Using the regular expression (ubuntu), Test Kitchen would be run on Ubuntu-1604 and Ubuntu-1804. Test Kitchen would only be run against fedora-latest if the regular expression (fedora) was used. The default value is all.

kitchen diagnose 

Use the diagnose subcommand to display a computed diagnostic configuration for one (or more) instances. Since it echoes all configuration information as YAML, this subcommand will clarify any implicit configuration settings.

Syntax

The syntax for this subcommand is as follows:

kitchen diagnose PLATFORMS (options)

Options

The options for this subcommand are as follows:

• --all: Contain all diagnoses. By default, the value is false.
• --instances: diagnostics, for instance. By default, the value is yes.
• -l, --log-level: the amount of logging that will be recorded in a log file. Options: debug, info, warn, error, and fatal (in order of importance). Info is the default value.
• --loader: data loader diagnostics should be included. By default, the value is false.
• PLATFORMS: Run the kitchen.yml file's Test Kitchen against one or more platforms listed. Run Test Kitchen across all platforms using all. You can combine two or more platforms into one run using a Ruby regular expression.

kitchen driver create 

To add a new Test Kitchen driver to the RubyGems project, use the driver create subcommand.

Syntax

The syntax for this subcommand is as follows:

kitchen driver create NAME

Options

The options for this subcommand are as follows:

• -l, --license: The RubyGems file's license. Apachev2, lgplv3, mit, and reserved are among the possible values. By default, the value is apachev2.

kitchen exec

To run a command on a remote instance, use the exec subcommand.

Syntax

The syntax for this subcommand is as follows:

kitchen exec PLATFORMS (options)

Options

The options for this subcommand are as follows:

• -c REMOTE_COMMAND: Used to designate a remote command to be executed using SSH.
• PLATFORMS: Run the kitchen.yml file's Test Kitchen against one or more platforms listed. Run Test Kitchen across all platforms using all. You can combine two or more platforms into one run using a Ruby regular expression.

kitchen init 

Create an initial Test Kitchen environment by using the init subcommand, which should include:

• generating the kitchen.yml file
• Adding the RubyGems file, .gitignore, and .thor to Test Kitchen
• the test/integration/default directory being created

Syntax

The syntax for this subcommand is as follows:

kitchen init

Options

The options for this subcommand are as follows:

• --create_gemfile: If a RubyGems file doesn't already exist, create one. By default, the value is false.
• -D, --driver: A RubyGems file should now contain one (or more) Test Kitchen drivers. Kitchen-vagrant by default.
• -l, --log-level: the amount of logging that will be recorded in a log file. Options: debug, info, warn, error, and fatal (in order of importance). Info is the default value.
• -P, --provisioner: the provisioner that Test Kitchen uses by default.
• PLATFORMS: Run the kitchen.yml file's Test Kitchen against one or more platforms listed. Run Test Kitchen across all platforms using all. You can combine two or more platforms into one run using a Ruby regular expression.

kitchen list 

To view the list of instances, use the list subcommand. Test Kitchen will automatically name instances by fusing the names of a platform and a suite. For example, the instance would be default-ubuntu-1804 if the suite was named default and the platform was named ubuntu-18.04. This guarantees secure DNS and hostname records for Test Kitchen instances.

Syntax

The syntax for this subcommand is as follows:

kitchen list PLATFORMS (options)

Options

The options for this subcommand are as follows:

• -b, --bare: Each instance's name should appear on a separate line. By default, the value is false.
• -l, --log-level: the amount of logging that will be recorded in a log file. Options: debug, info, warn, error, and fatal (in order of importance). Info by default.
• PLATFORMS:  Run the kitchen.yml file's Test Kitchen against one or more platforms listed. Run Test Kitchen across all platforms using all. You can combine two or more platforms into one run using a Ruby regular expression.

kitchen login 

To log in to one instance, use the login subcommand. Instances are determined using the kitchen.yml file's list of platforms and suites. The instance can be interacted with after successfully logging in, just like any other virtual machine, by adding or deleting packages, running or stopping services, and so on. A sandbox, indeed. Make any adjustments required to enhance cookbook testing coverage.

Syntax

The syntax for this subcommand is as follows:

kitchen login PLATFORM (options)

Options

The options for this subcommand are as follows:

• -l, --log-level: the amount of logging that will be recorded in a log file. Options: debug, info, warn, error, and fatal (in order of importance). Info is the default value.
• PLATFORMS:  Run the kitchen.yml file's Test Kitchen against one or more platforms listed. Run Test Kitchen across all platforms using all. You can combine two or more platforms into one run using a Ruby regular expression.

kitchen setup

One (or more) instance can be set up using the setup subcommand. The list of platforms in the kitchen.yml file is the basis for instances. 

Syntax

The syntax for this subcommand is as follows:

kitchen setup PLATFORMS (options)

Options

The options for this subcommand are as follows:

• -c, --concurrency: the number of concurrent connections permitted. By default, the value is 9999.
• -l, --log-level: the amount of logging that will be recorded in a log file. Options: debug, info, warn, error, and fatal (in order of importance). Info by default.
• PLATFORMS:  Run the kitchen.yml file's Test Kitchen against one or more platforms listed. Run Test Kitchen across all platforms using all. You can combine two or more platforms into one run using a Ruby regular expression.

kitchen test 

One (or more) validated instances can be tested using the test subcommand. According to the platforms and suites listed in the kitchen.yml file, instances are created. This subcommand will establish a new instance, converge it, set up the test harness, validate it using the test harness, and finally destroy the instance (cleaning up any earlier instances, if necessary).

Generally, use the test subcommand to check the consistency of a cookbook from beginning to end. Use the converge and verify subcommands when creating a cookbook regularly.

Syntax

The syntax for this subcommand is as follows:

kitchen test PLATFORMS (options)

Options

The options for this subcommand are as follows:

• --auto-init: In the absence of kitchen.yml, issue the init command. The default value is false.
• -c NUMBER, --concurrency NUMBER: the number of concurrent connections permitted. To restrict the number of instances tested simultaneously, use this parameter. With —concurrency 6, for example, you can increase this cap to six instances running simultaneously. By default, the value is 9999.
• -d, --destroy: the method of destruction applied at the end of a Test Kitchen run. The following possible values are available: always (delete instances always), never (never destroy instances), or passing (only destroy instances that passed). Passing is the default value.
• -l, --log-level:  the amount of logging that will be recorded in a log file. Options: debug, info, warn, error, and fatal (in order of importance). Info is the default value.
• PLATFORMS: Run the kitchen.yml file's Test Kitchen against one or more platforms listed. Run Test Kitchen across all platforms using all. You can combine two or more platforms into one run using a Ruby regular expression.

kitchen verify 

You can verify one or more instances with the verify subcommand. Examples are based on the kitchen's list of platforms and suites.yml document.

In general, utilize the test subcommand to ensure that a cookbook is high-quality from beginning to end. Use the converge and verify subcommands when creating a cookbook regularly.

Syntax

The syntax for this subcommand is as follows:

kitchen verify PLATFORMS (options)

Options

The options for this subcommand are as follows:

• -c, --concurrency: the number of concurrent connections permitted. By default, the value is 9999.
• -l, --log-level: the amount of logging that will be recorded in a log file. Options: debug, info, warn, error, and fatal (in order of importance). Info by default.
• PLATFORMS:  Run the kitchen.yml file's Test Kitchen against one or more platforms listed. Run Test Kitchen across all platforms using all. You can combine two or more platforms into one run using a Ruby regular expression.

kitchen version 

To print the version of Kitchen, use the version subcommand.

Syntax

The syntax for this subcommand is as follows:

kitchen version

Options

The options for this subcommand are not available.

Frequently Asked Questions

What is the Chef kitchen test?

Chef's integrated testing framework is called Test Kitchen. It makes it possible to create test recipes executed on the VMs after they have been created and converged using the cookbook. The test recipes are run on that VM to confirm that everything functions as it should.

What does Kitchen Converge mean?

The machine will continue to run after a converge, and the kitchen will automatically upload modifications after each converges to allow for quick configuration code iterations. The exit code for the kitchen has undergone extensive testing to ensure that it is always acceptable.

What is Kitchen Yml?

Chef offers a testing framework called Kitchen. Its goal is to provide several kitchen setup possibilities.

How is the test kitchen operated?

A test kitchen is a kitchen where test cooks and chefs research, test, and produce recipes for home cooks. It is typically furnished with many cooking stations. Recipes are frequently tested several times and reviewed by many people.

What is the location of Kitchen Yml?

A path to a kitchen can be established using several environment variables in Test Kitchen. yml or a file located in $HOME/. kitchen/config.

Conclusion

In this article, we have extensively discussed the Kitchen CLI tool. We have also explained the various commands of the kitchen CLI tool, their syntax, and what options are available with that command in detail.

We hope this blog has helped you enhance your Kitchen CLI tool knowledge. If you would like to learn more, check out our articles on DevOp's best things, DevOps tools, and reasons to build a career in DevOps. Practice makes a man perfect. To practice and improve yourself in the interview, you can check out Top 100 SQL problems, Interview experience, Coding interview questions, and the Ultimate guide path for interviews.

Do upvote our blog to help other ninjas grow. Happy Coding!