对于docker环境下使用gitlab,gitlab-runner为NetCore持续集成感兴趣的读者,本文将提供您所需要的所有信息,我们将详细讲解dockerindockergitlab,并且为您提
对于docker环境下使用gitlab,gitlab-runner 为 NetCore 持续集成感兴趣的读者,本文将提供您所需要的所有信息,我们将详细讲解docker in docker gitlab,并且为您提供关于.Net core 使用 Jenkins + Docker + Azure Devops(或者 GitHub、GitLab) 持续集成(CI/CD)、angularjs – 如何使用gitlab-ci-multi-runner在GitLab CI中自动运行测试、centos7 使用 docker 部署 gitlab + gitlab-runner、CICD持续集成: .gitlab-ci.yml配置小记(gitlab-ci + gitlab-runner)的宝贵知识。
本文目录一览:- docker环境下使用gitlab,gitlab-runner 为 NetCore 持续集成(docker in docker gitlab)
- .Net core 使用 Jenkins + Docker + Azure Devops(或者 GitHub、GitLab) 持续集成(CI/CD)
- angularjs – 如何使用gitlab-ci-multi-runner在GitLab CI中自动运行测试
- centos7 使用 docker 部署 gitlab + gitlab-runner
- CICD持续集成: .gitlab-ci.yml配置小记(gitlab-ci + gitlab-runner)
docker环境下使用gitlab,gitlab-runner 为 NetCore 持续集成(docker in docker gitlab)
环境
Centos7.6 安装应用docker,docker-compose (我的Centos是用Hyper-V跑的分了8G的内存,阿里云2G根本跑不起来gitlab)
为了保证我的Centos环境干净所以我的gitlab与gitlab-runner都是采用docker服务运行,包括后续的runner的工作形式(executor)也是选的docker。
准备工作:
拉取镜像:这步骤耗时挺长的,耐心等待吧(如果这个镜像没有了,你可以去hub.docker.com搜一下对应的镜像)
docker pull gitlab/gitlab-ce:latest
docker pull gitlab/gitlab-runner:latest
docker pull docker:stable
docker pull mcr.microsoft.com/dotnet/core/sdk
创建gitlab 与gitlabruner 服务
新建文件:docker-compose.yml ,
在Centos服务器上创建docker-compose.yml文件并运行
docker-compose run -d
gitlab:
image: ''gitlab/gitlab-ce:latest''
restart: always
hostname: ''192.168.2.2''
environment:
GITLAB_OMNIBUS_CONFIG: |
external_url ''http://hts92.wicp.vip:8989''#这里需要更换成你的固定ip或局域网IP地址(我个人做法是用的动态域名。做的端口映射,如果你是内网做demo无所谓)
ports:
- ''8989:8989''
volumes:
- ''/srv/gitlab/config:/etc/gitlab''
- ''/srv/gitlab/logs:/var/log/gitlab''
- ''/srv/gitlab/data:/var/opt/gitlab''
gitlab-runner:
image: ''gitlab/gitlab-runner:latest''
container_name: ''gitlab-runner''
restart: ''always''
volumes:
- ''/srv/gitlab-runner/confg:/etc/gitlab-runner''
- ''/var/run/docker.sock:/var/run/docker.sock''
到此 gitlab 与gitlab-runner 已经搭建好了。(第一次登陆时需要你设置root用户密码这里我就不截图了,因为我已经设置完了。)
接下来进入gitlab 新建个项目。项目名随意,
进入刚建好的项目
在开发机新建webapi项目:
dotnet new webapi -n user.api --no-https
添加镜像检测脚本
添加镜像检测删除脚本到项目根目录(后续ci构建脚本会用到,每次从新编译docker file 时 会帮你删除掉之前的实例跟镜像):保存为check-images.sh 放到项目根目录
if [ $(docker ps -a --format {{.Names}} | grep user-api) ] then docker rm -f user-api docker rmi user-api fi
创建 .gitlab-ci.yml文件 放到项目根目录
stages:
- build - deploy # 构建 build-job: stage: build only: - master cache: untracked: true script: - dotnet restore - dotnet publish -o ./out -c Release artifacts: # 可以缓存在gitlab的流水线记录中,供直接下载 expire_in: 30 days paths: - out/ tags: - 01-user-api-builder # 发布正式 deploy-job: stage: deploy only: - master dependencies: - build-job # 这里一定要依赖build-job,不然dockerfile里面的out目录无法使用 script: - ls out/ - docker ps - sh ./check-images.sh - docker build -t user-api . # 这里可以添加将生成好的image上传到dockerhub或者docker本地仓库 ### 如果生成的镜像需要统一上传到仓库管理,则后面的逻辑可以分离到另外一个runner去执行 # 这里可以添加从dockerhub或本地仓库拉取指定镜像 - docker run -d --name user-api -p 8080:80 user-api tags: - 01-user-api-deploy
创建 Dockerfile文件
创建 Dockerfile文件 放到项目根目录 (这里值得注意的是mcr.microsoft.com/dotnet/core/sdk 镜像名,要跟我们准备环境时候的镜像名保持一致,要不然build 时还需要在拉取 浪费时间,当然你可可以换成runtime环境的。好处就是编译镜像小,用我这个编译镜像大)
FROM mcr.microsoft.com/dotnet/core/sdk
WORKDIR /app
COPY out/ /app
ENTRYPOINT [ "dotnet", "/app/user.api.dll" ]
以上内容一同传至 gitlab刚建好的项目
gitlab项目目录结构如下
注册runner,
找到rnner信息
注册第一个runner
记得替换掉对应信息。(--url,--registration-toke)
docker exec -it gitlab-runner gitlab-runner register -n \
--url http://hts92.wicp.vip:8989/ \
--registration-token QJiAZYz3KSJyhWfsHKhC \
--executor docker \
--tag-list "helloapi-build" \
--description "helloapi-deploy-job" \
--docker-image "mcr.microsoft.com/dotnet/core/sdk:3.1"
注册第二个runner
(值得注意的是: --docker-volumes /var/run/docker.sock:/var/run/docker.sock,当时没有这句话 我的docker实例无法跟docker容器(docker run docker)本身通讯 。这个问题让我找了进一天的时间)
docker exec -it gitlab-runner gitlab-runner register -n \
--url http://hts92.wicp.vip:8989/ \
--registration-token QJiAZYz3KSJyhWfsHKhC \
--executor docker \
--tag-list "01-user-api-deploy" \
--description "01-user-api-deploy" \
--docker-image "docker:stable" \
--docker-volumes /var/run/docker.sock:/var/run/docker.sock
如下代表runner 已经开始工作了并且执行成功。
查看镜像
[root@localhost ~]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
user-api latest 62eafc3e4bf6 About a minute ago 1.74GB
mcr.microsoft.com/dotnet/core/sdk 20190726 3af77ac73731 2 days ago 1.74GB
mcr.microsoft.com/dotnet/core/sdk latest 3af77ac73731 2 days ago 1.74GB
gitlab/gitlab-runner-helper x86_64-d0b76032 f8d183475601 2 days ago 52.4MB
docker stable c4154a2b47a1 4 days ago 216MB
mysql/mysql-server latest 12a8d88596c0 4 days ago 294MB
gitlab/gitlab-runner latest 4142c6fc05d4 2 weeks ago 410MB
gitlab/gitlab-ce latest 15563c211d40 3 weeks ago 1.8GB
microsoft/mssql-server-linux latest 314918ddaedf 7 months ago 1.35GB
registry 2.3 83139345d017 3 years ago 166MB
[root@localhost ~]#
查看容器
2ced458eea91 user-api "dotnet /app/User.Ap…" 21 seconds ago Up 20 seconds 0.0.0.0:8080->80/tcp user-api
cfed5894c526 microsoft/mssql-server-linux "/opt/mssql/bin/sqls…" 3 minutes ago Up 3 minutes 0.0.0.0:1433->1433/tcp sqlserver
d713e32ee388 gitlab/gitlab-ce:latest "/assets/wrapper" 3 days ago Up 39 minutes (healthy) 22/tcp, 80/tcp, 443/tcp, 0.0.0.0:8989->8989/tcp gitlab_gitlab_1
e0cf226629d3 registry:2.3 "/bin/registry /etc/…" 3 days ago Up 39 minutes 0.0.0.0:5000->5000/tcp gitlab_registry_1
eab855f64938 gitlab/gitlab-runner:latest "/usr/bin/dumb-init …" 3 days ago Up 39 minutes gitlab-runner
以上容器已经运行成功
测试
(我的Centos虚拟机地址192.168.2.2)
总结:
看着几行代码搞定,但是由于第一次做也耗时将近两天,随后在做就简单多了。整理出以上内容给大家分享。 以下为参考文章。有问题留言。
参考文章
https://www.lizenghai.com/archives/5180.html#Runner
https://docs.gitlab.com/ee/ci/docker/using_docker_build.html
https://www.jianshu.com/p/43ffba076bc9
docker exec -it gitlab-runner gitlab-runner register -n \ --url http://hts92.wicp.vip:8989/ \ --registration-token QJiAZYz3KSJyhWfsHKhC \ --executor docker \ --tag-list "helloapi-build" \ --description "helloapi-deploy-job" \ --docker-image "mcr.microsoft.com/dotnet/core/sdk:3.1"
原文出处:https://www.cnblogs.com/hts92/p/11220604.html
.Net core 使用 Jenkins + Docker + Azure Devops(或者 GitHub、GitLab) 持续集成(CI/CD)
目前 CI/CD 挺火的,这里使用的 Jenkins + Docker + Azure Devops 部署,或者可以用这套 Jenkins + Docker + Github 或 GitLab 部署,
进入正题: 第零点:当然要先安装.Net core 运行时,官网上就有下载。
首先 这里的 jenkins 并不是装在 docker 里面的 jenkins,是直接安装到 linux 上的 jenkins。其实安装在 docker 更加方便,因为这样系统不用安装 JavaSdk,我参考的是晓晨的博客,原文链接:https://www.cnblogs.com/stulzq/p/9291237.html ,这里要强调的是:1、首先我们先要安装 java 环境,参考晓晨的博客,原文链接:https://www.cnblogs.com/stulzq/p/9286878.html 里面非常详细的介绍。
但是这里要注意的就是:
官网地址:http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html 在官网下载需要点击这个选项才能下载,下载框中的那个就可以了。
然后 jenkins 安装晓晨的博客已经说的非常明白了。
接下来就是 Azure Devops 的说明,微软这个东西挺不错的,配合 vs 使用也挺好用的,但是还是比不上 github,
如图:可以建立自己的分支上传(push)和拉取(pull),从某分支合并(merge),完成团队协作。基本上使用非常简单,通过 vs 就可以直接新建项目到 Azure Devops,也可以建立多个分支,达到团队协作的目的,这里就不详细说明啦。
接下来就是 docker 的安装了,这里也是参考晓晨博客,原文地址:http://www.cnblogs.com/stulzq/p/7743073.html,这里要说明的就是我们需要安装 docker-compose ,这样就可以运行 dockerfile 文件脚本,达到自动部署的目的。
好吧,基本上安装完之后,我们就可以开始了:
首先我们需要在 jenkins 上面新建一个任务,自由风格的软件项目: (这里有一部分参考晓晨的博客,原文链接:http://www.cnblogs.com/stulzq/p/8627824.html)
然后点击 ok 进入下一个页面,这里的是丢弃旧的构建,因为太多就占磁盘了,第一个是保留几天的 build 记录,第二个是最多保留多少个构建,设小一点就不会占很多硬盘空间了。
然后就是 git 的地址了:
上图的 git 地址, 就是这里的 git clone 地址 (当然 git 地址都行):
还需要注意的就是凭证(再点击右上角你的账户下的 security):
在这里面填入名称密码就可以了,然后在上面的凭证 Credentials 填入就行了:
接下来就是 jenkins 拉取代码的时间(这里 H/2 * * * * 是两分钟拉取一次):
:
然后是拉取后,构建执行的命令:
jenkins 拉取代码后会判断代码与之前的是否不一致,如果不一致,则会执行构建。
接下来是 docker 的说明:可以看到上图的命令,倒数两行,会执行这个脚本文件,这个脚本文件实际上是 docker 的一些命令,所以我们需要在项目目录中添加这个脚本文件,我就是直接添加 TXT 文件改后缀.sh。(有点 low。。。。)
来看看这个脚本里面放什么:
#!/bin/sh
docker container ls -a | grep "tr"
if [ $? -eq 0 ];then
docker container stop tr
docker container rm tr
docker rmi tr
docker network ls |grep tr
docker network rm tr
fi
docker build -t tr --build-arg env="Development" .
docker run -d --restart=always -p 8051:80 --name tr tr
docker cp /etc/localtime tr:/etc/
可以看到就是如果存在 tr 先停止 删除 然后再构建。当然我们也得有 dockerfile 这个文件,构建的时候 docker 会去找到 dockerfile 然后执行里面的命令(dockerfile 在新建.net core 项目的时候勾选支持 docker 就可以咯,还有直接添加 txt 去掉后缀也行哈哈哈)
然后看看 dockerfile 有什么:
# 基于dotnet基础环境构建镜像
FROM docker.io/microsoft/dotnet
RUN mkdir /TR
#定义参数
ARG env
# 把发布的内容拷贝到docker容器的TR目录下
COPY /publish /TR
# 设置工作目录
WORKDIR /TR
# 暴露80端口
EXPOSE 80
# 设置环境变量
ENV ASPNETCORE_ENVIRONMENT=$env
# 启动web
RUN echo "执行环境: $env"
CMD ["dotnet","TR.dll"]
dockerfile 指令详解说明:https://yeasy.gitbooks.io/docker_practice/content/image/dockerfile/,里面都有说明就不多说了,要注意的就是,大致的流程就是首先我们上传代码到 Azure Devops 上,然后 jenkins 根据凭证去 Azure Devops 拉取代码到服务器上,执行命令脚本构建,然后就交给脚本执行,找到 dockfile 执行,重构镜像再生成容器。网站就部署到 docker 里面了。
大致的就是这样,感谢晓晨的博客,给了我非常大的帮助,这就是晓晨的博客地址:https://www.cnblogs.com/stulzq/
angularjs – 如何使用gitlab-ci-multi-runner在GitLab CI中自动运行测试
我现在要做的是让一个运行npm install的作业下载所有依赖项,一个作业执行我用karma / jasmine编写的所有测试,运行karma start karma.conf.js或使用grunt并运行grunt test.
所以我尝试的第一份工作是:
cd app npm install karma start karma.conf.js
前两个命令被执行,但最后一个命令被完全忽略.所以我试图分开工作.第一个命令获得自己的工作(选项卡“并行运行”),最后一个命令在“成功运行”选项卡中移动到自己的工作.现在所有依赖项都已安装,第二个作业启动.到目前为止一切顺利,但第二项工作从删除所有先前安装的依赖项开始,然后尝试运行karma start karma.conf.js.这显然最终导致所有测试都失败,因为没有下载npm依赖“angular-mocks”.如果我将npm install添加到第二个作业(这对我来说没有多大意义),karma任务将再次被忽略.
这里有什么问题?我怎样才能解决这个问题?有没有办法不总是下载每个测试执行的所有依赖项?
before_script: - npm install test: script: npm test
centos7 使用 docker 部署 gitlab + gitlab-runner
快速配置应用
docker-compose.yml
使用 docker-compose
对 docker
容器集群进行快速编排
获取 docker-gitlab
的 docker-compose.yml
配置文件,进行快速构建
$ wget https://raw.githubusercontent.com/sameersbn/docker-gitlab/master/docker-compose.yml
获取 docker-compose.yml
文件后,进行自定义配置。
配置环境
打开 docker-compose.yml
文件,针对 gitlab
进行环境配置
version: ''2.3''
services:
...
# 省略显示其他服务
...
gitlab:
restart: always
image: sameersbn/gitlab:13.0.6
depends_on:
- redis
- postgresql
ports:
- "10080:80"
- "10022:22"
volumes:
- gitlab-data:/home/git/data:Z
healthcheck:
test: ["CMD", "/usr/local/sbin/healthcheck"]
interval: 5m
timeout: 10s
retries: 3
start_period: 5m
environment:
- DEBUG=false
- DB_ADAPTER=postgresql
- DB_HOST=postgresql
- DB_PORT=5432
- DB_USER=gitlab
- DB_PASS=password
- DB_NAME=gitlabhq_production
- REDIS_HOST=redis
- REDIS_PORT=6379
- TZ=Asia/Kolkata
- GITLAB_TIMEZONE=Kolkata
- GITLAB_HTTPS=false
- SSL_SELF_SIGNED=false
- GITLAB_HOST=localhost
- GITLAB_PORT=10080
- GITLAB_SSH_PORT=10022
- GITLAB_RELATIVE_URL_ROOT=
- GITLAB_SECRETS_DB_KEY_BASE=long-and-random-alphanumeric-string
- GITLAB_SECRETS_SECRET_KEY_BASE=long-and-random-alphanumeric-string
- GITLAB_SECRETS_OTP_KEY_BASE=long-and-random-alphanumeric-string
...
# 省略其他配置
...
参考配置文档,我们需要将时区设置为东八时区,设置数据混淆密匙,设置服务地址。
environment:
- TZ=Asia/Shanghai
- GITLAB_TIMEZONE=Asia/Shanghai
- GITLAB_HOST=192.168.2.192
设置混淆密匙,一般推荐 64
位随机字符串,可以用 pwgen
生成,可以安装 pwgen
服务,然后运行 pwgen -Bsv1 64
即可生成随机字符串。
environment:
- GITLAB_SECRETS_DB_KEY_BASE=nvqgzJdgrmr3tqsC4F9gKVNhKvTq3N7cJPjNggR93qthNhJ3MWkc7jNmNTLRXdhX
- GITLAB_SECRETS_SECRET_KEY_BASE=pcrf73fX4rM7bKxc7tcq3kwKWdtKKtrmmsHwT3J9rwCLMsK37PxCnXbMgnRpqJbk
- GITLAB_SECRETS_OTP_KEY_BASE=3d9tPCzpv7rfmVgnjN9McbztRVbp4rjxWWqFbNLTCbRz9mKkpvqqWgxMq7NM7c9w
同理,docker-compose.yml
的其他服务也需要配置东八时区。
数据卷挂载
数据卷挂载可对数据进行持久化保存,不会因为容器的删除而删除,数据挂载的目录数据会自动与容器内的数据同步,数据挂载的目录数据优先于容器内数据,即修改数据卷数据,会自动同步到容器内数据。
version: ''2.3''
services:
redis:
restart: always
image: redis:5.0.9
command:
- --loglevel warning
volumes:
- redis-data:/var/lib/redis:Z
environment:
- TZ=Asia/Shanghai
postgresql:
restart: always
image: sameersbn/postgresql:11-20200524
volumes:
- postgresql-data:/var/lib/postgresql:Z
environment:
- DB_USER=gitlab
- DB_PASS=password
- DB_NAME=gitlabhq_production
- DB_EXTENSION=pg_trgm
- TZ=Asia/Shanghai
gitlab:
restart: always
image: sameersbn/gitlab:13.0.6
depends_on:
- redis
- postgresql
ports:
- "10080:80"
- "10022:22"
volumes:
- gitlab-data:/home/git/data:Z
healthcheck:
test: ["CMD", "/usr/local/sbin/healthcheck"]
interval: 5m
timeout: 10s
retries: 3
start_period: 5m
注意:数据卷的挂载,需要在宿主机提前创建好对应的目录。
手动创建以下目录:
/app/volumes/gitlab/gitlab/
/app/volumes/gitlab/postgresql/
/app/volumes/gitlab/redis/
修改对应数据卷配置:
redis:
restart: always
image: redis:5.0.9
command:
- --loglevel warning
volumes:
- /app/volumes/gitlab/redis:/var/lib/redis:Z
postgresql:
restart: always
image: sameersbn/postgresql:11-20200524
volumes:
- /app/volumes/gitlab/postgresql:/var/lib/postgresql:Z
gitlab:
restart: always
image: sameersbn/gitlab:13.0.6
depends_on:
- redis
- postgresql
ports:
- "10080:80"
- "10022:22"
volumes:
- /app/volumes/gitlab/gitlab:/home/git/data:Z
gitlab-runner
拉下来的 docker-compose.yml
文件默认是没有 gitlab-runner
的,我们需要将 gitlab-runner
写到 docker-compose.yml
配置上来。
也要先创建数据卷挂载文件目录:
/app/volumes/gitlab-runner/config/
gitlab-runner:
restart: always
image: gitlab/gitlab-runner
depends_on:
- gitlab
volumes:
- /app/volumes/gitlab-runner/config:/etc/gitlab-runner:Z
- /var/run/docker.sock:/var/run/docker.sock
environment:
- TZ=Asia/Shanghai
快速构建应用
将配置好的 docker-compose.yml
文件放到 /app/docker/gitlab/
下,执行以下命令:
$ cd /app/docker/gitlab/
$ docker-compose up
docker-compose
会自动管理 docker
容器集群,包括对镜像进行拉取、创建以及启动。
稍等片刻,我们即可通过 http://192.168.2.192:10080/
打开 gitlab
页面,第一次打开是直接设置 root
账号的密码,设置密码后即可登录进入 gitlab
内页。
英文不好的同学可以进入个人设置那里设置 language
为简体中文。
注册runner
什么是 runner
,runner
就是 gitlab
进行可持续集成与可持续交付过程所跑的环境容器服务。
为了进行 ci/cd
=> 可持续集成/可持续部署,我们需要注册 runner
,一般我们注册的是共享 runner
,也就是任何仓库的 ci/cd
都可以在上面跑。当然,我们也可以创建多个 runner
服务,为特定仓库指定 runner
。
下面以注册共享 runner
为例:
比如
1、进入 runner
容器
$ docker exec -it 容器ID bash
2、注册 runner
$ gitlab-runner register
3、输入 gitlab
示例的 url
$ Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com ):
http://192.168.2.192:10080/
4、输入用来注册 runner
的 token
$ Please enter the gitlab-ci token for this runner:
yrErncrc8XY_e5-g7bU8
5、输入 runner
的描述,随后可在 gitlab
界面中修改
$ Please enter the gitlab-ci description for this runner:
gitlab-ci
6、输入与 runner
绑定的标签(可修改)
$ Please enter the gitlab-ci tags for this runner (comma separated):
gitlab-ci
7、选择 runner
的执行方式(推荐docker
)
$ Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:
docker
8、如果选择的执行方式是 docker
,会要求填写默认的镜像
$ Please enter the Docker image (eg. ruby:2.1):
alpine:latest
注册成功后会在 runner
容器 ~/etc/gitlab-runner/
目录下生成 config.toml
配置文件,这时候就可以在 gitlab
的管理页面中看到激活的 runner
然后,对 runner
进行修改,勾选 runner 可以选择无标签的项目
(默认是同样标签的项目才能使用对应标签的 runner
)。这样,runner
就可以变为共享 runner
了。
当我们需要专门为某个项目跑的 runner
时,那就不需要勾选 runner
可选择无标签选项,在下面配置添加 runner
服务的项目保存即可。
可持续集成/部署
可持续集成与部署需要配置 .gitlab-ci.yml
文件,gitlab
会检查每个仓库根目录是否存在 .gitlab-ci.yml
文件,有的话 runner
则自动跑起来。
gitlab
默认开启 auto devops
功能,如果没有 .gitlab-ci.yml
文件,则会自动运行 auto devops
,如果没有配置 Auto DevOps
功能与 Kubernetes
集成的话,建议关闭默认的 auto devops
功能。
.gitlab-ci.yml
这是一个自动编译前端代码并发布到 gitlab page
的配置文件:
building:
image: node:alpine # 指定运行环境
stage: build # 当前stage阶段为build
script: # build阶段运行的脚本
- yarn --registry=https://registry.npm.taobao.org
- yarn docs:build
artifacts: # 工件,可以缓存在gitlab的流水线记录中,供直接下载
expire_in: 3 days # 工件缓存的有效时间
paths: # 路径
- docs/.vuepress/dist/ # 工件指向的目录,这里指整个dist目录
cache: # 缓存
paths: # 路径
- node_modules/ # 缓存node_mudules将大大提高ci运行的速度
deploying:
stage: deploy # 当前阶段为deploy
script: # deploy阶段运行的命令
- rm -rf public/* # linux命令,递归无询问删除public目录下所有文件- mv dist/* public //将dist目录下的所有文件都移动到public目录下
artifacts: # 工件缓存
expire_in: 3 days # 时效为3天
paths: # 路径
- public # 缓存整个public目录的文件
only:
- master # ceate pages下的所有操作只在 master 分支上进行
自动化
当我们提交我们的代码后,gitlab
会自动根据 .gitlab-ci.yml
的配置运行 runner
。
这样我们就实现自动化集成与部署了,大大的提高了我们的开发效率。
身份认证
我们在 gitlab
上注册了自己的账号后,为了方便身份认证,一般需要用 ssh
生成身份认证密匙,这样就不需要每次访问都要输入账号密码。
配置SHH密匙
在我们的电脑 git bash
输入:
$ ssh-keygen -t rsa -C "我们在gitlab注册的邮箱" -f ~/.ssh/gitlab_id_rsa
此时会在我们电脑用户根目录的 /.ssh
下生成私匙跟公匙:
gitlab_id_rsa
gitlab_id_rsa.pub
打开 pub
后缀的公匙,复制粘贴到 gitlab
用户设置,保存即可。
在对 gitlab
仓库使用 git
命令的时候,如果出现提示没有权限的话,多半是因为 git
混淆了 github
与 gitlab
的 ssh
密钥,解决方法看下一步。
github与gitlab共存
假设我们之前就已经生成了 github
的 ssh
密匙:
github_id_rsa
github_id_rsa.pub
在我们电脑的用户目录 /.ssh/
下创建 config
文件,配置如下,保存即可:
#github
Host github.com
HostName github.com
IdentityFile C:/Users/jwchan/.ssh/github_id_rsa
#gitlab
Host 192.168.2.192
HostName 192.168.2.192
IdentityFile C:/Users/jwchan/.ssh/gitlab_id_rsa
这样,我们在提交代码的时候,会自动区分目标服务器从而使用对应的 ssh
密匙。
git基本操作
1、拉取仓库
$ git clone ssh://git@192.168.2.192:10022/jwchan/blog.git
2、进入仓库贡献代码
$ cd /blog/
3、查看仓库代码修改状态
$ git status
4、添加代码缓冲区
$ git add .
5、提交代码并注释
$ git commit -m "[fix]: bug"
6、推送代码到远程仓库
$ git push
CICD持续集成: .gitlab-ci.yml配置小记(gitlab-ci + gitlab-runner)
参考博文:基于gitlab-ci的CICD
概念
GitLab-CI
GitLab自带的持续集成系统,负责.gitlab-ci.yml脚本解析。
GitLab-Runner
脚本执行的承载者。GitLab-CI解析.gitlab-ci.yml文件后,根据里面配置的规则,分配到各个Runner来运行相应的脚本script。
.gitlab-ci.yml
位于git项目根目录,记录了一系列的阶段和执行规则。
Pipeline
一次 Pipeline 其实相当于一次构建任务,里面可以包含多个流程,如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。
Stages
构建阶段(上述所说的流程)。一次 Pipeline 中可以定义多个 Stages,所有 Stages 会按顺序运行,前一个 Stage 完成后,下一个才会开始。只有当所有 Stages 完成后,该构建任务 (Pipeline) 才会成功。任何一个 Stage 失败,后面的 Stages 都不会执行,该构建任务失败。
Jobs
构建工作,某个 Stage 里面执行的具体内容。我们可以在 Stages 里面定义多个 Jobs,相同 Stage 中的 Jobs 会并行执行。相同 Stage 中的 Jobs 都执行成功时,该 Stage 才会成功,如果任何一个 Job 失败,那么该 Stage 失败,即该构建任务 (Pipeline) 失败。
流程
安装部署
添加gitlab官方库
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash
安装最新版本的gitlab-runner
yum -y install gitlab-runner
启动服务
gitlab-runner list 查看各个 Runner 的状态
gitlab-runner stop 停止服务
gitlab-runner start 启动服务
gitlab-runner restart 重启服务
注册
需要先获取令牌。详细步骤请移步文章顶部参考博文。
.gitlab-ci.yml配置
这个文件大家参考意义不大,调用的命令很多是自定义的。博主主要是想记录下。
variables:
# 构建结果发送邮件(服务端python实现)
RECIEVER: xxx@yyy.com;
SYS_NAME: jinghailu
BASE_DIR: /export/App/
BACKUP_DIR: /export/App/bak/
BUILD_DIR: ./_build/
DEV_ALPHA_IP: **.**.**.**
DEV_DATABANK_IP: **.**.**.**
# 三个IP分别对应国内、泰国、印尼
UAT_IP: **.**.**.** **.**.**.** **.**.**.**
.env_init: &env_init |
# develop / master
IP_LIST="${UAT_IP}"
# 从分支dev-alpha提交代码并push
if [[ "${CI_COMMIT_REF_NAME}" == "dev-alpha" ]]; then
IP_LIST="${DEV_ALPHA_IP}"
fi
# 从分支dev-databank提交push
if [[ "${CI_COMMIT_REF_NAME}" == "dev-databank" ]]; then
IP_LIST="${DEV_DATABANK_IP}"
fi
#if [[ -n "${CI_COMMIT_TAG}" ]]; then
#IP_LIST="${UAT_IP}"
#fi
before_script:
- *env_init
# - PATH=$PATH:/export/servers/node-v10.15.1/bin/
cache:
key: "$CI_COMMIT_REF_NAME"
paths:
- node_modules/
- deploy.tar.gz
# for uat env
package-develop:
stage: build
script:
- npm install
- npm run build:uat
- mkdir $BUILD_DIR
- cp -r ./dist/ $BUILD_DIR/resource
- cp -r ./jdos/* $BUILD_DIR
- chmod a+x $BUILD_DIR/bin/*
- cd $BUILD_DIR && tar czvf ../deploy.tar.gz * && cd ..
- download_url=`upload-deploy-package -f deploy.tar.gz -r ${SYS_NAME}/${CI_COMMIT_REF_NAME}.tar.gz`
- my-sendmail -s "publish-${SYS_NAME}" -c "You could deploy in jdos now! </br></br> <b>Branch:</b> ${CI_COMMIT_REF_NAME} </br> <b>Commit:</b> ${CI_COMMIT_MESSAGE} </br> <b>Commit Author:</b> ${GITLAB_USER_NAME} </br> <b>Download Url:</b> ${download_url}" -r "$RECIEVER"
only:
- develop
- dev-alpha
- dev-databank
# for master env
package-master:
stage: build
script:
- npm install
- npm run build
- mkdir $BUILD_DIR
- cp -r ./dist/ $BUILD_DIR/resource
- cp -r ./jdos/* $BUILD_DIR
- chmod a+x $BUILD_DIR/bin/*
- cd $BUILD_DIR && tar czvf ../deploy.tar.gz * && cd ..
- download_url=`upload-deploy-package -f deploy.tar.gz -r ${SYS_NAME}/${CI_COMMIT_REF_NAME}.tar.gz`
- my-sendmail -s "publish-${SYS_NAME}" -c "You could deploy in jdos now! </br></br> <b>Branch:</b> ${CI_COMMIT_REF_NAME} </br> <b>Commit:</b> ${CI_COMMIT_MESSAGE} </br> <b>Commit Author:</b> ${GITLAB_USER_NAME} </br> <b>Download Url:</b> ${download_url}" -r "$RECIEVER"
only:
- master
# Auto Deploy
deploy:
stage: deploy
script:
- echo $IP_LIST
- for ip in $IP_LIST; do
- echo $ip
# backup files
- ssh admin@$ip "cd $BASE_DIR && mkdir -p $BACKUP_DIR && tar czvf /export/App/bak/resource-`date +%Y%m%d%H`.tar.gz resource/ bin/"
# stop service
- ssh admin@$ip "cd /export/App/bin && /export/App/bin/stop.sh"
# send file
- scp deploy.tar.gz admin@$ip:$BASE_DIR
# deploy files
- ssh admin@$ip "cd $BASE_DIR && \rm -rf ./resource && tar xzvf deploy.tar.gz && \rm deploy.tar.gz"
# work only in pre-production env
# - ssh admin@$ip "cd $BASE_DIR/nginx && \cp jinghailu.jd.com_yufa agent"
# start service
- ssh admin@$ip "cd /export/App/bin && /export/App/bin/start.sh"
- done
- my-sendmail -s "deploy-${SYS_NAME}" -c "Deployed successfully! </br></br> <b>Branch:</b> ${CI_COMMIT_REF_NAME} </br> <b>Commit:</b> ${CI_COMMIT_MESSAGE} </br> <b>Commit Author:</b> ${GITLAB_USER_NAME}" -r "$RECIEVER"
only:
- master
- develop
- dev-alpha
- dev-databank
笔记
处理流程:
- 制定分支push
- 构建阶段 - 安装依赖(服务端每次拉取最新代码时更新依赖库)
- 构建阶段 - 执行打包命令
- 构建阶段 - 压缩包传到oss平台
- 构建阶段 - 发送邮件,附oss访问地址
- 部署阶段 - 遍历IP,从oss拉包到部署服务器,启动脚本
Tip:
- 相同 Stage 中的 Jobs 会并行执行
- job越少耗时越短。尝试过拆分更细粒度的阶段,阶段越多耗时越长。故最终还是只用了2个阶段。
关于docker环境下使用gitlab,gitlab-runner 为 NetCore 持续集成和docker in docker gitlab的问题我们已经讲解完毕,感谢您的阅读,如果还想了解更多关于.Net core 使用 Jenkins + Docker + Azure Devops(或者 GitHub、GitLab) 持续集成(CI/CD)、angularjs – 如何使用gitlab-ci-multi-runner在GitLab CI中自动运行测试、centos7 使用 docker 部署 gitlab + gitlab-runner、CICD持续集成: .gitlab-ci.yml配置小记(gitlab-ci + gitlab-runner)等相关内容,可以在本站寻找。
本文标签: