ARM芯片的node-sass支持

用M1芯片的博友越来越多了，但node-sass，在高版本的nodejs上一直不能正常使用，下面来说说如何在ARM芯片上把node-sass跑起来。

直奔主题： 自打M1问世，node-sass的作者就一直没有想着更好的支持arm，所以：降级！

我是在mac M1芯片的docker中进行测试的，因为宿主机的环境有些复杂。

开docker容器

1
2
3
4
5
docker run -ti \
-p 20081:8080 \
-v /Users/ryan/dockerdata/uni_node14:/root/uni \
--name uni_node14 centos:7 \
bash

映射了8080端口和一个路径，这样方便文件操作和访问。

在docker中安装nodejs14

1
2
3
4
curl -sL https://rpm.nodesource.com/setup_14.x | bash -
yum list nodejs --showduplicates | sort -r   #列出所有版本
# 默认安装最新版本,安装指定版本
yum install nodejs-14.16.0 -y

这里我用了nodejs 14.16.0

安装node-sass

因为sass的安装需要编译环境，所以先yum装对应的包

1
yum install gcc cmake automake autoconf libtool make gcc-c++ kernel-devel

安装node-sass

1
npm install node-sass@4.14.0 --sass_binary_site=https://npm.taobao.org/mirrors/node-sass/

注意这里的版本 4.14.0 。

至此，ARM上node-sass安装完毕。

Gitlab持续集成「PHP篇」

《Gitlab持续集成Runner的安装与配置》

《Gitlab持续集成详细配置与工作原理》

《为Gitlab持续集成打造一个部署用的docker》

《Gitlab持续集成「springboot篇」》

《Gitlab持续集成「PHP篇」》

《Gitlab持续集成「VUE篇」》

PHP项目不要要编辑，一个job可以搞定。

发布节点用到的镜像centos7-sshpass:1.0.0详见 《为Gitlab持续集成打造一个部署用的docker》

案例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
stages:
  - deploy

deploy_dev:
  stage: deploy
  image: 'centos7-sshpass:1.0.0'
  script:
    - ls ./ -lah
    # 清除原有
    - sshpass -p abc ssh -p 1234 -o StrictHostKeychecking=no root@localhost "rm -fr /path/to/pub/*"
    # 拷贝文件包
    - sshpass -p abc scp -o StrictHostKeyChecking=no -P 1234 -r ./* root@localhost:/path/to/pub/
  tags:
    - runner_test
  only:
    changes:
      - dev_ver


deploy_test:
  stage: deploy
  image: 'centos7-sshpass:1.0.0'
  script:
    - ls ./ -lah
    # 清除原有
    - sshpass -p abc ssh -p 1234 -o StrictHostKeychecking=no root@localhost "rm -fr /path/to/pub/*"
    # 拷贝文件包
    - sshpass -p abc scp -o StrictHostKeyChecking=no -P 1234 -r ./* root@localhost:/path/to/pub/
  tags:
    - runner_test
  only:
    changes:
      - dev_ver

如果：

  • 项目根目录下的 dev_ver被修改，则会触发 deploy_dev:
  • 项目根目录下的 test_ver被修改，则会触发 deploy_test:

Gitlab持续集成「VUE篇」

《Gitlab持续集成Runner的安装与配置》

《Gitlab持续集成详细配置与工作原理》

《为Gitlab持续集成打造一个部署用的docker》

《Gitlab持续集成「springboot篇」》

《Gitlab持续集成「PHP篇」》

《Gitlab持续集成「VUE篇」》

java、vue等项目需要编译，所以，至少有两个job，一个是用 nodejs 镜像打dist包，一个是发布到对应位置。

发布节点用到的镜像centos7-sshpass:1.0.0详见 《为Gitlab持续集成打造一个部署用的docker》

案例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
stages:
  - prepare
  - deploy

prepare:
  stage: prepare
  image: 'node:16.14.0'
  cache:
    key: "$CI_COMMIT_REF_NAME"
    paths:
      - node_modules/
      - dist/
  script:
    - npm install
    - npm run build:prod
    - ls dist/ -lah
  tags:
    - runner_test
  only:
    changes:
      - dev_ver
      - test_ver
deploy_dev:
  stage: deploy
  image: 'centos7-sshpass:1.0.0'
  cache:
    key: "$CI_COMMIT_REF_NAME"
    paths:
      - dist/
  script:
    - ls dist/
    # 清除原有
    - sshpass -p abc ssh user@localhost -o StrictHostKeychecking=no "rm -fr /path/to/pub/*"
    # 拷贝dist包
    - sshpass -p abcc scp -o StrictHostKeyChecking=no -p -r dist/*.* user@localhost:/path/to/pub/
  tags:
    - runner_test
  only:
    changes:
      - dev_ver

deploy_test:
  stage: deploy
  image: 'centos7-sshpass:1.0.0'
  cache:
    key: "$CI_COMMIT_REF_NAME"
    paths:
      - dist/
  script:
    - ls dist/
    # 清除原有
    - sshpass -p abc ssh user@localhost -o StrictHostKeychecking=no "rm -fr /path/to/pub/*"
    # 拷贝dist包
    - sshpass -p abcc scp -o StrictHostKeyChecking=no -p -r dist/*.* user@localhost:/path/to/pub/
  tags:
    - runner_test
  only:
    changes:
      - test_ver

以上这个案例，定义了两个环节 prepare和deploy，有三个job：

  • prepare: 在dev_ver或test_ver被修改时会被触发
  • deploy_dev: 在dev_ver被修改时会被触发
  • deploy_test: 在test_ver被修改时会被触发

那么，如果：

  • 项目根目录下的 dev_ver被修改，则会触发 prepare: 和 deploy_dev:
  • 项目根目录下的 test_ver被修改，则会触发 prepare: 和 deploy_test:

Gitlab持续集成「springboot篇」

《Gitlab持续集成Runner的安装与配置》

《Gitlab持续集成详细配置与工作原理》

《为Gitlab持续集成打造一个部署用的docker》

《Gitlab持续集成「springboot篇」》

《Gitlab持续集成「PHP篇」》

《Gitlab持续集成「VUE篇」》

java、vue等项目需要编译，所以，至少有两个job，一个是用 maven镜像打jar包，一个是发布到对应位置。

发布节点用到的镜像centos7-sshpass:1.0.0详见 《为Gitlab持续集成打造一个部署用的docker》

案例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
# 定义了两个流程
stages:
  - prepare
  - deploy

prepare:    # job的名称，可以随便起
  stage: prepare    #这里要跟 stages 里面定义的保持一致
  image: 'maven:3.6.3-openjdk-8'    #用哪个镜像
  cache:    # 缓存
    policy: pull-push   #缓存方式 有 pull push pull-push
    key: ${CI_COMMIT_REF_SLUG}  #按照分支进行缓冲
    paths:
      - target/     #把target目录缓冲下来给下一步用
  script:   #执行脚本
    - mvn -v && java -version
    - mvn clean install
  tags:
    - java01    #对应的Runner的TAG，多个runner可以用同样的tag，到时候gitlab来分配具体用哪个runner来执行
  only:
    changes:    此步骤（job）通过文件修改来触发，下面定义的意思是，这两个文件其中一个有修改即触发执行
      - dev_ver
      - test_ver


deploy_dev:     #往dev版发布
  stage: deploy     #这里要跟 stages 里面定义的保持一致
  image: 'centos7-sshpass:1.0.0'
  cache:
    policy: pull  #只读不写
    key: ${CI_COMMIT_REF_SLUG}  #按照分支进行缓冲
    paths:
      - target/
  script:
    - ls ./target/
    # 拷贝jar包
    - sshpass -p abcd scp -o StrictHostKeyChecking=no -P 1234 target/demo-0.0.1-SNAPSHOT.jar root@localhost:/app/demo-0.0.1-SNAPSHOT.jar
    # 运行脚本
    - sshpass -p abcd ssh -p 1234 root@localhost "/app/jenkins_restart.sh demo-0.0.1-SNAPSHOT >> /app/jenkins_restart.log"
  tags:
    - java01
  only:
    changes:    #这里仅针对dev_ver的修改触发
      - dev_ver
    

deploy_test:    #往test版发包
  stage: deploy
  image: 'centos7-sshpass:1.0.0'
  cache:
    policy: pull  #只读不写
    key: ${CI_COMMIT_REF_SLUG}  #按照分支进行缓冲
    paths:
      - target/
  script:
    - 。。。。。。
  tags:
    - java01
  only:
    changes:
      - test_ver    #仅 文件 test_ver修改时候触发

以上这个案例，定义了两个环节 prepare和deploy，有三个job：

  • prepare: 在dev_ver或test_ver被修改时会被触发
  • deploy_dev: 在dev_ver被修改时会被触发
  • deploy_test: 在test_ver被修改时会被触发

那么，如果：

  • 项目根目录下的 dev_ver被修改，则会触发 prepare: 和 deploy_dev:
  • 项目根目录下的 test_ver被修改，则会触发 prepare: 和 deploy_test:

为Gitlab持续集成打造一个部署用的docker

《Gitlab持续集成Runner的安装与配置》

《Gitlab持续集成详细配置与工作原理》

《为Gitlab持续集成打造一个部署用的docker》

《Gitlab持续集成「springboot篇」》

《Gitlab持续集成「PHP篇」》

《Gitlab持续集成「VUE篇」》

因为docker化部署的Runner，每一部都需要在容器中完成，针对没有完全使用k8等容器化运维的项目或者项目构建过程中需要做额外操作的ci/cd流程，使用官方容器就比较尴尬：

  • 打包好的目标文件，在maven、nodejs容器因为没有对应的命令，无法上传到指定位置
  • ci/cd过程复杂，需要跟其他服务交互

这种情况，咱们就得自己包docker image来给Runner用。

ceontos-sshpass

为了应对以上问题，笔者自己包了个发版的docker，地址在 https://github.com/ryangsun/centos7-sshpass

构建镜像

1
2
3
git clone https://github.com/ryangsun/centos7-sshpass.git
chmod 700 build-image.sh
./build-image.sh

默认创建的docker镜像为 centos7-sshpass:1.0.0，233M大小。

Gitlab持续集成详细配置与工作原理

《Gitlab持续集成Runner的安装与配置》

《Gitlab持续集成详细配置与工作原理》

《为Gitlab持续集成打造一个部署用的docker》

《Gitlab持续集成「springboot篇」》

《Gitlab持续集成「PHP篇」》

《Gitlab持续集成「VUE篇」》

Gitlab Runner 窍门

解决gitlab Runner 执行 job时反复拉取镜像的问题

编辑 /etc/gitlab-runner/config.toml

找到 shm_size = 0 段
添加

1
pull_policy = "if-not-present"

每次都要cache的内容可直接放到配置文件中

因为在docker方式中，每次job拉起镜像，都是崭新的，所以在构建Java项目时，.m2文件夹不存在，导致每次都需要重新下载全量jar包。
的确可以通过 gitlab-ci.yml中的cache段来解决，但每次写实在太麻烦，所以这个配置，也可以通过编辑 /etc/gitlab-runner/config.toml来解决。

找到 volumes = ["/cache"]段，修改为

1
volumes = ["/cache","/dockerdata/gitlab-runner-java01/root/.m2:/root/.m2"]

其中"/dockerdata/gitlab-runner-java01/root/.m2:/root/.m2" 与docker -v参数的传值类似，冒号前面是宿主机路径，后面是容器内路径。

基本原理

  • 不管我们用什么方式安装的gitlab，本身并不具备cicd功能，需要安装配套的Runner来具体做事。
  • Docker方式部署的runner也不直接做打包发布的事情，而是通过定义不同环节用哪个docker容器来完成任务，这种方式下的runner，其实就是个管控器。
  • 何时触发构建动作、由谁执行构建动作、如何构建，需要在项目根目录下的 gitlab-ci.yml 来定义。

运行方式

触发

gitlab的 pipeline既可以自动触发，也可以通过gitlab界面的cicd相关页面手动触发，这取决于在gitlab-ci.yml中如何配置。

  • 手动触发：gitlab项目页面 -> 左侧"CI/CD" -> 右侧按钮"Run Pipeline"
  • 自动触发：gitlab-ci.yml 中，每个job的 only 段，方式非常灵活，可按照 分支提交动作、文件修改动作 等等方式。

only案例，修改文件触发构建

作为开发人员，最方便的莫过于修改本地文件然后提交了，以下方式，只需要在项目根目录创建两个文件dev_ver和test_ver，分别对应自动部署到开发版和测试版。
当gitlab获取到提交请求时，会自动扫描gitlab-ci.yml文件，如果对应的文件有修改，则进行对应的构建和发布操作。

1
2
3
4
only:
  changes:
    - dev_ver
    - test_ver

only案例，手动触发

如果想通在gitlab网页界面上操作，可采用这种变量传值方式：

1
2
3
4
only:
  variables:
    - $RELEASE == "dev"
    - $RELEASE == "test"

此时，gitlab项目页面 -> 左侧"CI/CD" -> 右侧按钮"Run Pipeline"，在对应的页面中变量栏key输入 RELEASE,value栏输入dev，则会触发此规则。

阶段

以下信息描述了两个阶段 prepare和deploy阶段

1
2
3
stages:
- prepare
- deploy

当然，可以制定更多的阶段（Job），对于docker方式的Runner而言，每个阶段都会临时启动一个docker来执行对应的任务。

执行

在每个执行阶段中，我们需要定义：

  • 触发规则 only
  • 采用的镜像 image
  • 运行的脚本 script
  • 缓冲（为了下一环节能用到上一环节的作业成果） cache

执行案例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
# 定义了两个流程
stages:
  - prepare
  - deploy

prepare:    # job的名称，可以随便起
  stage: prepare    #这里要跟 stages 里面定义的保持一致
  image: 'maven:3.6.3-openjdk-8'    #用哪个镜像
  cache:    # 缓存
    policy: pull-push   #缓存方式 有 pull push pull-push
    key: ${CI_COMMIT_REF_SLUG}  #按照分支进行缓冲
    paths:
      - target/     #把target目录缓冲下来给下一步用
  script:   #执行脚本
    - mvn -v && java -version
    - mvn clean install
  tags:
    - java01    #对应的Runner的TAG，多个runner可以用同样的tag，到时候gitlab来分配具体用哪个runner来执行
  only:
    changes:    此步骤（job）通过文件修改来触发，下面定义的意思是，这两个文件其中一个有修改即触发执行
      - dev_ver
      - test_ver


deploy_dev:     #往dev版发布
  stage: deploy     #这里要跟 stages 里面定义的保持一致
  image: 'centos7-sshpass:1.0.0'
  cache:
    policy: pull  #只读不写
    key: ${CI_COMMIT_REF_SLUG}  #按照分支进行缓冲
    paths:
      - target/
  script:
    - ls ./target/
    # 拷贝jar包
    - sshpass -p abcd scp -o StrictHostKeyChecking=no -P 1234 target/demo-0.0.1-SNAPSHOT.jar root@localhost:/app/demo-0.0.1-SNAPSHOT.jar
    # 运行脚本
    - sshpass -p abcd ssh -p 1234 root@localhost "/app/jenkins_restart.sh demo-0.0.1-SNAPSHOT >> /app/jenkins_restart.log"
  tags:
    - java01
  only:
    changes:    #这里仅针对dev_ver的修改触发
      - dev_ver
    

deploy_test:    #往test版发包
  stage: deploy
  image: 'centos7-sshpass:1.0.0'
  cache:
    policy: pull  #只读不写
    key: ${CI_COMMIT_REF_SLUG}  #按照分支进行缓冲
    paths:
      - target/
  script:
    - 。。。。。。
  tags:
    - java01
  only:
    changes:
      - test_ver    #仅 文件 test_ver修改时候触发

以上这个案例，定义了两个环节 prepare和deploy，有三个job：

  • prepare: 在dev_ver或test_ver被修改时会被触发
  • deploy_dev: 在dev_ver被修改时会被触发
  • deploy_test: 在test_ver被修改时会被触发

那么，如果：

  • 项目根目录下的 dev_ver被修改，则会触发 prepare: 和 deploy_dev:
  • 项目根目录下的 test_ver被修改，则会触发 prepare: 和 deploy_test:

Gitlib持续集成Runner的安装与配置

《Gitlab持续集成Runner的安装与配置》

《Gitlab持续集成详细配置与工作原理》

《为Gitlab持续集成打造一个部署用的docker》

《Gitlab持续集成「springboot篇」》

《Gitlab持续集成「PHP篇」》

《Gitlab持续集成「VUE篇」》

首先，gitlab不做持续集成的事儿，只是发送指令和接收结果，实际做cicd的是Runner。安装和配置runner有集中方式，这里记录两种：

docker方式，非常轻便灵活

展开容器

1
2
3
4
5
6
docker run -d \
--name gitlab-runner-docker \
--restart always \
-v /dockerdata/gitlab-runner-docker/etc/gitlab-runner:/etc/gitlab-runner \
-v /var/run/docker.sock:/var/run/docker.sock \
gitlab/gitlab-runner:latest

接入对应的gitlab

1
docker exec -it gitlab-runner-docker gitlab-runner register

接着会询问gitlab的地址、token ，这两个信息，可以在我们自己gitlab的 admin->概览->Runner中查询到。

之后会询问 这个runner的名字和tag，tag这里要注意，会影响到实际cicd中的调用，因为跑自动化的时候是可以通过tag来指定runner的。

交互式提问结束后，在gitlab的Runner页面，应该有对应的Runner注册上来了。

Centos中通过ssh连接

添加yum源

1
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash

安装runner

1
yum install gitlab-ci-multi-runner

向GitLab-CI注册runner

1
gitlab-ci-multi-runner register

后面的步骤跟docker方式类似，gitlab的路径、token，连接方式选ssh，然后把本机的IP、ssh端口、账号密码录入进去。

配置过程（以docker方式为例）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# docker exec -it gitlab-runner-java01 gitlab-runner register
Runtime platform                                    arch=amd64 os=linux pid=24 revision=5316d4ac version=14.6.0
Running in system-mode.                            
                                                   
Enter the GitLab instance URL (for example, https://gitlab.com/):
<这里输入gitlab私仓的url>
Enter the registration token:
<这里输入runner的token>
Enter a description for the runner:
[007fa02670d1]: <给这个runner起个名字，会显示在gitlab中>
Enter tags for the runner (comma-separated):
<这里输入tag，跑任务的时候可以通过 tags 来指定>
Registering runner... succeeded                     runner=rANP_dLs
Enter an executor: docker, docker-ssh, parallels, shell, virtualbox, docker+machine, custom, ssh, docker-ssh+machine, kubernetes:
<运行方式，这里写 docker>
Enter the default Docker image (for example, ruby:2.6):
<默认运行容器，如果在job中不指定容器，默认采用的运行容器，这里我添了 tico/docker>
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

Harbor SSL避坑指南

Harbor的安装与配置请参考这里Harbor的安装与配置

Docker默认情况下，push和pull对应的仓库均需要ssl加密，如果我们在内网采用Harbor作为私仓，有两种方案可以解决：

  • Harbor开启ssl
  • docker侧修改配置文件，并且需重启docker服务

实际情况是，docker因为承载的服务较多，无法选择重启方案，那么就必须采用第一种方案。这种方案：

  • harbor侧开启ssl
  • 对应的docker服务侧需要拷贝对应的签名证书

Harbor开启ssl

创建ssl证书

1
2
3
4
5
6
7
8
9
创建一个证书文件夹
mkdir harbor_cert && cd harbor_cert
# 创建ca时，根据提示输入 IP地址
openssl req  -newkey rsa:4096 -nodes -sha256 -keyout ca.key -x509 -days 365 -out ca.crt
openssl req  -newkey rsa:4096 -nodes -sha256 -keyout server.key -out server.csr
# 把IP地址写入到文件中
echo subjectAltName = IP:xx.xx.xx.xx > extfile.cnf
# 生成 cr
openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -extfile extfile.cnf -out server.crt

配置Harbor

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
cd harbor2.3/
vim harbor.yml

#修改对应的配置项目：
# https related config
https:
  # https port for harbor, default is 443
  port: 10443
  # The path of cert and key files for nginx
  certificate: /root/harbor_cert/server.crt
  private_key: /root/harbor_cert/server.key
#保存

#使配置生效
./prepare

#重启Harbor
docker-compose down -v
docker-compose up -v

拷贝对应签名文件到docker服务侧

1
2
3
scp server.crt  root@<docker侧主机>:/etc/docker/certs.d/<Harbor主机IP>:<harbor主机端口>/
scp ca.crt  root@<docker侧主机>:/etc/docker/certs.d/<Harbor主机IP>:<harbor主机端口>/
scp server.key root@<docker侧主机>:/etc/docker/certs.d/<Harbor主机IP>:<harbor主机端口>/

这里注意的是：如果Harbor侧ssl的监听端口为443，则docker侧的路径为

1
/etc/docker/certs.d/<Harbor主机IP>/

否则为

1
/etc/docker/certs.d/<Harbor主机IP>:<harbor主机端口>/

测试

1
docker login <Harbor主机IP>:<harbor主机端口>

这样，无需重启docker服务，即可实现内网harbor私仓的正常使用。

相关的docker对应的官方文档

用DinD方式构建docke用DinD方式构建docker

Docker in Docker(dind)

Docker in Docker(dind) image可以用于Jenkins做build， 可以在一台机器上起多个docker image，每个image里面安装不同的第三方，形成不同的build环境，然后可以将待编译的代码SCP或GIT过去，用指定账号SSH来进行编译，达到一个机器多种编译环境的效果，提高了效率。Docker in Docker(dind) 镜像基于centos7，可用于jenkins打包编译：

  • 基础镜像: centos7
  • 内置用户：jenkinsbuild, 密码: jenkinsbuild, 构建文件夹: /home/jenkinsbuild/ci-jenkins
  • 采用ssh login方式登录

构建和使用镜像

构建镜像

1
./build-centos7-dind

展开容器

1
2
3
4
5
6
7
docker run -d -p 22 \
--name=centos7-dind \
-e TZ=Asia/Shanghai \
-e LANG=en_US.UTF-8  \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /usr/bin/docker:/usr/bin/docker \
centos7-dind:1.0.0

将打代码copy到容器

1
scp -P \<port\> -r \<buildsourcecode\> jenkinsbuild@localhost:/home/jenkinsbuild/ci-jenkins/

ssh 登录进去

1
ssh -p \<port\> jenkinsbuild@localhost

免密登录

1
将对对应公钥copy到 /home/jenkinsbuild/ 对应位置即可。

git地址

https://github.com/ryangsun/centos7-dind

Jenkins远程docker构建方案

背景介绍

Jenkins，包括idea，有很多集成方案构建docker，但是因为网络结构、构建环境等客观原因，集成性的方案并不能满足需求。如：

  • Jenkins权限限制；
  • Jenkins已经是docker化部署，无法嵌套集成方案；
  • 构建环境不唯一，需要多个docker环境分别构建；
  • Jenkins端无私仓权限，无法把构建好的docker部署到指定位置。

这时，基于DinD的构建方案就非常方便了。

安装与部署DinD容器

容器的Dockerfile见这里：

https://github.com/ryangsun/centos7-dind

安装和部署介绍见

docker构建环境搭建

免密登录

1、将jenkins对应使用的私钥copy到dind容器的对应文件中：

1
scp -P <DinD容器端口> <Jenkins私钥文件> <DinD容器>:/home/jenkinsbuild/.ssh/....

2、Jenkins创建新的远程主机连接

3、Jenkins SSH Publishers配置：

image-20210705115301268

第一步：针对一般的java项目，需要将jenkins打包好的jar文件和对应的Dockerfile拷贝到DinD容器。上图中，我们开了两个Transer Set，一个拷贝了.jar文件，一个拷贝了项目对应的Dockerfile。

第二步：远程执行命令构建docker:

1
2
3
4
5
6
#进入构建目录并构建Docker
cd ~/ci-jenkins/${JOB_NAME} && docker build -t <私仓IP>:<私仓端口>/mytest/${JOB_NAME}:${BUILD_ID} .
#将构建好的docker推到私仓
docker push <私仓IP>:<私仓端口>/mytest/${JOB_NAME}:${BUILD_ID}
#推私仓成功后，删除本地的docker image
docker rmi <私仓IP>:<私仓端口>/mytest/${JOB_NAME}:${BUILD_ID}

第三步：触发后续操作，如Rancher构建等。