Skip to main content

Introduction to Ansible Deployment at Omnitouch

Overview​

Omnitouch Network Services uses Ansible as its infrastructure automation platform to deploy complete cellular network solutions (4G/5G) in a consistent, repeatable, and automated manner. This document provides an overview of how we leverage Ansible to orchestrate complex telecom deployments.

What is Ansible?​

Ansible is an open-source automation tool that allows you to:

  • Configure systems
  • Deploy software
  • Orchestrate complex workflows
  • Manage infrastructure as code

Ansible uses a declarative approach - you describe the desired state of your systems, and Ansible ensures they reach that state.

How Omnitouch Uses Ansible​

Key Concepts​

1. Inventory (Hosts Files)​

Defines what systems to manage. Each customer deployment has a hosts file that describes:

  • All virtual machines in the network
  • Their IP addresses
  • Network configuration
  • Service-specific parameters

Host files are what you will be working with to define your network.

See: Hosts File Configuration

2. Roles​

Defines how to configure each component. Roles are reusable units that contain:

  • Tasks (steps to execute)
  • Templates (configuration file templates)
  • Handlers (actions triggered by changes)
  • Variables (default configuration values)

Example roles for OmniCore components: omnihss, omnisgwc, omnipgwc, omnidra, etc

These are defined by the ONS team, while you can edit them, there's generally cleaner ways to make any tweaks you might need from within your hosts file.

3. Playbooks​

Orchestrates when and where roles are applied:

- name: Setup Omnicore MME
  hosts: mme
  roles:
    - omnimme

We use these essentially as groups for the roles.

In practice, each service playbook applies a single role, and shared setup is pulled in separately. A service bundle like services/epc.yml uses import_playbook to first run common.yml and then each per-service playbook:

- name: Install Common
  import_playbook: common.yml

- name: Run MME Playbook
  import_playbook: omnimme.yml

4. Group Variables​

Provides customer-specific configuration that overrides role defaults. This is where customer customization happens without modifying the base roles.

See: Group Variables and Configuration

Deployment Architecture​

The Deployment Process​

1. Define Infrastructure​

Create a hosts file describing your network topology:

Planning Note: Before defining infrastructure, review the IP Planning Standard for guidance on network segmentation, IP address allocation, and subnet organization.

Proxmox Users: If deploying on Proxmox, see Proxmox VM/LXC Deployment for automated VM/container provisioning.

See: Hosts File Configuration and Configuration Reference

mme:
  hosts:
    customer-mme01:
      ansible_host: 10.10.1.15
      mme_code: 1

2. Customize Configuration​

Set customer-specific variables in group_vars:

plmn_id:
  mcc: '001'
  mnc: '01'
customer_name_short: customer

#ToDo - Add link here to conifg reference for complete list

3. Run Playbooks​

Deploy the network:

ansible-playbook -i hosts/customer/host_files/production.yml services/epc.yml

4. Automated Deployment​

Ansible will:

  • Create/provision VMs (if using Proxmox/VMware integration)
  • Configure networking
  • Install software packages from APT cache
  • Deploy application code
  • Configure services with customer settings
  • Start services
  • Validate deployment

Key Components We Deploy​

OmniCore (4G/5G Packet Core Platform)​

  • OmniHSS - Home Subscriber Server
  • OmniSGW - Serving Gateway (Control plane)
  • OmniPGW - Packet Gateway (Control plane)
  • OmniUPF - User Plane Function
  • OmniDRA - Diameter Routing Agent
  • OmniTWAG - Trusted WLAN Access Gateway

See: https://docs.omnitouch.com.au/docs/repos/OmniCore

OmniCall (Voice & Messaging Platform)​

  • OmniCall CSCF - Call Session Control Function (P-CSCF, I-CSCF, S-CSCF)
  • OmniTAS - IMS Application Server (VoLTE/VoNR services)
  • OmniMessage - SMS Center (SMS-C)
  • OmniMessage SMPP - SMPP protocol support
  • OmniSS7 - SS7 signaling components (STP, HLR, CAMEL)
  • VisualVoicemail - Voicemail functionality

See: https://docs.omnitouch.com.au/docs/repos/OmniCall

OmniCharge/OmniCRM​

  • CRM Platform - Customer relationship management, self-signup, billing

See: https://docs.omnitouch.com.au/docs/repos/OmniCharge

Support Services​

  • DNS - Network DNS resolution
  • License Server - License management
  • Monitoring - Prometheus, Grafana

See: Deployment Architecture Overview

Package Management​

We use a hybrid package distribution model:

Pre-compiled APT Packages​

All Omnitouch software is distributed as Debian packages (.deb files):

  • Built from source in our CI/CD pipeline
  • Versioned and tested
  • Hosted on package repositories

APT Cache System​

Customers can choose between:

  1. Local APT Cache - Mirror of required packages on-site for offline deployment
  2. Public Repository - Direct access to Omnitouch's hosted package repository

There is also a unified omnicore .deb (built from packaging/) that bundles the playbooks and tooling for self-provisioning a deployment.

See: APT Cache System

License Management​

All Omnitouch software components require valid licenses managed through a central license server:

  • Components check license validity on startup
  • Features are enabled/disabled based on license
  • License server can be local or cloud-hosted

See: License Server

Benefits of This Approach​

Repeatability​

The same Ansible playbooks can deploy:

  • Development labs
  • Testing environments
  • Production networks
  • Customer sites

Consistency​

Every deployment uses the same tested configurations, reducing human error.

Version Control​

Infrastructure is defined as code in Git:

  • Track all changes
  • Review before deployment
  • Roll back if needed

Customization Without Complexity​

Customers can customize their deployment through group_vars without modifying core roles.

Rapid Deployment​

Deploy a complete cellular network in hours instead of days or weeks.

Getting Started​

Prerequisites​

Before running Ansible playbooks, you need to install the required dependencies. This project uses uv to manage the Python environment, so uv is required.

1. Install uv​

If uv isn't already installed, install it using whichever method suits your control node — see the uv installation docs. For example:

pipx install uv                                    # via pipx
curl -LsSf https://astral.sh/uv/install.sh | sh    # standalone installer

2. Install Dependencies​

From the repository root, run:

uv sync

This creates an isolated .venv/ and installs Ansible plus all necessary Python packages (pinned in uv.lock) for Omnitouch deployment automation.

3. Activate the Environment​

Activate the virtual environment, and keep it activated for all Ansible commands:

source .venv/bin/activate      # Windows: .venv\Scripts\activate

4. Install Ansible Collections​

Install the Ansible collections the playbooks depend on (from requirements.yml):

ansible-galaxy collection install -r requirements.yml

5. Run Ansible Commands​

With the environment activated, run Ansible commands directly:

ansible --version

Note: Deactivate the environment when finished by running deactivate.

Deployment Steps​

  1. Review the Hosts File Configuration to understand how to define your network
  2. Learn about Group Variables for customization
  3. Understand the APT Cache System for package management
  4. Review the Deployment Architecture to see how everything fits together
  5. Deploy!

Next Steps​

Last updated on