[后端]gitlab之gitlab-ci自动部署
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了[后端]gitlab之gitlab-ci自动部署相关的知识,希望对你有一定的参考价值。
参考技术A gitlab-ci全称是gitlab continuous integration的意思,也就是持续集成。中心思想是当每一次push到gitlab的时候,都会触发一次脚本执行,然后脚本的内容包括了测试,编译,部署等一系列自定义的内容。本文就是利用gitlab-ci的持续集成来实现自动部署。相比之前 webhook的自动部署 还是强大以及方便了许多。自动部署涉及了若干个角色,主要介绍如下
这样就装好了gitlab-ci-multi-runner,然而我们只是装好了gitlab-runner,当然我们要接着向gitlab-CI注册这个runner,不然gitlab-CI在push事件到来的时候怎么知道要调用谁呢?这里也可以发现和webhook方式的区别,webhook方式是我们主动配置了一个连接给gitlab;gitlab-runner只要注册一下就好了。
那么我们就注册一下
然后就注册好了,在gitlab中相应的位置就可以看到你注册好的runner信息。
这里我们只有一个stage是deploy。only指定了只有在master分支push的时候才会被执行。tags是shell,对应了刚才注册runner的时候的tags。
最重要的script部分deploy Example_Group Example_Project,这里是一条shell指令,为了方便通用性,deploy是我在服务器上编写的一个脚本,传入参数是Example_Group Example_Project分别是项目组名和项目名。执行这一条指令就能够自动部署到/xxx/Example_Group/Example_Project的服务器目录下。那么随便什么项目都用这个格式去套就好了,这样新项目的自动部署也不需要登录到服务器上去修改了。
并编辑成如下内容
这个脚本的大意就是,如果目录不存在,那么就git clone一个,如果存在了就git pull一个到指定目录下。这样就达到了自动部署的目的。记得修改里面的gitlab.example.com的地址哦。
加上执行权限,然后把这个脚本放在gitlab-runner的~/.local/bin下就可以生效了(为了不用写难看的./deploy)
并且把 /.local/bin加到$PATH路径中(用户执行命令时候能够查找到这个目录),只要在 /.profile末尾加入这一句话
用cat查看公钥,然后复制这一串公钥。在gitlab中新建一个账号比如叫gitlab-runner,把这个账号添加到你的项目成员中,然后在这个账号的user_profile里面,把公钥粘贴进去就好了。总之就是把这个账号配置成能用ssh登录的。
如果还是不成功,可以在服务器上手工deploy XX XX一次,第一次访问这个服务器的时候,有个命令行提示是要把sign添加进已知服务器列表,需要手工输入个yes。如果在服务器上能够正常deploy,那么
这样就大功告成了。
尝试一下git push到相应项目,然后到服务器上的目录看一下是不是有了呢。
GitLab-CI与GitLab-Runner
GitLab官方材料
如何利用Gitlab-ci持续部署到远程机器?
长话短说,今天聊一聊使用Gitlab-CI 自动部署到远程服务器。
如果看过《》这篇文章的朋友,会注意到我是在 Gitlab-Runner服务器上自动部署的站点,本次我们结合ssh
部署到远程机器(将CI服务器和部署服务器分离,避免资源抢占)。
SSH免密登陆
还是那句话,CI/CD实质是将我们手动集成、拷贝部署的方式脚本化,远程部署的重要姿势是要求免密操控。
要让Gitlab Runner部署到远程机器,远程机器必须信任gitlab runner
账户。
- 先执行
su gitlab-runner
切换到gitlab-runner
账户 - 在你的CI机器(主控端)上使用 ssh-keygen命令创建公钥,使用
ssh-keygen -t rsa
来创建,程序会问你存放目录,如果不需要修改,直接回车几次即可 - 将~/.ssh目录下
id_rsa.pub
文件拷贝到受控机器的~/.ssh
目录中,然后将文件内容导入到~/.ssh/authorized_keys
文件
主控方:
scp /home/gitlab-runner/.ssh/id_rsa.pub
受控方:
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
- 在受控方机器设置权限:
~/.ssh
权限设置为700;
~/.ssh/authorized_keys
权限设置为600
之后在主控CI机器 就具备免密登陆 远程机器的能力。
如何持续部署?
利用镜像tag持续部署: gitlab项目只要打出tag--> 执行构建镜像Job(以此次git tag为镜像tag)-->执行部署Job,拿到git tag-->部署该tag镜像
CI_COMMIT_REF_NAME
变量得到 The branch or tag name for which project is built- 在docker-compose.yml里设置
image: ${DOCKER_REGISTRY}/eap/eap-front-end:${TAG}
,可感知部署时插入的tag变量
build_image:Front-end:
stage: build_image
script:
- docker build -t $DOCKER_REGISTRY_HOST/eap/eap-front-end:$CI_COMMIT_REF_NAME .
- docker login $DOCKER_REGISTRY_HOST -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD
- docker push $DOCKER_REGISTRY_HOST/eap/eap-front-end:$CI_COMMIT_REF_NAME
tags:
- my-tag
only:
- tags
deploy:alpha:
stage: deploy
variables:
deploy_path: "/home/eap/website"
script:
- ssh -t ***@10.202.42.252 "cd $deploy_path && export TAG=$CI_COMMIT_REF_NAME && docker-compose -f docker-compose.yml build && docker-compose -f docker-compose.yml up -d"
tags:
- my-tag
only:
- tags
上面的黄色背景行描述了 ssh远程登陆-->切换到部署目录-->插入本次构建的git tag--->执行容器部署的脚本写法。
That‘all, 本文记录了gitlab-ci持续部署到远程机器的过程: ssh免密登陆是本菜鸡最近搞定的姿势,持续部署的方式简单实用。
两年前,本人也是linux小白,也经历了[想学][放弃][想学][放弃]...的循环。 .NETCore 作为新一代开源跨平台框架,面向云原生而生,容器技术作为云原生的奠基石,.NETer要拥抱容器,拥抱Linux。
以上是关于[后端]gitlab之gitlab-ci自动部署的主要内容,如果未能解决你的问题,请参考以下文章