<p>You hint in the title about immutable infrastructure, so it sounds like you already know the solution:  don't change existing servers, but bring up new ones with your changes, switch over to them, and switch back to the old ones if necessary.</p>

<p>Theoretically any of the standard config management tools can roll back by simply checking out a previous commit and rerunning the config.  However, practically speaking this often isn't the case, as you may have introduced a new config rule (and so whatever it is doing is simply ignored in older versions) or you've written a rule that isn't easily reversible (for instance, does some destructive data operation).  If you were <strong>very</strong> careful in how you always write your playbooks, you could avoid this, but a few less error-prone solution is just to use an immutable infrastructure approach.</p>

CC BY-SA 4.0
2019-05-31T15:55:29.513Z
There is a vast difference between 'rollback' and 'restore n-1 version'. In theory there should be a way to rollback and rollforward however most tools simply do not have the smarts to implement it. Restoring to N-1 is only one step above manually making changes directly on a server. An Ansible instructor at a course went so far as to say that it 'can't be done' with Ansible.
Underverse
CC BY-SA 4.0
2019-06-17T20:04:00.510Z
@Underverse I don't understand the distinction you're trying to make. Can you clarify your terminology?
Xiong Chiamiov
CC BY-SA 4.0
2019-06-18T13:35:32.507Z
'Rollback' as in keeping a snapshot copy of the state of the files of a target environment before copying in a new version, so that the original state can be restored at will. Note that an exact copy of the files is kept temporarily to allow this. To 'restore n-1 version' means to go into the source repository, and deploying these files in to the target environment. Rollback is immediate as it is an exact copy. A 'rollback' reverses all actions to the target environment. The n-1 restore can be used to manually roll back previous files. In theory Ansible playbooks could do this.
Underverse
CC BY-SA 4.0
2019-06-18T13:40:49.933Z
@XiongChiamov For further clarification, I asked an Ansible expert from Redhat how he would 'rollback a change made by an Ansible playbook' and subsequently restore the last known good state (rollforward). His answer was similar to yours: Add a new version to Git, use Ansible to deploy that version, then retrieve the n-1 version from Git and deploy that (to effect rollback). For 'rollforward' he would get the N (latest) version from Git and deploy it.True rollback would snapshot the target environment state, and be able to restore it.
Underverse
CC BY-SA 4.0
2019-04-29T17:58:32.867Z
2019-04-29T17:58:32.867Z
Xiong Chiamiov
<p>I am interested in whether there are any configuration management tools out there that make it easy to roll back.</p>

<p>So far it seems that with Ansible, Chef, and Puppet you have to write the roll back tasks/recipes/whatever to get back to your previous state.</p>

<p>Coming from a bit of personal interest and experience with NixOS I have seen that with pure Immutable Infrastructure rollback is easy.</p>

<p>I am in Enterprise environments where NixOS is not happening. How can Enterprises begin to approach Rollbacks better with tools that work with Windows and Enterprise Linux Distros?</p>

<ansible><infrastructure-as-code><immutable-servers><nixos>
Configuration Management Tools and Rollbacks / Approaching Immutable Infrastructure
David West
# Configuration Management Tools and Rollbacks / Approaching Immutable Infrastructure

(Asked by: username_0 on 2019-04-29)

I am interested in whether there are any configuration management tools out there that make it easy to roll back.

So far it seems that with Ansible, Chef, and Puppet you have to write the roll back tasks/recipes/whatever to get back to your previous state.

Coming from a bit of personal interest and experience with NixOS I have seen that with pure Immutable Infrastructure rollback is easy.

I am in Enterprise environments where NixOS is not happening. How can Enterprises begin to approach Rollbacks better with tools that work with Windows and Enterprise Linux Distros?

**Tags:** ansible, infrastructure-as-code, immutable-servers, nixos


---

## 1 answers

### Answer by username_1 on 2019-04-29. Score: 3

You hint in the title about immutable infrastructure, so it sounds like you already know the solution: don't change existing servers, but bring up new ones with your changes, switch over to them, and switch back to the old ones if necessary.

Theoretically any of the standard config management tools can roll back by simply checking out a previous commit and rerunning the config. However, practically speaking this often isn't the case, as you may have introduced a new config rule (and so whatever it is doing is simply ignored in older versions) or you've written a rule that isn't easily reversible (for instance, does some destructive data operation). If you were **very** careful in how you always write your playbooks, you could avoid this, but a few less error-prone solution is just to use an immutable infrastructure approach.

> **Comments:**
> **username_2**: There is a vast difference between 'rollback' and 'restore n-1 version'. In theory there should be a way to rollback and rollforward however most tools simply do not have the smarts to implement it. Restoring to N-1 is only one step above manually making changes directly on a server. An Ansible instructor at a course went so far as to say that it 'can't be done' with Ansible.  
> **username_1**: @username_2 I don't understand the distinction you're trying to make. Can you clarify your terminology?  
> **username_2**: 'Rollback' as in keeping a snapshot copy of the state of the files of a target environment before copying in a new version, so that the original state can be restored at will. Note that an exact copy of the files is kept temporarily to allow this. To 'restore n-1 version' means to go into the source repository, and deploying these files in to the target environment. Rollback is immediate as it is an exact copy. A 'rollback' reverses all actions to the target environment. The n-1 restore can be used to manually roll back previous files. In theory Ansible playbooks could do this.  
> **username_2**: @XiongChiamov For further clarification, I asked an Ansible expert from Redhat how he would 'rollback a change made by an Ansible playbook' and subsequently restore the last known good state (rollforward). His answer was similar to yours: Add a new version to Git, use Ansible to deploy that version, then retrieve the n-1 version from Git and deploy that (to effect rollback). For 'rollforward' he would get the N (latest) version from Git and deploy it.True rollback would snapshot the target environment state, and be able to restore it.  

---

