Ansible is great for deploying infrastructure, but it requires you to have a control machine. This adds the burden of manually setting it up and securing it, and then pulling down your playbooks and making connections out to your servers.

I would like a way to run my playbooks 'in the cloud' rather than on my own system. I am aware the commercial offering Ansible Tower, however as far as I can see this is not suitable for personal use.

One option is to run them using a hosted CI tool such as Travis-CI or Gitlab CI, however this feels wrong from a security point of view, as somebody who gained access to my Travis/GitLab accounts would then have access to all of my servers.

Which solutions are out there that meet this requirement? Does my GitLab CI proposal have severe security problems or is it an accepted solution?

2 Answers 2


The solution is to automate setting up the control machine, i.e., the VM. You can use, for example, Vagrant, Terraform or similar tools (I'll stick with Vagrant in this answer for this example, it's about the principle). With that approach, the VM is wholly defined by a text file ("Vagrantfile"), and can easily and repeatably be created and re-created. The Vagrantfile species a base image, for example some particular Linux distribution; networking etc.; and necessary command lines to set it up, going from there.

You can set up your VM (i.e., install Ansible) by just providing all necessary shell commands. In this particular example, this is probably enough. If you need a more complex VM, you can get kind of recursive, and configure the VM itself by using Ansible (or one of its alternatives).

Obviously, you will want to treat the Vagrantfile the same as your other configurations; i.e., commit it to your SCM and keep it up to date.

This is just an example: You don't need to use Vagrant or a VM; you can also install your Ansible inside a Docker image or whatever your cloud provider of choice provides as containerization.

  • 1
    Perhaps you could also mention terraform
    – 030
    Jan 27, 2019 at 13:17
  • 1
    @rubberband876 yes, I do this and run my control machine on aws
    – jdog
    Jan 28, 2019 at 4:48
  • 1
    @rubberband876: Of course you can set up your Ansible control machine with Ansible; I thought you wanted to solve the problem of setting up a machine to run Ansible, in the first place. If you set up your Ansible with Ansible, then you also would need to setup your Ansible-Ansible-runner with Ansible to run Ansible to set up your actual machines... :-) People use Vagrant/Terraform as a first step to set up something which needs no "prior" setup (those VMs appear out of "thin air" without any requirements whatsoever, totally separate from the host computer).
    – AnoE
    Jan 28, 2019 at 12:51
  • 1
    @rubberband876: Yes, that is correct.
    – AnoE
    Jan 28, 2019 at 21:26
  • 1
    @rubberband876: well, that's the crux - if you don't trust your cloud/platform provider, then you're pretty much out of luck, especially with a "push-type" ansible deployment. But better open a new question for that, I haven't used Ansible out of Gitlab CI, so don't know if there a good option to handle the secrets in a manner to protect them from someone taking over your Gitlab account.
    – AnoE
    Jan 28, 2019 at 23:12

If you're going to go the infrastructure-as-code way, you're going to want to store that code in a repository. Having your infrastructure definition stored in a VCS (GitLab) has pretty much the same security implications as storing code in GitLab. Just make sure you don't store sensitive data or credentials in plain text, or at all if you can help it. In Ansible's case, that usually means using Ansible Vault to encrypt sensitive files. But that's by no means the only way.

As for deploying, you can use ansible-pull, which runs on the machine you want to set up:

ansible-pull -U <repository> [options] [<playbook.yml>]

It will get the Ansible config from the specified repository to local host, then executes the playbook you tell it to.

That should meat your requirements, but it also means that the machine executing ansible-pull will have access to everything that is in that repository. Whether that is secure enough for your environment or not is up to you. You can split your Ansible config in several repositories, use different branches, revoke the machine's access after the initial pull, etc.

In general, encrypt sensitive data in the repository (encryption on disk), make sure you pull over SSH or HTTPS (encryption in flight), and be mindful of who has access to the repository, even indirectly (access/user management), and you've gone a long way towards having a decently secure environment.

Whether using CI to deploy Ansible is secure enough or not, that's debatable. One could argue that someone who gains (write) access to the Travis/GitLab account where you keep your Ansible playbooks already got access to your infrastructure since they can alter those playbooks, it's just a matter of time. On the other hand, code stored in repository is half the point of infrastructure-as-code. YMMV.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.