How a Bank Transforms Traditional Ops with Docker: CMDB, CI/CD, and Scaling Strategies

Introduction

The article records a comprehensive sharing by Shen Weikang, an operations veteran at Guangfa Bank Data Center, on adapting traditional operations to container technologies such as Mesos, Kubernetes, and Swarm.

CMDB: Standardization, Differentiation and Customization

CMDB remains a core component for both traditional and automated operations. When Docker lacks its own CMDB, many usability issues arise. Standardizing all assets simplifies management, but in practice, especially in legacy industries, full standardization is difficult due to inevitable differences.

For example, upgrading a library changes the image; a custom Dockerfile is needed to reflect those changes.

Guangfa Bank implements the following practices:

Operating System : Select the base OS and version via the Dockerfile FROM field.

Common Software : Choose software (e.g., Java, Tomcat) from a dropdown; the system adds the appropriate ENV variables.

Dependency Package Upload : Package project‑specific libraries (Python, RPMs, certificates) that are not covered by the base image.

Installation Script : Provide a setup.sh entry in the uploaded package to define installation steps.

Port Mapping : Map container ports using the Dockerfile EXPOSE directive.

Storage Usage : Choose volume types (AUFS, external storage, NAS) based on I/O and persistence requirements.

Startup Command : Define the container’s entry point, analogous to Dockerfile CMD, and store it in a Docker‑specific CMDB.

The CMDB summarises three parts: environment demand configuration, configuration file management, and application runtime configuration.

1. Continuous Integration

1.1 Image Classification

Images are divided into three categories:

Base Environment Image : Contains only OS and basic dependencies. Naming convention: appName_projectTag_base (e.g., ABC_201701_base ).

Application Version Image : Built on the base image and includes compiled artifacts. Tagged with a timestamp to uniquely identify the build.

Application Runtime Image : Adds environment‑specific configuration files to the version image, producing distinct images for DEV, TEST, and PROD.

The configuration can be viewed as a configuration center, but the bank prefers plain configuration files.

Jenkins drives the CI pipeline: source code is fetched from Git, compiled into a WAR, and optionally delivered via FTP for traditional deployment. For Docker, the WAR is combined with the base image to produce a version image, then layered with environment configuration to create a runtime image.

2. Operations Practices

2.1 Interaction

Traditional ops allow direct SSH to VMs for performance inspection. In Docker, this becomes cumbersome; the bank proposes agents that execute actions (e.g., heap dump) inside containers via docker exec, avoiding direct user interaction.

2.2 Application Update and Gray Release

Rolling upgrades replace containers batch‑wise. The timing of container termination must consider both the container’s

OK status and the application’s startup time to avoid service interruption.

Bank services cannot afford downtime; therefore, upgrade scripts coordinate with monitoring tools to ensure availability before proceeding.

2.3 Elastic Scaling and Availability

Scaling decisions are based on business peak periods and automated monitoring policies. The bank stresses that automatic container termination must be coordinated with traditional monitoring to prevent premature shutdowns.

2.4 Logging

Containers output logs to standard output, which are collected by a log agent (logstash) and stored in Elasticsearch for Kibana visualization. For multi‑instance containers, log ordering is handled by tagging each log line with container identifiers.

2.5 Monitoring

Monitoring integrates both container‑level metrics (cAdvisor, custom exporters) and host‑level metrics. Application‑specific health checks (e.g., Tomcat response codes) are exposed via HTTP endpoints and consumed by load balancers such as HAProxy.

3. Application Refactoring

The bank focuses on four refactoring principles:

Node Differentiation : Avoid special‑case nodes; aim for uniform container environments.

Persistence : Use external volumes or NAS for data that must survive container restarts; consider Redis for in‑memory data.

Variability : Replace hard‑coded IPs/hostnames with environment variables.

Ease of Management : Ensure containers start within seconds and shut down gracefully to support micro‑service agility.

Overall, the bank blends traditional operational practices with modern container orchestration to achieve reliable, scalable, and maintainable services.