Configuration Management: When to Move to Ansible or Puppet

Why scripts alone become insufficient

When you have few servers that are similar, bash scripts and manual edits feel fast and simple. Over time, scripts grow, exceptions appear, and no one is sure what a given file actually does. New team members fear touching old snippets: they perform sequences of actions rather than describing the desired state, often without checking results.

Usually everything relies on habits: "SSH in and fix it," "run the script from the ops folder," "Peti has the current version on his laptop." This is when the infrastructure begins to drift. Configuration drift happens quietly: one server was updated by hand, another was forgotten; someone temporarily stopped a service and never restored it; a config line was added "for the incident" and stayed for months.

Non-repeatability becomes a major source of errors. The same script can behave differently due to package versions, execution order, missing dependencies, or remnants of past manual changes on a server. The more systems there are, the more often you hear "it works for me": people compare different environments.

Early symptoms are usually the same: small changes cause outages, servers with the same role diverge in package and config versions, rollbacks turn into detective work, incident recovery drags on, and teams argue about who changed what.

This hits hardest those who work at the boundaries. Admins get on-call nights and endless requests to "tweak one host." Security loses control: it’s hard to prove that accesses and policies are consistent, and changes are approved. The service desk can’t reproduce fixes consistently because knowledge lives in a single person’s memory.

A typical scenario: you have 20 application servers. On Friday someone fixed a problem by adding a parameter to a config on one node. On Monday that node was replaced after a failure and brought up "as usual" with an old script, so the parameter disappeared. The bug returns and the hunt begins to find who and when changed it. In moments like that it becomes clear: it’s time to move from disparate actions to desired-state management and the discipline provided by configuration management.

What desired-state management and change auditing give you

The main difference between a set of scripts and a managed approach is that you describe not "what to do right now" but "how it should always be." For example: the required package is installed, the service is running, the config is at the correct version, file permissions are correct. That is desired-state management: the system brings the server to the required state even if someone changed something manually.

Scripts often act as one-off tasks. If you run them again the result may be unpredictable: some things are already configured, some are partially changed, and other machines may have different versions. In configuration management idempotence matters: you apply the same set of rules repeatedly and the system changes only what differs from the desired state. This reduces the risk of breaking a node by re-running tasks and simplifies bulk changes.

Another advantage is separation of data and logic. Logic describes general rules (web-server role, database role, password policy), while data is stored separately: variables for different environments, host lists, parameters for specific departments. This makes supporting multiple environments (test, pilot, prod) easier without copying code and duplicating nearly identical files.

Change auditing turns "someone once edited by hand" into a clear history. In a healthy process you should be able to answer: who initiated the change and with what rights, what exactly changed (parameters, files, versions), when it was applied, where (which servers or groups), and what the run result was.

When a service fails at night and the team argues about what happened last, an audit removes guessing. Instead of manually comparing configs you open the run history and see who applied a role, which hosts were affected, which template was updated and at what step errors started. This saves hours during incidents and helps build access control not by forbidding everyone, but by rules that say "who can change what and through which process."

When it’s time to adopt configuration management

Disparate scripts work while the infrastructure is small and changes are rare. But as soon as you have more servers and services than you can confidently hold in your head, the familiar signs appear: different config versions, minute-by-minute manual edits, and long investigations into "why it worked yesterday."

The clearest indicator is that you increasingly spend time restoring uniform state instead of making improvements. At that point, configuration management is not a trendy practice but a way to regain predictability.

Practical signals that it’s time

The transition usually pays off quickly if several of these apply:

• you already have dozens (or hundreds) of servers and manual checks become endless lists;
• changes occur often: patches, updates, new accounts, key rotation, security policy edits;
• you have compliance requirements: you must prove what changed, by whom and when, and be able to reproduce a configuration on a new server;
• you depend on one script author or a "lead admin" who knows all the nuances;
• the infrastructure is distributed: branches, separate data centers, cloud, test stands, and the same behavior is needed everywhere.

Important: it’s not only about machine count. Even 15–20 servers become painful if they are different types (apps, databases, terminals, monitoring) and require varied access and update policies.

A scenario that quickly exposes the problem

An organization with a head office and several sites. A critical patch goes out overnight; in the morning security asks for a report: which nodes were updated, who ran the work, where were deviations. The team hunts for logs in chats, tries to remember which script was "current," and manually compares package versions.

Configuration management changes this approach: you declare the desired state, apply it uniformly across sites, and get a history of changes. Updates and access controls become reproducible even if team members change.

Ansible Automation Platform, Puppet and SaltStack: how to choose

Choosing a tool usually comes down to what matters most for you: quick start and convenience, strict policy enforcement, or fast reaction in a hybrid environment. And one more question: what the team can realistically maintain daily.

Ansible Automation Platform: when simplicity and quick start matter

Ansible is often chosen to replace fragmented scripts with clear playbooks without installing agents on every server. It’s convenient for common tasks: updates, user management, application deployments, and fact gathering.

Problems arise when playbooks are treated like "scripts 2.0": exceptions and conditional branches grow and become hard to test and maintain. Agree early on rules: role structure, mandatory checks, and a consistent variable style.

Puppet: when policies and long-lived configurations are critical

Puppet is commonly used where a declarative model and continuous enforcement of state are required. It fits servers and roles that live for years and must comply with standards without manual workarounds.

The trade-off is a higher entry barrier and the need for discipline. You manage the model of desired state and policies rather than task execution.

SaltStack: when speed and event-driven actions matter

SaltStack is chosen when execution speed and event-driven operations matter: reacting to environment changes, managing mixed infrastructures, and performing fast operations across many nodes. It’s useful for hybrid scenarios where resources live in different domains but need unified control.

Before choosing, answer practical questions:

• what’s more important: ease of adoption or strict policy control?;
• do you need regular drift detection and automatic remediation?;
• how will you audit changes: who changed what and by what request?;
• are there isolation and access requirements (especially in public sector and finance)?;
• what skills does your team already have, and who will maintain the solution in a year?

A common approach: start with Ansible to quickly standardize basic settings, then tighten controls where auditing and compliance matter more than speed. If your infrastructure runs on-prem and you support it 24/7, build processes from the start: who approves changes, how they land in the repository, and how you prove configuration compliance.

Step-by-step plan to move from scripts to desired state

Transitions usually fail not because of the tool choice but because of missing a clear sequence. Short, verifiable steps show benefits quickly and reduce risk to production.

Start with an inventory. Collect a list of servers and services: where they are (data center, branch, cloud), OSes and versions, access methods, owners (team or person), and which scripts are actually used. Often half of automation lives on personal laptops or in scattered folders — record that honestly.

Next, define a minimal "golden standard" for all nodes. Keep it small but meaningful: consistent users and keys, basic SSH config, time sync, logging and log forwarding. Better to have 4–5 verifiable rules than to attempt everything at once.

To reduce risk, pick a pilot group of 10–30 nodes and avoid the most critical systems. A good pilot is typical servers that often get manual fixes: test environments, auxiliary services, or parts of office infrastructure.

Then describe the state as code. In different systems these will be roles and playbooks, modules and manifests, or states, but the idea is the same: define the desired state, not a sequence of manual commands.

A practical sequence:

• record inventory and owners, agree on the single source of truth;
• describe the golden standard as roles or modules;
• create a repository and review rules: who can change, who approves, how releases are tracked;
• run the first pass in report/dry-run/compile/check mode and analyze discrepancies;
• only then apply changes to the pilot and measure the effect.

The "report only" phase is easy to skip, but it’s valuable. For example, you may assume NTP is configured everywhere, but a report reveals different time sources causing clock drift. That’s not a reason to immediately Apply — it’s a signal to align settings with service owners first.

When the pilot is stable, expand in waves: by environment (dev, test, prod), by node type or by branch. Desired-state management becomes a team habit and changes stop being surprises.

How to organize change audit and access control

Audit starts not with logs, but with a rule: any infrastructure change must be a code change. Even a single parameter should follow the same path as regular code edits. Then configuration management becomes verifiable and repeatable.

The most straightforward team practice is working via merge/pull requests. In the request record not only what changed but why: link to the task or incident, a short risk assessment and rollback plan, who reviewed the change, which environments are affected, and the result of test runs.

Next, separate environments and agree on promotion rules. For example: dev can be applied frequently, stage only from the main branch, and prod only after approval by the responsible person and during an agreed window. This prevents a "temporary" fix from accidentally reaching production.

Execution logs must quickly answer three questions: who ran it, what was applied, and what changed. Store logs centrally and consistently across sites. Agree in advance on retention periods and how to search by host, task and time.

Build access control around roles: who can edit code, who can run applies, who can approve. For production use approvals and a "two pairs of eyes" rule. Define a break-glass access separately — time-limited, with a required reason and post-incident review.

For regular oversight produce simple reports weekly: where drift exists, which runs failed and why, where manual interventions occurred, and which changes carry elevated risk (accounts, networks, accesses).

Common mistakes and pitfalls during adoption

The main adoption problem is not the tool but team habits. When people move from scattered scripts and manual edits to configuration management they often replicate the same style, producing chaos at a new level.

A frequent mistake is trying to automate everything at once: servers, networks, databases, monitoring, access policies and a few "quick wins." Then it’s hard to identify what broke, where the single source of truth is, and how to roll back.

Typical pitfalls:

• no pilot or too broad a pilot, so first failures look like the whole idea failed;
• manual edits continue without process, so actual state drifts from code;
• secrets (passwords, tokens, keys) end up in the repo or plain variables;
• no standards for structure and naming, so after a month no one knows where things are;
• changes applied without checks: no dry-run, no validation, no tests on a staging environment.

Exceptions are especially dangerous. In real infrastructures they are inevitable: a service temporarily disabled on one node, a manual hotfix "until tomorrow," a non-standard package installed for one department. If such deviations are not formalized and time-limited they become permanent and undermine trust in desired-state management.

Agreeing on simple rules helps:

• manual edits are forbidden or allowed only through a clear process (request, reason, expiry, responsible person);
• all secrets are stored in a secured vault, not in code;
• mandatory checks and a rollback plan before apply;
• a single agreed structure and naming convention used by everyone.

A typical example: an admin "quickly" edits configs on two servers to close an incident. A week later automation reapplies the template and overwrites the change, the incident repeats and the team argues. The cure is not a new module but discipline: ban quiet changes, document exceptions and always run checks before applying.

Quick readiness checklist for team and infrastructure

If you’re unsure whether you’re ready for Ansible, Puppet or SaltStack, check processes rather than tools. Configuration management pays off where desired state can be described and applied with discipline.

If you answer "no" or "sometimes" to a point, treat it as a preparation priority rather than a blocker:

• Unified source of truth for configurations. Do you have a place for current configuration: OS parameters, packages, service settings, templates? If part lives in chat, part in personal notes and part in scripts on different servers, start with inventory.
• Repeatable deployment. Can you bring up a new server to standard in hours, not days? A reproducible result without guesswork is essential.
• Change log and run results. Can you see who ran changes, what was applied and how the run ended (success, failure, what changed)? This is the basis for investigations and calm on-call shifts.
• Drift control and regular reconciliation. Do you check that servers don’t drift from the standard over time?
• Rollback and second-person clarity. How quickly can you revert after a bad change, and can another engineer follow the procedure without guidance?

A practical test: take a typical service (e.g., an internal portal web server) and ask two different people to prepare an identical machine from scratch. If results differ and times vary widely, it’s time to formalize standards and move them into desired-state code.

A simple real-world example

An organization with two sites (main and backup), about 150 servers and different teams: day shift, night shift and contractors for some systems. Historically everything is driven by scripts: some bash, some PowerShell, and manual edits when things "catch fire."

After a critical incident some servers get SSH settings changed (allowed algorithms and access parameters), and others get logging and rotation rules adjusted. A week later an audit shows that similarly purposed servers behave differently: logs aren’t collected consistently, and SSH access differs from policy.

The issue is rarely people, but the lack of a single standard and clear change history. The team moves from scattered scripts to desired-state management: a basic configuration is described as rules, identical for all servers with a given role. At the same time audit is enabled: who changed what, when and why.

Pilots usually start not with the most critical systems but with auxiliary services (jump-host, logging service, test stands). Then production roles are added gradually.

Steps look like this:

• define a base server profile: SSH, time, logging, users, monitoring agents;
• put configurations under version control and agree change rules (request, review, comment);
• separate rights: who can apply changes and who can only view;
• run a pilot on 10–20 servers and compare actual settings to the standard;
• after stabilization roll out to other roles.

Within 1–2 months measurable results appear: fewer incidents due to config differences, faster onboarding of new servers, and simpler incident analysis thanks to change logs. Configuration management becomes insurance: emergency fixes are possible but don’t dissolve into chaos and are returned to a verifiable standard.

Next steps: pilot, scaling and support

Start with a short pilot rather than trying to describe the entire infrastructure. Choose a small but representative domain: 10–30 servers of one type or one service with clear owners and a release schedule.

First, fix 3–5 standards that deliver quick wins and are commonly broken by manual changes: accounts and groups, basic updates, consistent logging and rotation, time sync, basic DNS/network settings, and mandatory monitoring or EDR agents if used.

Then pick the tool to fit your context, not someone else’s rankings. If the team already works with YAML and Git workflows, Ansible Automation Platform is an easy start. If you need a stricter declarative model, consider Puppet or SaltStack. Ensure the chosen path is supported by the people who will be on-call in six months.

Treat the pilot as a project with success criteria understandable to business and operations: time to bring a server to standard, number of policy deviations before and after, share of changes with transparent history (who, when, why), and recovery speed after failures.

If the pilot succeeds, plan for growth: management servers, code and role repositories, secrets storage, backups, and access rules (who changes code, who runs applies, who approves changes). At scale the challenge is not "one more playbook" but discipline: branches, reviews, run schedules and maintenance windows.

When time or experience is insufficient, engage a system integrator to survey current practices, set up the pilot, train and hand over to operations. In Kazakhstan this is often combined with infrastructure refresh: for example, GSE.kz as a manufacturer and system integrator can supply servers and workstations for the management domain, assist with integration and provide support so the solution remains stable after the pilot.