Geek Answers Handbook

Ansible - remote or local automation?

When starting an automation tool, such as Ansible, to create an infrastructure stack in the cloud (for example, AWS), is it enough to have an automation tool and build a stack in separate areas / VPCs in the cloud or does it make sense to have your own automation tool and scripts locally (own processing center data / machine)?

Both seem to be used, but I'm just wondering if there is a standard for best practice.

+6
source share
2 answers

Unlike xeraa good answer, we run as much as possible from within AWS.

The real benefits we get from this are that it allows us to use the centralized Jenkins servers that run Ansible (and Terraform in our case to actually provide AWS with Ansible, which was only used to set up EC2 instances and run administrative books for administrative tasks).

We can then control access to these Jenkins servers through credentials and / or security groups / NACLs.

The implementation of this method means that we can control the number of people who have some credentials that will allow them to create everything that they like and / or destroy everything that they like.

Ideally, we only provide credentials to Jenkins servers through the IAM EC2 instance roles, but we are not quite there yet.

One of the real benefits of this is that our front / second line supports guys who use Windows, pretty much exclusively get access to a good web-based GUI to manage things in the middle of the night and run Jenkins jobs in which they specifically have access to which will perform operations such as restarting the server / service or even recovering part of the VPC.

We have a separate "dev" account with which developers have access to their own machines, and here we build things when we develop our Ansible database (and Terraform) before this code base is used in our test and production conditions.

+4
source

We run everything locally.

A plus

  • We test all the playbooks (and our software) in the local Vagrant box, so we still need to locally.
  • We do not need additional cars. And you should also configure them using Ansible, so at least someone should install Ansible. Otherwise, you have a problem with the chicken and the egg.
  • Probably a little faster because you have less network host.

minus

  • Everyone needs a local Ansible installation that will only work on Linux and Mac, but not on Windows (maybe just the goal).

Other considerations

  • For our Windows users, a Linux / Mac user creates a virtual machine with Ansible (everything is configured) and exports it as a base field. Then, Windows users can import this base field into Vagrant and just need to run it - everything is already installed. This includes Ansible, so you can run everything from a VM.
  • At first, we planned to put Ansible in our NAT instances (for private VPC subnets). But then we need one configuration to configure VPC, security groups and NAT instances, and another to run in NAT instances and configure the rest of the infrastructure. However, we could not see any real benefit in this, so now we have everything locally.

PS: Not sure if there is a final answer, but these are our arguments.

+4
source

More articles:


All Articles