Learn Chef - Knife & Chef CLI

#Introduction

In episode 7 you learned about ERB templates and the three levels of server-side data storage: data bags, encrypted data bags, and chef-vault. You know how to render dynamic configuration files and how to read secrets from within recipes. All those operations happen through cookbook files, but nothing yet connects the cookbook to the actual nodes.

That connector is the job of knife, Chef's built-in CLI that runs on the workstation. With knife you can register new nodes, upload cookbooks to the server, create data bags, run SSH commands across many nodes at once, and manage environments and cookbook versions.

Episode 8 will cover the knife commands most commonly used day-to-day, then move into environments with attribute overrides and cookbook version freezing for tighter release control.

#Knife: The Infrastructure Remote Control

Knife is a command-line utility that talks to the chef-server through the REST API. All of knife's configuration lives in ~/.chef/knife.rb or ~/.chef/config.rb, which contains the chef-server_url address, the workstation node name, and the location of the caller's private key.

Verify the connection to the server with the simplest commands:

knife client list
knife node list

knife client list shows all registered clients, while knife node list shows nodes that are registered and have attributes. A regular node is usually also a client, so the two often appear side by side.

#Uploading Cookbooks

A finished cookbook must be uploaded to the server before nodes can run it. Without an upload, the recipe only exists on the workstation and will never be executed by chef-client on another machine.

knife cookbook upload web_server
knife cookbook upload --all

knife cookbook upload web_server uploads the cookbook named web_server along with its dependencies automatically. The --all option uploads every cookbook in the working directory. To see the versions already on the server, use knife cookbook list:

knife cookbook list -a

The output shows each cookbook's name and version, for example web_server 0.1.0. If you upload again with the same version, knife will reject it because that version is already used by a run list, unless you use --force.

#Creating Data Bags from the CLI

The data bags you learned about in episode 7 can be created directly from knife without writing a JSON file first:

knife data bag create users
knife data bag create users alice -c '{"department":"engineering"}'

The second command writes an item with the id alice and inline JSON content. To add an item from a file, use knife data bag from file users bob.json as learned in episode 7.

#Bootstrap and Remote Execution

Bootstrap is the process of registering a new node on the chef-server while also installing chef-client on that machine. It's the fastest way to bring a new server under Chef management.

knife bootstrap 203.0.113.10 \
  --ssh-user deploy \
  --ssh-password 'S3cure' \
  --sudo \
  --node-name web01 \
  --run-list 'recipe[apt],recipe[web_server]'

The bootstrap process connects to the target machine over SSH, installs chef-client, registers it as a node and client on the server, then immediately runs the provided run list. Once bootstrapping finishes, the web01 node can be seen with knife node list and its attributes explored with knife node show web01.

To run chef-client manually on an existing node, use knife ssh:

knife ssh 'name:web*' 'sudo chef-client'
knife ssh 'role:app_server' 'sudo chef-client' --manual-list '192.0.2.10,192.0.2.11'

knife ssh accepts a node search query as its first argument. The query name:web* selects all nodes whose name starts with web. The second command uses a role search, and the --manual-list option forces execution against a list of IPs without referencing node data on the server.

#Bootstrap vs SSH Comparison

#Environments and Attribute Overrides

The environments you learned about in episode 6 serve to differentiate deployment stages. Through knife, environments can be created and managed without writing Ruby files:

knife environment create development
knife environment create staging
knife environment create production
knife node environment set web01 production

Environment attributes are written as JSON. Environments govern attributes of the override type, whose level is higher than the default from cookbooks and roles, but lower than node attributes:

knife environment edit production

The editor that opens contains empty JSON. You can fill it with the following block:

{
  "name": "production",
  "description": "Production",
  "override_attributes": {
    "web_server": {
      "worker_processes": 16,
      "port": 443
    }
  },
  "cookbook_versions": {
    "web_server": "~> 0.1.0"
  }
}

The override_attributes block overrides the default cookbook values for all nodes in the production environment. The cookbook_versions block limits which cookbook versions nodes may run, so production nodes don't suddenly change behavior when a new cookbook is uploaded.

#Cookbook Versions and Freezing

Chef applies semver to cookbooks via the version field in metadata.rb. Every time you change a cookbook's behavior, bump the version with chef exec berks or manually in metadata.rb, then upload again.

Freeze prevents a cookbook at a specific version from being changed after upload. When a cookbook is frozen, the server rejects uploading the same version again:

knife cookbook upload web_server --freeze
knife cookbook upload web_server --force

--freeze marks the cookbook as immutable on the server. If you forget to bump the version and try to upload again, knife will reject it with a message that the version is frozen. The --force option bypasses the freeze, but should only be used when you're really sure, because it can make nodes use an inconsistent version.

#Release Flow with Versions

The recommended order for releasing changes:

1. Change the recipe or template in the cookbook, then bump the version in metadata.rb.
2. Upload the cookbook with knife cookbook upload web_server --freeze.
3. Test in the staging environment by changing a test node's run list.
4. If successful, update cookbook_versions in the production environment.
5. Run chef-client on production nodes with knife ssh 'chef_environment:production' 'sudo chef-client'.

#Conclusion

In episode 8 you mastered the most commonly used knife commands, from knife node list, knife cookbook upload, knife data bag create, knife ssh, to knife bootstrap. You also understood how environments use attribute overrides and cookbook_versions to differentiate deployment stages, and how --freeze keeps cookbook versions consistent.

Key takeaways:

• Knife is the CLI that connects the workstation to the chef-server to manage nodes, cookbooks, and data bags.
• Knife bootstrap registers a new node while installing chef-client and running its first run list.
• Knife ssh executes commands on many nodes at once with search query support.
• Environments use override_attributes and cookbook_versions to differentiate dev, staging, and production.
• Freeze locks a cookbook version on the server so changes must go through a new version.

In the next episode, episode 9, we shift focus from the workstation to the server: Chef Infra Server. You'll learn to install chef-server-core, run chef-server-ctl reconfigure, create organizations and users, configure SSL, and handle backups with knife-ec-backup and high availability strategies. See you there.