I should have mentioned that my components are going to have multiple installations for different customers, hence the environment specific stuff (target host, ports, names, paths etc) goes inside the var file i provide.
My purpose of posting this here is get idea about others are 'really' managing their infrastructure. On Wednesday, 3 August 2016 17:22:56 UTC+5:30, Dick Davies wrote: > > I'd use a role per component personally. I'm not 100% clear on why > you'd want to ask for variables > at each run, surely you want to capture that information and remove > the chance of error. > > To be honest it's a matter of taste, I'm having to adjust my playbook > styles to match the way > the team works. > > By the sound of it your team wants to use roles, I'd weigh that in > your decision much more > heavily than any opinion random dudes on the internet like me are > going to give you. > > On 3 August 2016 at 11:22, ishan jain <[email protected] <javascript:>> > wrote: > > Roles are reusable, well managed and promotes sharing - this i > understand > > very well. But somehow, i do not like them much, specially in enterprise > > applications. > > > > The application i am working on is a monolith being converted in small > > independent self contained systems. Each deployment is a combination of > a > > set of these components. Each component is managed by a team and these > > components are functionally dependent on each other, i.e. they can be > > installed individually, but for the whole system to function, a set of > > components in required. > > > > I design the deployment automation like this - a playbook for each > component > > asking one input - that deployment specific variables. Teams responsible > for > > components also maintain these component specific scripts and any change > > will not require mandatory change in another playbook. > > > > Now me and my colleagues have a disagreement in this regard. They are > hell > > bent on using roles, simply because that is the way to go. My arguments > are: > > - There is nothing to reuse really. Component specific stuff is not > really > > reusable. > > - Any dependency in within ansible scripts should be avoided. > > - we are not going to put roles in public/private galaxy > > - We need a playbook to use a combination of roles anyway > > > > I want to know what other people using Ansible for deploying their > > applications think. Do they prefer playbooks for everything or they try > to > > introduce as many roles as possible ? > > > > Also, i was a bit surprised to see that importing a playbook is > deprecated > > now. I was thinking of writing wrapper playbooks that in turn run a > bunch of > > other playbooks in a sequence. I mean what is wrong in that ? > > > > -- > > 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] <javascript:>. > > To post to this group, send email to [email protected] > <javascript:>. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/ansible-project/158564f8-efcb-48db-b6bd-841224fc7071%40googlegroups.com. > > > > For more options, visit https://groups.google.com/d/optout. > -- 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/a0740265-b6b9-40ae-bbaa-fa5f67a5c590%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
