每天学习一点点

test 所在位置如下图所示，用来在打包时动态替换配置文件的，比如测试环境需要测试的配置文件，开发环境需要开发的配置文件，那么在发布测试版本时，就用如下的配置方式来激活测试配置文件。以上方式创建的工程，需要确保Tomcat的webapps目录中，有manage文件夹，这个文件夹是在下载Tomcat时自带的，用来显示Tomcat的管理页面。在服务中找到Jenkins，然后找到‘登录’，选择‘此账号’，点击浏览，输入administrator，自动会加载管理员账号，然后输入密码，点击确定。

在学习阶段，为了能快速部署Kubernetes，这里用一个快速安装工具：Kubeode，来完成Kubernetes的部署。接下来部署一个单机，一主一从的Kubernetes。一主一从都部署在同一台服务器上。在虚拟机新开一个服务器，ip配置为192.168.1.13，Kubernetes在这台新服务器上进行部署。

因 为这些应⽤运⾏在容器⾥，它们不会影响运⾏在同⼀台服务器上的其他应⽤，当你是为完全不同的组织机构运⾏应⽤时，这就很关键了。容器云平台需要解决的最核⼼的问题是应⽤运⾏，Kubernetes 将容器化应⽤运⾏的实体抽象为Pod，Pod 类似⾖荚，它是⼀个或者多个容器镜像的组合。kubelet是运⾏在每个节点上的负责启动容器的重要的守护进程。etcd是⾼可⽤的键值对的分布式安全存储系统，⽤于持久化存储集群中所有的资源对象，例如集群 中的Node、Service、Pod的状态和元数据，以及配置数据等。

前面通过执行脚本的方式，完成了pipline流水线的构建。脚本是保存在Jenkins中的，这种方式不利于迁移，也不利于查找脚本的历史变更信息。通过把脚本放到GitLab中，然后在Jenkins中引用的方式来解决上述的问题。

前面已经完成了，通过在Jenkins中创建自由风格的工程，在界面上的配置，完成了发布、构建的过程。这种方式的缺点就是如果要在另一台机器上进行同样的配置，需要一项一项去填写，不方便迁移，操作比较麻烦。解决这个问题，就要用到纯脚本方式的操作，用pipline流水线。

在之前的Jenkins配置中，固定写死了程序的版本号，实际情况是随着版本的不断迭代，版本号也是不断变化的，版本号由代码仓库（GitLab）设置。当前Jenkins配置是固定写的1.0，本节我们要把它改成动态的，随着代码的版本自动更新。

前面已经把harbor搭建好了，也可以向harbor中推送自定义镜像。原计划是在Jenkins这台服务器上，完成镜像构建，然后把镜像推送的harbor仓库中。现在改变计划了，Jenkins所在的服务器（192.168.1.10）不负责镜像构建工作，镜像构建工作放到harbor所在的服务器（192.168.1.12）上完成。这样做的好处是，Jenkins的职责更加清晰，它只是为了完成流水线的事情（自动化工具）。为了完成整个CI/CD的工作，在harbor所在的服务器上，完成。

注意，如要要在服务器上拉取镜像，需要先在/etc/docker/daemon.json文件中配置"insecure-registries": ["192.168.1.12:85"]，这样才能让docker知道镜像仓库地址，否则docker无法拉取镜像。命令执行完毕，可以通过docker images 查看到最新命名的镜像（注意镜像ID与原镜像相同，说明是同一个镜像，只是起了一个新的名称，为了满足harbor的要求）现在把自己构建的镜像，上传到harbor镜像仓库中（192.168.1.12）

当前的操作模式如下，Jenkins去GitLab中获取源代码，然后编译打包为jar，再把jar文件和Dockerfile文件上传到目标服务器上，在目标服务器上完成镜像的构建和容器的生成。这种做法的缺点是如果有多台目标服务器，那就需要在每台目标服务器上都做镜像构建的动作。而且目标服务器一般就是生产环境运行的服务器，在这里做镜像构建的操作，并不是一个好的选择。

前面已经顺利完成了jar文件的打包和发布，但在实际使用时，可能会遇到外部依赖环境发生改变，为了解决这些问题，更多的是把应用程序以docker镜像，生成容器的方式运行，这是一种标准化的方式。

01什么是DevOps02DevOps基础环境准备03-DevOps-安装并初始化Gitlab04-DevOps-安装并初始化Jenkins05-DevOps-Jenkins自动拉取构建代码105-DevOps-Jenkins自动拉取构建代码206-DevOps-自动构建Docker镜像07-DevOps-安装部署Harbor镜像仓库08-DevOps-向Harbor上传自定义镜像09-DevOps-Jenkins实现CI持续集成10-DevOps-Jenkins参数化构建实现多版本发布11-DevOps-

到这一步，成功把源代码从本地上传到了Gitlab仓库，然后通过Jenkins自动从Gitlab仓库中拉取到代码，再自动打包。5.通过SSH传输，将Spring Boot应用最终的jar包，上传到应用服务器（192.168.1.11）【由Jenkins完成】现在只是生成了jar包，但是还没有对外进行暴露，外部无法访问这个程序，下一步就要把这个jar包发布和启动。下面验证下打包后的文件是否存在，进入到Jenkins的工作目录中，找到对应的jar包。1.搭建了GitLab代码仓库，将本地代码提交到仓库。

验证下Jenkins是否真正的拉取到了文件，进入Jenkins所在的服务器（192.168.1.10），找到/var/jenkins/workspace目录，看里面是否有Jenkins创建的工程文件夹（myproject-ci）shell脚本说明，使用maven来执行package命令，将源代码编译，自动测试，并打包，形成jar文件，这个过程由maven自动完成。通过以上操作，把原来的容器删掉，基于原有的docker镜像，重新创建了新的Gitlab容器和Jenkins容器。

Jenkins主要起到一个驱动者，流水线的工作，下游代码拉取，上游生产环境发布、构建，这些工作由Jenkins进行驱动。Jenkins由Java语言开发，用于监控持续重复的工作，包括：持续的软件版本发布/测试项目，监控外部调用执行的工作。拉取新的maven配置文件，这个配置文件更改了包的下载路径，改为阿里云的下载，速度更快。-e代表环境变量，定义插件访问时的地址，从腾讯云下载，提高速度。下载maven压缩包，并完成解压缩。创建Jenkins需要的文件夹，并授权。下载jdk压缩包，并完成解压缩。

Gitlab可以理解为是自己搭建的GitHub，也就是自己的代码仓库。

准备两台Linux的操作系统，最简单的方式就是在本机上使用虚拟机搭建两个操作系统（实际生产环境是两台服务器，虚拟机的方式用于学习使用）操作系统准备完毕，执行下面语句，用于式开启网络的ipv4模式，同时关闭防火墙，避免一些网络通信问题。

当一个项目开发完毕，在开发环境正常运行，交给运维人员，可能就会出现一些莫名其妙的，意料之外的问题，这本质上是因为开发和运维在发布的产品上不一致，开发和运维对环境的理解也不一样，所以就会出现在开发环境可以运行的程序，到了生产环境就不一定好使了。在日常开发中，运维人员主要负责跟生产环境打交道，开发和测试，不去操作生产环境的内容，生产环境由运维人员操作，这里面包含了环境的搭建、系统监控、故障的转移，还有软件的维护等内容。CD还指持续部署，成熟的CI/CD管道的最后阶段是持续部署。DevOps的核心是CI/CD。