将这个生产的语法，复制到pipeline语法中
choice choices: ['10.4.7.12', '10.4.7.21', '10.4.7.22'], description: '发布哪台node上', name: 'host'
构建一下，发现也可以使用选择型参数了，类似这个的人工交互就可以选择多个参数了，可以写一个通用的模版，就处理人工交互的逻辑
现在我们可以去人工选择了，这里面的值怎么获取到，我们处理不同的项目，必须在这里面去实现，比如选择这个git之后，拉取这个代码编译构建，这些可能都是一些相同点，不同点发布的机器不一样，所以要选择用户是拿到的哪个git地址，发布的哪个机器，在脚本里去拿到，其实默认这个name就是一个变量，jenkins已经将这个赋予变量，并且pipeline可以直接获取这个变量名，就是刚才定义的git,host这个名字，那么我们从刚才设置的parameters里去测试这个变量可不可以拿到，拿到的话说明这个就很好去处理
构建一下，现在构建成功后已经是构建成功了，也已经获取到刚才我们的git这个参数下的值了
有了这些方式，就可以将这些不同点通过里面的agent和shell脚本来处理了,写pipeline参数化构建就是满足更多的一个需求，能适配更多的项目，能让人工干预的做一些复杂的任务
五、jenkins在k8s中动态创建代理
如何在k8s中动态的创建slave代理？
当完成这些任务之后考虑的问题，这些任务都是在jenkins机器去完成的，那么这个也肯定是在pod中去运行的，因为我们的是将jenkins部署在pod中的，也就是这当前的这个节点去完成的拉取代码，编译，构建镜像，发布，那么可能会遇到一个问题，那么项目很多，每天做持续集成很高，十几次甚至上百次，面对这样的一个需求量，当前的这个pod是很难支撑的，就好比刚才的job，有十几个人去运行，来运行不同的服务，本来是可以几分钟完成的事情，最后导致10多分钟才执行完成，这样的话就很耽误项目进度了，所以就需要使用jenkins的master-slave架构了，而master只负责调度分配，slave来完成这些job任务，而slave是由物理机或者虚拟机存在的，和master保持通信，只要有任务就下发到slave节点，这样就解决了单jenkins的性能问题了
也就是提前创建好几个jenkins-slave，在其他节点让它们待定着，当master有人点job构建了，这个jenkins会帮你把这个job具体做的事，转发到slave去干活，master也就启到一个领导的角色，它本身就没什么压力了，只负责调度了，那么如果不用k8s的容器的这样架构，就好比在一台机器上装了一个jenkins，然后找台主机做slave,在manage node,添加new node,然后这个就会通过master下发任务让slave去完成了。