持续集成高级篇之基于win32-openssh搭建jenkins混合集群(一)

系列目录

前面的demo我们使用的都是只有一个windows主节点的的jenkins,实际生产环境中,一个节点往往是不能满足需求的.比如,.net项目要使用windows节点构建,java项目如果部署在linux服务器上往往也需要目标类型的linux节点做为构建节点,开发中使用的jdk版本不同也可能需要不同的构建主机.构建docker镜像往往也需要linux主机(强烈不建议使用docker for windows 进行linux环境的docker构建).本节我们讲解如何搭建一个主节点为windows server主机,从节点同时包含windows server和centos的jenkins集群

需要注意的是,由于windows不支持ssh(至少目前绝大多数线上的windows server主机是这样的),因此windows从节点往往是通过JNLP的方式搭建的.而linux则相对较为简单,只需要配置ssh即可.

使用JNLP配置从节点虽然也不十分复杂,但是缺点也比较明显.那就是需要在目标主机上启动一个控制台程序,一方面这个程序容易被误关,另一方面如果windows server重启则需要手动把它启动起来,这样极大增加了工作量.如果运维的工作负荷非常高,很可能在一次大规模主机重启后忘记重启一些软件,这样很多错误可能在已经影响使用的情况下才会发现.因此,这里我们探索一种新的方式,即使用微软公司开发的win32-openssh(现已集成到windows 10和windows server 2019),配置也非常方式.有了win32-openssh,我们就可以像linux主机一样使用ssh方式配置windows从节点.虽然我们提倡使用win32-openssh,但是仍然会介绍如何使用JNLP来配置windows从节点

经过笔者测试,win32-openssh支持windows server 2008及以上版本,目前恐怕没有更老的服务器版本了吧,大家不用担心生产环境无法使用的问题.当然,win32-openssh的用途绝不仅限于搭建jenkins混合集群,还可以用它完成更多的基于windows的自动化管理工作.笔者基于win32-openssh做了一套windows服务的自动化管理工具(支持windows服务的关闭,更新,启动,重启,停止,扩容等功能),目前部署在大约30台线上服务器上.

安装win32-openssh

前面我们说到要基于win32-openssh来基于ssh配置Jenkins的windows从节点,这节我们就先介绍如何安装win32-openssh,然后紧接着开始使用ssh配置jenkins windows从节点.

linux从节点ssh配置也是一样,因此不再单独介绍linux从节点的ssh配置

我们进入openssh-win32github页面进行下载,根据自己系统位数选择32位或者64位的.

下载完成以后进行解压,把解压后的文件夹放到C盘(也可以是其它盘),然后进入文件夹里面,内容类似如下:

在当前目录下打开powershell(或者从其它位置打开,cd到当前目录),在powershell命令窗口输入.\install-sshd.ps1,执行安装命令.

如果在执行过程中powershell报错,提示权限不足,则进行以下设置Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope Process,很多网上的教程没有指定scope,则很容易造成安全问题,在个人电脑上无所谓,在服务器上一定要重视过高的权限.

完了以后再执行FixHostFilePermissions.ps1FixUserFilePermissions.ps1这两个文件.(在powershell命令窗口输入.\文件名).

启动ssh服务.

安装完成以后,ssh相关服务默认是不启动的,我们打开服务管理界面,手动启动它们并把启动类型设置为自动,这样服务器重启开机时ssh相关的服务就会自动启动.

windows10开启ssh

windows较新的版本已集成了openssh,但是需要手动开启它.

  • 进入我的电脑,然后点击上面的计算机标签,然后选择卸载或更新应用

  • 在出现的界面里选择管理额外功能

  • 点击添加功能,然后在出现的列表里找到ssh相关的功能,都添加上

把openssh所在文件夹添加到path

我们把win32-openssh所在文件夹路径添加到环境变量path里,这样我们就可以在控制台输入ssh命令来连接远程主机,而不需要类似xshell,putty这样的终端工具.

生成ssh key

添加完环境变量后,我们打开cmd或者powershell命令窗口,输入ssh-keygen命令,生成ssh key,输入命令后一路回车.最终生成的key存放在C:/Users/当前用户名/.ssh/目录下.

其中id_rsa为私钥,id_rsa.pub为公钥,authorized_keys为授权访问本机的远程电脑的公钥,known_hosts为,初次访问远程主机时存储的信息.晚些时候我们会用到这些文件.

安装完ssh以后如果忘记了它的安装位置,打开命令窗口,输入where ssh就可以看到ssh.exe所在的目录.

原文地址:https://www.cnblogs.com/tylerzhou/p/11456796.html

时间: 2024-10-04 12:08:31

持续集成高级篇之基于win32-openssh搭建jenkins混合集群(一)的相关文章

持续集成高级篇之Jenkins cli与Jenkins ssh

系列目录 Jenkins Cli介绍 Jenkins Cli为Jenkins提供的一个cli工具,此工具功能非常强大,可以完成诸如重启jenkins,创建/删除job,查看job控制台输出,添加/删除节点等功能.但是实际工作中,像创建任务这样的配置显然cli非常吃力,不如直接在web管理界面操作,但是对于重启Jenkins,查看诊断信息等,执行一个手动构建任务等,则直接使用cli比进入web管理界面操作更加方便.因此什么时候web管理界面,什么时候使用cli,要看是否有利于提升生产力,是否有利于

持续集成高级篇之Jenkins Pipeline 集成sonarqube

系列目录 前面章节中我们讲到了Sonarqube的使用,其实Sonarqube获取msbuild结果主要是执行三个命令,开始标记,执行msbuild,结束标记,这些都是命令,是非常容易集成到我们ci流程中的,但是使用这种方式最为简单,但是Sonarqube插件与jenkins集成的更好,我们可以通过jenkins页面看到构建结果是否成功,以及可以通过链接轻松地跳到Sonarqube web管理界面.前面章节我们介绍了如何在自由式任务中使用sonarqube插件,这里我们讲下如何在pipeline

持续集成高级篇之Jekins参数化构建(二)

系列目录 上一节我们讲解了如何使用bat脚本或者powershell脚本自身的机制来达到参数化构建的目的,这在一定程序上增加了灵活性,然而缺点也相当明显:它只能适应一些相对比较固定的参数传入(比如像上一节讲到的,构建的环境分为(development和production)两种情况,对于一些相对较复杂的情况以上方法就会捉襟见肘,最为明显问题是外部的变化可能导致参数随之做必要更改,最常见的是文件的位置参数,我们指定归档文件的目录为D盘下的一个文件夹,现在D盘满了需要指定为其它盘,则所有的脚本都需要

持续集成高级篇之Jekins参数传入与常见任务

系列目录 有的童鞋可能已经发现,PipeLine项目与自由式项目相比,可配置的项少了很多,比如说环境变量定义,所有步骤完成后执行动作,拉git代码库等.其实这些功能并没有缺,而是配置的方式不一样了,以前是通过图形化界面配置,虽然直观简便,但是功能不能包罗万像,对于一些复杂的项目显得捉襟见肘,而Jenkins PipeLine使用代码配置功能更加强大.以后的章节中我们会介绍常用的配置如何通过PipeLine里的Groovy脚本来实现. 前面讲参数化构建的时候已经讲到对于复杂的构建把一些重复的,常用

持续集成高级篇之Jenkins Pipeline git拉取

系列目录 PipeLine中拉取远程git仓库 前面讲自由式任务的时候,我们可以看到通过自由式job里提供的图形界面配置git拉取非常方便的,实际上使用PipeLine也并不复杂.这一节我们展示一下如何在PipeLine任务中拉取git仓库代码. node{ stage("check out"){ git credentialsId: '3c210def-c000-4e2a-9b2d-838986a6b172', url: 'https://github.com/mrtylerzhou

基于Docker的Consul服务发现集群搭建

原文:基于Docker的Consul服务发现集群搭建 在去年的.NET Core微服务系列文章中,初步学习了一下Consul服务发现,总结了两篇文章.本次基于Docker部署的方式,以一个Demo示例来搭建一个Consul的示例集群,最后给出一个HA的架构示范,也会更加贴近于实际应用环境. 一.示例整体架构 此示例会由一个API Gateway, 一个Consul Client以及三个Consul Server组成,有关Consul的Client和Server这两种模式的Agent的背景知识,请

基于corosync+pacmaker实现高可用集群

目前,corosync功能和特性已经非常完善了,所以pacmaker独立出来之后通常都将pacmaker和corosync结合来使用,corosync并没有通用的资源管理器,因此要借助pacmaker来实现 常用的资源管理器: ·cman:rgmanager ·crm: crm的资源约束有: ·location :资源对节点的偏好 ·colocation:排序约束:资源运行在同一节点上的可能性,需要一定评估的 ·order: 资源采取动作的次序 资源有很多属性,以下为最常见的几类 ·集群属性 ·

基于heartbeat v1+ldirectord实现LVS集群高可用

前言 高可用集群,High Availability Cluster,简称HA Cluster,是指以减少服务中断时间为目的的服务器集群技术.通过上文可以看出,LVS集群本身并不能实现高可用,比如Director Server不能检测Real Server的健康度,一旦其中一台或全部Real Server宕机,Director Server还会继续转发请求,导致站点无法访问,同样,如果Director Server宕机站点就更不可能正常运转了.本文将讲解如何基于heartbeat v1实现LVS

基于heartbeat v2 crm实现基于nfs的mysql高可用集群

前言 因heartbeat v1内置的资源管理器haresource功能比较简单,且不支持图形化管理,所以heartbeat v2不再支持haresource,转而使用更加强大的资源管理器crm进行集群管理.本文将讲解如何基于heartbeat v2 crm实现基于nfs的mysql高可用集群. 高可用实现 实验拓扑 实验环境 node1:172.16.10.123 mariadb-5.5.36 CentOS6.6 node2:172.16.10.124 mariadb-5.5.36 CentO