Pipe
Git strategy
从GitLab拉去一个仓库到job中的默认方式
- git clone // 相对慢,每个作业从头克隆仓库,确保项目工作站始终是原始的
git fetch // 宠用项目的工作站,相对更快。当不存在时降级到clone
Git shallow clone
git depth default value 50
限制GitLab CI/CD克隆仓库是修改数。能加速流水线的执行。最大数1000。
disable:keep value empty or set to 0Timeout
超时时间定义一个job能够运行的最大时间,默认60mins,job超过阈值将会失败。
runner级别可覆盖超时时间自定义CI配置路径
默认.gitlab-ci.yml在项目根路径下,可以配置路径来找到其他路径下的配置文件。
测试覆盖率
Test coverage parsing,流水线运行成功后可展示
移除代码颜色值,可能会让显示匹配出错,可使用语句过滤
管道可见性
public pipelines :
public 任何人都管道可见并可看job的详情
- internal 任何登录用户可见
- private guest和更高等级可见
disbaled public pipelines
- public 任何人都可见,但只有报告者和更高等级能看到job详情
- internal 登录用户可见,只有报告者和更高等级能看到job详情
-
自动取消挂起的管道
Pipeline Badges
pipeline status badge
pending
- running
- passed
- failed
- skipped
- canceled
- unknown
测试覆盖率报告徽章
Auto DevOps
提供预定义的CI/CD配置,允许自动化检测、构建、测试、部署以及监控应用程序。借助CI/CD最佳实践与工具,Auto DevOps旨在简化一系列成熟和现代化软件开发生命周期的设置和执行。
概览
配合Auto DevOps,软件开发过程设置变得简单,每个项目能用最少的配置有完整的工作流从验证到监控。只要推送你的代码,GitLab将执行一切。这使得创建一个新项目变简单,并且给一个公司启动项目带来了一致性。
默认启动
自GitLab11.3开始,Auto DevOps管道对所有项目默认启动。如果项目没有明确的启动允许,Auto DevOps将自动在第一次管道故障时禁用Auto DevOps。你的项目如果存在配置文件,将持续使用。GitLab管理员能修改这项设置在管理员区域。
快速开始
使用的私域GitLab,你需要在你配置GKE集群前配置Google OAuth2 OmniAuth Provider。按指南步骤开始使用。
对比应用程序平台和PaaS
Auto DevOps提供功能通常包含一个应用程序平台或PaaS(平台及服务)。从Heroku的创新工作中激发灵感,并超越多种方式。
- Auto DevOps用若干Kubernetes集群工作,你不被限制于使用GitLab的内部组件。
- 没有额外开销,你可以使用私域Kubernetes集群或任何公共云容器作为服务。
- Auto DevOps有超多功能包含安全测试、性能测试和代码质量测试。
- Auto DevOps提供增量毕业路径。如果你需要高级自定义,你能开始修改模板不需要重新开始完整不同的平台。
功能
- 自动构建
- 自动测试
- 自动代码质量
- 自动SAST静态应用安全测试
- 自动依赖扫描
- 自动许可证合规性
- 自动容器扫描
- 自动审查应用
- 自动DAST动态应用安全测试
- 自动部署
- 自动网站性能测试
- 自动监视
因为Auto DevOps引来许多不同组件,最好有以下基础知识:
- Kubernetes
- Helm
- Docker
- GitLab Runner
- Prometheus
AutoDevOps提供优秀的默认项为所有stages,你也能自定义大多数你需要的。
要求
- GitLab Runner - 你的运行器能够通过配置运行Docker,通常这种方法使用Docker和Kubernetes执行器,在特权模式下启动。运行期不需要安装在kubernetes集群,但是kubernetes执行器易用并且能自动扩容。基于Docker的运行器也能配置自动扩容。运行器能作为共享的运行器注册在整个GitLab实例中,或者特定运行期注册在特定的项目中。
- 基本域(用于自动审查应用和自动部署) - 你需要一个配置了通配符DNS的域,能够用于你所有的AutoDevOps应用。
- Kubernetes(用于自动审查应用、自动部署和自动监控) - 为了能够部署,你需要Kubernetes1.5+, 你需要面向项目的一个Kubernetes集群或面向整个GitLab一个Kubernetes默认服务模板。
- 一个加载均衡器 - 你能通过部署NGINX ingress在你的集群中使用nginx-ingress Helm图表。
- Prometheus(用于自动监控) - 启动自动监控,你将需要安装Prometheus在某处(集群内外),并且配置为scrape你的Kubernetes集群。为获得应答指标(补充系统指标),你需要配置Prometheus监控NGINX。Prometheus服务整体需要在项目中被允许,或作为默认服务模板在整个GitLab安装中被允许。
如果你没有安装K8s或Prometheus,自动审查应用、自动部署、自动监控将被静默跳过。
Auto DevOps基础域
如果你想使用自动审查应用和自动部署,必须要有Auth DevOps基础域。他能被定义在以下各处。
- 集群中的各处设置,项目中或者组中
-
Runners
‘Runner’ 是运行一个job的过程。你能起多个runners。用户独立,甚至可以机器独立。
active Runner活跃可以处理任何jobs
- paused Runner被暂停,将不会收到新jobs
实践记录
本地手动部署Gitlab-Runner
步骤
- 下载安装Gitlab Runner
使用Docker方法进行安装
docker run -d —name gitlab-runner —restart always \ -v /srv/gitlab-runner/config:/etc/gitlab-runner \ -v /var/run/docker.sock:/var/run/docker.sock \ gitlab/gitlab-runner:latest docker run -d —name gitlab-runner —restart always -v /srv/gitlab-runner/config:/etc/gitlab-runner -v /var/run/docker.sock:/var/run/docker.sock gitlab/gitlab-runner:latest
注册GitLab
gitlab-runner register
- 指明URL:http://gitlab.compass.com
- 输入token:xxxxxxxx
- 声明tags、desc
- 注意:需要在设置中打开run untagged jobs(正式环境尽量不要打开)
- 检查runners activated for this project
允许GitLab-Runner与远程服务器进行通信
CI机器创建公钥(实验无法使用)
ssh-keygen -t rsa // 直接回车后生成路径为~/.ssh
docker cp xxx-container-name:xxx-pubkey-path/id_rsa.pub xxx-host-path // 拷贝生成的公钥文件到本机docker exec -it xxx-container-id /bin/bash // 访问目标部署服务器Dockercd ~
mkdir .sshdocker cp xxx-host-path/id_rsa.pub xxx-container-name:xxx-path/id_rsa.pub // 复制到目标服务器中cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys // 将公钥生成到受信keys中ls -la // 查看权限 .ssh 700, authorized_keys 600chmod 700 .shh-
CI机器创建公钥发送给目标机器
进入gitlab-runner容器
- su gitlab-runner // 请不要再root账号下配置免密登录,无法使用!
- passwd gitlab-runner
- ssh-key -t rsa // 生成公钥
- cd ~/.ssh
- ssh-copy-id guitao@192.xxx.xxx.xx // enter yes & enter passwd
- ssh guitao@xxx.xxx.xx.xx