The container runs in a Docker container on a Tencent Lightweight Cloud Server (Shanghai, 4C4G8M) and controls another Tencent Lightweight Server (Shanghai, 4C4G8M) via Agent to perform tasks such as code pulling, automatic building, packaging, testing, and deployment.
Jenkins receives WebHook push notifications for code from the image repository on Nanjing University Git, and all related operations are conducted according to the documentation. Both the front-end, back-end, and Python services run in containers in the production environment. Currently, the master branch is set as the production environment, and only pushes to this branch will trigger builds. The build status is pushed back to Nanjing University Git using GitLab Connection. The main branch for daily development is develop.
The deployment diagram is as follows.
The list of repositories and descriptions come as follows.
This section is omitted as much as possible. In summary, the steps are as follows:
Install the basic environment, pull the image, and configure the image repository.
Start the Jenkins Docker container and ensure it can SSH into the business logic server using RSA key authentication.
Configure the business logic server to pull images from Nanjing University Git via SSH.
Write the pipeline script, configure the WebHook, GitLab access token, GitLab Connection, etc., and gradually debug to optimize the entire CI/CD process for use in daily development.
Deployment Instructions
Trigger Methods
Trigger via WebHook
Trigger a build by actively sending a push event type WebHook when there are new commits on the master branch.
Manually Trigger Build in Jenkins
After logging into the Jenkins backend, navigate to the Jenkins pipeline page and click Build Now to manually trigger the build.
Currently, the Java backend repository can collect JUnit test results and JaCoCo-based test coverage reports, which can be displayed on the Jenkins web page.
Additionally, the build results have been successfully pushed back to Nanjing University Git.
Notes
Front-end
The front-end is generally ready for use immediately after building, but it is strongly recommended to use incognito mode or press Ctrl+F5 to force refresh the webpage. Although cnpm has been adopted, the packaging speed is still not very stable and may exhibit some fluctuations.
Back-end
The back-end packaging is not done within the container; it is merely deployed in the container. This approach effectively utilizes caching, resulting in good speed, with most builds completing within one minute (after upgrading the server to 4C4G).
Python
Due to the need to load pre-trained models, the network may not always be stable (sometimes it loads quickly, while other times it can inexplicably hang, with an estimated 20% probability). As a result, the time required to start the service after a successful build can vary significantly (the Docker background startup does not affect the execution flow).
The Python service can only start normally after all four model files are loaded. It is set to restart the Gunicorn worker to load these four files if they fail to load within ten minutes. If necessary, you can attempt multiple times.
Regarding the pip source, the source has already been changed during the Docker build.
FROM node:14.18-stretch as build-stage WORKDIR /app COPY package*.json ./ RUN npm install -g cnpm --registry=https://registry.npm.taobao.org RUN cnpm install COPY ./ . RUN cnpm run build
FROM nginx as production-stage RUN mkdir /app COPY --from=build-stage /app/dist /app COPY nginx.conf /etc/nginx/nginx.conf COPY cert/se3.ydjsir.com.cn.pem /etc/nginx/se3.ydjsir.com.cn.pem COPY cert/se3.ydjsir.com.cn.key /etc/nginx/se3.ydjsir.com.cn.key
# This is the proxy to backend, obviously the address will be modified accordingly after backend is also in the docker location ^~ /api/ { proxy_pass http://172.17.0.1:8888/; }