“

In this paper, a continuous integration deployment practice of Linux + Jenkins + Gitee was illustrated, including software installation, project permissions, task building, script writing, etc.

background

I had a project in my hand, which was maintained by myself at the very beginning and completed by myself from development -> deployment -> launch. The actual application scenarios are as follows: local development, Gitee source code storage + version control, server Git source code acquisition, server compiled code, project officially online access.

Slowly along with the development of the project, the developer will be one more, this time it involves two people develop different function on-line, respectively process into development (parallel) – > test (parallel) – > deployment (always) – > online () at any time, no longer entirely determined by a person each path of execution (forced by one person is not not, of course). Because it is entirely up to one person to control the deployment -> go live process, it can seriously affect the flow of collaboration. For example, when a developer needs to deploy, another process controller must be able to access the server in real time, pull code, and execute compile commands. The process controller, on the other hand, has no independent time to do anything else and is tied to the current iteration, which can be very resource-intensive, especially if frequent operations are required in a short period of time.

This was a real pain point I experienced on my own small projects, and it deepened my understanding of the introduction of continuous integration (CI) into my team. However, this article will not explain too much about the original content, but more focus on the practice, that is, how to build a normal Jenkins environment and build tasks from scratch.

directory

  • Environmental profile
  • Install Jenkins
  • Configure Jenkins (Roles, project permissions)
  • Configuration Gitee
  • Configure tasks (task building, scripting)
  • advice

Environmental profile

  • Jenkins Latest Version
  • Tencent cloud server (standard SA2) (the cheapest file can, Ali cloud can also)
  • CentOS Linux Release 7.6.1810 (Core)
  • Code repository: Gitee service (also available at Github, similar configuration method)

Install Jenkins

1, choose tsinghua university image download (other version please see: https://mirrors.tuna.tsinghua.edu.cn/jenkins/redhat-stable/)

Wget HTTP: / / https://mirrors.tuna.tsinghua.edu.cn/jenkins/redhat-stable/jenkins-2.222.3-1.1.noarch.rpmCopy the code

2. Yum install

Yum install - y Jenkins - 2.222.3-1.1 noarch. RPMCopy the code

3. Java installation

Yum -y install Java -- 1.8.0 comes with itsCopy the code

4. Start Jenkins service

systemctl start jenkins
Copy the code

5. Interview Jenkins

// Open the following address in the browser by default. If you have a separate domain name, you can also directly access the domain name http:// your server IP address :8080/Copy the code

6. Get Jenkins password

cat /var/lib/jenkins/secrets/initialAdminPassword
Copy the code

7. Configure the domestic mirror address for plug-in installation (to speed up the speed of expansion in installation)

Vi/var/lib/Hudson/Jenkins. Model. UpdateCenter. XML / / open the file directly is amended as: < url > https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json < / url > can / / / / restart service here still with tsinghua university, if you have special requirements, You can consider other mirror addressesCopy the code

8. Install the role-based Authorization Strategy plug-in for permission management

“

The above steps how to operate the Jenkins interface is omitted, the reason is because the Jenkins has been a relatively perfect system, if need Jenkins detail instructions, you can refer to the official documentation (https://www.jenkins.io/zh/doc/)

Configure Jenkins (Roles, project permissions)

1. Choose System Management > Global Security Configuration > Authorization Policy.

2. Select Role-based Strategy and click Save

3. Choose System > Manage And Assign Roles

4. Go to Manage Roles

5. Assign a Global Roles -> base Roles to all Roles -> Read Roles for basic users

6. Configure a Project Roles (renamed Item Roles for Jenkins) for the same purpose and save the Settings

  • Add a project permissionJenkinsTestProject
  • Regex matches allJenkinsTestProjectThe initial project is written asPattern : JenkinsTestProject.*

7. Create a role. Choose System Management > User Management > Create a role

8. Assign Roles: Choose Manage And Assign Roles > Assign Roles And save the Settings

  • Assign Global roles to roles
  • Assign privileges to Item Roles

9. Test whether the corresponding permission is normal

  • Create a New Task

  • Create project permissions again for comparison testing

  • tolisiAssign permissions (Note: If not assignedbase roles, you will find that,lisiYou cannot view any data after logging in )

  • tolisiAssign permissions

  • The loginzhangsanTo view its corresponding task

  • The loginlisiTo view its corresponding task

  • Role rights and project rights have been configured

Configuration Gitee

Yum -y install Git

Install the Gitee plug-in

“

Detailed configuration and solutions, reference gitee official tutorial (https://gitee.com/help/articles/4193)

The core steps are as follows:

Go to Jenkins -> Manage Jenkins -> Configure System -> Gitee Configuration -> Gitee Connections

2. Enter Gitee or whatever name you want in Connection Name

3. Enter the full URL address of the code cloud in the URL of Gitee host: https://gitee.com (the domain name of the code cloud deployment input by the privatized client)

4. If the Credentials cloud APIV5 private token is not configured, click Add – > Jenkins

  • DomainchooseGlobal credentials
  • KindchooseGitee API Token
  • ScopeChoose the range you need
  • Gitee API TokenEnter your code cloud private token to get the address:https://gitee.com/profile/personal_access_tokens
  • ID DescripitonEnter what you wantID 和describeCan be

5. The Credentials select the Gitee APIV5 Token

6. Click Advanced to configure whether to ignore SSL error (suitable for Jenkins environment) and set link test timeout (suitable for your network environment).

7. Click Test Connection to Test whether the link is successful. If it fails, please check steps 3, 5 and 6 above.

Configure tasks (task building, scripting)

1. Pull the code to workspace

  • New Task -> Configuration -> Source Management
  • chooseGit
  • Input corresponding toRepository URL

  • Once set up, click the corresponding build task to pull the branch to normallyJenkins 的 workspace

2. Set the password-free login between Jenkins server and target server

  • The operations on the Jenkins server are as follows:
    • ssh-keygen -t rsa -P ''
    • ssh-copy-id -i ~/.ssh/id_rsa.pub <IP>
  • Among them,<IP>For the target server
  • Validation, inJenkinsOn the server, directly throughssh <IP>To log in to the target server

3. Set up Jenkins Shell

4. Execute the task and click Build Now

5. View console output

6. An error message is displayed

  • The cause of the error is that Jenkins is started by default as the Jenkins user, but the Jenkins user does not have permission to perform SSH password-free login

  • Enter Jenkins server, switch Jenkins system user, find the switch failed, still root account

  • Error: /bin/bash in /etc/passwd was changed to /bin/false by yum

  • Change Jenkins’ /bin/false ‘to /bin/bash’

    • performvim /etc/passwd
    • Modify theJenkinsThe ` ` / bin/falsefor/bin/bash`

  • Run su Jenkins again and the output is as follows, because when installing Jenkins, Jenkins only created the Jenkins user, but did not create the home directory for it

  • Solutions are as follows:
    • performvim ~/.bash_profile
    • Add in the last lineexport PS1='[\u@\h \W]\$'
    • Save and executesource ~/.bash_profile
  • Verify success,su jenkins

  • At this timeJenkinsThe user cannot proceed yetsshNo secret login, so the subsequent need toJenkinsThe user added the secure-free login
  • JenkinsThe user to usesudoCommand Configuration

    • switchrootUser:su root
    • Execute the commandsudo visudo
    • Add a line at the end of the filejenkins ALL=(ALL) NOPASSWD: ALL
    • At this timeJenkinsUsers can use itsudoThe command
  • generateJenkinsThe key pair of the user is changed toJenkins
    • ssh-keygen -t rsa -P ''
    • ssh-copy-id -i ~/.ssh/id_rsa.pub <user>@<IP>
    • Among them<user>@<IP>The sample is:[email protected]
  • Performed againJenkinsBuild tasks will still report errors

  • The reason is,JenkinsOn the server,JenkinsPassword – free login set by the user is for the target serverrootFor users, you need to add them to the corresponding commandsrootThe user, otherwise will default to the target serverJenkinsThe user login
  • Modify the build taskshellThe following

  • Build again and the task succeeds

advice

  • In the preceding steps, configureJenkinsIf the related password exemption permission of a user is not changedshell, can beJenkinsThe default startup user byJenkinsThe user torootAnd can also be started normally
  • In the example above, a single point of service is usednodeService build task configuration, multi-point cluster, load and other build options should be considered if clustering is required
  • If it is a purely static front-end project, you can package (npm run build) similar operation writesshell, and then synchronizes to the target server using a file push similar to the original example

gossip

The following contents are personal views for reference only

Since I do front-end development myself, many of the examples are based on front-end considerations. There is more to be mined for server-specific deployment strategies. How to think about cluster deployment, load deployment, and so on.

In terms of personal experience, the problem Jenkins solved was essentially to transform more processes originally operated by manual operation into simple UI interactive system, and to replace manual input through scripted implementation schemes. In the liberation of development & operation personnel hands at the same time to avoid manual operation prone to error scenarios.

In software engineering, the concept of CI/CD (continuous integration/continuous delivery) is often introduced. In my opinion, they are not mysterious, but they have real application space. But only when we encounter the corresponding pain point in software engineering, we will have a deeper understanding and understanding.

Browse creative Commons license agreements



This work adoptsCreative Commons Attribution – Same way share 4.0 International LicenseGrant permission.