In comparison with ad-hoc commands, playbooks are used in complex scenarios, and they offer increased flexibility. Playbooks use YAML format, so there is not much syntax needed, but indentation must be respected. Ansible playbooks tend to be more of a configuration language than a programming language.<\/p>\n
<\/p>\n
Like the name is saying, a playbook is a collection of plays. Through a playbook, you can designate specific roles to some of the hosts and other roles to other hosts. By doing so, you can orchestrate multiple servers in very diverse scenarios, all in one playbook.<\/p>\n
<\/p>\n
Blocks<\/span> <\/p>\n <\/p>\n Multiple plays<\/span> The following example shows the format for creating a simple playbook with multiple plays.<\/p>\n <\/p>\n <\/p>\n To have all the details precise before continuing with examples, we must first define a task. These are the interface to ansible modules for roles and playbooks.<\/p>\n One playbook with one play, containing multiple tasks looks like this.<\/p>\n Explanation:<\/p>\n The ordering of the contents within a playbook is important, because Ansible executes plays and tasks in the order they are presented.<\/p>\n Each ansible playbook works with an inventory file. The inventory file contains a list of servers divided into groups for better control for details like IP address and SSH port for each host.<\/p>\n The inventory file you can use for this example looks like below. There are two groups, named group1 and group2 each containing host1 and host2 respectively.<\/p>\n <\/p>\n Another useful example of an Ansible playbook containing this time two plays for two hosts is the next one. For the first group of hosts, group1, selinux will be enabled. If it is enabled, then a message will appear on the screen of the host.<\/p>\n For the second group of hosts, httpd package will be installed only if the ansible_os_family is RedHat and ansible_system_vendor is HP.<\/p>\n Explanation:<\/p>\n Example of the when clause, In this case, when OS type is Debian. The <\/p>\n Besides tasks, there are also some particular tasks called handlers. Handlers must have a unique name throughout the playbook. These work in the same way as a regular task but a handler can be notified via a notifier.<\/p>\n If a handler is not notified during the run of the playbook, it will not run. However, if more than one task notifies a handler, this will run only once after all the tasks are finished.<\/p>\n In the example shown below, you can see how a specific task has a notify section which calls upon another task. If the output of the first task is changed, then a handler task will be called. The best example is to have a configuration file changed and afterward restart that specific service.<\/p>\n In this case, if the first task, <\/p>\n Running playbooks Basic Playbook Syntax The playbook will install apache in the newest version.<\/p>\n Modification playbook to start and enable Adding We can limit running playbook only on one host. It is usefull when you engineering playbooks.<\/p>\n Let’s check if our playbook works:<\/p>\n <\/p>\n Use Variables to Retrieve the Results of Running Commands<\/span><\/p>\n Example<\/p>\n <\/p>\n Let’s write uid of output to the file:<\/p>\n <\/p>\n Executing a dry run<\/span> <\/p>\n Step-by-step execution<\/span> <\/p>\n Idempotency<\/span><\/p>\n When possible, try to avoid the A number of things could be done to use the shell module in an idempotent way, and sometimes making those changes and using shell is the best approach. But a quicker solution may be to use The copy module is special-purpose and can easily test to see if the state has already been met, and if it has will make no changes. The shell module allows a lot of flexibility, but also requires more attention to ensure that it runs in an idempotent way. Idempotent playbooks can be run repeatedly to ensure systems are in a particular state without disrupting those systems if they already are.<\/p>\n <\/p>\n Example 1.<\/span><\/p>\n This demonstration illustrates the creation and use of Ansible playbooks. The demonstration will be conducted out of the \/home\/student\/imp-playdemo directory on workstation using the supplied configuration file, inventory, and playbooks. It is assumed that workstation is the control node, and that servera.lab.example.com is a managed host. The control node 1. Log in as the student user on workstation. Change directory to the working directory and review the contents of the directory.<\/p>\n 2. Review the \/home\/student\/imp-playdemo\/ftpclient.yml playbook. It ensures that the latest version of the lftp package is installed on the local managed host. This operation will require escalated privileges, so the playbook enables privilege escalation using sudo and the root user. The connection to the managed host is made with the devops user.<\/p>\n … 4. Execute the \/home\/student\/imp-playdemo\/ftpclient.yml playbook.<\/p>\n <\/p>\n <\/p>\n Example 2.<\/span><\/p>\n A developer has asked you to configure Ansible to automate the setup of web servers for your company’s intranet web site. The developer is using the host Construct a playbook on the control node, workstation, called \/home\/student\/impplaybook\/intranet.yml. Create a play in this playbook that configures the managed host as requested by the developer. Also include a task to create the The playbook should also contain another play which performs a test from the control node to ensure that the web server is accessible across the network. This play should be comprised of a task which makes an HTTP request to Final playbook <\/p>\n Example.<\/p>\n A developer responsible for the company’s Internet website has asked you to write an Ansible playbook to automate the setup of his server environment on serverb.lab.example.com. A working directory, \/home\/student\/imp-lab, has been created on workstation for the purpose of managing the managed node, serverb. The directory has already been populated with an ansible.cfg configuration file and an inventory inventory file. The managed host, serverb, is already defined in this inventory file. The application being developed on serverb will require the installation of the latest versions of the firewalld<\/em>, httpd<\/em>, php<\/em>, php-mysql<\/em>, and mariadb-server<\/em> packages. The firewalld<\/em>, httpd<\/em>, and mariadb<\/em> services also need to be enabled and running. The firewalld<\/em> service must also provide access for remote systems to the web site provided by the httpd<\/em> service.<\/p>\n Construct a playbook on the control node, workstation, called The playbook should also contain another play which performs a simple test from the control node to ensure that the web server is accessible across the network as expected. This play should be comprised of a task which uses the <\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" In comparison with ad-hoc commands, playbooks are used in complex scenarios, and they offer increased flexibility. Playbooks use YAML format, so there is not much syntax needed, but indentation must be respected. Ansible playbooks tend to be more of a configuration language than a programming language.<\/p>\n","protected":false},"author":1,"featured_media":3227,"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\/3226"}],"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=3226"}],"version-history":[{"count":70,"href":"http:\/\/miro.borodziuk.eu\/index.php\/wp-json\/wp\/v2\/posts\/3226\/revisions"}],"predecessor-version":[{"id":3411,"href":"http:\/\/miro.borodziuk.eu\/index.php\/wp-json\/wp\/v2\/posts\/3226\/revisions\/3411"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/miro.borodziuk.eu\/index.php\/wp-json\/wp\/v2\/media\/3227"}],"wp:attachment":[{"href":"http:\/\/miro.borodziuk.eu\/index.php\/wp-json\/wp\/v2\/media?parent=3226"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/miro.borodziuk.eu\/index.php\/wp-json\/wp\/v2\/categories?post=3226"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/miro.borodziuk.eu\/index.php\/wp-json\/wp\/v2\/tags?post=3226"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nComplex playbooks may contain a long list of tasks. Some tasks in the list may be related in their function. With Ansible version 2.0, blocks offer another alternative to task organization. Blocks can be used to group related tasks together. This not only improves readability but also allows task parameters to be performed on a block level when writing more complex playbooks. The following examples show how a list of tasks can be organized into distinct groups with the use of blocks.<\/p>\ntasks:\r\n- name: first task\r\n yum:\r\n name: httpd\r\n state: latest\r\n- name: second task\r\n yum:\r\n name: openssh-server\r\n state: latest\r\n- name: third task\r\n service:\r\n name:httpd\r\n enabled:true\r\n state: started\r\n- name: fourth task\r\n service:\r\n name: sshd\r\n enabled:true\r\n state:started<\/pre>\n
tasks:\r\n- block:\r\n - name: first package task\r\n yum:\r\n name: httpd\r\n state: latest\r\n - name: second package task\r\n yum:\r\n name: openssh-server\r\n state: latest\r\n- block:\r\n - name: first service task\r\n service:\r\n name: httpd\r\n enabled: true\r\n state: started\r\n - name: second service task\r\n service:\r\n name: sshd\r\n enabled: true\r\n state: started<\/pre>\n
\nPlaybook can contain one or more plays. Because plays map managed hosts to tasks, scenarios that require different tasks to be performed on different hosts, such as orchestration, necessitate the use of different plays. Rather than having plays in separate playbook files, multiple plays can be placed in the same playbook file. Plays are expressed in a list context, so the start of each play is indicated by a preceding dash and space.<\/p>\n---\r\n# This is a simple playbook with two plays\r\n- name: first play\r\n hosts: web.example.com\r\n tasks:\r\n - name: first task\r\n service:\r\n name: httpd\r\n enabled: true\r\n- name: second play\r\n hosts: database.example.com\r\n tasks:\r\n - name: first task\r\n service:\r\n name: mariadb\r\n enabled: true\r\n...<\/pre>\n
---\r\n\r\n- hosts: group1\r\n tasks:\r\n - name: Install lldpad package\r\n yum:\r\n name: lldpad\r\n state: latest\r\n - name: check lldpad service status\r\n service:\r\n name: lldpad\r\n state: started<\/pre>\n
\n
[group1]\r\nhost1 ansible_host=192.168.100.2 ansible_ssh_port=22\r\n[group2]\r\nhost2 ansible_host=192.168.100.3 ansible_ssh_port=22<\/pre>\n
Ansible_os_family<\/code> and ansible_system_vendor<\/code> are variables gathered with gather_facts option and can be used like in this conditional example.<\/p>\n---\r\n\r\n- hosts: group1\r\n tasks:\r\n - name: Enable SELinux\r\n selinux:\r\n state: enabled\r\n when: ansible_os_family == 'Debian'\r\n register: enable_selinux\r\n\r\n - debug:\r\n Imsg: \"Selinux Enabled. Please restart the server to apply changes.\"\r\n when: enable_selinux.changed == true\r\n\r\n- hosts: group2\r\n tasks:\r\n - name: Install apache\r\n yum:\r\n name: httpd\r\n state: present\r\n when: ansible_system_vendor == 'HP' and ansible_os_family == 'RedHat'<\/pre>\n
ansible_os_family<\/code> variable is gathered via gather_facts<\/code> functionality.
\nThe task output is registered for future use, with its name enable_selinux
\nAnother example of the when clause. In this case, a message will be displayed for the host user if the SELinux was indeed enabled before. Another example of the when clause consisting of two rules.<\/p>\n---\r\n\r\n- hosts: group2\r\n tasks:\r\n - name: sshd config file modify port\r\n lineinfile:\r\n path: \/etc\/ssh\/sshd_config\r\n regexp: 'Port 28675'\r\n line: '#Port 22'\r\n notify:\r\n - restart sshd\r\n handlers\r\n - name: restart sshd\r\n service: sshd\r\n name: sshd\r\n state: restarted<\/pre>\n
\"sshd config file modify port\"<\/code> is changed, meaning that if the port is not 28675 in the first place, then it will be modified and the task will notify the handler with the same name to run, and it will restart the sshd service.<\/p>\n
\n<\/span><\/p>\n[miro@controlnode playbooks]$ cat \/etc\/ansible\/hosts\r\nmanagedhost1 ansible_host=managedhost1.example.com\r\n\r\n[labservers]\r\nmanagedhost1.example.com\r\nmanagedhost2.example.com\r\n\r\n\r\n[miro@controlnode playbooks]$ cat \/home\/miro\/ansible\/playbooks\/playbook0.yml\r\n---\r\n- hosts: labservers\r\n become: yes\r\n tasks:\r\n - name: ensure apache is at the latest version\r\n yum:\r\n name=httpd\r\n state=latest<\/pre>\n
[miro@controlnode playbooks]$ ansible-playbook playbook0.yml\r\n\r\nPLAY [labservers] ****************************************************************************************************************\r\n\r\nTASK [Gathering Facts] ***********************************************************************************************************\r\nok: [managedhost2.example.com]\r\nok: [managedhost1.example.com]\r\n\r\nTASK [ensure apache is at the latest version] ************************************************************************************\r\nok: [managedhost2.example.com]\r\nchanged: [managedhost1.example.com]\r\n\r\nPLAY RECAP ***********************************************************************************************************************\r\nmanagedhost1.example.com : ok=2 changed=1 unreachable=0 failed=0\r\nmanagedhost2.example.com : ok=2 changed=0 unreachable=0 failed=0<\/pre>\n
httpd<\/code> service:<\/p>\n[miro@controlnode playbooks]$ cat \/home\/miro\/ansible\/playbooks\/playbook0.yml\r\n---\r\n- hosts: labservers\r\n become: yes\r\n\r\n tasks:\r\n - name: ensure apache is at the latest version\r\n yum:\r\n name: httpd\r\n state: latest\r\n - name: start enable httpd\r\n service:\r\n name: httpd\r\n state: started\r\n enabled: yes\r\n\r\n[miro@controlnode playbooks]$ ansible-playbook playbook0.yml\r\n\r\nPLAY [labservers] ****************************************************************************************************************\r\n\r\nTASK [Gathering Facts] ***********************************************************************************************************\r\nok: [managedhost2.example.com]\r\nok: [managedhost1.example.com]\r\n\r\nTASK [ensure apache is at the latest version] ************************************************************************************\r\nok: [managedhost2.example.com]\r\nok: [managedhost1.example.com]\r\n\r\nTASK [start enable httpd] ********************************************************************************************************\r\nchanged: [managedhost1.example.com]\r\nchanged: [managedhost2.example.com]\r\n\r\nPLAY RECAP ***********************************************************************************************************************\r\nmanagedhost1.example.com : ok=3 changed=1 unreachable=0 failed=0\r\nmanagedhost2.example.com : ok=3 changed=1 unreachable=0 failed=0<\/pre>\n
index.html<\/code> file:<\/p>\n[miro@controlnode playbooks]$ cat \/home\/miro\/ansible\/playbooks\/playbook0.yml\r\n---\r\n- hosts: labservers\r\n become: yes\r\n tasks:\r\n - name: ensure apache is at the latest version\r\n yum:\r\n name: httpd\r\n state: latest\r\n - name: start enable httpd\r\n service:\r\n name: httpd\r\n state: started\r\n enabled: yes\r\n - name: create index.html\r\n file:\r\n path: \/var\/www\/html\/index.html\r\n state: touch\r\n - name: add line to index.html\r\n lineinfile:\r\n path: \/var\/www\/html\/index.html\r\n line: \"Hello World !\"\r\n\r\n\r\n[miro@controlnode playbooks]$ ansible-playbook playbook0.yml\r\n\r\nPLAY [labservers] ****************************************************************************************************************\r\n\r\nTASK [Gathering Facts] ***********************************************************************************************************\r\nok: [managedhost1.example.com]\r\nok: [managedhost2.example.com]\r\n\r\nTASK [ensure apache is at the latest version] ************************************************************************************\r\nok: [managedhost2.example.com]\r\nok: [managedhost1.example.com]\r\n\r\nTASK [start enable httpd] ********************************************************************************************************\r\nok: [managedhost2.example.com]\r\nok: [managedhost1.example.com]\r\n\r\nTASK [create index.html] *********************************************************************************************************\r\nchanged: [managedhost2.example.com]\r\nchanged: [managedhost1.example.com]\r\n\r\nTASK [add line to index.html] ****************************************************************************************************\r\nchanged: [managedhost2.example.com]\r\nchanged: [managedhost1.example.com]\r\n\r\nPLAY RECAP ***********************************************************************************************************************\r\nmanagedhost1.example.com : ok=5 changed=2 unreachable=0 failed=0\r\nmanagedhost2.example.com : ok=5 changed=2 unreachable=0 failed=0<\/pre>\n
[miro@controlnode playbooks]$ ansible-playbook playbook0.yml --limit managedhost1.example.com\r\n\r\nPLAY [labservers] ****************************************************************************************************************\r\n\r\nTASK [Gathering Facts] ***********************************************************************************************************\r\nok: [managedhost1.example.com]\r\n\r\nTASK [ensure apache is at the latest version] ************************************************************************************\r\nok: [managedhost1.example.com]\r\n\r\nTASK [start enable httpd] ********************************************************************************************************\r\nok: [managedhost1.example.com]\r\n\r\nTASK [create index.html] *********************************************************************************************************\r\nchanged: [managedhost1.example.com]\r\n\r\nTASK [add line to index.html] ****************************************************************************************************\r\nok: [managedhost1.example.com]\r\n\r\nPLAY RECAP ***********************************************************************************************************************\r\nmanagedhost1.example.com : ok=5 changed=1 unreachable=0 failed=0\r\n<\/pre>\n
[miro@controlnode playbooks]$ curl managedhost1\/index.html\r\nHello World !<\/pre>\n
\n
register<\/code> keyword<\/li>\n---\r\n\r\n- hosts: scoldham2.mylabserver.com \r\n tasks: \r\n - name: copy a file \r\n copy: \r\n src: testfile \r\n dest: \/home\/user\/testregister \r\n mode: 400 \r\n register: var \r\n - name: output debug info \r\n debug: msg=\"debug info is {{ var }}\"<\/pre>\n[miro@controlnode playbooks]$ cat playbook1.yml\r\n---\r\n\r\n- hosts: localhost\r\n tasks:\r\n - name: create file\r\n file:\r\n path: \/tmp\/newfile\r\n state: touch\r\n register: output\r\n - debug: msg=\"Register output is {{output}}\"<\/pre>\n[miro@controlnode playbooks]$ ansible-playbook playbook1.yml\r\n\r\nPLAY [localhost] *********************************************************************************************************************************************************************************************\r\n\r\nTASK [Gathering Facts] ***************************************************************************************************************************************************************************************\r\nok: [localhost]\r\n\r\nTASK [create file] *******************************************************************************************************************************************************************************************\r\nchanged: [localhost]\r\n\r\nTASK [debug] *************************************************************************************************************************************************************************************************\r\nok: [localhost] => {\r\n\"msg\": \"Register output is {u'group': u'miro', u'uid': 1000, u'dest': u'\/tmp\/newfile', u'changed': True, 'failed': False, u'state': u'file', u'gid': 1000, u'secontext': u'unconfined_u:object_r:user_tmp_t:s0', u'mode': u'0664', u'owner': u'miro', u'diff': {u'after': {u'path': u'\/tmp\/newfile', u'state': u'touch'}, u'before': {u'path': u'\/tmp\/newfile', u'state': u'file'}}, u'size': 0}\"\r\n}\r\n\r\nPLAY RECAP ***************************************************************************************************************************************************************************************************\r\nlocalhost : ok=3 changed=1 unreachable=0 failed=0<\/pre>\n[miro@controlnode playbooks]$ cat playbook1.yml\r\n---\r\n \r\n- hosts: localhost\r\n tasks:\r\n - name: create file\r\n file:\r\n path: \/tmp\/newfile\r\n state: touch\r\n register: output\r\n - debug: msg=\"Register output is {{output}}\"\r\n\r\n - name: edit file\r\n lineinfile:\r\n path: \/tmp\/newfile\r\n line: \"{{output.uid}}\"\r\n\r\n\r\n[miro@controlnode playbooks]$ ansible-playbook playbook1.yml\r\n\r\nPLAY [localhost] ***********************************************************************************************\r\n\r\nTASK [Gathering Facts] *****************************************************************************************\r\nok: [localhost]\r\n\r\nTASK [create file] *********************************************************************************************\r\nchanged: [localhost]\r\n\r\nTASK [debug] ***************************************************************************************************\r\nok: [localhost] => {\r\n\"msg\": \"Register output is {u'group': u'miro', u'uid': 1000, u'dest': u'\/tmp\/newfile', u'changed': True, 'failed': False, u'state': u'file', u'gid': 1000, u'secontext': u'unconfined_u:object_r:user_tmp_t:s0', u'mode': u'0664', u'owner': u'miro', u'diff': {u'after': {u'path': u'\/tmp\/newfile', u'state': u'touch'}, u'before': {u'path': u'\/tmp\/newfile', u'state': u'file'}}, u'size': 0}\"\r\n}\r\n\r\nTASK [edit file] ***********************************************************************************************\r\nchanged: [localhost]\r\n\r\nPLAY RECAP *****************************************************************************************************\r\nlocalhost : ok=4 changed=2 unreachable=0 failed=0\r\n\r\n[miro@controlnode playbooks]$ cat \/tmp\/newfile\r\n1000\r\n<\/pre>\n
\nAnother helpful option is the -C<\/code> option. This causes Ansible to report what changes would have occurred if the playbook were executed, but does not make any actual changes to managed hosts. The following example shows the dry run of a playbook containing a single task for ensuring that the latest version of httpd package is installed on a managed host. Note that the dry run reports that the task would effect a change on the managed host.<\/p>\n[student@controlnode ~]$ ansible-playbook -C webserver.yml\r\nPLAY [play to setup web server] ************************************************\r\nTASK [setup] *******************************************************************\r\nok: [servera.lab.example.com]\r\nDemonstration: Writing and executing playbooks\r\nDO407-A2.0-en-1-20160804 89\r\nTASK [latest httpd version installed] ******************************************\r\nchanged: [servera.lab.example.com]\r\nPLAY RECAP *********************************************************************\r\nservera.lab.example.com : ok=2 changed=1 unreachable=0 failed=0<\/pre>\n
\nWhen developing new playbooks, it may be helpful to execute the playbook interactively. The ansible-playbook command offers the --step<\/code> option for this purpose. When executed with this option, Ansible steps through each task in the playbook. Prior to executing each task, it prompts the user for input. User can choose ‘y’ to execute the task, 'n'<\/code> to skip the task, or 'c'<\/code> to exit step-by-step execution and execute the remaining tasks noninteractively.
\nThe following example shows the step-by-step run of a playbook containing a task for ensuring that the latest version of the httpd package is installed on a managed host.<\/p>\n[student@controlnode ~]$ ansible-playbook --step webserver.yml\r\nPLAY [play to setup web server] ************************************************\r\nPerform task: TASK: setup (y\/n\/c): y\r\nPerform task: TASK: setup (y\/n\/c): *********************************************\r\nTASK [setup] *******************************************************************\r\nok: [servera.lab.example.com]\r\nPerform task: TASK: latest httpd version installed (y\/n\/c): y\r\nPerform task: TASK: latest httpd version installed (y\/n\/c): ********************\r\nTASK [latest httpd version installed] ******************************************\r\nok: [servera.lab.example.com]\r\nPLAY RECAP *********************************************************************\r\nservera.lab.example.com : ok=2 changed=0 unreachable=0 failed=<\/pre>\n
command<\/code>, shell<\/code>, and raw<\/code> modules in playbooks. Because these take arbitrary commands, it is very easy to write non-idempotent playbooks with these modules. For example, this task using the shell module is not idempotent. Every time the play is run, it will rewrite \/etc\/resolv.conf<\/code> even if it already consists of the line \"nameserver 192.0.2.1\"<\/code>.<\/p>\n- name: Non-idempotent approach with shell module\r\n shell: echo \"nameserver 192.0.2.1\" > \/etc\/resolv.conf<\/pre>\n
copy<\/code> module and use that to get the desired effect. The following example will not rewrite the file \/etc\/resolv.conf<\/code> if it already consists of the right content:<\/p>\n- name: Idempotent approach with copy module\r\n copy:\r\n dest: \/etc\/resolv.conf\r\n content: \"nameserver 192.0.2.1\\n\"<\/pre>\n
\nalso manages itself as a managed host. The managed hosts have a devops user that is able to get root access through sudo without a password. SSH authentication keys are set up to give student login access to the devops user.
\nThe supplied configuration file specifies the remote user and the location of the inventory. It also configures Ansible logging to be enabled on the control node and managed hosts.<\/p>\n[student@workstation ~]$ cd \/home\/student\/imp-playdemo\r\n[student@workstation imp-playdemo]$ ls -la\r\n\r\ntotal 12\r\ndrwxrwxr-x. 3 student student 50 May 18 21:03 .\r\ndrwx------. 7 student student 4096 May 18 21:03 ..\r\n-rw-rw-r--. 1 student student 138 May 18 21:03 ansible.cfg\r\n-rw-rw-r--. 1 student student 34 May 18 21:03 inventory\r\ndrwxrwxr-x. 2 student student 6 May 18 21:03 log\r\n\r\n\r\n[student@workstation imp-playdemo]$ cat ansible.cfg\r\n\r\n[defaults]\r\nremote_user=devops\r\ninventory=inventory\r\nlog_path=\/home\/student\/imp-playdemo\/log\/ansible.log\r\nno_log=False\r\nno_target_syslog=False\r\n\r\n\r\n[student@workstation imp-playdemo]$ cat inventory\r\nlocalhost\r\nservera.lab.example.com<\/pre>\n
---\r\n- name: ftp client installed\r\n hosts: localhost\r\n remote_user: devops\r\n become: yes\r\n become_method: sudo\r\n become_user: root\r\n tasks:\r\n- name: latest lftp version installed\r\n yum:\r\n name: lftp\r\n state: latest<\/pre>\n
\n3. Review the\/home\/student\/imp-playdemo\/ftpserver.yml playbook. It ensures that the latest version of the vsftpd and firewalld packages are installed on servera. This operation will require escalated privileges, so the playbook enables privilege escalation using sudo and the root user. The connection to the managed host is made with the devops user. The playbook ensures that firewalld allows incoming connections for the FTP service. It
\nalso ensures that the vsftpd and firewalld services are enabled and running.
\nRelated tasks are grouped together using blocks.<\/p>\n---\r\n- name: ftp server installed\r\n hosts: servera.lab.example.com\r\n remote_user: devops\r\n become: yes\r\n become_method: sudo\r\n become_user: root\r\n tasks:\r\n - block:\r\n - name: latest vsftpd version installed\r\n yum:\r\n name: vsftpd\r\n state: latest\r\n- name: latest firewalld version installed\r\n yum:\r\n name: firewalld\r\n state: latest\r\n- block:\r\n - name: firewalld permits ftp service\r\n firewalld:\r\n service: ftp\r\n permanent: true\r\n state: enabled\r\n immediate: yes\r\n- block:\r\n - name: vsftpd enabled and running\r\n service:\r\n name: vsftpd\r\n enabled: true\r\n state: started\r\n - name: firewalld enabled and running\r\n service:\r\n name: firewalld\r\n enabled: true\r\n state: started\r\n...<\/pre>\n
[student@workstation imp-playdemo]$ ansible-playbook ftpclient.yml\r\nPLAY [ftp client installed] ****************************************************\r\nTASK [setup] *******************************************************************\r\nok: [localhost]\r\nTASK [latest lftp version installed] *******************************************\r\nchanged: [localhost]\r\nPLAY RECAP *********************************************************************\r\nlocalhost : ok=2 changed=1 unreachable=0 failed=0\r\n5. Execute the \/home\/student\/imp-playdemo\/ftpserver.yml playbook.\r\n[student@workstation imp-playdemo]$ ansible-playbook ftpserver.yml\r\nPLAY [ftp server installed] ****************************************************\r\nTASK [setup] *******************************************************************\r\nok: [servera.lab.example.com]\r\nTASK [latest vsftpd version installed] *****************************************\r\nchanged: [servera.lab.example.com]\r\nTASK [latest firewalld version installed] **************************************\r\nok: [servera.lab.example.com]\r\nTASK [firewalld permits ftp service] *******************************************\r\nchanged: [servera.lab.example.com]\r\nTASK [vsftpd enabled and running] **********************************************\r\nchanged: [servera.lab.example.com]<\/pre>\n
servera<\/code> to develop the web site and test your Ansible playbook.
\nA working directory, \/home\/student\/imp-playbook, has been created on workstation for the purpose of managing the managed node, servera. The directory has already been populated with an ansible.cfg<\/code> configuration file and an inventory<\/code> inventory file. The managed host, servera, is already defined in this inventory file. The developer needs the managed host to have the latest versions of the httpd<\/code> and firewalld<\/code> packages installed. Also, the httpd<\/code> and firewalld<\/code> services need to be enabled and running. Lastly, firewalld should allow remote systems access to the HTTP service.<\/p>\n\/var\/www\/html\/index.html<\/code> file to test the installation. Populate this file with the message ‘Welcome to the example.com intranet! ‘<\/em>.<\/p>\nhttp:\/\/servera.lab.example.com\/index.html<\/code> and verifies that the HTTP status return code is 200.<\/p>\nintranet.yml<\/code> looks like this:<\/p>\n---\r\n- name: intranet services\r\n hosts: servera.lab.example.com\r\n become: yes\r\n tasks:\r\n - block:\r\n - name: latest httpd version installed\r\n yum:\r\n name: httpd\r\n state: latest\r\n - name: latest firewalld version installed\r\n yum:\r\n name: firewalld\r\n state: latest\r\n - block:\r\n - name: firewalld permits http service\r\n firewalld:\r\n service: http\r\n permanent: true\r\n state: enabled\r\n immediate: yes\r\n - block:\r\n - name: httpd enabled and running\r\n service:\r\n name: httpd\r\n enabled: true\r\n state: started\r\n - name: firewalld enabled and running\r\n service:\r\n name: firewalld\r\n enabled: true\r\n state: started\r\n - block:\r\n - name: test html page\r\n copy:\r\n content: \"Welcome to the example.com intranet!\\n\"\r\n dest: \/var\/www\/html\/index.html\r\n - name: test\r\n hosts: localhost\r\n tasks:\r\n - name: connect to intranet\r\n uri:\r\n url: http:\/\/servera.lab.example.com\r\n status_code: 200<\/pre>\n
internet.yml<\/code>. Create a play in this playbook that configures the managed host as requested by the developer. Place the package installation tasks within a block. Place the firewall configuration task within a separate block. Place the service management tasks within another separate block. In a final block, include a task that uses the get_url<\/code> module to fetch and populate the content for the \/var\/www\/html\/index.php<\/code> file on the managed host to test the installation. This content is available for download at http:\/\/materials.example.com\/<\/code> grading\/var\/www\/html\/index.php<\/code>.<\/p>\nuri<\/code> module to make an HTTP request to http:\/\/ serverb.lab.example.com\/index.php<\/code> and verifies that the HTTP status return code is 200.<\/p>\n---\r\n- name: internet services\r\n hosts: serverb.lab.example.com\r\n become: yes\r\n tasks:\r\n - block:\r\n - name: latest httpd version installed\r\n yum:\r\n name: httpd\r\n state: latest\r\n - name: latest firewalld version installed\r\n yum:\r\n name: firewalld\r\n state: latest\r\n - name: latest mariadb-server version installed\r\n yum:\r\n name: mariadb-server\r\n state: latest\r\n - name: latest php version installed\r\n yum:\r\n name: php\r\n state: latest\r\n - name: latest php-mysql version installed\r\n yum:\r\n name: php-mysql\r\n state: latest\r\n - block:\r\n - name: firewalld permits http service\r\n firewalld:\r\n service: http\r\n permanent: true\r\n state: enabled\r\n immediate: yes\r\n - block:\r\n - name: httpd enabled and running\r\n service:\r\n name: httpd\r\n enabled: true\r\n state: started\r\n - name: mariadb enabled and running\r\n service:\r\n name: mariadb\r\n enabled: true\r\n state: started\r\n - name: firewalld enabled and running\r\n service:\r\n name: firewalld\r\n enabled: true\r\n state: started\r\n - block:\r\n - name: get test php page\r\n get_url:\r\n url: \"http:\/\/materials.example.com\/grading\/var\/www\/html\/index.php\"\r\n dest: \/var\/www\/html\/index.php\r\n mode: 0644\r\n - name: test\r\n hosts: localhost\r\n tasks:\r\n - name: connect to internet web server\r\n uri:\r\n url: http:\/\/serverb.lab.example.com\r\n status_code: 200<\/pre>\n