这篇文章是工作中的一种思考，并未实际应用。
假设我们有多个系列的任务要跑，每个系列的任务在不同的环境上，那么Jenkins本身其实就可以当做一个任务的执行器，不同的节点根据任务的需要数量预装环境并打上不同的label。
此时的系统结构应该是这样的，Jenkins启动一个入口任务，然后下面的子任务启动，寻找机器环境执行。
如果机器环境也是任务中的变量，那么一系列的任务的前置步骤就是先去部署环境，待环境处理完成后进行任务。
对于各种云服务器，他们或许会有接口去远程批量调动机器重新安装系统(没用过也没百度到，或许大客户有这个功能)。提前预设的节点可以采用这种方案，Jenkins节点在节点重装的时候是掉线的，所以任务不会跑失败，只会等待，Jenkins会去尝试重新连接这些机器（需要保证新的环境能链接上）。节点配置中有一个连接超时的设置，也有重试的间隔和次数，可以将其配置的多一些，根据经验，启动任务的时候如果没有环境，也会尝试一次连接环境，但是不确定是否会对所有机器进行重连，所以这几个节点的配置要确保安装完新系统的时候节点能够重新连接上来。
此时的系统结构可能是这样的：
Jenkins上先启动的是环境更新任务，只需要待全部机器都开始下线后就可以执行后面的任务，等待任务环境执行。
对于容器，我们可以利用Jenkins云可以拉取镜像的功能，在前置步骤中先进行镜像的版本更新，推送到docker的hub或者就在云主机的本地提交（K8S的云可能一定要提交到仓库里，docker的可以不拉仓库，直接在本地操作）。
jenkins任务的结构相同，将环境更新改为镜像更新任务。
因为正式任务是衔接在环境或镜像更新后面的，所以我们也可以通过在Jenkins配置参数控制是否要执行更新步骤。
