Guide to IASTU-HPC2
  • Introduction
  • User's Manual
    • basics
      • basic info
      • connecting
      • storage (must-read)
      • module system (must-read)
      • workflow on jobs
    • softwares
      • python
      • mathematica
      • matlab
      • spark
      • singularity
      • fortran, C, C++
      • java
      • command line tools
      • tensorflow
      • jax
    • FAQ
  • Administrator's Manual
    • Hardwares
    • Toolchains
      • Toolset for DELL servers
      • Ansible
      • Slurm
      • Spack
      • Container
      • BigData
      • Toolset for logging and monitoring
      • Further considerations
    • History
      • ToDo
      • VM Test
      • Real Setup
      • Admin Workflow
      • Softwares for scientific computations
      • Relay Host
Powered by GitBook
On this page
  • Common modules in Ansible
  • General syntax in playbooks
  • Conditionals
  • Loops
  • Useful keywords
  • CLI commands
  • Jinja Template Extension in Ansible
  • filters
  • test
  • Ansible Vault
  • Development consideration
  • Misc
  • Cautions
  • More references
  • My comments

Was this helpful?

  1. Administrator's Manual
  2. Toolchains

Ansible

PreviousToolset for DELL serversNextSlurm

Last updated 5 years ago

Was this helpful?

In this section, some aspects on ansible is discussed.

Common modules in Ansible

  • file

  • copy

  • command

  • cron: name attr must be specfied, otherwise, the crontab task shall be added repeatedly

  • debug: msg info to be printed

  • user

  • service

  • setup: get basic facts as variables collecting from nodes, note the key prefix ansible_ is not used

  • template: backup=yes

  • authorized_keys

  • lineinfile: When modifying a line the regexp should typically match both the initial state of the line as well as its state after replacement by line to ensure idempotence. Insert lines logic:

  • apt

  • make

  • hostname

  • : mysql-python package missing issue: , apt: name=python3-mysqldb state=present is enough, however pip install mysql-python wouldn't work.

  • pip

  • set_fact: set varible per host and used later in playbooks

  • : Using ansible to deploy gluster fs

General syntax in playbooks

Conditionals

  • when: the argument is rendered by jinja2, but no need for bracket or, and, not

  • compare operator in general language is ok to use in the condition statement, linke !=, >=

  • changed_when, failed_when

Loops

  • loop: list or list of hash, corresponding variables in leading task

  • some moudules directly support list argument

  • register of a loop task, has attr results as a list

Useful keywords

  • environment: config the env variables, http_proxy:http://blah, play level or task level

  • become: the user after ssh

  • remote_user: the user used for ssh

CLI commands

  • ansible-vault, encrypt protected info by given password, used as !value|eencrypted strings in playbooks

  • ansible-galaxy init: create the directory structure for ansible roles

  • ansible-playbook -e "var=value", overwrite var with highest priority

  • -vv: verbose mode

  • example: ansible -i ~/hpc/hosts cn -m apt -a "name=iperf state=present" --become -K

  • eg. ansible -i ./hosts cn[1:2] -m service -a "name=ganglia-monitor state=restarted" --become -K

Jinja Template Extension in Ansible

filters

Jinja template rendering only happen before the task is sent to nodes.

  • int, string to int

  • to_json, to_yaml, from_json, from_yaml

  • default(val) for default value of undefined variables, default(omit) use default value from external such as system defaults

  • min, flatten, flatten(levels=1)

  • unique, union(list), intersect(list), difference(list), symmetric_difference(list)

  • "{{mac_prefix| random_mac}}"

  • "{{ 60|random }}", "{{ [1,2,3]|random }}"

  • "{{ list|shuffle }}"

  • log(3), default base is e, pow(5), root(3), default power is 2, abs, round

  • hash, arguments can be sha1 or md5 or more choices. password_hash('sha256', 'mysecretsalt')

  • {{dict|combine(dict2)}} similar to dict.update(dict2) in python

  • regex_search('regexpr'), regex_search('regexpr', new)

test

Example

vars:
  my_var: "blah"
tasks:
  - debug:
      msg: "matched"
      when: my_var is match ("bl*")

Ansible Vault

Development consideration

  • Future plan: a spack module for ansible (settled by changed_when to avoid changed report of command)

  • molecule: full stack to test ansible

Misc

Cautions

  • In template system, just use {{}} instead of quote "" outside.

  • ansible_facts, the key should rip the ansible part off, which is ...

  • but for host_vars[hostname] to access the facts, the ansible prefix is must, which is in contrast with ansible_facts...

  • lookup plugin dont take become: yes as a thing, it just cannot cat other user's file….

  • for copy to copy files without permission, use remote_src: yes option, otherwise become is also useless...

  • the dest path cannot be a relative one, but use {{role_path}} instead

  • {{ D['key']|default ('undefined') }} can be used as default value for non existing keys of dict

More references

My comments

In general, ansible playbooks is definitely a type of domain specific language (DSL). There are so many fields, that config files (json or yaml) have been evolving into DSL which go far beyond the scope of some nouns, but also complicated adjective and verbs in the configurations. In some sense, it is always a question, that whether such a scheme is really simple and efficient enough as claimed? Maybe, say playbooks in this case, is easier to handle and suitable for more complicated cases when implemented directly as python scripts instead of a indirect level of abstraction (yml, which one needs reinvent basically all wheels of grammars in a Turing complete language like if and for, and still has less expression power than a Turing complete language). Of course, it is just my personal thought.

with_items, register.results is automatically a list, see

nested loop, use jinja template as "{{ ['alice', 'bob'] |product(['clientdb', 'employeedb', 'providerdb'])|list }}", see .

host pattern in ansible adhoc: . As quoted "You can refer to hosts within the group by adding a subscript to the group name", that is to say, the pattern is group[1:2] instead of c[1:2] as host names.

, --check in cli args, no real change happen but only reported as a simulation, also --diff to show difference

"{{json or yml data| json_query("query pattern")}}", this query pattern is backend with

ipaddr, ipv4, ipv6, return bool default, but can extract more info if arguments are given, see

parse_cli("spec") parse output by given spec file, for details of syntax, see

urlsplit get info from url by given arguments, see

indent in jinja template config files:

each task has it own ssh session and shell: . The default shell of ansible is sh, while source is a bash builtin instead of sh.

differece between command and shell module: . Command is weaker, it doesn't support evaluation on env vars and no support for |, & like things in shell.

Hostname is not persistent due to cloud init system in ubuntu, see .

default_ipv4 item in ansible fact could be empty, dont rely on this variable to setup networks. It seems that there is value only after dhclient <nic>? It is actually the default route ip, see .

git
blog
apt_key
apt repository
mysql_user
post
supervisorctl
gluster_volume
blog
cronvar
this post
here
doc
check mode
jmespath
doc
doc
doc
doc
practical example of modules and action plugins
lots of cool posts on ansible
blog
how source work with ansible
blog
solution here
this post
Some advance tricks on ansible