Chef (Week 9)
Chef is a Configuration Management and Infrastructure as Code (IaC) tool used to automate the installation and configuration of software on servers using code. Instead of manually installing software on each server, you write code called recipes and Chef installs automatically.
Why Chef?
| Without Chef | With Chef |
| Login to each server manually | Write one recipe — Chef installs on all servers |
| Time consuming & error-prone | Automated, consistent, scalable |
| Hard to replicate environments | Idempotent — same result every run |
Chef Architecture
Model 1: Chef Server Model (Enterprise)
| Component | Role |
| Chef Server | Stores all configuration (cookbooks) |
| Chef Workstation | Where cookbooks are written and uploaded |
| Chef Client | Runs on each managed node |
| Node | Managed server (EC2 instance) |
Flow — Pull Model
Workstation → Upload cookbook → Chef Server | Node → Pull configuration → Apply
Model 2: Chef Solo / Local Mode
Simpler version with no Chef Server. Recipes stored locally and run using chef-client --local-mode. Best for learning, small projects, or 2–5 servers.
Chef Terminology
| Term | Description |
| Cookbook | Collection of recipes (e.g., nginx_cookbook, java_cookbook) |
| Recipe | Instructions written in Ruby DSL |
| Resource | Basic unit — package, service, file |
| Node | Any managed server (EC2 instance) |
| Run List | Ordered list of recipes to run on a node |
Sample Recipe (Ruby DSL)
package 'nginx' do
action :install
end
service 'nginx' do
action [:enable, :start]
end
Chef Step-by-Step Procedure
Step 1: Install Chef Workstation
wget https://packages.chef.io/files/stable/chef-workstation/...
sudo dpkg -i chef-workstation_*.deb
chef --version
Step 2: Create Cookbook
chef generate cookbook java_cookbook
# Creates structure:
# java_cookbook/
# recipes/default.rb
# metadata.rb
Step 3: Write Recipe
# java_cookbook/recipes/default.rb
package 'openjdk-17-jdk' do
action :install
end
Step 4: Transfer Cookbook to Node
scp -r java_cookbook ubuntu@<node-ip>:/home/ubuntu/
Step 5: Fix Directory Structure on Node
mkdir ~/cookbooks
mv java_cookbook cookbooks/
# Chef local-mode expects: ~/cookbooks/java_cookbook/
Step 6: Run Chef in Local Mode
sudo chef-client --local-mode -o recipe[java_cookbook]
# Nginx node:
sudo chef-client --local-mode --runlist 'recipe[nginx_cookbook]'
Puppet (Week 10)
Puppet is a Configuration Management and Infrastructure as Code (IaC) tool that manages servers automatically using code instead of manual configuration.
Puppet Architecture — Pull Model
| Component | Role |
| Puppet Master | Central configuration server |
| Puppet Agent | Installed on each managed node |
| Node | Managed server (EC2 instance) |
| Manifest | Configuration file (.pp file — Puppet DSL) |
| Catalog | Compiled configuration sent from Master to Agent |
Puppet Workflow
Agent runs on node → Agent contacts Master → Master sends catalog → Agent applies configuration → Agent reports back (every 30 minutes by default)
Puppet Terminology
Manifest (.pp file)
package { 'nginx':
ensure => installed,
}
service { 'nginx':
ensure => running,
enable => true,
}
Node-specific Configuration
node 'ec2-nginx' {
package { 'nginx': ensure => installed }
service { 'nginx': ensure => running }
}
node default {
package { 'openjdk-17-jdk': ensure => installed }
}
Idempotency — Key Concept
If you run Puppet 100 times, it will not reinstall packages that are already installed. It only makes changes when the actual state differs from the desired state. This is called idempotent behavior.
Puppet Step-by-Step Procedure
Step 1–2: Install Puppet Master & Agents
# On Master (EC2-1):
sudo apt install puppetserver -y
sudo systemctl start puppetserver
# On Nodes (EC2-2, EC2-3):
sudo apt install puppet-agent -y
Step 3: Configure Agent to Point to Master
# On each node — edit puppet.conf:
[main]
server = <master-hostname>
Step 4: Sign Certificates on Master
# On Master — list pending requests:
sudo puppetserver ca list
# Sign all agents:
sudo puppetserver ca sign --all
Step 5: Run Puppet Agent on Nodes
sudo puppet agent -t
# Output: Notice: Applied catalogue in X seconds
Ansible (Week 11)
Ansible (by Red Hat) is an agentless automation and configuration management tool used to install software, configure servers, deploy applications, and manage cloud infrastructure. It uses SSH — no agent installation needed on target nodes.
Why Ansible?
| Without Ansible | With Ansible |
| Login to 20 EC2 servers one by one | Run one playbook — configures all servers |
| Manual, error-prone | Automated, repeatable, idempotent |
| No agent needed | Uses SSH — agentless architecture |
Ansible Architecture — Push Model
| Component | Role |
| Control Node | Where Ansible is installed |
| Managed Nodes | Target servers (EC2 instances) |
| Inventory | File listing target servers |
| Playbook | YAML configuration file with tasks |
| Module | Small task unit (apt, service, copy, file, etc.) |
Ansible Concepts
Inventory File
[java_servers]
192.168.1.10
[nginx_servers]
192.168.1.20
Playbook (YAML)
- name: Install Java on all java servers
hosts: java_servers
become: yes
tasks:
- name: Install OpenJDK 17
apt:
name: openjdk-17-jdk
state: present
- name: Start Java verification
command: java -version
Key Ansible Commands
# Run a playbook:
ansible-playbook setup.yml
# Test connectivity:
ansible all -m ping
# Run ad-hoc command on all hosts:
ansible all -m shell -a "java -version"
Important Features
Agentless (SSH only) · Simple YAML syntax · Idempotent · Fast setup · No master server required
SaltStack (Week 12)
SaltStack is a fast configuration management and remote execution tool that manages large-scale infrastructure using a Master–Minion architecture. It supports both push and pull models and uses ZeroMQ for very fast communication.
Salt Architecture
| Component | Role |
| Salt Master | Central control server |
| Salt Minion | Installed on each managed node |
| State File (.sls) | YAML configuration file |
| Pillar | Secure variable data (passwords, keys) |
| Grains | System information (OS, IP, memory) |
Push Model (Remote Execution)
# Master pushes command to all minions instantly:
salt '*' test.ping
salt '*' cmd.run 'apt update'
Pull Model (State Application)
# Minions apply states from master:
salt '*' state.apply
Salt State File
# install_java.sls
install_java:
pkg.installed:
- name: openjdk-17-jdk
start_java_check:
cmd.run:
- name: java -version
SaltStack Setup
# Install Master (EC2-1):
sudo apt install salt-master -y
# Install Minion (EC2-2, EC2-3):
sudo apt install salt-minion -y
# Configure minion to point to master:
# Edit /etc/salt/minion → master: <master-ip>
# Accept minion keys on master:
salt-key -L # List pending
salt-key -A # Accept all
# Test:
salt '*' test.ping
Tool Comparison
| Feature | Chef | Puppet | Ansible | SaltStack |
| Language | Ruby DSL | Puppet DSL | YAML | YAML |
| Model | Pull | Pull | Push | Push & Pull |
| Agent required | Yes (Chef Client) | Yes (Puppet Agent) | No (SSH) | Yes (Salt Minion) |
| Config file | Recipe (.rb) | Manifest (.pp) | Playbook (.yml) | State File (.sls) |
| Speed | Moderate | Moderate | Moderate | Very Fast (ZeroMQ) |
| Learning curve | High (Ruby) | Medium | Low (YAML) | Medium |
| Best for | Complex IaC | Large enterprise | Simple automation | Large-scale / fast |
📄
Configuration Management — Notes PDF
Week 9–12 · Chef, Puppet, Ansible & SaltStack
⬇ Download PDF