← Back to all projects

CHEF INFRA IAC MASTERY

In the early 2000s, sysadmins used Bash scripts to configure servers. These scripts were imperative—they told the computer *what to do* step-by-step. If a script ran twice, it often broke things.

Learn Chef Infra: From Zero to Infrastructure-as-Code Master

Goal: Deeply understand state convergence and idempotency through Chef Infra. You will master the Ruby DSL used to describe system states, understand how to manage complexity across hundreds of nodes, and build a fully automated, self-healing infrastructure that bridges the gap between raw hardware and cloud-native services.

Why Chef Matters

In the early 2000s, sysadmins used Bash scripts to configure servers. These scripts were “imperative”—they told the computer what to do step-by-step. If a script ran twice, it often broke things.

Chef, released in 2009, popularized “Declarative” Infrastructure as Code. Instead of telling the server “Install Nginx,” you tell Chef “Nginx should be installed.” Chef then checks the state; if it’s there, it does nothing. If it’s missing, it fixes it. This is Idempotency.

The Three-Tier Architecture

To master Chef, you must visualize the flow of data between your laptop, the central brain, and the target servers.

      [ WORKSTATION ]               [ CHEF INFRA SERVER ]             [ NODES ]
   (Where you write code)           (The Central Brain)           (Target Servers)
   ┌───────────────────┐            ┌───────────────────┐       ┌───────────────────┐
   │  Ruby Cookbooks   │            │  Stored Policies  │       │  Chef Client      │
   │  Knife / Policy   │ ──push───> │  Node Metadata    │ <───> │  System State     │
   │  Test Kitchen     │            │  Search Index     │       │  Convergence      │
   └───────────────────┘            └───────────────────┘       └───────────────────┘
            ↑                                                          ↑
            └───────────────────────── Ohai ───────────────────────────┘
                (System profiling: CPU, RAM, OS, Networking)

Why Understanding This Unlocks Success:

  1. State Management: You stop thinking about “running scripts” and start thinking about “desired states.”
  2. Scalability: One cookbook can manage 1 node or 10,000 nodes using attributes.
  3. Searchability: Chef Server indexes your hardware. You can query: “Find all nodes with more than 16GB RAM running Ubuntu 22.04.”
  4. Security as Code: Compliance is no longer a manual check; it’s a resource that converges every 30 minutes.

Core Concept Analysis

1. The Resource: The Atomic Unit of Configuration

A Resource is a statement of configuration that describes a piece of the system and its desired state.

# The "What"
package 'nginx' do
  action :install # The "Desired State"
end

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

2. The Convergence Loop

Chef doesn’t just run code; it follows a precise lifecycle.

START
  │
  ▼
[ Compile Phase ] ───> Read all recipes, build a Resource Collection in memory.
  │
  ▼
[ Converge Phase ] ───> For each resource:
  │                     1. Inspect current state (e.g., Is Nginx installed?)
  │                     2. Compare to desired state (e.g., Should it be installed?)
  │                     3. If mismatch -> Execute "Provider" to fix it.
  │                     4. If match -> Do nothing (Idempotency).
  │
  ▼
END (System is in "Desired State")

Concept Summary Table

Concept Cluster What You Need to Internalize
Idempotency Running the same code twice results in no additional changes after the first run.
Resources The building blocks (file, package, service, user). You describe the result, not the process.
Recipes & Cookbooks Recipes are files containing resources. Cookbooks are packages of recipes and files.
Attributes Variables for your infrastructure. They allow one cookbook to behave differently on different nodes.
Search The ability to query the Chef Server for information about other nodes (e.g., find the DB IP).
Convergence The process by which Chef brings the system from its current state to the desired state.

Deep Dive Reading by Concept

Foundation

Concept Book & Chapter
Idempotency & IaC Philosophy “Infrastructure as Code” by Kief Morris — Ch. 1: “What is Infrastructure as Code?”
The Chef DSL “Chef Infrastructure Automation Cookbook” by Matthias Marschall — Ch. 1: “Chef Infrastructure”
Ruby for Chef “Learning Chef” by Taylor & Vargo — Ch. 2: “Ruby Primer”

Intermediate

Concept Book & Chapter
Attributes & Data Bags “Chef Infrastructure Automation Cookbook” by Matthias Marschall — Ch. 3: “Working with Attributes”
Testing (Test Kitchen) “Test-Driven Infrastructure with Chef” by Stephen Nelson-Smith — Ch. 4: “Test Kitchen”

Project 1: The Local System Gardener

  • File: CHEF_INFRA_IAC_MASTERY.md
  • Main Programming Language: Ruby (Chef DSL)
  • Alternative Programming Languages: HCL (Terraform), YAML (Ansible)
  • Coolness Level: Level 2: Practical but Forgettable
  • Business Potential: 1. The “Resume Gold”
  • Difficulty: Level 1: Beginner
  • Knowledge Area: Configuration Management / Local Orchestration
  • Software or Tool: Chef Workstation / chef-client
  • Main Book: “Learning Chef” by Mischa Taylor & Seth Vargo

What you’ll build: A “local-mode” Chef recipe that manages your workstation’s environment—installing your favorite editors, configuring Git, and creating a specific folder structure for projects.

Why it teaches Chef: It removes the complexity of servers and networking. You learn the basic resources (package, directory, file, git) and observe idempotency firsthand by running the command multiple times.

Core challenges you’ll face:

  • Understanding action :nothing vs :create → maps to resource control
  • Managing file permissions → maps to security attributes
  • Running Chef in Local Mode → maps to using chef-client -z

Key Concepts:

  • Resource Declaration: “Learning Chef” Ch. 3
  • Idempotency: “Infrastructure as Code” (Kief Morris) Ch. 2

Difficulty: Beginner Time estimate: Weekend Prerequisites: Basic command line usage, Chef Workstation installed.

Real World Outcome

You’ll have a single Ruby file (setup.rb) that, when run, ensures your machine is perfectly configured. If you delete a folder or uninstall an app, running the command brings it back.

Example Output:

$ chef-client -z setup.rb
[2025-12-28] INFO: Starting Chef Infra Client
[2025-12-28] INFO: --- Resource Collection ---
* directory[/Users/dev/Projects] action create (up to date)
* package[git] action install (up to date)
* file[/Users/dev/.gitconfig] action create
  - update content in file /Users/dev/.gitconfig from none to abc123
  - restore selinux security context
[2025-12-28] INFO: Chef Infra Client finished, 1/3 resources updated in 02 seconds

The Core Question You’re Answering

“If I run this code a second time, why doesn’t it fail or create a duplicate?”

Before you write any code, realize that Chef is a ‘diff engine’ for your OS. It compares what is with what should be.

Concepts You Must Understand First

Stop and research these before coding:

  1. Resources
    • What is the difference between package and service?
    • What happens if a resource fails in the middle of a recipe?
    • Book Reference: “Learning Chef” Ch. 3
  2. Chef Local Mode
    • What is the -z (zero) flag?
    • How does Chef store its “state” locally?

Questions to Guide Your Design

  1. Execution Order
    • Does Chef run resources from top to bottom?
    • What happens if I try to configure Git before installing it?
  2. User Context
    • Am I running this as root/sudo or as my local user?
    • How does Chef know which home directory to use?

Thinking Exercise

The Idempotency Trace

Look at this snippet:

file '/tmp/hello.txt' do
  content 'Hello World'
end

Trace the logic:

  1. Run 1: File doesn’t exist. Result?
  2. Run 2: File exists with ‘Hello World’. Result?
  3. Manual change: You change the file to ‘Goodbye’. Run 3: Result?

The Interview Questions They’ll Ask

  1. “Explain the difference between the Compile phase and the Converge phase.”
  2. “What is an idempotent resource?”
  3. “How do you run Chef without a central server?”
  4. “What is the purpose of the action :nothing property?”
  5. “How would you ensure a directory exists only after a package is installed?”

Hints in Layers

Hint 1: The Basics Start by using the directory resource to create a folder in /tmp. Run it twice and watch the output.

Hint 2: Content Use the file resource to put text in that directory.

Hint 3: Logic Try using the package resource for something simple like tree or wget.

Hint 4: Verification Use ls -la and which to verify that Chef actually did what the output said.

Books That Will Help

Topic Book Chapter
Chef Resources “Learning Chef” by Taylor & Vargo Ch. 3
Local Mode “Chef Infrastructure Automation Cookbook” by Marschall Ch. 1

Project 2: The Hardened Bastion (Security Policy)

  • File: CHEF_INFRA_IAC_MASTERY.md
  • Main Programming Language: Ruby (Chef DSL)
  • Alternative Programming Languages: OpenPolicyAgent (Rego)
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: System Hardening / Security
  • Software or Tool: Chef Infra Client, SSH, UFW/Iptables
  • Main Book: “Infrastructure as Code” by Kief Morris

What you’ll build: A cookbook that transforms a vanilla Linux server into a secure “Bastion” host by automating SSH hardening (disabling root login, password auth), configuring a firewall (UFW), and setting up automatic security updates.

Why it teaches Chef: This project moves from “installing things” to “enforcing policy.” You’ll learn to use the template resource to manage complex config files and use notifies to restart services only when configurations change.

Core challenges you’ll face:

  • Managing the SSH config template → maps to ERB templates and variables
  • Orchestrating Service Restarts → maps to Notifications and Subscriptions
  • Handling OS-specific variations → maps to Platform detection (node[‘platform’])

Key Concepts:

  • Templates (ERB): “Learning Chef” Ch. 5
  • Handlers & Notifications: “Chef Infrastructure Automation Cookbook” Ch. 2

Difficulty: Intermediate Time estimate: 1 week

Real World Outcome

You’ll have a reusable “Hardening” cookbook. When applied to a fresh Ubuntu or CentOS server, it will automatically lock it down.

Example Output:

$ sudo chef-client --local-mode --runlist 'recipe[my_security::bastion]'
...
* template[/etc/ssh/sshd_config] action create
  - update content in file /etc/ssh/sshd_config from ... to ...
  - sending restart notification to service[ssh]
* service[ssh] action restart
  - restart service service[ssh]
* service[ufw] action enable
* service[ufw] action start

The Core Question You’re Answering

“How do I manage a configuration file that is 90% the same but has 10% variable parts?”

This project introduces Templates. Instead of writing a whole file, you write a blueprint and let Chef fill in the blanks.

Concepts You Must Understand First

  1. Service Notifications
    • Why shouldn’t we restart SSH every time Chef runs?
    • What is the difference between :immediately and :delayed notifications?
  2. Node Attributes
    • How do I store the SSH port number so it’s easy to change?

Project 3: The Dynamic Web Proxy

  • File: CHEF_INFRA_IAC_MASTERY.md
  • Main Programming Language: Ruby (Chef DSL)
  • Alternative Programming Languages: Python (SaltStack)
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 2. The “Micro-SaaS / Pro Tool”
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Web Infrastructure / Load Balancing
  • Software or Tool: Nginx, Ohai, Chef Attributes
  • Main Book: “Chef Infrastructure Automation Cookbook” by Matthias Marschall

What you’ll build: A dynamic Nginx reverse proxy configuration. The Nginx config will automatically adjust its “worker_processes” based on the actual CPU count of the server it’s running on, and the “server_name” based on the node’s hostname.

Why it teaches Chef: This introduces Ohai—Chef’s system discovery tool. You’ll learn that your code isn’t static; it “reads” the hardware it’s sitting on and adapts the configuration dynamically.

Core challenges you’ll face:

  • Accessing Ohai data → maps to Node attributes (node[‘cpu’][‘total’])
  • Calculating values in Ruby → maps to Using Ruby logic inside recipes
  • Testing with Test Kitchen → maps to Local virtualization for cookbooks

Key Concepts:

  • Ohai: “Chef Infrastructure Automation Cookbook” Ch. 1
  • Attributes Precedence: “Learning Chef” Ch. 6

Difficulty: Intermediate Time estimate: 1 week

Real World Outcome

You’ll see Nginx configured differently on a small VM (1 CPU) vs a large server (8 CPUs), even though you use the exact same cookbook.

Example Output:

# On a 1-CPU node
$ cat /etc/nginx/nginx.conf | grep worker_processes
worker_processes 1;

# On an 8-CPU node
$ cat /etc/nginx/nginx.conf | grep worker_processes
worker_processes 8;

The Core Question You’re Answering

“How can I write one piece of code that behaves correctly on many different types of hardware?”

This project teaches you to stop hardcoding values. You learn to trust the Node Object as your source of truth.

Project 4: The Load Balancer (Search & Service Discovery)

  • File: CHEF_INFRA_IAC_MASTERY.md
  • Main Programming Language: Ruby (Chef DSL)
  • Alternative Programming Languages: Go (Consul Template)
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 4. The “Open Core” Infrastructure
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Distributed Systems / Network Topology
  • Software or Tool: HAProxy, Chef Server Search
  • Main Book: “Chef Infrastructure Automation Cookbook” by Matthias Marschall

What you’ll build: An HAProxy load balancer that automatically finds all nodes in your infrastructure tagged as “web-server” and adds them to its backend pool.

Why it teaches Chef: This is the “Aha!” moment of Chef. You move from configuring single nodes to Orchestration. You’ll use search, which queries the Chef Server for the IP addresses of other nodes. When a new web server is added to the cluster, the load balancer converges and adds it automatically.

Core challenges you’ll face:

  • Writing a Search Query → maps to Chef Server API and Indexing
  • Handling empty search results → maps to Defensive programming in recipes
  • Orchestrating convergence timing → maps to Understanding eventually consistent state

Key Concepts:

  • Search API: “Chef Infrastructure Automation Cookbook” Ch. 5
  • Roles & Environments: “Learning Chef” Ch. 7

Difficulty: Advanced Time estimate: 2 weeks Prerequisites: A running Chef Server (hosted or local chef-zero), at least 2 nodes (VMs).

Real World Outcome

A load balancer that updates itself. You spin up a new web server, run chef-client on it, then run chef-client on the balancer, and boom—the traffic is now distributed to the new node.

Example Output:

$ sudo chef-client
...
* template[/etc/haproxy/haproxy.cfg] action create
  - update content in file /etc/haproxy/haproxy.cfg
  - Added node 'web-server-03' (10.0.0.45) to pool
  - sending reload notification to service[haproxy]

The Core Question You’re Answering

“How do my servers know about each other without me manually typing IP addresses into config files?”

This is the foundation of Service Discovery. Your infrastructure becomes a living database that you can query.

Project 5: The Secret Vault (Data Bags & Encryption)

  • File: CHEF_INFRA_IAC_MASTERY.md
  • Main Programming Language: Ruby
  • Alternative Programming Languages: HashiCorp Vault
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Security / Secret Management
  • Software or Tool: Chef Data Bags, knife secret
  • Main Book: “Learning Chef” by Taylor & Vargo

What you’ll build: A user management cookbook that creates system accounts for your team. Since users have passwords and SSH keys, you’ll store them in Encrypted Data Bags.

Why it teaches Chef: You’ll learn how to handle data that shouldn’t be in your git repository. This project covers the lifecycle of “secrets”—creation, encryption, and decryption at runtime on the node.

Core challenges you’ll face:

  • Managing Encryption Keys → maps to Key distribution
  • JSON structure design → maps to Data Bags schema
  • Ruby Iteration → maps to Creating multiple resources from a data structure

Real World Outcome

A secure, centralized way to manage access. You add a JSON file to the data bag, and next time the nodes run, the new user exists with their specific SSH key.

Example Output:

$ knife data bag show users jdoe --secret-file ~/.chef/encrypted_data_bag_secret
{
  "id": "jdoe",
  "ssh_keys": "ssh-rsa AAAAB3...",
  "shell": "/bin/zsh"
}

Project 6: The Self-Healing Database

  • File: CHEF_INFRA_IAC_MASTERY.md
  • Main Programming Language: Ruby / InSpec (Infrastructural Testing)
  • Alternative Programming Languages: SQL
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 4. The “Open Core” Infrastructure
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Database Reliability / Compliance
  • Software or Tool: Postgres, Chef InSpec, Test Kitchen
  • Main Book: “Test-Driven Infrastructure with Chef” by Stephen Nelson-Smith

What you’ll build: A PostgreSQL cookbook that not only installs the DB but includes InSpec tests. If someone manually stops the database or changes a setting, Chef will detect the “compliance failure” and fix it.

Why it teaches Chef: This introduces the “Check” part of “Check-and-Repair.” You’ll learn to write tests before code (TDD) and use InSpec to verify the system state independently of the Chef run.

Core challenges you’ll face:

  • Writing InSpec controls → maps to Compliance as Code
  • State validation → maps to Verification phase
  • Automated Testing Pipelines → maps to Test Kitchen and Docker

Project 7: Real World Outcome

You’ll have a single cookbook that you can run on a Raspberry Pi (Debian), a Cloud Server (Ubuntu), and a Windows Laptop, and it will “just work.”

Example Output:

# On Linux
$ chef-client -z setup.rb
* package[vim] action install (up to date)

# On Windows
$ chef-client -z setup.rb
* windows_feature[Net-Framework-Core] action install (up to date)

Project 8: The Core Question You’re Answering

“How do I turn a complex mess of low-level resources into a simple, high-level language that my team can actually understand?”

This is the transition from Writing Recipes to Building a Platform.

Project 9: Real World Outcome

You will eliminate the risk of an “accidental update.” If a newer version of a cookbook is released, your production servers won’t touch it until you explicitly update the Policyfile.lock.json.

Project 10: The Interview Questions They’ll Ask

  1. “How does a node authenticate with the Chef Server?”
  2. “What is the role of the validator.pem file?”
  3. “Describe the steps of a ‘knife bootstrap’ command.”
  4. “How do you handle nodes that are behind a firewall during bootstrap?”
  5. “What happens if a node’s client.pem is lost?”

Project Comparison Table

Project Difficulty Time Depth of Understanding Fun Factor
1. Local Gardener Level 1 Weekend Foundation ⭐⭐
2. Hardened Bastion Level 2 1 Week Security/Templates ⭐⭐⭐
3. Dynamic Proxy Level 2 1 Week Introspection (Ohai) ⭐⭐⭐
4. Load Balancer Level 3 2 Weeks Search/Orchestration ⭐⭐⭐⭐
5. Secret Vault Level 2 1 Week Security/Data Bags ⭐⭐⭐
6. Healing DB Level 3 2 Weeks Testing (InSpec) ⭐⭐⭐⭐
7. Cross-Platform Level 2 1 Week Abstraction ⭐⭐⭐
8. Resource Factory Level 4 2 Weeks Ruby Metaprogramming ⭐⭐⭐⭐⭐
9. Policyfile Rev Level 3 1 Week Supply Chain/Versioning ⭐⭐⭐
10. Bare-Metal Boot Level 5 1 Month Network/Authentication ⭐⭐⭐⭐⭐

Recommendation

If you are a Beginner: Start with Project 1 (Local Gardener). It takes 30 minutes to see your first result without needing a server. If you are an Intermediate Sysadmin: Focus on Project 4 (Load Balancer). This is where you see the power of Chef’s central database. If you are a Senior Engineer: Build Project 8 (Custom Resource Factory). This will teach you how to build a scalable IaC platform for an entire company.

Final Overall Project: The Self-Scaling, Self-Healing Infrastructure

What you’ll build: A complete, multi-tier environment (Load Balancer -> App Servers -> Database) that uses every concept learned:

  1. Infrastructure as Code: Everything is in cookbooks.
  2. Policyfiles: All versions are locked and promoted through environments.
  3. Secret Management: Encrypted data bags for DB credentials.
  4. Service Discovery: The Load Balancer finds App Servers via Search.
  5. Compliance: InSpec runs after every convergence to verify security.
  6. Custom Resources: The App is deployed using a custom my_app resource.

Goal: You should be able to delete the entire environment, run a single script, and have the whole cluster rebuild itself and be ready for traffic in 10 minutes with zero manual intervention.

Summary

This learning path covers Chef Infra through 10 hands-on projects. Here’s the complete list:

# Project Name Main Language Difficulty Time Estimate
1 Local System Gardener Ruby (Chef) Beginner Weekend
2 Hardened Bastion Ruby (Chef) Intermediate 1 week
3 Dynamic Web Proxy Ruby (Chef) Intermediate 1 week
4 The Load Balancer Ruby (Chef) Advanced 2 weeks
5 The Secret Vault Ruby (Chef) Intermediate 1 week
6 Self-Healing Database Ruby/InSpec Advanced 2 weeks
7 Cross-Platform Gardener Ruby (Chef) Intermediate 1 week
8 Custom Resource Factory Ruby Expert 2 weeks
9 Policyfile Revolution Ruby Advanced 1 week
10 Bare-Metal Bootstrapper Ruby/Bash Master 1 month

Expected Outcomes

After completing these projects, you will:

  • Understand Idempotency vs Imperative scripting.
  • Master the Chef DSL and Ruby-based configuration.
  • Be able to orchestrate complex clusters using Search and Discovery.
  • Implement Compliance as Code using InSpec.
  • Design Scalable Platforms using Custom Resources and Policyfiles.

You’ll have built 10 working projects that demonstrate deep understanding of Infrastructure as Code from first principles.

Real World Outcome

You will have a “Continuous Compliance” dashboard. You’ll see tests passing/failing in real-time and watch as Chef automatically repairs a database that has been tampered with.

Example Output:

$ kitchen verify
...
Profile: postgres-baseline
  ✔  postgres-01: Postgres should be running
  ✔  postgres-02: Postgres should be listening on port 5432
  ✖  postgres-03: Password authentication should be md5
     expected "trust" to eq "md5"
...
$ kitchen converge  # Chef fixes the auth type
$ kitchen verify    # Now it passes

Project 7: The Cross-Platform Gardener (Conditional Logic)

  • File: CHEF_INFRA_IAC_MASTERY.md
  • Main Programming Language: Ruby
  • Alternative Programming Languages: Go (internal branching)
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 1. The “Resume Gold”
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: OS Internals / Portability
  • Software or Tool: Ubuntu, CentOS, Windows Server
  • Main Book: “Learning Chef” by Taylor & Vargo

What you’ll build: A “Unified User” cookbook that works on Ubuntu (apt), CentOS (yum), and Windows (Powershell/Feature). It detects the OS and applies the correct package manager and file paths automatically.

Why it teaches Chef: This project forces you to grapple with Abstraction. You’ll use Ruby case statements and the value_for_platform helper. You’ll learn that a well-written cookbook doesn’t care about the OS; it cares about the intent.

Core challenges you’ll face:

  • Managing Path Differences → maps to Library files in Chef
  • Platform Mapping → maps to Using Ohai’s node[‘platform’] and node[‘platform_family’]
  • Testing multiple OSs simultaneously → maps to Test Kitchen multi-platform suites

Project 8: The Custom Resource Factory

  • File: CHEF_INFRA_IAC_MASTERY.md
  • Main Programming Language: Ruby
  • Alternative Programming Languages: Rust (custom binary resources)
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 5. The “Industry Disruptor”
  • Difficulty: Level 4: Expert
  • Knowledge Area: Domain Specific Languages (DSL)
  • Software or Tool: Chef Custom Resources
  • Main Book: “Chef Infrastructure Automation Cookbook” by Matthias Marschall

What you’ll build: A custom Chef resource called my_app_deploy. Instead of writing 20 lines of package, directory, and template code for every app, you’ll create a single, clean resource that other developers can use: my_app_deploy 'frontend' { version '1.2.3' }.

Why it teaches Chef: This is where you move from being a “user” of Chef to an “architect.” You’ll learn the difference between a Recipe and a Custom Resource. You’ll handle properties, state tracking, and the “unified mode” of modern Chef.

Core challenges you’ll face:

  • Defining Properties and Types → maps to Ruby metaprogramming
  • Managing Internal State → maps to Load current value / current_resource
  • Creating a Reusable Library → maps to Cookbook structure best practices

Project 9: The Policyfile Revolution

  • File: CHEF_INFRA_IAC_MASTERY.md
  • Main Programming Language: Ruby / JSON
  • Alternative Programming Languages: Terraform State Lock
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Software Supply Chain / Versioning
  • Software or Tool: Chef Policyfiles
  • Main Book: “Infrastructure as Code” by Kief Morris

What you’ll build: A migration from old-school “Roles and Environments” to the modern Policyfile workflow. You’ll create a Policyfile.rb that locks down every single cookbook version and dependency for a specific “Web Server” policy.

Why it teaches Chef: You’ll learn how to solve the “Works on my machine” problem in infrastructure. Policyfiles ensure that the exact code you tested in Test Kitchen is what runs in Production, preventing “dependency hell.”

Core challenges you’ll face:

  • Resolving Dependency Conflicts → maps to Berkshelf vs Policyfile
  • Promoting Policies → maps to Policy Groups (Staging vs Prod)
  • Immutable Infrastructure → maps to Locking state

Project 10: The Bare-Metal Bootstrapper

  • File: CHEF_INFRA_IAC_MASTERY.md
  • Main Programming Language: Ruby / Bash
  • Alternative Programming Languages: Python (Cloud-init)
  • Coolness Level: Level 5: Pure Magic
  • Business Potential: 5. The “Industry Disruptor”
  • Difficulty: Level 5: Master
  • Knowledge Area: Bare-Metal Provisioning / PXE
  • Software or Tool: Knife, SSH, iDRAC/IPMI
  • Main Book: “Chef Infrastructure Automation Cookbook” by Matthias Marschall

What you’ll build: A tool that uses knife bootstrap to take a raw, newly-installed Linux server and bring it into the Chef cluster automatically. You will integrate it with a script that triggers upon first boot (via Cloud-init or PXE).

Why it teaches Chef: This is the “Birth” of a node. You’ll understand how the chef-client gets installed, how it authenticates with the Chef Server using keys (client.pem), and how it fetches its first run-list.

Core challenges you’ll face:

  • Key Exchange/Security → maps to Validation keys and RSA
  • Network Connectivity → maps to Firewalls and Proxies
  • Unattended Installation → maps to Bootstrapping flags and templates