Recently, I tried to automate the deployment of projects through Jenkins, but I didn't expect to step on a lot of pitfalls. The basic principle of Jenkins deployment:
Pull the code on gitlab through the Jenkins server, package it, push it to the target server, and run the startup script.
Then Jenkins has to solve three problems.
1. Connect to the target server
2. Package and push to the directory corresponding to the target server.
3. Run the startup script.
1. First, to solve the first problem, connect to the remote server.
1. The Jenkins server must be able to ping the target server.
2. The Jenkins server must be able to telnet to port 22 of the target server.
3. Generate a key in Jenkins, which is a public key and private key pair, execute the command:
ssh-keygen -t rsa/.ssh/id_rsa.pub
Copy the public key to the authorized_keys file in the /root/.ssh directory of the target server and
id_rsa.pub file. If these two files do not exist in /root/.ssh, create them manually.
Pitfall 1 here: The content of authorized_keys does not allow newlines. If there are newlines, you need to manually delete the newlines.
Pit 2: The permission of authorized_keys must be 600, the permission of id_rsa.pub must be 700, and the permission of this directory must be 700.
You can't connect if you give multiple permissions casually. For example, if you give 755 or 777. It won't work.
You can use the command directly:
chmod 700 /root/.ssh
cd /root/.ssh
chmod 600 authorized_keys
chmod 700 id_rsa.pubThis matches the secret key for connecting the Jenkins server to the target server.
Next, you need to configure the operation of connecting to the target server on the Jenkins management configuration.
Enter Jenkins, click "Manager Jenkins"
Click "Configure System"
Add a new server in "SSH Servers", configure as shown below
This is the private key of the jenkins server.
After configuration, click Test Configuration
If it is success, it means that the jenkins server can already connect to the target server.
2. Use Jenkins to package the code and push it to the remote server.
1. Create a new item
Then configure the package push information of the project in the configuration item
General is some basic configuration of the build task. name, description, etc.
Project name : It is set in the step of creating the build task just now, of course it can also be changed here.
Description : A description of the build task.
Source control is where configuration code lives.
R es repository URL : fill in the Git address of the project
Credentials : Credentials, which are equivalent to users, can use HTTP username and password, or RSA files. It is recommended to choose root directly.
Branches to build : Branches to build. */master indicates the master branch, and can also be set to other branches.
Source code browser : the code warehouse management tool you use, such as github, gitlab. "Automatic" can be selected.
The above is a description of the configuration that is packaged and pushed to the target server
3. Run the startup script configuration
This is the startup script that describes what to run on the target server.