rollback of applications

84 views
Skip to first unread message

skg

unread,
Jun 15, 2015, 8:38:49 AM6/15/15
to ansible...@googlegroups.com
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?

Yassen Damyanov

unread,
Jun 18, 2015, 3:02:54 AM6/18/15
to ansible...@googlegroups.com


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

Martin

unread,
Jun 18, 2015, 12:42:32 PM6/18/15
to ansible...@googlegroups.com
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 :)

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.


--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/85636d21-048f-473d-92cd-7abf404a17e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--

Dick Davies

unread,
Jun 20, 2015, 8:22:03 AM6/20/15
to ansible list
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 :D
> https://groups.google.com/d/msgid/ansible-project/CAK1mKEQQW%3DY2A3-06YMgzTi0MuAkOnaEK01N37M3BetsmfH-GA%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages