rollback of applications

Archives Ansible Project
1

How would you get ansible to deal with the following use case:

An application, X version 1, is installed with it’s configuration variables for version 1. Subsequently X version 2 is released with a differnt config variable set. 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?

2

Where the installed app goes into? (what folder(s)?) What is the target OS? Where/how are your version-dependent configuration variable sets kept?

3

I’d choose a red/blue/green approach.

Basically it boils down to rotating the three environments (red, blue, green). The application is served from either separate hosts, directories, processes. Whatever your isolation level is

The basic assumption is that, just like your application codebase, your codebase for configuration management is in version control so that you can jump back in time. It is up to you (or rather the assumptions and constraints of your business to find a workflow based on branches or whatever floats your boat)

  • red: Old "production version
  • blue: Current “production” version
  • green: Current “development” version – this does NOT mean that development happens here. This DOES mean that the rollout and actual verification runs against this version (most probably the people who make the call of releasing a new version have access to it)

As you are ready to release you will simply switch the thing that routes your traffic (it does sound an awful lot like a service that is reachable via a network connection) to the “green” environment.

You end up with this state:

  • blue: Old "production version
  • green: Current “production” version
  • red: Current “development” version

After the next deployment:

  • green: Old "production version
  • red: Current “production” version
  • blue: Current “development” version

Now go forth and rotate :slight_smile:

Yeah it’s pretty general, but I can’t give you a more specific answer since your question was stated that way or it could be me simply misunderstanding what you want.

4

Glad to hear this is working out - I came up with a similar solution
for our deployments
(using the same colour terms to stop people thinking 'a'/'b'/'c' or
'1'/'2'/'3' somehow indicated
an order of importance) but haven't implemented it yet.

Hadn't heard it mentioned elsewhere before. Have since googled
'blue/green' deployments
and realized there's nothing new under the sun :smiley: