The author introduces the author of this article is Wang Xianbao firstname.lastname@example.org, which is mainly responsible for the development of AutoCMS and the operation and maintenance of the caching platform. It is good at Python automated operation and maintenance, distributed caching and distributed file system application management.
The team introduces us as the car home operation and maintenance team. It is the most core team in the automotive home technology department. It is composed of OP and dev. Our goal is to build a high performance, high scalability, low cost, stable and reliable website infrastructure platform for the auto home group. Team technology blog address is http://autohomeops.github.io/.
Contact: you can communicate with us via email or message from official technology blog.
AutoCMS is the unified configuration management tool currently being used by the auto home. This article will introduce in detail the method and architecture implementation of the system. First, let’s look back at the following stages of software family deployment and configuration file management.
Original stage (manual deployment, Wiki specification)
In the initial stage, software deployment and configuration file management depended entirely on manpower. Deploy new business, operation and maintenance according to the software version of research and development test environment, download software package to official network, compile and install on the server, then manually configure file and start service according to R & D requirements. There are many problems exposed at this stage:
The source of software package is not mandatory, which brings great security risks.
The new business is on the line or the business is expanding urgently, and operation and maintenance invest a lot of manpower to complete the heavy manual labor.
The standardization of deployment directory relies on Wiki specification maintenance. Problems often arise when manpower is deployed.
Semi automation stage (relying on manpower packing, yum deployment)
With the implementation of operation and maintenance automation, build your own Yum source and package it to standardize the source of software version and deploy directory. When you need batch deployment, you can save a lot of manpower by installing Yum install to install related software packages by the server, but you still need to log in to the server to modify the configuration file to meet the needs of the line. The backup before the configuration file changes and the recovery after failure still need manpower maintenance.
The management system AutoCMS is now being used to realize page management software deployment and configuration files, and realize fast batch management software.
The following is a detailed introduction of the AutoCMS we are using.
Introduction to the use of 2.AutoCMS
AutoCMS is a system of software deployment and configuration file management based on puppet implementation, which avoids the manual installation of deployment software, provides reliable software standardization deployment, configuration files and basic services management services. The main functions of this system are as follows:
Batch deployment package
Page management software configuration file changes, support backup and rollback.
Multi environment deployment, development, testing, online environment isolation
Grayscale push configuration
Remote execution of security commands
Basic statistical functions
The user’s operation process is as follows:
Creating a host group is a collection of hosts that need to deploy the same software or the same configuration, and the configuration module needs to be associated with the host group. The configuration module is a puppet module that is written in advance.
The host will need to deploy the module’s host to join the group (the host’s input source is the CMDB interface).
Select the environment to select the environment of the host according to the needs, and the configuration data of each environment is stored independently, without affecting each other.
Configuration parameters are different according to the configuration module, and configuration files are written to generate different configuration pages. As long as the business operations and dimensions select the corresponding parameters on the page, puppet will generate the corresponding configuration files according to these parameters.
When the configuration of the push configuration business operation and maintenance is completed, the host group management page is returned, the host and the push configuration are selected, and the puppet agent of the related host will be triggered, and the corresponding software and configuration will be deployed.
3. system architecture description
AutoCMS uses Django as the front-end framework, and the backend deployer is based on the puppet implementation, and implements complete deployment and configuration logic through the ENC and report functions of puppet. The overall architecture is as follows:
Front-end configuration page
Because each software configuration option is different, the front end software parameter configuration page must use the configuration file dynamic generation.
At the beginning of the design, we chose MongoDB between MySQL and MongoDB.
Schema-less, JSON style storage: since the configuration data is different from the software, its data can not be stored on the key-value, each software configuration item may have a custom structure, so the JSON format is used, and the MongoDB bson just meets the requirement and saves the frequent use of foreign keys in MySQL. . In addition, JSON format data is easy to grasp and understand, and the stored data are clear at a glance.
CRUD is convenient and fast, supports range query and regular query, and supports upsert option.
Compared with other NoSQL products, we are more familiar with the persistence and high availability of mongodb.
The deployment implementation layer is implemented through the puppet module, with the parameters referenced in the module through a custom facter or using the ENC to read the configured storage MongoDB acquisition.
Implementation of multi instance deployment:
The multi instance deployment of a host is implemented by create_resources function. For example, a host needs to configure multiple Tomcat instances, and the data will be structured as follows:
The implementation of multi environment separation: the puppet code part of this system has git as version control, and the environment separation of the puppet code level is done by the multi branch features of the GIT itself. Execute the puppet code of different branches according to the requirements.
4. configuration case
The following is an example of Tomcat automatic deployment module.
According to the deployment requirements, a storage structure with several parameters is designed.
Fill in the configuration file of the front-end layout, and automatically generate the front-end configuration page.
Write the puppet automatic deployment module.
Write the ENC conversion program
After the above preparation work is done well, the system is on-line. The operation and maintenance group can create the host group, associated with the Tomcat module, and add the host to the group and configure the parameters.
After the configuration is completed, the grayscale release is verified without any problems. The whole quantity is pushed, the state is observed, and the configuration is finished.
With the advent of the cloud era, many servers can customize the environment for the implementation of the mirror image, but with the expansion of the business scale, the personalized configuration of the server will be more and more, and the maintenance work of the mirror will gradually increase, and the use of AutoCMS can solve this problem flexibly. Writing their configuration requirements into configuration modules and grouping servers and pushing them down in batches can save a lot of manual labor for operators. Let operation and maintenance personnel devote their energies to more valuable work.