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:
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”.
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?
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).
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.
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!
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.