Jenkins持续集成实践指南：扩展与管理策略

需积分: 9 54 浏览量更新于2024-07-19 收藏 3.5MB PDF 举报

"Jenkins-Continuous-Integration-Cookbook 是一本关于Jenkins持续集成实践的指南，涵盖了硬件推荐、规模化架构、易管理性等多个方面，旨在帮助用户掌握Jenkins的基本使用和解决日常问题。" 正文: Jenkins是广泛应用的开源持续集成(CI)和持续部署(CD)工具，用于自动化各种软件开发过程。本书《Jenkins Continuous Integration Cookbook》提供了丰富的实践建议和策略，以优化Jenkins的使用。硬件推荐部分： 1.1 引言：这部分介绍了选择适合Jenkins硬件的重要性。 1.2 选择合适的主服务器：强调了主服务器的内存需求，指出至少需要一定的内存以确保Jenkins稳定运行。 1.3 选择合适的从属机器（奴隶节点）：从属机器需要满足特定条件才能成为有效的构建节点，讨论了如何选择这些机器。 1.4 样例用例：通过Netflix和Yahoo的例子，展示了大型组织如何配置和扩展Jenkins。规模化架构： 2.1 引言：讨论了为了应对大规模项目和高并发需求，Jenkins的架构设计和扩展策略。 2.2 分布式构建架构：解释了主从通信协议，说明了如何利用分布式构建提高效率。 2.3 创建可互换的从属节点：提倡配置工具定位，定义资源共享策略，并介绍了如何设置云从属节点以实现灵活扩展。 2.4 适配Jenkins主服务器规模：探讨了主服务器划分策略和计算所需的工作节点、主服务器和执行器的方法，以及为主服务器提供可扩展的存储解决方案。 2.5 设置备份策略：包括确定$JENKINS_HOME位置，理解其结构，选择备份策略，以及定义回滚实例以应对故障。弹性Jenkins架构： 2.6 弹性Jenkins架构章节关注Jenkins系统的健壮性，讨论如何构建能够抵御故障的架构。易管理性： 3.1 引言：介绍如何通过测试实例和组织策略来提升Jenkins的管理效率。 3.2 测试实例：这部分可能涵盖创建和维护测试Jenkins实例，以便进行配置验证和实验。通过以上内容，读者可以深入了解Jenkins的配置、扩展和管理，从而有效地在实际项目中应用Jenkins，实现高效的持续集成和持续部署流程。这本书不仅适合初学者，也对经验丰富的Jenkins用户有很高的参考价值，帮助他们在实践中克服挑战，优化CI/CD流程。

Architecting for Scale

Java Web Start program has to be launched in the slave machine in 2 different

ways:

• Manually by navigating to the Jenkins master URL in the slave’s browser.

Once the Java Web Start icon is clicked, the slave agent will be launched on

the slave machine. The downside of this approach is that the slaves cannot

be centrally managed by the Jenkins master and each/stop/start/update of the

slave agent needs to be executed manually on the slave machine in versions of

Jenkins older than 1.611. This approach is convenient when the master cannot

instantiate the connection with the client (i.e. it runs outside a firewall whereas

the slave runs inside).

• As a service, which allows for restarts to be automated. First you’ll need to

manually launch the slave using the above method. After manually launching

it, jenkins-slave.exe and jenkins-slave.xml will be created in the slave’s work

directory. Now go to the command line to execute the following command:

sc.exe create "<serviceKey>" start= auto binPath= "<path to jenkins-slave.exe>" DisplayName= "<service display name>"

<serviceKey> is the name of the registry key to define this slave service and <service

display name> is the label that will identify the service in the Service Manager

interface.

To ensure that restarts are automated, you will need to download a slave jar newer than

v 2.37 and copy it to a permanent location on the slave machine. The slave.jar can be

found in:

http://<your-jenkins-host>/jnlpJars/slave.jar

If running a version of Jenkins newer than 1.559, the slave.jar will be kept up to date

each time it connects to the master.

• The JNLP-HTTP connector: This approach is quite similar to the JNLP-TCP

Java Web Start approach, with the difference in this case being that the slave

agent is executed as headless and the connection can be tunneled via HTTP(s).

The exact command can be found on your JNLP slave’s configuration page:

Figure 2.3. JNLP slave launch command

Architecting for Scale

This approach is convenient for an execution as a daemon on Unix.

• Custom-script: It is also possible to create a custom script to initialize the

communication between master and slave if the other solutions do not provide

enough flexibility for a specific use-case. The only requirement is that the script

runs the java program as a java -jar slave.jar on the slave.

Windows slaves set-up can either follow the standard SSH and JNLP approach or use

a more Windows-specific configuration approach. Windows slaves have the following

options:

• SSH-connector approach with Putty

• SSH-connector approach with Cygwin and OpenSSH: This

is the easiest to

setup and recommended approach.

• Remote management facilities (WMI + DCOM): With this approach, which

utilizes the Windows Slave plugin

), the Jenkins master will register the slave

agent on the windows slave machine creating a Windows service. The Jenkins

master can control the slaves, issuing stops/restarts/updates of the same. However

this is difficult to set-up and not recommended.

• JNLP-connector approach: With this approach

it is possible to manually

manage it from the master. Each stop/start/update of the slave agent needs to be

executed manually on the slave machine, unless running Jenkins 1.611 or newer.

2.3. Creating fungible slaves

2.3.1. Configuring tools location on slaves

The Jenkins Global configuration page let you specify the tools needed during the

builds (i.e. Ant, Maven, Java, etc).

When defining a tool, it is possible to create a pointer to an existing installation by

giving the directory where the program is expected to be on the slave. Another option

is to let Jenkins take care of the installation of a specific version in the given location.

It is also possible to specify more than one installation for the same tool since different

jobs may need different versions of the same tool.

The pre-compiled “Default” option calls whatever is already installed on the slave and

exists in the machine PATH, but this will return a failure if the tool was not already

installed and its location was not added to the PATH system variable.

http://wiki.jenkins-ci.org/display/JENKINS/SSH+slaves+and+Cygwin

http://wiki.jenkins-ci.org/display/JENKINS/Windows+Slaves+Plugin

http://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+as+a+Windows+service

Architecting for Scale

One best practice to avoid this failure is to configure a job with the assumption that

the target slave does not have the necessary tools installed, and to include the tools’

installation as part of the build process.

2.3.2. Define a policy to share slave machines

As mentioned previously, slaves should be interchangeable and standardized in

order to make them sharable and to optimize resource usage. Slaves should not

be customized for a particular set of jobs, nor for a particular team. CloudBees'

recommendation is always to make slaves general enough to be shared among jobs and

teams, but there are exceptions.

Lately Jenkins has become more and more popular not only in CI but also in CD,

which means that it must orchestrate jobs and pipelines which involve different teams

and technical profiles: developers, QA people and Dev-Ops people.

In such a scenario, it might make sense to create customized and dedicated slaves:

different tools are usually required by different teams (i.e. Puppet/Chef for the Ops

team) and teams’ credentials are usually stored on the slave in order to ensure their

protection and privacy.

In order to ensure the execution of a job on a single/group of slaves only (i.e. iOS

builds on OSX slaves only), it is possible to tie the job to the slave by specifying the

slave’s label in the job configuration page. Note that the restriction has to be replicated

in every single job to be tied and that the slave won’t be protected from being used by

other teams.

2.3.3. Setting up cloud slaves

Cloud build resources can be a solution for a case when it is necessary to maintain a

reasonably small cluster of slaves on-premise while still providing new build resources

when needed.

In particular it is possible to offload the execution of the jobs to slaves in the cloud

thanks to ad-hoc plugins which will handle the creation of the cloud resources together

with their destruction when they are not needed anymore:

• The EC2 Plugin

let Jenkins use AWS EC2 instances as cloud build resources

when it runs out of on-premise slaves. The EC2 slaves will be dynamically

created inside an AWS network and de-provisioned when they are not needed.

• The JCloud plugin

creates the possibility of executing the jobs on any cloud

provider supported by JCloud libraries

https://wiki.jenkins-ci.org/display/JENKINS/Amazon+EC2+Plugin

https://wiki.jenkins-ci.org/display/JENKINS/JClouds+Plugin

剩余87页未读，继续阅读

qinyuc

粉丝: 0
资源: 2

Jenkins持续集成实践指南：扩展与管理策略

Jenkins.Continuous.Integration.Cookbook.2nd.Edition

Jenkins Continuous Integration Cookbook 无水印pdf

Jenkins 2.x Continuous Integration Cookbook, 3rd Edition-Packt Publishing(2017)

jenkins-2.190.3-1.1.noarch.rpm下载

jenkins-2.401.1-1.1.noarch.rpm 的公钥尚未安装

centos 安装jenkins jenkins-2.401.1-1.1.noarch.rpm 的公钥尚未安装

jenkins-cli.jar下载

jenkins-2.401.3-1.1.noarch.rpm 的公钥尚未安装

jenkins.service - jenkins continuous integration server loaded: loaded (/usr

最新资源