When communicating with the on-site implementation personnel, there was a misplacement of information, and the ip address in the screenshot sent by the implementation personnel was not the ip address in use (machine c reinstalled the system and changed the ip address)
This ip address needs to docker-compose.ymlbe set in the configuration file. The wrong ip address caused the configuration file I transferred to be wrong.
The service deployment can start normally (the code configuration is fine), but the application cannot be accessed. I saw the screenshot of his test access page later, only to find that the ip is inconsistent, wasting an hour or two
Error 2 file location error
The location of a file was misplaced, and after it was packed into a compressed package and sent to the on-site implementation personnel, the execution result did not meet expectations
At first, it was suspected that the account used by the implementer was not the root account, and the file permission problem
Later, I found out that when I compressed the package by myself, there were 2 files in the wrong folder.
When testing locally, I directly dragged and uploaded the file, and there was no problem with updating, deploying, and starting the test, and no folder path error was found.
Since the previous progress was very smooth, when the entire update and deployment compressed package was compiled, the entire compressed package was not tested. As a result, the implementer encountered an error during the actual deployment process, and only found the problem after troubleshooting, wasting an hour or two.
newly encountered error
Our microservices and middleware are all deployed using docker, and the Spring Boot program is packaged into a tar package image
When deploying, according to the file directory structure in the server, put the service tar package and static files that need to be updated according to the directory structure, and then pack the entire package into a compressed package and hand it over to the implementer
In the past, the implementation personnel copied the compressed package to the client's computer through a U disk, decompressed it first, and then uploaded it to the Linux system through a transmission tool. In order to simplify the operation steps of the implementers, put the decompression step into the update script (directly upload the entire compressed package to the designated folder of the linux system)
Static resources such as the interface were updated twice before, and no problems were encountered
I encountered a problem when updating and deploying the background service last week, showing that the tar package is damaged, the tar header is invalid, and the use cannot be recognizedError processing tar file(exit status 1): archive/tar: invalid tar header
After compressing the page file and tar package into zip in the windows system, use unzip to decompress it in Linux, the tar file is damaged, and the image cannot be loaded
It still needs to be decompressed in the windows server first, and then use the transmission to enter the linux system according to the transmission
Other problems encountered
Many customers have very old machines, win7 system, and old browsers. Moreover, in the intranet environment, it is impossible to download and update the browser
Existing B/S applications generally only adapt to mainstream browsers. Our platform also reported js loading errors in old browsers.
It is necessary to prepare offline installation packages of some newer browser versions in advance, such as Google, Firefox, and 360.
lessons learned
For the deployment environment that cannot be connected to the Internet and the implementation personnel who are not very skilled, it is necessary to simplify the process as much as possible, and update the details of the deployment document, and add more screenshots
Most parameter configurations remain unchanged. For configurations that need to be changed, they should be repeatedly confirmed with the on-site implementation personnel to ensure a successful deployment update
Although the on-site implementation personnel can assist in some file uploads and script execution, it is a bit difficult to troubleshoot, and the remote video and photos are very blurry. Due to unfamiliarity with the development and linux environment, it is also very troublesome for the two parties to cooperate. For the update package and update script delivered to the on-site implementation personnel, don’t be blindly confident, test it in a simulated similar environment in the company, actually run the script, check if there is an error, and deal with it in advance to ensure a successful deployment update
For the offline intranet environment, prepare more offline installation packages of software that may be used, especially file upload tools (such as winscp) and browsers