{"id":3701,"date":"2020-05-17T11:06:29","date_gmt":"2020-05-17T09:06:29","guid":{"rendered":"http:\/\/miro.borodziuk.eu\/?p=3701"},"modified":"2020-09-28T22:57:13","modified_gmt":"2020-09-28T20:57:13","slug":"ansible-comprehensive-notes","status":"publish","type":"post","link":"http:\/\/miro.borodziuk.eu\/index.php\/2020\/05\/17\/ansible-comprehensive-notes\/","title":{"rendered":"Ansible Training Notes"},"content":{"rendered":"

 <\/p>\n

<\/p>\n

Configuration file<\/span><\/h2>\n

When installed, the ansible package provides a base configuration file located at \/etc\/ansible\/ansible.cfg<\/code>.<\/p>\n

Priority in which the configuration files are processed:<\/p>\n

    \n
  1. $ANSIBLE_CONFIG<\/code> (an environment variable)<\/li>\n
  2. .\/ansible.cfg<\/code> (in the current directory)<\/li>\n
  3. ~\/.ansible.cfg<\/code> (the user’s home directory)<\/li>\n
  4. \/etc\/ansible\/ansible.cfg<\/code><\/li>\n<\/ol>\n

    To find out what config file is in use, run the following:<\/p>\n

    $ ansible --version\r\nansible 2.7.9\r\nconfig file = \/home\/ansible\/ansible.cfg\r\n<\/code><\/pre>\n
    To get started, copy configuration files to the home directory:<\/p>\n
    $ cp \/etc\/ansible\/ansible.cfg ~\/ansible.cfg\r\n$ cp \/etc\/ansible\/hosts ~\/inventory\r\n<\/code><\/pre>\n
    Note the maximum number of simultaneous connections that Ansible makes is controlled by the forks parameter in ansible.cfg<\/code>:<\/p>\n
    forks 5\r\n<\/code><\/pre>\n
    Inventory<\/span><\/h2>\n
    Example inventory configuration:<\/p>\n
    $ cat ~\/inventory\r\n\r\n[myself]\r\ncontrolnode.example.com host=controlnode ansible_connection=local\r\n\r\n[web]\r\nmanagedhost[1:2].example.com host=managedhost[1:2]\r\n\r\n[db] \r\nmanagedhost[3:4].example.com host=managedhost[3:4] ansible_user=dbadmin\r\n\r\n[lab:children]\r\nweb\r\ndb<\/pre>\n
    Listing hosts from inventory:<\/p>\n
    [ansible@controlnode ~]$ ansible all --list-hosts\r\nhosts (5):\r\ncontrolnode.example.com\r\nmanagedhost1.example.com\r\nmanagedhost2.example.com\r\nmanagedhost3.example.com\r\nmanagedhost4.example.com\r\n\r\n[ansible@controlnode ~]$ ansible web --list-hosts\r\nhosts (2):\r\nmanagedhost1.example.com\r\nmanagedhost2.example.com\r\n\r\n[ansible@controlnode ~]$ ansible db --list-hosts\r\nhosts (2):\r\nmanagedhost3.example.com\r\nmanagedhost4.example.com<\/pre>\n
    There is a special group named “all” that matches all managed hosts in the inventory.<\/p>\n
    - hosts: all\r\n<\/code><\/pre>\n
    There is also a special group named “ungrouped” which matches all managed hosts in the inventory that are not members of any group.<\/p>\n
    - hosts: ungrouped\r\n<\/code><\/pre>\n
    Quote host patterns used on the CLI to protect them from unwanted shell expansion:<\/p>\n
    - hosts: '*.example.com'\r\n- hosts: '10.0.0.*'\r\n<\/code><\/pre>\n
    Multiple entries in the inventory can be referenced using lists:<\/p>\n
    - hosts: web,managedhost1.example.com\r\n<\/code><\/pre>\n
    If you have static and dynamic inventory files in the same directory, then they are merged and treated as one inventory!<\/p>\n
    Show inventory for all:<\/p>\n
    $ ansible \"*\" -i ~\/inventory --list-hosts<\/code><\/pre>\n
    Target two inventories from the command line like this:<\/p>\n
    $ ansible-playbook play.yml -i staging -i production<\/pre>\n
    Aggregating inventory sources with a directory::<\/p>\n
    inventory\/\r\n  openstack.yml # configure inventory plugin to get hosts from Openstack cloud\r\n  dynamic-inventory.py # add additional hosts with dynamic inventory script\r\n  static-inventory # add static hosts and groups\r\n  group_vars\/\r\n    all.yml # assign variables to all hosts<\/pre>\n
    Privilege escalation configuration in ansible.cfg<\/code>:<\/p>\n
    [privilege_escalation]\r\nbecome = false\r\nbecome_method = sudo\r\nbecome_user = root\r\nbecome_ask_pass = false\r\n<\/code><\/pre>\n
    How to set the default user to use for playbooks in ansible.cfg<\/code>:<\/p>\n
    remote_user = ansible\r\n<\/code><\/pre>\n
    How to set the log file in ansible.cfg<\/code>:<\/p>\n
    log_path = \/home\/ansible\/ansible.log\r\n<\/code><\/pre>\n
    <\/h2>\n
    Ad Hoc Commands<\/span><\/h2>\n
    \n
    \n
    \n
    Common modules:<\/div>\n<\/header>\n
    \n
      \n
    • ping<\/code> <\/strong>\u2013 Validate if server is up and recheable. No required parameters.<\/li>\n<\/ul>\n
      $ ansible all -m ping\r\n$ ansible all -m ping --limit managedhost1<\/pre>\n
        \n
      • command<\/code> <\/strong>– If no module is defined, Ansible uses the internally predefined “command<\/em>” module.\n
        $ ansible all -m command -a \/usr\/bin\/hostname -o\r\n$ ansible all -a \"\/usr\/bin\/echo hi\"\r\n$ ansible all -a \"\/sbin\/reboot\"\r\n$ ansible all -a \"\/sbin\/reboot\" -f 10\r\n$ ansible managedhost1 -a '\/bin\/yum list installed postfix'<\/pre>\n<\/li>\n<\/ul>\n
          \n
        • yum<\/code> <\/strong>\u2013 Use yum package manager. Parameters name<\/code> and state<\/code>.<\/li>\n<\/ul>\n
          $ ansible all -m yum -a 'name=tcpdump state=present'\r\n$ ansible all -m yum -a 'list=tcpdump'\r\n$ ansible managedhost1 -b -m yum -a \"name=elinks state=latest\"<\/pre>\n
            \n
          • service<\/code> <\/strong>\u2013 Control Daemons. Parameters name<\/code> and state<\/code>.<\/li>\n<\/ul>\n
            $ ansible managedhost1 -m service -a 'name=httpd state=started'<\/pre>\n
              \n
            • user<\/code> <\/strong>\u2013 Manipulate system users. Parameters name<\/code>.<\/li>\n<\/ul>\n
              Creating a user sam in the labservers group:<\/p>\n
              $ ansible labservers -i inventory -b -m user -a \"name=sam\"<\/pre>\n
              Adding user sam<\/em> to the wheel<\/em> group. Append parameter is needed due to we dont wan\u2019t to wipe out group file:<\/p>\n
              $ ansible labservers -b -m user -a \"name=sam append=yes groups=wheel\"<\/pre>\n
                \n
              • copy<\/code> <\/strong>\u2013 Copy files. Parameters src<\/code>.<\/li>\n<\/ul>\n
                $ ansible all -m copy -a \"src=\/home\/miro\/ansible\/testfile dest=\/tmp\/testfile\"<\/pre>\n
                Use the copy module to change content of a file:<\/p>\n
                $ ansible all -b -m copy -a 'content=\"Host managed by Ansible\\n\" dest=\/etc\/motd'<\/code><\/pre>\n
                  \n
                • file<\/code> <\/strong>\u2013 Work with files. Parameters path<\/code>.<\/li>\n<\/ul>\n
                  Creating a file on managed host in user directory:<\/span><\/div>\n
                  \n
                  $ ansible managedhost1\u00a0 -m file -a \"path=\/home\/miro\/newfile state=touch\"<\/pre>\n<\/div>\n
                  \n
                  Informations about the file:<\/p>\n
                  $ ansible managedhost1\u00a0 -m file -a \"path=\/home\/miro\/newfile\"<\/pre>\n
                  Changing properties of the file:<\/p>\n
                  $ ansible managedhost1 -m file -a \"path=\/home\/miro\/newfile mode=0400\"\r\n<\/pre>\n<\/div>\n
                    \n
                  • setup<\/strong> <\/code>\u2013 Gather ansible facts. No required parameters.\n
                    $ ansible managedhost1\u00a0 -b -m setup<\/pre>\n<\/li>\n
                  • debug<\/strong> <\/code>– prints statements during execution and can be useful for debugging variables or expressions without necessarily halting the playbook<\/li>\n<\/ul>\n
                    $ ansible managedhost1 -m debug -a \"var=vars\"<\/pre>\n
                      \n
                    • git<\/code> <\/strong>\u2013 Interact with git repositories. Parameters repo<\/code> and dest<\/code>.<\/li>\n<\/ul>\n<\/div>\n<\/article>\n
                      Note: if possible, try to avoid the command<\/code>, shell<\/code> and raw<\/code> modules in playbooks! It’s easy to write non-idempotent playbooks this way.<\/p>\n<\/div>\n
                      Documentation<\/span><\/h2>\n
                      Ansible module documentation and playbook snippets:<\/p>\n
                      $ ansible-doc -l\r\n$ ansible-doc -s module_name\r\n$ ansible-doc module_name\r\n<\/code><\/pre>\n
                      Ansible-playbook command<\/span><\/h2>\n
                      Ansible executes plays and tasks in the order they are presented! How to check for YAML syntax errors:<\/p>\n
                      $ ansible-playbook --syntax-check playbook.yaml\r\n<\/code><\/pre>\n
                      Limit playbook to specyfied host:<\/p>\n
                      $ ansible-playbook playbook.yaml -l managedhost1<\/pre>\n
                      Which host(s) the playbook applies to?<\/p>\n
                      $ ansible-playbook playbook.yaml --list-hosts\r\n<\/code><\/pre>\n
                      Whats tasks will be performed?<\/p>\n
                      $ ansible-playbook playbook.yaml --list-tasks\r\n<\/code><\/pre>\n
                      Run one task at a time:<\/p>\n
                      $ ansible-playbook playbook.yaml --step\r\n<\/code><\/pre>\n
                      Playbook dry-run:<\/p>\n
                      $ ansible-playbook -C playbook.yaml\r\n<\/code><\/pre>\n
                      Playbook step-by-step execution:<\/p>\n
                      $ ansible-playbook --step playbook.yaml\r\n<\/code><\/pre>\n
                      The beginning of each play begins with a single dash followed by a space.<\/p>\n
                      To only run the first task, the \u2013tags<\/code> argument can be used:<\/p>\n
                      $ ansible-playbook main.yml --tags 'production'<\/pre>\n
                      To skip tagged task:<\/p>\n
                      $ ansible-playbook main.yml --skip-tags 'production'<\/pre>\n
                       <\/p>\n
                      \u00a0<\/span>Playbook<\/span><\/p>\n
                      Playbook attributes:<\/p>\n
                        \n
                      • hosts<\/strong> <\/code>– hosts which are managed by ansible. Must be defined in every play.<\/li>\n
                      • user<\/code> <\/strong>– user which will run ansible playbook<\/li>\n
                      • remote_user<\/strong> <\/code>– can be used to define the user that runs the tasks.<\/li>\n
                      • become<\/strong> <\/code>– can be used to enable privilege escalation.<\/li>\n
                      • become_method<\/code> <\/strong>– can be used to define the privilege escalation method.<\/li>\n
                      • become_user<\/code> <\/strong>– can define the user account to be used for privilege escalation.<\/li>\n
                      • gether_facts<\/strong> <\/code>– to gether or not to gether the facts<\/li>\n
                      • tasks<\/strong> <\/code>– is defined as a list of dictionaries.<\/li>\n
                      • block<\/code> <\/strong>– can be used to group related tasks together.<\/li>\n
                      • name<\/code> <\/strong>– can be used to give a descriptive label to a play.<\/li>\n<\/ul>\n
                        Skeleton of simple playbook:<\/p>\n
                        ---\r\n- hosts: managedhost1\r\n  user: ansible\r\n  become: yes\r\n  #remote_user: ansible\r\n  #become_method: sudo\r\n  #become_user: root\r\n  #gether_facts: no\r\n  \r\n  vars_files: path_to_file\r\n  vars:\r\n    variable1: value1\r\n    variable2: value2\r\n\r\n  tasks:\r\n\r\n  - block:\r\n    - name: name of task1\r\n    - name: name of task2\r\n    - name: name of task3\r\n\r\n  - block:\r\n    - name: name of task4\r\n    - name: name of task5\r\n    - name: name of task6\r\n\r\n  - block:\r\n    - name: name of task7\r\n    - name: name of task8<\/pre>\n
                        Common modules:<\/p>\n
                          \n
                        • yum<\/strong> <\/code>– Installs, upgrade, downgrades, removes, and lists packages<\/li>\n
                        • yum_repository<\/strong><\/code> – Add or remove YUM repositories<\/li>\n
                        • service<\/strong> <\/code>– Controls services on remote hosts.<\/li>\n
                        • file <\/strong><\/code>– Set attributes of files, symlinks or directories.<\/li>\n
                        • copy<\/strong> <\/code>– copies a file from the local or remote machine to a location on the remote machine.<\/li>\n
                        • firewalld<\/strong> <\/code>– manages firewalld rules.<\/li>\n
                        • template<\/strong> <\/code>– tTemplates processed by the Jinja2 templating
                          \nlanguage.<\/li>\n
                        • lineinfile<\/code> <\/strong>– ensures a particular line is in a file, or replace
                          \nan existing line using a back-referenced regular expression.<\/li>\n
                        • blockinfile<\/code> <\/strong>– This module will insert\/update\/remove a block of multi-line text<\/li>\n
                        • replace<\/code> <\/strong>– replace all instances of a pattern within a file<\/li>\n
                        • command<\/code> <\/strong>– The given command will be executed on all selected nodes. The command(s) will not be processed through the shell, so variables like `$HOME’ and operations like `”<“‘, `”>”‘, `”|”‘, `”;”‘ and `”&”‘ will not work. Use the [shell] module if you need these features.<\/li>\n
                        • shell<\/strong> <\/code>– takes the command name followed by a list of space-delimited arguments.<\/li>\n
                        • debug<\/strong> <\/code>– prints statements during execution and can be useful for
                          \ndebugging variables or expressions<\/li>\n
                        • fetch<\/code> <\/strong>– Download a file from managed host.<\/li>\n
                        • get_url<\/strong> <\/code>– Downloads files from HTTP, HTTPS, or FTP to the remote server.<\/li>\n
                        • uri<\/strong> <\/code>– Interacts with HTTP and HTTPS web services<\/li>\n
                        • mysql_user<\/strong> <\/code>– Adds or removes a user from a MySQL database.<\/li>\n
                        • mysql_db<\/code><\/strong> – Add or remove MySQL databases from a remote host<\/li>\n
                        • cron<\/strong> <\/code>– manage crontab and environment variables entries.<\/li>\n
                        • at<\/strong> <\/code>– schedule a command or script file to run once in the future<\/li>\n
                        • selinux<\/strong> <\/code>– Configures the SELinux mode and policy<\/li>\n
                        • package_facts<\/code> <\/strong>– Return information about installed packages as facts<\/li>\n
                        • parted<\/strong><\/code> – Allows configuring block device partition using the `parted’ command line tool.<\/li>\n
                        • lvg<\/code> <\/strong>– create voulme group<\/li>\n
                        • lvol<\/code> <\/strong>– create logical volume<\/li>\n
                        • filesystem<\/code> <\/strong>– creates a filesystem.<\/li>\n
                        • mount<\/strong> <\/code>– controls active and configured mount points in `\/etc\/fstab’.<\/li>\n
                        • archive -<\/strong><\/code>Packs an archive. It is the opposite of [unarchive].<\/li>\n
                        • unarchive<\/code>–<\/strong> Unpacks an archive. It will not unpack a compressed file that does not contain an archive.<\/li>\n
                        • authorized_key<\/code><\/strong> – Adds or removes SSH authorized keys for particular user accounts.<\/code><\/li>\n
                        • add_host<\/code><\/strong> – create new hosts and groups in inventory<\/li>\n<\/ul>\n
                          For each play in a playbook, you get to choose which machines in your infrastructure to target and what remote user to complete the steps as. You can use keyword become<\/code> on a particular task instead of the play:<\/p>\n
                          ---\r\n- hosts: webservers\r\n  remote_user: ansible\r\n  serial: 2\r\n  tasks:\r\n    - service:\r\n        name: httpd\r\n        state: started\r\n      become: yes\r\n      become_method: sudo\r\n<\/code><\/pre>\n
                          Use the serial keyword to run the hosts through the play in batches. Host variables take precedence over group variables, but variables defined by a playbook take precedence over both.<\/p>\n
                          Including and Importing Files<\/span><\/h2>\n
                          When you include content, then Ansible processes included content during the run of the playbook, as content is required.<\/p>\n
                          When you import content, Ansible processes imported content when the playbook is initially read, before the run starts.<\/p>\n
                          Note that include<\/code> was replaced in Ansible 2.4 with new directives such as:<\/p>\n
                            \n
                          • vars_files<\/code><\/strong><\/li>\n
                          • include_vars<\/code><\/strong><\/li>\n
                          • include_tasks<\/code><\/strong><\/li>\n
                          • import_tasks<\/code> <\/strong><\/li>\n
                          • import_playbook<\/code><\/strong><\/li>\n<\/ul>\n
                            You can find documentation in ansible-doc<\/em> command.<\/p>\n
                            These can be used to enhance the ability to reuse tasks and playbooks:<\/p>\n
                            ---\r\nhosts: all\r\ntasks:\r\n  - name: Import task file and use variablesimport_playbook:\r\n    include_vars:  variables.yml\r\n    include_tasks: tasks1.yml\r\n    import_tasks:  tasks2.yml\r\n\r\n- name: Include a play after another play\r\n  import_playbook: otherplays.yml\r\n<\/code><\/pre>\n
                            Examples:<\/p>\n
                            tasks:\r\n  - name: Import task file and use variables\r\n    import_tasks: task.yml\r\n    vars:\r\n      package: vsftpd\r\n      service: vsft\r\n\r\n  - name: Install the {{ package }} package\r\n    yum:\r\n      name: \"{{ package }}\"\r\n      state: latest\r\n  - name: Start the {{ service }} service\r\n    service:\r\n      name: \"{{ service }}\"\r\n      enabled: true\r\n      state: started\r\n<\/code><\/pre>\n
                            <\/h2>\n
                            Ansible Variables<\/span><\/h2>\n
                            Places to define variables:<\/p>\n
                              \n
                            • vars<\/code>, include_vars<\/code><\/li>\n
                            • Command line (-e<\/code> ) as key=value:<\/li>\n<\/ul>\n
                              $ ansible-playbook play.yml -e 'key=value'<\/pre>\n
                              or YAML\/JSON<\/p>\n
                              $ ansible-playbook play.yml -e '{\"myVar\":\"myValue\",\"anotherVar\":\"anotherValue\"}'<\/pre>\n
                              if filename prepend with @<\/p>\n
                              $ ansible-playbook pla.yml -e \"@filename\"<\/pre>\n
                                \n
                              • Variables for hosts and host groups can be defined by creating two directories, group_vars<\/code> <\/strong>and host_vars<\/code><\/strong>, in the same working directory as the inventory file or directory.<\/li>\n<\/ul>\n
                                If the value to define varies for each datacenter, a group variable can be set for each datacenter:<\/p>\n
                                [admin@station project]$ cat ~\/project\/group_vars\/datacenter1\r\npackage: httpd\r\n[admin@station project]$ cat ~\/project\/group_vars\/datacenter2\r\npackage: apache<\/pre>\n
                                If the value to be defined varies for each host in every datacenter, using host variables is recommended:
                                \nShell<\/p>\n
                                [admin@station project]$ cat ~\/project\/host_vars\/demo1.example.com\r\npackage: httpd\r\n[admin@station project]$ cat ~\/project\/host_vars\/demo2.example.com\r\npackage: apache\r\n[admin@station project]$ cat ~\/project\/host_vars\/demo3.example.com\r\npackage: mariadb-server\r\n[admin@station project]$ cat ~\/project\/host_vars\/demo4.example.com\r\npackage: mysql-server<\/pre>\n
                                The directory structure for project, if it contained all of the example files above, might look like this:<\/p>\n
                                project\r\n\u251c\u2500\u2500 ansible.cfg\r\n\u251c\u2500\u2500 group_vars\r\n\u2502 \u251c\u2500\u2500 datacenters\r\n\u2502 \u251c\u2500\u2500 datacenters1\r\n\u2502 \u2514\u2500\u2500 datacenters2\r\n\u251c\u2500\u2500 host_vars\r\n\u2502 \u251c\u2500\u2500 demo1.example.com\r\n\u2502 \u251c\u2500\u2500 demo2.example.com\r\n\u2502 \u251c\u2500\u2500 demo3.example.com\r\n\u2502 \u2514\u2500\u2500 demo4.example.com\r\n\u251c\u2500\u2500 inventory\r\n\u2514\u2500\u2500 playbook.yml<\/pre>\n
                                  \n
                                • Roles, blocks, and inventories<\/li>\n<\/ul>\n
                                  Whether or not you define any variables, you can access information about your hosts with the Special Variables Ansible provides, including “magic” variables, facts, and connection variables.<\/p>\n
                                  The most commonly used magic variables are:<\/p>\n
                                    \n
                                  • hostvars <\/strong><\/code><\/li>\n
                                  • groups <\/strong><\/code><\/li>\n
                                  • group_names <\/strong><\/code><\/li>\n
                                  • inventory_hostname<\/strong><\/code><\/li>\n<\/ul>\n
                                    Prints all magic variables:<\/p>\n
                                    $ ansible localhost -m debug -a \"var=vars\"<\/pre>\n
                                    $ ansible localhost -m debug -a \"var=hostvars\"<\/pre>\n
                                    The group_names<\/code> <\/strong>variable contains a list of all the groups the current host is in. We can use it to install specific packages:<\/p>\n
                                    tasks:\r\n  - name: Install webserver packages\r\n    package:\r\n      name: \"{{ item }}\"\r\n      state: latest\r\n    loop:\r\n      - httpd\r\n      - firewalld\r\n    when: \"'webserver' in group_names\"\r\n<\/code><\/pre>\n
                                    The hostvars<\/code> <\/strong>variable lets you access variables for another host, including facts that have been gathered about that host.<\/p>\n
                                    {{ hostvars['managedhost1.example.com']['ansible_default_ipv4']['address'] }}\r\n{{ hostvars['managedhost1.example.com']['ansible_fqdn'] }}\r\n<\/code><\/pre>\n
                                    The inventory_hostname<\/code> <\/strong>variable is the name of the hostname as configured in Ansible’s inventory host file. The groups variable is a list of all the groups in the inventory.<\/p>\n
                                    when: inventory_hostname in groups[\"webservers\"]\r\nwhen: inventory_hostname in groups.webservers<\/code><\/pre>\n
                                    <\/h2>\n
                                    Ansible Facts<\/span><\/h2>\n
                                    How to print facts for all hosts?<\/p>\n
                                    - name: Ansible fact dump\r\n  hosts: all\r\n  tasks:\r\n    - name: Print all Ansible facts\r\n      debug:\r\n        var: ansible_facts\r\n<\/code><\/pre>\n
                                    - name: Ansible package fact dump\r\n  hosts: all\r\n  tasks:\r\n    - name: Gather package facts\r\n      package_facts:\r\n        manager: auto\r\n<\/code><\/pre>\n
                                    Before Ansible 2.5, facts were injected as individual variables prefixed with the string ansible_<\/code> instead of being part of the ansible_facts<\/code> variable.<\/p>\n
                                    At the time of writing this, Ansible recognises both the new fact naming system (using ansible_facts<\/code>) and the old pre 2.5 naming system where facts are injected as separate variables.<\/p>\n
                                    You can use an ad-hoc command to run the setup module to print the value of all facts:<\/p>\n
                                    $ ansible localhost -m setup\r\n<\/code><\/pre>\n
                                    or<\/p>\n
                                    $ ansible localhost -m gather_facts<\/pre>\n
                                    Filter results:<\/p>\n
                                    $ ansible localhost -m setup -a 'filter=*distribution*'\r\n<\/code><\/pre>\n
                                    Some commonly used facts. In no particular order:<\/p>\n
                                    ansible_facts['hostname'] = ansible_hostname\r\nansible_facts['fqdn'] = ansible_fqdn\r\nansible_facts['default_ipv4']['address'] = ansible_default_ipv4.address\r\nansible_facts['distribution'] = ansible_distribution\r\nansible_facts['distribution_major_version'] = ansible_major_version\r\nansible_facts['domain'] = ansible_domain\r\nansible_facts['memtotal_mb'] = ansible_memtotal_mb\r\nansible_facts['processor_count'] = ansible_processor_count\r\n<\/code><\/pre>\n
                                    To disable fact gathering for a play, you can set the gather_facts<\/code> keyword to “no”:<\/p>\n
                                    gather_facts: no\r\n<\/code><\/pre>\n
                                     <\/p>\n
                                    Custom facts<\/strong> can be defined in a static file, formatted as an INI<\/strong> file or using JSON and placed in \/etc\/ansible\/facts.d<\/code> and the file name must end in .fact<\/code>.<\/p>\n
                                    They can also be executable scripts which generate JSON output, just like a dynamic inventory script. Note that custom fact files cannot be in YAML format!<\/p>\n
                                    Creating custom facts on managedhost1:<\/p>\n
                                    [miro@managedhost1 ~]$ sudo mkdir -p \/etc\/ansible\/facts.d\r\n[miro@managedhost1 ~]$ sudo vim \/etc\/ansible\/facts.d\/prefs.fact\r\n[miro@managedhost1 ~]$ cat \/etc\/ansible\/facts.d\/prefs.fact\r\n[location]\r\ntype=physical\r\ndatacenter=Katowice\r\n<\/pre>\n
                                    On the controlnode we can print local facts from the managedhost1:<\/p>\n
                                    [miro@controlnode ansible]$ ansible managedhost1 -m setup -a \"filter=ansible_local\"\r\nmanagedhost1 | SUCCESS => {\r\n\"ansible_facts\": {\r\n\"ansible_local\": {\r\n\"prefs\": {\r\n\"location\": {\r\n\"datacenter\": \"Katowice\",\r\n\"type\": \"physical\"\r\n}\r\n}\r\n}\r\n},\r\n\"changed\": false\r\n}<\/pre>\n
                                    <\/h2>\n
                                    Ansible Loops, Conditionals
                                    \n<\/span><\/h2>\n
                                    Ansible supports iterating a task over a set of items using the loop<\/code> keyword. A simple loop iterates a task over a list of items.<\/p>\n
                                    Since Ansible 2.5, the recommended way to write loops is to use the loop<\/code> keyword. The old syntax used loops prefixed with with_<\/code>.<\/p>\n
                                    - name: Ensure that packages are present\r\n  package:\r\n    name: \"{{ item }}\"\r\n    state: present\r\n  loop:\r\n    - firewalld\r\n    - httpd\r\n    - vsftpd\r\n<\/code><\/pre>\n
                                    - name: Ensure that web server ports are open\r\n  vars:\r\n    packages:\r\n    - http\r\n    - https\r\n  firewalld:\r\n    service: \"{{ item }}\"\r\n    immediate: true\r\n    permanent: true\r\n    state: enabled\r\n  loop:\r\n    \"{{ packages }}\"\r\n   \r\n<\/code><\/pre>\n
                                    Ansible conditionals operators<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
                                    Operator<\/strong><\/em><\/td>\nExample<\/strong><\/em><\/td>\n<\/tr>\n
                                    Equal<\/td>\n\u00a0\"{{ max_memory }} == 512\"<\/code><\/td>\n<\/tr>\n
                                    Less than<\/td>\n\u00a0\"{{ min_memory }} < 128\"<\/code><\/td>\n<\/tr>\n
                                    Greater than<\/td>\n\"{{ min_memory }} > 256\"<\/code><\/td>\n<\/tr>\n
                                    Less than or equal to<\/td>\n\u00a0\"{{ min_memory }} <= 256\"<\/code><\/td>\n<\/tr>\n
                                    Greater than or equal to<\/td>\n\u00a0\"{{ min_memory }} >= 512\"<\/code><\/td>\n<\/tr>\n
                                    Not equal to<\/td>\n\u00a0\"{{ min_memory }} != 512\"<\/code><\/td>\n<\/tr>\n
                                    Variable exists<\/td>\n\"{{ min_memory }} is defined\"<\/code><\/td>\n<\/tr>\n
                                    Variable does not exist<\/td>\n\u00a0\"{{ min_memory }} is not defined\"<\/code><\/td>\n<\/tr>\n
                                    Variable is set to 1, True, or yes<\/td>\n\u00a0\"{{ available_memory }}\"<\/code><\/td>\n<\/tr>\n
                                    Variable is set to 0, False, or no<\/td>\n\u00a0\"not {{ available_memory }}\"<\/code><\/td>\n<\/tr>\n
                                    Value is present in a variable or an array<\/td>\n\"{{ users }} in<\/code>
                                    \nusers[\"db_admins\"]\"<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
                                    Logical AND and OR operations are supported:<\/p>\n
                                    when: ansible_domain == \"example.com\" and ansible_distribution == \"RedHat\"\r\nwhen: ansible_processor_cores == \"1\" or ansible_processor_cores == \"2\"\r\n<\/code><\/pre>\n
                                    Loops and conditionals can be combined:<\/p>\n
                                    - name: Ensure that packages are present on RedHat\r\n  package:\r\n    name: \"{{ item }}\"\r\n    state: present\r\n  loop:\r\n    - firewalld\r\n    - httpd\r\n  when: ansible_distribution == \"RedHat\"\r\n<\/code><\/pre>\n
                                    <\/h2>\n
                                    Lookups<\/span><\/h2>\n
                                    Lookup plugins allow access to outside data sources. Lookups occur on the local computer, not on the remote computer. One way of using lookups is to populate variables:<\/p>\n
                                    vars:\r\n  motd_value: \"{{ lookup('file', '\/etc\/motd') }}\"\r\ntasks:\r\n  - debug:\r\n      msg: \"motd value is {{ motd_value }}\"\r\n<\/code><\/pre>\n
                                    <\/h2>\n
                                    Ansible Handlers<\/span><\/h2>\n
                                    Handlers always run in the order specified by the handlers section of the play. A handler called by a task in the tasks part of the playbook will not run until all of the tasks under tasks have been processed.<\/p>\n
                                    notify: restart httpd service\r\n\r\nhandlers:\r\n  - name: restart httpd service\r\n    service:\r\n      name: httpd\r\n      state: restarted\r\n<\/code><\/pre>\n
                                    If a task fails and the play aborts on that host, any handlers that had been notified by earlier tasks in the play will not run. Use the following to force execution of the handler:<\/p>\n
                                    force_handlers: yes\r\n<\/code><\/pre>\n
                                    Handlers are notified when a task reports a “changed” result. Handlers are not notified when it reports an “ok” or “failed” result.<\/p>\n
                                    Ignore errors:<\/p>\n
                                    ignore_errors: yes\r\n<\/code><\/pre>\n
                                    <\/h2>\n
                                    Commonly Used Files Modules with Examples<\/span><\/h2>\n
                                    The file module acts like chcon<\/code> when setting file contexts:<\/p>\n
                                    - name: Create a file\r\n  hosts: localhost\r\n  become: true\r\n  tasks:\r\n    - name: Create a file and set permissions\r\n      file:\r\n        path: \/root\/file\r\n        owner: root\r\n        group: root\r\n        mode: 0640\r\n        state: touch\r\n        setype: user_tmp_t\r\n    - name: SELinux type is persistently set to user_tmp_t\r\n      sefcontext:\r\n        target: \/root\/file\r\n        setype: user_tmp_t\r\n        state: present\r\n<\/code><\/pre>\n
                                    - name: Copy a file\r\n  hosts: localhost\r\n  become: true\r\n  tasks:\r\n    - name: Copy a file\r\n      copy:\r\n        src: file\r\n        dest: \/root\/file\r\n        force: yes\r\n        owner: root\r\n        group: ansible\r\n        mode: 0640\r\n<\/code><\/pre>\n
                                    - name: Add a line to a file\r\n  hosts: localhost\r\n  become: true\r\n  tasks:\r\n    - name: Add a new line to a file\r\n      lineinfile:\r\n        path: \/root\/file\r\n        line: \"this is the new line\"\r\n        state: present\r\n<\/code><\/pre>\n
                                    - name: Add block of text to a file\r\n  hosts: localhost\r\n  become: true\r\n  tasks:\r\n    - name: Add a block of text to an existing file\r\n      blockinfile:\r\n        path: \/root\/file\r\n        block: |\r\n          This is the first line to be added.\r\n          This is the second line to be added.\r\n        state: present\r\n<\/code><\/pre>\n
                                    - name: Download a file from managed hosts\r\n  hosts: localhost\r\n  become: false\r\n  tasks:\r\n    - name: Fetch a file\r\n      fetch:\r\n        src: \/etc\/hosts\r\n        dest: my-folder\r\n        flat: no\r\n<\/code><\/pre>\n
                                    - name: Download a file from remote host\r\n  hosts: localhost\r\n  become: false\r\n    - name: Download file from URL\r\n      get_url:\r\n        url: http:\/\/katello.hl.local\/pub\/index.html\r\n        dest: \/tmp\/index.html\r\n<\/code><\/pre>\n
                                    - name: Disable SSH root login\r\n  hosts: localhost\r\n  become: true\r\n  tasks:\r\n  - name: Modify SSH server config\r\n    lineinfile:\r\n      dest: \"\/etc\/ssh\/sshd_config\"\r\n      regexp: \"^PermitRootLogin\"\r\n      line: \"PermitRootLogin no\"\r\n<\/code><\/pre>\n
                                    <\/h2>\n
                                    Jinja2 Templates<\/span><\/h2>\n
                                    Similar to Puppet. Puppet templates are based upon Ruby’s ERB, Ansible templates are based upon Jinja2.<\/p>\n
                                    A file containing a Jinja2 template does not need to have any specific file extension.<\/p>\n
                                    Use the template module to deploy it:<\/p>\n
                                    - name: Use a template file\r\n  hosts: localhost\r\n  gather_facts: yes\r\n  tasks:\r\n    - name: Deploy index.html\r\n      template:\r\n        src: templates\/index.j2\r\n        dest: \/var\/www\/html\/index.html\r\n<\/code><\/pre>\n
                                    $ cat templates\/index.j2\r\nThe system kernel is: {{ ansible_kernel }}\r\n<\/code><\/pre>\n
                                    <\/h2>\n
                                    Roles<\/span><\/h2>\n
                                    Similar to Puppet modules, reusable code in a modular fashion. Create a role skeleton:<\/p>\n
                                    $ mkdir roles && cd roles\r\n$ ansible-galaxy init my_role\r\n<\/pre>\n
                                    $ tree my_role\/\r\nmy_role\/\r\n\u251c\u2500\u2500 defaults\r\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 main.yml\r\n\u251c\u2500\u2500 files\r\n\u251c\u2500\u2500 handlers\r\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 main.yml\r\n\u251c\u2500\u2500 meta\r\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 main.yml\r\n\u251c\u2500\u2500 README.md\r\n\u251c\u2500\u2500 tasks\r\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 main.yml\r\n\u251c\u2500\u2500 templates\r\n\u251c\u2500\u2500 tests\r\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 inventory\r\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 test.yml\r\n\u2514\u2500\u2500 vars\r\n    \u2514\u2500\u2500 main.yml\r\n<\/pre>\n
                                    The original way to use roles is via the roles:<\/code> option for a play:<\/p>\n
                                    ---\r\n- name name of a task \r\n  hosts: webservers\r\n  roles:\r\n     - webservers<\/code><\/pre>\n
                                    Changing a role\u2019s behavior with variables:<\/p>\n
                                    ---\r\n- name name of a task <\/code> hosts: webservers roles: - role: webservers variable: value<\/pre>\n
                                    As of Ansible 2.4, you can use roles inline with any other tasks using import_role<\/code> or include_role<\/code>:<\/p>\n
                                    ---\r\n- hosts: webservers\r\n  tasks:\r\n  - debug:\r\n      msg: \"before we run our role\"\r\n  - import_role:\r\n      name: example\r\n  - include_role:\r\n      name: example\r\n  - debug:\r\n      msg: \"after we ran our role\"\r\n<\/code><\/pre>\n
                                    The order of execution for your playbook is as follows:<\/p>\n
                                      \n
                                    1. Any pre_tasks<\/code> defined in the play.<\/li>\n
                                    2. Any handlers triggered so far will be run.<\/li>\n
                                    3. Each role listed in roles will execute in turn (with dependencies).<\/li>\n
                                    4. Any tasks defined in the play.<\/li>\n
                                    5. Any handlers triggered so far will be run.<\/li>\n
                                    6. Any post_tasks<\/code> defined in the play.<\/li>\n
                                    7. Any handlers triggered so far will be run.<\/li>\n<\/ol>\n
                                      ---\r\n- hosts: remote.example.com\r\n  \r\n  pre_tasks:\r\n  - debug:\r\n    msg: 'hello'\r\n  \r\n  roles:\r\n  - role1\r\n  - role2\r\n  \r\n  tasks:\r\n  - debug:\r\n    msg: 'still busy'\r\n  \r\n  post_tasks:\r\n  - debug:\r\n    msg: 'goodbye'<\/pre>\n
                                      Role dependencies are always executed before the role that includes them, and may be recursive.<\/p>\n
                                      Search for roles from the CLI:<\/p>\n
                                      $ ansible-galaxy search --author redhat\r\n$ ansible-galaxy search --galaxy-tags tomcat\r\n$ ansible-galaxy search tomcat --platforms EL\r\n<\/code><\/pre>\n
                                      Ansible Galaxy is a public library of Ansible roles written by users. Similar to Puppet Forge. Install a role from Galaxy:<\/p>\n
                                      $ ansible-galaxy install <author.name> -p ~\/.ansible\/roles\r\n<\/code><\/pre>\n
                                      List installed roles:<\/p>\n
                                      $ ansible-galaxy list -p ~\/.ansible\/roles\/\r\n- <author.name>, 1.9.5\r\n<\/code><\/pre>\n
                                      To define role source, use requirements.yml<\/code>:<\/p>\n
                                      - src: http:\/\/katello.hl.local\/pub\/ansible-haproxy.tar.gz\r\n  name: haproxy\r\n- src: http:\/\/katello.hl.local\/pub\/ansible-mysql.tar.gz\r\n  name: mysql\r\n<\/code><\/pre>\n
                                      $ ansible-galaxy init -r requirements.yml\r\n<\/code><\/pre>\n
                                       <\/p>\n
                                      RHEL System Roles<\/span><\/h3>\n
                                      $ sudo yum install rhel-system-roles\r\n$ ls \/usr\/share\/doc\/rhel-system-roles-1.0\/\r\nkdump\r\nnetwork\r\npostfix\r\nselinux\r\ntimesync\r\n<\/code><\/pre>\n
                                      $ ansible-galaxy list\r\n- rhel-system-roles.selinux, (unknown version)\r\n- linux-system-roles.network, (unknown version)\r\n- rhel-system-roles.postfix, (unknown version)\r\n- rhel-system-roles.timesync, (unknown version)\r\n- rhel-system-roles.kdump, (unknown version)\r\n- linux-system-roles.timesync, (unknown version)\r\n- linux-system-roles.kdump, (unknown version)\r\n- linux-system-roles.postfix, (unknown version)\r\n- rhel-system-roles.network, (unknown version)\r\n- linux-system-roles.selinux, (unknown version)\r\n<\/code><\/pre>\n
                                      Password Hashing<\/span><\/h2>\n
                                      How to generate SHA512 crypted passwords for the user module? The answer is taken from Ansible FAQ.<\/p>\n
                                      - name: Create user with password\r\n    user:\r\n      name: sandy\r\n      password: \"{{ user_pw | password_hash('sha512') }}\"\r\n<\/code><\/pre>\n
                                      <\/h2>\n
                                      meta – Execute Ansible Actions<\/span><\/h2>\n
                                      Meta tasks are a special kind of task which can influence Ansible internal execution or state. Choices:<\/p>\n
                                      * flush_handlers\r\n* refresh_inventory\r\n* noop\r\n* clear_facts\r\n* clear_host_errors\r\n* end_play\r\n* reset_connection\r\n<\/code><\/pre>\n
                                      Example meta task for how to run handlers after an error occurred:<\/p>\n
                                       tasks:\r\n   - name: Attempt and graceful roll back demo\r\n     block:\r\n       - debug:\r\n           msg: 'I execute normally'\r\n         notify: run me even after an error\r\n       - command: \/bin\/false\r\n     rescue:\r\n       - name: make sure all handlers run\r\n         meta: flush_handlers\r\n handlers:\r\n    - name: run me even after an error\r\n      debug:\r\n        msg: 'This handler runs even on error'\r\n<\/code><\/pre>\n
                                      Note that meta is not really a module as such it cannot be overwritten.<\/p>\n
                                      <\/h2>\n
                                      Ansible Check Mode (Dry Run)<\/span><\/h2>\n
                                      When ansible-playbook<\/code> is executed with --check<\/code> or -C<\/code> it will not make any changes on remote systems. To modify the check mode behavior of individual tasks, you can use the check_mode option:<\/p>\n
                                      - name: this task will run under checkmode and not change the system\r\n  lineinfile:\r\n    line: \"PermitRootLogin no\"\r\n    dest: \/etc\/ssh\/sshd_config\r\n    state: present\r\n  check_mode: yes\r\n<\/code><\/pre>\n
                                      The above will force a task to run in check mode, even when the playbook is called without --check<\/code>.<\/p>\n
                                      <\/h2>\n
                                      Ansible Playbook Debugger<\/span><\/h2>\n
                                      Ansible includes a debugger as part of the strategy plugins. This debugger enables you to debug as task.<\/p>\n
                                      The debugger keyword can be used on any block where you provide a name attribute, such as a play, role, block or task.<\/p>\n
                                      ---\r\n- hosts: ansible2.hl.local\r\n  tasks:\r\n    - unarchive:\r\n        src: files\/archive.tgz\r\n        dest: \/tmp\/\r\n        remote_src: no\r\n    - name: archive file\r\n      debugger: on_failed\r\n      archive:\r\n        path: \/tmp\/archive.html\r\n        dest: \/tmp\/file.gz\r\n        format: tgz\r\n<\/code><\/pre>\n
                                      <\/h2>\n
                                      Ansible Ignoring Failed Commands<\/span><\/h2>\n
                                      Playbooks will stop executing any more steps on a host that has a task fail. To ignore this behaviour, set ignore_errors<\/code> to true<\/code>:<\/p>\n
                                      - name: this will not be counted as a failure\r\n  command: \/bin\/false\r\n  ignore_errors: yes\r\n<\/code><\/pre>\n
                                      This is useful when you expect a task to fail. For example, you are checking if Apache website is reachable. It may be unreachable, but you don’t want the play to fail because of that.<\/p>\n
                                      <\/h2>\n
                                      Ansible Run Once<\/span><\/h2>\n
                                      There may be a need to only run a task one time for a batch of hosts. This can be achieved by configuring run_once<\/code> on a task:<\/p>\n
                                      - command: \/tmp\/upgrade_database.sh\r\n  run_once: true\r\n<\/code><\/pre>\n
                                      Ansible Aborting the Play<\/span><\/h2>\n
                                      There will be cases when you will need to abort the entire play on failure, not just skip remaining tasks for a host, to avoid breaking the system. The any_errors_fatal<\/code> play option will mark all hosts as failed if any fails, causing an immediate abort:<\/p>\n
                                      - hosts: all\r\n  any_errors_fatal: true\r\n  roles:\r\n    - database\r\n<\/code><\/pre>\n
                                      <\/h2>\n
                                      Ansible Keywords<\/span><\/h2>\n
                                      These are some of the keywords available on common playbook objects.<\/p>\n
                                      Notable play keywords:<\/p>\n
                                      any_errors_fatal\r\nbecome\r\nbecome_method\r\nbecome_user\r\ncheck_mode\r\ndebugger\r\nforce_handlers\r\ngather_facts\r\nhandlers\r\nhosts\r\nignore_errors\r\nname\r\nno_log\r\norder\r\nport\r\npost_tasks\r\npre_tasks\r\nremote_user\r\nroles\r\nrun_once\r\nserial\r\ntasks\r\nvars\r\nvars_files\r\n<\/code><\/pre>\n
                                      Notable block keywords:<\/p>\n
                                      always\r\nblock\r\nrescue\r\nwhen\r\n<\/code><\/pre>\n
                                      Notable task keywords:<\/p>\n
                                      loop\r\nregister\r\n<\/code><\/pre>\n
                                      <\/h2>\n
                                      Ansible Setting Defaults for Modules<\/span><\/h2>\n
                                      It can be useful to define default arguments for a particular module using the module_defaults<\/code> attribute:<\/p>\n
                                      - hosts: all\r\n  become: true\r\n  module_defaults:\r\n    file:\r\n      owner: root\r\n      group: devops\r\n      mode: \"664\"\r\n      state: touch\r\n  tasks:\r\n    - file:\r\n        path: \/tmp\/file1\r\n    - file:\r\n        path: \/tmp\/file2\r\n    - file:\r\n        path: \/tmp\/file3\r\n<\/code><\/pre>\n
                                      It is a time saver when you need to use the same module repeatedly.<\/p>\n
                                      <\/h2>\n
                                      Ansible Vault<\/span><\/h2>\n
                                      $ ansible-vault [create|decrypt|edit|encrypt|rekey|view] vaultfile.yml\r\n<\/code><\/pre>\n
                                      By default, Ansible uses functions from the python-crypto<\/code> package to encrypt and decrypt vault files. To speed up decryption at startup, you install the python-cryptography<\/code> package.<\/p>\n
                                      $ ansible-vault create vaultfile.yml\r\n$ ansible-vault view vaultfile.yml\r\n<\/code><\/pre>\n
                                      Check syntax of a playbook that uses the vault file:<\/p>\n
                                      $ ansible-playbook --syntax-check --ask-vault-pass playbook.yml\r\n<\/code><\/pre>\n
                                      Create a password file to use for the playbook execution:<\/p>\n
                                      $ echo \"ansible\" > key\r\n$ ansible-playbook --syntax-check --vault-password-file=key playbook.yml<\/pre>\n
                                      \n
                                      \n
                                       <\/p>\n
                                      \n
                                      \n
                                      \n
                                      \n
                                      \n
                                      Ansible Best Practices<\/span><\/h2>\n
                                      Tips for making the most of Ansible and Ansible playbooks.<\/p>\n
                                        \n
                                      1. Always mention the state. The state<\/code> parameter is optional to a lot of modules. Whether state=present<\/code> or state=absent<\/code>, it is always best to leave that parameter in your playbooks to make it clear.<\/li>\n
                                      2. Generous use of whitespace to break things up, and use of comments, which start with #<\/code>, is encouraged.<\/li>\n
                                      3. Always name tasks. It is recommended to provide a description about why something is being done!<\/li>\n
                                      4. Keep it simple. Do not attemtp to use every feature of Ansible together, all at once. Use what works for you!<\/li>\n
                                      5. Ansible best practice has no limit on the amount of variable and vault files or their names.<\/li>\n<\/ol>\n<\/article>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
                                        Ansible and Vim<\/span><\/h2>\n
                                        When writing playbooks in vim editor, modify its action in response to Tab key entries. Add the following line to $HOME\/.vimrc<\/code>. It will perform a two space indentation when the Tab key is pressed.<\/p>\n
                                        autocmd FileType yaml setlocal ai ts=2 sw=2 et \r\n<\/code><\/pre>\n
                                        Settings explained:<\/p>\n
                                        ai   - autoindent (turns it on)\r\nsw=2 - shiftwidth (indenting is 2 spaces)\r\net   - expandtab (do not use actual tab character)\r\nts=2 - tabstop (tabs are at proper location)\r\n<\/code><\/pre>\n
                                        Two other helpful but optional vim settings:<\/p>\n
                                        nu (show line number)\r\ncursorline (line to show current cursor position)\r\n<\/code><\/pre>\n
                                        <\/h2>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
                                         <\/p>\n","protected":false},"author":1,"featured_media":3730,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[86],"tags":[],"_links":{"self":[{"href":"http:\/\/miro.borodziuk.eu\/index.php\/wp-json\/wp\/v2\/posts\/3701"}],"collection":[{"href":"http:\/\/miro.borodziuk.eu\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/miro.borodziuk.eu\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/miro.borodziuk.eu\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/miro.borodziuk.eu\/index.php\/wp-json\/wp\/v2\/comments?post=3701"}],"version-history":[{"count":64,"href":"http:\/\/miro.borodziuk.eu\/index.php\/wp-json\/wp\/v2\/posts\/3701\/revisions"}],"predecessor-version":[{"id":3806,"href":"http:\/\/miro.borodziuk.eu\/index.php\/wp-json\/wp\/v2\/posts\/3701\/revisions\/3806"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/miro.borodziuk.eu\/index.php\/wp-json\/wp\/v2\/media\/3730"}],"wp:attachment":[{"href":"http:\/\/miro.borodziuk.eu\/index.php\/wp-json\/wp\/v2\/media?parent=3701"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/miro.borodziuk.eu\/index.php\/wp-json\/wp\/v2\/categories?post=3701"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/miro.borodziuk.eu\/index.php\/wp-json\/wp\/v2\/tags?post=3701"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}