对于 Jenkins 的使用, 我感觉只用到其中一小部分功能, 但也就是这一小部分功能, 也推动了整个 CI/CD 的过程, Jenkins 的使用方式有很多中, 可能我用到的只是其中一种, 但是已经满足我的需求, 便不再贪婪, 本次要约定好 Jenkins 中的脚本规则, 对于我的整个生成流水线来讲, 约定至高无上, 遵从约定, 或许会出现错误, 但出现的几率肯定低于不遵从约定, 随意设计好的多.
一, Jenkins 安装及项目配置
1,Jenkins 安装
在以前的博客中已经介绍过 Jenkins 的安装, 我使用的是在 Docker 中安装 Jenkins, 利弊明显, 在容器中安装方便, 但是也带来一些问题, 如不能很好的和 Docker Machie 结合使用, 如果想在 Jenkins 脚本中分发服务到其他主机上, 那必须要在 Jenkins 中额外安装 SSH 插件. 而在主机上直接安装 Jenkins, 则步骤要多一点, 需要安装 Java 环境等操作, 但是可以在 Jenkins 中直接使用 Docker Machine 的功能, 直接将服务分发到 Swarm 服务器集群中, 这便带来了优势.
Docker 中完成 Jenkins 安装: https://www.cnblogs.com/CKExp/p/9536864
2,Jenkins 集群搭建
对于 Jenkins 的作用需要重申重要一点就是, 在我的整个生成流水线中 Jenkins 的最大目的是担任奶妈角色, 也就是镜像的创建, 甚至整个 Jenkins 集群的目的都是镜像的创建, 在聊天时发现有人在自己的每一台机器上安装 Jenkins, 然后搭建 Jenkins 集群, 然后将构建任务下发至子节点中并构建完毕后生成服务, 我的思路在刚开始使用 Jenkins 时甚至也是这样, 但是慢慢的我发现不对, 这整个思路就是荒谬, 难不成我的每一台机器上都得安装 Jenkins, 逐步探索, 总结出来就是, Jenkins 只是奶妈, 最终目的只是镜像生产者.
Jenkins 集群搭建过程: https://www.cnblogs.com/CKExp/p/9541137.html
3,Jenkins 中新建项目
在我的生成流水线中, Jenkins 的主要职责便是将代码仓库中的代码拉取过来, 完成镜像的构建, 而对于 Jenkins 中, 构建项目, 有一些需要设置的地方, 如 Git 地址, 凭证, 构建时间, 构建脚本等.
Jenkins 中新建项目: https://www.cnblogs.com/CKExp/p/9940479.html
二, 约定 Jenkins 的构建脚本
利用在构建 Jenkins 脚本时加入的 Docker Compose 工具, 可以在脚本构建时生成多个镜像, 且可以有依赖关系, 方便相互关联的服务部署.
1, 利用 Docker Compose 中的参数 -f 指定项目中的 compose.YAML 文件, 这个文件的位置在之前约定项目结构中设置好了, 在 docker 文件夹下, 对于 docker compose, 会将这两个 YAML 文件合并为一个, 因此, 可以设置多个 YAML 文件, 用于不同的作用. 通过制定 - p 参数来设置项目名称, down 参数将删除指定的镜像, 服务, 容器, 网关等, 对于构建镜像的命令, 可以使用 up 命令或是 build 命令, 两者区别是, 使用 up 命令时会在本机上生成指定镜像的容器, 而 build 命令则只负责构建镜像.
约定项目文件结构: https://www.cnblogs.com/CKExp/p/9940457.html
- #!/bin/bash
- # 获取短版本号
- GITHASH=`git rev-parse --short HEAD`
- docker-compose -f ./docker/docker-compose.YAML -f ./docker/docker-compose.override.YAML -p multimap down --rmi local --remove-orphans
- docker-compose -f ./docker/docker-compose.YAML -f ./docker/docker-compose.override.YAML -p multimap up -d --build
- # docker-compose -f ./docker/docker-compose.YAML -f ./docker/docker-compose.override.YAML -p multimap build
注意: 如果不指定 - p 参数, 则会使用默认文件夹名, 在此处为 docker 文件夹名, 则会带来一系列问题, 如对于默认网关名称, 镜像名称等, 都是使用 docker 开头, 这就导致多个项目会发生冲突, 都是使用 docker 开头的网关, 多个项目只能一个有效, 因此约定每个项目在指定 - p 参数时以项目名称为主.
2, 镜像构建完毕, 将镜像推送到镜像仓库中, 指定仓库地址, 用户名和密码 (我这里使用的是腾讯云的镜像仓库, 如果使用的私有仓库或其他云的, 则需要替换), 可以利用 docker-compose 提供的 push 命令, 将 docker compose 中生成的镜像都推送到镜像仓库中.
echo ---------------Push-Images...------------------
docker login -u=xxx 用户名 xxx -p=xxx 密码 xxx ccr.ccs.tencentyun.com
docker-compose -f ./docker/docker-compose.YAML -f ./docker/docker-compose.override.YAML push
3,(可选) 如果需要将创建服务到 Swarm 集群 (或是 k8s 中), 也可以利用 Jenkins 完成, 如果是将 Jenkins 安装在宿主机上, 则可以使用如下命令创建服务:
首先执行登录仓库功能:
docker-machine SSH host1 docker login -u xxx 用户名 xxx -p xxx 密码 xxx ccr.ccs.tencentyun.com
创建服务, 指定服务内外端口, 指定镜像, 如需指定更多信息, 可以查看命令帮助, 指定完毕服务创建会从镜像仓库中获取最新的镜像, 我使用的是 latest 标签, 如果是生产环境需要打上数字标签, 方便应用程序版本管理:
- docker-machine SSH host1 docker service create \
- --with-registry-auth \
- --name multimapService
- --publish published=32700,target=80 \
- ccr.ccs.tencentyun.com/sassassin/multimap:latest
更新服务, 指定镜像名称, 仍然是该镜像仓库地址, 如果显示没有镜像, 重新使用 docker login 登录, 然后执行命令 (登录命令很关键).
docker-machine SSH host1 docker service update --image ccr.ccs.tencentyun.com/sassassin/multimap:latest xxxService
4, 对于构建过程中生成的无效镜像等, 可以利用 Jenkins 来定时删除, 不建议在项目构建完毕去发起命令删除, 原因在于, 多个项目构建时, 一个项目构建完毕, 另一个项目正在构建过程中, 可能会产生中间镜像, 但这镜像或许是有作用的, 当构建完毕的项目执行镜像删除时, 会发生删除错误, 中间镜像正在被使用, 因此, 最好是单独设置一个任务去定时删除无效镜像
Jenkins 定时删除无效镜像: https://www.cnblogs.com/CKExp/p/9900539.html
至此, Jenkins 在我的整个生成流水线的过程算是完整了, 最后在指明一点, Jenkins 在我的整个生成流水线中, 最大的角色就是镜像生产者 (奶妈).
本文地址: https://www.cnblogs.com/CKExp/p/9940467.html
来源: https://www.cnblogs.com/CKExp/p/9940467.html