Kingsfordweg 151, 1043GR Amsterdam, The Netherlands ● 24/7 support — support@novogara.com
Knowledge base

Configuration management

The question is not whether you will rebuild this machine. It is whether you will be able to.

Why bother

A server configured by hand is a document nobody wrote. Six months later nobody remembers why that sysctl is set, and rebuilding after a failure means archaeology.

With configuration in a repository you get a rebuild that takes minutes, a diff for every change, a review before it happens, and identical staging and production. That last one removes a whole category of “works on staging”.

Ansible, for most people

Agentless — it works over SSH, so there is nothing to install on the target. YAML, which is readable by people who do not write Ansible daily. That combination is why it wins for small estates.

Puppet and Chef are more powerful and need an agent and more investment. Salt sits in between. If you have no strong reason, Ansible.

The shape of a repository

An inventory listing your machines by group, roles for each concern (base, nginx, postgres), group variables for per-environment settings, and playbooks that apply roles to groups.

Start with a base role that every machine gets: users and sudo, SSH hardening, the firewall, NTP, automatic updates, monitoring agents. That alone makes a new server a ten-minute job.

Idempotence is the whole point

Running it twice must change nothing the second time. That means using modules rather than shell commands:

  • ansible.builtin.lineinfile or template, not sed -i
  • ansible.builtin.service, not systemctl start
  • Where you must shell out, give it creates: or changed_when: so it reports honestly

Then --check --diff becomes a trustworthy preview of what a run would do, and that is what makes it safe to run against production.

Secrets

Never in plain YAML in the repository. ansible-vault encrypts variables in place and is adequate for most teams; a dedicated secret store is better at scale. See managing secrets.

Habits that keep it honest

  • Run it regularly, not only when you change something. A repository that has drifted from reality for three months is fiction.
  • Target a group, not all, and use --limit while you are developing a role.
  • Test on a staging machine first. See staging and test servers.
  • Serialise rollouts with serial: 1 so a bad change hits one machine rather than all of them.
  • Keep it boring. Clever Ansible is unreadable Ansible.

With our API

Provisioning and configuration fit together: our API creates and reinstalls machines, Ansible configures them once they boot. For resellers that is the whole pipeline — an order becomes a running, configured server without anyone touching a console.


Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base