{"id":1087,"date":"2026-02-22T08:02:47","date_gmt":"2026-02-22T08:02:47","guid":{"rendered":"https:\/\/devopsschool.org\/blog\/uncategorized\/chef\/"},"modified":"2026-02-22T08:02:47","modified_gmt":"2026-02-22T08:02:47","slug":"chef","status":"publish","type":"post","link":"https:\/\/devopsschool.org\/blog\/chef\/","title":{"rendered":"What is Chef? Meaning, Examples, Use Cases, and How to use it?"},"content":{"rendered":"\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Quick Definition<\/h2>\n\n\n\n<p>Chef is a configuration management and automation tool that defines infrastructure as code to provision, configure, and manage systems consistently across environments.<br\/>\nAnalogy: Chef is like a recipe book for infrastructure where cookbooks are sets of recipes and the chef applies those recipes to servers so they end up the same every time.<br\/>\nFormal technical line: Chef is an infrastructure-as-code platform that uses declarative recipes and a client-server or local execution model to converge system state via resources, cookbooks, recipes, and a node object.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">What is Chef?<\/h2>\n\n\n\n<p>What it is: Chef is an infrastructure automation framework focused on configuration management, system convergence, and idempotent resource execution. It provides a DSL for declaring desired system state, a client to enforce that state, and tooling for packaging and sharing configuration as cookbooks.<\/p>\n\n\n\n<p>What it is NOT: Chef is not a full CI\/CD pipeline, not a general-purpose orchestration engine like Kubernetes, and not a monitoring or observability platform by itself.<\/p>\n\n\n\n<p>Key properties and constraints:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Declarative resources with idempotent behavior.<\/li>\n<li>Supports client-server (Chef Server) and local mode (chef-client &#8211;local-mode).<\/li>\n<li>Extensible via custom resources, libraries, and ohai plugins.<\/li>\n<li>State is represented in node objects and cookbooks, often managed in source control.<\/li>\n<li>Policy-based management possible via Policyfiles or Chef Automate.<\/li>\n<li>Requires secure key management for node authentication.<\/li>\n<li>Works at VM, bare-metal, and container image build time; limited in ephemeral container runtime orchestration.<\/li>\n<\/ul>\n\n\n\n<p>Where it fits in modern cloud\/SRE workflows:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Provisioning and bootstrapping VMs or instances during infrastructure lifecycle.<\/li>\n<li>Image baking (AMI creation) as part of immutable infrastructure patterns.<\/li>\n<li>Configuration drift remediation on long-lived instances.<\/li>\n<li>Integrates with CI\/CD to test cookbooks and apply policies during deployment pipelines.<\/li>\n<li>Used alongside container orchestration for managing nodes or underlying OS configuration rather than pod-level config.<\/li>\n<\/ul>\n\n\n\n<p>Diagram description (text-only):<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Developer writes cookbook in Git.<\/li>\n<li>CI runs linters and unit tests against cookbooks.<\/li>\n<li>Cookbooks uploaded to Chef Server or packaged as policies.<\/li>\n<li>Nodes authenticate to Chef Server and request run-lists.<\/li>\n<li>Chef Server returns desired configuration; client converges system.<\/li>\n<li>Reporting back to Chef Server or Chef Automate for compliance and visibility.<\/li>\n<li>Integrations push telemetry into monitoring and CI systems.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Chef in one sentence<\/h3>\n\n\n\n<p>Chef is an infrastructure-as-code system that codifies system configuration as reusable cookbooks to converge node state reliably across environments.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Chef vs related terms (TABLE REQUIRED)<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Term<\/th>\n<th>How it differs from Chef<\/th>\n<th>Common confusion<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>T1<\/td>\n<td>Puppet<\/td>\n<td>Declarative model with different language and agent model<\/td>\n<td>Confused as same tool category<\/td>\n<\/tr>\n<tr>\n<td>T2<\/td>\n<td>Ansible<\/td>\n<td>Agentless push using SSH versus Chef agent pull<\/td>\n<td>People think Ansible and Chef equal scope<\/td>\n<\/tr>\n<tr>\n<td>T3<\/td>\n<td>Salt<\/td>\n<td>Real-time event driven features versus Chef&#8217;s converge model<\/td>\n<td>Salt often mixed up with orchestration tools<\/td>\n<\/tr>\n<tr>\n<td>T4<\/td>\n<td>Terraform<\/td>\n<td>Infrastructure provisioning vs configuration management<\/td>\n<td>Terraform is not for detailed OS config<\/td>\n<\/tr>\n<tr>\n<td>T5<\/td>\n<td>Kubernetes<\/td>\n<td>Container orchestration not config mgmt for OS<\/td>\n<td>Some expect Chef to manage pods<\/td>\n<\/tr>\n<tr>\n<td>T6<\/td>\n<td>Packer<\/td>\n<td>Image baking tool vs runtime configuration tool<\/td>\n<td>Both used in image workflows<\/td>\n<\/tr>\n<tr>\n<td>T7<\/td>\n<td>Chef Automate<\/td>\n<td>Enterprise UI and compliance layer, not core engine<\/td>\n<td>People think Automate is required<\/td>\n<\/tr>\n<tr>\n<td>T8<\/td>\n<td>Policyfile<\/td>\n<td>Way to pin cookbooks and dependencies<\/td>\n<td>Confused with cookbook versioning<\/td>\n<\/tr>\n<tr>\n<td>T9<\/td>\n<td>Ohai<\/td>\n<td>System discovery tool not config language<\/td>\n<td>Sometimes mistaken for monitoring<\/td>\n<\/tr>\n<tr>\n<td>T10<\/td>\n<td>Habitus<\/td>\n<td>Not Chef Habitat; different ecosystem<\/td>\n<td>Name confusion causes mistakes<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if any cell says \u201cSee details below\u201d)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Why does Chef matter?<\/h2>\n\n\n\n<p>Business impact:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Revenue: Reduces outages and misconfiguration-related downtime that can directly impact revenue by ensuring consistent deployments.<\/li>\n<li>Trust: Improves reproducibility of environments leading to predictable customer experiences.<\/li>\n<li>Risk: Enables compliance checks and automated remediation to reduce audit and security risks.<\/li>\n<\/ul>\n\n\n\n<p>Engineering impact:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Incident reduction: By fixing drift and automating configuration, fewer incidents are caused by human error.<\/li>\n<li>Velocity: Teams can onboard infrastructure changes faster with repeatable cookbooks and CI gating.<\/li>\n<li>Knowledge capture: Cookbooks encode operational knowledge reducing tribal knowledge risk.<\/li>\n<\/ul>\n\n\n\n<p>SRE framing:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SLIs\/SLOs: Chef helps maintain availability and configuration compliance SLIs by ensuring desired state.<\/li>\n<li>Error budgets: Faster remediation reduces SLO burn during configuration incidents.<\/li>\n<li>Toil reduction: Automating repetitive configuration tasks reduces manual toil for on-call engineers.<\/li>\n<li>On-call: Clear runbooks from cookbook actions reduce cognitive load during incidents.<\/li>\n<\/ul>\n\n\n\n<p>What breaks in production \u2014 realistic examples:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Drift causes a security package to be missing on a subset of hosts leading to a vulnerability.<\/li>\n<li>Uncoordinated manual config changes override app settings causing inconsistent behavior across availability zones.<\/li>\n<li>Wrong package version rolled into AMIs causes a cascading failure when instances scale.<\/li>\n<li>Improper service restarts after configuration changes cause downtime during deployments.<\/li>\n<li>Secrets or credentials mis-provisioned due to environment mismatch leading to authentication failures.<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Where is Chef used? (TABLE REQUIRED)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Layer\/Area<\/th>\n<th>How Chef appears<\/th>\n<th>Typical telemetry<\/th>\n<th>Common tools<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>L1<\/td>\n<td>Edge network<\/td>\n<td>Configure load balancers and proxies<\/td>\n<td>Config drift and update success<\/td>\n<td>Chef, Syslog, Netflow<\/td>\n<\/tr>\n<tr>\n<td>L2<\/td>\n<td>OS service<\/td>\n<td>Manage packages and services<\/td>\n<td>Service uptime and restart counts<\/td>\n<td>Chef, systemd, Prometheus<\/td>\n<\/tr>\n<tr>\n<td>L3<\/td>\n<td>App runtime<\/td>\n<td>Deploy config files and env vars<\/td>\n<td>App startup time and config diff<\/td>\n<td>Chef, Consul, Vault<\/td>\n<\/tr>\n<tr>\n<td>L4<\/td>\n<td>Image build<\/td>\n<td>Bake AMIs and images with desired state<\/td>\n<td>Build success and artifact size<\/td>\n<td>Chef, Packer, Artifact repo<\/td>\n<\/tr>\n<tr>\n<td>L5<\/td>\n<td>Kubernetes nodes<\/td>\n<td>Ensure node OS and kubelet config<\/td>\n<td>Node readiness and kubelet restarts<\/td>\n<td>Chef, kubelet, node-exporter<\/td>\n<\/tr>\n<tr>\n<td>L6<\/td>\n<td>CI\/CD<\/td>\n<td>Test and apply cookbooks in pipelines<\/td>\n<td>Lint pass rate and test duration<\/td>\n<td>Git, CI, ChefDK<\/td>\n<\/tr>\n<tr>\n<td>L7<\/td>\n<td>Security\/compliance<\/td>\n<td>Apply compliance profiles and fixes<\/td>\n<td>Compliance drift and failure rate<\/td>\n<td>Chef InSpec, Chef Automate<\/td>\n<\/tr>\n<tr>\n<td>L8<\/td>\n<td>Serverless\/managed<\/td>\n<td>Bootstrap build-time config only<\/td>\n<td>Build logs and deploy success<\/td>\n<td>Chef limited use, CI logs<\/td>\n<\/tr>\n<tr>\n<td>L9<\/td>\n<td>Observability<\/td>\n<td>Configure agents and configs<\/td>\n<td>Agent health and metric scrape status<\/td>\n<td>Chef, Prometheus, Datadog<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">When should you use Chef?<\/h2>\n\n\n\n<p>When it\u2019s necessary:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You manage many long-lived instances requiring consistent OS-level configuration.<\/li>\n<li>You need automated compliance and remediation across fleets.<\/li>\n<li>Your organization relies on infrastructure-as-code and wants versioned cookbooks.<\/li>\n<\/ul>\n\n\n\n<p>When it\u2019s optional:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>For small fleets where ad-hoc scripts would suffice.<\/li>\n<li>For ephemeral containerized workloads where Kubernetes config maps and image baking are preferred.<\/li>\n<\/ul>\n\n\n\n<p>When NOT to use \/ overuse it:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid using Chef to orchestrate per-request, high-frequency tasks better handled by application code or event-driven systems.<\/li>\n<li>Do not use Chef inside short-lived containers for runtime configuration; prefer image build or container orchestration methods.<\/li>\n<\/ul>\n\n\n\n<p>Decision checklist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If you have heterogeneous OSs and long-lived nodes AND need compliance -&gt; Use Chef.<\/li>\n<li>If you are adopting immutable infrastructure and Kubernetes-native config -&gt; Consider images + Kubernetes tools instead.<\/li>\n<li>If you need fast ephemeral scaling with no persistent state -&gt; Avoid using Chef for runtime.<\/li>\n<\/ul>\n\n\n\n<p>Maturity ladder:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Beginner: Use community cookbooks, run chef-client in local mode, focus on idempotent resources.<\/li>\n<li>Intermediate: Adopt Policyfiles, CI testing, integrate InSpec for compliance.<\/li>\n<li>Advanced: Use Chef Automate for visibility, staged deployments, manage node policies at scale, integrate with secret stores and image baking.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">How does Chef work?<\/h2>\n\n\n\n<p>Components and workflow:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Author cookbooks and resources in a VCS.<\/li>\n<li>Test cookbooks locally with unit tests and Test Kitchen.<\/li>\n<li>Upload cookbooks or publish policyfiles to Chef Server or store them in artifact repo.<\/li>\n<li>Nodes authenticate using client keys and request their run-list or policy from Chef Server.<\/li>\n<li>Chef Client executes resources to converge node state and reports results back.<\/li>\n<li>Optional: Chef Automate aggregates reports, runs compliance scans, and provides dashboards.<\/li>\n<\/ol>\n\n\n\n<p>Data flow and lifecycle:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Source code -&gt; CI -&gt; Cookbooks\/Policies -&gt; Chef Server -&gt; Node pulls -&gt; Chef Client converges -&gt; Reports sent back -&gt; Operators observe and adjust.<\/li>\n<\/ul>\n\n\n\n<p>Edge cases and failure modes:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Partial convergence due to interrupted runs.<\/li>\n<li>Resource dependency cycles causing failures.<\/li>\n<li>Network partitions preventing nodes from reaching server.<\/li>\n<li>Secret rotation not propagated leading to auth failures.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Typical architecture patterns for Chef<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Classic Chef Server pattern: Central Chef Server with multiple nodes pulling run-lists; use when many nodes and policies are centralized.<\/li>\n<li>Workstation + Chef Server: DevOps authors cookbooks from a workstation, run CI, and upload to server; good for teams with developers contributing to infra.<\/li>\n<li>Local mode \/ chef-solo: Run cookbooks locally or during image build; useful for immutable images and small environments.<\/li>\n<li>Chef Automate + Compliance: Add Automate for visibility, compliance, and workflow; suitable for regulated environments.<\/li>\n<li>Hybrid with IaC: Terraform provisions cloud infrastructure, Chef configures OS and applications; best for separation of concerns.<\/li>\n<li>Image baking integration: Use Packer to run Chef during image build to produce hardened artifacts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Failure modes &amp; mitigation (TABLE REQUIRED)<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Failure mode<\/th>\n<th>Symptom<\/th>\n<th>Likely cause<\/th>\n<th>Mitigation<\/th>\n<th>Observability signal<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>F1<\/td>\n<td>Node can&#8217;t reach server<\/td>\n<td>Chef run fails with network error<\/td>\n<td>Network\/DNS or firewall issue<\/td>\n<td>Retry, alert network team<\/td>\n<td>Connection error rate<\/td>\n<\/tr>\n<tr>\n<td>F2<\/td>\n<td>Convergence fails<\/td>\n<td>Resources show failed state<\/td>\n<td>Cookbooks with bugs or missing deps<\/td>\n<td>Revert policy, fix tests<\/td>\n<td>Failed resource count<\/td>\n<\/tr>\n<tr>\n<td>F3<\/td>\n<td>Drift continues<\/td>\n<td>Drift detected after run<\/td>\n<td>Resource not declared or non-idempotent<\/td>\n<td>Add resource checks, idempotent code<\/td>\n<td>Drift detection alerts<\/td>\n<\/tr>\n<tr>\n<td>F4<\/td>\n<td>Slow runs<\/td>\n<td>Chef runs exceed run interval<\/td>\n<td>Heavy compile phase or numerous resources<\/td>\n<td>Optimize cookbooks, converge frequency<\/td>\n<td>Run duration trend<\/td>\n<\/tr>\n<tr>\n<td>F5<\/td>\n<td>Secret leak<\/td>\n<td>Secrets found in node attributes<\/td>\n<td>Plaintext secrets in cookbooks<\/td>\n<td>Move to Vault and encrypt data bags<\/td>\n<td>Secret exposure alert<\/td>\n<\/tr>\n<tr>\n<td>F6<\/td>\n<td>Dependency conflicts<\/td>\n<td>Cookbook upload rejects<\/td>\n<td>Gem or cookbook version conflicts<\/td>\n<td>Use Policyfiles and dependency locking<\/td>\n<td>Upload error logs<\/td>\n<\/tr>\n<tr>\n<td>F7<\/td>\n<td>Partial upgrades<\/td>\n<td>Mixed cookbook versions on nodes<\/td>\n<td>Staggered upgrades or failed nodes<\/td>\n<td>Force policy sync or rollback<\/td>\n<td>Version drift metric<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Key Concepts, Keywords &amp; Terminology for Chef<\/h2>\n\n\n\n<p>(Glossary of 40+ terms. Each line: Term \u2014 definition \u2014 why it matters \u2014 common pitfall)<\/p>\n\n\n\n<p>Abstraction Resource \u2014 Declarative unit representing state change \u2014 Core building block \u2014 Creating non-idempotent actions<br\/>\nAttribute \u2014 Node-level key value used in cookbooks \u2014 Drives configuration variation \u2014 Overuse leads to inconsistent defaults<br\/>\nChef Server \u2014 Central store for cookbooks and node data \u2014 Coordinates nodes \u2014 Single point if not HA<br\/>\nChef Client \u2014 Agent that applies cookbooks on nodes \u2014 Executes convergence \u2014 Not running causes drift<br\/>\nCookbook \u2014 Package of recipes, resources and files \u2014 Reuse and share configs \u2014 Unversioned cookbooks cause surprises<br\/>\nRecipe \u2014 A sequence of resource declarations \u2014 Implements configuration \u2014 Long recipes reduce reusability<br\/>\nResource \u2014 Chef primitive like package service file \u2014 Idempotent operations \u2014 Misused resources cause non-idempotence<br\/>\nProvider \u2014 Implements resource actions for platforms \u2014 Handles platform specifics \u2014 Unsupported providers fail on some OSs<br\/>\nOhai \u2014 Node discovery system that collects system data \u2014 Used in attribute context \u2014 Missing plugins reduce context<br\/>\nData Bag \u2014 JSON storage for node data \u2014 Useful for shared config \u2014 Plaintext storage is insecure<br\/>\nEncrypted Data Bag \u2014 Encrypted data bag variant \u2014 Protects secrets \u2014 Key management is required<br\/>\nPolicyfile \u2014 Way to lock cookbook versions and run-lists \u2014 Ensures reproducible runs \u2014 Adoption learning curve<br\/>\nRole \u2014 Legacy construct for grouping run-lists \u2014 Useful for global roles \u2014 Conflicts with environments and policyfiles<br\/>\nEnvironment \u2014 Scopes attributes and cookbook versions \u2014 Controls per-stage behavior \u2014 Overcomplicates when mixed with roles<br\/>\nKnife \u2014 CLI tool for Chef operations \u2014 Admin tasks and uploads \u2014 Misuse can cause accidental changes<br\/>\nTest Kitchen \u2014 Tool for testing cookbooks in VMs or containers \u2014 Validates changes \u2014 Slow without caching<br\/>\nInSpec \u2014 Compliance and testing framework \u2014 Automates compliance checks \u2014 Test drift if not maintained<br\/>\nChef Automate \u2014 Enterprise UI and analytics layer \u2014 Compliance and workflow \u2014 Not required for core features<br\/>\nHabitat \u2014 Different Chef project for application packaging \u2014 Focus on app automation \u2014 Confused with Chef core<br\/>\nOhai plugin \u2014 Extends platform detection \u2014 Improves targeting \u2014 Platform misdetection possible<br\/>\nRun-list \u2014 Ordered list of recipes and roles for a node \u2014 Drives node converge \u2014 Long run-lists make debugging hard<br\/>\nClient key \u2014 Private key used by nodes to authenticate \u2014 Security critical \u2014 Compromise allows node impersonation<br\/>\nChefDK \/ Workstation \u2014 Development tooling bundle \u2014 Local test and authoring \u2014 Outdated versions cause tool mismatch<br\/>\nCookstyle \u2014 Linter for Chef code \u2014 Enforces style \u2014 Ignoring linting increases bugs<br\/>\nBerkshelf \u2014 Cookbook dependency manager \u2014 Simplifies dependencies \u2014 Conflicts without locking<br\/>\nPolicy Group \u2014 Grouping of policies for stages \u2014 Manages promotion flow \u2014 Misconfiguration can block deploys<br\/>\nHandler \u2014 Event hooks for Chef runs \u2014 Custom reporting or actions \u2014 Handlers can leak resources if miswritten<br\/>\nOhai hint \u2014 Small file to influence Ohai behavior \u2014 Platform detection control \u2014 Forgotten hints change detection<br\/>\nResource Guard \u2014 Conditional guard to avoid actions \u2014 Prevents unsafe operations \u2014 Overuse causes divergence<br\/>\nIdempotence \u2014 Ability to apply same operation repeatedly with same result \u2014 Essential for safe automation \u2014 Non-idempotent code breaks retries<br\/>\nConverge \u2014 Process of applying changes to reach desired state \u2014 Core runtime action \u2014 Mid-run failures leave partial state<br\/>\nChef Vault \u2014 Secret management integration \u2014 Securely distribute secrets \u2014 Complexity in rotation<br\/>\nService resource \u2014 Manages system services \u2014 Ensures services running \u2014 Race conditions during restarts<br\/>\nTemplate \u2014 ERB-based file rendering \u2014 Templatize config files \u2014 Secrets in templates are risky<br\/>\nOhai attribute precedence \u2014 Order of attribute evaluation \u2014 Resolves conflicts \u2014 Misunderstanding leads to wrong values<br\/>\nResource notifications \u2014 Triggers to restart or reload resources \u2014 Coordinate dependent changes \u2014 Notification loops possible<br\/>\nDelayed vs immediate notifications \u2014 Timing of notifications during run \u2014 Controls restart timing \u2014 Mis-timing can cause state issues<br\/>\nBootstrap \u2014 Initial node setup to install chef-client \u2014 First step for new nodes \u2014 Incorrect bootstrap causes authentication errors<br\/>\nCompliance profile \u2014 InSpec packaged rules \u2014 Enforces policy \u2014 Outdated profiles misrepresent compliance<br\/>\nImmutable infrastructure \u2014 Pattern of replacing rather than changing nodes \u2014 Use Chef during bake phase \u2014 Misused for runtime changes<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">How to Measure Chef (Metrics, SLIs, SLOs) (TABLE REQUIRED)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Metric\/SLI<\/th>\n<th>What it tells you<\/th>\n<th>How to measure<\/th>\n<th>Starting target<\/th>\n<th>Gotchas<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>M1<\/td>\n<td>Chef run success rate<\/td>\n<td>Percent of successful chef runs<\/td>\n<td>SuccessCount \/ TotalRuns per hour<\/td>\n<td>99% daily<\/td>\n<td>Skewed by scheduled runs<\/td>\n<\/tr>\n<tr>\n<td>M2<\/td>\n<td>Run duration<\/td>\n<td>Time chef-client takes to converge<\/td>\n<td>Median and p95 run time<\/td>\n<td>p95 &lt; 5m for small fleets<\/td>\n<td>Long runs may be normal at scale<\/td>\n<\/tr>\n<tr>\n<td>M3<\/td>\n<td>Drift events<\/td>\n<td>Number of manual drifts detected<\/td>\n<td>Drift detections per day<\/td>\n<td>&lt; 5 per 100 nodes<\/td>\n<td>Detection depends on tooling<\/td>\n<\/tr>\n<tr>\n<td>M4<\/td>\n<td>Failed resources<\/td>\n<td>Failed resource count per run<\/td>\n<td>Sum failed resources per run<\/td>\n<td>0 critical failures<\/td>\n<td>Non-critical failures may be acceptable<\/td>\n<\/tr>\n<tr>\n<td>M5<\/td>\n<td>Policy sync lag<\/td>\n<td>Time between policy publish and node sync<\/td>\n<td>PublishTime to NodeSyncTime<\/td>\n<td>&lt; 15m for critical patches<\/td>\n<td>Depends on run interval<\/td>\n<\/tr>\n<tr>\n<td>M6<\/td>\n<td>Secret access failures<\/td>\n<td>Secret retrieval failure rate<\/td>\n<td>SecretErrors \/ Attempts<\/td>\n<td>&lt; 0.1%<\/td>\n<td>Secrets rotation can spike this<\/td>\n<\/tr>\n<tr>\n<td>M7<\/td>\n<td>Compliance failure rate<\/td>\n<td>Failed InSpec controls percent<\/td>\n<td>FailedControls \/ TotalControls<\/td>\n<td>&lt; 1% in prod<\/td>\n<td>Profiles vary by baseline<\/td>\n<\/tr>\n<tr>\n<td>M8<\/td>\n<td>Upload errors<\/td>\n<td>Cookbook upload failure count<\/td>\n<td>UploadErrors per day<\/td>\n<td>0 expected<\/td>\n<td>CI races can cause transient errors<\/td>\n<\/tr>\n<tr>\n<td>M9<\/td>\n<td>Chef client offline nodes<\/td>\n<td>Nodes not checking in<\/td>\n<td>NodesLastSeen &gt; threshold<\/td>\n<td>&lt; 1% nodes<\/td>\n<td>Maintenance and scheduling affect metric<\/td>\n<\/tr>\n<tr>\n<td>M10<\/td>\n<td>Run frequency adherence<\/td>\n<td>Nodes within expected run window<\/td>\n<td>NodesRunInWindow \/ TotalNodes<\/td>\n<td>95%<\/td>\n<td>Nodes with different schedules skew metric<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Best tools to measure Chef<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Prometheus + node_exporter<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Chef: Node-level metrics like run duration, CPU, and process metrics.<\/li>\n<li>Best-fit environment: Linux\/Unix fleets and Kubernetes nodes.<\/li>\n<li>Setup outline:<\/li>\n<li>Install node_exporter on nodes or scrape exporter metrics.<\/li>\n<li>Expose Chef run metrics via node exporter or pushgateway.<\/li>\n<li>Create Prometheus jobs to scrape Chef metrics endpoints.<\/li>\n<li>Configure service discovery for dynamic fleets.<\/li>\n<li>Store metrics and set up recording rules.<\/li>\n<li>Strengths:<\/li>\n<li>Open-source and flexible.<\/li>\n<li>Good for custom metrics and high cardinality.<\/li>\n<li>Limitations:<\/li>\n<li>Requires PromQL knowledge.<\/li>\n<li>Long-term storage needs additional components.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Datadog<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Chef: Chef run monitoring, event streams, and host-level telemetry.<\/li>\n<li>Best-fit environment: Cloud environments and enterprises.<\/li>\n<li>Setup outline:<\/li>\n<li>Install Datadog agent on nodes.<\/li>\n<li>Configure Chef integration to capture run metadata.<\/li>\n<li>Forward chef-client logs as events.<\/li>\n<li>Create dashboards and monitors.<\/li>\n<li>Strengths:<\/li>\n<li>Rich integrations and built-in dashboards.<\/li>\n<li>Alerting and automation features.<\/li>\n<li>Limitations:<\/li>\n<li>Commercial cost.<\/li>\n<li>Proprietary data model.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Chef Automate<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Chef: Compliance, run reports, and cookbook analytics.<\/li>\n<li>Best-fit environment: Organizations using Chef at scale.<\/li>\n<li>Setup outline:<\/li>\n<li>Install Automate and connect Chef Server.<\/li>\n<li>Enable reporting and compliance ingestion.<\/li>\n<li>Configure teams and access controls.<\/li>\n<li>Strengths:<\/li>\n<li>Native view into Chef data.<\/li>\n<li>Compliance-driven workflows.<\/li>\n<li>Limitations:<\/li>\n<li>Enterprise licensing.<\/li>\n<li>Operational overhead.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 ELK Stack (Elasticsearch Logstash Kibana)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Chef: Chef-client logs, upload events, and run detail logs.<\/li>\n<li>Best-fit environment: Centralized log analysis on-prem or cloud.<\/li>\n<li>Setup outline:<\/li>\n<li>Forward chef-client logs to Logstash or Beats.<\/li>\n<li>Parse and index run status and resource outputs.<\/li>\n<li>Build Kibana dashboards for run trends.<\/li>\n<li>Strengths:<\/li>\n<li>Flexible log search.<\/li>\n<li>Good for forensic analysis.<\/li>\n<li>Limitations:<\/li>\n<li>Storage and index management required.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Grafana Cloud<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Chef: Dashboards for Prometheus or other metric backends related to Chef.<\/li>\n<li>Best-fit environment: Cloud-hosted metrics visualization.<\/li>\n<li>Setup outline:<\/li>\n<li>Connect metric sources like Prometheus or Graphite.<\/li>\n<li>Build dashboards for run history and compliance trends.<\/li>\n<li>Configure alerting rules and notification channels.<\/li>\n<li>Strengths:<\/li>\n<li>Strong visualization.<\/li>\n<li>Multi-data-source support.<\/li>\n<li>Limitations:<\/li>\n<li>Alerting maturity depends on backend chosen.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Recommended dashboards &amp; alerts for Chef<\/h3>\n\n\n\n<p>Executive dashboard:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels: Overall Chef run success rate, Compliance score, Number of nodes, Time to remediate critical failures.<\/li>\n<li>Why: High-level health indicators for leadership and risk posture.<\/li>\n<\/ul>\n\n\n\n<p>On-call dashboard:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels: Failed runs in last hour, Nodes offline with last seen timestamp, Top failing resources, Recent run logs.<\/li>\n<li>Why: Provide quick triage context for responders.<\/li>\n<\/ul>\n\n\n\n<p>Debug dashboard:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels: Per-node run duration, Resource-level failures, Chef client logs output, Network connectivity checks.<\/li>\n<li>Why: Deep troubleshooting during incidents.<\/li>\n<\/ul>\n\n\n\n<p>Alerting guidance:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Page vs ticket:<\/li>\n<li>Page for systemic failures affecting many nodes or critical compliance breaches.<\/li>\n<li>Ticket for single-node failures with low impact.<\/li>\n<li>Burn-rate guidance:<\/li>\n<li>If compliance SLO breached rapidly, page on-call and consider rolling halt of changes.<\/li>\n<li>Noise reduction tactics:<\/li>\n<li>Deduplicate alerts per policy and group by resource or class.<\/li>\n<li>Suppress transient alerts with short recovery windows.<\/li>\n<li>Rate-limit per node for repetitive failures.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Implementation Guide (Step-by-step)<\/h2>\n\n\n\n<p>1) Prerequisites\n&#8211; Define supported OS platforms and versions.\n&#8211; Set up version control for cookbooks.\n&#8211; Provision Chef Server or decide on local mode.\n&#8211; Establish secret management (Vault or Chef Vault).\n&#8211; Define CI for cookbook testing.<\/p>\n\n\n\n<p>2) Instrumentation plan\n&#8211; Decide which Chef metrics to emit (run success, duration).\n&#8211; Add handler to emit Chef run events to monitoring.\n&#8211; Instrument compliance using InSpec.<\/p>\n\n\n\n<p>3) Data collection\n&#8211; Centralize chef-client logs to logging backend.\n&#8211; Export node attributes and run reports into Chef Automate or ELK.\n&#8211; Collect host metrics via Prometheus or APM tools.<\/p>\n\n\n\n<p>4) SLO design\n&#8211; Define SLI for run success and compliance.\n&#8211; Set baseline SLO targets (see metric table).\n&#8211; Create error budget and alerting thresholds.<\/p>\n\n\n\n<p>5) Dashboards\n&#8211; Implement Executive, On-call, and Debug dashboards as described earlier.<\/p>\n\n\n\n<p>6) Alerts &amp; routing\n&#8211; Configure alerts for failed run rate, offline nodes, and compliance breaches.\n&#8211; Route critical pages to SRE lead and ops channel, tickets to platform team.<\/p>\n\n\n\n<p>7) Runbooks &amp; automation\n&#8211; Create runbooks for common failures and autorun remediation scripts.\n&#8211; Automate safe rollbacks and policy reversion procedures.<\/p>\n\n\n\n<p>8) Validation (load\/chaos\/game days)\n&#8211; Run image bake tests and validate cookbooks under load.\n&#8211; Perform chaos tests: simulate network partitions, Chef Server outage.\n&#8211; Run game days for on-call teams to exercise runbook actions.<\/p>\n\n\n\n<p>9) Continuous improvement\n&#8211; Review incidents and update cookbooks and runbooks.\n&#8211; Enforce code review and CI checks for cookbook changes.\n&#8211; Schedule periodic compliance profile updates.<\/p>\n\n\n\n<p>Pre-production checklist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>CI passes lint and unit tests.<\/li>\n<li>Test Kitchen verification in target OS.<\/li>\n<li>Compliance profile runs green in staging.<\/li>\n<li>Secrets are handled via encrypted bags or external secret store.<\/li>\n<li>Backup of Chef Server and key rotation plan.<\/li>\n<\/ul>\n\n\n\n<p>Production readiness checklist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Chef run SLOs defined and monitored.<\/li>\n<li>Alerting routes validated and tested.<\/li>\n<li>Runbooks available and accessible to on-call.<\/li>\n<li>HA for Chef Server or fallback local mode plan.<\/li>\n<li>Versioned cookbooks and rollback plan.<\/li>\n<\/ul>\n\n\n\n<p>Incident checklist specific to Chef:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Identify scope: nodes affected and last successful run.<\/li>\n<li>Check Chef Server health and authentication logs.<\/li>\n<li>Rollback recent cookbook\/policy if needed.<\/li>\n<li>Re-run chef-client with debug enabled on sample node.<\/li>\n<li>Validate remediation and close postmortem loop.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Use Cases of Chef<\/h2>\n\n\n\n<p>1) OS hardening for compliance\n&#8211; Context: Regulated environment requiring consistent hardening.\n&#8211; Problem: Manual hardening is inconsistent.\n&#8211; Why Chef helps: Automates and enforces configuration with InSpec checks.\n&#8211; What to measure: Compliance failure rate.\n&#8211; Typical tools: Chef, InSpec, Chef Automate.<\/p>\n\n\n\n<p>2) Image baking for immutable infra\n&#8211; Context: Cloud deployments using AMIs.\n&#8211; Problem: Manual AMI building creates inconsistencies.\n&#8211; Why Chef helps: Run Chef during Packer builds to produce pre-configured images.\n&#8211; What to measure: Build success rate and image drift.\n&#8211; Typical tools: Packer, Chef, Artifact repo.<\/p>\n\n\n\n<p>3) Configuration drift remediation\n&#8211; Context: Long-lived VMs diverge from baseline.\n&#8211; Problem: Manual fixes cause drift.\n&#8211; Why Chef helps: Converge nodes back to declared state periodically.\n&#8211; What to measure: Drift events per week.\n&#8211; Typical tools: Chef, Prometheus.<\/p>\n\n\n\n<p>4) Service bootstrap and lifecycle\n&#8211; Context: Deploying middleware and applications on VMs.\n&#8211; Problem: Complex service startup order and dependency management.\n&#8211; Why Chef helps: Encodes ordering and notifications.\n&#8211; What to measure: Service start success and restart counts.\n&#8211; Typical tools: Chef, systemd, Consul.<\/p>\n\n\n\n<p>5) Scaling hybrid on-prem + cloud\n&#8211; Context: Mixed infrastructure environments.\n&#8211; Problem: Inconsistent tooling and onboarding.\n&#8211; Why Chef helps: Single tooling for heterogeneous platforms.\n&#8211; What to measure: Node configuration parity.\n&#8211; Typical tools: Chef, Knife, Inventory systems.<\/p>\n\n\n\n<p>6) Secret distribution in closed networks\n&#8211; Context: Air-gapped or limited-network sites.\n&#8211; Problem: Securely distribute credentials.\n&#8211; Why Chef helps: Encrypted data bags or Vault integration run during bootstrap.\n&#8211; What to measure: Secret retrieval success and access logs.\n&#8211; Typical tools: Chef Vault, HashiCorp Vault.<\/p>\n\n\n\n<p>7) Compliance reporting for audits\n&#8211; Context: Auditors require evidence of compliance.\n&#8211; Problem: Manual evidence gathering is slow.\n&#8211; Why Chef helps: InSpec profiles provide automated reports.\n&#8211; What to measure: Time to produce audit reports.\n&#8211; Typical tools: Chef Automate, InSpec, Reporting storage.<\/p>\n\n\n\n<p>8) Multi-environment promotion\n&#8211; Context: Promote config from dev to prod.\n&#8211; Problem: Drift in promotion steps and versions.\n&#8211; Why Chef helps: Policyfiles and policy groups manage promotion flow.\n&#8211; What to measure: Policy promotion latency.\n&#8211; Typical tools: Policyfiles, CI.<\/p>\n\n\n\n<p>9) Emergency patching\n&#8211; Context: Critical CVE discovered.\n&#8211; Problem: Rapidly patching fleets reliably.\n&#8211; Why Chef helps: Push cookbooks to remediate and verify.\n&#8211; What to measure: Patch coverage and time to remediate.\n&#8211; Typical tools: Chef, Automate, Monitoring.<\/p>\n\n\n\n<p>10) OS configuration for Kubernetes nodes\n&#8211; Context: Kubernetes cluster underlying node config.\n&#8211; Problem: Kubelet and OS tuning inconsistent across nodes.\n&#8211; Why Chef helps: Ensure kubelet flags and sysctl applied at node level.\n&#8211; What to measure: Node readiness and kubelet restart rate.\n&#8211; Typical tools: Chef, kubelet, node-exporter.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Scenario Examples (Realistic, End-to-End)<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #1 \u2014 Kubernetes node OS compliance and bake<\/h3>\n\n\n\n<p><strong>Context:<\/strong> A company runs Kubernetes clusters across cloud providers and needs consistent OS tuning.<br\/>\n<strong>Goal:<\/strong> Ensure node OS configuration and kubelet settings are standardized and baked into images.<br\/>\n<strong>Why Chef matters here:<\/strong> Chef enforces OS-level settings and runs during image bake for immutable nodes.<br\/>\n<strong>Architecture \/ workflow:<\/strong> Git cookbooks -&gt; CI tests -&gt; Packer runs Chef during image build -&gt; AMIs published -&gt; Autoscaling pools use images -&gt; Nodes run minimal chef-client for last-mile tweaks.<br\/>\n<strong>Step-by-step implementation:<\/strong> 1) Write resources for sysctl and kubelet config. 2) Test with Test Kitchen. 3) Integrate with Packer to run chef-client. 4) Publish image. 5) Replace node groups via rolling update.<br\/>\n<strong>What to measure:<\/strong> Image build success, node readiness time, kubelet restart rate.<br\/>\n<strong>Tools to use and why:<\/strong> Chef for OS config, Packer for image bake, Prometheus for node telemetry.<br\/>\n<strong>Common pitfalls:<\/strong> Forgetting cloud-init or user-data overrides; neglecting kubelet version compatibility.<br\/>\n<strong>Validation:<\/strong> Deploy a canary node pool, run readiness and performance tests.<br\/>\n<strong>Outcome:<\/strong> Standardized node images with reduced drift and improved reliability.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #2 \u2014 Serverless build-time configuration<\/h3>\n\n\n\n<p><strong>Context:<\/strong> Team deploys serverless functions and needs consistent build-time dependencies and credentials.<br\/>\n<strong>Goal:<\/strong> Ensure artifacts are built with standard config and secrets at build time.<br\/>\n<strong>Why Chef matters here:<\/strong> Use Chef in CI to configure build environments and bake artifacts rather than runtime.<br\/>\n<strong>Architecture \/ workflow:<\/strong> Cookbooks in Git -&gt; CI runs Chef in local mode to provision build agent -&gt; Build artifact produced and uploaded -&gt; Deployment triggers.<br\/>\n<strong>Step-by-step implementation:<\/strong> 1) Create cookbook that installs build dependencies. 2) Use chef-client local mode in CI container. 3) Inject secrets via encrypted data bags only at build time. 4) Validate artifacts and publish.<br\/>\n<strong>What to measure:<\/strong> Build success rate and artifact reproducibility.<br\/>\n<strong>Tools to use and why:<\/strong> Chef local mode for build agents, CI system, encrypted secret store.<br\/>\n<strong>Common pitfalls:<\/strong> Including runtime secrets inside artifacts; poor secret rotation.<br\/>\n<strong>Validation:<\/strong> Repeatable builds produce identical checksums.<br\/>\n<strong>Outcome:<\/strong> Consistent serverless artifacts and faster deploy confidence.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #3 \u2014 Incident response: configuration-caused outage<\/h3>\n\n\n\n<p><strong>Context:<\/strong> After a policy change, a service across multiple zones failed to start.<br\/>\n<strong>Goal:<\/strong> Rapidly identify and remediate the misconfiguration and prevent recurrence.<br\/>\n<strong>Why Chef matters here:<\/strong> Chef run reports and cookbooks point to the change set and enable rolling fixes.<br\/>\n<strong>Architecture \/ workflow:<\/strong> Chef Server stores policies; nodes report failures to monitoring; SRE investigates and reverts policy if necessary.<br\/>\n<strong>Step-by-step implementation:<\/strong> 1) Triage using run logs and Automate reports. 2) Isolate affected policy version. 3) Rollback policy and re-deploy. 4) Patch cookbook and add tests. 5) Postmortem and update runbooks.<br\/>\n<strong>What to measure:<\/strong> Time to rollback, nodes recovered, recurrence rate.<br\/>\n<strong>Tools to use and why:<\/strong> Chef Automate for reports, Logging stack for run logs, CI for cookbook tests.<br\/>\n<strong>Common pitfalls:<\/strong> Slow policy promotion and missing runbooks for rollback.<br\/>\n<strong>Validation:<\/strong> Re-run test suite and a staged rollout.<br\/>\n<strong>Outcome:<\/strong> Reduced downtime and improved change controls.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #4 \u2014 Cost vs performance tuning for web services<\/h3>\n\n\n\n<p><strong>Context:<\/strong> A fleet of VMs hosts web services with variable traffic and cost sensitivity.<br\/>\n<strong>Goal:<\/strong> Optimize OS and service configuration to balance latency and cost.<br\/>\n<strong>Why Chef matters here:<\/strong> Chef can apply tuned kernel, NUMA, and service settings consistently across instance types and environments.<br\/>\n<strong>Architecture \/ workflow:<\/strong> Benchmarks run in staging -&gt; Cookbooks parameterize tuning for instance families -&gt; CI promotes tuned policies -&gt; Monitoring measures latency and cost metrics.<br\/>\n<strong>Step-by-step implementation:<\/strong> 1) Benchmark different tuning configs. 2) Encode winning configs as attribute driven cookbooks. 3) Use policyfile promotion for instance classes. 4) Observe and adjust.<br\/>\n<strong>What to measure:<\/strong> Request latency p95, cost per request, CPU efficiency.<br\/>\n<strong>Tools to use and why:<\/strong> Chef for configuration, APM for latency, cloud cost tools.<br\/>\n<strong>Common pitfalls:<\/strong> Over-tuning causing instability under bursty workloads.<br\/>\n<strong>Validation:<\/strong> Run load profiles and compare cost\/perf.<br\/>\n<strong>Outcome:<\/strong> Balanced settings that provide acceptable latency at lower cost.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Common Mistakes, Anti-patterns, and Troubleshooting<\/h2>\n\n\n\n<p>List of mistakes (Symptom -&gt; Root cause -&gt; Fix)<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Symptom: Chef runs succeed but config not applied. -&gt; Root cause: Attributes precedence causing wrong values. -&gt; Fix: Review attribute precedence and centralize overrides.<\/li>\n<li>Symptom: Frequent failed resources. -&gt; Root cause: Non-idempotent custom resources. -&gt; Fix: Refactor to idempotent operations and add guards.<\/li>\n<li>Symptom: Long chef runs. -&gt; Root cause: Heavy compile-phase tasks. -&gt; Fix: Move expensive operations to converge phase or bake images.<\/li>\n<li>Symptom: Secret exposure in logs. -&gt; Root cause: Plaintext secrets in templates. -&gt; Fix: Use encrypted data bags or external secrets.<\/li>\n<li>Symptom: Nodes not checking in. -&gt; Root cause: Expired client keys or firewall rules. -&gt; Fix: Rotate keys, validate network rules.<\/li>\n<li>Symptom: Partial apply after interruption. -&gt; Root cause: Interrupted runs without re-run. -&gt; Fix: Ensure retry policies and idempotence.<\/li>\n<li>Symptom: Chef Server overload. -&gt; Root cause: Many nodes checking in at same time. -&gt; Fix: Stagger run intervals and enable server HA.<\/li>\n<li>Symptom: Cookbook dependency errors. -&gt; Root cause: Unpinned cookbook versions. -&gt; Fix: Use Policyfiles and lock dependencies.<\/li>\n<li>Symptom: Audit failures after upgrade. -&gt; Root cause: Outdated InSpec profiles. -&gt; Fix: Update profiles and run in staging.<\/li>\n<li>Symptom: Missing platform support. -&gt; Root cause: Provider not implemented for OS. -&gt; Fix: Add or vendor platform-specific provider or skip.<\/li>\n<li>Symptom: Unexpected service restarts. -&gt; Root cause: Notifications triggered by templates for each run. -&gt; Fix: Use conditional notifications or checksum logic.<\/li>\n<li>Symptom: High alert noise. -&gt; Root cause: Alerts firing for known transient issues. -&gt; Fix: Tune thresholds and add suppression windows.<\/li>\n<li>Symptom: Chef changes blocked by CI. -&gt; Root cause: Slow tests. -&gt; Fix: Parallelize tests and use test doubles.<\/li>\n<li>Symptom: Drift continues after chef runs. -&gt; Root cause: Missing resource definitions for changed configs. -&gt; Fix: Add resources that assert desired state.<\/li>\n<li>Symptom: Unauthorized cookbook changes. -&gt; Root cause: Lack of RBAC over Chef server. -&gt; Fix: Enforce RBAC and code review workflows.<\/li>\n<li>Symptom: Chef run failing only occasionally. -&gt; Root cause: Race between services during startup. -&gt; Fix: Add service readiness checks and retries.<\/li>\n<li>Symptom: Large cookbook size causing slow upload. -&gt; Root cause: Including unrelated binaries. -&gt; Fix: Reduce cookbook artifacts and use artifacts repo.<\/li>\n<li>Symptom: Compliance false positives. -&gt; Root cause: Tests checking irrelevant flags. -&gt; Fix: Tweak InSpec controls for environment variance.<\/li>\n<li>Symptom: Resource ordering issues. -&gt; Root cause: Implicit dependencies not declared. -&gt; Fix: Use notifications and explicit requires.<\/li>\n<li>Symptom: Monitoring lacks context for failures. -&gt; Root cause: No structured Chef event emission. -&gt; Fix: Add handlers to emit structured events.<\/li>\n<li>Symptom: Chef client version drift. -&gt; Root cause: No standardization on Chef client versions. -&gt; Fix: Enforce client version via base image or lifecycle policy.<\/li>\n<li>Symptom: Secrets not rotated. -&gt; Root cause: No automated rotation integration. -&gt; Fix: Integrate Vault and automate rotation in cookbooks.<\/li>\n<li>Symptom: Observability blind spots. -&gt; Root cause: Only collecting metrics, not logs and traces. -&gt; Fix: Add log forwarding and tracing instrumentation.<\/li>\n<li>Symptom: Overloaded on-call due to Chef noise. -&gt; Root cause: Too many low-priority alerts. -&gt; Fix: Reclassify alerts and use noise reduction.<\/li>\n<\/ol>\n\n\n\n<p>Observability pitfalls (at least 5 included above):<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Not emitting structured Chef run events.<\/li>\n<li>Only collecting metrics without logs.<\/li>\n<li>Missing node attribute reporting in telemetry.<\/li>\n<li>No correlation between run ID and logs.<\/li>\n<li>Alerts tuned per node rather than per policy leading to duplication.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Best Practices &amp; Operating Model<\/h2>\n\n\n\n<p>Ownership and on-call:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform team owns Chef infrastructure and cookbooks.<\/li>\n<li>App teams own their recipe-level logic.<\/li>\n<li>On-call rota includes one platform engineer for Chef emergencies.<\/li>\n<\/ul>\n\n\n\n<p>Runbooks vs playbooks:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Runbooks: Step-by-step remediation for common failures.<\/li>\n<li>Playbooks: Higher-level sequences for larger scale operations.<\/li>\n<\/ul>\n\n\n\n<p>Safe deployments:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Canary cookbooks to a small node subset.<\/li>\n<li>Rollback by promoting previous policy in Policyfile or reverting in Git.<\/li>\n<li>Use staged promotion (dev -&gt; staging -&gt; prod).<\/li>\n<\/ul>\n\n\n\n<p>Toil reduction and automation:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Automate repetitive maintenance via scheduled runs and handlers.<\/li>\n<li>Bake common dependencies into images.<\/li>\n<li>Use policy-driven promotion to reduce manual steps.<\/li>\n<\/ul>\n\n\n\n<p>Security basics:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use encrypted data bags or external secret stores.<\/li>\n<li>Rotate client keys and Chef Server certificates.<\/li>\n<li>Enforce least privilege on Chef Server using RBAC.<\/li>\n<\/ul>\n\n\n\n<p>Weekly\/monthly routines:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Weekly: Review failed runs and drift events.<\/li>\n<li>Monthly: Update compliance profiles and test cookbook upgrades.<\/li>\n<li>Quarterly: Rotate keys and review access controls.<\/li>\n<\/ul>\n\n\n\n<p>What to review in postmortems related to Chef:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Recent cookbook changes and promotions.<\/li>\n<li>Run logs and resource failure counts.<\/li>\n<li>Time to detect and remediate configuration-related incidents.<\/li>\n<li>Gaps in testing and CI coverage.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Tooling &amp; Integration Map for Chef (TABLE REQUIRED)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Category<\/th>\n<th>What it does<\/th>\n<th>Key integrations<\/th>\n<th>Notes<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>I1<\/td>\n<td>Source Control<\/td>\n<td>Stores cookbooks and policies<\/td>\n<td>CI, Policyfiles, Git<\/td>\n<td>Use branch protection<\/td>\n<\/tr>\n<tr>\n<td>I2<\/td>\n<td>CI<\/td>\n<td>Tests and uploads cookbooks<\/td>\n<td>Test Kitchen, Berkshelf<\/td>\n<td>Gate uploads to server<\/td>\n<\/tr>\n<tr>\n<td>I3<\/td>\n<td>Image Builder<\/td>\n<td>Runs Chef during build<\/td>\n<td>Packer, AMI registries<\/td>\n<td>Bake immutable images<\/td>\n<\/tr>\n<tr>\n<td>I4<\/td>\n<td>Secret Store<\/td>\n<td>Secure secrets distribution<\/td>\n<td>Vault, Chef Vault<\/td>\n<td>Use short lived tokens<\/td>\n<\/tr>\n<tr>\n<td>I5<\/td>\n<td>Compliance<\/td>\n<td>Run InSpec profiles<\/td>\n<td>Chef Automate, CI<\/td>\n<td>Continuous compliance scanning<\/td>\n<\/tr>\n<tr>\n<td>I6<\/td>\n<td>Monitoring<\/td>\n<td>Collect Chef metrics<\/td>\n<td>Prometheus, Datadog<\/td>\n<td>Export chef-client metrics<\/td>\n<\/tr>\n<tr>\n<td>I7<\/td>\n<td>Logging<\/td>\n<td>Centralized chef logs<\/td>\n<td>ELK, Splunk<\/td>\n<td>Index run details<\/td>\n<\/tr>\n<tr>\n<td>I8<\/td>\n<td>Orchestration<\/td>\n<td>Provision infrastructure<\/td>\n<td>Terraform, Cloud APIs<\/td>\n<td>Use Chef for config not infra<\/td>\n<\/tr>\n<tr>\n<td>I9<\/td>\n<td>Artifact Repo<\/td>\n<td>Store packaged cookbooks<\/td>\n<td>Artifactory, S3<\/td>\n<td>Versioned artifacts<\/td>\n<\/tr>\n<tr>\n<td>I10<\/td>\n<td>Dashboard<\/td>\n<td>Visualize Chef health<\/td>\n<td>Grafana, Chef Automate<\/td>\n<td>Executive and debug views<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Frequently Asked Questions (FAQs)<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What is the difference between Chef Server and Chef Automate?<\/h3>\n\n\n\n<p>Chef Server stores cookbooks and node data; Chef Automate adds UI, reporting, and compliance workflows.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can Chef be used in immutable infrastructure workflows?<\/h3>\n\n\n\n<p>Yes, Chef is commonly run during image bake to produce immutable artifacts.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Is Chef agentless?<\/h3>\n\n\n\n<p>No, Chef typically uses a client agent that pulls policies; local mode is available for build-time runs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How does Chef handle secrets?<\/h3>\n\n\n\n<p>Use encrypted data bags, Chef Vault, or integrate with external secret stores like Vault.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When should I use Policyfiles?<\/h3>\n\n\n\n<p>Use Policyfiles to pin cookbook versions and make node convergence reproducible.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can Chef manage containers?<\/h3>\n\n\n\n<p>Chef is used to build container images and configure host OS but not ideal for per-pod runtime orchestration.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How do I test Chef cookbooks?<\/h3>\n\n\n\n<p>Use Test Kitchen, ChefSpec, and InSpec for unit, integration, and compliance testing.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What languages are used to write Chef cookbooks?<\/h3>\n\n\n\n<p>Cookbooks use Ruby DSL and ERB templates for configuration.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to prevent configuration drift?<\/h3>\n\n\n\n<p>Run chef-client regularly, enforce policies, and bake images for immutable workloads.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How do I secure Chef Server?<\/h3>\n\n\n\n<p>Enable TLS, enforce RBAC, rotate client keys, and audit uploads.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Does Chef support Windows?<\/h3>\n\n\n\n<p>Yes, Chef supports Windows via Windows-specific resources and providers.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When should I prefer Ansible over Chef?<\/h3>\n\n\n\n<p>Choose Ansible for agentless push models and simpler ad-hoc tasks; prefer Chef for long-lived node convergence.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to monitor Chef at scale?<\/h3>\n\n\n\n<p>Export Chef run metrics to Prometheus or monitoring service and aggregate reports in Chef Automate.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What is Chef Habitat?<\/h3>\n\n\n\n<p>Separate project focused on application lifecycle and packaging, different from core Chef config management.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can Chef handle compliance auditing?<\/h3>\n\n\n\n<p>Yes, InSpec profiles integrated via Chef Automate offer audit capabilities.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How do I rollback cookbook changes?<\/h3>\n\n\n\n<p>Rollback via policy promotion to a previous locked Policyfile or revert in Git and republish.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Is Chef suitable for serverless?<\/h3>\n\n\n\n<p>Use Chef at build time in CI; not typically for runtime serverless config.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to scale Chef Server?<\/h3>\n\n\n\n<p>Use high-availability deployment options and stagger node check-in intervals.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Conclusion<\/h2>\n\n\n\n<p>Chef remains a powerful tool for configuration management, compliance, and image baking in environments with long-lived infrastructure. It fits well into modern cloud-native ecosystems when used to manage OS and build-time configuration while integrating with CI, secret stores, and monitoring.<\/p>\n\n\n\n<p>Next 7 days plan:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Day 1: Inventory nodes and define supported OS list.<\/li>\n<li>Day 2: Create or import cookbooks and add linting.<\/li>\n<li>Day 3: Set up CI to run Test Kitchen and ChefSpec.<\/li>\n<li>Day 4: Integrate secret management and encrypt data bags.<\/li>\n<li>Day 5: Publish a policy to a staging policy group and run canary.<\/li>\n<li>Day 6: Configure monitoring and dashboards for Chef metrics.<\/li>\n<li>Day 7: Run a game day to simulate Chef Server outage and recovery.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Appendix \u2014 Chef Keyword Cluster (SEO)<\/h2>\n\n\n\n<p>Primary keywords<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Chef<\/li>\n<li>Chef automation<\/li>\n<li>Chef cookbooks<\/li>\n<li>Chef recipes<\/li>\n<li>Chef configuration management<\/li>\n<li>Chef infrastructure as code<\/li>\n<li>Chef Automate<\/li>\n<li>Chef Server<\/li>\n<li>Chef client<\/li>\n<li>Policyfile<\/li>\n<\/ul>\n\n\n\n<p>Secondary keywords<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Chef InSpec<\/li>\n<li>Chef Habitat<\/li>\n<li>ChefDK<\/li>\n<li>Test Kitchen<\/li>\n<li>Knife CLI<\/li>\n<li>Encrypted data bags<\/li>\n<li>Chef policy groups<\/li>\n<li>Ohai system<\/li>\n<li>Cookbook testing<\/li>\n<li>Cookstyle lint<\/li>\n<\/ul>\n\n\n\n<p>Long-tail questions<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What is Chef in DevOps<\/li>\n<li>How does Chef differ from Ansible<\/li>\n<li>How to write a Chef cookbook<\/li>\n<li>How to use Policyfiles in Chef<\/li>\n<li>How Chef Automate works<\/li>\n<li>How to bake AMIs with Chef<\/li>\n<li>How to manage secrets with Chef Vault<\/li>\n<li>How to test Chef cookbooks with Test Kitchen<\/li>\n<li>How to monitor Chef runs with Prometheus<\/li>\n<li>How to implement compliance with InSpec<\/li>\n<\/ul>\n\n\n\n<p>Related terminology<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Infrastructure as code<\/li>\n<li>Configuration drift<\/li>\n<li>Idempotence<\/li>\n<li>Converge<\/li>\n<li>Run-list<\/li>\n<li>Resource provider<\/li>\n<li>Attribute precedence<\/li>\n<li>Client key rotation<\/li>\n<li>Immutable infrastructure<\/li>\n<li>Bootstrap process<\/li>\n<\/ul>\n\n\n\n<p>Additional phrases<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Chef best practices<\/li>\n<li>Chef deployment strategy<\/li>\n<li>Chef run duration<\/li>\n<li>Chef compliance scanning<\/li>\n<li>Chef automation pipeline<\/li>\n<li>Chef cookbook versioning<\/li>\n<li>Policyfile promotion<\/li>\n<li>Chef node attributes<\/li>\n<li>Chef server HA<\/li>\n<li>Chef troubleshooting<\/li>\n<\/ul>\n\n\n\n<p>Operational keywords<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Chef run success rate<\/li>\n<li>Chef failed resources<\/li>\n<li>Chef drift detection<\/li>\n<li>Chef secret management<\/li>\n<li>Chef logging and monitoring<\/li>\n<li>Chef automation runbooks<\/li>\n<li>Chef incident response<\/li>\n<li>Chef CI integration<\/li>\n<li>Chef image baking<\/li>\n<li>Chef scalability<\/li>\n<\/ul>\n\n\n\n<p>Audience-focused keywords<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Chef for SRE<\/li>\n<li>Chef for DevOps teams<\/li>\n<li>Chef for enterprise<\/li>\n<li>Chef for compliance teams<\/li>\n<li>Chef for cloud-native<\/li>\n<li>Chef for Kubernetes nodes<\/li>\n<li>Chef for Windows<\/li>\n<li>Chef for Linux<\/li>\n<li>Chef for hybrid cloud<\/li>\n<li>Chef for immutable infrastructure<\/li>\n<\/ul>\n\n\n\n<p>Technical phrases<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Chef DSL Ruby<\/li>\n<li>Chef resource notification<\/li>\n<li>Chef attribute precedence<\/li>\n<li>Chef encrypted data bag usage<\/li>\n<li>Chef Policyfile lock<\/li>\n<li>Chef Test Kitchen suites<\/li>\n<li>Chef InSpec controls<\/li>\n<li>Chef Automate reporting<\/li>\n<li>Chef knife bootstrap<\/li>\n<li>Chef cookbook dependencies<\/li>\n<\/ul>\n\n\n\n<p>Search intent phrases<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>How to configure servers with Chef<\/li>\n<li>Best Chef cookbooks for security<\/li>\n<li>Chef automation tutorial<\/li>\n<li>Chef versus Puppet comparison<\/li>\n<li>How to audit with Chef InSpec<\/li>\n<li>Chef cookbook example for nginx<\/li>\n<li>Chef cookbook for system hardening<\/li>\n<li>Chef tutorial for beginners<\/li>\n<li>Chef implementation guide<\/li>\n<li>Chef troubleshooting guide<\/li>\n<\/ul>\n\n\n\n<p>Questions for discovery<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Can Chef manage containers<\/li>\n<li>When to use Chef over Terraform<\/li>\n<li>How to secure Chef Server<\/li>\n<li>How to rotate Chef client keys<\/li>\n<li>How to automate cookbook promotion<\/li>\n<li>How to integrate Chef with Vault<\/li>\n<li>How to test Chef changes safely<\/li>\n<li>How to monitor Chef Automate<\/li>\n<li>How to scale Chef Server<\/li>\n<li>How to bake images with Chef<\/li>\n<\/ul>\n\n\n\n<p>Developer-focused phrases<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Writing custom Chef resources<\/li>\n<li>Testing Chef libraries<\/li>\n<li>Managing attributes with Chef<\/li>\n<li>Chef cookbook structure<\/li>\n<li>Versioning cookbooks with Policyfile<\/li>\n<li>Linting Chef code with Cookstyle<\/li>\n<li>Using Berkshelf in Chef<\/li>\n<li>Chef cookbook unit tests<\/li>\n<li>Chef cookbook integration tests<\/li>\n<li>Chef automation CI best practices<\/li>\n<\/ul>\n\n\n\n<p>Compliance-focused phrases<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Chef InSpec profiles examples<\/li>\n<li>Chef audit automation<\/li>\n<li>Chef compliance reporting<\/li>\n<li>Automating PCI compliance with Chef<\/li>\n<li>SOC2 compliance and Chef<\/li>\n<li>Chef Automate compliance dashboard<\/li>\n<li>Writing InSpec controls<\/li>\n<li>Running compliance at scale<\/li>\n<li>Compliance drift detection Chef<\/li>\n<li>Regulatory audit with Chef<\/li>\n<\/ul>\n\n\n\n<p>Security terms<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Encrypted data bag best practices<\/li>\n<li>Chef Vault usage guide<\/li>\n<li>Securing Chef client keys<\/li>\n<li>TLS for Chef Server<\/li>\n<li>RBAC in Chef Server<\/li>\n<li>Secret rotation in Chef<\/li>\n<li>Least privilege in Chef<\/li>\n<li>Hardening cookbooks<\/li>\n<li>Audit trails in Chef Automate<\/li>\n<li>Remediating vulnerabilities with Chef<\/li>\n<\/ul>\n\n\n\n<p>Cloud and platform terms<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Chef on AWS<\/li>\n<li>Chef on Azure<\/li>\n<li>Chef on GCP<\/li>\n<li>Chef with Kubernetes nodes<\/li>\n<li>Chef in hybrid cloud<\/li>\n<li>Chef for bare metal<\/li>\n<li>Chef for OpenStack<\/li>\n<li>Chef in CI pipelines<\/li>\n<li>Chef and Packer integration<\/li>\n<li>Chef for image baking<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>&#8212;<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-1087","post","type-post","status-publish","format-standard","hentry"],"_links":{"self":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts\/1087","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/comments?post=1087"}],"version-history":[{"count":0,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts\/1087\/revisions"}],"wp:attachment":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/media?parent=1087"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/categories?post=1087"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/tags?post=1087"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}