Gitlab-Ci-Runner

先来说一下配置CI/CD的目标，咱们在提交代码后即提交push申请后gitLab会主动生成一个pipeLine工作，如果咱们想要在每次提交代码之后都跑一次单元测试就须要对其进行编辑，此外咱们还能够在此运行咱们自定义的脚本来实现更多需要，例如向钉钉收回推送。 上面这就是对应的配置文件——.gitlab-ci.yml咱们在此文件中次要用到的一共就只有上面几个关键词： stages：设置运行步骤variables：定义变量tags：设置运行环境script：设置要执行的命令对于stages: stages: -step1 //步骤一 -step2 //步骤二step_one: stage: step1 //申明是属于步骤一 . . .step_two: stage: step1 //申明是属于步骤一. . .step_three stage: step2 //申明是属于步骤二. . .其中step_one和step_two是并行执行的。step_two在其后执行。 对于variables须要揭示的是gitLab有本人内置的变量，咱们能够间接进行应用，只须要在scrpts: 执行-env，就能够查看总共有那些变量。 对于scrpts:其作用就相当咱们本地的在我的项目根目录下的终端，输出相应指令就能够在运行相应步骤时执行。 对于tags：申明运行时所用的环境 第一个问题—在远端执行时呈现格局报错咱们自定义的脚本在本地运行没有问题后就提交到了gitlab中通过gitlab CI/CD调用时却产生了格局谬误，例如：存在预期之外的“（”等报错。 在网上查找后所失去的问题出处都是呈现在脚本解释器的阐明上即脚本结尾的 #!/bin/bash 然而通过测试——新建test.sh在远端运行通过bash解释器运行发现并没有问题，不会产生报错； 于是我又认真地看了一边shell教程，发现这下面对于函数的阐明是这样的:没有用到function关键字，于是我尝试着去掉它之后发现的确不报错了，但之后在远端执行时还遇到等等其余的格局问题就不在此一一赘述了。 一步一步跟着远端运行的报错解决完格局问题后的确能够在远端残缺运行咱们自定义的.sh文件，然而为什么在本地就没有这些格局问题在远端就呈现问题了过后还是没有解决，过后只是把它归纳于可能是版本不一样。 所以这样的解决办法就带来了上面第二个问题： 问题二—获取pipeLine运行工夫时遇到的问题在gitlab给出的pipeLine自带的变量中只有pipeLine的创立工夫：CI_PIPELINE_CREATED_AT 一开始是想可不可以间接在gitLab CI 运行时取得以后工夫，间接在gitLab配置文件中计算出其时间差，然而找了很久都没有找到能够间接在gitLab CI中获取以后工夫的办法，所以只能转变思路——把CI_PIPELINE_CREATED_AT传给咱们的shell脚本，在脚本中实现这些操作。 currentTime=`date "+%Y-%m-%d %H:%M:%S"` //获取工夫while [ -n "$1" ]; do //shell脚本是以字符串为单位承受的变量case "$1" in. . .-M) PIPE="$2" //把$2即传过来的工夫赋给PIPE CURRENT_STAMP=$(date -d "$currentTime" +%s) //转化为工夫戳 PIPE_STAMP=$(date -d "$PIPE" +%s) //转化为工夫戳 TIME_STRING=$((CURRENT_STAMP-PIPE_STAMP)) //计算工夫戳差值 CONTENT=$CONTENT$TIME_STRING"秒" shift 2 //将数据前移2项，即$1=$3,$2=$4... ;;done在本地执行之后能够失常运行，在远端运行时发现最初计算出来的差值始终为零，起初认为是pipe_line的开始工夫有误，然而查看后与预期统一，于是就尝试着在脚本中输入转化后的起始工夫戳和以后工夫戳然而发现其打印后果都为空。 ...

gitlab的单元测试依赖于gitlab-runner，gitlab-runner的作用便是根本gitlab仓库相干的配置来运行单元测试(蕴含但不限于)并把单元测试的后果反馈给gitlab。 所以如果咱们跑单元测试的环境是macos，则须要在一台macos主机上安装gitlab-runner；如果咱们跑单元测试的环境是ubuntu，则须要在一台ubuntu的主机上安装gitlab-runner。 gitlab-runner装置实现后，须要将其注册到gitlab中，这样gitlab才会对其发动近程的调用。注册命令如下： sudo gitlab-runner register --url https://yourGitLab.ServerDomainName.com --registration-token yourGitLabToken但出于某些平安方面的起因，如果咱们的gitlab服务器的证书并不在拟运行单元测试主机的无效验证范畴，则会报一个如下谬误： This solves the x509: certificate signed by unknown authority problem when registering a runner.此时则须要咱们在运行注册命令时，手动的为其指定一个无效的证书。 解决方案gitlab官网专门对这个问题进行了阐明。大略就是说咱们须要手动的为每个预注册的站点来指定相干的证书。 在https的拜访过程中，浏览器会主动的为咱们下载证书并应用 CA 证书进行验证，但gitlab-runner并不会如此，所以咱们须要手动的帮忙一下它。 尽管gitlab的官网给出了几种解决方案，但试验证实将下载到的证书注册到操作系统上是最简略的计划。 步骤如下： 获取证书如果跑gitlab服务的网站的证书就是你申请的，那么你自身就领有一个crt证书，能够略过此步，持续往下看。 如果咱们并不把握以后站点的证书，则能够应用openssl来将获取服务器的crt证书，该操作能够在运行gitlab-runner的测试机上进行，也能够在本人的电脑上进行： openssl s_client -showcerts -connect gitlab.example.com:443(批改为你本人的域名及端口) < /dev/null 2>/dev/null | openssl x509 -outform PEM > ~/gitlab.example.com.crt(批改为本人的名字)总之呢，咱们须要的是一个在gitlab站点上装置的crt证书。 注册证书假如咱们按上一步的操作拿到了相干站点的证书，并且上传到了运行gitlab-runner的机器上。上面，咱们以ubuntu操作系统为例，介绍如何把这个证书全局的装置到操作系统。 yunzhi@yunzhi-virtual-machine:/etc/ca-certificates$ sudo apt-get install -y ca-certificates[sudo] password for yunzhi: Reading package lists... DoneBuilding dependency tree Reading state information... Doneca-certificates is already the newest version (20210119~20.04.2).0 upgraded, 0 newly installed, 0 to remove and 160 not upgraded.yunzhi@yunzhi-virtual-machine:~$ sudo cp gitlab.example.com.crt /usr/local/share/ca-certificates/yunzhi@yunzhi-virtual-machine:/usr/local/share/ca-certificates$ sudo update-ca-certificatesUpdating certificates in /etc/ssl/certs...rehash: warning: skipping DigiCert-Global-Root-CA.pem,it does not contain exactly one certificate or CRL1 added, 0 removed; done.Running hooks in /etc/ca-certificates/update.d...done.是要害，示意胜利增加了1个证书。 ...

【日常】.gitlab-ci.yml解读# .job: 定义暗藏的工作Job，该工作不会被Gitlab cicd执行# &template 定义锚点# 暗藏工作联合锚点，能够提供模板给工作Job复用 —— 不可跨文件应用，跨文件思考`!reference`API# .job: &template定义可复用的内容.script_package_install-deploy: &script_package_install-deploy | yarn global add @custom/deploy-tool# docker 镜像image: node:latest# 钩子函数，脚本执行之前须要执行的命令before_script: - npm config set registry https://registry.npm.taobao.org/ - npm config set cache-folder .cache - *script_package_install-deploy# 定义不同的周期阶段，属于同一周期的工作Job并行执行stages: - build - deploy_staging - deploy_preview - deploy_production# .job: &template定义可复用的内容.script_set_env: &script_set_env | if [ "$CI_COMMIT_REF_NAME" == "production" ]; then if [ "$CI_JOB_STAGE" == "deploy_production" ]; then export DEPLOY_ENVIRONMENT=prod else export DEPLOY_ENVIRONMENT=preview fi else [ "$CI_COMMIT_REF_NAME" == "staging" ] export DEPLOY_ENVIRONMENT=staging fi# .job: &template定义可复用的内容# 通过*template应用锚点定义的内容.deploy: &deploy_common script: - *script_set_env - deploy-tool deploy# 定义工作buildbuild: stage: build # 所属周期阶段，同周期的并行执行 cache: # 须要缓存文件 key: $CI_PROJECT_NAME paths: - .cache/**/* - node_modules/**/* script: # 该工作要执行的脚本 - npm i - *script_set_env # 通过*template应用锚点定义的内容 - deploy-tool build only: # 执行机会：staging、production分支push后主动执行 - staging - production# 定义工作deploy_stagingdeploy_staging: stage: deploy_staging # 所属周期阶段，同周期的并行执行 <<: *deploy_common # 通过<<: *template合并锚点定义的内容 environment: # 定义要部署的环境 name: staging only: # 执行机会：staging分支push后主动执行 - staging# 定义工作deploy_previewdeploy_preview: stage: deploy_preview # 所属周期阶段，同周期的并行执行 <<: *deploy_common # 通过<<: *template合并锚点定义的内容 environment: # 定义要部署的环境 name: preview only: # 执行机会：production分支push后主动执行 - production# 定义工作deploy_previewdeploy_production: stage: deploy_production # 所属周期阶段，同周期的并行执行 <<: *deploy_common # 通过<<: *template合并锚点定义的内容 environment: # 定义要部署的环境 name: production when: manual # 手动执行 only: # 因为when的存在，不主动执行了，when默认值on_success - production*template vs. <<: *template*template：复用的只是工作脚本的其中一个指令<<: *template：复用的是整个工作脚本 ...

GitLab CI 是什么？GitLab CI 是GitLab内置的进行继续集成的工具，只须要在仓库根目录下创立.gitlab-ci.yml 文件，并配置GitLab Runner；每次提交的时候，gitlab将自动识别到.gitlab-ci.yml文件，并且应用Gitlab Runner执行该脚本。 Gitlab Runner简介GitLab-Runner就是一个用来执行.gitlab-ci.yml 脚本的工具。Runner就像认真工作的工人，GitLab-CI就是治理工人的核心，所有工人都要在GitLab-CI外面注册。当相应的我的项目发生变化时，GitLab-CI就会告诉相应的工人执行对应的脚本。 GitLab-Runner个别都是配合GitLab-CI应用的,在GitLab外面定义一个属于这个工程的软件集成脚本，用来自动化地实现一些软件集成工作。GitLab-Runner执行状况如下： 本地代码改变变动代码推送到GitLab上GitLab 将这个变动告诉GitLab-CIGitLab-CI找出这个工程相关联的gitlab-runnergitlab-runner把代码更新到本地依据预设置的条件配置好环境依据预约义的脚本(个别是.gitlab-ci.yml)执行把执行后果告诉给GitLabGitLab显示最终执行的后果Runner类型gitLab-Runner能够分类两种类型：Shared Runner（共享型）和Specific Runner（指定型）。 Shared Runner：所有工程都可能用的，且只有系统管理员可能创立。Specific Runner：只有特定的我的项目能够应用。Runner搭建1. Runner 装置　(Install GitLab Runner 官网)GitLab Runner 能够在 GNU/Linux、macOS、FreeBSD 和 Windows 上装置和应用。你能够装置它： 在一个容器中。通过手动下载二进制文件。通过应用 rpm/deb 包的存储库。以Ubuntu为例(Install GitLab Runner using the official GitLab repositories)： 1. Add the official GitLab repository:# For Debian/Ubuntucurl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash2. Install the latest version of GitLab Runner, or skip to the next step to install a specific version:# For Debian/Ubuntu/Mintsudo apt-get install gitlab-runner2. 获取Runner注册Token装置好Runner之后，须要向Gitlab进行注册，注册Runner须要GitLab-CI的url和token。可依据需要注册抉择所需类型Runner。 ...

简介GitLab-CI GitLab-CI就是一套配合GitLab应用的继续集成系统（当然，还有其它的继续集成系统，同样能够配合GitLab应用，比方Jenkins）。而且GitLab8.0当前的版本是默认集成了GitLab-CI并且默认启用的。 GitLab-Runner GitLab-Runner是配合GitLab-CI进行应用的。个别地，GitLab外面的每一个工程都会定义一个属于这个工程的软件集成脚本，用来自动化地实现一些软件集成工作。当这个工程的仓库代码产生变动时，比方有人push了代码，GitLab就会将这个变动告诉GitLab-CI。这时GitLab-CI会找出与这个工程相关联的Runner，并告诉这些Runner把代码更新到本地并执行预约义好的执行脚本。指标：代码提交到GitLab上，由GitLab的CI性能主动实现部署。原理：GitLab在接管到代码提交事件时，通过.gitlab-ci.yml的配置信息与对应节点上的runner进行交互。装置部署planA （内网可用）下载&&装置[root@gitlab ~]# wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-12.0.1-ce.0.el7.x86_64.rpm--2021-08-16 10:11:02-- https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-12.0.1-ce.0.el7.x86_64.rpmResolving mirrors.xxxxe.com (mirrors.xxxxe.com)... 10.130.104.43Connecting to mirrors.xxxxe.com (mirrors.xxxxe.com)|10.130.104.43|:443... connected.HTTP request sent, awaiting response... 200 OKLength: 32189634 (31M) [application/x-redhat-package-manager]Saving to: ‘gitlab-ce-12.0.1-ce.0.el7.x86_64.rpm’100%[=============================================================================================================================>] 32,189,634 2.23MB/s in 11s 2021-08-16 10:11:13 (2.80 MB/s) - ‘gitlab-ce-12.0.1-ce.0.el7.x86_64.rpm’ saved [32189634/32189634][root@gitlab ~]# lsanaconda-ks.cfg gitlab-ce-12.0.1-ce.0.el7.x86_64.rpm[root@gitlab ~]# rpm -ivh gitlab-ce-12.0.1-ce.0.el7.x86_64.rpm warning: gitlab-ce-12.0.1-ce.0.el7.x86_64.rpm: Header V4 RSA/SHA512 Signature, key ID 880721d4: NOKEYerror: Failed dependencies: git is needed by gitlab-runner-12.0.1-1.x86_64[root@gitlab ~]# cat /etc/redhat-releaseCentOS Linux release 7.4.1708 (Core) [root@gitlab ~]# rpm -ivh gitlab-ce-12.0.1-ce.0.el7.x86_64.rpm --nodeps --forcewarning: gitlab-ce-12.0.1-ce.0.el7.x86_64.rpm: Header V4 RSA/SHA512 Signature, key ID 880721d4: NOKEYPreparing... ################################# [100%]Updating / installing... 1:gitlab-runner-12.0.1-1 ################################# [100%]GitLab Runner: creating gitlab-runner...批改gitlab-runner 启动用户[root@gitlab ~]# ps -ef | grep runnerroot 3739 1 0 10:23 ? 00:00:00 /usr/lib/gitlab-runner/gitlab-runner run --working-directory /home/gitlab-runner --config /etc/gitlab-runner/config.toml --service gitlab-runner --syslog --user gitlab-runnerroot 3801 3780 0 10:49 pts/0 00:00:00 grep --color=auto runner[root@gitlab ~]# gitlab-runner uninstallRuntime platform arch=amd64 os=linux pid=3802 revision=0e5417a3 version=12.0.1[root@gitlab ~]# gitlab-runner install --working-directory /root --user rootRuntime platform arch=amd64 os=linux pid=3821 revision=0e5417a3 version=12.0.1[root@gitlab ~]# gitlab-runner restartRuntime platform arch=amd64 os=linux pid=3853 revision=0e5417a3 version=12.0.1[root@gitlab ~]# gitlab-runner statusRuntime platform arch=amd64 os=linux pid=3868 revision=0e5417a3 version=12.0.1gitlab-runner: Service is running![root@gitlab ~]# ps -ef | grep gitlab-runnerroot 3861 1 0 10:51 ? 00:00:00 /usr/lib/gitlab-runner/gitlab-runner run --working-directory /root --config /etc/gitlab-runner/config.toml --service gitlab-runner --syslog --user root注册[root@gitlab ~]# gitlab-ci-multi-runner registerRuntime platform arch=amd64 os=linux pid=3878 revision=0e5417a3 version=12.0.1Running in system-mode. Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):https://gitlab.xxxx.com #gitlab urlPlease enter the gitlab-ci token for this runner:Gxxxxxxxxxxxxxxxx7 #gitlab tokenPlease enter the gitlab-ci description for this runner:[gitlab]: wuhan-tongj-10.82.16.44Please enter the gitlab-ci tags for this runner (comma separated):wuhan-tongj-10.82.16.44Registering runner... succeeded runner=GLNByiz6Please enter the executor: shell, virtualbox, docker+machine, docker-ssh+machine, docker, parallels, kubernetes, docker-ssh, ssh:shell #脚本执行的语言用处等Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded! ...

概念服务治理遇到的问题 在微服务项目中每个服务都是独立运行的我的项目不可能对每个我的项目进行手动部署,波及到自动化运维的问题 继续集成继续集成(Continues Integration,简称CI)继续集成指的是,频繁(一天屡次)地将代码集成到骨干,长处有两个: 疾速发现错误: 每实现一点更新, 就集成到骨干,能够疾速发现错误,定位谬误避免分支大幅偏离主题: 如果不是常常集成,骨干又在不断更新,会导致当前集成难度变大,甚至难以集成继续集成强调:开发人员提交了新的代码之后,立刻进行构建,(单元)测试,依据测试后果,确定新代码和原有代码是否集成到一起与集成相干的概念还有继续交付和继续部署 应用GitLab继续集成GitLab8.0当前,GitLab CI就曾经集成在GitL中,只有在我的项目中增加一个 .gitlab-ci.yml文件,而后增加一个Runner,就能够进行继续集成Pipeline Pipeline: 管道 ,一次Pipeline相当于一次构建工作,能够蕴含多个流程:装置依赖,运行测试,编译,部署测试服务器,部署生产服务器等流程任何提交或者Merge Request的合并都能够触发PipelineStages Stages示意构建阶段,也就是下面的流程,能够在一次Pipeline中构建多个Stages,这些Stages的特点: 所有Stages会依照程序运行: 即当一个Stage实现后,下一个Stage才会开始只有当所有Stages实现后,该构建工作(Pipeline)才会胜利如果任何一个Stage失败,那么后续的Stages都不会执行,该构建工作(Pipeline)失败Jobs Jobs示意构建工作,示意某个Stage外面执行的工作,能够在Stages里定义多个Jobs,这些Jobs特点: 雷同Stage中的Jobs会并行执行雷同Stage中的Jobs都执行胜利时,该Stage才会执行胜利如果任何一个Job失败,那么该Stage失败,即构建工作(Pipeline)失败 继续交付继续交付(Continuous Delivery): 频繁地将软件的新版本,交付给品质团队或用户以供评审评审通过,代码就进入生产阶段继续交付是继续集成的下一步,强调的是:不管怎么更新,软件是随时随地能够交付的继续交付是在继续集成的根底上,将集成后的代码部署到更靠近实在运行环境的类生产环境(production-like environment)中 继续部署继续部署(Continuous Deployment)是继续交付的下一步,指的是代码通过评审后,主动部署到生产环境继续部署的指标: 代码在任何时刻都是可部署的,可进入生产阶段继续部署的前提: 自动化实现测试,构建,部署等步骤 GitLab RunnerGitLab CI一般来说,构建工作会占用很多的系统资源(编译代码时),因为GitLab CI是GitLab的一部分,由GitLab CI来运行构建工作的化,GitLab的性能会大大降落GitLab CI最大的作用: 是治理各个我的项目的构建状态 GitLab RunnerGitLab Runner能够装置到不同的机器上,在构建工作运行期间不会影响GitL的性能基于Docker装置GitLab Runner: 1.创立工作目录: /usr/local/docker/runner2.创立构建目录: /usr/local/docker/runner/environment3.下载jdk-8u152-linux-x64.tar.gz复制到/usr/local/docker/runner/environment4.下载apache-maven-3.5.3-bin.tar.gz复制到/usr/local/docker/runner/environmentdaemon.json1.在/usr/local/docker/runner/environment目录下创立daemon.json,用于配置加速器和仓库地址-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------{ "registry-mirrors":[ "https://registry.docker-cn.com" ], "insecure-registries":[ "127.0.0.1:5000" ]}----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Dockerfile1.在 /usr/local/docker/runner/environment目录下创立Dockerfile---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------FROM gitlab/gitlab-runnerMAINTAINER Lusifer <topsale@vip.qq.com># 批改软件源RUN echo 'deb http://mirrors.aliyun.com/ubuntu/ xenial main restricted universe multiverse' > /etc/apt/sources.list && \ echo 'deb http://mirrors.aliyun.com/ubuntu/ xenial-security main restricted universe multiverse' >> /etc/apt/sources.list && \ echo 'deb http://mirrors.aliyun.com/ubuntu/ xenial-updates main restricted universe multiverse' >> /etc/apt/sources.list && \ echo 'deb http://mirrors.aliyun.com/ubuntu/ xenial-backports main restricted universe multiverse' >> /etc/apt/sources.list && \ apt-get update -y && \ apt-get clean# 装置 DockerRUN apt-get -y install apt-transport-https ca-certificates curl software-properties-common && \ curl -fsSL http://mirrors.aliyun.com/docker-ce/linux/ubuntu/gpg | apt-key add - && \ add-apt-repository "deb [arch=amd64] http://mirrors.aliyun.com/docker-ce/linux/ubuntu $(lsb_release -cs) stable" && \ apt-get update -y && \ apt-get install -y docker-ceCOPY daemon.json /etc/docker/daemon.json# 装置 Docker ComposeWORKDIR /usr/local/binRUN wget https://raw.githubusercontent.com/topsale/resources/master/docker/docker-composeRUN chmod +x docker-compose# 装置 JavaRUN mkdir -p /usr/local/javaWORKDIR /usr/local/javaCOPY jdk-8u152-linux-x64.tar.gz /usr/local/javaRUN tar -zxvf jdk-8u152-linux-x64.tar.gz && \ rm -fr jdk-8u152-linux-x64.tar.gz# 装置 MavenRUN mkdir -p /usr/local/mavenWORKDIR /usr/local/maven# RUN wget https://raw.githubusercontent.com/topsale/resources/master/maven/apache-maven-3.5.3-bin.tar.gzCOPY apache-maven-3.5.3-bin.tar.gz /usr/local/mavenRUN tar -zxvf apache-maven-3.5.3-bin.tar.gz && \ rm -fr apache-maven-3.5.3-bin.tar.gz# COPY settings.xml /usr/local/maven/apache-maven-3.5.3/conf/settings.xml# 配置环境变量ENV JAVA_HOME /usr/local/java/jdk1.8.0_152ENV MAVEN_HOME /usr/local/maven/apache-maven-3.5.3ENV PATH $PATH:$JAVA_HOME/bin:$MAVEN_HOME/binWORKDIR /--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------docker-compose.yml在 /usr/local/docker/runner 目录下创立 docker-compose.yml---------------------------------------------------------------------------------------------------------------------------------------------------------------------------# 示意从 environment 目录下寻找 Dockerfile，即在Docker 里装 Dockerversion: '3.1'services:gitlab-runner: build: environment restart: always container_name: gitlab-runner privileged: true volumes: - ./config:/etc/gitlab-runner - /var/run/docker.sock:/var/run/docker.sock------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------构建镜像并启动 ...

本文详细介绍如何在Linux系统使用Docker安装Gitlab、Gitlab-Runner并实现项目的CICD 一、安装Gitlab1、拉取镜像并启动由于服务器的80端口可能被占用，所以这里我们改成了其他端口来启动 docker run -d -p 2443:443 -p 5678:80 -p 2222:22 --name gitlab --restart always -v/srv/gitlab/config:/etc/gitlab -v /srv/gitlab/logs:/var/log/gitlab -v /src/gitlab/data:/var/opt/gitlab docker.io/gitlab/gitlab-ce2、修改配置文件修改gitlab.yml文件vim /src/gitlab/data/gitlab-rails/etc/gitlab.yml找到如下配置，修改host为你服务的IP或者域名(不能加http://)，修改完毕后保存退出 修改gitlab.rb文件vim /srv/gitlab/config/gitlab.rb找到external_url，默认是被注释的，要打开，并填写暴露出去的http://ip:port，IP一定要和gitlab.yml文件配置的相同，port为你启动时指定的，我们这里是5678，最后加上ssh协议下使用的IP和端口(这里的端口是你启动时指定的，我们这里是2222)，最后保存并退出 停止并移除之前启动的gitlab# 停止docker stop gitlab# 移除docker rm gitlab重新启动gitlab这里要将容器端口改为5678 docker run -d -p 2443:443 -p 5678:5678 -p 2222:22 --name gitlab --restart always -v/srv/gitlab/config:/etc/gitlab -v /srv/gitlab/logs:/var/log/gitlab -v /src/gitlab/data:/var/opt/gitlab docker.io/gitlab/gitlab-ce二、安装Gitlab-Runner可以在某个项目里``settings --> CICD --> Runner进行配置，也可以在GitLab主设置页安装共享Runner，安装方法都一致 1、拉取Runner镜像并启动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:latest2、进入Runner容器内docker exec -it gitlab-runner bash3、运行以下命令gitlab-runner register输入Gitlab实例的地址Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )http://xxx输入tokenPlease enter the gitlab-ci token for this runnerxxx输入Runner的描述Please enter the gitlab-ci description for this runner[hostname] my-runner输入与Runner关联的标签Please enter the gitlab-ci tags for this runner (comma separated):my-tag,another-tag输入Ruuner的执行者Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:docker如果上面执行者为docker，需要你在.gitlab-ci.yml中指定docker版本Please enter the Docker image (eg. ruby:2.1):alpine:latest通过以上命令后，就可以在gitlab中查看到了这个刚刚创建的runner ...

Github travis-ci CI CDCICD 是 持续集成Continuous Integration和持续部署Continuous Deployment简称。指在开发过程中自动执行一系列脚本来减低开发引入 bug 的概率，在新代码从开发到部署的过程中，尽量减少人工的介入。 本文主要介绍一下 travis-ci 持续集成和给 github Actions Travis-cihttps://www.travis-ci.org/1.登录travis-ci通过 github账号登录,会自动同步你的仓库 选择需设置的仓库 先勾选一个测试仓库 3 设置一些解释说明可以看具体的文档,主要包括这几方面 添加.travis.ymlTravis-ci 构建的生命周期 具体一些步骤可以查看文档. 这个文件主要是告诉 Travis CI 应该做什么,以前端node.js为例: language: node_js # 语言设置node_js: # node 版本 - "8"# npm现在默认缓存，如果您要禁用它，请将以下内容添加到您的.travis.yml：cache: npm: false before_install: # 安装前 - npm installscript: - npm run build如果当前目录存在yarn.lock可以使用 Yarn; 如果当前目录中都存在package.json和yarn.lock，则运行以下命令而不是 npm install 具体的一些配置,通过查看文档即可; 现在已经构建成功; 发布部署如果每次构建完都自动部署,或者手动部署可以再下一步; language: node_jsnode_js: - "8"before_install: - yarn installscript: - yarn build after_script: - cd ./dist - git init - git config user.name "${U_NAME}" - git config user.email "${U_EMAIL}" - git add . - git commit -m "Update tools" - git push --force --quiet "https://${GH_TOKEN}@${GH_REF}" master:${P_BRANCH}#指定分支，只有指定的分支提交时才会运行脚本branches: only: - master发布的是 github page 博客. ...

基于GitLab CI搭建Golang自动构建环境Golang发布遇到的问题对于golang的发布，之前一直没有一套规范的发布流程，来看看之前发布流程： 方案一开发者本地环境需要将环境变量文件改为正式环境配置编译成可执行文件发送给运维（运维）将文件覆盖为线上（运维）重启进程（可谓“又臭又长”） 方案二开发者讲代码commit到gitlab上交给运维同学（运维）pull代码（运维）编译成可执行文件（运维）覆盖线上文件（运维）重启进程这种对于运维属于重度依赖，而运维同学又需要去关心代码的编译，增加了运维同学的工作了。 以上两种方案都是之前项目中发生过的，对于发版来说可谓是一种“噩梦”，易出错，流程长，运维要是不在根本无法操作。 解决方案为了解决上面提到的两种发布问题，目前我们做了如下的设计方案： 开发者提交代码到GitLab服务器添加一个Tag触发构建（.gitlab-ci.yml+makefile）将构建后的文件打包添加上版本号（1.0.0+）后推送到版本服务器在Jenkins选择对应的版本号发布到指定Web Server上发布时，开发只需要编写“.gitlab-ci.yml”以及makefile对项目进行构建，而运维只需要配置jenkins，将文件发布到Web Server上即可，完成了开发和运维的解耦。 什么是GitLab-CIGitLab CI 是 GitLab Continuous Integration （Gitlab 持续集成）的简称。从 GitLab 的 8.0 版本开始，GitLab 就全面集成了 Gitlab-CI,并且对所有项目默认开启。只要在项目仓库的根目录添加 .gitlab-ci.yml 文件，并且配置了 Runner（运行器），那么每此添加新的tag都会触发 CI pipeline。 一些概念在介绍 GitLab CI 之前，我们先看看一些持续集成相关的概念。 Pipeline一次 Pipeline 其实相当于一次构建任务，里面可以包含多个流程，如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。 任何提交或者 Merge Request 的合并都可以触发 Pipeline，如下图所示： +------------------+ +----------------+| | trigger | || Commit / MR +---------->+ Pipeline || | | |+------------------+ +----------------+StagesStages 表示构建阶段，说白了就是上面提到的流程。 我们可以在一次 Pipeline 中定义多个 Stages，这些 Stages 会有以下特点： 所有 Stages 会按照顺序运行，即当一个 Stage 完成后，下一个 Stage 才会开始只有当所有 Stages 完成后，该构建任务 (Pipeline) 才会成功如果任何一个 Stage 失败，那么后面的 Stages 不会执行，该构建任务 (Pipeline) 失败因此，Stages 和 Pipeline 的关系就是： ...

近期在按照业务划分项目时，我们组被分了好多的项目过来，大量的是基于 Node.js 的，也是我们组持续在使用的语言。现有流程中的一些问题在维护多个项目的时候，会暴露出一些问题： 如何有效的使用 测试用例如何有效的使用 ESLint部署上线还能再快一些吗 使用了 TypeScript 以后带来的额外成本测试用例首先是测试用例，最初我们设计在了 git hooks 里边，在执行 git commit 之前会进行检查，在本地运行测试用例。 这会带来一个时间上的问题，如果是日常开发，这么操作还是没什么问题的，但如果是线上 bug 修复，执行测试用例的时间依据项目大小可能会持续几分钟。 而为了修复 bug，可能会采用 commit 的时候添加 -n 选项来跳过 hooks ，在修复 bug 时这么做无可厚非，但是即使大家在日常开发中都采用commit -n 的方式来跳过繁琐的测试过程，这个也是没有办法管控的，毕竟是在本地做的这个校验，是否遵循这个规则，全靠大家自觉。 所以一段时间后发现，通过这种方式执行测试用例来规避一些风险的作用可能并不是很有效。 ESLint然后就是 ESLint，我们团队基于airbnb的 ESLint 规则自定义了一套更符合团队习惯的规则，我们会在编辑器中引入插件用来帮助高亮一些错误，以及进行一些自动格式化的操作。 同时我们也在 git hooks 中添加了对应的处理，也是在 git commit 的时候进行检查，如果不符合规范则不允许提交。 不过这个与测试用例是相同的问题： 编辑器是否安装 ESLint 插件无从得知，即使安装插件、是否人肉忽略错误提示也无从得知。git hooks 可以被绕过部署上线的方式之前团队的部署上线是使用shipit周边套件进行部署的。 部署环境强依赖本地，因为需要在本地建立仓库的临时目录，并经过多次ssh XXX "command"的方式完成 部署 + 上线 的操作。 shipit提供了一个有效的回滚方案，就是在部署后的路径添加多个历史部署版本的记录，回滚时将当前运行的项目目录指向之前的某个版本即可。_不过有一点儿坑的是，很难去选择我要回滚到那个节点，以及保存历史记录需要占用额外的磁盘空间_ 不过正因为如此，shipit在部署多台服务器时会遇到一些令人不太舒服的地方。 如果是多台新增的服务器，那么可以通过在shipit配置文件中传入多个目标服务器地址来进行批量部署。 但是假设某天需要上线一些小流量（比如四台机器中的一台），因为前边提到的shipit回滚策略，这会导致单台机器与其他三台机器的历史版本时间戳不一致（因为这几台机器不是同一时间上线的） 提到了这个时间戳就另外提一嘴，这个时间戳的生成是基于执行上线操作的那台机器的本地时间，之前有遇到过同事在本地测试代码，将时间调整为了几天前的时间，后时间没有改回正确的时间时进行了一次部署操作，代码出现问题后却发现回滚失败了，原因是该同事部署的版本时间戳太小，shipit 找不到之前的版本（shipit 可以设置保留历史版本的数量，当时最早的一次时间戳也是大于本次出问题的时间戳的） 也就是说，哪怕有一次进行过小流量上线，那么以后就用不了批量上线的功能了 （没有去仔细研究shipit官方文档，不知道会不会有类似--force之类的忽略历史版本的操作） 基于上述的情况，我们的部署上线耗时变为了： （__机器数量__）X（__基于本地网速的仓库克隆、多次 ssh 操作的耗时总和__）。 P.S. 为了保证仓库的有效性，每次执行 shipit 部署，它都会删除之前的副本，重新克隆 ...

本文为[原创]文章，转载请标明出处。原文链接：https://weyunx.com/2019/01/23…原文出自微云的技术博客准备工作下载安装包# Linux x86-64sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64# Linux x86sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-386# Linux armsudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-arm如果是离线安装的话，可以手工联网下载，然后放到内网中，放到/usr/local/bin目录下，并命名为gitlab-runner# 赋予可执行权限sudo chmod +x /usr/local/bin/gitlab-runner# 创建 GitLab CI 用户sudo useradd –comment ‘GitLab Runner’ –create-home gitlab-runner –shell /bin/bash # 安装sudo gitlab-runner install –user=gitlab-runner –working-directory=/home/gitlab-runner# 运行sudo gitlab-runner start注册 Runner首先需要准备URL和Token，可以在 GitLab 项目的 settings->CI/CD->Runners settings 中找到# 注册sudo gitlab-runner register# 输入本地的 gitlab URLPlease enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )https://gitlab.com# 输入 TokenPlease enter the gitlab-ci token for this runnerxxx# 输入 tag, 注意要跟 job 的 tag 一致，后续详细说明Please enter the gitlab-ci tags for this runner (comma separated):my-tag,another-tag# 选择 executor, Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:docker使用 tagsRunner 默认只会在配置了和自身 tags 一致的项目上运行，是为了防止 Runner 运行在大量项目上出现问题。同时可以在 Runner 中取消该设置，允许 Runner 运行在无 tags 的项目上，配置如下Visit your project’s Settings ➔ CI/CDFind the Runner you wish and make sure it’s enabledClick the pencil buttonCheck the Run untagged jobs optionClick Save changes for the changes to take effectExecutor 比较ExecutorSSHShellVirtualBoxParallelsDockerKubernetesClean build environment for every build✗✗✓✓✓✓Migrate runner machine✗✗partialpartial✓✓Zero-configuration support for concurrent builds✗✗ (1)✓✓✓✓Complicated build environments✗✗ (2)✓ (3)✓ (3)✓✓Debugging build problemseasyeasyhardhardmediummediumIt’s possible, but in most cases it is problematic if the build uses services installed on the build machineIt requires to install all dependencies by handFor example using Vagrant具体详细可参考这里GitLab 中配置 Runner在 GitLab 项目中新增.gitlab-ci.yml ，可以选择预先设置好的模版。未完待续… ...