OPS435 Online Lab9
Revision as of 20:01, 25 March 2021 by Rchan (talk | contribs) (Created page with "Category:OPS435Category:rchanCategory:OPS435 Lab = Under Review and update, will be released on March 29, 2021 = = Objective = :# Confirm and review the Ansible p...")
Under Review and update, will be released on March 29, 2021
Objective
- Confirm and review the Ansible package installed on matrix.senecacollege.ca
- Explore and run Ansible's ad hoc commands
- Explore and study a few Ansible's modules
- Explore, create, and run a few Ansible playbooks
Overview
- Ansible is an agentless IT automation engine for automating cloud provisioning, configuration management, application deployment, intra-service orchestration, and many other IT system administration tasks.
- Ansible uses no additional custom security infrastructure, and it uses a very simple human readable language called 'YAML', to compose an Ansible Playbook which allows you to describe the tasks you want to automate.
Reference
- For more detail information about ansible, check out the ansible web site at www.ansible.com
- Overview on how ansible works
- Ansible Latest User Guide
- A System Administrator's guide to getting started with Ansible
System requirements
- You must have a valid Seneca user account on matrix.senecacollege.ca and an VM assigned to you in myvmlab.senecacollege.ca:
- control machine (matrix.senecacollege.ca)- run ansible to configure your assigned VM in myvmlab.senecacollege.ca
- managed machine(s) (your vm in myvmlab.senecacollege) - to be managed by the control machine
- You should be able to ssh from matrix.senecacollege.ca as a regular user to your managed machine without supplying a login password.
- Your account on your managed machine is a sudoer and can run sudo with/without password.
- Has Python 2.7+ installed on your managed machine(s).
Investigation I: The Ansible Package
- In this investigation, we explore the main components of the Ansible configuration management system and its operating environment. we also study a simple playbook for managing the configuration of a CentOS 7.x VM.
- You need at least two Linux systems for this lab: your account on matrix.senecacollege.ca to be used as the control machine and your assigned VM in myvmlab.senecacollege.ca as the managed machines. The Ansible package is already installed on matrix for you.
Key Concepts when using Ansible
- YAML - a human-readable data serialization language use by Ansible's playbooks. To know more, your can check out the wikipedia page here or a simple introduction here
- Control machine - the host on which you use Ansible to execute tasks on the managed machines
- Managed machine - a host that is configured by the control machine
- Hosts file - contains information about machines to be managed - click here for sample hosts file
- Idempotency - is an operation that, if applied twice to any value, gives the same result as if it were applied once.
- Ad hoc commands - a simple one-off task:
- shell commands
- ansible 192.168.99.153 -a 'date'
- ansible 192.168.99.153 -a 'df'
- ansible 192.168.99.153 -a 'iptables -L -n -v' -u root
- shell commands
- Ansible modules - code that performs a particular task such as copy a file, installing a package, etc:
- copy module
- ansible 192.168.99.153 -m copy -a "src=/ops435/ansible.txt dest=/tmp/ansible.txt"
- Package management
- ansible 192.168.99.153 -m yum -a "name=epel-release state=latest"
- copy module
- Playbooks - contains one or multiple plays, each play defines a set of repeatable tasks on one or more managed machines. Playbooks are written in YAML. Every play in the playbook is created with environment-specific parameters for the target machines:
- ansible-playbook -i 192.168.99.153, setup_webserver.yaml
- ansible-playbook firstrun.yaml
Part 1: The Ansible package installed on matrix
- You only need to have the "ansible" package on your control VM (i.e. matrix).
- Login to matrix with your Seneca account and change to the directory ~/ops435/lab9
- Issue the following command to check the version of the "ansible" package:
rpm -q ansible
- To confirm that you have access to the Ansible package, try the following command:
[raymond.chan@mtrx-node02pd lab9]$ ansible --help usage: ansible [-h] [--version] [-v] [-b] [--become-method BECOME_METHOD] [--become-user BECOME_USER] [-K] [-i INVENTORY] [--list-hosts] [-l SUBSET] [-P POLL_INTERVAL] [-B SECONDS] [-o] [-t TREE] [-k] [--private-key PRIVATE_KEY_FILE] [-u REMOTE_USER] [-c CONNECTION] [-T TIMEOUT] [--ssh-common-args SSH_COMMON_ARGS] [--sftp-extra-args SFTP_EXTRA_ARGS] [--scp-extra-args SCP_EXTRA_ARGS] [--ssh-extra-args SSH_EXTRA_ARGS] [-C] [--syntax-check] [-D] [-e EXTRA_VARS] [--vault-id VAULT_IDS] [--ask-vault-pass | --vault-password-file VAULT_PASSWORD_FILES] [-f FORKS] [-M MODULE_PATH] [--playbook-dir BASEDIR] [-a MODULE_ARGS] [-m MODULE_NAME] pattern ...
- Take a look of all the available command line options for the "ansible" command. There are a lots of options when running Ansible. Let's move on to try a few simple ones.
Part 2: Sample runs for some of the Ad hoc commands
[rchan@centos7 ansible]$ ansible 192.168.99.153 -m copy -a "src=/home/rchan/ops435/ansible/ansible.txt dest=/tmp/ansible.txt" 192.168.99.153 | SUCCESS => { "changed": true, "checksum": "837affc90674fb92cdb0ebac6e49ad31a586b37e", "dest": "/tmp/ansible.txt", "gid": 1001, "group": "rchan", "md5sum": "78ae49d77d28d06173cf2194a3909732", "mode": "0664", "owner": "rchan", "secontext": "unconfined_u:object_r:user_home_t:s0", "size": 106, "src": "/home/rchan/.ansible/tmp/ansible-tmp-1542902119.15-117618539513309/source", "state": "file", "uid": 1001 }
- 192.168.99.153 is the remote machine's IP address.
- "-m copy" tells ansible to use the copy module
- after '-a' is the arguments to the copy module, which specify the source file and the destination for the copy action.
- If you got the same "SUCCESS" message, login to the remote machine (in this example, it is 192.168.99.153) and check the directory "/tmp" for the file ansible.txt.
Part 3: Sample runs for using some Ansible's built-in modules
- You can get a complete list of all the ansible modules installed on you system with the following command:
ansible-doc --list_files
- "yum" is a built-in ansible module. You can get the detail information about any ansible module with the following command:
ansible-doc yum
- The following command demonstrates how to install the "epel-release" package with the "yum" module with different module arguments and under different remote user (your result may be differ from what is show below):
[rchan@centos7 ansible]$ ansible 192.168.99.153 -m yum -a "name=epel-release state=present" 192.168.99.153 | SUCCESS => { "changed": false, "msg": "", "rc": 0, "results": [ "epel-release-7-11.noarch providing epel-release is already installed" ] } [rchan@centos7 ansible]$ ansible 192.168.99.153 -m yum -a "name=epel-release state=present" -u root 192.168.99.153 | SUCCESS => { "changed": false, "msg": "", "rc": 0, "results": [ "epel-release-7-11.noarch providing epel-release is already installed" ] } [rchan@centos7 ansible]$ ansible 192.168.99.153 -m yum -a "name=epel-release state=latest" -u root 192.168.99.153 | SUCCESS => { "changed": false, "msg": "", "rc": 0, "results": [ "All packages providing epel-release are up to date", "" ] }
Part 4: Gather software and hardware information available on remote machine
- One of the main ansible module is called "setup", it is automatically called by ansible playbook to gather useful "facts" about remote hosts that can be used in ansible playbooks. It can also be executed directly by the ansible command (/usr/bin/ansible) to check what "facts" are available to a host.
[rchan@centos7 ansible]$ ansible 192.168.99.153 -m setup 192.168.99.153 | SUCCESS => { "ansible_facts": { "ansible_all_ipv4_addresses": [ "192.168.122.99", "192.168.99.153" ], "ansible_all_ipv6_addresses": [ "fe80::5054:ff:fe11:6767", "fe80::5054:ff:fe8c:b67c" ], "ansible_architecture": "x86_64", "ansible_bios_date": "04/01/2014", "ansible_bios_version": "1.9.1-5.el7_3.2", "ansible_cmdline": { "BOOT_IMAGE": "/vmlinuz-3.10.0-862.14.4.el7.x86_64", "LANG": "en_CA.UTF-8", "console": "ttyS0", ... "ansible_userspace_bits": "64", "ansible_virtualization_role": "guest", "ansible_virtualization_type": "kvm", "module_setup": true }, "changed": false }
Investigation II: Ansible Playbook
What is a playbook?
- * Playbook is one of the core features of Ansible.
- * Playbook tells Ansible what to execute by which user on the remote machine.
- * Playbook is like a to-do list for Ansible
- * Playbook is written "YAML".
- * Playbook links a task to an ansible module and provide needed arguments to the module which requires them.
Part 1: A playbook to update the /etc/motd file
Name: motd-play.yml
--- - hosts: 192.168.99.153 user: root vars: apache_version: 2.6 motd_warning: 'WARNING: use by ICT faculty/students only.' testserver: yes tasks: - name: setup a MOTD copy: dest: /etc/motd content: "{{ motd_warning }}"
Sample Run:
[rchan@centos7 playbooks]$ ansible-playbook motd-play.yml PLAY [192.168.99.153] ********************************************************** TASK [Gathering Facts] ********************************************************* ok: [192.168.99.153] TASK [setup a MOTD] ************************************************************ changed: [192.168.99.153] PLAY RECAP ********************************************************************* 192.168.99.153 : ok=2 changed=1 unreachable=0 failed=0
Part 2: A playbook to install and start Apache Server
Name: httpd-play.yml
--- - hosts: 192.168.99.153 user: root vars: apache_version: 2.6 motd_warning: 'WARNING: use by ICT faculty/students only.' testserver: yes tasks: - name: install apache action: yum name=httpd state=installed - name: restart apache service: name: httpd state: restarted
Sample Run:
[rchan@centos7 playbooks]$ ansible-playbook httpd-play.yml PLAY [192.168.99.153] ********************************************************** TASK [Gathering Facts] ********************************************************* ok: [192.168.99.153] TASK [install apache] ********************************************************** changed: [192.168.99.153] TASK [restart apache] ********************************************************** changed: [192.168.99.153] PLAY RECAP ********************************************************************* 192.168.99.153 : ok=3 changed=2 unreachable=0 failed=0
Investigation III: Using Playbook to configure an OPS435 Linux VM machine
- Assume you have just installed the latest version of CentOS 7.x on a VM with GNOME Desktop. You need to configure it so that you can use it for doing the Labs for OPS435. The following configuration tasks need to be done on that VM:
- update all the packages installed on the VM
- install extra packages repository for enterprise Linux
- install python3 if it is not already installed
- set the host name to your Seneca user name
- install the git package
- create a new user with your Seneca_id with sudo access
- configure the new user account so that you can ssh to it without password
- setup a directory structs for completing and organizing labs as shown below:
/home/[seneca_id]/ops435/lab0 /home/[seneca_id]/ops435/lab1 /home/[seneca_id]/ops435/lab2 /home/[seneca_id]/ops435/lab3 /home/[seneca_id]/ops435/lab4 /home/[seneca_id]/ops435/lab5 /home/[seneca_id]/ops435/lab6 /home/[seneca_id]/ops435/lab7 /home/[seneca_id]/ops435/lab8 /home/[seneca_id]/ops435/lab9
- create a playbook named "config_ops435.yml" to perform the tasks mentioned above.
- test and capture its output for a successful run of your playbook to a file named "lab9_[seneca_id].txt"
Lab 9 Sign-off (Show Instructor)
Have the following items ready to show your instructor:
- * The Ansible playbook called "config_ops435.yaml" for configuring the VM mentioned in Lab 1.
- * The result of running the playbook "config_ops435.yaml". Save the result in a file called "lab9_[seneca_id].txt"
Upload the following files to blackboard
- * config_ops435.yaml
- * lab9_[seneca_id].txt