php网站模块,潍坊做外贸网站,汽车专业科技网站建设,东莞好的网站国外站建设价格由于图片和格式解析问题#xff0c;为了更好阅读体验可前往 阅读原文 CI/CD 是 持续集成#xff08;Continuous Integration#xff09; 和 持续交付/部署#xff08;Continuous Delivery/Continuous Deployment#xff09; 的缩写#xff0c;是现代软件开发中的一种自动… 由于图片和格式解析问题为了更好阅读体验可前往 阅读原文 CI/CD 是 持续集成Continuous Integration 和 持续交付/部署Continuous Delivery/Continuous Deployment 的缩写是现代软件开发中的一种自动化方法论用于加速代码交付和部署的流程同时保证代码质量和稳定性
大家工作中应该也都接触到了它的方便如提交MR、自动打包、自动部署等等让开发者大大省去了大量的部署时间从而专注于需求的开发纯牛马
那么时间久了你是否对这种方法有过思考如这一系列是如何运作的、自己如何搭建尝试呢对于每位开发者来说都有必要尝试去搭建完整的体系这样自己对软件落地的整体体系会有更明确的认知。本篇文章将手把手带你完成前端项目从开发到部署的整个过程 小贴士 文章中涉及到的代码示例你都可以从 这里查看 若对你有用还望点赞支持本篇不适合0️⃣基础小白需要掌握docker、linux、gitlab、k8s、node等相关知识如果你对这方面的内容还是空白可以参考我的往期文章 项目准备
首先在代码管理仓库创建一个项目用来存放项目代码(这里以Gitlab为例)创建fe-cicd
接着创建工程项目并简单写2个页面这里本人用CLI助手直接用已有的项目模板来作为演示项目读者也可以直接使用执行以下命令很快就会创建好空壳项目模板
# 初始化项目
➜ hengshuai create fe-cicd
HengShuai CLI v0.0.13
? 请选择要创建的模板 create a vue project
? 请选择模板类型 vue3 admin skeleton with nestjs
? 是否需要自动安装依赖❓ NoSuccessfully created project fe-cicd.Get started with the following commands:➜ cd fe-cicd
➜ pnpm install将本地项目推送到代码仓库
git add .
git cm -m 初始化
git remote add gitlab http://192.168.10.10/learn/fe-cicd.git
git push origin dev以上步骤比较简单我们搞完后就可以在仓库里看到项目代码了: 打包测试
对于一个新项目在真正部署前一般我们都会在本地执行打包脚本先验证下是否可以跑的通执行以下命令
pnpm run build
pnpm run start查看运行结果项目正常运行了 CI准备
跑流水线最重要的还是ci的配置脚本通过ci脚本我们可以精确控制流水线如何执行因此配置好ci是关键
注册Runner
在写ci配置前要确保已经准备好了gitlab runner它主要来执行ci的如果你对runner还是很陌生话请先参考我的往期文章这里在项目中已经启用了准备好的runner使用标签是testingrunner的标签名在注册时就可以确定建议使用有意义的命名规则 一个项目可以使用的多个runner在ci中体现就是每个阶段都可以使用不同的runner或者同阶段的并行任务使用不同runner也可以加速流程各位视机器配置自行决定
编写gitlab ci
本次项目使用Gitlab CI 进行来执行流水线工作因此我们在项目根目录下创建新建.gitlab-ci.yml
::: warning 温馨提示 如果你对gitlab ci的配置文件不是很熟悉可以参考我的往期文章并结合官方文档本篇以主要流程为主不做很详细的配置介绍 :::
这里我们将流水线分4个阶段
install安装依赖build项目构建deploy项目部署notice消息通知消息通知又分为成功和失败
根据以上划分可以简单写出下面这些内容
image: node:18-alpinevariables:IMAGE_TAG: $CI_PROJECT_NAME:$CI_COMMIT_REF_NAMEstages:- install_deps- build- deploy- noticeinstall_dependencies:stage: install_depsonly:- devtags:- testingcache:key:files:- pnpm-lock.yamlpaths:- node_modulesartifacts:expire_in: 30 #30spaths:- node_modulesscript:- echo Installing dependencies...- sed -i s/dl-cdn.alpinelinux.org/mirrors.aliyun.com/g /etc/apk/repositories- apk update apk add git apk add openssh-client- npm config set registry https://registry.npmmirror.com/- npm install -g pnpm- pnpm install- echo Dependencies installed successfully!build_project:stage: buildonly:- devtags:- testingartifacts:expire_in: 30paths:- distneeds:- install_dependenciesscript:- echo Building project...- pnpm builddeploy_project:stage: deployonly:- devtags:- testingneeds:- build_projectscript:- echo Deploying project...- echo success# 流水线成功消息
notice_success:stage: noticeonly:- devtags:- testingneeds:- deploy_projectwhen: on_successscript:- echo success# 流水线失败消息
notice_failure:stage: noticeonly:- devtags:- testingneeds:- deploy_projectwhen: on_failurescript:- echo failure以上流水线管道在GitLab上的可视化效果如下 按分支执行
通常项目开发会分为好几个环节如beta、testing、prod等等不同环境的可能会有不同的权限不同环境的runner可能也不一样因此在ci脚本中就可以真不同环境来区分哪些阶段的流程
假设以下的消息通知让它只在dev、testing环境下执行那么就可以通过only关键字来明确指出
notice_success:stage: noticeonly:- dev- testingtags:- testingscript:- echo success自动化测试
团队中一般对于基建项目会很严格出一点错误可能就会影响到成百上千的项目。所以通常都会在发布前做相关的自动化测试保证最基本的测试用例不会受到影响只有这样才能把握住代码的质量而在ci中我们也可以把它集成进来在流水线时通过跑自动化测试根据结果来决定是否可以继续执行下去了
本次通过Vitest来演示单元测试你可以通过其他的工具(如Jest、Cypress)附加测试功能先创建一个简单的测试用例
// __test__/unit/demo.spec.ts
import { describe, expect, it } from vitest;describe(Test Demo, () {it(should pass, () {expect(true).toBe(true);});
});新增测试npm脚本
{scripts: {test:unit: vitest run}
}读者先在本地运行看能否跑通避免在ci中增加未知问题 增加测试脚本后我们需要把它集成到ci中在ci中增加一个testing阶段用来跑测试用例
stages:- testing # 新增测试阶段testing_project:stage: testingtags:- testingneeds:- install_dependenciesscript:- echo Testing project...- pnpm run test:unit以上只是简单的将测试放入了ci管道如果你对测试数据比较感兴趣如代码覆盖率、代码质量等等可以参考Test coverage文档、Code quality文档
打包镜像
以上我们就对流水线的上半部分的工作就基本做完了接下来就是打包应用并发布了这也是很关键的一个步骤本篇只做云原生应用的部署如果你还没有涉及到容器相关的技术这里不做相关的介绍
容器最关键的就是镜像对于应用来说可以通过Dockerfile来创建镜像文件下面是简单的一个例子
FROM node:18.19.0-alpine3.19WORKDIR /app# 直接从ci打包阶段拿到产物
COPY dist dist
COPY node_modules node_modules
COPY ecosystem.config.js ecosystem.config.jsRUN npm install pm2 -g --registryhttps://registry.npmmirror.com/ENTRYPOINT [pm2-runtime, start, ecosystem.config.js, --env, production]你可以能对上面的docker镜像文件有疑问❓可能觉得他太少了最基本的项目打包脚本都没有哪来的构建产物这里我们可以理解为在流水线的流程中在打包阶段将产物保存然后在构建镜像时直接用就行而不需要在docker中再次构建这样就省去了大量的时间更过可以参考gitlab官方文档
当然docker最终跑的脚本是通过pm2来维护的我们还需要编写个pm2的配置文件
// https://pm2.keymetrics.io/docs/usage/quick-start/
module.exports {apps: [{name: fe-cicd,script: dist/server/main.js,watch: false,instance: 2,autorestart: true,max_memory_restart: 1G,env: {NODE_ENV: development,},env_production: {NODE_ENV: production,},},],
}这里使用kaniko来构建镜像
build_image:stage: buildneeds:- build_projectimage:name: gcr.io/kaniko-project/executor:debugentrypoint: []only:- devtags:- testingscript:- echo Deploying project...- for var in ${PROJECT_ENV_VARIABLE// / }; do echo $var .env;done- mkdir -p /kaniko/.docker- echo {\auths\:{\${DOCKER_REPO}\:{\username\:\${DOCKER_REGISTRY_USER}\,\password\:\${DOCKER_REGISTRY_PASSWORD}\}}} /kaniko/.docker/config.json- /kaniko/executor--context ${CI_PROJECT_DIR}--dockerfile ${CI_PROJECT_DIR}/Dockerfile--destination $DOCKER_REPO/$IMAGE_TAGrules:- if: $CI_COMMIT_TAG以上构建镜像后会把它推送到容器的仓库中心细心的读者已经发现我们在我们在build阶段新增了镜像的构建因此以下为整体的流程呈现效果 部署应用
在流水线中docker镜像构建好后就可以把镜像推到镜像仓库了通常公司都会有自己的私有仓库然后通过k8s拉取最新镜像自动部署了这就是部署的基本流程
deploy_to_k8s:stage: deployimage: bitnami/kubectl:latestonly:- devtags:- testingneeds:- build_imagebefore_script:- echo Setting up kubectl- mkdir -p ~/.kube- echo $KUBE_CONFIG ~/.kube/configscript:- echo Updating Kubernetes deployment- kubectl set image deployment/$K8S_DEPLOYMENT_NAME $K8S_CONTAINER_NAME$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA --namespace$K8S_NAMESPACE- kubectl rollout status deployment/$K8S_DEPLOYMENT_NAME --namespace$K8S_NAMESPACE消息通知
等k8s镜像部署阶段完成后代表整个流程就结束了因此我们可以在流水线的尾部在增加一个通知阶段通过发送具体的消息来来告知我们的开发人员当然流水线的执行状态有成功和失败2中状态根据不同的状态来告知
你可以通过HTTP请求将信息发送到消息服务中心消息中心可以集成到公司用到的应用这样就会一触即达
消息通知阶段的流水线以上已经展示过了这里就不再写了稍微补充下用到的基础镜像
notice_success:# 通过curl来发送消息image: curlimages/curl:7.80.0# 以下内容自行发挥执行机制
通常流水线的执行时机都是通过固定的事件触发的如分支合并、分支push等等而对于重要的环境往往需要手动来降低风险或者说可以更好的决定执行时机对于一个复杂应用的发布可能会涉及到很多基础服务的发布那么对于自动化发布来说会很麻烦这里简单提一下如何修改执行时机
deploy-job:stage: deployscript:- echo Deploying the applicationwhen: manual # 配置为手动触发在往期的文章中都有关于执行时机的介绍这里只是提醒下如何更好的实践 心跳检测
大多数的应用都会面对很多问题如负载、故障等等而稳定的应用都会有很多监控措施对于镜像如何检测它是否正常运行呢最简单的就是通过写一个检测接口通过一定的频率来调用根据响应来判断是否正常这样在镜像拉胯时可以重新部署
下面我们用NodeJS简单写了一个接口/common/health-check
Controller(/common)
export class CommonController {// 心跳检测Get(/health-check)healthCheck() {return ok;}
}接着在k8s pod配置文件中添加心跳检测
apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: liveness-http
spec:containers:- name: livenessimage: registry.k8s.io/e2e-test-images/agnhost:2.40args:- livenesslivenessProbe:httpGet:path: /common/health-checkport: 8080initialDelaySeconds: 3periodSeconds: 3更多玩法请参考探针检测
其他
纯静态前端项目大部分会配合nginx使用这里不做演示
线上的应用运行效果如何(内存、负载、响应等等)通常都会在相关的监控后台查看可以参考k8s可视化资源监控也可以根据api自行设计监控后台 由于图片和格式解析问题为了更好阅读体验可前往 阅读原文
