Production/Staging vs Development

[Andrew Pashkin]

Hi!
Here I read about how to manage differences between staging and production servers. As I understand it boils down to defining different variables to different servers.
But what is the good way to handle differences in systems if they are not only in variables but affect which packages should be installed or not.
In my case development environment is roughly a subset of production/staging - no need to web-server and queue.
So how in this case how to describe what should go to production and what in development servers?
I see two ways:
1) Make two host-groups - "base" and "live". in first - there would be only one host-group - "base" and in second - two "base" and "live" which would contain same hosts. And also there must be two playbooks - "base_playbook" and "live_playbook" - first will be applied to "base" hosts group and second to "live".
2) Second approach is to make variable like "environment" with three possible values - "production", "staging", "development". And then use conditional statements in playbooks.

Bot happroaches doesnt seem perfect, maybe there is a better ones?

-- 
With kind regards, Andrew Pashkin.
cell phone - +7 (985) 898 57 59
Skype - waves_in_fluids
e-mail - andrew....@gmx.co.uk

[Petros Moisiadis]

--
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/537B8C20.1040304%40gmx.co.uk.
For more options, visit https://groups.google.com/d/optout.

Hello,

First of all, it is unclear to me how effectively you are going to do your staging if you are not deploying a full stack of the software needed to run on production. That said, if you do have some parts that can be omitted from deploying your staging servers, it seems that you should reorganize your deployment tasks by creating roles that can be selectively applied as you want. For example, you could have a production playbook which would apply all needed roles and a staging playbook which would apply all roles except those that can be omitted (e.g. the 'web-server' and the 'queue' role, according to your saying).

[Petros Moisiadis]

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/537B904C.4060608%40yahoo.gr.

For more options, visit https://groups.google.com/d/optout.

Well I think I confused you wanting to do development differently than staging/production with you wanting to do staging differently than production (you meant the first, probably). But what I said about the creation of roles still applies.

[Andrew Pashkin]

On 20.05.2014 21:26, 'Petros Moisiadis' via Ansible Project wrote:

First of all, it is unclear to me how effectively you are going to do your staging if you are not deploying a full stack of the software needed to run on production.

Staging and production include all parts of stack, they are same and differ only by values like size of cache of something, etc.
What does not include all stack is development machine - local virtual machine of developer, it not require some parts of system - for example instead of production web-servers it use lightweight develpment server built into web-framework, it also does not need a queue.

That said, if you do have some parts that can be omitted from deploying your staging servers, it seems that you should reorganize your deployment tasks by creating roles that can be selectively applied as you want. For example, you could have a production playbook which would apply all needed roles and a staging playbook which would apply all roles except those that can be omitted (e.g. the 'web-server' and the 'queue' role, according to your saying).

Yeah, seems like you right, it fits best in Ansible model:

• Hosts are for defining ip-addresses and host-specific variables
• Conditional statements are for task-wide purposes, not for globally subsetting tasks - there would be a lot of refactoring if there would be need to add new, fouth environment, for example.
  
• And roles are for grouping tasks in them - so they fit just right.

Thanks for the answer!

[Petros Moisiadis]

--

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/537B9370.9030807%40gmx.co.uk.

For more options, visit https://groups.google.com/d/optout.

Also, if creating a new role for a group of tasks does not make much sense (e.g. because the tasks are too specific and are not meant to be reused  by other projects), you can just create a separate task file and use "include" statements in order to include it only in playbook for the environments that need these tasks.