背景 Stable Diffusion 在训练数据集之前，需要先对数据进行预处理。 本篇文章就是介绍如何对图像进行批量预处理。 图片上传 上传图像到你指定目录，我的目录时/mnt/smb/ 打开SD-web地址，进入192.168.1.232:7861，选择附加功能，进行图像预处理 批量抠图 选择从目录进行批量处理 填写输入目录和输出目录 举例： 原本我的共享文件夹 地址是\\192.168.1.249\DB Training\ai-pre-photo\out-photo 将所有的 \\192.168.1.249\DB Training\ 改为 /mnt/smb/ 所有的 \ 改为 / 因此 需填写地址如下图： 选择抠图模型 滑倒最底部选择背景去除算法,选择你要使用的算法，我这边选择silueta算法,可以根据你自己的需求使用算法 执行生成 点击生成按钮，开始对图像批量处理 查看生成的图像 在对应的共享文件夹也可以查看

背景 ComfyUI 是用于稳定扩散的基于节点的用户界面。ComfyUI 由 Comfyanonymous 于 2023 年 1 月创建，他创建了该工具来学习稳定扩散的工作原理。 效果 webui和ComfyUI之间的区别,相比较webUI，ComfyUI更工业化，更符合高级使用者的配置 安装 安装本体 下载软件 1mkdir ~/sd-web 2cd ~/sd-web 3git clone https://github.jobcher.com/gh/https://github.com/comfyanonymous/ComfyUI.git 环境依赖 1cd ~/sd-web/ComfyUI 2conda create -n ComfyUI python=3.10 3pip install -r requirements.txt -i https://pypi.douban.com/simple --trusted-host=pypi.douban.com 下载sd_xl_turbo模型 1aria2c --console-log-level=error -c -x 16 -s 16 -k 1M https://huggingface.jobcher.com/https://huggingface.co/stabilityai/sdxl-turbo/resolve/main/sd_xl_turbo_1.0_fp16.safetensors -d ~/sd-web/ComfyUI/models/checkpoints -o sd_xl_turbo_1.0_fp16.safetensors 启动服务 1cd ~/sd-web/ComfyUI 2python main.py --listen --port 6006 --cuda-device 1 webUI共享模型 1cd 2mv extra_model_paths.yaml..example extra_model_paths.yaml 编辑参数 1vim extra_model_paths.yaml 修改 base_path: path/to/stable-diffusion-webui/ 改为你的webui实际地址，例如： base_path: ~/sd-web/stable-diffusion-webui/ 1#config for a1111 ui 2#all you have to do is change the base_path to where yours is installed 3a111: 4 base_path: path/to/stable-diffusion-webui/ ## 这里改为你实际的webui地址 5 6 checkpoints: models/Stable-diffusion 7 configs: models/Stable-diffusion 8 vae: models/VAE 9 loras: | 10 models/Lora 11 models/LyCORIS 12 upscale_models: | 13 models/ESRGAN 14 models/RealESRGAN 15 models/SwinIR 16 embeddings: embeddings 17 hypernetworks: models/hypernetworks 18 controlnet: models/ControlNet 重启服务

背景 Stable Diffusion (稳定扩散) 是一个扩散模型，2022年8月由德国CompVis协同Stability AI和Runway发表论文，并推出相关程序。 AUTOMATIC1111开发了图形化界面：「Stable Diffusion WebUI」，这是能用AI技术生成图片的开源软件，只要给定一组描述文本，AI就会开始绘图(准确的说是「算图」或「生图」)；亦能模仿现有的图片，生成另一张图片。甚至给它一部分涂黑的图片，AI也能按照你的意愿将图片填上适当的内容。除此之外还支持自行训练模型加强生图效果。 本篇文章就是介绍如何安装 stable-diffusion-webui 安装conda 在 Ubuntu 上安装 Anaconda 的步骤如下： 首先，你需要下载 Anaconda 的安装包。你可以从 Anaconda 的官方网站上下载最新版本的 Anaconda for Linux。选择适合你的系统的版本（Python 3.x）。 访问下载链接：https://www.anaconda.com/products/distribution#download-section 下载完成后，你可以在终端中导航到下载的文件所在的目录。你可以使用 cd 命令来改变目录。例如，如果你的下载文件在 Downloads 文件夹中，你可以输入以下命令： 1cd ~/Downloads 然后，你需要运行 bash 命令来安装 Anaconda。假设你下载的 Anaconda 文件名为 “Anaconda3-2020.02-Linux-x86_64.sh”，你可以输入以下命令： 1bash Anaconda3-2020.02-Linux-x86_64.sh 请注意，你需要将上述命令中的 “Anaconda3-2020.02-Linux-x86_64.sh” 替换为你实际下载的文件名。 4. 接下来，你会看到 Anaconda 的许可协议。按 Enter 键滚动到底部，然后输入 ‘yes’ 来接受许可协议。 5. 然后，你需要确认 Anaconda 的安装位置。你可以选择默认位置或输入新的位置。 6. 安装完成后，你会看到一个提示，询问你是否希望 Anaconda3 添加到你的 PATH。你应该输入 ‘yes’。 7. 最后，你需要激活安装。你可以通过关闭并重新打开终端或运行以下命令来完成此操作： 1source ~/.bashrc 验证安装。在终端中输入以下命令： 1conda list 如果安装成功，这个命令会显示一个已安装的包的列表。

单元测试的价值 单元测试是一种白盒测试技术，通常由开发人员在编码阶段完成，目的是验证软件代码中的每个单元（方法或类等）是否符合预期，即尽早在尽量小的范围内暴露问题。 我们都知道，问题发现得越早，修复的代价越小。毫无疑问，在开发阶段进行正确的单元测试可以极大地节省时间和金钱。如果跳过单元测试，会导致在后续更高级别的测试阶段产生更高的缺陷修复成本。 如图，假如有一个只包含两个单元 A 和 B 的程序，且只执行端到端测试，如果在测试过程中发现了缺陷，则可能有如下多种原因： 该缺陷由单元 A 中的缺陷引起； 该缺陷由单元 B 中的缺陷引起； 该缺陷由单元 A 和单元 B 中的缺陷共同引起； 该缺陷由单元 A 和单元 B 之间接口的缺陷引起； 该缺陷是测试方法或测试用例的错误导致的。 由此可见，忽略单元测试会导致后续发现缺陷时，要花费较高的成本来确认缺陷原因。 单元测试除了能够在较早阶段识别软件中的错误，它还有如下价值。 反馈速度快：单元测试通常以自动化形式运行，执行速度非常快，可以快速反馈结果，跟持续集成结合起来，形成有效的反馈环。 重构的有力保障：系统需要大规模重构时，单测可以确保对已有逻辑的兼容，如果单元测试都通过，基本上可以保证重构没有破坏原来代码逻辑的正确性。 使更熟悉代码：写单元测试的过程本身就是一个审视代码的过程，可以发现一些设计上的问题（代码设计的不可测试）、代码编写方面的问题（边界条件的处理不当）等。 既然单元测试由开发人员来设计和执行，那作为测试人员是不是就不需要学习这门技术了？不知道你是怎样看待这个想法的，我的观点是： 单元测试只是通常情况下由开发人员完成，并不是绝对的，在一些公司或项目里也存在测试人员完成的情况； 在你负责的模块或服务里，第一级别的测试不是你来完成的，那么你更有必要去了解它的设计思路和执行情况，这能帮助你发现单元测试可能存在的问题点，也有利于你设计和执行后续高级别的测试类型； 开发人员总是不太擅长做测试类的工作，当你掌握了单元测试的技能，你便更有机会去帮助和影响到开发人员，赢得他对你的尊重，也有利于你们更好地合作； 这种想法是测试人员的常见想法，所以掌握单元测试技能在测试人员群体中也会是稀缺技能，因此，掌握它将会获得额外的锻炼机会和个人影响力，要知道，机会总是留给有准备的人。 微服务下的单元测试类型 就像之前课程所说：微服务中最大的复杂性不在于服务本身，而在于微服务之间的交互方式，服务与服务之间常常互相调用以实现更多更复杂的功能。 举个例子，我们需要测试的是订单类（Order）中的获取总价方法（getTotalPrice()），而在该方法中除了自有的一些代码逻辑外，通常需要去调用其他类的方法。比如这里调用的是用户类（User）的优惠等级方法（reductionLevel ()）和商品类（Goods）中的商品价格方法（getUnitPrice()）。很显然，优惠等级方法或商品价格方法，只要一方有错误，就会导致订单类获取总价方法的测试失败。基于这种情况，可以有两种单元测试类型。 1. 社交型单元测试（Sociable Unit Testing） 如图，测试订单类的获取总价方法（Order.getTotalPrice()）时会真实调用用户类的优惠等级方法（User.reductionLevel()）和商品类的商品单价方法（Goods.getUnitPrice()）。将被测试单元视为黑盒子，直接对其进行测试，这种单元测试称之为社交型单元测试（Sociable Unit Testing）。 2. 孤立型单元测试（Solitary Unit Testing） 如图，如果测试订单类的获取总价方法（Order.getTotalPrice()）时，使用测试替身 （test doubles） 技术来替代用户类的优惠等级方法（User.reductionLevel()）和商品类的商品单价方法（Goods.getUnitPrice()）的效果。对象及其依赖项之间的交互和协作被测试替身代替，这种单元测试称之为孤立型单元测试（Solitary Unit Testing）。 另外，上述提到的测试替身是一种在测试中使用对象代替实际对象的技术，常用的技术如下。 桩代码（Stubs）：当在对象上调用特定方法时，会对其进行硬编码（临时代码）的方式来代替真实代码提供固定响应。比如，某函数 X 的实现中调用了一个函数 Y，而 Y 不能调用，为了对函数 X 进行测试，就需要模拟一个函数 Y，那么函数 Y 的实现就是所谓的桩代码。 模拟代码（Mocks）：模拟代码跟桩代码类似，它除了代替真实代码的能力之外，更强调是否使用了特定的参数调用了特定方法，因此，这种对象成为我们测试结果的基础。 根据被测单元是否与其交互者隔离，会产生以上两种单元测试类型，这两种类型的单元测试在微服务测试中都起着重要作用，它们用来解决不同的测试问题。

可以从两个方面来保障微服务的质量： 选取合适的测试策略模型，确保测试活动全面且有效； 建立质量保障体系，使质量保障内化为企业的组织能力。 如何选择合适的测试策略模型？ 要想使面向微服务的测试活动全面且有效，可以借用“测试金字塔”的思想，针对不同类型和颗粒度的测试投入不同的精力，达到一个最佳平衡： 测试需要分层，每一层的测试颗粒度有所不同； 不同层次的测试比重有差异，通常来说，层次越高，测试比重应越少。 需要说明的是，传统意义下的测试金字塔，在微服务架构下不再完全奏效。因为微服务中最大的复杂性不在于服务本身，而在于微服务之间的交互方式，这一点值得特别注意。 因此，针对微服务架构，常见的测试策略模型有如下几种。 （1） 微服务“测试金字塔” 基于微服务架构的特点和测试金字塔的原理，Toby Clemson 有一篇关于“微服务架构下的测试策略”的文章，其中通过分析阐述了微服务架构下的通用测试策略。 如图，该策略模型依然是金字塔形状，从下到上依次为单元测试、集成测试、组件测试、端到端测试、探索式测试。 （2） 微服务“测试蜂巢” 这种策略模型是蜂巢形状，它强调重点关注服务间的集成测试，而单元测试和端到端测试的占比较少。 （3） 微服务“测试钻石” 这种策略模型是钻石形状的，组件测试和契约测试是重点，单元测试比率减少，另外增加了安全和性能等非功能的测试类型。 我想，有多少个基于微服务架构的测试团队大概就有多少个测试策略模型吧。“测试金字塔”是一种测试策略模型和抽象框架，当技术架构、系统特点、质量痛点、团队阶段不同时，每种测试的比例也不尽相同，而且最关键的，并不一定必须是金字塔结构。 理解了测试策略模型的思考框架，我们看下应如何保障测试活动的全面性和有效性。 全面性 微服务架构下，既需要保障各服务内部每个模块的完整性，又需要关注模块间、服务间的交互。只有这样才能提升测试覆盖率和全面性，因此，可以通过如下的分层测试来保证微服务的全面性。 单元测试（Unit Test） ：从服务中最小可测试单元视角验证代码行为符合预期，以便测试出方法、类级别的缺陷。 集成测试（Integration Test）：验证当前服务与外部模块之间的通信方式或者交互符合预期，以便测试出接口缺陷。 组件测试 （Component Test）：将测试范围限制在被测系统的一部分（一般是单个服务），使用测试替身（test doubles）将其与其他组件隔离，以便测试出被测代码的缺陷。 契约测试（Contracts Test）：验证当前服务与外部服务之间的交互，以表明它符合消费者服务所期望的契约。 端到端测试（End-to-end Test）：从用户视角验证整个系统的功能能否符合用户的预期。 可见，上述测试策略模型中的测试方法，是自下而上逐层扩大测试范围和边界，力保微服务架构的模块内、模块间交互、服务内、服务间交互、系统范围等维度的功能符合预期。 有效性 确定了分层测试方法，我们应该如何选取每种测试方法的比例，来确保该测试策略的有效性呢？ 首先必须要明确的是不存在普适性的测试组合比例。我们都知道，测试的目的是解决企业的质量痛点、交付高质量的软件。因此不能为了测试而测试，更不能为了质量而不惜一切代价，需要考虑资源的投入产出比。 测试策略如同测试技术、技术架构一样，并不是一成不变，它会随着业务或项目所处的阶段，以及基于此的其他影响因素的变化而不断演进。但归根结底，还是要从质量保障的目标出发，制定出适合当时的测试策略，并阶段性地对策略进行评估和度量，进而不断改进和优化测试策略。因此，选取测试策略一定要基于现实情况的痛点出发，结果导向，通过调整测试策略来解决痛点。 比如，在项目早期阶段或某 MVP 项目中，业务的诉求是尽快发布到线上，对功能的质量要求不太高，但对发布的时间节点要求非常严格。那这种情况下快速地用端到端这种能模拟用户真实价值的测试方法保障项目质量也未尝不可；随着项目逐渐趋于平稳后，时间要求渐渐有了节奏，对功能的质量要求会逐渐变高，那么这时候可以再根据实际情况引入其他测试方法，如契约测试或组件测试等。 你要永远记住，适合自身项目阶段和团队的测试策略才是“完美”的策略。 如何建立质量保障体系？ 上述分层的测试策略只是尽可能地对微服务进行全面的测试，确保系统的所有层次都被覆盖到，它更多体现在测试活动本身的全面性和有效性方面。要想将质量保障内化为企业的组织能力，就需要通过技术和管理手段形成系统化、标准化和规范化的机制，这就需要建设质量保障体系。 质量保障体系：通过一定的流程规范、测试技术和方法，借助于持续集成/持续交付等技术把质量保障活动有效组合，进而形成系统化、标准化和规范化的保障体系。 同时，还需要相应的度量、运营手段以及组织能力的保障。 如下几个方面是质量保障体系的关键，后续课程也将按如下方式展开讲解。 流程规范：没有规矩不成方圆，好的流程规范是保障质量中非常关键的一环。当出现交付质量差的情况时，过程质量也一定是差的。通常会出现某些关键动作未执行或执行不到位、对事情的不当处理等情况，而这些情况可以通过建立闭环、分工明确的流程规范完全可以避免。另外，研发过程中，过程质量跟执行人的质量意识、个人能力等直接相关，那么就需要建立易执行的流程规范，降低人员的执行门槛。同时需要特别注意，规范的不断完善是几乎所有团队的常态，但当规范执行效果不好时一定要及时跟进，分析其根本原因，必要时要进行简化。 测试技术： 测试策略模型中的分层测试方法可以使面向微服务的测试活动具有一定的全面性和有效性，使得被测内容在功能方面符合预期。除功能性之外，软件质量还有其他很多属性，如可靠性、易用性、可维护性、可移植性等，而这些质量属性就需要通过各种专项测试技术来保障了。同时，还有许多测试技术的首要价值在于提升测试效率。因此合理地组合这些测试技术，形成测试技术矩阵，有利于最大化发挥它们的价值。 持续集成与持续交付：微服务的优势需要通过持续集成和持续交付的支持才能充分发挥出来，这就要求在执行测试活动时提高反馈效率、尽快发现问题。一方面要明确各种“类生产环境”在交付流程中的位置和用途差异点，保证它们的稳定可用。另一方面需要将各种测试技术和自动化技术集成起来，使代码提交后能够自动进行构建、部署和测试等操作，形成工具链，实现真正意义上的持续集成和持续交付。 度量与运营：管理学大师德鲁克曾经说过“你如果无法度量它，就无法管理它（It you can’t measure it, you can’t manage it)”。要想能有效管理和改进，就难以绕开度量这个话题。对于研发过程来说，度量无疑是比较难的，它是一个脑力密集型的过程，指标多维度，且很多维度的内容难以清晰地度量。在质量保障体系中，我将基于质量、效率、价值等多维度视角建立起基础的度量体系，并结合定期运营做定向改进，形成 PDCA 正向循环，促使各项指标稳步提升。同时，需要特别警惕的是，度量是一把双刃剑，这里我也会告诉一些我的经验教训和踩过的坑，避免走错方向。 组织保障：产品的交付离不开组织中每个参与部门成员的努力。正如质量大师戴明所说，质量是设计出来的，不是测试出来的。因此在组织中树立起“质量文化”至关重要。在这部分内容里，我将介绍常见的参与方的角色、职责和协作过程中的常见问题、对策，以及如何营造质量文化等内容。 总结 谈到了基于微服务架构下的各种质量挑战，可以从两个方面有效且高效地保障微服务的质量：确保面向微服务的测试活动具备全面性和有效性，质量保障需要内化为企业的组织能力。

端到端测试详解 定义 端到端测试（End-to-end Test）是一种用于测试整个应用程序的流程是否符合预期的测试技术。 它模拟用户真实的使用场景，通过用户界面测试应用程序，如图所示： 与其他类型的测试相反，端到端测试是面向业务的，其目的是验证应用程序系统整体上是否符合业务目标。为了实现这一目标，该系统通常被视为黑盒子：尽可能完整地部署系统中的微服务，并主要通过 GUI 和 API 等公共接口对其进行操作。 GUI：Graphical User Interface，又称图形用户界面或图形用户接口。它是采用图形方式显示的计算机操作用户界面，是一种人与计算机通信的界面显示格式，允许用户使用鼠标等输入设备操纵屏幕上的图标或菜单选项，以选择命令、调用文件、启动程序或执行其他一些日常任务。 API：Application Programming Interface，又称呼应用程序编程接口或应用程序接口。它是一组定义、程序及协议的集合，通过 API接口实现计算机软件之间的相互通信。API 的一个主要功能是提供通用功能集，同时也是一种中间件，为各种不同平台提供数据共享。 由于微服务架构包含多个具有相同行为的活动部件，因此端到端测试为服务之间传递消息的正确性提供了更多的信心，而且还可以确保正确配置了其他网络基础结构，例如防火墙、代理或负载均衡等。 测试范围 通过微服务的分层测试策略可知，端到端测试的范围比其他类型的测试大得多。 分层测试策略-测试范围 绝大多数情况下，微服务应用系统会依赖一个或多个由外部管理的微服务。通常，这些外部服务包含在端到端测试范围内。 但是，在极少数情况下，也可以主动排除它们。因为如果外部服务由第三方管理，可能会经常出现稳定性和可靠性问题，这会导致端到端测试因不可控的原因而失败。 微服务应用的典型示例 比如，某个应用程序系统依赖公安部门的背景审查服务，通过调用该服务来查询用户是否有过违法前科。首先这样的服务通常会按调用次数付费（每次 5-10 元），具有较高的测试成本，其次背景审查服务不总是稳定可用的。在这种情况下，通过服务虚拟化技术模拟背景审查服务是个不错的选择，这虽然多少会降低端到端测试的信心，但增加了测试用例套件的稳定性。 测试入口 因为端到端测试是面向业务的，那么测试时要从真实用户的使用场景来进行测试，根据应用程序系统是否有 GUI，可以分为两种情况： 应用程序系统有 GUI，这种情况下用户可以直接操作 GUI 来使用系统，那么诸如 Selenium WebDriver 之类的工具可以帮助驱动 GUI 触发系统内的特定行为。 应用程序系统没有 GUI，这种情况下，使用 HTTP 客户端通过其公共的 API 直接操作微服务。没有真实的 GUI，不能直观地看到业务功能行为，但可以通过后台数据来确定系统的正确性，比如 API 的返回结果、持久化数据的变化情况，等等。 测试设计 确定测试范围和测试入口后，可以进一步梳理出要测试的功能列表或用例集，并对其按业务能力、优先级、重要性等维度进行分组。这样可以将它们拆分为较小的任务，以便整个团队可以排序处理，比如可以首先实施优先级较高的用例组，或按紧急程度处理关键的用例，这有助于我们尽早消除潜在的障碍。 另外，由于端到端测试的目标是完全集成后的系统的行为，使得编写和维护测试用例会比其他类型的测试更加困难： 端到端测试涉及的活动部件比其他测试多得多； 端到端测试须考虑系统中的异步处理。 这些因素都可能给端到端测试带来挑战，比如测试过程不稳定、测试时间过长、测试用例集的维护成本高，等等。因此，应尽可能以最粗粒度进行端到端的测试设计。 如何开展端到端测试？ 熟悉了端到端测试的基本内容，我们来看下如何开展端到端测试，主要有如下几类： UI 自动化 对于带有 GUI 的应用程序系统，在进行端到端测试时，可以通过 UI 自动化的方式进行。如果 GUI 是 Web 形式，则 Selenium 是首选工具；如果 GUI 是 Native 形式，则可以使用 Appium。

containerd 现在很多人说起容器都会说到docker，docker凭借镜像（images）快捷的部署，占领了极大的技术市场，docker公司将自己的核心依赖 Contanerd 捐给了 CNCF，这个就是contanerd的由来，containerd 在kubernetes在 v1.24之后的版本作为底层核心进行使用。 Containerd架构 可以看到 Containerd 仍然采用标准的 C/S 架构，服务端通过 GRPC 协议提供稳定的 API，客户端通过调用服务端的 API 进行高级的操作。 为了解耦，Containerd 将不同的职责划分给不同的组件，每个组件就相当于一个子系统（subsystem）。连接不同子系统的组件被称为模块。 总体上 Containerd 被划分为两个子系统： Bundle : 在 Containerd 中，Bundle 包含了配置、元数据和根文件系统数据，你可以理解为容器的文件系统。而 Bundle 子系统允许用户从镜像中提取和打包 Bundles。 Runtime : Runtime 子系统用来执行 Bundles，比如创建容器。 其中，每一个子系统的行为都由一个或多个模块协作完成（架构图中的 Core 部分）。每一种类型的模块都以插件的形式集成到 Containerd 中，而且插件之间是相互依赖的。例如，上图中的每一个长虚线的方框都表示一种类型的插件，包括 Service Plugin、Metadata Plugin、GC Plugin、Runtime Plugin 等，其中 Service Plugin 又会依赖 Metadata Plugin、GC Plugin 和 Runtime Plugin。每一个小方框都表示一个细分的插件，例如 Metadata Plugin 依赖 Containers Plugin、Content Plugin 等。 总之，万物皆插件，插件就是模块，模块就是插件。 常用插件 Content Plugin : 提供对镜像中可寻址内容的访问，所有不可变的内容都被存储在这里。 Snapshot Plugin : 用来管理容器镜像的文件系统快照。镜像中的每一个 layer 都会被解压成文件系统快照，类似于 Docker 中的 graphdriver。 Metrics : 暴露各个组件的监控指标。 安装 卸载docker 首先要保证环境干净整洁，如果你有安装docker服务，需要先卸载docker，如果没有安装可以跳过

背景 什么是 CI/CD 可观察性，我们如何为更多可观察的管道铺平道路？可观察性不仅仅是观察错误或监控基本健康信号。相反，它会更深入，以便您可以了解系统内行为背后的“原因”。 CI/CD 可观察性在其中发挥着关键作用。这是关于深入了解持续集成和部署系统的整个管道——查看每个代码签入、每个测试、每个构建和每个部署。当您组合所有这些数据时，您可以全面了解整个软件交付过程，揭示效率领域、瓶颈和潜在故障点。 CI/CD 可观察性是可观察性的一个子集，专注于软件开发生命周期。它有助于以多种方式确保流程可靠、相关且易于理解： 积极主动解决问题。没有可观察性，我们只能对问题做出反应。有了它，我们可以在问题升级之前预见并解决问题，从而节省时间和资源。 更好的决策。通过了解 CI/CD 流程的细节，团队可以在资源分配、流程变更和工具采用方面做出更明智的决策。 建立信心。通过对 CI/CD 管道的清晰洞察，开发人员、测试人员和运营团队可以对他们发布的软件更有信心。它减少了“对部署的恐惧”并培育了持续改进的文化。 问责制和透明度。可观察性确保 CI/CD 流程的每一步都是可追溯的。这意味着，如果出现问题，可以追溯到其源头，促进问责并帮助解决根本原因，而不仅仅是解决症状。 问题 CI/CD 系统并非没有自身的挑战。破坏 CI/CD 管道平稳运行的常见问题是不稳定、性能下降和配置错误。 Flakiness 片状 片状测试是 CI/CD 方程中不可预测的变量。当测试在代码没有任何更改的情况下产生不同的结果（通过或失败）时，该测试被认为是“不稳定的”。出现片状现象通常有以下几个原因： 外部依赖和环境问题。如果这些依赖项不能始终可用，则依赖于外部服务、数据库或特定环境设置的测试可能会产生不可预测的结果。如果环境设置不正确或意外拆除，也可能会发生这种情况。从本质上讲，先前测试的残留或外部服务的不可用可能会扭曲结果，使其不可靠。 比赛条件。当系统的行为依赖于不可控事件的顺序或时间时，就会出现这种情况。特别是在异步操作中，如果管理不当，事件序列的不可预测性可能会导致偶发故障。 Performance regression 性能回归 随着 CI/CD 流程的发展并变得更加复杂，系统性能可能会开始下降。这种回归可能不会立即显现出来，但长期的累积效应可能会阻碍 CI/CD 管道的效率。以下是常见的原因： 测试执行效率低下。某些测试可能会运行比必要的时间更长的时间，这可能是因为冗余操作、设置的等待时间太长或查询效率低下。这在集成和端到端测试中尤其明显。 代码和测试膨胀。当我们添加更多功能和测试而不解决技术债务或进行优化时，我们的构建时间可能会增加。有些测试从添加之日起可能会很慢。如果不解决这些问题，整个构建和测试过程可能会比需要的时间更长。 Misconfigurations 配置错误 即使是最深思熟虑的管道也可能因配置错误而失败。这可能导致： 次优测试计划。 CI/CD 管道遵循一条关键路径，其中每个步骤都依赖于前一个步骤。如果步骤未设置为按正确的顺序执行或正在等待非依赖项，则可能会导致效率低下。 次优容量规划。未配置足够的资源或对所需工作负载规划不当可能会导致管道出现瓶颈。如果 CI/CD 流程在关键阶段没有必要的能力，则可能会减慢整个工作流程或导致中断和故障。 DORA 指标 Deployment frequency 部署频率 (DF)：组织成功发布到生产环境的频率 Mean Lead time for changes 变更平均前置时间 (MLT)：从代码提交到代码在生产中运行所需的时间 Mean time to recover 平均恢复时间 (MTTR)：发生服务事件或缺陷后恢复服务需要多长时间 Change failure rate 变更失败率 (CFR)：导致失败的变更百分比 优化 CI/CD 可观察性 目前GraCIe 是 Grafana 正在使用的应用程序插件，旨在为用户提供一种简单的方法来了解他们的 CI/CD 系统。它非常适合评估构建性能、识别测试结果中的不一致以及分析构建输出。该应用程序简化了这些流程，旨在轻松提供有关管道的见解。

Argo cd 安装和部署 Argo CD 是一个为 Kubernetes 而生的，遵循声明式 GitOps 理念的持续部署（CD）工具。Argo CD 可在 Git 存储库更改时自动同步和部署应用程序 安装 前提：你已经安装好了 k8s 环境，我们将在国内的k8s环境下部署argocd 1k3s kubectl create namespace argocd 2kubectl apply -n argocd -f https://github.jobcher.com/gh/https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml 检查是否正常部署 1kubectl get po -n argocd 如果没有错误的情况下应该是全部都runnning，但是如果出现argocd-repo-server CrashLoopBackOff错误有以下解决途径： 使用以下补丁修补了部署。删除后，错误消失，repo 服务器可以启动。 1apiVersion: apps/v1 2kind: Deployment 3metadata: 4 name: argocd-repo-server 5spec: 6 template: 7 spec: 8 securityContext: 9 seccompProfile: 10 type: RuntimeDefault 如果出现argocd-dex-server imagepullbackoff错误有以下解决方法： 1docker pull ghcr.io/dexidp/dex:v2.37.0 2docker tag ghcr.io/dexidp/dex:v2.37.0 harbor/dexidp/dex:v2.37.0 3docker push harbor/dexidp/adex:v2.

背景 我的logstash是多管道部署结果发现有大量日志丢失的情况查看logstash日志出现了以下报错 [2023-11-07T09:43:38,492][ERROR][logstash.javapipeline ][log] Pipeline worker error, the pipeline will be stopped {:pipeline_id=>“log”, :error=>"/var/lib/logstash/queue/log/checkpoint.head.tmp (Too many open files)", :exception=>Java::JavaIo::FileNotFoundException, :backtrace=>[“java.base/java.io.FileOutputStream.open0(Native Method)”, “java.base/java.io.FileOutputStream.open(FileOutputStream.java:298)”, “java.base/java.io.FileOutputStream.(FileOutputStream.java:237)”, “java.base/java.io.FileOutputStream.(FileOutputStream.java:187)”, “org.logstash.ackedqueue.io.FileCheckpointIO.write(FileCheckpointIO.java:105)”, “org.logstash.ackedqueue.Page.headPageCheckpoint(Page.java:202)”, 这个问题是 Logstash Pipeline 在处理数据时报错,原因是打开文件过多导致"Too many open files" 解决方法 1. 检查操作系统的文件打开数量限制,使用ulimit -n查看。如果太低,可以提高这个限制 打开 /etc/profile 增加ulimit 值 1vim /etc/profile 2## 增加，保存并退出 3ulimit -n 10240 4# 重载配置 5source /etc/profile 2. 适当增大Logstash的heap size,如-Xms和-Xmx设置为2g。 1vim /etc/logstash/jvm.option 2# 修改参数 3-Xms 2g 4-Xmx 2g 5# 重启logstash服务

使用 ElasticSearch Curator 7天定期删除日志 背景 Curator 是 Elastic 官方发布的一个管理 Elasticsearch 索引的工具，可以完成许多索引生命周期的管理工作。 我使用的 elasticseraech 8.0 以上的版本，所有我直接安装最新版的curator,服务器是centos 7 的 二进制安装 下载 1wget https://packages.elastic.co/curator/5/centos/7/Packages/elasticsearch-curator-5.8.4-1.x86_64.rpm 安装 curator 1rpm -ivh elasticsearch-curator-5.8.4-1.x86_64.rpm 2curator --version 进入安装文件，创建文件 1cd /opt/elasticsearch-curator 2mkdir log 3cd log 4touch run.log 创建config.yml文件在log目录下 config.yml样例如下： 配置说明参考官网说明：config.yml 1# Rmember, leave a key empty if there is no value. None will be a string, 2# not a Python "NoneType" 3client: 4 hosts: 5 - 192.168.10.17 # elasticsearch IP 地址 6 port: 9200 7 url_prefix: 8 use_ssl: False 9 certificate: 10 client_cert: 11 client_key: 12 ssl_no_validate: False 13 http_auth: elastic:password # elastic 密码，没有就不用写 14 timeout: 30 15 master_only: False 16 17logging: 18 loglevel: INFO 19 logfile: /opt/elasticsearch-curator/log/run.

背景 我是在ubuntu服务器安装docker服务，我已经安装好了docker和docker-compose服务，这里我就不写这些服务的安装过程，直接开始安装sonarqube服务 安装 sonarqube服务器 1.执行脚本文件 config.sh 1#!/bin/bash 2sysctl -w vm.max_map_count=262144 3sysctl -w fs.file-max=65536 4ulimit -n 65536 5ulimit -u 4096 6# # 永久改变 7# echo "vm.max_map_count=262144" >> /etc/sysctl.conf 8# sysctl -p 1sh config.sh 2.执行docker-compose文件 1version: '3' 2services: 3 postgres: 4 image: postgres:15 5 container_name: postgres 6 ports: 7 - 5432:5432 8 volumes: 9 - ./sonar/postgres/postgresql:/var/lib/postgresql 10 - ./sonar/postgres/data:/var/lib/postgresql/data 11 environment: 12 TZ: Asia/Shanghai 13 POSTGRES_USER: user #数据库用户 14 POSTGRES_PASSWORD: password #数据库密码 15 POSTGRES_DB: sonar 16 17 sonarqube: 18 depends_on: 19 - postgres 20 image: sonarqube:9.