Terraform: Create Ansible provisioner

[lukehoersten]

I'd like to use Terraform to build infrastructure then configure it with Ansible, similar to the Chef provisioner.

[donovanmuller]

+1

[martineg]

+1
(is https://github.com/adammck/terraform-inventory an alternative?)

[lukehoersten]

terraform-inventory just isn't as clean as the Terraform Chef provisioner and hopefully what a true Ansible provisioner could be.

[tony612]

:+1:

[IanVS]

Honest question: would there be a benefit to having a built-in Ansible provisioner over-and-above just using local-exec and using the Ansible cli?

[donovanmuller]

@IanVS That is the route I followed initially but Terraform seems to buffer stdout, so once you kick off your Ansible plays you don't see anything until your play is done or has been running enough until the buffer flushes.

I'm hoping support for Ansible would hopefully solve this problem, however if there is a workaround or a fix in Terraform that would solve this, then that would be good enough for me.
Not sure about others reasons behind this?

[nlamirault]

:+1:

[bborysenko]

:+1:

[wakwanza]

+1

[kchygoe]

+1

[vikingops]

:+1:

[jsmartin]

Fix local_exec's buffering of stdout and just call the ansible-playbook command. Couple that with a terraform dynamic inventory script. That's going to be the most flexible.

[IanVS]

Ansible has its own dynamic inventory scripts as well. The advantage to using them rather than Terraform dynamic inventory is that you can continue to run the Ansible playbooks (for updates, upgrades, deployments, etc.) after you have used Terraform to spin up the resources.

[jsmartin]

@IanVS by "terraform dynamic inventory script" I'm referring to an Ansible dynamic inventory script that pulls form Terraform :).

[lukehoersten]

It's not so much about kicking off Ansible as it is about communicating the information Terraform has to Ansible. Ansible dynamic inventory is many times not enough (for example groups are auto-generated from tags etc). Ansible plays however typically use nice group names like "webservers". What would be ideal is something similar to what Vagrant does with Ansible:
http://docs.vagrantup.com/v2/provisioning/ansible.html

So, after running Terraform, Terraform now knows the custom VPC DNS domain names I've given each host. This is not easily known to Ansible. Also, Terraform could generate a static inventory w/ groups of my choosing etc.

This is just what I had in mind and a lot of it comes form Vagrant. Perhaps others are thinking of other features.

[ghost]

It would be great if stdout / wasn't buffered, at least as a stop-gap.

[riccardofreixo]

+1

[dflower-rms]

+1

[d33d33]

+1

[pmastalerz]

:+1:

[beeradb]

+1

[michaelandersen]

+1

[danieslo]

+1

[kelseyfrancis]

+1

[cad]

+1

[sidick]

+1

[jdoss]

+1

[dereulenspiegel]

+1

[asafdav]

+1

[rjsamson]

:+1:

[jsmartin]

@LukeHoersten: I think at the very least, we'd still need unbufferred output of the playbook run in Terraform. In terms of generating a static inventory, how would you propose the inventory hosts and groups are created? What is the drawback to tagging the things and using Ansible's ec2.py as a dynamic inventory script? Or creating a dynamic inventory script that parses Terraform's state file?

[lukehoersten]

I think unbuffered output and using tags would be a great start. It's been a while since I originally posted the issue and I've solved some of my problems, like you said, by using groups and then using a static + ec2.py inventory to get reasonable group names from there. I didn't know both static and dynamic inventory could be used together previously.

[lukehoersten]

So I think formally I'm looking for:

1. a static inventory generator similar to Vagrant so I can put Route53 DNS names in Ansible inventory groups
2. Unbuffered output

[farridav]

+1

[tep-pl]

+1

[bscott]

+1

[wraithm]

+1

[rposborne]

+1

[s1lv3r40]

+1

[IanVS]

I'm pretty sure that additional +1 comments at this point won't help, and that it would be more useful if someone took a crack at making a PR. I'm a bit weary of seeing these in my inbox, and I imagine the maintainers must feel the same way.

[michaelandersen]

I agree. Let's confirm no one actively working on it. Otherwise I'd be
willing to take crack at it
On Dec 3, 2015 2:44 AM, "Ian VanSchooten" [email protected] wrote:

I'm pretty sure that additional +1 comments at this point won't help, and
that it would be more useful if someone took a crack at making a PR. I'm a
bit weary of seeing these in my inbox, and I imagine the maintainers must
feel the same way.

—
Reply to this email directly or view it on GitHub
https://github.com/hashicorp/terraform/issues/2661#issuecomment-161490653
.

[jsmartin]

My attempt at taking a crack at it would be re-using (to the extent possible) the code that Packer uses to run unbuffered local commands. I don't think having native config options for Ansible is that useful (and you'll constantly be playing catch-up with upstream).

[NicolasMas]

+1

[spinx]

+1

[fxp0]

+1

[IanVS]

@michaelandersen It looks like nobody's claimed this. Still want to make an attempt?

[Mil0dV]

@michaelandersen if you'd fork and make a start perhaps my coworker and I can also assist, at least with testing/code review. If you're willing to give push acc we could prob also contribute some code.

[thecodeassassin]

+1

[michaelandersen]

Ok @Mil0dV, i'll take a crack at it. I'll ping you guys when i have something worth reviewing

[shafiqissani]

+1

[Mil0dV]

Ok @Mil0dV, i'll take a crack at it. I'll ping you guys when i have something worth reviewing

Now that is something that I would like to +1!

[vasiliyb]

+1

[luis-echegaray]

+1

[kisamoto]

+1

[gibbsoft]

+1

[lucazz]

+1

[athak]

+1

[glnds]

+1

[johnjelinek]

:+1:

[jcmartins]

+1

[vmindru]

+1

[visualdensity]

+1

[panda87]

+1

[ortenheim]

+1

[aamorin]

:+1: ! definitely this is something I want too :)

[JimmySpivey]

:+1:

[jonmorehouse]

Hey everyone! I actually started hacking this up as a plugin over at: https://github.com/jonmorehouse/terraform-provisioner-ansible

Would love any and all feedback you all have!

[andrefbsantos]

:+1:

[pinterb]

@jonmorehouse I'm definitely interested in this. I'll start kicking the tires. Anything in particular you'd like to see get extra attention?

[wanghaisheng]

+2

[darksheer]

:+1:

[Mil0dV]

So besides the +1/2's, has anybody actually tried @johnmorehouse' plugin already?

[cad]

@Mil0dV I did try his plugin. It's promising. We should support him and bring some discussion and PRs to his repo if you ask me.

[lukehoersten]

I'll give it a try. Thanks for the reminder. The README looks like it's exactly what I've been looking for.

[Surgo]

+1

[jonmorehouse]

Thanks for the support on the plugin! I'm actively working on it and trying to get it "battle tested" for us to all use.

I'm planning on simplifying things a lot and adding support for more ansible features by switching to a more "native" approach. It shouldn't change the interface too much, but it might be worth following along on this ticket: https://github.com/jonmorehouse/terraform-provisioner-ansible/issues/13

[jmcvetta]

:+1:

[vmindru]

@jonmorehouse

Hi

very interested in this provisioner to become alive. Don't give up on your idea so early. A couple of things I want to mention ( if those are obvious repeating doesn't harm )

Did you know?

1) One can pass inventory data directly somehow as JSON format ? e.g.

Multiple hosts
ansible-playbook -i 'host1,host2,host3,host4:80,host5' --options playbook.yml

One host
ansible-playbook -i 'host1,' --options playbook.yml
Note: pay attention to the comma

2) The second problem I see is to wait for a connection before you fire-up your ansible thingy , for that I use remote-exec with ls command as a workaround before I do local-exec with ansible, this ensures the host is up before I start ansible run.

As a result, I have this thingy that plays the role of "Ansible provisioner"

provisioner "remote-exec" {
    inline = ["ls"]
    connection {
      type = "ssh"
      user = "user"
      private_key = "${file(var.ansible.private_key_path)}"
     }
  }
provisioner "local-exec" {
      command = "ansible-playbook -i '${aws_instance.server.public_ip},' --private-key ${var.ansible.private_key_path}   -e ansible_role_path='${var.ansible.role_path}' -s ${var.ansible.playbook_path} -T 300"
  }

Note: the -T 300 is just a paranoic preacatution :)
Note: -e ansible_role_path is just a var used for comodity you can also add this as option for ansible provisioner.

Let me know what do you think about this?

[panda87]

@vmindru I really like the idea you presented.
There is a way to use local-exec provisioner to run multiple ansible playbooks?

[bitemyapp]

:+1: would really like to see this.

[babatundebusari]

+1

[cad]

Folks, please use the +1 reaction at the top of this thread. It's a new Github feature. Otherwise this kind of posts make all of our notification icons go blue. And it crowds the thread that it gets hard to follow the meaningful conversations in it.

[rgabo]

I also heard that everyone who +1'd can only start using as many as +1 days later than those who merely subscribed to the Github issue. Thanks @Cad for pointing out the new feature to everyone and thanks for all the spam emails :wink:

[vmindru]

Monkey see monkey do
On Apr 5, 2016 12:19 PM, "Gabor Ratky" [email protected] wrote:

I also heard that everyone who +1'd can only start using as many as +1
days later than those who merely subscribed to the Github issue. Thanks
@Cad https://github.com/Cad for pointing out the new feature to
everyone and thanks for all the spam emails [image: :wink:]

[image: 1]
https://cloud.githubusercontent.com/assets/96628/14278542/89db5c2e-fb28-11e5-91f4-b7823da0966c.png

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/hashicorp/terraform/issues/2661#issuecomment-205744268

[v1k0d3n]

can we just close the ticket and mark @jonmorehouse contribution as the solution going forward? i think it's a great start; now we just need to start contributing to it. can anyone on the terraform team consider it for merge, and @LukeHoersten, what are your thoughts since you opened the issue? if there was more dialog, then it would probably drown out the +1's (although it's nice to know that others want feature this too) :)

[lukehoersten]

I'm in support of @jonmorehouse approach but this ticket represents inclusion in terraform proper and not an external plugin. If we could fold this ticket into a PR that would be ideal.

[v1k0d3n]

i couldn't agree more. @jonmorehouse would you be comfortable with submitting a PR? i think it's a great start. submitting it as a PR will only improve the module imo.

[jsmartin]

One thing I cannot determine from the documentation or examples is if ansible-playbook is executed on the terraform control node or on the managed node. Although it is supported, I would not recommend running Ansible on the managed node.

Also, I still don't get the benefit of using this vs calling ansible-playbook with local-exec. If local-exec could provide unbuffered output, you'd have everything you'd need. Having to maintain a specific plugin and playing catchup with new Ansible features as they are released doesn't seem worth it.

As someone already pointed out, ansible dynamic inventories can be leveraged to target tagged instances. No need to generate inventory files for terraform to use.

[mcgonagle]

+1

[sodre]

+1

[leopepe]

+1

[rehmanzile]

+1

[mdunnio]

+1

This would be a seriously useful feature.

[v1k0d3n]

not sure if anyone is actually reading through the thread or not, but for those who have +1'ed, have you tried @jonmorehouse's https://github.com/jonmorehouse/terraform-provisioner-ansible? It's already received 58 stars, which coincidentally is the same number of +1's (if you count the +2) in this thread.

[sujaip]

+1

[isamuelson]

+1

[crestenstclair]

Not to knock https://github.com/jonmorehouse/terraform-provisioner-ansible but that is NOT a first-party quality terraform provisioner.

It's a great start! But, it's too early to point to this repo and say "Problem solved!"

[rehmanzile]

Hmm. This request has been open for more than a year now.

[elmanytas]

+1

[sagagliardo]

+1

[schmitzcc]

+1

[stephanlindauer]

is it really that hard to understand that there are other ways to express interest in an issue is being resolved?
http://thenextweb.com/dd/2016/03/11/github-wants-shut-added-emoji-reactions/#gref
also there is a "subscribe" button that puts emphasis on an issue by the number of people being subscribed (who, by the way, are spammed with those +1 comments).
also, btw: sorry for another off-topic comment. ;)

[rehmanzile]

It has been more than a year for this request. I am thinking to use Ansible's AWS module. That way, I don't have to implement glue logic for terraform to Ansible.

[ninjatux]

@rehmanzile i used the cloud modules of Ansible but the fact that it doesn't keep the current state is not ideal for infrastructure management. Is totally different the way Ansible and Terraform works, you will never be able to get the same results with Ansible, destroying or applying incremental changes to your infrastructure will be a pain.

Instead I decided to use Terraform to create and manage the infrastructure and output the inventory for Ansible for provisioning the machines. The only thing I had to do to glue the 2 tools is using a bash script that launches them in sequence.

[minac]

Hi Valerio,

I'm thinking about doing the same. Do you mind sharing the "glue" you used
in terms of passing the inventory and any variables?

Thanks!

Miguel
https://www.migueldavid.eu

On 20 Sep 2016 8:26 a.m., "Valerio Barrila" [email protected]
wrote:

@rehmanzile https://github.com/rehmanzile i used the cloud modules of
Ansible but the fact that it doesn't keep the current state is not ideal
for infrastructure management. Is totally different the way Ansible and
Terraform works, you will never be able to get the same results with
Ansible, destroying or applying incremental changes to your infrastructure
will be a pain.

Instead I decided to use Terraform to create and manage the infrastructure
and output the inventory for Ansible for provisioning the machines. The
only thing I had to do to glue the 2 tools is using a bash script that
launches them in sequence.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/terraform/issues/2661#issuecomment-248224644,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEzKhpcM4vgy9epAxb1UVeGYa4Qj_FJVks5qr4q9gaJpZM4FUw5N
.

[rehmanz]

@ninjatux Thanks! for sharing! I am also looking into Salt Cloud. It maintains the state of the infra and performs configuration tasks via Salt Formulas.

[ninjatux]

@minac take a look at how to use terraform outputs for creating your ansible inventory. Once you can output everything you need for creating you inventory and/or your variables you can use a very simple script like this one:

#! /bin/bash
# terraform exec
terraform apply
# get variables
CUSTOM_VAR=`terraform output custom-var`
# build inventory
terraform output ansible-inventory > inventory_file
# exec polaybook
ansible-playbook -i ./inventory_file --extra-vars "custom_var=${CUSTOM_VAR}" play.yml

of course it really depend on your needs, but this is a simple approach that works for me.

[vmindru]

repeating this just in case you did not notice this earlier.

  provisioner "local-exec" {
      command = "ansible-playbook --private-key ${var.ansible_private_key} -i '${element(openstack_compute_floatingip_v2.test-vm.*.address, count.index)},'  -s ${var.ansible_plyabook_path} -T 300 -u root"
  }

this would like you would from command line

ansible-playbook --private-key ~/.ssh/id_rsa  -i '10.10.10.10,'  -s ~/some_playbook -T 300 -u root

the secret is you provide the inventory as json format and ansible treats it as dynamic inventory

e.g.

'host1,host2,host3,'

there fore you don't have to invent ugly workarounds and you trigger your playbook during your terraform apply run.

[ninjatux]

@vmindru will it output also ansible execution logs?

[vmindru]

@ninjatux why don't you just try it ? :) yeah it should last time i was doing this it did, let me try it again.
Also i think if fails if ansible fails.

let me test this for you.

VM

[vmindru]

@ninjatux sorry for late reply, here is an example of failed local-exec ansible apply, this might not be ideal but in 100% cases i have encountered it was kind of enough to understand what went wrong. as a simple workaround maybe redirect > 2>&1 to a file to capture full output of the command.

openstack_compute_instance_v2.test-vm: Provisioning with 'local-exec'...
openstack_compute_instance_v2.test-vm (local-exec): Executing: /bin/sh -c "ansible-playbook --private-key ~/.ssh/id_rsa -i '10.8.200.28,'  -s -T 300 -u cirros  ./ansible/apache.yml "

openstack_compute_instance_v2.test-vm (local-exec): PLAY [all] *********************************************************************

openstack_compute_instance_v2.test-vm (local-exec): TASK [setup] *******************************************************************
openstack_compute_instance_v2.test-vm: Still creating... (1m20s elapsed)
openstack_compute_instance_v2.test-vm (local-exec): fatal: [10.8.200.28]: UNREACHABLE! => {"changed": false, "msg": "SSH Error: data could not be sent to the remote host. Make sure this host can be reached over ssh", "unreachable": true}
openstack_compute_instance_v2.test-vm (local-exec):     to retry, use: --limit @./ansible/apache.retry

openstack_compute_instance_v2.test-vm (local-exec): PLAY RECAP *********************************************************************
openstack_compute_instance_v2.test-vm (local-exec): 10.8.200.28                : ok=0    changed=0    unreachable=1    failed=0

Error applying plan:

1 error(s) occurred:

* Error running command 'ansible-playbook --private-key ~/.ssh/id_rsa -i '10.8.200.28,'  -s -T 300 -u cirros  ./ansible/apache.yml ': exit status 3. Output: 
PLAY [all] *********************************************************************

TASK [setup] *******************************************************************
fatal: [10.8.200.28]: UNREACHABLE! => {"changed": false, "msg": "SSH Error: data could not be sent to the remote host. Make sure this host can be reached over ssh", "unreachable": true}
        to retry, use: --limit @./ansible/apache.retry

PLAY RECAP *********************************************************************
10.8.200.28                : ok=0    changed=0    unreachable=1    failed=0   



Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.
[vmindru@vmutil vmindru_vmindru_swift]$ 

also here is an example of success local-exec , it prints the stdout

openstack_compute_instance_v2.test-vm: Provisioning with 'local-exec'...
openstack_compute_instance_v2.test-vm (local-exec): Executing: /bin/sh -c "ssh-keygen -R 10.8.200.28 "
openstack_compute_instance_v2.test-vm (local-exec): # Host 10.8.200.28 found: line 292 type RSA
openstack_compute_instance_v2.test-vm (local-exec): /home/vmindru/.ssh/known_hosts updated.
openstack_compute_instance_v2.test-vm (local-exec): Original contents retained as /home/vmindru/.ssh/known_hosts.old

given there is a strong solution/workaround for this, I don't really understand why one still want's to have an ansible provisioner. could we just document this and have it available someone near local-exec e.g. local-exec best practices .

I really find terraform+ansible a "happy marriage" creating Skynet's with this 2 tools all the time :)

[vmindru]

p.s. here is another success local-exec an ansible run this time

openstack_compute_instance_v2.test-vm: Provisioning with 'local-exec'...
openstack_compute_instance_v2.test-vm (local-exec): Executing: /bin/sh -c "ansible-playbook --private-key ~/.ssh/id_rsa -i '10.8.200.28,'  -s -T 300 -u root  ./ansible/apache.yml "

openstack_compute_instance_v2.test-vm (local-exec): PLAY [all] *********************************************************************

openstack_compute_instance_v2.test-vm (local-exec): TASK [setup] *******************************************************************
openstack_compute_instance_v2.test-vm: Still creating... (5m3s elapsed)
openstack_compute_instance_v2.test-vm: Still creating... (5m10s elapsed)
openstack_compute_instance_v2.test-vm: Still creating... (5m13s elapsed)
openstack_compute_instance_v2.test-vm (local-exec): ok: [10.8.200.28]

openstack_compute_instance_v2.test-vm (local-exec): TASK [test file] ***************************************************************
openstack_compute_instance_v2.test-vm (local-exec): changed: [10.8.200.28]

openstack_compute_instance_v2.test-vm (local-exec): PLAY RECAP *********************************************************************
openstack_compute_instance_v2.test-vm (local-exec): 10.8.200.28                : ok=2    changed=1    unreachable=0    failed=0

openstack_compute_instance_v2.test-vm: Creation complete

Apply complete! Resources: 1 added, 0 changed, 1 destroyed.

[chulkilee]

In addition to https://github.com/adammck/terraform-inventory, I found https://github.com/CiscoCloud/terraform.py

[jamtur01]

@chulkilee Have a look at https://github.com/jonmorehouse/terraform-provisioner-ansible.

[hartzell]

@vmindru -- Thanks for your remote-exec/local-exec trick. It's very useful.

Do you have any magic to save me from the host key being unknown on a newly-built instance? I end up getting prompted and typing yes, like so:

digitalocean_droplet.foo (local-exec): TASK [setup] *******************************************************************
The authenticity of host '138.68.5.100 (138.68.5.100)' can't be established.
ECDSA key fingerprint is SHA256:gd8T55FBx1J2M6qVr3VS1nxqDy0DVkG16DNpF3ZH7uY.
Are you sure you want to continue connecting (yes/no)? digitalocean_droplet.foo: Still creating... (49s elapsed)
yes
digitalocean_droplet.foo: Still creating... (50s elapsed)
digitalocean_droplet.foo (local-exec): ok: [138.68.5.100]

[netflash]

@hartzell try to add parameter

--ssh-common-args='-o StrictHostKeyChecking=no'

to the ansible-playbook

@vmindru right ?

[mattwillsher]

Set
StrictHostKeyChecking no
As part of your ssh_args in the ansible.cfg file or as part of your ~/.ssh/config file.

On 20 Oct 2016, at 19:31, George Hartzell [email protected] wrote:

@vmindru -- Thanks for your remote-exec/local-exec trick. It's very useful.

Do you have any magic to save me from the host key being unknown on a newly-built instance? I end up getting prompted and typing yes, like so:

digitalocean_droplet.foo (local-exec): TASK [setup] *********************
The authenticity of host '138.68.5.100 (138.68.5.100)' can't be established.
ECDSA key fingerprint is SHA256:gd8T55FBx1J2M6qVr3VS1nxqDy0DVkG16DNpF3ZH7uY.
Are you sure you want to continue connecting (yes/no)? digitalocean_droplet.foo: Still creating... (49s elapsed)
yes
digitalocean_droplet.foo: Still creating... (50s elapsed)
digitalocean_droplet.foo (local-exec): ok: [138.68.5.100]
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[gibbsoft]

Modify or create an ansible.cfg file and consider adding these lines:

[defaults]
accept_hostkey = True
host_key_checking = False

For more info:
http://docs.ansible.com/ansible/intro_configuration.html#host-key-checking

Best regards

Nigel

---

Nigel Gibbs
Cloud Architecture Consultant / DevOps Consultant
Gibbsoft Ltd
w: gibbsoft.com
e: [email protected]
t: [phone]

On 20 October 2016 at 19:59, Alex Romanov [email protected] wrote:

@hartzell https://github.com/hartzell try to add parameter

--ssh-common-args='-o StrictHostKeyChecking=no'

to the ansible-playbook

@vmindru https://github.com/vmindru right ?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/terraform/issues/2661#issuecomment-255196933,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC4KjQR9Lp9l5_DZ7ygKlUs6MRs6xxqgks5q17oTgaJpZM4FUw5N
.

[mattwillsher]

host_key_checking is best left set to True unless the server at the other end is regularly re-provisioned. host_key_checking = False options forces Ansible to accept a change SSH key (as per ~/.ssh/known_hosts) and a SSH MITM attack would go unnoticed. http://docs.ansible.com/ansible/intro_getting_started.html#host-key-checking covers the details of this option.

accept_hostkey = True doesn't appear to be a valid option in ansible.cfg.

[mr-future]

+3

[vin047]

As an alternative solution, you can also:

1. use file provisioner to copy over the playbook
2. use remote_exec to launch ansible-playbook on the remote host

ansible + dependencies need to be installed on remote host, and the playbook and remote_exec command need to be implemented as if using ansible pull mode. e.g:

in the playbook:

- hosts: '{{ hosts }}'
  remote_user: '{{ user }}'

in the resource provisioner:

provisioner "remote-exec" {
  inline = [
    "ansible-playbook /home/me/play.yml --become --connection=local --inventory=localhost, --extra-vars='hosts=all user=me'"
  ]
 }

This approach uses terraforms inbuilt connection mechanism which mitigates the ssh host key checking issue and auto retries (with customisable timeout) if sshd isn't up yet etc

[chulkilee]

I ended up with a python script to translate output of terraform output -json into ansible inventory format (dynamic inventory). By doing this, I have more control on how and when to run provisioning (and the scope of it).

Now I'm not sure what is the merit of terraform provisioner for Ansible at all. All I need is to pass all information from Terraform to Ansible, and that can be done with ansible dynamic inventory. Only advantage of terraform provisioner is that it runs automatically after resource is created. However at the same time you lose control on how, and when to run ansible (e.g. re-run bootstrap on existing resource).

[highbass]

@chulkilee that would be useful! can you opensource it?

[pgporada]

You can get unbuffered Ansible output by running a playbook as follows. You can see this in the vagrant doc's as well. http://docs.ansible.com/ansible/guide_vagrant.html

    PYTHONUNBUFFERED=1 ansible-playbook playbook.yml

[chulkilee]

@highbass see http://docs.ansible.com/ansible/dev_guide/developing_inventory.html

You just need to write a python script to read output of 'terraform output -json and transform it as you needed. If you want a "general" solution, several projects are mentioned in other comments.

[hartzell]

Several folks have been questioning the usefulness of an Ansible provisioner, suggesting instead that we run Ansible separately. I'd just like to chime in and say that:

• it's very useful that successful provisioning is considered part-and-parcel of an instance being considered viable (if provisioning fails, the instance is not considered to have been built);
• while it's true that I could write bash scripts to do my provisioning I find the ability to use Ansible's higher-level mechanisms to be concise and maintainable; and finally
• it's convenient to not require that all of my nodes include up-to-date Ansible and all of its prereqs.

[alessandro-dibella-rockalltech]

+1

[cochransj]

👍

[andor-pierdelacabeza]

@cochransj @alessandro-dibella-rockalltech @visokoo @mr-future @schmitzcc And all the "+1" or ":+1:" posters, previous and to come: Stop Spamming.

If you wanna show support, instead of posting a comment and notifying the 100 people subscribed to it, there's an awesome "Add your reaction" button for each commit and issue, were you can give 'thumbs up' or 'thumbs down' or wathever you feel like giving to this issue. :man_facepalming:

[rehmanzile]

👍

[stack72]

Hi Friends,

Just an FYI, I opened an issue on a terraform-provisioner-ansible to talk about this. The maintainer of that project is going to be doing some work on it and then he will be looking at, potentially, opening a PR to the core repo

While we'd love to see something like this, we don't currently have any plans to implement this ourselves. Until then, this issue is unlikely to see any movement and remain stale. We're trying to prune the stale issues (that aren't going to be addressed anytime soon) by closing them. Note that we only do this for enhancement requests and not bugs.

Thanks

@stack72

[FlorinAndrei]

@stack72 That issue you're referencing - you've actually closed it. Why reference it here, then?

[stack72]

@FlorinAndrei I am now waiting on the writer of the provisioner

This is classed as something we are not going to be working on ourselves - I am in email talks with the writer

[rcaught]

@stack72 there hasn't been movement on that repo for over a year. Any updates? I would really like to run an Ansible provisioner, but don't feel comfortable when things go this stale.

[rcaught]

Also, I've read the other issue, but this seems like it needs someone just to move the current version (with PR's merged that fix some things) into core. Otherwise we could be sitting here waiting for a rewrite forever.

[stack72]

Hi @rcaught

I totally understand your concerns - as you can see, I did ask the question over there and the owner said he was going to do it. Unfortunately, I don't really feel as though it's my place to pick someone's code and move it to Terraform core - we haven't written it and don't own it

I am hopeful this will get resolved though

Thanks

Paul

[nealabh]

Hi all

was looking for some similar kind of a solution for provisioning azure VMs
something like this worked well for me.

provisioner "local-exec" {
command = < cat < ${element(azurerm_public_ip.mh..ip_address, count.index)}
EOF
EOD
}
}
resource "null_resource" "ansible" {
triggers {
host_ip = "${element(azurerm_public_ip.mh..ip_address, count.index)}"
}
provisioner "local-exec" {
command = "sleep 1m && ansible-playbook -i azure_hosts deploy.yml"
}
}

creating a null resource helped me generate an un-buffered output.

what do you guys think on this?

[wjam]

It seems like the provisioner that's been linked here is only designed to run Ansible on the machine that has been created rather than running from the machine that is running Terraform. Wouldn't a better approach be similar to how Packer already does this?

Packer accomplishes this by for the ansible provisioner (Ansible runs on the machine running packer) by proxying the commands through an in-memory SSH server to the remote instance, thus reusing already configured connection.

For ansible-local (Ansible runs on the machine that has just been created), it's just a case of copying up a bunch of files and then running the Ansible command.

[radekg]

I've created this recently, this runs ansible on the provisioned host: https://github.com/radekg/terraform-provisioner-ansible.
The local one will be ready over the weekend or so. I'd be happy to contribute into the core, if anyone would be interested.

Edit: But I do understand the feature creep story, in such case, just a heads up. The plugin linked above works fine with terraform 0.11.x.

[radekg]

I've added the local mode to the https://github.com/radekg/terraform-provisioner-ansible. Currently with a few caveats but the first version is there: https://github.com/radekg/terraform-provisioner-ansible#running-in-local-mode.

[monokal]

Why did this ticket get closed? I find it odd that we have a Chef Provisioner but no supported Ansible Provisioner with so much interest being shown. local-exec isn't a nice or reliable method of executing Ansible.

[jullianoacqio]

+1

[devops-rob]

I agree with @monokal completely. Ansible and terraform are a marriage made in heaven! To not have native provisioner support for it or a willingness to introduce such a provisioner is beyond me. I use terrafrom because it makes deployment and management tasks easy, until we get to the ansible bit so reading some of the comments, I can understand why some people have opted to use ansible modules instead but then again, it's not ideal either. There seems to be a huge demand for such a provisoner looking at this thread so for me it's a no-brainer but somehow this has been closed :-/

[radekg]

Looking at the comments above, I'd love to repeat, happy to see https://github.com/radekg/terraform-provisioner-ansible contributed to the core. There are definitely a bunch of features to be implemented (the biggest one being Windows support) but it is more or less complete. It supports local and remote deployments, quite well tested on non-Windows deployments at this moment in time.

[monokal]

Can you open a PR then so there's at least a chance of it being reviewed?

On Sat, 2 Jun 2018, 11:12 pm Rad Gruchalski, [e-mail]
wrote:

Looking at the comments above, I'd love to repeat, happy to see
https://github.com/radekg/terraform-provisioner-ansible contributed to
the core. There are definitely a bunch of features to be implemented (the
biggest one being Windows support) but it is more or less complete. It
supports local and remote deployments, quite well tested on non-Windows
deployments at this moment in time.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/terraform/issues/2661#issuecomment-394120751,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE6NkhgsDFGFMEDW4Fr4DQE_GvpTPHDxks5t4w3PgaJpZM4FUw5N
.

[bkmeneguello]

What are the criterions to add a feature to core? Maintenance? I think @radekg ansible provisioner is amazing and if promoted to core it would be amazing.

[radekg]

The https://github.com/radekg/terraform-provisioner-ansible is now available via Terraform Module Registry. Not sure if this is the correct distribution path but I was not able to think of anything better.

I'm not sure if the file naming in prebuilt releases will cause a problem when Terraform resolves the provisioner (I would assume it might be a problem). Please let me know if that is a problem, indeed.

Edit: it turned out that the released files naming was an issue. I have documented this in the readme and supplied a shell script to fetch and deploy a version of the provisioner: https://github.com/radekg/terraform-provisioner-ansible#installation.

[nwipfli]

Just tested the v.1.0.0 and it is working great. Very useful provisioner.

[radekg]

I have released version 2.0.0 of the Ansible provisioner:

• https://github.com/radekg/terraform-provisioner-ansible/releases/tag/v2.0.0
• https://registry.terraform.io/modules/radekg/ansible/provisioner/2.0.0

2.0.0 is not a drop-in replacement. Changes are documented: https://github.com/radekg/terraform-provisioner-ansible#breaking-changes. I have also provided some examples: https://github.com/radekg/terraform-provisioner-ansible/tree/master/examples.

Additionally, I have created a pull request for terraform. https://github.com/hashicorp/terraform/pull/19021 reflects the the commit https://github.com/radekg/terraform-provisioner-ansible/commit/47d943565097e3d5b3612c056f220df807343bb6 (https://github.com/radekg/terraform/commit/fac2403f4793da24685fa0013f09668f251c6860). The intent is to contribute the provisioner to Terraform.

[dmitrypol]

+1. Would be great to have official support.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.