8
\$\begingroup\$

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:

  1. Export the tarball from subversion on the target box
  2. Untar it.
  3. 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"
200_success
145k22 gold badges190 silver badges478 bronze badges
asked Feb 28, 2017 at 10:36
\$\endgroup\$
1
  • 1
    \$\begingroup\$ I'm attempting to do something similar and my search led me here. This looks good to me. I guess one of the things you could do to improve this script is to check if your application was already installed or is present in the box prior to attempting a download, extract and installation. \$\endgroup\$ Commented Mar 25, 2018 at 4:17

1 Answer 1

3
\$\begingroup\$

(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.

answered Sep 16, 2021 at 3:03
\$\endgroup\$

Your Answer

Draft saved
Draft discarded

Sign up or log in

Sign up using Google
Sign up using Email and Password

Post as a guest

Required, but never shown

Post as a guest

Required, but never shown

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

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.