本文主要是记录在开发 CI/CD 平台 pipeline 中遇到的一些问题和解决方法。 背景原有公司使用的是jenkins来进行CI/CD，虽然是jenkins是界内老牌的CI/CD 平台，但是在使用过程中也遇到一些问题，如消耗资源多、拉取代码会拉取全量、权限管控无法做到精细化、无法做到高可用等问题。也尝试使用过 gitlab-runner ，同样会存在权限管控的问题。基于以上的背景，决定

Course Setup clone代码：https://github.com/microsoft/generative-ai-for-beginners 安装minicoda：https://docs.anaconda.com/miniconda/ Introduction to Generative AI and LLMs LLM如何工作 分词器，文本到数字：大型语言模型接收文本作为输入

相关背景 在Azure上的数据库是单个实例，未来可能会有部分库数据量激增，需要将其迁移到独立的实例中去，同时最小程度影响线上数据和服务运行。 本次可以仅针对同区的数据库实例做迁移。 预期效果 能够最小程度影响线上服务数据操作，将某个库从一个实例迁移到另一个实例中。 最理想的情况是实现线上数据的平滑迁移，用户无感知、数据不丢失。 实现方案DMS 存量增量迁移 + 直接切换 通过使用阿里云/Az

背景近期因为监管原因，国内网络无法拉取dockerhub镜像，而且各大高校和厂商的镜像加速地址也相继下线，导致直接使用dockerhub镜像的服务都无法拉取，所以需要将dockerhub上的镜像都迁移到阿里云容器镜像服务中。 在镜像仓库中我们有的进行是多平台架构的，而使用docker进行直接拉取的话只能指定单个容器架构，这样子的话得想要迁移全部就变得很麻烦。 在同事的推荐下使用了skopeo，效

背景最近在写一个ci/cd的项目，分为server端和runner端，类似于github的actions方式进行构建、打包应用的功能，在进行构建时runner需要不断的将构建日志和状态上报传输给server，那么上报方式的选择有很多选择，最开始我们使用的是grpc的双向流方式，主要是因为server可能会发送终止的请求给runner端，双向流的消息最为及时且效率最高。但是双向流是长连接（有状态）

相关背景 美服出现部分应用接口被外部流量恶意请求，刷取登录接口的情况。 需要针对集群的所有应用进行限流，防止因为恶意请求或者大流量导致服务宕机。 预期效果： 能够实现全局或者应用维度的 IP 限流。 以每分钟300个请求的限流机制为例，向服务发送301个请求，限流器将拒绝第301个请求。同时，限流器会返回一个429 HTTP状态码（Too Many Requests），并在请求到达服务之前进行

背景使用docker进行部署应用时，如果未进行日志配置，当日志量不断增多时会导致磁盘被占满的情况。 当前 jenkins、gitlab、rancher都是使用docker部署在VM上的，因启动时为配置容器日志大小清理策略，导致占用系统盘过多响应缓慢 清理方案手动清理当服务正在线上访问无法重启可以进入到指定容器目录下将该日志文件删除 1echo "" > 57b2980

背景当一个新Pod创建后，Service就能立即选择到它，并会把请求转发给Pod 。但是通常一个Pod启动是需要时间的，部分应用在启动时需要进行加载上游相关服务连接等，如果Pod还没准备好，这时把请求转给Pod的话，Pod也无法处理，会造成请求失败的情况发生。 简介启动探针（Startup Probe）：用于检查容器中的应用是否已经启动。如果启动探针失败，Kubernetes会等待一段时间，然后

背景近期在写一套CI/CD系统，由于部分项目是通过 electron 来实现跨端，需要在同一套代码中在不同平台进打包构建，在Windows下打包的时候总是出现问题，而且错误提示不明显，对于这一领域接触不多的解决起来比较麻烦，在这里记录一下相关的解决方法。 问题缺失 Visual studio 相关库 解决方法 直接下载 visual studio 进行安装，选中 “Desktop develo

背景本文主要是记录在使用 istio 作为 servicemesh 的环境中需要对某些应用进行基准测试。 环境 Kubernetes 1.26 Istio 1.18.2 压测工具 wrk（） 本次压测工具使用 wrk 进行压测 wrk基准测试工具的输出报告，解释如下： Running 30s test @ https://pipeline-dev.ddd.com/healthz：这表示正