资讯专栏INFORMATION COLUMN

上云采购季！| 爆款云服务器低至4.6元/月，首单享0.9折

免费试用
首页/文章专栏/前端自动化部署-.gitlab-ci.yml配置

前端自动化部署-.gitlab-ci.yml配置

社区管理员 / 1120人阅读

一、前言

该过程中用到的技术栈git gitlab shell

需要提前准备的内容

  • 一个项目myweb

  • 本机安装Git

  • 一个Gitlab仓库

  • docker私有仓库

  • gitlab runner(Gitlab-runner)

公司的代码一般都保存在私有化部署的Gitlab，要使用Gitlab的CI/CD，需要Gitlab版本>8.0.0

CI/CD虽然不难，但配置过程中有很多坑，而且有些要了解的概念也比较多，可以分成多个步骤，逐一攻破。

二、入门CI实战

1、安装、注册Gitlab-runner

gitlab-runner需要提前进行安装和注册，详情

进入Gitlab->CICD->Runner 当前可用的runner有

image.png

如图所示，该项目可用的runner

  • 左边runner仅可以为当前项目使用，但需要激活一下。

  • 右边为共享的runner, 可以直接使用

  • .gitlab-ci.yml中以tags和runner的tags关联

2、先把CI跑起来

首先在项目的根目录下新建.gitlab-ci.yml，然后在该文件中配置pipeline的任务，这些任务将会跑在gitlab-runner中。

一个最简单的.gitlab-ci.yml文件，其中CI_COMMIT_BRANCH、GITLAB_USER_LOGIN是一些gitlab定义好的变量，可以直接使用，你也可以定义自己的变量

image: "node" stages:   - BuildImage before_script:   - echo "before_script"   - echo "This job deploys something from the $CI_COMMIT_BRANCH branch."   - echo "Hello, $GITLAB_USER_LOGIN!" build:   tags:     - test   stage: BuildImage   image: "node"   script:     - node -v 复制代码

推送Git仓库

git add .gitlab-ci.yml git commit -m "commit ci" git push 复制代码

进入gitlab-> CI/CD页面，可以看到一个pipeline状态是stuck，这是因为没有Gitlab-runner。

image.png

3、使用Gitlab-runner执行pipeline

修改.gitlab-ci.yml，仅展示部分

build:   # tags,代表要使用的runner,这里改成uaek-c1    tags:     - uaek-c1   stage: BuildImage   image: "node"   script:     - node -v 复制代码

提交代码，进入CI/CD页面看到新增了一条pipeline执行完成

image.png

点击新的记录，可以看到对应的Stage，点击当前任务

image.png

可以看到Gitlab-runner执行.gitlab-ci.yml的具体信息。

image.png

到目前为止，已经看到了.gitlab-ci.yml触发到执行的过程，接下来，看看针对这个项目怎样去具体跑CI

三、项目实战配置

构建Docker镜像参考详情

1、在项目添加Dockerfile文件和Nginx配置文件

(1)、根目录中添加配置文件Dockerfile

FROM node:10-alpine as builder WORKDIR /data/myweb COPY . . RUN npm install --registry=https://registry.npm.taobao.org --no-package-lock --no-save RUN yarn publish:prod FROM nginx:alpine as myweb RUN cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \     && echo "Asia/Shanghai" > /etc/timezone  WORKDIR /data/production COPY ./nginx /etc/nginx/conf.d COPY  --from=builder /data/myweb/build /data/production EXPOSE 80, 443 复制代码

(2)、在项目根目录中新建nginx/default.conf，我们用外挂的nginx配置文件覆盖原来Nginx镜像中的配置文件

server {     listen 80;     listen [::]:80;     server_name localhost;     location / {         root /data/production;         index index.html;         try_files $uri /index.html;     }     error_page 500 502 503 504 /50x.html;     location = /50x.html {      root /usr/share/nginx/html;     } } 复制代码

2、配置文件

# 定义全局变量,镜像名称，命名空间，镜像拉取的密码的变量名 variables:   IMAGE_HUB: "lvpf/myweb"    DOCKER_HUB_URL: "hub.docker.com/r/lvpf/myweb" # 这里打印一些变量，仅仅为了展示，看下这些gitlab预设的变量值，可以去掉 before_script:   - echo "VARIABLE CI_COMMIT_SHA IS $CI_COMMIT_SHA!"   - echo "VARIABLE CI_COMMIT_TAG IS $CI_COMMIT_TAG!"   - echo "VARIABLE CI_PROJECT_DIR IS $CI_PROJECT_DIR!" # stages顺序运行, 同一个stage的所有job并行 stages:   - BuildImage # 任务1，构建docker镜像 docker-image-master:   # 使用的Gitlab Runner标签   tags:     - uaek-c1   # 任务名称   stage: BuildImage   # 由于当前runner为k8s构建的，所以这里执行docker构建和上传需要通过kaniko镜像，具体可以看下面参考文档（）   image: gcr.io/kaniko-project/executor   script:     # 首先我们需要为我们的镜像生成一个tag，规则是：如果有 git tag，就使用 git tag，如果没有的话，就使用 git commit sha     - IMAGE_TAG=$CI_COMMIT_SHA && if [[ -n "$CI_COMMIT_TAG" ]]; then IMAGE_TAG=$CI_COMMIT_TAG; fi     - echo $IMAGE_HUB:$IMAGE_TAG     - mkdir -p /kaniko/.docker     - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json     - /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $DOCKER_HUB_URL:$IMAGE_TAG   # 使用 only 来限制这个 job 什么情况下会运行，下面的设置标识只有新的 tag 被创建时才触发CI，如果去掉，每次推送分支都会触发CI   only:     - tags 复制代码

3、注意事项

  • 一般公司安全性考虑，不会将镜像推送到hub，公司内网一般也不通，要考虑自建私有镜像仓库

  • gitlab-runner可以使用的宿主机类型很多，包括云主机、docker、k8s等，构建镜像的解决方式略有不同，可以参考文档

  • 其中一些涉及密码的变量，可以通过Gitlab->Setting->CI/CD->Variables来设置，直接在.gitlab-ci.yml中使用


作者：前端中后台
链接：https://juejin.cn/post/6967570299336261646
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。


混合云 私有云 前端自动化 web前端自动化测试 自动化部署 自动化配置

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/127954.html

相关文章

  • 基于 GitLab CI 搭建前端自动构建环境

    摘要：什么是持续集成持续集成，简称指的是，频繁地一天多次将代码集成到主干。如图什么是一次其实相当于一次构建任务，里面可以包含多个流程，如安装依赖运行测试编译部署测试服务器部署生产服务器等流程。参考链接用进行持续集成 什么是持续集成 ? 持续集成（Continuous integration，简称CI）指的是，频繁地（一天多次）将代码集成到主干。 GitLab CI 什么是 GitLab CI...

    Warren 评论0 收藏0

  • React Native项目自动化打包发布

    摘要：所以在此给大家分享一下不使用构建工具实现项目自动化打包发布的思路。对于一个前端项目来说，自动化的构建是很有必要的，同时我们也可以通过实现更多的功能比如代码检测，单元测试等等。另外这种思路同样适用于其他项目等前端项目，等移动端项目。 今天这篇文章的目的是在rn项目的构建，并不会涉及到rn框架或者使用的讲解，说起构建，特别是前端构建大家应该很快会想到webpack、Grunt、 Gulp等...

    desdik 评论0 收藏0

  • Gitlab CI/CD执行流程

    一、什么是CI/CDCI 持续集成CD 持续交付CI/CD就是在开发阶段，通过自动化发布，来频繁部署应用的一种方式二、为什么要配置CI/CD想象一下，一个项目的发布如果手动部署，需要的操作有：单元测试打包文件上传服务器等等如果每个过程都需要手动执行，每次都要保证不出错，这个已经很繁琐了。而现在大的前端项目多达10+的人开发，而且人员流动大。如果每个人都这么发布，快速迭代就容易出错。这时候就需要CI...

    社区管理员 评论0 收藏0

  • Node项目的Gitlab自动部署实践（基于Docker）

    摘要：只要的项目有提交，相关就根据来决定是否跑自动部署的命令。项目的自动部署添加执行的注册命令，按照说明进行参数配置。至此，和服务都已经自动部署完成。 准备工作 说明 公司最近准备了一台新的开发服务器，正好用以实践docker的基本应用。docker的好处不再赘述，详情可参考阮一峰的这篇入门。（关于Docker最好的中文介绍，没有之一）。 公司目前主要使用了EggJs + ReactJS的技...

    oysun 评论0 收藏0

  • gitlab-ci坑后感与指北

    摘要：本文的目的最主要是备忘其次是分享疗效并不能让你一下子掌握这只是一个比较完整的解决方案其他基础知识自行补充基调首先这不是屠龙刀不要奢望一篇文章可以走遍天下这里只是提供一个具体的落地方案一个具体的技术选型阶段代码仓库关于代码仓库本文选取的方案是 本文的目的:最主要是备忘, 其次是分享 疗效: 并不能让你一下子掌握CI/CD, 这只是一个比较完整的解决方案,其他基础知识,自行补充. 基调...

    jerry 评论0 收藏0

发表评论

登陆后可评论

0条评论

社区管理员

男|高级讲师
我要私信

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<