前几日接到一项新任任务，该任务要求将往昔部署于私有服务器之上的项目，全部迁移至云端予以部署。先前的发布流程实际上算是较为简易的，都是于本地完成打包操作，接着借助文件传输，把打好包的 jar 包或者前端编译好的文件夹，径直替换至服务器上。颇为传统且颇为直接。

然而，此次情形有所不同，老板期望上线流程能够具备更高的自动化程度，必须达成一键部署的效果，以此来削减人工操作，从而实现省时省力的目标。说实话，就我这样的开发人员而言，哪里做过这类工作呢。向来都是现成做好的流水线直接拿来使用便可以了，无奈人手不足，就直接要求我去做 。

接下来，我们要开始逐一地去尝试、探究一番，瞧瞧从私有服务器到转到云端部署，再到达成一键发布，这里面会碰到什么样的阻碍，有哪些是必须格外留意的要点。

除此之外还得提醒，每家公司的基础架构环境不一样，要求也各有区别，下面所讲的内容呢，更多是为新手提供参考，助力其理解，从而迈向入门，而具体的操作呀，则必须依据自身公司的现实情况去进行调整。

名词解释 #技术分享基础问题

首先我们先来搞清楚一些最基础的概念。

将其说成 ACR ，实际上也就是一个归私人所有的镜像仓库。此乃某里云那边的称谓（Cloud），然而事实上每一个云部件生产商均有类似这般的服务，像腾讯云就具备，只不过名称不一样罢了。其核心发挥的作用都是相同的，那便是用以储存已然打造完成的镜像。

为啥要采用私有仓库呢，是由于你没办法将你们公司的服务包发布至 Hub 这种公共仓库上去，如此一来既不安全，又不符合公司规范。故而我们会把自身的镜像推送至 ACR 这种私有仓库里，随后在部署服务时便从这里拉取镜像。

要说ACK，它是阿里云一款产品，全称是Cloud。它是托管化容器服务，也就是说，它把集群搭建、管理那整套繁杂操作封装好了。你只需关注如何让服务运行起来，不用操心集群、节点、控制面这些底层内容。

接下来，我要向众人阐述一下，那个 ACK 当中含有的一些基础理念以及相关内容，以此助力你更有效地领会它其究竟是依循怎样的方式来开展运作的。

首先，存在着命名空间，你能够将其简便地理解为类似“文件夹”这般的事物。它所具备的作用是助力你更为便利地对运行的镜像以及服务予以管理。这恰似你电脑当中的文件夹，把各异的东西按照类别放置妥当，进行查找以及维护的时候也会显得更加清晰且明了。

接下来要说的是，无状态节点以及有状态节点 ，这二者之间的差异主要体现在存储层面。无状态节点指的是，它们不会保管数据，一旦节点被破坏，数据也就随之消失，重新开始运行就如同全新创建的一般。与之相反，有状态节点是能够支持数据持久化的，能够进行存储绑定，数据不会有遗失情况发生。就像我们平常所开展的微服务，大多属于无状态性质的，这是因为它们能够随时被销毁并重新构建，用不着担忧数据丢失问题。你同样能够借助它们去查看访问的方式，像服务的公开以及路由规则这类情况。

来讲讲容器组，它能给你来个想象，是那种服务的“集合体”状。有个情况是，一个服务往往会存在多个副本节点着，啥是副本节点呢，就是有多个一模一样的容器一块儿同时是处在运行的状态。容器组便是要把这些副本进行集中管理的所在之地，在这儿你能够 sight 到每个副本节点的运行状态，并且还有它们的日志信息，这样就便利你进行问题排查或者监控运行的整个情况了 。

网络服务（）

他存在着好多不一样种类的情形，通过直接管控某一个微服务的全部节点副本，以此达成他的目标 。

仅于当下集群的“虚拟网络”之中产生效力，任何外部的实体，不管那个实体是另外的一个集群，抑或是你办公室的笔记本，均无法进行访问。→ 这等同于“房门仅在屋内开启” 。

要将服务端口映射至那个节点所处的那一层网络。要是节点归属私有网段（10.x/172.x/192.168.x），并且没有进行额外打通，那么外部或者另一个集群依旧无法访问。倘若节点是公网 IP，或者两个集群的 VPC/局域网路由/对等连接已经打通，那么外部或者另一个集群便能够凭借 : 进行访问。这就好比房门通向走廊，而走廊能否通达，取决于你俩是否置身于同一条走廊之中。

云厂商会帮你去额外主动申请一个公网负载均衡IP，或者是内网SLB加上公网绑定，不管节点自身有没有公网IP，都会给到你一个能够拿去在公网当中进行访问的具体地址，这一情况就相当于直接在大楼门口给你挂一个专门独立的门牌号，使得任何人都能够去按门铃 。

路由（）

居于同一公网入口IP加上端口之情形，按照域名或者路径，将流量区分至各异的后端，此事并无阐述之必要，你全然能够把它视作nginx来对待即可。

版本号为，网络相关的，Kubernetes的，v1这个版本号，属于，网络配置方面的，Kubernetes版本号为，network。
kind: Ingress
metadata:
  name: nacos3-ingress
  namespace: common
  labels:
    app: nacos3
    component: ingress
    ingress-controller: nginx
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /nacos-demo(/|$)(.*)
路径类型：特定于实现的 ，这是一种特定于实现的路径类型 。
        backend:
          service:
            name: nacos3
            port:
              number: 8080

当然，并非所有的路径分配都得写到同一个里面，比如说nginx，我们也会将各个项目的配置文件区分开来，如此这般，分开进行声明就行。

配置管理配置项

这是属于你Java项目的配置文件，它只是能够进行单独配置，然而我们基本都是借助Nacos来实施管理，并不会用这个，反而使用它的都是公共组件，诸如像这种类型的 。

apiVersion: v1
kind: ConfigMap
metadata:
  name: xxl-job-config
  namespace: common
  labels:
    app: xxl-job
    version: "3.2.0"
data:
  application.properties: |
    ### web
服务器端口等于8080，服务器.servlet路径的方面路径是/xxl-job-admin 。

界面查看查看效果如图所示：

保密字典

我们平常会将数据库的密码呀，亦或是一些加密文件之类的，通通放置于此地。最为常见的用途呢，就形如你若要从 ACR 拉取镜像，此时便需要预先把账号和密码配置妥当。不太相同的是，此处的类型不可采用普通的（如图所示）。

而是要用

.io/ 这个类型，专门用来存储镜像仓库的认证信息。

apiVersion: v1
data:
  .dockerconfigjson: >-
类别：机密，元数据：名称：acr，命名空间：微信应用，类型：Kubernetes 容器编排引擎的 Docker 配置 JSON 格式 。

皆是生成所得，要是并不明晰初始数据究竟是什么，那么能够自行于网络界面操作完毕后，将其复制出来查看一番。

存储

这块儿事儿主要为说每个服务分配存储空间，之前使用之际，操作尤为简单，当即挂载一个目录便可启用，并无特别之处，于服务启动之时指定一个目录，数据即能存储于彼处。然而抵达云上环境或者之时，情形便有所不同，于此无法如那般径直挂载目录。它们皆要求我们先行申请存储资源，随后将存储绑定至相应服务，不可采用本地目录之方式。

想象它如同编写Java代码的进程那般，首先撰写一个类，之后借助new弄出一个对象，随后才针对此对象去设定各类属性值 。

存储类

首先，这一步得先存在类。然后codejock dockingpane，关于你具体打算运用何种类型的磁盘，在某里云上全部能够看见。要是你进行使用，那就必须予以声明才行。

这属于已然存在着的资源呀，并非由我们来进行创建呢。当然啦，我是不会去运用命令的哟，毕竟我也需要先展开查询呀，关于 web 界面的操作情况是这样的：

点击后，你就能看到各个类型了。

存储卷

这个时候，你得着手开始 new 对象了，首先要明确写出你所需要的是什么样的磁盘，其容量具体是多大。然而，至于具体是给哪个人使用，存储卷的情况并不清楚。这仅仅只是一个属性值罢了。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nacos3-data-dev
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce

持久卷回收策略：保留,使得该卷在其所属的持久卷声明被删除后,不会被自动删除,而是保持其现有状态,以供后续可能的重新使用或。
储存类名称为阿里云磁盘固态硬盘 ，其中储存类名称是阿里云磁盘固态硬盘标点符号为冒号，冒号后面跟着阿里云磁盘固态硬盘，就是储存类名称为阿里云。
  hostPath:
    path: /mnt/nacos3-data/demo

申请好后，会显示在界面上。

存储声明

此时，便是设置属性值的阶段了。要直接将其与存储卷进行绑定，如此一来，整个流程便宣告完成了。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nacos3-pvc
  namespace: common
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
volume名称是，pv-nacos3-data-dev 。
  storageClassName: alicloud-disk-ssd

这个存储就可以给你的服务使用了。

volumes:
  - name: nacos3-storage
    persistentVolumeClaim:
      claimName: nacos3-pvc
  - name: nacos3-logs
    persistentVolumeClaim:
      claimName: nacos3-logs-pvc

环境配置

其次，云上环境的启动得以时日，此部分主要由甲方来承担操作事务。你无需过于忧虑，后续他们会将所有相关资讯都梳理完备并予以你。恰似账户的登陆通告、ACR（容器镜像服务）的账户与密码、ACK（容器服务）的密钥详情等等 。

换而言之，要是项目之中运用了云端的数据库服务，那么同样会一并给予数据库的连接信息。这些相关内容，我们会将其一同规整到一个表格文档之中去，以便利于你在其后的时间段进行查阅或者通过复制粘贴来加以运用，进而防止信息出现遗漏或者再度开启沟通。

跳板机

接下来讲讲服务的部署流程，一般状况下，咱们的服务都是会部署在内网环境当中，这意味着不会直接给予你一个公网地址供你去访问。所以，你这边一定要先申请开通一些防火墙规则，以此确保必要的网络能够通畅。具体而言，主要涉及到以下几个关键要点：

首要的是，需预备一台跳板机，跳板机所发挥的作用极为简易，那便是协助你径直去操控云端的 ACR（容器镜像仓库）以及 ACK（容器服务），要是你对于这些名词仍不太熟知，建议尽快去补充相关知识，如此一来后续操作将会顺畅许多，除此以外，这台跳板机还得予以部署，用以开展自动化构建以及部署的工作。

要使得跳板机能正常开展工作，就一定要预先将跳板机所处的网络以及、ACR、ACK这些服务的网络予以打通。倘若条件许可的话，还能够把Maven拉取的国内镜像仓库域名一同放开，如此构建速度便会快出许多。要是没办法打通Maven镜像的话，那你就需要手动把jar包上传到Maven私服，操作会繁杂一些。

对于为何非得申请跳板机，关键在于云上的 ACR 以及 ACK 管理界面操作起来颇为繁杂，径直经由界面开展某些批量操作或者进行复杂配置是极为不便的。具备了跳板机，你能够直接借助命令行去执行各类操作，效率会高出许多。当然咯，要是你比较热衷于折腾，也能够选择直接于云服务的 Web 界面采用 yaml 文件格式来创建并管理资源，这两种方式都行得通。

环境

必须要有跳板机所需的预置环境，以及命令，要是没有的话，就得临时开通外网权限自行安装，要是进行源代码编译，就会碰到诸多莫名其妙的问题，这远远超出开发的能力范围了。

紧随其后你还得去配置一下的那个环境，其目的在于能够运用命令去操作 ack 环境。要是你尚未拥有那就去下载一回。

然后跟着教程走就行。这部分没啥难度。

环境

要想正常打包项目并推送过去，就得提前登录到 acr 环境，不然 ack 拉取不到镜像，命令会提示给你。我把 acr 的命名空间用于隔离生产和测试环境了，得提前创建好，不然直接推送到 acr 会报错。

所有登录方面的相关信息，都会于镜像指南那儿提供予你，acr登录账密的开通人员同样会提供给你，径直依照教程去操作就行。

接下来便进入到了实施部署的阶段，由于我们已经将网络的基础部分顺利予以打通。为了达成便于启动的目的，我径直运用进而开启其运作的是容器，相关文件具体展列如下：

version: '3'
服务：詹金斯：镜像：詹金斯/詹金斯：长期支持版，容器名称：詹金斯 - 2.481，重启：总是，特权：真，网络： - 詹金斯，环境：DOCKER_TLS_CERTDIR：/certs/客户端，卷： - /数据/詹金斯/詹金斯数据/证书：/certs/客户端：只读， - /数据/詹金斯/詹金斯数据：/var/詹金斯家， - /数据/ Maven：/根/.m2， - /var/运行/ Docker.sock：/var/运行/ Docker.sock， - /usr/bin/ Docker：/usr/bin/ Docker， - ~/.docker：/根/.docker：只读， - /usr/local/bin/kubectl：/usr/local/bin/kubectl， - /数据/npm缓存：/根/.npm，端口： - “8080 ：8080”，用户：根 。
网络，其中jenkins，驱动程序，桥接 。

在这里，我预先将mvn的仓库目录进行了挂载显露，包括前端编译所产生的缓存包，以及相关的系列命令，进而能够对ack展开操作。好可以，接下来则是启动行为，启动之后直接去安装被推荐的插件。有能力多安装就不要少安装codejock dockingpane，毕竟我们仅仅是处于单纯的开发阶段环境。首先需要确保能够正常地运行流水线再说。针对这一部分所欠缺缺少的插件，一旦遭遇遇到报错情况，我也就当即进行了安装，只不过忘记做好记录记载了，只要流水线处于报错状态，你便前往插件商店去进行安装就行。或者自行手动进行上传。

账密配置

之所以账密以及秘钥信息都得预先于之中为配置好，是鉴于存在对git、acr、ack这些服务进行操作的需求。如图所示：

进入后，然后点击页面的 ，如图所示：

随后你去点击新增此项即可，要是属于账密类型的，那你便进行选择，采用with方式 ，比如说ack属于配置信息范畴，是我直接予以创建的 file。

这样基本就可以了。

项目相关

由于每一个项目结构之中都不存在关乎 或者 这类的 k8s 文件处于该结构内里，因而此类之情况都是分开在单独的一个项目当中，随后再复制出来以供其他项目去运用，在创建好项目过后，我这里径直创建出一个自由风格的项目，如图所示：

然后配置下 git 仓库地址即可，如图所示：

然后在配置下构建后的操作，如图所示：

在这儿，我把处于 uat 目录里头那个所有的文件，都给归档到工作空间那儿去了。如此这般，在你去保存以便能够进行构建任务的时候，就会生成出一个可供其他所有任务去使用的文件。就如同图里所展示的那样：

余留的项目皆为流水线项目。径直去创建一下。于此你能够运用git来管理流水线，亦能够径直于脚本之中撰写流水线，均可的，为了能够迅速予以验证，我在此处率先采用的是脚本 。

一个项目的脚本如下：

pipeline {
    agent any
    tools {
如果在Global Tool里名为Maven - 3.9，那就使用这个叫做Maven 'Maven - 3.9'的工具 。
    }
在环境设置里，所有配置都直接以硬编码的方式设定为测试环境，其中，阿里云容器镜像仓库地址为“**cr.aliyuncs.com”，应用名称是“**”，容器镜像仓库命名空间为“**”，这里固定使用开发命名空间，凭证ID方面，代码仓库凭证ID是“git”，容器镜像仓库登录凭证ID是“acr - credentials”，不过这个需要您去创建，kubeconfig凭证ID是“ack - dev”，此固定使用测试环境的kubeconfig，代码库信息固定，代码仓库URL为“**.git”，分支是“uat - cloud”，关于Maven命令，其打包命令是“mvn clean package -Dmaven.test.skip=true” 。
这里并非是要你改写一段代码信息呀，你提供的内容本身主要是代码片段相关，不太符合按照特定要求改写句子并输出的任务性质呢。请你提供合适的可改写的句子，以便我按照规则进行操作。 所以请你明确给出一个完整的、可改写的句子，比如：小明去学校上学。 这样我就能为你进行改写啦。  如果你只是想对这段代码相关内容进行润色等其他操作，可进一步说明需求。  但。
阶段 { 阶段(“检查代码_out”) { 步骤 { 回显 “开始从 ${GIT_URL} 拉取分支 ${GIT_BRANCH}...” 执行命令:git 凭证输入,识别码:GIT_CRED_ID, 网址:string:GIT_URL, 分支:string:GIT_BRANCH} } }。
stage('Maven Build') { steps { withCredentials([file(credentialsId:'maven-settings-nexus', variable: 'MVN_SETTINGS')]) { sh'mvn -s $MVN_SETTINGS clean package \ -Dmaven.test.skip=true' } } } 这里按步奏，通过凭证参数获取私服设置文件，执行maven清理打包命令跳过测试。 stage('Copy Dockerfile') { steps { copyArtifacts( projectName: '**', selector: lastSuccessful(), target: 'docker-tmp' ) sh 'cp docker-tmp/uat/docker/Dockerfile.' } } 此步骤负责复制共享Job生成的Dockerfile到当前工作区 。
处于名为‘Build & Push Image’的阶段，步骤如下，脚本内容为（引号里：利用docker，构建并推送镜像，构建一个带有特定标签的镜像，标签为${FULL_IMAGE_NAME}，并且构建时使用指定的构建参数JAR_FILE，其值为target/*.jar，基于当前目录进行构建，之后推送其标签为${FULL_IMAGE_NAME}的镜像） 。
stage('Deploy to ACK')，具有步骤。步骤里包含如下内容：script部分的步骤中有，把共享Job产生的Dockerfile复制到当前工作区，具体操作是copyArtifacts，其projectName为'**'，selector是lastSuccessful()，target为'docker-tmp'。并且执行sh 'cp docker-tmp/uat/k8s/**.yaml.'用于复制文件。还有使用测试环境的kubeconfig进行部署，具体是withCredentials，其中credentialsId为KUBECONFIG_CRED_ID，variable为'KUBECONFIG_FILE'。之后更新镜像标签并部署，执行sh "kubectl --kubeconfig=${KUBECONFIG_FILE} apply -f **.yaml"，最后查看部署状态，执行sh "kubectl --kubeconfig=${KUBECONFIG_FILE} get pods -l app=${APP_NAME}" 。
post，总是，执行cleanWs() 。

小结

大体而言，此次历经从私有服务器迁移至云端部署，而后再到一键发布之举，着实算得上是硬着头皮前去应对，全程一边不断踩坑一边进行摸索。对于身为写 Java 类别的我来讲，平日里鲜少去接触这些云原生相关的事物，比方说 ACK、ACR、跳板机等，起初的时候真的是一脸茫然。然而逐步推进下来，实际上其逻辑并非繁杂，关键之处在于流程必须梳理清晰、配置务必要牢记于心。期望这篇记录能够对和我一样“被拉来帮忙”的开发同学存有一定帮助，勿要像我这般每次皆从零开始盲目摸索。身处的环境存在差异，具体的细节也不一样，然而大方向基本上是相近的，依照着去做肯定能够开展起相关行动。希望我们大家都能够减少踩中那些坑洼，进一步早日结束工作下班回家！

如有侵权请联系删除！