{"id":215,"date":"2026-10-12T22:41:00","date_gmt":"2026-10-12T22:41:00","guid":{"rendered":"http:\/\/www.scmgalaxy.com\/tutorials\/2010\/03\/21\/power-point-ppt-configuration-management\/"},"modified":"2026-10-12T22:41:00","modified_gmt":"2026-10-12T22:41:00","slug":"power-point-ppt-configuration-management","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/power-point-ppt-configuration-management\/","title":{"rendered":"Configuration Management in DevOps: Workflow, Tool Comparison, and an Ansible Example"},"content":{"rendered":"\n

Originally published on 2010-03-21; fully revised and updated.<\/em><\/p>\n\n\n\n

Configuration management is the practice of defining and enforcing system configuration as code so environments stay consistent over time. This rewrite is aimed at DevOps engineers and platform teams who need repeatable deployments, reduced drift, and safer change control across development, staging, and production.<\/p>\n\n\n\n

The original post was a short SlideShare embed. This updated version provides a complete, practical reference you can use directly.<\/p>\n\n\n\n

Original embedded slide deck (archival)<\/h2>\n\n\n\n

Original permalink: https:\/\/www.devopsschool.com\/blog\/power-point-ppt-configuration-management\/<\/a><\/p>\n\n\n\n

{slideshare}[slideshare id=1117749&doc=configurationmanagement-090308134227-phpapp02]{\/slideshare}<\/p>\n\n\n\n

What configuration management solves<\/h2>\n\n\n\n

Without configuration management, servers and clusters tend to diverge over time: package versions drift, manual fixes are forgotten, and incidents become harder to reproduce. With configuration managed as code, teams can track changes, review them, and apply them consistently.<\/p>\n\n\n\n

  • Consistency:<\/strong> same desired state across environments.<\/li>
  • Auditability:<\/strong> configuration changes are tracked in version control.<\/li>
  • Repeatability:<\/strong> rebuilding or scaling infrastructure is predictable.<\/li>
  • Drift control:<\/strong> unauthorized or accidental changes are easier to detect and correct.<\/li>
  • Safer operations:<\/strong> dry runs, peer review, and staged rollout reduce change risk.<\/li><\/ul>\n\n\n\n

    End-to-end workflow in a DevOps pipeline<\/h2>\n\n\n\n

    A robust workflow treats configuration exactly like application code: author, review, validate, stage, deploy, and continuously check for drift.<\/p>\n\n\n\n

    \nflowchart TD\n    A[Define desired state as code] --> B[Commit to Git]\n    B --> C[CI validates syntax and policy]\n    C --> D[Review and approve]\n    D --> E[Apply in staging]\n    E --> F[Run service checks]\n    F --> G{Promote to production}\n    G -- no --> A\n    G -- yes --> H[Apply in production]\n    H --> I[Detect drift and open fix change]\n    I --> A\n<\/pre>\n\n\n\n
    Approaches and tools compared<\/h2>\n\n\n\n
    Different tools can achieve configuration management, but they differ in operating model, complexity, and fit for scale.<\/p>\n\n\n\n
    Option<\/th>Model<\/th>Best for<\/th>Trade-offs<\/th><\/tr><\/thead>
    Manual shell scripts<\/td>Imperative commands executed directly on hosts<\/td>Small, one-off tasks<\/td>Hard to keep idempotent; drift grows quickly<\/td><\/tr>
    Ansible<\/td>Agentless automation (commonly over SSH\/WinRM) with YAML playbooks<\/td>Teams that want quick adoption and readable automation<\/td>Controller design and inventory strategy matter at larger scale<\/td><\/tr>
    Puppet<\/td>Declarative desired state with agent-based enforcement<\/td>Large fleets needing continuous state enforcement<\/td>Agent and control-plane lifecycle adds operational overhead<\/td><\/tr>
    Chef<\/td>Code-driven automation with Ruby DSL, typically agent-based<\/td>Complex automation patterns and strong code customization<\/td>Steeper learning curve for teams unfamiliar with Ruby DSL<\/td><\/tr>
    Salt<\/td>Remote execution plus state management, event-driven capabilities<\/td>Teams needing both orchestration and configuration control<\/td>Architecture choices can increase design complexity<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Hands-on example: baseline web server configuration with Ansible<\/h2>\n\n\n\n
    This example installs and enables NGINX on a target host group named web<\/strong>. It demonstrates idempotent configuration management with a dry-run step before enforcement.<\/p>\n\n\n\n
    Inventory file<\/h3>\n\n\n
    [web]\nweb-01 ansible_host=192.0.2.10 ansible_user=ubuntu\nweb-02 ansible_host=192.0.2.11 ansible_user=ubuntu<\/code><\/span><\/pre>\n\n\n
    Playbook<\/h3>\n\n\n
    ---<\/span>\n-<\/span> name<\/span>: Configure<\/span> web<\/span> servers<\/span>\n  hosts<\/span>: web<\/span>\n  become<\/span>: true<\/span>\n  tasks<\/span>:\n    -<\/span> name<\/span>: Ensure<\/span> nginx<\/span> is<\/span> installed<\/span>\n      ansible<\/span>.builtin<\/span>.package<\/span>:\n        name<\/span>: nginx<\/span>\n        state<\/span>: present<\/span>\n\n    -<\/span> name<\/span>: Ensure<\/span> nginx<\/span> service<\/span> is<\/span> enabled<\/span> and<\/span> running<\/span>\n      ansible<\/span>.builtin<\/span>.service<\/span>:\n        name<\/span>: nginx<\/span>\n        enabled<\/span>: true<\/span>\n        state<\/span>: started<\/span><\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
    Validate first, then apply<\/h3>\n\n\n
    ansible-playbook<\/span> -i<\/span> inventory<\/span>.ini<\/span> web<\/span>.yml<\/span> --syntax-check<\/span>\nansible-playbook<\/span> -i<\/span> inventory<\/span>.ini<\/span> web<\/span>.yml<\/span> --check<\/span> --diff<\/span>\nansible-playbook<\/span> -i<\/span> inventory<\/span>.ini<\/span> web<\/span>.yml<\/span><\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
    Minimal CI validation stage<\/h3>\n\n\n
    stages<\/span>:\n  -<\/span> validate<\/span>\n\nvalidate_config<\/span>:\n  stage<\/span>: validate<\/span>\n  script<\/span>:\n    -<\/span> ansible-playbook<\/span> -i<\/span> inventory<\/span>.ini<\/span> web<\/span>.yml<\/span> --syntax-check<\/span>\n    -<\/span> ansible-playbook<\/span> -i<\/span> inventory<\/span>.ini<\/span> web<\/span>.yml<\/span> --check<\/span><\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
    Common pitfalls and best practices<\/h2>\n\n\n\n
    • Pitfall:<\/strong> making emergency manual server edits and never backporting them. Best practice:<\/strong> every change goes through version control and pull request review.<\/li>
    • Pitfall:<\/strong> applying directly to production first. Best practice:<\/strong> validate in CI, then stage, then promote.<\/li>
    • Pitfall:<\/strong> treating configuration tools as ad-hoc scripting engines. Best practice:<\/strong> prefer idempotent resources and declarative patterns where possible.<\/li>
    • Pitfall:<\/strong> weak inventory and host-group design. Best practice:<\/strong> model environments and roles explicitly to prevent accidental broad changes.<\/li>
    • Pitfall:<\/strong> no drift checks after deployment. Best practice:<\/strong> schedule regular compliance runs and open fix changes automatically.<\/li><\/ul>\n","protected":false},"excerpt":{"rendered":"
      This guide explains configuration management for DevOps teams: what it solves, how it fits into delivery workflows, and how major tool options compare. It also includes a practical Ansible example you can adapt for real environments.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[2],"tags":[],"class_list":["post-215","post","type-post","status-publish","format-standard","hentry","category-uncategorised"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/215","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=215"}],"version-history":[{"count":2,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/215\/revisions"}],"predecessor-version":[{"id":79053,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/215\/revisions\/79053"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=215"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=215"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=215"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}