Re: [ansible-project] Multiple instances of Ansible to deliver to production and non-production environments

[Byron Mabbett]

Thanks Dick,
'policy scar tissue' :')

Thats great, I am going to use that. It's more that we have had no CM, it 
all been manual in the past. Have tried to say by implementing Ansible we 
do no need the complete separation, so will have to prove it. The agentless 
of ansible was the key point for me in going with it.

On Wednesday, February 17, 2016 at 12:14:17 AM UTC+13, Dick Davies wrote:
>
> We run the same playbooks against 7 (!) various staging environments, 
> with a different inventory 
> for each. Per-environment config goes into the inventory under the 
> [all:vars] key - including things 
> like versions of RPMs etc. 
>
> SSH credentials are managed out of band, but there's a central git 
> repo to hold all this that can 
> be checked out to a bastion host on the relevant environment. 
>
> We've occasionally branched the repo to allow big changes in playbook 
> structure to be proven 
> on dev. environment configs but try to merge those into master asap. 
>
> As others have said, a playbook per environment is likely to involve 
> unproven playbook 
> runs against production. 
>
> (as an aside, the restrictions you are being presented with sound like 
> 'policy scar tissue' after someone 
> got burned by a different CM solution like Puppet or Chef. The 
> agentless nature of Ansible makes 
> it a lot less likely a change can 'leak' into prod without some 
> operator explicitly wanting it). 
>
> On 14 February 2016 at 20:23, Byron Mabbett  > wrote: 
> > HI All, 
> > First post and we are looking to implement Ansible into a new cloud 
> > environment for multiple legacy systems. 
> > 
> > Sorry but there is a bit of a story first and this is more a 
> setup/component 
> > architecture question as we have a security constraint that production 
> and 
> > non-production data centers can never talk to each other. Meaning 
> components 
> > such as version control and configuration management have to have two 
> > instances (prod and non-prod) with separate login's etc and syncing 
> taking 
> > place between them. 
> > 
> > I think this is mad, and have managed to talk them down to have only one 
> > version control instance. 
> > 
> > However, compromise was a prod and non prod Ansible, which we can sort 
> of 
> > justify, as we have a lack of maturity with tools as we are just 
> starting to 
> > implement Ansible. 
> > 
> > Do others have experience in running two instances of Ansible, and 
> keeping 
> > common config in sync? 
> > 
> > eg: 
> > 1. One source repository for Ansible config containing both prod and 
> > non-prod config 
> > 2. Two source repository's for Ansible config, one prod and one non-prod 
> > config 
> > 
> > Any steer's appreciated. 
> > 
> > Cheers 
> > Byron 
> > 
> > -- 
> > 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/ea685c2a-0084-49b6-b692-1934c366d45f%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 ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/2194db62-7238-4b48-814e-c14134740da2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ansible-project] Multiple instances of Ansible to deliver to production and non-production environments

[Dick Davies]

We run the same playbooks against 7 (!) various staging environments,
with a different inventory
for each. Per-environment config goes into the inventory under the
[all:vars] key - including things
like versions of RPMs etc.

SSH credentials are managed out of band, but there's a central git
repo to hold all this that can
be checked out to a bastion host on the relevant environment.

We've occasionally branched the repo to allow big changes in playbook
structure to be proven
on dev. environment configs but try to merge those into master asap.

As others have said, a playbook per environment is likely to involve
unproven playbook
runs against production.

(as an aside, the restrictions you are being presented with sound like
'policy scar tissue' after someone
got burned by a different CM solution like Puppet or Chef. The
agentless nature of Ansible makes
it a lot less likely a change can 'leak' into prod without some
operator explicitly wanting it).

On 14 February 2016 at 20:23, Byron Mabbett  wrote:
> HI All,
> First post and we are looking to implement Ansible into a new cloud
> environment for multiple legacy systems.
>
> Sorry but there is a bit of a story first and this is more a setup/component
> architecture question as we have a security constraint that production and
> non-production data centers can never talk to each other. Meaning components
> such as version control and configuration management have to have two
> instances (prod and non-prod) with separate login's etc and syncing taking
> place between them.
>
> I think this is mad, and have managed to talk them down to have only one
> version control instance.
>
> However, compromise was a prod and non prod Ansible, which we can sort of
> justify, as we have a lack of maturity with tools as we are just starting to
> implement Ansible.
>
> Do others have experience in running two instances of Ansible, and keeping
> common config in sync?
>
> eg:
> 1. One source repository for Ansible config containing both prod and
> non-prod config
> 2. Two source repository's for Ansible config, one prod and one non-prod
> config
>
> Any steer's appreciated.
>
> Cheers
> Byron
>
> --
> 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-project+unsubscr...@googlegroups.com.
> To post to this group, send email to ansible-project@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/ea685c2a-0084-49b6-b692-1934c366d45f%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 ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/CAK5eLPSXbrsHdy%3Dtm81hxrRuWZiRd32OWN0CgvL%2BJ-QV0xZu%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ansible-project] Multiple instances of Ansible to deliver to production and non-production environments

[Maciej Delmanowski]

Hey Byron,

I'm using Ansible with multiple environments daily and it's very easy
once you unlearn what Ansible documentation presents as a best
practice. :-)

First, forget about /etc/ansible/ directory and its contents. Instead,
in your home directory create separate directories, each one for a
different "environment" - production, staging, testing, etc. For
example:

~/src/projects/example.com/production/
~/src/projects/example.com/staging/

Additionally create a separate directory for all of your playbooks
that will be applied to both environments:

~/src/projects/example.com/playbooks/

Now, cd into one of the project directories (let's say
~/src/projects/example.com/staging/) and assume that you work from
there. The same steps should be performed in the other project
directory.

Create ansible inventory and other required directories, for example:

ansible/inventory/hosts
ansible/inventory/group_vars/all/
ansible/inventory/group_vars/group/
ansible/inventory/host_vars//

ansible/roles/
ansible/playbooks/

In the project directory, create 'ansible.cfg' file with contents:

[defaults]
inventory = ansible/inventory
roles_path = ansible/roles/

You can add any variables from /etc/ansible/ansible.cfg that you want,
just make sure that it points to your local project directory instead
of the /etc/ansible/ directory. Put your playbooks and roles in
previously created directories. It's easier if you put them in a
shared common directory and symlink them to project directories.

Now, when you want to work in a staging environment, or production
environment, all you need to do is cd into it and ansible should
(using local ansible.cfg file) automatically use that environment. So
for example to run your main playbook, run:

ansible-playbook ansible/playbooks/site.yml -l host

And to switch to production environment, run:

cd ../production

These environments should be completely separate and should use
different hosts. You could try and combine different parts of the
inventory between them, but it might get tricky. Regardless, you
should use the same set of playbooks and roles in both environments to
be sure that staging environment reflects your production environment.
Only think that should be different is contents of the
'ansible/inventory/' directory, if needed.

Try it out a couple of times and I think that you will like it. :-)

Cheers,
Maciej


On Sun, Feb 14, 2016 at 9:23 PM, Byron Mabbett  wrote:
> HI All,
> First post and we are looking to implement Ansible into a new cloud
> environment for multiple legacy systems.
>
> Sorry but there is a bit of a story first and this is more a setup/component
> architecture question as we have a security constraint that production and
> non-production data centers can never talk to each other. Meaning components
> such as version control and configuration management have to have two
> instances (prod and non-prod) with separate login's etc and syncing taking
> place between them.
>
> I think this is mad, and have managed to talk them down to have only one
> version control instance.
>
> However, compromise was a prod and non prod Ansible, which we can sort of
> justify, as we have a lack of maturity with tools as we are just starting to
> implement Ansible.
>
> Do others have experience in running two instances of Ansible, and keeping
> common config in sync?
>
> eg:
> 1. One source repository for Ansible config containing both prod and
> non-prod config
> 2. Two source repository's for Ansible config, one prod and one non-prod
> config
>
> Any steer's appreciated.
>
> Cheers
> Byron
>
> --
> 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-project+unsubscr...@googlegroups.com.
> To post to this group, send email to ansible-project@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/ea685c2a-0084-49b6-b692-1934c366d45f%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 ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/CAEnKK1yswcjTa2jX6SqD9pCDmya74yPOH3yvk_JNPXSRSxpwLA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[ansible-project] Multiple instances of Ansible to deliver to production and non-production environments

[Byron Mabbett]

HI All,
First post and we are looking to implement Ansible into a new cloud 
environment for multiple legacy systems.

Sorry but there is a bit of a story first and this is more a 
setup/component architecture question as we have a security constraint that 
production and non-production data centers can never talk to each other. 
Meaning components such as version control and configuration management 
have to have two instances (prod and non-prod) with separate login's etc 
and syncing taking place between them. 

I think this is mad, and have managed to talk them down to have only one 
version control instance.

However, compromise was a prod and non prod Ansible, which we can sort of 
justify, as we have a lack of maturity with tools as we are just starting 
to implement Ansible.

Do others have experience in running two instances of Ansible, and keeping 
common config in sync?

eg:
1. One source repository for Ansible config containing both prod and 
non-prod config
2. Two source repository's for Ansible config, one prod and one non-prod 
config

Any steer's appreciated.

Cheers
Byron

-- 
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-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/ea685c2a-0084-49b6-b692-1934c366d45f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.