Ansible Installation and Configuration for Cockpit and GitLab Runner in the Android Department

The Android department of Liulishuo manages multiple servers that support daily APK packaging and various common services.

All devices and services are uniformly deployed using Ansible, with Cockpit as the daily monitoring tool, greatly simplifying operational workload. The following describes the Ansible configuration process, using Cockpit and GitLab Runner as examples.

Ansible Installation and Configuration

Ansible is a Python‑based automation tool that enables bulk system configuration, program deployment, and command execution. Because Ansible communicates over SSH, no client agents need to be pre‑installed on target hosts.

The main components are Ansible, Modules, Plugins, Playbooks, and Host Inventory.

The workflow: Ansible reads the Host Inventory to identify managed hosts, executes tasks defined in Playbooks, uses Modules to perform actions such as ping or copy, and relies on Plugins to connect to the hosts.

General Ansible project configuration steps:

1. Install Ansible on the local machine.

sudo pip3 install ansible

yum install -y ansible

Verify the installation:

ansible --version

2. Create a project (the file structure is not strictly required). Example project layout is shown below.

2.1 The hosts file defines managed nodes, SSH credentials, and common variables such as installation directories.

all:
vars:
ansible_connection: ssh
ansible_ssh_user: ******
ansible_ssh_pass: ******
ansible_become: yes
ansible_become_password: ****
ansible_ssh_common_args: '-o StrictHostKeyChecking=no'
ansible_python_interpreter: /usr/bin/python3
ansible_dir: /opt/ansible
nginx_config_dir: /etc/nginx/sites-enabled
nfs_share_dir: /opt/runner-share-files
nfs_share_backup_dir: /opt/runner-share-files-bak
children:
master:
hosts:
node2:
ansible_host: node1.xxx.com
slave:
hosts:
node1:
ansible_host: node2.xxx.com

2.2 main.yml is the top‑level playbook that imports all service configuration playbooks.

- import_playbook: config-service.yml
- import_playbook: config-cockpit.yml
- import_playbook: config-gitlab-runner.yml
- import_playbook: config-nfs.yml

2.3 The tasks/ and handlers/ directories contain service‑specific configuration steps, such as copying GitLab Runner configuration files to target nodes. The hosts field limits which machines the tasks run on.

2.4 config‑xxx files orchestrate the execution of the corresponding tasks.

2.5 The files/conf directory holds configuration files for services such as Nginx.

3. Execute the configuration:

ansible-playbook -i hosts main.yml --limit node4

The --limit option restricts execution to a specific node; omitting it runs against all nodes.

Cockpit Monitoring Service

Cockpit, developed by Red Hat, is a web‑based graphical service management tool that requires no intermediate layer and can manage multiple services. The following shows how to install and configure Cockpit via Ansible.

- name: config cockpit
hosts: all
vars:
tasks:
- name: install cockpit
apt:
name:
- cockpit
- cockpit-docker
- cockpit-pcp
- cockpit-ws
state: present
- name: ensure Cockpit is started
systemd:
name: "cockpit.socket"
state: "started"
enabled: true
daemon_reload: true
- name: enable port 9090 for cockpit
ufw:
rule: allow
port: 9090

After Ansible deployment, opening the URL of any node provides a unified web interface to monitor and manage machine status, Docker services, network, accounts, and more.

GitLab Runner

1. Install the Runner directly on the target host.

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash
sudo apt-get install gitlab-runner

2. In Ansible, set the configuration file with concurrency, GitLab URL, token, etc.

concurrent = 2
check_interval = 0
[session_server]
session_timeout = 1800
[[runners]]
name = "xxx"
url = "https://xxx/"
token = "xxxx"
executor = "docker"
builds_dir = "/opt/builds"
cache_dir = "/opt/runner-share-files/runner-cache"
pre_clone_script = "source /opt/scripts/pre_clone_script.sh"
pre_build_script = "source /opt/scripts/pre_build_script.sh"
post_build_script = "source /opt/scripts/post_build_script.sh"

3. Maintain the Docker images required by the Runner through playbooks.

- import_playbook: tasks/copy_gitlab_config.yml
- hosts: all
vars:
dest_path: /opt/scripts
tasks:
- name: create runner script dir
file:
path: "{{ dest_path }}"
state: directory
- name: copy runner script
copy:
src: scripts/
dest: "{{ dest_path }}"
owner: root
group: root
mode: preserve
- import_tasks: tasks/docker.yml
- import_tasks: tasks/androidrunner.yml
handlers:
- import_tasks: handlers/androidrunner.yml

For example, to build a specific Flutter Docker image, add the following tasks.

- name: copy flutter dockerFile
copy:
src: docker/flutter
dest: "{{ ansible_dir }}/docker"
owner: root
group: root
mode: preserve
notify:
- rebuild flutter docker image
- name: build flutter docker image
docker_image:
build:
path: "{{ ansible_dir }}/docker/flutter"
args:
flutter_version: "{{ item.git }}"
name: "lls_flutter:{{ item.image }}-jdk11"
source: build
loop:
- { git: 'v1.12.13+hotfix.9', image: 'v1.12.13-hotfix.9' }
- { git: '3.0.5', image: '3.0.5' }

Conclusion

By leveraging Ansible, the operational threshold and workload for CI/CD services are dramatically reduced, allowing Android engineers to maintain services efficiently. Standardized server deployment also lowers team turnover risk; changes only require updating Ansible scripts without complex documentation or deep contextual knowledge.