On 05/20/14 20:26, 'Petros Moisiadis' via Ansible Project wrote: > On 05/20/14 20:08, Andrew Pashkin wrote: >> Hi! >> Here I read >> <http://docs.ansible.com/playbooks_best_practices.html#stage-vs-production> >> 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 - [email protected] >> -- >> 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 [email protected] >> <mailto:[email protected]>. >> To post to this group, send email to [email protected] >> <mailto:[email protected]>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/ansible-project/537B8C20.1040304%40gmx.co.uk >> <https://groups.google.com/d/msgid/ansible-project/537B8C20.1040304%40gmx.co.uk?utm_medium=email&utm_source=footer>. >> 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). > -- > 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 [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/537B904C.4060608%40yahoo.gr > <https://groups.google.com/d/msgid/ansible-project/537B904C.4060608%40yahoo.gr?utm_medium=email&utm_source=footer>. > 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. -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/537B92B5.9010706%40yahoo.gr. For more options, visit https://groups.google.com/d/optout.
