linuxea:gitlab-ci之docker镜像质量品质报告 在此前的两篇关于gitlab-ci的镜像的安全和质量的问题上做了一些简单的描述，现在就着此前的，我们在使用另外一个开源工具dive，使用dive用来对 镜像每个图层做分析，分析效率和镜像是否有浪费的空间，最后打印一个测试品质的报告。此前在另外一篇文章如何从docker镜像恢复Dockerfile提到如何简单使用dive查看dockerfile.阅读本章节，你将了解dive的基本使用和在gitlab-ci中的集成方式。我们先来看gitlab上作者给出的基本功能如下描述显示按层细分的Docker镜像内容当你在左侧选择一个图层时，将显示该图层的内容以及右侧的所有先前图层。此外，还可以使用箭头键完全浏览文件树（可以查看一些 dockerfile指令）。<当你使用dive image的时候你会进入一个交互式的接口>指出每层中发生了哪些变化已更改，已修改，添加或删除的文件在文件树中指示。可以调整此值以显示特定图层的更改，或直到此图层的聚合更改。估算“镜像效率”左下方窗格显示基本图层信息和一个实验指标，用于猜测镜像所包含的空间浪费。这可能是跨层重复文件，跨层移动文件或不完全删除文件。提供了百分比“得分”和总浪费的文件空间。快速构建/分析周期你可以构建Docker镜像并使用一个命令立即进行分析： dive build -t some-tag .你只需要docker build使用相同的dive build 命令替换你的命令。CI集成 分析和成像，并根据镜像效率和浪费的空间获得通过/失败结果。CI=true在调用任何有效的dive命令时，只需在环境中进行设置。安装centoscurl -OL https://github.com/wagoodman/dive/releases/download/v0.7.0/dive_0.7.0_linux_amd64.rpm rpm -i dive_0.7.0_linux_amd64.rpmdockerdocker run --rm -i -v /var/run/docker.sock:/var/run/docker.sock \ -e CI=true \ wagoodman/dive:v0.7 registry.linuxea.com/dev/linuxeabbs:latest使用我们主要围绕CI展开如果要查看Dockerfile或者其他层的详情，可以使用dive IMAGE,参考如何从docker镜像恢复Dockerfile[root@linuxea.com ~]# CI=true dive registry.linuxea.com/dev/linuxeabbs:latest Fetching image... (this can take a while with large images) Parsing image... Analyzing image... efficiency: 99.6914 % wastedBytes: 1858891 bytes (1.9 MB) userWastedPercent: 0.5040 % Run CI Validations... Using default CI config PASS: highestUserWastedPercent SKIP: highestWastedBytes: rule disabled PASS: lowestEfficiency Result:PASS [Total:3] [Passed:2] [Failed:0] [Warn:0] [Skipped:1]如何理解这些内容背后的含义是什么？参考github作者的回复，总体就如下3条规则efficiency：这基本上是（总镜像大小）/（总和（所有层中的字节数））。我们的想法是，如果你不删除任何文件或添加任何文件两次，那么你的“效率”为100％。如果你开始复制/删除文件，则会根据效率计算（按浪费文件的大小加权）。wastedBytes：发现在多个层上重复的原始字节数，或者发现在更高层中删除的原始字节数（因此，如果最终未使用，则可能不应该在任何层中。userWastedPercent：这基本上是效率的倒数，除了不考虑基础镜像的任何修改。更具体地说，这是wastedBytes / sum（所有层中的字节，基本镜像层除外）。集成到管道4/4 Docker_Dive: <<: *bash_init script: - Docker_Dive artifacts: name: "$CI_JOB_STAGE-$CI_COMMIT_REF_NAME" paths: [Docker_Dive.log] 函数部分 function Docker_Dive() { export PROJECT_NAME=$(echo "$CI_PROJECT_PATH_SLUG" |awk -F- '{print $2}') export IMAGE_TAG_LATEST="$REPOSITORY_URL"/"$PROJECT_NAME":latest docker run --rm -i -v /var/run/docker.sock:/var/run/docker.sock -e CI=true \ wagoodman/dive:v0.7 "$IMAGE_TAG_LATEST" |tee Docker_Dive.log } 部分截图如下：延伸阅读linuxea:如何使用gitlab-ci/cd来构建docker镜像和发布如何从docker镜像恢复Dockerfilelinuxea:gitlab-ci/cd docker容器漏洞扫描clair-scannerlinuxea:gitlab-ci/cd runner配置和安装(一)linuxea:gitlab-ci的定时任务linuxea:docker仓库harbor-https的配置和使用linuxea:白话容器之Registry与Harbor的构建和使用 (26)linuxea:Docker多阶段构建与- target和--cache-from阅读更多devopsgitlabgitlab-ci/cdjenkins

linuxea:gitlab-ci之docker-bench-security 在前面的两篇中，记录了gitlab-ci构建构建docker镜像和安全漏洞扫描，但在github上还有一个不错的项目--> Docker Bench for SecurityDocker Bench for Security是一个脚本，用于检查有关在生产中部署Docker容器的许多常见最佳实践。附：DOCKER安全性和最佳实践这其中， 检查的东西很多样化，包括：资源限制，明文密码，swarm以及其他的一些辅助性质或者参考价值的信息。阅读本章，你将了解Docker Bench for Security在gitlab-ci中的集成实践，这将有助于推动gitlab-cI自动化。运行Docker Bench有提供现成的Docker容器镜像，我们直接拿来使用。请注意，此容器正以大量特权运行- 共享主机的文件系统，pid和网络命名空间，因为基准测试的部分应用于正在运行的主机。不要忘记根据你的操作系统调整共享卷，例如它可能不使用systemddocker run -it --net host --pid host --userns host --cap-add audit_control \ -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \ -v /var/lib:/var/lib \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /usr/lib/systemd:/usr/lib/systemd \ -v /etc:/etc --label docker_bench_security \ docker/docker-bench-security默认情况下，会检查所有的容器项目和镜像，我们要通过选项来规避一些我们想要的结果： -b optional Do not print colors -h optional Print this help message -l FILE optional Log output in FILE -c CHECK optional Comma delimited list of specific check(s) -e CHECK optional Comma delimited list of specific check(s) to exclude -i INCLUDE optional Comma delimited list of patterns within a container name to check -x EXCLUDE optional Comma delimited list of patterns within a container name to exclude from check -t TARGET optional Comma delimited list of images name to checktype一共会检查如下几项，我们通过-c参数：-c docker_daemon_configuration 来检查我们想要一个函数的结果。如果你的粒度更小 ，可以使用:-c check_2找到。[INFO] 1 - Host Configuration [INFO] 2 - Docker daemon configuration [INFO] 3 - Docker daemon configuration files [INFO] 4 - Container Images and Build File [INFO] 5 - Container Runtime [INFO] 6 - Docker Security Operations [INFO] 7 - Docker Swarm Configuration示例：仅仅检查-c docker_daemon_configuration，并且镜像只是registry.linuxea.com/dev/linuxeabbs:latest[root@linuxea.com ~]# docker run -it --net host \ --pid host \ --userns host \ --cap-add audit_control \ -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \ -v /var/lib:/var/lib \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /usr/lib/systemd:/usr/lib/systemd \ -v /etc:/etc \ --label docker_bench_security \ docker/docker-bench-security -t registry.linuxea.com/dev/linuxeabbs:latest -c docker_daemon_configuration在或者检查某一个小项添加到管道参数：-t 指定镜像-c 指定CIS，只检查指定的项目-l 结果输出到文件(似乎不好用，用tee代替)添加新的项3/3 DockerBench_Security: <<: *bash_init script: - docker_bench_security artifacts: name: "$CI_JOB_STAGE-$CI_COMMIT_REF_NAME" paths: [docker_bench_security.log]函数部分 function docker_bench_security() { export PROJECT_NAME=$(echo "$CI_PROJECT_PATH_SLUG" |awk -F- '{print $2}') export IMAGE_TAG_LATEST="$REPOSITORY_URL"/"$PROJECT_NAME":latest docker run -i --rm --net host \ --pid host \ --userns host \ --cap-add audit_control \ -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \ -v /var/lib:/var/lib \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /usr/lib/systemd:/usr/lib/systemd \ -v /etc:/etc \ --label docker_bench_security \ docker/docker-bench-security -t "$IMAGE_TAG_LATEST" -c container_images |tee docker_bench_security.log }运行部分结果如下：延伸阅读linuxea:如何使用gitlab-ci/cd来构建docker镜像和发布linuxea:gitlab-ci/cd docker容器漏洞扫描clair-scannerlinuxea:gitlab-ci/cd runner配置和安装(一)linuxea:gitlab-ci的定时任务linuxea:docker仓库harbor-https的配置和使用linuxea:白话容器之Registry与Harbor的构建和使用 (26)linuxea:Docker多阶段构建与- target和--cache-from阅读更多devopsgitlabgitlab-ci/cdjenkins

linuxea:gitlab-ci/cd docker容器漏洞扫描clair-scanner 一个镜像被build完成后，并不一定就是符合预期的，这往往取决于编写Dockerfile的用户的水平。尽管我们可以安排很多规则，使用很多制度去规避这些风险，但是总有一些事情发生超乎我的预料之外。为此，我们需要一些检测 镜像是否符合预期的手段。Docker镜像包含一个应用程序及其所有依赖项。由于它还包含操作系统的众多二进制文件和库，因此确保其根文件系统中不存在任何漏洞或至少不存在任何关键或主要漏洞非常重要。扫描CI / CD管道中的镜像可以降低这种安全风险。在前一篇文章中，我简单的介绍了如何使用gitlab在一个非常简单的go项目上设置CI / CD管道。管道中定义了了两个阶段：build 镜像部署事实上 ，我们可以在build镜像之前，做静态的代码分析在此过程中构建的docker镜像基于我此前 制作的镜像，但是这是一个无验证其内部的，我们需要做一些改善。阅读本章节，你将了解在CI中对镜像做一些简单的漏洞检测，在此后的文章中还继续会有此类的应用出现在CI中。添加镜像扫描到管道有几种镜像扫描解决方案，商业和开源。在本文中，我们将使用Clair和clair-scanner，2个开源工具。GitLab的以下文档提供了添加专用于镜像扫描的附加阶段的所有说明，https：//docs.gitlab.com/ce/ci/examples/container_scanning.html，它基本上运行Clair服务器，提供现有的CVE，然后二进制文件->clair-scanner检查镜像构建的每一层。上述链接中的管道语法是基于Docker的，经过尝试，发现并不适用于当下我的shell环境，于是我做了简单的修改。那现在的这个函数风格就成了这样： function image_check() { export PROJECT_NAME=$(echo "$CI_PROJECT_PATH_SLUG" |awk -F- '{print $2}') export CLAIRR=$(docker inspect --format={{.NetworkSettings.IPAddress}} clair) export DINDIRR=$(ip addr show docker0|awk 'NR==3{split($2,a,"/"); print a[1]}') export IMAGE_TAG_LATEST="$REPOSITORY_URL"/"$PROJECT_NAME":latest if [ `docker ps -a|awk '{print $NF}'|egrep "db"|wc -l` == 1 ];then echo "db is exist"; else docker run -d --name db arminc/clair-db:latest; fi if [ `docker ps -a|awk '{print $NF}'|egrep "clair"|wc -l` == 1 ];then echo "clair is exist"; else docker run -p 6060:6060 --link db:postgres -d --name clair --restart on-failure arminc/clair-local-scan:v2.0.7; fi echo -e "\033[44;37m`date +%F/%T` CVE scanning Start running now ....\033[0m" docker run --name docker-dind -i --rm -v /var/run/docker.sock:/var/run/docker.sock docker:stable-dind apk add wget ca-certificates \ && wget -qO ./clair-scanner https://github.com/arminc/clair-scanner/releases/download/v8/clair-scanner_linux_amd64 \ && chmod +x ./clair-scanner \ && echo -e "clairIP:\033[31m\033[01m[ $CLAIRR ]\033[0m\ndockerIP: \033[31m\033[01m\033[05m[ $DINDIRR ]\033[0m\nImages Name: \033[31m\033[01m\033[05m[ $IMAGE_TAG_LATEST ]\033[0m \033[0m" \ && touch clair-whitelist.yml \ && while( ! wget -q -O /dev/null http://"$CLAIRR":6060/v1/namespaces ) ; do sleep 1 ; done \ && retries=0 \ && echo -e "\033[44;37m`date +%F/%T` Waiting for clair daemon to start\033[0m" \ && while( ! wget -T 10 -q -O /dev/null http://"$CLAIRR":6060/v1/namespaces ) ; do sleep 1 ; echo -n "." ; if [ $retries -eq 10 ] ; then echo " Timeout, aborting." ; exit 1 ; fi ; retries=$(($retries+1)) ; done \ && ./clair-scanner -c http://"$CLAIRR":6060 --ip "$DINDIRR" -r gl-container-scanning-report.html -l clair.log -w clair-whitelist.yml "$IMAGE_TAG_LATEST" || true }还是使用了docker-in-docker，不过，我从shell启动，而后传递参数，而不是直接在gitlab-ci中定义docker images。注意：我这里有使用的ansible，ansible在宿主机，docker中需要安装也可以，如果这样，就意味着需要重新build docker:dind镜像。我只能寄托于gitlab-runner的executors(执行人)支持多个，当然，这是不存在的。很明显，这也不合时宜。并且，我更喜欢这样的shell风格，仅此而已。添加了这个新阶段，让我们看看它是如何运行新的管道。下面的屏幕截图显示了这个新的image_sanning阶段的部分输出。可以在顶部看到镜像的每一层都被分析。可以看到，这似乎还不错，没有明显的漏洞。摘要这篇短文说明在现有的CI / CD管道中添加简单的镜像扫描阶段并不复杂。这提供了其他信息，例如镜像包含的漏洞的数量和ID。从这些信息来看，仍然很难知道如何处理它们，但是遵循好的习惯能够避免一些问题。延伸阅读linuxea:如何使用gitlab-ci/cd来构建docker镜像和发布linuxea:gitlab-ci/cd runner配置和安装(一)linuxea:gitlab-ci的定时任务linuxea:docker仓库harbor-https的配置和使用linuxea:白话容器之Registry与Harbor的构建和使用 (26)linuxea:Docker多阶段构建与- target和--cache-from阅读更多devopsgitlabgitlab-ci/cdjenkins

linuxea:如何使用gitlab-ci/cd来构建docker镜像和发布 此前发布了一些关于gitlab和jenkins的文章，主要围绕简单的发布更新，但没有设计到docker环节，此篇将会简单的介绍如何通过gitlab-ci来做一次docker的打包和发布。阅读此章节，你将了解如何使用gitlab-ci进行docker打包镜像，以及周边的依赖使用。如果你不了解gitlab和gitlab-runner的使用，请查看此前的gitlab和gitlab-runner的配置安装部分简述我们先准备一个非常简单的代码，而后通过gitlab-ci使用docker build镜像，而后push到仓库中，在使用ansible命令到node节点来拉取镜像，完成一个非常简单的发布更新。这里需要注意的是gitlab和私有仓库的验证问题，可以参考linuxea:gitlab和gitlab-runner与harbor的配置安装的配置部分，大致可能是这样：external_url 'http://git.linuxea.com' gitlab_rails['registry_enabled'] = true gitlab_rails['registry_path'] = "/var/opt/gitlab/gitlab-rails/shared/registry" gitlab_rails['registry_api_url'] = "http://registry.linuxea.com" registry['enable'] = false尽管这只是一个简单的测试，但仍然可以通过这个过程来了解一次构建，或者说使用gitlab-ci构建发生的事情和部分细节。我将会在后续的文章中继续更新关于从docker镜像出发的问题上在做几个ci的处理，比如：镜像质量。代码准备一个go文件测试package main import ( "fmt" "net/http" ) func Hello(w http.ResponseWriter,r *http.Request) { fmt.Println("helo www.linuxea.com") fmt.Fprint(w,"20190303 www.linuxea.com") } func login(w http.ResponseWriter,r *http.Request) { fmt.Println("login") fmt.Fprint(w,"login") } func main() { http.HandleFunc("/",Hello) http.HandleFunc("/user/login",login) err := http.ListenAndServe("0.0.0.0:8080",nil) if err != nil { fmt.Println("http listen failed") } } Dockerfiledockerfile的作用将go文件复制到容器内启动即可FROM marksugar/go:alpine-go1.11.5 as linuxea MAINTAINER www.linuxea.com LABEL maintainer="www.linuxea.com" RUN mkdir /data COPY linuxea.go /data/linuxea.go COPY . /data/ WORKDIR /data CMD ["go","run","linuxea.go"]尽管这里使用的是COPY了一个文件，为了区分dockerignore的效果，我COPY .到/data下。我想我们在实际使用中仍然有必要使用.dockerignore来忽略一些文件，如下.git **/*.log **/*-log-* **/*.tar.gz **/*.war jenkins_home/*.txt Dockerfile .dockerignore *.md !info.md LICENSE CHANGELOG .gitlab-ci.ymlRegistry我们需要一个仓库来存放构建好的镜像，我这里使用的是Harbor，我在harbor创建另一个用户，而后在gitlab中设置，现在先测试一下登陆[root@linuxea.com_10_10_240_145 ~/linuxeabbs]$ echo "123.linuxea.coM" | docker login --username linuxea registry.linuxea.com --password-stdin WARNING! Your password will be stored unencrypted in /root/.docker/config.json. Configure a credential helper to remove this warning. See https://docs.docker.com/engine/reference/commandline/login/#credentials-store Login SucceededHarbor的构建和使用参考此前的linuxea:白话容器之Registry与Harbor的构建和使用 (26)gitlab我至少要设置三个变量在gitlab的ci构建中，分别是：CI_BUILD_TOKENCI_BUILD_USERREPOSITORY_URL这三个变量分别扮演用户，密码，Registry地址，如下：这些变量在上面的registry中提到过，是在harbor中创建好的用户，以及仓库/dev也是我提前创建好的。此后我在.gitlab-ci.yml中调用gitlab-ci在整个gitlab-ci中，只是做了两个阶段，分别是build镜像，推送到仓库，而后到节点上进行配置一个anisble，而后调用ansible pull镜像。准备ansible[linuxea-bbs] 172.25.50.17 ansible_ssh_user=root ansible_ssh_port=22992 ansible_ssh_pass=dtops.cc我编写了简单的方式来实现这个构建和发布的过程，借用了docker-compose，在stages中分为两个阶段 ：build和deploy-test。这样用的好处是，在build中可以有多个阶段树，当build执行完成后，到了deploy-test会通过手动点击完成更新。如下：stages: - build - deploy-test # 变量 variables: LANG: "en_US.UTF-8" PROJECT_HOSTGROUP: "linuxea-bbs" before_script: - echo "start now!" - export LANG=en_US.UTF-8 - export LANGUAGE=en_US:en - export LC_ALL=en_US.UTF-8 .base_init: &bash_init stage: build allow_failure: true # build镜像 1/3 docker_build: <<: *bash_init script: - docker_build artifacts: name: "$CI_JOB_STAGE-$CI_COMMIT_REF_NAME" paths: [build.json] 2/3 image_check: <<: *bash_init script: - image_check deploy: stage: deploy-test environment: name: staging url: http://172.25.50.17:8080 only: - master script: #- ansible ${PROJECT_HOSTGROUP} -m shell -a "[ -d ${WWWDIR} ]||mkdir ${WWWDIR} -p" #- ansible ${PROJECT_HOSTGROUP} -m synchronize -a 'src=./ dest=${WWWDIR}/ rsync_opts=--delete,--exclude=*.json,--exclude=*.yml,--exclude=*.git' #- ansible ${ANSIBLEGROUP} -m shell -a "chown -R 400.400 /data/wwwroot/" - ansible ${PROJECT_HOSTGROUP} -m shell -a "echo "$CI_BUILD_TOKEN" | docker login --username "$CI_BUILD_USER" "$REPOSITORY_URL" --password-stdin" - ansible ${PROJECT_HOSTGROUP} -m shell -a "cd /data/ && docker-compose pull" - ansible ${PROJECT_HOSTGROUP} -m shell -a "cd /data/ && docker-compose up -d" when: manual allow_failure: false #-----------------------Auto_Devops----------------------------- .auto_devops: &auto_devops | [[ "$TRACE" ]] && set -x function docker_build() { echo "$CI_BUILD_TOKEN" | docker login --username $CI_BUILD_USER $REPOSITORY_URL --password-stdin # docker login -u $CI_BUILD_USER -p $CI_BUILD_TOKEN $REPOSITORY_URL export PROJECT_NAME=$(echo "$CI_PROJECT_PATH_SLUG" |awk -F- '{print $2}') export PROJECT_TAG=$(echo "$CI_COMMIT_SHA" |cut -c 1-5) export IMAGE_TAG="$REPOSITORY_URL"/"$PROJECT_NAME":"$PROJECT_TAG" export IMAGE_TAG_LATEST="$REPOSITORY_URL"/"$PROJECT_NAME" export CONTAINER_IMAGE="$REPOSITORY_URL"/"$PROJECT_NAME" docker pull "$CONTAINER_IMAGE":latest || true docker build -t "$IMAGE_TAG" . docker build -t "$IMAGE_TAG_LATEST" . docker push "$IMAGE_TAG" docker push "$IMAGE_TAG_LATEST" } function image_check() { echo "image_check" } before_script: #- echo "$CI_BUILD_TOKEN" | docker login --username $CI_BUILD_USER $REPOSITORY_URL --password-stdin - *auto_devops 重要说明如上所示，其中我使用版本号码的前五位数作为每次更新的镜像标签，并且每次会build两个镜像，分别是带标签的镜像和最新的镜像，这样的好处在于，每次更新只需要重新拉取即可。而回滚则指定镜像标签即可。命令摘取出来如下：CI_PROJECT_PATH_SLUG：获取项目名称PROJECT_TAG：获取版本号IMAGE_TAG：组合变量 export PROJECT_NAME=$(echo "$CI_PROJECT_PATH_SLUG" |awk -F- '{print $2}') export PROJECT_TAG=$(echo "$CI_COMMIT_SHA" |cut -c 1-5) export IMAGE_TAG="$REPOSITORY_URL"/"$PROJECT_NAME":"$PROJECT_TAG" export IMAGE_TAG_LATEST="$REPOSITORY_URL"/"$PROJECT_NAME" export CONTAINER_IMAGE="$REPOSITORY_URL"/"$PROJECT_NAME" docker pull "$CONTAINER_IMAGE":latest || true docker build -t "$IMAGE_TAG" . docker build -t "$IMAGE_TAG_LATEST" . docker push "$IMAGE_TAG" docker push "$IMAGE_TAG_LATEST"一旦代码发生变动就会执行gitlab-ci.yml的代码。build image开始部署点击开始执行ansible现在你的docker仓库中就被上传了对应的镜像，而latest一直都只有一个的。在实际使用的时候，如果出现权限不够，可如下尝试：usermod -aG docker gitlab-runner usermod -aG root gitlab-runner提示为了确保能够拉取到镜像，你需要配置daemon.json[root@etcd2 ~]# cat /etc/docker/daemon.json { "insecure-registries": ["registry.linuxea.com"] }另外，你可能还需要配置这些私有的域名解析 。如果你有疑问，你可以留言或者加入我们的QQ讨论群延伸阅读linuxea:gitlab-ci/cd runner配置和安装(一)linuxea:gitlab-ci的定时任务linuxea:docker仓库harbor-https的配置和使用linuxea:白话容器之Registry与Harbor的构建和使用 (26)linuxea:Docker多阶段构建与- target和--cache-from阅读更多devopsgitlabjenkins

linuxea:gitlab-ci的定时任务 在此前的基于gitlab的ci/cd中，我写了几篇文章来说明他的基本用法，我将会在后续的文章中不断来完善gitlab和jenkins的用法。阅读本章，你将了解gitlab基于ci的定时任务。安装配置gitlab-runner参考官网的安装手册进行安装即可yum install gitlab-runner而后可以常用docker或者shell的方式来选择后续命令执行的环境获取token，参考此前的安装配置文章dockergitlab-runner register \ --non-interactive \ --url "http://git.ds.com/" \ --registration-token "jQj1Fi2xd53xqg3ZeMVU" \ --executor "docker" \ --docker-image alpine:3.9 \ --description "docker-runner" \ --tag-list "docker,shell" \ --run-untagged \ --locked="false"shellgitlab-runner register \ --non-interactive \ --url "http://git.xx.com/" \ --registration-token "jQj1Fi2xd53xqg3ZeMVU" \ --executor "shell" \ --description "docker-runner" \ --tag-list "docker,shell" \ --run-untagged \ --locked="false"我这里使用的shellroot@linuxea.com ~ ☸ 2019-03-14 15:48:43 $ gitlab-runner register \ > --non-interactive \ > --url "http://git.xx.com/" \ > --registration-token "jQj1Fi2xd53xqg3ZeMVU" \ > --executor "shell" \ > --description "docker-runner" \ > --tag-list "docker,shell" \ > --run-untagged \ > --locked="false" Runtime platform arch=amd64 os=linux pid=13181 revision=4745a6f3 version=11.8.0 Running in system-mode. Registering runner... succeeded runner=jQj1Fi2x Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded! 配置文件位置root@linuxea.com ~ ☸ 2019-03-14 15:49:34 $ cat /etc/gitlab-runner/config.toml concurrent = 1 check_interval = 0 [session_server] session_timeout = 1800 [[runners]] name = "docker-runner" url = "http://git.ds.com/" token = "b5819c16ec11f45e8b6a59175453ec" executor = "shell" [runners.cache] [runners.cache.s3] [runners.cache.gcs]一般情况下，配置完成我们需要重启一下，尽管提示说会生效systemctl restart gitlab-runner.service 如果不想重启，可以通过list查看，并使用status查看是否runingroot@linuxea.com ~ ☸ 2019-03-14 15:50:34 $ gitlab-runner list Runtime platform arch=amd64 os=linux pid=14411 revision=4745a6f3 version=11.8.0 Listing configured runners ConfigFile=/etc/gitlab-runner/config.toml docker-runner Executor=shell Token=b5819c16ec11f45e8b6a59175453ec URL=http://git.ds.com/root@linuxea.com ~ ☸ 2019-03-14 15:51:30 $ gitlab-runner status docker-runner Runtime platform arch=amd64 os=linux pid=14523 revision=4745a6f3 version=11.8.0 gitlab-runner: Service is running!如果没有，也可以使用gitlab-runner start docker-runner来进行启动测试计划任务我们创建一个项目用作测试，并且写一个简单的命令，命名为.gitlab-ci.ymlstages: - test 1/1 test: stage: test script: - a=$(curl -s curlip.me|awk 'NR==5{print $2" "$3}') - echo $a如下图然后我们将使用GitLab-CI安排它每天运行。现在，我们配置"日程表"(汉化后叫日程表)。CI/CD ---> 日程表--->新建计划。我们创建一个1分钟执行一次的计划。这里的定时，取决于cron配置。那么表现的形式大致如下不过，这样你会发现，他只会运行一次，而后将遵循1小时运行一次的规律,如下图这些信息在gitlab社区有过讨论，得出的结果，也就是如果一个job设置了计划，那么最小的粒度是1小时延伸阅读安装runner配置runner查看更多如果你要查看更多关于jenkins和gitlab-ci/cd的文章，请关注一下分类。gitlab-ci/cdjenkins

linuxea: jenkins基于用户角色的权限控制 jenkins基于用户角色的权限控制需要Role-based Authorization Strategy插件的控制，其中需要借助jenkins用户对角色授权，而在角色下添加项目的所属角色，而这个角色通过正则匹配绑定项目，那这也就是说你的项目要想做控制，必须有统一的一个标签来进行区分。那如果你事先没有准备，也没有关系，Rename即可。这些绑定后，在到全局roles中勾选对应的：角色和项目，相互对应即可完成权限控制。如果你可以打开官网，推荐阅读：https://wiki.jenkins.io/display/JENKINS/Role+Strategy+Plugin先决条件：​ jenkins version: 2.138.2 ​ 插件：Role-based Authorization Strategy安装插件登录jenkins，在左侧选择Manage Jenkins(管理詹金斯)找到管理插件(Manage Plugins)而后点击"Installed"，在右侧"Filter"中输入"role",可以看到我这里已经安装了一个Role-based Authorization Strategy ,如下图而后仍然在Manage Jenkins页面中选择Configure Global Security，打开Role-Based Strategy创建用户在Manage Jenkins中选择Manage Users，点击Create User,创建用户Manage and Assign Roles这时候Manage Jenkins页面就多了一个Manage and Assign Roles，进入选择Manage RolesManage Roles而后在Global roles 中的role to add中add一个输入角色role。这个角色的权限只有read这里的图片太宽，请右击“在新的标签页打开”打开图片而后在add一个Project roles这里的Project roles和Global roles是相互对应，Global roles是全局角色，而Project roles是项目角色，为了便于区分，我建议将全局role或者项目role以及用户名设置成一样。而Pattern是一个正则匹配。以项目开头来区分分配。如: linuxea. 也就是说以linuxea开头的都划入linuxea角色中，linuxea项目具备linuxea角色的授权权限.如果你是linuxea-api-euk这样的项目，那么就应该写成linuxea-api-.之类的如下图而后保存。Assign Roles回到Manage Jenkins中一个Manage and Assign Roles页面，选择Assign Roles进入在Global roles和Item roles add 用户和item rolesitem roles关联了Project roles中的Pattern中的正则匹配和被正则匹配中的项目的项目权限。由此你可以控制你的项目权限

linuxea:jenkins pipeline阶段终止 在管道中，声明的阶段里面是连续的，其中，可以配置的方式很多。且不管每个阶段运行的状态如何，都可以为配置成想要的一些操作，或者行为。如：发邮件，多条件判断等。如果按照正常的运行，不做阶段处理，默认会依次执行多个阶段。这并不是我们想要的，因此，在每个阶段如果执行失败就终止，而不执行后面的是有必要的。当然，这里是有区分的，脚本管道可以使用try，而post作用范围更大使用try 和currentBuild.result = 'FAILURE'即可假如此阶段不通就停止了。相反的，假如此刻需求是，无论那个阶段执行失败都不应该终止，就默认即可。但是，需求如果变成，当执行失败后的还需要动作，参考external-workspace-manager