2.1

Business requirements

An image can create multiple containers. A project contains multiple containers. A container instance can only mount

one container volume. A service can have multiple user container instances. A project can contain multiple images. A project can have multiple container volumes mounted. The domain model is shown in Figure 1.

Figure 1.

Domain model.

2.2

Functional requirements

All functions of the model are placed in the following high-level use case diagram, which is divided into two categories: all permission functions of ordinary users and all permission functions of super administrators. The high-level use case diagram of the project is shown in Figure 2.

Figure 2.

High level use case diagram.

The use case summary is described in Table 1.

Table 1.

Use case summary description.

2.3

Non functional requirements

Correctness: Business errors are not allowed. Robustness: In case of system failure, the user’s login data will not be lost. The system will use the RDB snapshot mode in Redis to ensure data backup of the user’s data and password⁶. Performance: The system processing time shall not exceed 2 seconds under normal traffic conditions, and the latest time under busy traffic conditions shall not exceed 5 seconds. Security: user password information can be encrypted with MD5 to prevent user information from being disclosed. Compatibility: can run Linux kernel 3.10.0-1062.1.2.el7.x86_ 64 and above.

3.1

Technology roadmap

The core key technology of this model in the implementation process is based on Docker container technology. This technology can break the limitations of traditional deployment projects and running projects, and it is more convenient and simple to complete the project⁷. You only need to package the project into an image, and it can run everywhere on the server, with high startup efficiency, easy maintenance and iteration.

Docker is an open source application container engine. Just let developers package their applications and dependency packages into a portable container, and then publish them to any mainstream Linux machine to achieve virtualization.

3.2

Model frame design

The system client is implemented as a SPA single page Web application. It uses AJAX requests to interact with the server based on HTTP protocol. The page uses Vue+JQuery+JavaScript to build a componentized page⁸. The Vue component is used to split the interface module. The variable part is split into separate subcomponents. Each module has a common component to reduce the development effort. The parent component uses different subcomponents in different scenarios through page logic control, Display the user interfaces under different logics. Because Vue is only responsible for processing part of the UI logic and does not provide a communication scheme with the server, it uses the AJAX implementation of JQuery or the popular Fetch to handle the communication with the server. The second level data is required in the data monitoring interface, so the mainstream WebSocket communication technology is used to ensure that the monitoring data of the container is updated in real time. The client system architecture is shown in Figure 3.

Figure 3.

Client system architecture diagram.

The server side system architecture is mainly divided into four layers to realize the division of different responsibilities, ensure that each layer has a single function, and follow the principle of unity⁹. The display layer is mainly used by the front end to show users the requirements for completing user functions. The control layer is responsible for distributing and processing client requests, verifying the Tokens of user identity information, permission control, data type conversion, view analysis, session management, and business logic layer is responsible for handling specific business logic, The data access layer is mainly used to provide necessary data support for the business logic layer (for example, if a user logs in, he needs to put the generated token in Redis for verification to see whether it is a legitimate user, and if he needs to query the user’s permission from the MySQL database, the database service layer will provide data persistence support). The data access layer is responsible for the persistence of business entities¹⁰. The server system architecture is shown in Figure 4.

Figure 4.

Server system architecture.

3.3

Database design

The database involves the implementation of 14 tables corresponding to different functions. The conceptual model (ER diagram) is shown in Figure 5.

Figure 5.

ER diagram.

3.4

System use case realization

3.4.1

User create container process.

The user enters the project, operates on the Create Container page, and returns the corresponding prompt after the operation. The case of creating a container instance is shown in Figure 6.

Figure 6.

Sequence diagram of create container instance use case.

3.4.2

User created project function.

The user creates the project on the Create Project page, and returns the corresponding prompt after the operation. The implementation sequence diagram of creating project use cases is shown in Figure 7.

Figure 7.

Sequence diagram for creating project use cases.

3.4.3

User management run container.

The case of running container instance creates a container successfully for management. Select the container to run and return the corresponding prompt after the operation. The implementation sequence of running container instance is shown in Figure 8.

Figure 8.

Sequence diagram of use cases of running container.

3.4.4

User export image function.

The user enters the project to export the image, and returns the corresponding prompt after the operation. The implementation sequence of the export image is shown in Figure 9.

Figure 9.

Sequence diagram of export image use case.

4.

MODEL IMPLEMENTATION AND DISCUSSION

The core business of the model is to create a container instance. The user needs to configure some parameters required for creating a container instance from the front end and send the parameters to the back end through the request. The back end will request the DockerClientAPI to interact with the Docker daemon through the ActiveMQ message queue task asynchronously, and then create a container instance. If the creation is successful, the result will be sent to the ActiveMQ message queue, Return the prompt information to the user.

The logic code of the back-end core business part of the container creation is shown below.

Importing an image is to upload the image file locally to DockerHub for direct use, transfer the file through the file byte stream, and then create a container instance object through the uploaded image. Exporting an image is to download the image file on the remote DockerHub.

Because the system is a token authentication mechanism of single sign on based on Redis technology, and the system uses the Spring Security permission control framework, and encrypts the user’s password plaintext information, it improves the security of the user’s personal information using the system. Therefore, the key technical difficulty is to correctly verify the Token information when generating and logging in the Token based on the Spring Security framework, and put the Token information into the Redis cache.