Zangyzhi

Docker 安装与疑难问题排查解决指南本文档记录了一次完整的 Docker 安装、配置镜像加速以及解决一系列复杂配置不生效问题的过程，旨在为遇到类似“幽灵”问题的用户提供一份从入门到深度排查的完整指南。 一、 Docker 标准安装与配置（Ubuntu）在 Ubuntu 系统上安装 Docker Engine 的标准步骤。 1. 准备工作更新 apt 包索引并安装必要的依赖软件。 Bash 12sudo apt-get updatesudo apt-get install ca-certificates curl 2. 添加 Docker 官方 GPG 密钥为了确保下载的软件包是官方且未被篡改的，需要添加 Docker 的 GPG 密钥。 Bash 12345678# 创建用于存放密钥的目录sudo install -m 0755 -d /etc/apt/keyrings# 下载 Docker 的 GPG 密钥sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/dock ...

本文记录一次服务器接入交换机的聚合整改。设备地址、端口编号、服务器名称和 MAC 地址均已脱敏。 一、故障现象服务器交换机上出现大量 MAC move 记录，同一个虚拟机 MAC 在同一台服务器的多个物理端口之间反复漂移。现场同时存在以下特征： 服务器使用多块物理网卡； 虚拟交换机或操作系统 Teaming 启用了负载均衡； 交换机端仍把这些端口当作独立 Access 口； 部分端口属于同一业务 VLAN，但没有加入相同聚合组。 这会造成交换机不断重写 MAC 表，表现为间歇丢包、ARP 异常、服务时通时断和未知单播增加。 二、先确认服务器侧模式交换机端不能凭端口数量直接创建聚合。必须先确认服务器侧属于哪一种模式： 服务器侧模式 交换机侧要求 LACP / 802.3ad 对应端口必须加入同一个动态聚合组 Active/Standby 通常保持独立端口，只允许主端口转发 Switch Independent 不应强制创建 LACP 聚合 虚拟交换机桥接 需要确认是否会让同一 MAC 同时从多个端口发出 本次通过服务器配置、端口流量、LACP Part ...

本文来自一次容器化 GitLab 偶发慢请求排查。主机名、域名、地址、项目名和访问凭据均已省略。 一、现象GitLab 登录页多数时候可以正常打开，容器健康检查也显示 healthy，但用户仍会遇到随机慢和超时。多次请求耗时差异很大，日志中出现： RedisClient::ReadTimeoutError； Waited 1.0 seconds； rack-timeout； 容器历史状态包含 OOMKilled=true。 只看 HTTP 200 或容器健康状态，很容易误判为“服务正常”。 二、证据链排查同时采集了容器、主机和应用三个层面的指标。 2.1 GitLab 容器 容器内存限制约 5 GiB； 实际使用已接近限制； 容器内存在十余个 Puma worker； 单个 worker 占用数百 MiB； 配置文件没有显式限制 Puma、Sidekiq 和监控组件资源。 2.2 宿主机 主机内存和 Swap 均处于高压状态； Swap 几乎被用满； vmstat 显示较高 IO wait； 多个进程长时间处于 blocked 状态； Redis 的 RDB 后台保存进一步增 ...

本文记录一次 vSphere Replication 多节点只读巡检。主机名、地址、域名、证书内容和访问凭据均已脱敏。 一、巡检目标环境包含一台管理节点和两台附加复制服务节点。巡检希望回答四个问题： 三台 Appliance 是否在线； 复制服务和管理服务是否正常运行； 是否存在卡住的配置任务； 能否从管理 API 读取配对关系、复制服务器和虚拟机复制状态。 二、巡检方法本次只执行读取操作，检查以下层级： 1234567891011TCP/HTTPS 可达性 ↓Appliance 配置 API ↓系统服务状态 ↓任务队列 ↓VR 管理 API 会话 ↓Pairings / Replication Servers / Replications 不能因为 Web 页面能打开，就直接判断复制链路健康。管理面、复制服务和具体复制任务是不同层级。 三、检查结果三台节点的基础状态均正常： 检查项 管理节点 附加节点 A 附加节点 B HTTPS/配置接口 正常 正常 正常 复制服务 Running Running Running REST ...

本文根据一次真实网络调整过程整理。设备地址、域名、端口编号和业务名称均已泛化，仅保留可复用的排障思路。 一、问题背景现场网络经过多次临时调整后，出现了几类相互交织的现象： 部分终端间歇性断网，故障难以稳定复现； 无线客户端偶尔获得服务器网段地址； 核心到出口的链路存在历史抖动记录； 服务器接入交换机出现大量 MAC 地址漂移； 实际物理拓扑与旧文档不一致，多个临时 Trunk 扩大了广播域。 这类问题不能只盯着某一根网线或某一个端口。正确做法是先重建事实，再按风险从低到高逐步处理。 二、排障边界第一阶段严格采用只读方式： 只执行 display 类命令； 不进入 system-view； 不保存配置； 采集前后都记录接口计数器和链路状态； 对不可达设备只记录现象，不通过重启等方式强行恢复。 这样可以把“采集造成的变化”和“网络自身变化”区分开，也方便后续建立可靠基线。 三、重新建立拓扑通过 LLDP、LACP、MAC 地址表、ARP 表、Trunk VLAN 列表和现场接线信息交叉验证，最终将网络抽象为以下结构： 12345678防火墙/出口 │三层核心交换机 ...

一、项目背景与环境概述1.1 项目信息 项目名称: Cleanl.de (新视点/ThinkCMF 6.0) 框架版本: ThinkPHP 6.0.14 LTS + ThinkCMF 6.0.8 PHP 版本要求: ≥ 7.4.0 (推荐 8.0+) 数据库: MySQL 5.7+ (备份来自 5.7.40-log) 1.2 服务器环境 控制面板: Plesk Obsidian (Webhosting.netcup) Web 服务器: Apache + mod_fcgid (FastCGI) PHP 版本: 8.5.4 (NTS) 数据库服务器: MySQL 8.0.44 (外部服务器 10.35.232.191:3306) 操作系统: Linux (Debian/Ubuntu 系列) 1.3 项目结构特点ThinkCMF 采用安全目录结构： 12345678910cleanl.de/ # 项目根目录├── app/ # 应用代码 (不可Web访问)├── data/ # 数据配置 ...

1. 引言：理解Linux运维开发的角色与快速入门之路 Linux运维开发工程师的角色融合了系统运维和软件开发的双重职责，其核心目标在于提升软件交付的效率和可靠性 1。对于希望快速进入这一领域的专业人士而言，本报告旨在提供一条专注且高效的成长路径。报告将详细阐述成为一名合格的Linux运维开发工程师所需掌握的关键技能，推荐有效的学习资源，提供实用的求职策略，并指导如何通过实践经验快速积累能力。 2. Linux运维开发工程师的必备技能：核心技术能力详解 2.1. Linux操作系统基础：角色的基石理解Linux操作系统的基本原理是运维开发工作的首要前提。这包括深入理解Linux的文件系统结构、文件权限管理、软件包管理（例如Debian系的apt，Red Hat系的yum和dnf等），以及熟练使用各种命令行实用工具 2。能够自如地在Linux环境下进行操作和管理是至关重要的 3。进一步地，还需要理解操作系统的一些核心概念，例如进程管理、内存管理以及执行基本的系统管理任务 4。对于更深入的DevOps实践而言，创建和管理高度定制化的Linux镜像，无论是针对虚拟机还是容器，也是一项重要的 ...

想知道 Hexo 支持哪些 Front Matter 格式 😄 Hexo 这家伙主要认这几种，带你看代码： **最爱 YAML (---)**：这是默认老大，兼容性最好！大家都用它。写起来像这样： 12345678910111213---title: 我的第一篇文章 # 文章标题date: 2025-04-14 13:25:00 # 创建日期 (注意格式)tags: # 标签，可以有多个 - 学习笔记 - Hexo示例categories: # 分类，也可以有层级 - 技术 - 前端updated: 2025-04-14 13:26:00 # 更新日期 (可选)---这里开始就是你的 Markdown 正文啦... 看到没？用 --- 包起来，里面是 键: 值 的格式，用缩进来表示层级，很简单吧！👍 **也认识 JSON ({})**：对，它也能看懂 JSON！虽然用的人少些，但如果你就是喜欢大括号，也没问题。通常直接把 JSON 对象放在文件最开头： 123456789{ "title": "我的第二 ...

可以通过以下几种方法使用 VS Code 将代码提交到 GitHub 仓库： 核心流程（最常用）： 这个流程假设你已经在本地初始化了 Git 仓库，并且已经将其连接到了一个 GitHub 远程仓库。 打开项目文件夹： 在 VS Code 中打开你的项目所在的文件夹。 打开源代码管理视图： 点击 VS Code 左侧活动栏中的第三个图标（通常像一个分叉的树枝），或者使用快捷键 Ctrl+Shift+G (Windows/Linux) 或 Cmd+Shift+G (Mac)。 查看更改： 在源代码管理视图中，你会看到所有已修改但尚未提交的文件列在“更改”下面。 暂存更改 (Stage Changes)： 暂存单个文件： 将鼠标悬停在要提交的文件上，然后点击右侧出现的 + (加号) 图标。 暂存所有更改： 将鼠标悬停在“更改”标题上，然后点击右侧出现的 + (加号) 图标。 暂存后的文件会移动到“已暂存的更改”区域。暂存意味着你希望将这些特定的更改包含在下一次提交中。 输入提交信息 (Commit Message)： 在源代码管理视图顶部的输入框中，输入本次提交的描述信息。这个 ...

真诚才是必杀技先承认一件事：这个标题有些讨巧。 如果把真诚当作一种“必杀技”，目的仍然是让别人喜欢自己、信任自己，甚至从别人那里得到回报，那么它就成了一种包装得更好看的技巧。这不是真诚，只是更隐蔽的算计。 我现在更愿意这样理解：真诚不是保证成功的方法，而是一种尽量不歪曲事实、不欺骗别人，也不欺骗自己的选择。 真诚不保证得到好结果真诚可能换来信任，也可能换来误解、拒绝，甚至被人利用。说真话不一定让关系更亲近，承认错误也不一定马上得到原谅。现实不会因为一个人态度真诚，就自动给他一个圆满的结局。 因此，“只要真诚，就一定能赢得别人”并不符合事实。人与人之间能否建立关系，还取决于立场、利益、能力、时机和边界。真诚只是其中一部分，不能代替解决问题的能力，也不能抹平真实存在的矛盾。 即便如此，真诚仍然有价值。它至少让沟通建立在比较真实的信息上，减少猜测和表演，也让自己不必为了维持一个谎言，再制造更多谎言。 坦诚不等于毫无保留真诚不是把所有想法都说出来，更不是以“我这个人说话直”为理由伤害别人。每个人都有隐私，也有暂时不想回答的问题。对不方便说的事，可以直接说“不方便透露”或“我还没有想好”，而不是 ...