Test Runner Management of Ansible

Test Runner Management of Ansible

What does test runner management do?

Questions:

• What kind of runners do we have now? answer
• If you need to setup a new runner, what will you do? answer
• If you have a task that you need to setup 100 runners in one day,
  • What will happen if you setup the runner one by one? answer
  • What will you do? answer
  • What do you expect? answer
• Guess what problems are coped with by test runner management? answer
• what it will look like? answer

---

How does test runner management run?

• prepare a master and one or more destination hosts.
• connection between master and slave hosts.

• master push cmd or program or anything else to slave hosts.
• slave hosts execute what the master want them do.

So what we can use to complete all of these?

• SSH

• Ansible

---

Ansible

This picture shows the main content of Ansible.

Official Docs

Ansible introduction

Installation

• apt install

sudo apt-get update
sudo apt-get install software-properties-common
sudo apt-add-repository ppa:ansible/ansible
sudo apt-get update
sudo apt-get install ansible

• pip install

sudo pip install ansible

What happen after the installation?

• check the installation

# to check if the ansible installed
ansible --version

• the default configuration file of Ansible.(/etc/ansible/ansible.cfg)
• the default inventory file of Ansible.(/etc/ansible/hosts)

vim /etc/ansible/ansible.cfg
vim /etc/ansible/hosts

What is Configuration Management

Configuration management in terms of Ansible means that it maintains configuration of
the product performance by keeping a record and updating detailed information which
describes an enterprise’s hardware and software.

Such information typically includes the exact versions and updates that have been applied
to installed software packages and the locations and network addresses of hardware
devices. For e.g. If you want to install the new version of WebLogic/WebSphere server
on all of the machines present in your enterprise, it is not feasible for you to manually go
and update each and every machine.

You can install something in one go on all of your machines with Ansible
playbooks and inventory written in the most simple way. All you have to do is list out the
IP addresses of your nodes in the inventory and write a playbook to install
WebLogic/WebSphere. Run the playbook from your control machine & it will be installed
on all your nodes.

Inventory

Ansible can operate one or more hosts in the same time. All of these hosts are recorded in the inventory file.

e.g:

mode.test.com   # the host ip

[qa_server]  # we can group the host
foo.example.com   
bar.example.com

[wifi_server]
one.example.com
two.example.com
three.example.com

ad-hoc

• Ad hoc commands are commands which can be run individually to perform quick functions.
  These commands need not be performed later.

• These ad-hoc commands are not used for configuration management and deployment,
  because these commands are of one time usage.

e.g:

ansible XXX -m file -a "src=XXX dest=XXX"

playbook

• ansible-playbook is used for configuration management and deployment.

• Playbooks are the files where Ansible code is written. Playbooks are written in YAML
  format. YAML stands for Yet Another Markup Language. Playbooks are one of the core
  features of Ansible and tell Ansible what to execute. They are like a to-do list for Ansible
  that contains a list of tasks.

• Playbooks contain the steps which the user wants to execute on a particular machine.
  Playbooks are run sequentially. Playbooks are the building blocks for all the use cases of
  Ansible.

Some other important elements in playbook:

• role
• task

How to write a playbook.

• Role Structure

Roles have a structured layout on the file system. The default structure can be changed
but for now let us stick to defaults.
Each role is a directory tree in itself. The role name is the directory name within the /roles
directory.

Creating a Role Directory
The above command has created the role directories.

ansible-galaxy init --force --offline testrole
tree testrole

testrole
├── defaults
│   └── main.yml
├── files
├── handlers
│   └── main.yml
├── meta
│   └── main.yml
├── README.md
├── tasks
│   └── main.yml
├── templates
├── tests
│   ├── inventory
│   └── test.yml
└── vars
    └── main.yml

Not all the directories will be used in the example and we will show the use of some of
them in the example.

• To write a playbook

---
# by default, we only install
- hosts:
    - build-runners
    - local-test-runners
    - pc-test-runners
    - rpi-test-runners
  roles:
    - setup-apt
    - setup-utilities
    - setup-docker
    - setup-gitlab-runner
    - setup-network
    - setup-python
    - setup-test-packages

QA

What kind of runners do we have now?

• PC
• raspberry-pi

If you need to setup a new runner, what will you do?

• install the runner(softerware/python libs…)
• setup the environments (no password for sudo)
• register the runner for CI
• test the runner
• …

What will happen if you setup the runner one by one?

• Take to long
• low efficiency
• repeat too much
• too much work without sense
• …

What will you do?

Answer freely

What do you expect?

• do job once
• finish all of setup in one round
• no repetition
• …

Guess what problems are coped with by test runner management?

• do job once
• finish all of setup in one round
• no repetition
• …

what it will look like?

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-l4VSVYWa-1596941050479)(runner_img/manage.png)]

Example

- hosts: pi@192.168.152.122
  tasks:
  - name: copy test
    file:
      src: "/home/test/test-runner-management/SH.hoasts"
      dest: "/home/pi/SH.hoasts"
      state: touch

ansible pi@192.168.152.122 -m file -a "src=/home/test/test-runner-management/SH.hoasts dest=/home/pi/SH.hoasts state=touch"