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"
-
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\$Karthic Raghupathi– Karthic Raghupathi2018年03月25日 04:17:44 +00:00Commented Mar 25, 2018 at 4:17
1 Answer 1
(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.