How Ansible Transforms DevOps at a Trading Exchange: Lessons and Best Practices

1. Company and Technical Architecture

The speaker previously worked at a Shanghai exchange and now in Singapore, focusing on Ansible practices in a trading environment.

Key points include eliminating small servers, implementing physical network isolation for security and compliance, transitioning from commercial integration solutions to domestic open‑source DevOps, and adopting the internationally recognized DevOps/AIOps standard.

They are gradually moving to OpenStack, evolving from Bash scripts to Ansible v1.0.

2. Ansible Standard Learning Path

Official and internal training materials are organized into a structured learning roadmap.

3. Ansible Project Practice

Standardization is the foundation of automation. With clear standards, Ansible can quickly implement any requirement, whether in private data centers, hosted environments, private clouds, or public clouds.

3.1 Linux Practice

The team manages Linux and Windows hosts, having removed small machines.

Control nodes run on RHEL 6/7 with Python 2.7.14. Ansible 2.4 introduced significant Windows support.

Supported RHEL versions include 5, 6, and 7, with baseline standards for automation.

Ansible consists of an inventory and playbooks, providing four main functions described later.

Client installation usually requires only simplejson on RHEL 5.5; other versions work out‑of‑the‑box.

Configuration files are simple, supporting traditional password authentication and a cache mechanism.

Variables are documented in detail, providing a clear reference for users.

Core functions include user management (creation, trust relationships, password changes) and dynamic configuration, as well as patch management for high‑severity vulnerabilities.

Backup and recovery are critical; lack of backups previously caused server re‑installation.

Conditional filtering in Ansible is convenient but can be inefficient; pre‑grouping via CMDB is recommended.

3.2 Windows Practice

Although Ansible is less commonly used for Windows, the team manages Windows hosts using Ansible 2.4 or newer (including 2.6).

A detailed Windows security baseline is maintained.

Directory structure mirrors the Linux layout; for Windows versions earlier than 2012, PowerShell upgrades are required.

Modules support registry, local security policies, and advanced audit policies, with Chinese language support.

4. Ansible v1.x Project Summary

The team switched from Puppet to Ansible due to security compliance, complexity of legacy Bash scripts, and the need for a stable, easily upgradable solution.

Ansible’s version stability and simple upgrade process allow rapid iteration across departments.

Standardization enables the conversion of Excel‑based procedures into Ansible playbooks, supporting both physical and virtual X86 servers.

The community is active, knowledge bases are rich, and the team has successfully implemented Windows baseline compliance, network isolation, and automated patching for desktops.

5. Ansible v2.0 Project

The v2.0 project is underway in the Singapore office and will be shared in a future session.