Ansible playbook to install application from tarball

I'm doing this, but as I'm the expert here (because no-one else is doing it) I have no real idea how awesome my code actually is.

So the code should do the following:

• Export the tarball from subversion on the target box

• Untar it.

• Run the install script, answering questions appropriately.

For this review, I'd love input into whether this can be done differently, should generally follow different rules or whether it's just he best code you've ever seen.

-
  hosts: localhost
  become: true
  remote_user: root
  become_user: root
  become_method: su
  tasks:
  - name: Grab the encrypted variables
    include_vars:
      file: secret_things
      name: secrets

  - name: Grab the non-encrypted variables
    include_vars:
      file: mech_cfg.yml
      name: mech_cfg

  - name: install pip
    yum:
      name: python-pip
      state: latest

  - name: install pexpect==3.3 -- required for the expect module
    pip:
      name: pexpect
      version: 3.3

  - name: Get the tarball from subversion
    subversion:
      repo: https://repo/path
      dest: /tmp/mechballs
      username: "{{ secrets.svn_user }}"
      password: "{{ secrets.svn_pass }}"
      export: yes
      force: yes

  - name: Expand the tarball
    unarchive:
      src: /tmp/mechballs/{{ mech_cfg.mech_tarball }}.tar.gz
      dest: /tmp/mechballs/
      remote_src: true

  - name: Install the tarball
    expect:
      chdir: /tmp/mechballs/{{ mech_cfg.mech_tarball }}
      command: ./doinstall
      echo: yes
      responses:
        "Where do you want to install.*": "/opt/location"
        "Do you want to proceed with the installation .*" : "y"

(I know, reviving an OLD post, but the info I am sharing should be helpful to anyone new to Ansible that ends up here.)

You're playbook looks pretty good, well done! There are a few minor things that would help make your Ansible fu better.

First, your use of remote_user and specifically indicating that user as "root" makes your use of become_user and become_method redundant. However, in a case where "root" is not allowed to connect via ssh, and instead one would connect as "myuser" for example, then your code would change to remote_user: myuser and the become_user and become_method would be relevant.

Here is my edit of your playbook. Comments on what/why follow below.

---
- hosts: localhost
  become: true
  remote_user: root
  vars_files:
  - secret_things
  - mech_cfg.yml
  tasks:

  - name: install pip
    yum:
      name: python-pip
      state: latest

  - name: install pexpect==3.3 -- required for the expect module
    pip:
      name: pexpect
      version: 3.3

  - name: Get the tarball from subversion
    subversion:
      repo: https://repo/path
      dest: /tmp/mechballs
      username: "{{ vault_svn_user }}"
      password: "{{ vault_svn_pass }}"
      export: yes
      force: yes

  - name: Expand the tarball
    unarchive:
      src: /tmp/mechballs/{{ mech_tarball }}.tar.gz
      dest: /tmp/mechballs/
      remote_src: yes

  - name: Install the tarball
    expect:
      chdir: /tmp/mechballs/{{ mech_tarball }}
      command: ./doinstall
      echo: yes
      responses:
        "Where do you want to install.*": "/opt/location"
        "Do you want to proceed with the installation .*" : "y"
...

The big differences should be obvious.

Your first two tasks are gone; the include_vars module is typically only used to dynamicly load variables from a file. It is simpler and cleaner to define variables from a file for the play that needs them with the vars_files: declaration.

Also, be aware that the manner in which you call these files makes the variables in each file elements of a variable you named in each task. That does not happen with vars_files: so your variable names should be adjusted accordingly. Notice that your svn_user and svn_pass variable names have changed. Prepending vault_ to a variable that is encrypted with ansible-vault is a common practice, but not required.

Note: your 'secrets' file should be ansible-vault encrypted to protect the secrets written to storage. If properly used, variables can be declared inside a vault and will be decrypted when needed by the tasks/plays.

In closing, this is a decent playbook and functionally correct.

StackExchange Code Review Q#156523, answer score: 3