rollback of applications using ansible or puppet - puppet

Question

How would you get ansible or puppet to deal with the following use case:
An application, X version 1, is installed with its configuration variables for version 1. Subsequently X version 2 is released with a different config variable set (i.e. that appplication may have added or removed a variable from their files under /etc). I want to upgrade to X version 2 and preserve old configuration from X version 1. I also want the option to rollback to X version 1 at a later date restoring it to the configuration state it had prior to upgrading to X version 2.
How would you go about ensuring this using Ansible or Puppet?

Answer 1

Your question is likely to be flagged as overly broad because there are so many potential answers/approaches, and it's going to depend greatly upon a number of other questions, such as:
Are you using a package manager (rpm, apt, etc) or are you installing applications manually, using gnu automake, or something else?
Precisely what sorts of configuration files are involved, how many, where are they located, etc?
At the most basic level, if you're relying on well-maintained packages then simply using the appropriate package manager may suffice. If you're doing anything beyond that then you're going to have to customize things based on your own preferences. There is no single wrong or right answer as to how to do this sort of thing simply because there are so many different approaches based on your individual needs/requirements.
As way of one example, suppose you have an application that relies on the configuration file /etc/service.conf, which only has a single entry containing a version number:
version: 1.2.3
You could simply template this file and specify the version number in Ansible or Puppet. For example, in Ansible you would just have a template that looks like this:
version: {{ version }}
And then a playbook that looks something like this:
- hosts: localhost
vars:
version: 1.2.3
tasks:
- yum: name=package-{{ version }}
state=present
- template: src=service.template
dest=/etc/service.conf
Of course you might want to expand this to ensure other versions of the package are removed so only the latest version exists.
If your environment is more complex, for example having a lot of different configuration files that need to be maintained and/or templating not being a viable solution then you probably want to implement some sort of backup/archiving of the configuration files before updating them. This could also be done any one of a number of ways, for example:
Using the Ansible fetch module to fetch configuration files from the target server
Simply invoking tar, cp, or something similar to make a backup of the files on the target server
You could also design a completely unique method of maintaining multiple versions of applications. For example, we use symlinks to manage multiple versions of third party applications as well as our own applications. We build and install different versions of Apache in locations like /deploy/software/httpd-2.2.21, /deploy/software/httpd-2.4.0, etc. and have a symlink named /deploy/software/httpd that points to the version we currently want to run. All the version-specific configuration files, etc. remain in the version-specific directory, so switching versions is as simple as shutting down Apache, changing the symlink, and restarting Apache.