Red Hat Ansible - Constructs
Apologies for the delay in getting this posted.
Red Hat Ansible has a lot of constructs that are really easy to understand!
Config file ansible.cfg - located in /etc/ansible/ansible.cfg The default interpreter path may also be set in ansible.cfg The defaults are great for most Log_path - to turn on logging to file or Ansible_log_path environ variable (or both) (Default is off) BCP turn on logrotate turn on SSH pipelining - ANSIBLE_SSH_PIPELINING=1 (off by default) default is also 'smart' which also checks for ControlPersist roles_path nocows=1 --forks - default is 5 Change if you need to utilize Environment Variables & CLI Options Tool - ansible-config Inventory - raw material that can be automated (static files or dynamic from another src) Dynamic (AWS EC2 instances) & Static pull info such as ec2.py detection API Modules - 400+ modules Tool - Module Index to search for specific module function or ansible-doc -l, ansible-doc yum Call Python scripts directly via Ansible Python API (not supported by Red Hat) Plug-ins - The gears in the engine Connection plug-ins allow Ansible to cmn w/ managed hosts and cloud providers Local - for Linux Apps, When writing playbooks that interface w/ cloud services or other API or When Ansible is invoked locally by cron job WinRm - requires pywinrm module on control node Docker - Ansible V2 allows it to treat Docker as managed hosts w/o SSH CLI - Collections - is a strict project/directory structure for delivering Ansible Content, download thru Galaxy, not Mazer! Min V2.9 of Engine BCP FQCN (Fully Qualified Collection Namespace) path to the module Automation Hub Control - Tower Built on top of Jinja Engine - formerly known as Core - can be bought thru subscriptions - keep this current via Yum Install not PIP Facts - things that are learned about remote nodes, are returned in structured data JSON Use to track for auditing & reports can then populate in ServiceNow Custom facts - /etc/ansible/facts.d (file must end in .fact extension) Cached facts - can be disabled use to config Network cards by PCI Address, exposes them as pciid Fact gather can be turned off via gather_facts: no (BCP speeds up task running) Gotcha - Pulling facts from Network devices is hit & miss even in Oct. '19 Filetree - Galaxy - online community for Roles (over 21000 exist) - learn from others who have gone before you (18K+ subscribers) install from the community to your playbook directory /etc/ansible/roles https://galaxy.ansible.com/explore#/: Istio Role on GitHub for an OpenShift Cluster, start your own Service mesh Inventory (inventories) - raw materials that ansible can automate (hosts/nodes, Groups, Nested Groups, Inventory specialized data (variables) static/dynamic sources BCP - declare in host_vars & group_var dir, use of include_vars Types: Static / Dynamic Static - INI file like text file [webservers] [db-servers] Dynamic - generated by outside provider(s) - cloud providers, cobbler system info, Zabbix, LDAP, CMDB - can download info from GitHub Ansible-cmdb add_host Location - /etc/ansible/hosts Groups - use 'children' suffix Ranges - Variables - String or number that gets assigned a value, append to end of host line inventory [:vars], let you reuse data from Playbooks, Inventory files, Tasks & Roles & Jinja2 template files - modifying files before distrib to managed hosts Allowed in Loops & Conditionals but not in playbooks Gotcha: Avoid putting logic into cfg file templates Delimiters Variables or logic placed btwn tags Expressions {% ... %} Output to User {{ ... }} Comments {# ... #} Control Structures Loops 'for' statement Conditionals 'if' statement Use Jinja2 template in Playbook Precedence - aka chain of Precedence 16 categories (low # = lower precedence) Register - way to capture output for reuse later Scope - defines where variable is accessible from 3-level: Global, Play & Host BCP use same Var across files, use of " " marks are mandatory for 1st element, use to build long paths (simpler), define vars for hosts is cleaner and easier, Host_vars take precedence over Group_vars Include - can be stored in own files, good way to segment data & can exploit Ansible Vault Testing - yamllint.com or --check, --syntax-check always_run (True or False) Modules - aka Module Library, Tools in the toolkit, > 450 modules shipped by default Most are written in Python unless Windows then its PowerShell based (recall Ansible can call PowerShell) set the ansible_python_interpreter to explicitly configure a Python 3 interpreter Check mode - aka dry run os_Cloud - OpenStack Nodes - managed by type & access Ansible Operator was created to address this short-coming. The Ansible Operator consists of two main pieces: A small chunk of Golang code, which handles the interface between Kubernetes/OpenShift and the operator. A container, which receives events from the above code and runs Ansible Playbooks as required. Creates watches.yaml file Operator SDK Project Proxy - for Jump Servers Playbooks - are YAML files, which contain the automation language and are written in YAML, tasks are executed sequentially (Top down) & invoke Ansible modules (Instruction book). More flexible than ad-hoc cmds turn mundane into powerful Plays and tasks executed in order presented Play define various attributes attribute: value Name is BCP name: my first play Access K8s API thru OpenShift Python client Block formatting - distinct groups Conditionals Loop - require use of array - use 'item' keyword 3-types Simple List of Hash Nested Loops Any Dynamic statement that adds value There will be another posting soon to tie the pieces together!
