基于华为云码道与 ModelArts MaaS 的原创智能论文阅读学习助手PaperLens案例类型：AI 应用开发 / 智能阅读 / 开发者工具实践适用对象：高校学生、科研入门者、需要精读英文论文的个人用户在线体验：http://101.245.81.114代码仓库：falconousZhang/PaperLens_final参考体例：华为云开发者空间实战案例1. 案例介绍1.1 项目背景在阅读英文科研论文时，初学者经常遇到以下问题：PDF 排版复杂，正文、公式、图表与双栏文本之间缺乏清晰的阅读引导；论文中包含大量专业术语和长句，逐句翻译耗时，简单机翻又难以解释原理；阅读过程中产生的高亮、笔记和问题分散在不同工具中，难以形成连续的学习记录；通用大模型不了解当前论文上下文，容易给出脱离原文、缺少依据的回答；传统审稿工具更偏向评价论文质量，并不完全适合个人“读懂论文、掌握方法”的目标。PaperLens 因此被设计为一款 AI 驱动的个人论文阅读学习助手。系统以原始 PDF 为阅读主体，在不破坏论文版式的前提下，将总结、翻译、选中文字解释、论文问答、高亮、笔记、批判性阅读和学习报告导出整合到同一个工作台中。1.2 建设目标项目的核心目标不是替代用户阅读，而是降低进入论文内容的门槛，并让 AI 的每一次回答都尽量与论文原文建立联系。具体目标包括：保留原始 PDF 排版，提供逐页阅读体验；支持页面总结、全文翻译和选中文字解释；建立论文级多轮问答，让模型结合全文和历史对话回答；支持原文高亮与笔记，并按论文、页码进行管理；提供用户注册登录、数据隔离和管理员治理能力；将学习解释、笔记、批判性阅读等内容汇总导出为 Markdown、PDF 或 DOCX；使用低成本华为云资源完成可访问、可演示的部署。1.3 案例成果PaperLens 已形成从论文上传到学习资料沉淀的完整闭环：注册/登录 ↓ 上传 PDF → 文本与版式解析 → 进入逐页阅读工作台 ↓ ↓ 论文库管理 总结 / 翻译 / 选中文字解释 ↓ ↓ 阅读进度 多轮论文问答 ↓ ↓ 高亮与笔记 ← 原文定位与交互 → 批判性阅读 └───────────────┬───────────────┘ ↓ 学习报告导出图 1 PaperLens 论文库：集中展示论文解析状态、阅读进度、高亮与笔记数量，并支持继续阅读和论文管理。项目已部署在华为云 ECS，使用华为云 ModelArts Studio（MaaS）提供真实大模型推理能力，并通过 Docker Compose 运行前端、后端和 PostgreSQL。2. 整体解决方案2.1 方案概述PaperLens 采用前后端分离架构。浏览器负责 PDF 页面展示、文本选择和学习交互；后端负责用户权限、论文解析、任务状态、模型调用、数据持久化和报告生成。大模型能力通过统一的 LLMClient 抽象接入，当前实际部署使用华为云 ModelArts Studio（MaaS）的对话模型服务。系统遵循三个设计原则：原文优先：左侧始终展示原始 PDF 页面，AI 结果作为辅助信息显示在右侧；来源可追溯：解析时记录页码、字符区间和文本块位置，学习内容可以重新定位到原文；任务可恢复：耗时操作以任务状态保存，页面刷新后可以恢复轮询，不依赖一次 HTTP 连接持续到模型返回。2.2 技术选型层次技术或服务作用前端Vue 3、TypeScript、Vite、Pinia、Vue Router、Axios阅读工作台、状态管理、路由保护和 API 调用后端Python、FastAPI、Pydantic、SQLAlchemyREST API、业务服务、参数校验和数据访问数据库PostgreSQL 16、Alembic用户、论文、页面、问答、解释、笔记、任务和审计数据PDF 处理PyMuPDF、pdfplumber页面渲染、正文提取、文本块定位和表格识别大模型华为云 ModelArts Studio（MaaS）、GLM-5.2总结、翻译、选中文字解释、论文问答和批判性阅读报告ReportLab、python-docxMarkdown、PDF、DOCX 学习报告生成部署华为云 ECS、VPC、安全组、弹性公网 IP、Docker Compose、Nginx单机容器化部署与公网访问研发辅助华为云码道（CodeArts）代码智能体需求理解、跨文件编码、测试设计、问题定位和部署调试2.3 开发环境与云资源准备本案例将“开发工具”和“运行资源”明确分开。码道、Rules 与 Skills 只在研发阶段使用，不会随应用一起部署；真正运行 PaperLens 时只需要前端、后端、数据库、文件卷和 MaaS 服务。类别本案例配置说明本地开发Windows、Git、Docker Desktop、Node.js、Python编码、容器联调和定向验收智能研发华为云码道（CodeArts）代码智能体、项目级 Rules、开发 Skills需求设计、编码、测试资产与问题定位大模型服务ModelArts Studio（MaaS）兼容对话接口由统一 LLMClient 调用，密钥仅通过环境变量注入云服务器华为云 ECS，Ubuntu 22.04，2 vCPU、4 GiB、40 GiB小规模实习项目的单机部署网络VPC、子网、安全组、弹性公网 IP，5 Mbit/s公网只开放 Web 入口和受限 SSH容器运行Docker Engine、Docker Compose运行 Nginx、FastAPI 和 PostgreSQL为控制成本，当前实际部署没有单独购买 RDS、OBS、ELB 或 Kubernetes。数据库与文件使用 ECS 上的 Docker 持久卷；项目保留向 RDS 和 OBS 演进的接口与部署资料，但案例不会把“已经设计”描述成“已经购买并运行”。3. 系统架构设计3.1 逻辑架构3.2 分层设计表现层前端采用 Vue 3 + TypeScript。核心页面包括登录注册、论文库、上传页面、论文阅读工作台、批判性阅读结果、报告导出和管理员控制台。论文阅读工作台采用左右分栏布局：左侧按页显示原始 PDF 图像，并叠加可选择的透明文本层；右侧在“学习解释、论文问答、学习记录”之间切换；用户选择原文后，可以直接创建黄色高亮、绿色笔记或发起通俗解释；点击历史解释时，系统自动跳转到对应页并高亮来源文本。接口层FastAPI 对外提供统一的 /api/v1 接口，按领域拆分为认证、论文、任务、学习解释、问答、论文库、学习记录、导出和管理员接口。Pydantic 负责输入输出边界，统一异常处理避免将数据库语句、文件路径或上游响应泄露给前端。业务层业务逻辑集中在 Service 层：pdf_parser：正文、章节、文本块、表格和 Evidence 解析；learning_service：页面总结、翻译与选中文字解释；qa_service、qa_retriever：论文级多轮问答和证据检索；highlight_service、note_service：高亮、笔记与原文锚点；review_service：批判性阅读；export_service、report_converter：学习报告组织与格式转换；admin_service：用户治理、内容元数据查询和审计。数据层PostgreSQL 保存结构化业务数据，Docker Volume 保存 PDF、页面图像和导出报告。数据库迁移由 Alembic 管理，容器启动时先执行迁移，再启动后端服务。3.3 核心数据流论文上传与解析用户上传 PDF，后端校验扩展名、文件头、大小和文件哈希；文件写入受控存储目录，创建论文记录和解析任务；PyMuPDF 提取页面正文、页面尺寸和文本块坐标；pdfplumber 尝试提取表格，表格失败不影响正文解析；系统生成页面、章节、文本分块和 Evidence 数据；论文状态更新为 PARSED，前端进入阅读工作台。学习解释用户选择总结、翻译，或在 PDF 文本层中选择一段原文；后端根据页码、字符区间和论文归属校验来源；系统构造带有明确边界的 Prompt，并调用 MaaS；模型输出经过结构校验和清洗后持久化；前端轮询任务状态，并将结果与对应页和选区关联。论文问答首次提问时，后端读取论文全文，在长度预算内构造论文上下文；后续提问同时附加最近的历史问答。检索模块优先识别问题中的页码、表号、图号等显式引用，再结合文本相关性选择候选证据。问答记录保存在会话中，用户可以切换、滚动查看或删除历史会话。3.4 华为云部署架构本案例定位为小规模实习项目，因此优先选择低成本、易维护的单机方案，而不是引入复杂的微服务集群。部署中只将 Nginx 的 80 端口发布到公网，后端 8000 和数据库 5432 仅在 Docker 私有网络中访问。数据库和文件目录使用持久卷，容器设置健康检查与 restart: unless-stopped。当前演示环境使用 HTTP；正式生产环境应增加域名、HTTPS 证书并启用 Secure Cookie。3.5 工程目录设计项目采用按前端、后端、部署和设计资料分区的单仓库结构。核心目录如下：PaperLens/ ├── backend/ │ ├── paperlens/ │ │ ├── api/ # FastAPI 路由与认证边界 │ │ ├── core/ # 配置、安全、错误和可观测性 │ │ ├── models/ # SQLAlchemy 业务模型 │ │ ├── schemas/ # Pydantic 请求与响应契约 │ │ └── services/ # 解析、解释、问答、记录和导出服务 │ ├── alembic/ # 数据库迁移链 │ └── tests/ # 后端测试资产 ├── frontend/ │ ├── src/api/ # API 客户端 │ ├── src/components/ # 阅读工作台组件 │ ├── src/stores/ # Pinia 状态 │ └── src/views/ # 登录、论文库、阅读、管理等页面 ├── deploy/huawei/ # 单 ECS 与生产化部署配置 ├── ProjectDocs/ # 需求、架构、页面、测试和 SDD 设计资料 ├── docker-compose.yml # 本地开发编排 └── README.md这种结构使码道能够先从设计资料理解约束，再定位到对应领域的路由、Schema、Service、模型和前端页面，减少把业务逻辑堆进单个文件的情况。3.6 核心数据模型PaperLens 的数据模型围绕“用户—论文—页面内容—学习行为”展开：数据域核心实体设计要点认证users、auth_sessions、password_reset_tokens角色、状态、刷新令牌轮换和密码重置论文papers、paper_pages、paper_sections、paper_chunks论文归属、解析状态、逐页正文和章节结构原文定位evidences、paper_tables页码、引用文本、字符区间、边界框和表格结构学习解释learning_explanations、learning_citations模式、范围、任务状态、来源引用和失败恢复论文问答paper_qa_conversations、paper_qa_turns、paper_qa_citations多轮顺序、幂等请求、上下文哈希和证据绑定学习记录paper_library_entries、paper_highlights、paper_notes阅读进度、黄色高亮、绿色笔记和原文锚点扩展分析analysis_tasks、review_results、metric_records、experiment_results批判性阅读、指标与实验理解导出与治理export_reports、admin_audit_logs报告状态、文件信息和管理员不可变审计任务型实体统一使用 PENDING → RUNNING → SUCCEEDED/FAILED 状态机。模型调用前结束数据库事务，模型返回后再用新事务写入结果，避免在外部网络等待期间长期持有连接或行锁。4. 使用华为云码道（CodeArts）代码智能体辅助开发与调试4.1 使用方式PaperLens 的功能跨度较大，涉及前端交互、后端 API、数据库迁移、PDF 处理、大模型调用和云端部署。项目使用华为云码道（CodeArts）代码智能体辅助理解代码库、拆解需求、生成跨文件代码、补充测试以及定位运行故障。项目没有采用“一次性生成整个系统”的方式，而是将开发过程拆成可验证的小阶段：明确用户目标 ↓ 形成单轮任务提示词和边界 ↓ 码道理解代码库并完成跨文件实现 ↓ 集中进行定向测试、构建或实际操作验收 ↓ 根据日志和页面现象定位问题 ↓ 码道完成同轮修正 ↓ 进入下一功能阶段4.2 Rules 与 Skills 工程化约束为了让智能体在长期迭代中保持一致，项目为码道配置了项目级规则和技能工作流，主要覆盖：需求细化与架构设计；页面原型和交互约束；前后端测试设计；功能详细设计与任务拆解；Sprint 进度管理；Bug 修复记录。每次给码道的任务都会说明目标、允许修改的范围、禁止事项、接口契约、数据一致性要求和验收方式。相比只描述“实现某功能”，这种结构化提示词能够降低跨文件修改遗漏、重复造轮子和无关重构的概率。4.3 提示词管理与迭代方法PaperLens 没有把码道提示词当作一次性聊天内容，而是为每个开发阶段保留任务编号、目标、约束、验收标准和后续状态。项目共形成 P1～P8.4 的 32 轮阶段提示词归档，使需求变化、实现边界和技术决策能够回溯。一条可执行的码道提示词通常包含以下结构：# 码道下一阶段提示词：<阶段编号与名称> ## 任务目标 - 本轮只解决什么问题 - 完成后用户能获得什么能力 - 与既有功能的关系 ## 开始前边界与真实基线 - 必读的设计文档和真实代码 - 当前迁移、接口、容器和功能状态 - 必须保护的用户数据与现有修改 - 禁止读取的密钥、令牌和环境信息 ## 设计与实现要求 - 数据模型、状态机和迁移规则 - API 请求/响应与错误语义 - Service、前端交互和安全边界 - 并发、幂等、事务和失败恢复 ## 测试资产与验收 - 只编写少量关键测试资产 - 码道不运行测试、构建、迁移或 Docker 命令 - 集中验收阶段执行定向测试、关键烟测和前端构建 ## 完成定义 - 允许修改的文件 - 必须同步的设计与 Sprint 文档 - 实际完成项、未完成项和风险必须如实报告提示词也随项目实践逐步演进：早期更强调从零搭建和运行验证；中期增加数据模型、API 契约、并发和安全约束；后期为了提高效率，码道只负责编写或更新少量测试资产，不在实现轮次运行耗时测试，测试执行统一放到集中验收阶段。4.4 代表性码道提示词节选以下内容选自项目实际提示词归档。为适合作为案例展示，省略了较长的文件清单、历史统计值和重复性约束，但保留了当轮的目标、关键边界与完成定义。提示词一：建立可运行工程骨架使用场景：项目初期先统一技术选型和数据契约，避免前后端、数据库和设计文档各自演进。你现在负责继续开发 D:\shixi\PaperLens 项目。 本轮目标不是一次性完成整个系统，而是完成“规格修正 + 可运行工程骨架”， 为后续端到端 MVP 开发建立稳定基础。 一、必须采用的 MVP 决策 1. 前端使用 Vue 3 + TypeScript + Vite + Pinia + Vue Router。 2. 后端使用 FastAPI + SQLAlchemy + Alembic。 3. 本地和部署均使用 PostgreSQL，不使用 SQLite。 4. Evidence 必须记录 page_number、quoted_text、bbox、char_start、 char_end、section_id 和 chunk_id，保证前端后续能够定位原文。 5. 上传统一使用 multipart 流式上传，最大 50 MB。 6. 后台任务进度统一使用 HTTP 轮询，暂不引入 WebSocket。 7. MVP 只支持可提取文本的 PDF，OCR 放入后续版本。 8. LLM 必须通过统一 LLMClient 调用，默认提供 MockLLMClient。 二、本轮交付 - 创建 backend、frontend、docker-compose.yml、.env.example 和 README。 - 后端实现健康检查、配置、数据库连接、ORM、首个迁移和统一错误结构。 - 前端实现基础路由、Pinia、首页、健康检查及后端不可用提示。 - Compose 只包含 PostgreSQL、backend 和 frontend。 三、边界 - 不写入真实密钥，不初始化或提交 Git。 - 不引入 Celery、Redis、Nginx、FAISS 或真实云服务。 - 不生成大量空接口或只有 pass 的占位代码。 - 本轮到“工程骨架可以启动、模型和契约自洽”为止， 不继续实现 PDF 解析和真实 LLM 功能。落地结果：码道完成了 FastAPI、Vue、PostgreSQL 与 Docker Compose 的基础工程，并建立了后续一直沿用的 Evidence 定位字段和 LLMClient 抽象。提示词二：接入华为云 ModelArts MaaS使用场景：在 Mock 模型链路已经可用后，增加真实华为云模型适配器，同时保证本地开发不依赖云端密钥。# P3.3 华为云 MaaS 真实生成式模型适配器 ## 任务目标 在不改变现有审阅 API、数据库模型和前端的前提下， 把 LLMClient 从“只有 Mock 实现”扩展为可配置的 HuaweiMaaSLLMClient。 默认本地和测试仍使用 MockLLMClient。 ## 实现边界 1. 复用现有 httpx，不新增第三方模型 SDK、requests 或重试库。 2. 华为 MaaS 适配器使用标准 chat/completions 请求结构。 3. endpoint、model、API Key、连接超时和读取超时全部来自 Settings。 4. API Key 使用安全类型保存，不得出现在日志、异常、响应或 repr 中。 5. 不修改公开 API、ORM、Alembic、Docker 和前端。 6. 云接口测试必须使用 MockTransport，禁止真实联网和产生费用。 ## 响应与失败处理 - 校验 HTTP 状态、响应 JSON、choices、message 和 content。 - 兼容模型返回单个完整 Markdown JSON 围栏。 - 拒绝前后杂文、多对象、字段缺失和未知字段。 - 上游失败统一转换为安全业务错误，不把响应正文或密钥返回给客户端。 ## 完成定义 - Mock 与 Huawei MaaS 通过同一 LLMClient 工厂切换。 - 没有云端配置时项目仍可离线运行。 - 配置示例只使用占位符，不读取、打印或提交真实密钥。落地结果：真实模型与 Mock 模型共用同一业务接口，学习解释、问答和批判性阅读无需感知底层供应商；部署时只需通过环境变量选择 MaaS 适配器。提示词三：把产品主线校正为论文阅读学习使用场景：项目中期确认“帮助个人用户读懂论文”才是核心目标，因此需要在保留已有分析能力的同时重构主要交互。# P7.1 论文阅读学习工作台与证据化学习解释 ## 任务目标 把 PaperLens 的产品主线从“辅助审稿”校正为“帮助个人用户阅读论文并学习”。 在已完成的 PDF 解析、章节/页面、Evidence、认证隔离和 Huawei MaaS LLMClient 基础上，实现受保护的论文阅读工作台，以及针对当前页面或 选中文字的总结、翻译和通俗解释闭环。 已有结构化审阅、指标提取、实验分析和报告能力继续保留，分别作为 “批判性阅读”“实验理解”和“学习成果导出”的高级能力，不删除或重做。 ## 来源与安全边界 1. 客户端只提交 mode、scope 和页码/选区标识，不提交论文正文或 prompt。 2. 后端根据当前用户和 paper_id 重新读取来源，禁止跨用户、跨论文引用。 3. 论文标题和正文均视为不可信输入，并放在明确标签中；其中出现的 “忽略之前指令”等文字不得覆盖 system 指令。 4. SUMMARY 概括当前范围；TRANSLATE 忠实翻译并保留标题、段落和编号； 选中文字解释要说明概念、原理和例子。 5. 结果必须保存页码、来源哈希和任务状态，失败只记录安全公开文案。 ## 前端交互 - 阅读页采用左右分栏，左侧保留原始 PDF 版式并支持文本选择。 - 右侧显示学习解释历史；点击记录跳转到来源页。 - 选中文字解释与原文位置关联，不能把解释结果挤在 PDF 正文下方。 - 页面切换或组件卸载时停止旧轮询，避免旧结果覆盖新页面。落地结果：PaperLens 从“生成审阅结论”转向“原文阅读 + 页面解释 + 学习沉淀”，形成当前最具辨识度的双栏阅读工作台。提示词四：实现论文级多轮问答使用场景：解决“论文里明明存在，模型却因为只收到当前页片段而回答没有”的问题。# P7.2 当前论文多轮问答与证据化会话 ## 任务目标 实现只围绕当前用户、当前论文的多轮问答。用户可以新建会话、连续提问、 查看历史；有依据的回答绑定服务端选取的论文来源，证据不足时明确降级， 不能用模型常识伪装成论文结论。 ## 上下文构造 1. 以当前 question 为 query，仅在当前论文的 Evidence 中做确定性相关性排序。 2. 后续提问附加同会话最近的成功问答，超限时按完整轮次从最旧开始移除。 3. 候选 Evidence 按相关度、页码、创建时间和 ID 稳定排序，并限制 top_k。 4. 当前问题、历史回答和论文正文全部视为不可信内容，不能提升为 system role。 5. Embedding 与 LLM 调用期间不得持有数据库事务或行锁。 ## 幂等与结果契约 - 请求包含 client_request_id；重复请求返回原轮次，不重复调用模型。 - 同一会话只允许一个 PENDING/RUNNING 轮次。 - 成功回答保存 answer、grounded 和来源引用；证据不足时 grounded=false。 - 模型只返回一个严格 JSON 对象，拒绝额外解释、未知字段和跨论文引用。 ## 前端交互 - 右侧使用类似即时通信软件的消息时间线。 - 会话历史和消息区域可独立滚动，输入区固定在底部。 - 支持新建、切换和删除会话，轮询在终态立即停止。落地结果：系统形成论文级会话、轮次、上下文预算和幂等机制。真实论文验证中发现仅依赖少量 Evidence 会漏掉跨页图表后，后续迭代又将策略调整为“首次提问按预算提供全文基础上下文，后续附加历史，并优先识别页码、表号和图号”，体现了设计根据实际效果继续修正的过程。提示词五：准备华为云部署与安全收口使用场景：开发轮次结束后，为 ECS 部署、备份恢复和后续云资源演进准备可复用资产。# P8.4 华为云部署、备份恢复与综合安全验收 ## 任务目标 在既有论文阅读学习、登录注册、管理员、任务恢复和限流能力基础上， 补齐华为云部署配置、备份恢复说明和安全清单，使项目达到 “代码与部署资料完整，等待真实云环境验收”的状态。 ## 真实性要求 1. 不实际购买、创建、修改或删除华为云资源。 2. 不把“部署资产已完成”写成“真实云上已经部署”。 3. 示例只能使用占位符，禁止读取或写入 API Key、AK/SK、JWT Secret、 数据库密码、真实 IP、域名和证书私钥。 4. 码道只编写代码、少量测试资产、部署配置和文档， 不运行测试、构建、迁移、Docker、HTTP 或真实云服务命令。 ## 部署资产 - 提供 deploy/huawei 下的环境示例、Compose、Nginx、部署和回滚说明。 - 后端和数据库不直接暴露公网；只由 Nginx 代理同源 /api/。 - 容器使用非 root、只读文件系统、tmpfs、no-new-privileges、 healthcheck、资源上限和 restart policy。 - Secret 通过受限环境文件或 secret 文件注入，entrypoint 不打印内容。 - 给出 VPC、安全组、ECS、MaaS、健康检查和小额验证的人工配置顺序。 ## 完成定义 区分“代码与部署资产已实现”“离线验收尚未执行” 和“真实华为云资源尚未创建/验证”三种状态，不夸大完成度。落地结果：项目形成单 ECS 演示编排和面向生产化演进的配置资料；真实部署时又根据小规模需求选择 PostgreSQL 与文件卷同机运行，避免为了案例展示购买不必要资源。4.5 码道参与的主要开发阶段阶段码道辅助内容形成的结果工程骨架分析前后端技术栈，生成 FastAPI、Vue、PostgreSQL、Docker 基础结构可运行的前后端与数据库环境PDF 解析实现上传校验、页面解析、章节识别、文本块坐标和 Evidence 生成从 PDF 到可阅读、可定位数据的链路大模型接入抽象 LLMClient，实现 Mock 与 Huawei MaaS 适配器本地离线开发与云端真实模型可切换阅读工作台跨文件实现 PDF 页面、透明文本层、左右分栏和选区工具条保留原版式的交互式阅读体验学习解释设计总结、翻译、选中文字解释的 Prompt、状态机和历史记录面向学习场景的 AI 辅助阅读能力论文问答设计会话、轮次、全文上下文、历史预算和检索策略支持论文内连续提问用户与管理实现 JWT、刷新令牌、用户隔离、管理员角色和审计完整登录注册与管理闭环报告导出组织解释、高亮、笔记和批判性阅读内容Markdown、PDF、DOCX 学习报告云端部署分析 Docker、Nginx、卷权限和 MaaS 日志在小规格华为云 ECS 上稳定运行4.6 码道辅助调试实例实例一：测试数据误写开发库早期测试虽然创建了测试数据库，但应用在模块导入时已经初始化了指向开发库的数据库连接，导致部分测试仍可能写入开发库。码道根据数据库记录变化和初始化顺序分析问题，协助调整为延迟配置数据库 Engine，并增加测试库名称守卫、迁移失败即终止和测试残留检查。解决后，测试环境明确使用 paperlens_test，避免自动化测试污染真实论文数据。实例二：真实 MaaS 输出格式不稳定Mock 模型始终返回标准 JSON，但真实模型可能返回 Markdown 代码围栏、额外解释或字段缺失。码道协助增加严格的响应解析、围栏兼容、字段校验和安全失败状态；学习解释还使用独立的较长读取超时，避免长页翻译被普通问答的超时配置提前终止。实例三：Docker 容器在 ECS 上反复重启部署时 Nginx 采用只读文件系统，但默认尝试在 /var/cache/nginx 创建临时目录，导致容器因权限不足反复重启。码道根据容器日志定位到临时目录问题，将相关目录调整到 /tmp，并通过受限 tmpfs 提供可写空间。后端文件卷也曾因宿主卷所有权不匹配导致上传失败，随后增加一次性的 storage-init 服务，在后端启动前修正目录所有者和权限。实例四：公网 HTTP 下论文问答误报网络失败浏览器在普通 HTTP 环境下不能保证提供 crypto.randomUUID()。前端在创建会话后生成幂等请求 ID 时抛出本地异常，因此服务器只看到会话被创建和删除，没有收到真正的问题请求。码道根据前后端访问日志定位到请求链中断位置，增加基于 getRandomValues 的 UUID v4 回退逻辑，并区分本地运行异常和真实网络异常。这些问题说明，代码智能体的价值不仅是生成代码，还包括结合代码库、日志、运行环境和数据状态完成工程化定位。5. 功能解决方案设计5.1 原版式 PDF 阅读系统不将 PDF 正文简单转换成连续纯文本，而是为每一页生成页面图像，同时输出带坐标的文本层。页面图像保证视觉排版与原论文一致，透明文本层负责文字选择、字符偏移计算和高亮交互。这种设计兼顾了两个目标：用户看到的是原论文版式、图片、公式和表格；系统仍能知道用户选中了哪段文字，并把操作绑定到页码和字符区间。图 2 论文阅读工作台：左侧按页保留原始 PDF 版式，右侧统一承载学习解释、论文问答和学习记录。5.2 页面级学习解释“总结”和“翻译”按页生成并保留历史：总结要求覆盖当前页的各级标题；如果一个段落延续到下一页，可读取有限的下一页上下文补全含义；翻译要求保留标题层级和正文段落，不将公式、编号和专有名词随意改写；选中文字解释只处理用户选择的原文，重点说明概念、原理和例子。所有解释按页排序。点击历史记录可跳转到来源页；选中文字解释打开时，对应原文保持蓝色高亮。图 3 页面完整翻译：在保留标题、作者信息和正文层次的基础上，对当前页内容进行中文翻译。图 4 选中文字解释：左侧原文保持蓝色定位高亮，右侧从概念、原理和示例角度给出通俗说明。5.3 论文级多轮问答论文问答采用类似即时通信软件的对话界面。系统保存完整会话历史，输入区固定在底部，消息区域可独立滚动。为了减少“论文里明明有，模型却回答没有”的情况，后端不只发送当前页摘要，而是在首次提问时组装论文全文上下文；后续轮次再附加历史问答，并对超长内容执行可预测的长度预算。对页码、图号、表号等问题，检索器给予显式引用更高优先级。图 5 论文级多轮问答：用户可以围绕指定页码、表格或方法连续追问，系统保留会话历史并结合论文内容回答。5.4 高亮和笔记用户可以直接在 PDF 上选择文字：高亮以黄色保存；笔记以绿色标记，并保存笔记正文；选中文字解释使用蓝色定位；学习记录只展示当前页的高亮和笔记。记录同时保存原文、页码、字符起止位置和来源哈希。当论文内容或解析结果发生变化时，系统可以识别来源不一致，避免错误定位。图 6 高亮与笔记：黄色标记用于原文高亮，绿色标记关联学习笔记，右侧仅展示当前页的学习记录。5.5 用户、权限与管理员系统系统支持注册、登录、刷新令牌、退出、修改密码、忘记密码和个人资料。密码使用 Argon2 哈希；访问令牌采用 JWT，刷新令牌使用 HttpOnly Cookie，并具有轮换和重放检测机制。所有论文、解释、问答和学习记录均按 user_id 隔离。管理员可以查看系统概况、管理用户状态和角色、只读查看跨用户内容元数据，关键操作写入不可变审计记录。5.6 学习报告导出报告不再限定为“审阅报告”。即使论文没有执行批判性阅读，只要存在学习解释、高亮或笔记，也可以生成学习报告。报告按页组织内容，并可选择是否加入批判性阅读、指标或实验信息，最终导出为 Markdown、PDF 或 DOCX。图 7 学习报告导出：支持 PDF、DOCX 和 Markdown，固定汇总学习解释、高亮摘录和学习笔记，并可按需加入扩展分析。6. 核心技术难点与解决思路6.1 PDF 视觉版式与文本交互难以兼得难点：直接展示 PDF 可以保留版式，但难以稳定获取选中文字的字符位置；只展示解析文本又会破坏双栏、图表和公式布局。解决思路：采用“页面图像 + SVG 透明文本层 + 解析文本索引”的三层结构。图像负责视觉，文本层负责浏览器选择，后端标准化文本负责字符区间与学习记录。6.2 解析结果存在不确定性难点：不同 PDF 的字体、编码、文本顺序和表格结构差异很大，单个表格解析异常可能导致整个事务失败。解决思路：对正文、章节、表格和 Evidence 分阶段处理；表格写入使用嵌套事务或降级策略，使局部失败不影响论文正文；对扫描版 PDF 明确返回不支持 OCR，而不是生成不可用结果。6.3 大模型回答必须与论文上下文绑定难点：如果只传当前页或少量 Evidence，模型可能无法理解跨页图表；如果直接无限制传全文，又会超过上下文或增加费用。解决思路：采用“全文基础上下文 + 当前页优先 + 显式页码/图表引用检索 + 历史轮次预算”的组合策略。系统保存上下文哈希和请求幂等键，避免同一问题被重复提交。6.4 模型输出和网络调用不稳定难点：真实模型可能返回围栏文本、非标准字段或较长推理内容；长页翻译比普通问答耗时更长。解决思路：统一 LLMClient 接口，设置连接与读取超时边界；不同任务可以覆盖单次读取超时；模型结果经过严格 Pydantic 校验，失败时写入安全的任务状态，不将上游响应和密钥返回给用户。6.5 异步任务与页面状态一致性难点：解析、解释、问答和导出都不是瞬时操作。快速切换论文或页面时，旧请求可能晚于新请求返回并覆盖界面。解决思路：后端采用持久化任务状态和原子认领，前端采用受控轮询、代次标识和组件卸载清理。刷新页面后重新查询活动任务，终态立即停止轮询。6.6 小规格 ECS 上的资源与可靠性难点：2 vCPU、4 GiB 内存同时运行镜像构建、数据库、后端和前端时容易出现内存压力；公网拉取 Docker Hub 镜像也可能超时。解决思路：配置交换分区和容器资源上限；使用多阶段构建缩小运行镜像；通过华为云 SWR 镜像加速拉取基础镜像；只运行单后端实例和小连接池，避免为实习项目引入 Redis、Celery、Kubernetes 等额外组件。7. 安全与可靠性设计真实 API Key、数据库密码和 JWT Secret 通过环境文件注入，不进入代码仓库；上传文件校验后缀、PDF magic、大小和存储路径，防止路径穿越；数据查询统一校验资源所有者，管理员接口使用独立权限保护；日志只记录请求 ID、阶段和安全错误分类，不记录论文全文、令牌或 MaaS 响应正文；后端与数据库不直接暴露公网端口；容器启用 no-new-privileges，前端使用只读文件系统；提供 live/ready 健康检查、启动恢复和容器自动重启；自动化测试使用独立测试数据库，并在测试前后检查数据残留。8. 项目实施过程8.1 分阶段建设项目采用逐阶段增量开发，每一阶段都对应独立提示词、设计更新和可验收结果。阶段主要任务阶段出口P1FastAPI、Vue、PostgreSQL、Docker 工程骨架首页与健康检查可运行，迁移链建立P2PDF 上传、解析、章节、页面、文本块、表格和 Evidence论文可从文件转换为结构化、可定位内容P3MockLLM、Embedding、Huawei MaaS、结构化结果前端真实模型与离线模型可以切换P4指标抽取、实验数据统计和模型运行配置模型理解与确定性计算分离P5实验文件导入、校验、比较和可视化论文实验结果可结构化分析P6Markdown、PDF、DOCX 报告分析结果可以形成文件交付P7阅读工作台、学习解释、多轮问答、高亮和笔记产品主线转为个人论文阅读学习P8登录注册、管理员、审计、恢复、限流、部署与安全形成完整用户系统并具备云端运行条件其中 P7 是产品方向最重要的一次调整。项目没有删除已经实现的审阅、指标和实验功能，而是把它们移动为“批判性阅读”和“实验理解”等高级入口，主路径改为上传论文后直接进入逐页阅读工作台。8.2 设计文档与任务追踪码道在编码前先同步以下设计层：需求细化：确认用户目标、功能范围、非目标和冲突决策；架构设计：明确前后端边界、外部 MaaS、任务与存储关系；数据模型：定义实体、外键、状态机、索引和迁移安全；API 设计：固定请求字段、响应结构、权限和错误语义；页面设计：固定路由、页面状态和交互行为；测试设计：只保留正常路径、关键失败和必要恢复场景；SDD 与 Sprint：把需求映射到具体设计、文件和任务状态。这种做法解决了长周期智能体开发中常见的“上一轮约束在下一轮丢失”问题。提示词不再重复粘贴整个项目，而是引用稳定设计资料，再补充本轮真实基线和差异要求。8.3 集中验收策略为了避免码道在每个实现轮次反复执行耗时的全量测试，项目后期采用“实现与验收分离”策略：码道负责更新必要测试资产，但提示词明确禁止运行测试、构建、迁移往返、Docker 重建和 HTTP 烟测；实现轮次完成后，先检查实际改动范围和接口契约；后端默认只运行受影响模块的定向测试；前端变更运行相关 Vitest 和一次生产构建；只保留一条关键业务烟测，例如“上传 PDF → 解析 → 进入阅读页”；认证、迁移链、共享基础设施或最终发布才执行更完整的回归。单个新功能通常只设计 1 个正常用例、1 个重要失败用例，以及在确有并发或恢复风险时增加 1 个对应场景。该策略更符合个人实习项目的成本与风险水平。8.4 华为云 ECS 部署过程部署采用单机 Compose，核心步骤如下：创建 VPC、子网、安全组、弹性公网 IP 和 Ubuntu 22.04 ECS；安全组开放 80，并将 22 端口来源限制为当前管理 IP；安装 Docker Engine 与 Compose，配置华为云 SWR 镜像加速；将代码发布包上传到 /opt/paperlens，检查校验和后解压；创建权限为 600 的部署环境文件，交互式写入数据库密码、JWT Secret 和 MaaS Key；使用 docker-compose.single.yml 构建并启动服务；检查容器状态、前端健康检查和后端 readiness；在浏览器完成注册、上传论文、学习解释和论文问答验证。示例命令中的配置均使用占位符，不包含真实凭据：cd /opt/paperlens chmod 600 deploy/huawei/.env.single docker compose \ --env-file deploy/huawei/.env.single \ -f deploy/huawei/docker-compose.single.yml \ up -d --build docker compose \ --env-file deploy/huawei/.env.single \ -f deploy/huawei/docker-compose.single.yml \ ps -a curl -fsS http://127.0.0.1/healthz curl -fsS http://127.0.0.1/api/v1/health/ready服务以 detached 模式运行，因此关闭本地 PowerShell 或 SSH 会话不会停止容器。ECS 重启后，Docker 服务与 Compose 的重启策略负责恢复应用。8.5 部署期问题闭环现象定位依据修正Docker Hub 拉取超时docker pull 访问官方 Registry 超时配置华为云 SWR 镜像加速并重启 DockerNginx 容器持续重启日志显示只读目录无法创建临时文件临时目录迁移到 /tmp，通过受限 tmpfs 提供写入PDF 上传失败后端日志显示持久卷目录权限不足启动前由一次性初始化服务修正卷所有权管理员升级 SQL 失败psql 变量替换与引号组合错误改用明确参数边界并先只读查询用户 ID论文问答前端报网络失败后端只有会话请求，没有问题请求为非安全 HTTP 环境增加 UUID v4 回退实现长页翻译偶发失败MaaS 请求耗时超过通用读取超时为学习解释配置独立、有限的读取超时部署验收以真实页面操作为准，不仅依赖容器显示 healthy。只有注册登录、论文上传解析、MaaS 学习解释、论文问答和管理员入口均完成小额验证，才认为案例具备可演示性。9. 应用效果与价值PaperLens 将“看 PDF、查术语、做笔记、问模型、整理报告”从多个割裂工具合并为一个连续流程。对个人学习场景而言，它带来的价值主要体现在：降低英文论文和专业概念的理解门槛；保持 AI 结果与当前论文、页码和原文选区的联系；让多轮问答、解释历史、高亮和笔记可以长期保存；通过华为云 MaaS 获得真实模型能力，同时保留 Mock 模型便于离线开发；通过码道代码智能体提升跨前后端开发和故障定位效率；使用单台小规格 ECS 即可完成课程设计、实习成果或个人演示部署。10. 局限与后续规划当前版本面向小规模个人使用，仍有以下边界：暂不支持扫描版论文 OCR；语义检索尚未使用持久化向量数据库；后台任务仍采用进程内执行器，不适合多实例横向扩展；单机 PostgreSQL 和本地文件卷需要定期备份；后续可根据实际用户量逐步引入 OBS、RDS、HTTPS、任务队列、pgvector 和多模态论文理解，但不在小规模案例阶段提前增加系统复杂度。11. 总结PaperLens 展示了如何将华为云码道（CodeArts）代码智能体、ModelArts Studio（MaaS）与常见 Web 技术结合，构建一套可实际部署的智能论文阅读学习应用。在研发侧，码道帮助项目完成需求拆解、跨文件编码、测试设计和部署故障定位；在运行侧，MaaS 提供总结、翻译、解释和问答能力；在基础设施侧，华为云 ECS 提供轻量、可控的容器运行环境。最终方案既满足个人学习项目的成本边界，也保留了向云数据库、对象存储和更可靠任务架构演进的空间。12. 参考资料华为云开发者空间实战案例参考页面华为云码道（CodeArts）代码智能体产品功能华为云码道（CodeArts）内置智能体用户指南ModelArts Studio（MaaS）API 调用规范华为云弹性云服务器 ECS 产品介绍

docker官方镜像仓下载很慢，华为云自有加速仓镜像不全，经常失败，可参考如下配置：修改docker配置 vim /etc/docker/daemon.json{ "registry-mirrors": [ "https://docker.1ms.run", "https://docker.xuanyuan.me", "https://$YOUR_ID.mirror.swr.myhuaweicloud.com" ], "max-concurrent-downloads": 10, "max-download-attempts": 5 } 其中 https://$YOUR_ID.mirror.swr.myhuaweicloud.com 镜像加速地址从控制台–容器镜像服务–镜像资源–镜像中心，右上角“镜像加速器”获取。修改后重启服务sudo systemctl daemon-reload sudo systemctl restart docker修改DNS，否则无法使用外部镜像加速源，vim /etc/resolv.conf 增加两行nameserver 8.8.8.8 nameserver 114.114.114.114 测试可用ping通 ping docker.1ms.run

一：🔥 虚拟化 & 容器化🦋 什么是虚拟化、容器化物理机：实际的服务器或者计算机。相对于虚拟机而言的对实体计算机的称呼。物理机提供给虚拟机以硬件环境，有时也称为“寄主”或“宿主”。虚拟化：是指通过虚拟化技术将一台计算机虚拟为多台逻辑计算机。在一台计算机上同时运行多个逻辑计算机，每个逻辑计算机可运行不同的操作系统，并且应用程序都可以在相互独立的空间内运行而互不影响，从而显著提高计算机的工作效率。容器化：容器化是一种虚拟化技术，又称操作系统层虚拟化(Operating system levelvirtualization)，这种技术将操作系统内核虚拟化，可以允许用户空间软件实例(instances)被分割成几个独立的单元，在内核中运行，而不是只有一个单一实例运行。这个软件实例，也被称为是一个容器(containers)。对每个实例的拥有者与用户来说，他们使用的服务器程序，看起来就像是自己专用的。容器技术是虚拟化的一种，而 docker是现今容器技术的事实标准类比理解物理机就像一个庄园，独立占用了一块土地，花园都是自己的，其他人无法共享使用。虚拟机相当于开发商的一个楼盘，一栋楼一套房子一户人家，共享一块宅基地，共享小区的花园，共享小区的游乐设施容器相当于几个人一起合租一套房，共享这套房子的卫生间、共享厨房、共享 WiFì，只有衣服、电脑等私人物品是你自己的。🦋 为什么要虚拟化、容器化?我们从上面的历史发展来看，虚拟化和容器化的最主要目的就是资源隔离，随着资源隔离的实现逐渐也带来了更大的收益。资源利用率高：将利用率较低的服务器资源进行整合，用更少硬件资源运行更多业务，降低 IT 支出和运维管理成本。比如上图中我们的土地直接复用，使用这块土地的人多了，但是成本还是庄园那块地环境标准化：一次构建，随处执行。实现执行环境的标准化发布，部署和运维。开发过程中一个常见的问题是 环境一致性问题。由于开发环境、测试环境、生产环境不一致，导致有些bug 并未在开发过程中被发现。而 Docker 的镜像提供了除内核外完整的运行时环境确保了应用运行环境一致性，从而不会再出现 「这段代码在我机器上没问题啊」 这类问题。资源弹性收缩：根据业务情况，动态调整计算、存储、网络等硬件及软件资源。比如遇到双 11 了，把服务扩容 100 个，双 11 过去了， 把扩容的 100 个收回去。差异化环境提供：同时提供多套差异化的执行环境，限制环境使用资源。比如我的服务一个以来 Ubuntu 操作系统，一个服务依赖 CentOS 操作系统，但是没有预算购买两个物理机，这个时候容器化就能很好的提供多种不同的环境。沙箱安全：为避免不安全或不稳定软件对系统安全性、稳定性造成影响，可使用虚拟化技术构建虚拟执行环境。比如我在容器里面执行 rm -f/* 不会把整个服务器搞死，也不影响其他人部署的程序使用。容器对比虚拟机更轻量，启动更快：传统的虚拟机技术启动应用服务往往需要数分钟，而 Docker 容器应用，由于直接运行于宿主内核，无需启动完整的操作系统，因此可以做到秒级、甚至毫秒级的启动时间。大大的节约了开发、测试、部署的时间。docker不需要虚拟内核，所以启动可以更快，相当于 windows 的开机时间省去了。维护和扩展容易：Docker 使用的分层存储以及镜像的技术，使得应用重复部分的复用更为容易，也使得应用的维护更新更加简单，基于基础镜像进一步扩展镜像也变得非常简单。此外，Docker 团队同各个开源项目团队一起维护了一大批高质量的 官方镜像，既可以直接在生产环境使用，又可以作为基础进一步定制，大大的降低了应用服务的镜像制作成本。比如 docker hub 提供了很多镜像，各个系统的一个命令就可以拿到了，研发也可以自己定制镜像分享给各个产品。🦋 虚拟化常见类别虚拟机：存在于硬件层和操作系统层间的虚拟化技术。虚拟机通过“伪造”一个硬件抽象接口将一个操作系统以及操作系统层以上的层嫁接到硬件上，实现和真实物理机几乎一样的功能。比如我们在一台 Windows 系统的电脑上使用 Android 虚拟机，就能够用这台电脑打开 Android 系统上的应用。容器：存在于操作系统层和函数库层之间的虚拟化技术。容器通过“伪造”操作系统的接口将函数库层以上的功能置于操作系统上。以 Docker 为例，其就是一个基于 Linux 操作系统的 Namespace 和 Cgroup 功能实现的隔离容器，可以模拟操作系统的功能。简单来说，如果虚拟机是把整个操作系统封装隔离，从而实现跨平台应用的话，那么容器则是把一个个应用单独封装隔离，从而实现跨平台应用。所以 容器体积比虚拟机小很多，理论上占用资源更少M。容器化就是应用程序级别的虚拟化技术。容器提供了将应用程序的代码、运行时、系统工具、系统库和配置打包到一个实例中的标准方法。容器共享一个内核(操作系统)，它安装在硬件上。JVM 之类的虚拟机：存在于函数库层和应用程序之间的虚拟化技术。Java 虚拟机同样具有跨平台特性，所谓跨平台特性实际上也就是虚拟化的功劳。因为 Java 语言是 调用操作系统函数库 的，JVM 就是在应用层与函数库层之间建立一个 抽象层，对下通过不同的版本适应不同的操作系统函数库，对上提供统一的运行环境交给程序和开发者，使开发者能够调用不同操作系统的函数库。补充：应用程序执行环境分层 硬件层：提供硬件抽象，包括指令集架构、硬件设备及硬件访问接口操作系统层：提供系统调用接口，管理硬件资源程序库层：提供数据结构定义及函数调用接口二：🔥 常见虚拟化实现方式🦋 主机虚拟化（虚拟机）实现主机虚拟化的原理是通过在物理服务器上安装一个 虚拟化层 来实现。这个虚拟化层可以在物理服务器和客户操作系统之间建立虚拟机，使得它们可以独立运行。从软件框架的角度上，根据虚拟化层是直接位于硬件之上还是在一个宿主操作系统之上，将虚拟化划分为 Type1 和 Type2 Type1 类的 Hypervisor：是一种系统软件，它充当计算机硬件和虚拟机之间的中介，负责有效地分配和利用由各个虚拟机使用的硬件资源，这些虚拟机在物理主机上单独工作，因此，Hypervisor 也称为 虚拟机管理器特点：直接运行在硬件之上，没有宿主机操作系统，Hypervisor 直接控制硬件资源和客户机典型框架为Xen、VmwareESXType2 类的 Hypervisor：运行在一个宿主机操作系统之上(Vmware Workstation) 或者 系统里面，Hypervisor 作为宿主机操作系统中的一个应用程序，客户机就是在宿主机操作系统上的一个进程。🦋 容器虚拟化实现容器虚拟化，有别于主机虚拟化，是操作系统层的虚拟化。基本原理：通过 namespace 进行各程序的隔离，加上 cgroups 进行资源的控制，以此来进行虚拟化。🎀 Namespace（命名空间）定义：namespace 是 Linux 内核用来隔离内核资源的方式。作用：实现进程、文件系统、用户等资源的隔离。具体实现：通过将一个或多个进程指定在同一个namespace中，使得这些进程只能看到与自己相关的资源。注意：Linux namespaces 是对全局系统资源的一种封装隔离，使得处于不同 namespace 的进程拥有独立的全局系统资源，改变一个 namespace 中的系统资源只会影响当前namespace 里的进程，对其他 namespace 中的进程没有影响。Namespace    系统调用参数    隔离的全局系统资源    内核版本UTS    CLONE_NEWUTS    主机名和域名    2.6.19IPC    CLONE_NEWIPC    信号量、消息队列和共享内存 – 进程间通信    2.6.19PID    CLONE_NEWPID    进程编号    2.6.24Network    CLONE_NEWNET    网络设备、网络栈、端口等    2.6.29Mount    CLONE_NEWNS    文件系统挂载点    2.4.19User    CLONE_NEWUSER    用户和用户组    3.8以上命名空间在容器环境下的隔离效果如下：UTS：每个容器能看到自己的 hostname，拥有独立的主机名和域名。IPC：同一个 IPC namespace 的进程之间能互相通讯，不同的IPC namespace 之间不能通信。PID：每个 PID namespace 中的进程可以有其独立的 PID，每个容器可以有其 PID 为进程。1 的 rootNetwork：每个容器用有其独立的网络设备，IP地址，IP路由表，/proc/net目录，端口号。Mount：每个容器能看到不同的文件系统层次结构。User：每个 container 可以有不同的 user 和 group id.想想以下如果我们要隔离两个进程需要怎么办?首先容器进程与进程之间需要隔离，所以需要 PID 隔离首先 容器 A 进程 不能读取 容器 B进程 通讯内容需要、隔离信号量等，所以需要 IPC 隔离首先 **容器 A 进程 **不能读取 容器 B进程 的文件，所以需要 Mount 隔离首先 **容器 A 进程 **不能读取 容器 B进程 的 socket，所以需要 网络隔离、主机隔离Docker 允许用户在主机和容器间共享文件夹，同时不需要限制容器的访问权限这就容易让容器突破资源限制。需要借助用户空间来完成用户之间的隔离。命令详解命令    功能    用途dd    复制文件并转换数据    创建镜像、测试性能、备份磁盘mkfs    创建文件系统    格式化新分区df    查看磁盘空间    查看挂载点使用情况mount    挂载文件系统    挂载 ISO、U盘、设备等unshare    创建隔离命名空间    容器底层调试、实验性隔离环境① dd 命令：用于读取、转换并输出数据，可以从标准输入或文件中读取数据，根据指定的格式转换数据，再输出到文件、设备或标准输出语法：dd OPTION ，参数如下：参数    描述if=文件名    输入文件名，默认为标准输入。即指定源文件。of=文件名    输出文件名，默认为标准输出。即指定目的文件。bs=bytes    同时设置读入/输出的块大小为 bytes 个字节，如果是ibs设置单次读入块大小, obs 设置单次输出块大小, cbs 设置转换块大小skip/seek=blocks    从 输入/输出 文件开头跳过 blocks 个块后再开始复制count=blocks    仅拷贝 blocks 个块，块大小等于 ibs 指定的字节数。conv=<关键字>，关键字有如下类型：conversion：用指定的参数转换文件ascii：转换 ebcdic 为 asciiebcdic：转换 asccii 为 ebcdicibm：转换 ascii 为 alternate ebcdicblock/unblock：把每一行转换为长度为 cbs，不足部分用空格lcase/ucase：交换输入的每对字节noerror：出错时不停止notrunc：不截断输出文件sync：将每个输入块填充到 ibs 个字节，不足部分用空（NULL）字符补齐案例# 生成镜像文件dd if=/dev/zero of=test.txt bs=8k count=1014# 大写转小写dd if=in.txt of=out.txt conv=ucase# 测试磁盘写入速度dd if=/dev/zero of=testfile bs=1G count=1 oflag=direct② mkfs 命令：在设备上创建指定类型的文件系统，即 “格式化”语法：mkfs [-V] [-t fstype] [fs-options] filesys [blocks] ，参数如下：参数    描述-t fstype    指定要建立何种文件系统；如 ext3，ext4。filesys    指定要创建的文件系统对应的设备文件名。blocks    指定文件系统的磁盘块数。-V    详细显示模式。fs-options    传递给具体文件系统的参数。案例# 格式化分区为 ext4 文件系统mkfs -t ext4 test.txtmke2fs 1.46.5 (30-Dec-2021)Discarding device blocks: done                            Creating filesystem with 20480 4k blocks and 20480 inodesAllocating group tables: done                            Writing inode tables: done                            Creating journal (1024 blocks): doneWriting superblocks and filesystem accounting information: done③ df 命令：用于显示目前在 Linux 系统上的文件系统磁盘使用情况统计。语法：dd OPTION ，参数如下：参数    描述-a, --all    包含所有的具有 0 Blocks 的文件系统。-h, --human-readable    使用人类可读的格式。-H, --si    很像 -h，但是用 1000 为单位而不是用 1024。-t, --type=TYPE    限制列出文件系统的类型。-T, --print-type    显示文件系统的形式。案例：lighthouse@VM-8-10-ubuntu:~$ df -hFilesystem      Size  Used Avail Use% Mounted ontmpfs           340M 1020K  339M   1% /run/dev/vda2        69G   22G   45G  33% /tmpfs           1.7G   24K  1.7G   1% /dev/shmtmpfs           5.0M     0  5.0M   0% /run/locktmpfs           340M  4.0K  340M   1% /run/user/1002tmpfs           340M  4.0K  340M   1% /run/user/1001④ mount 命令：用于加载文件系统到指定的加载点语法：mount [-l] mount [-t vfstype] [-o options] device dir常见参数如下：参数    描述-l    显示已加载的文件系统列表。-t vfstype    指定加载文件系统类型，支持常见的 ext3, ext4, iso9660, tmpfs, xfs 等。-o options    主要用来描述设备或档案的挂接方式。loop    用来把一个文件当成硬盘分区挂接上系统。ro    采用只读方式挂接设备。rw    采用读写方式挂接设备。device    要挂接（mount）的设备。dir    挂载点的目录。案例lighthouse@VM-8-10-ubuntu:test$ sudo mkdir /mymountlighthouse@VM-8-10-ubuntu:test$ sudo mount test.txt /mymountlighthouse@VM-8-10-ubuntu:test$ ll /mymount/total 24drwxr-xr-x  3 root root  4096 Jul  9 20:51 ./drwxr-xr-x 21 root root  4096 Jul  9 20:51 ../drwx------  2 root root 16384 Jul  9 20:47 lost+found/lighthouse@VM-8-10-ubuntu:test$ df -t ext4Filesystem     1K-blocks     Used Available Use% Mounted on/dev/vda2       72127952 22751700  46319384  33% //dev/loop4         72652       24     66896   1% /mymount# 取消挂载lighthouse@VM-8-10-ubuntu:test$ sudo umount /mymountlighthouse@VM-8-10-ubuntu:test$ df -t ext4Filesystem     1K-blocks     Used Available Use% Mounted on/dev/vda2       72127952 22751804  46319280  33% /⑤ unshare 命令：语法：dd OPTION ，参数如下：参数    描述-i, --ipc    不共享 IPC 空间。-m, --mount    不共享 Mount 空间。-n, --net    不共享 Net 空间。-p, --pid    不共享 PID 空间。-u, --uts    不共享 UTS 空间。-U, --user    不共享用户。-V, --version    版本查看。--fork    执行 unshare 的进程 fork 一个新的子进程，在子进程中执行 unshare 传入的参数。--mount-proc    执行子进程前，将 proc 优先挂载过去。案例：lighthouse@VM-8-10-ubuntu:test$ sudo unshare -u /bin/bashroot@VM-8-10-ubuntu:/home/lighthouse/code/test# hostname test1root@VM-8-10-ubuntu:/home/lighthouse/code/test# hostnametest1# 查看进程root@VM-8-10-ubuntu:/home/lighthouse/code/test# ps -ajx | grep bash1877172 1877180 1877180 1877180 pts/2    1886346 Ss    1001   0:00 -bash1877180 1886346 1886346 1877180 pts/2    1886346 S+       0   0:00 sudo unshare -u /bin/bash1886346 1886347 1886347 1886347 pts/1    1886575 Ss       0   0:00 sudo unshare -u /bin/bash1886347 1886348 1886348 1886347 pts/1    1886575 S        0   0:00 /bin/bash1886348 1886576 1886575 1886347 pts/1    1886575 S+       0   0:00 grep --color=auto bash# exit 退出进程, 发现之前的没有持久设置root@VM-8-10-ubuntu:/home/lighthouse/code/test# exitexitlighthouse@VM-8-10-ubuntu:test$ hostnameVM-8-10-ubuntu⚠️ 注意：unshare 是一个运行时命令，执行后会启动一个新的 shell 进程，该进程处于独立的命名空间中，但不会持久化 ，退出即失效。空间隔离实战① 进程隔离：unshare命令专门提供了一个参数--mount-proc，在新的namespace挂载一个独立的/proc目录，方便进行进程的监控。lighthouse@VM-8-10-ubuntu:test$ sudo unshare --fork --pid --mount-proc /bin/bashroot@VM-8-10-ubuntu:/home/lighthouse/code/test# ps -auxUSER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMANDroot           1  0.0  0.1   7636  4272 pts/1    S    21:00   0:00 /bin/bashroot           7  0.0  0.1  10336  3752 pts/1    R+   21:00   0:00 ps -aux可以看到，创建了新的 namespace后，ps -aux只能查到两个进程，一个是bash，一个是grep。这就将namespace内部的进程与宿主机的进程隔离开了。② 文件隔离 🎀 CGroup定义：cgroups(Control Groups) 是 linux 内核提供的一种机制，这种机制可以根据需求把系列系统任务及其子任务整合(或分隔)到按资源划分等级的不同组内，从而为系统资源管理提供一个统一的框架。作用：限制CPU、内存、网络等所使用的物理资源。具体实现：本质上来说，cgroups 是内核附加在程序上的一系列钩子(hook)，通过程序运行时对资源的调度触发相应的钩子以达到资源追踪和限制的目的。用途如下：Resource limitation：限制资源使用，例:内存使用上限/cpu 的使用限制Prioritization：优先级控制，例:CPU 利用/磁盘 IO 吞吐Accounting：一些审计或一些统计Control：挂起进程/恢复执行进程相关命令① pidstat：用于检测一个进程的 CPU、内存、IO、线程等资源的占用情况。sudo apt install sysstat # 安装pidstat [option] [时间间隔] [次数] # 语法一键获取完整项目代码bash12选项：-u：检测 CPU 使用情况（默认）-r：检测内存使用情况-d：检测 IO 使用情况-p：指定进程 PID，如果指定 ALL 则监视所有进程-C：检测通过指定命令启动的进程示例：默认输出：pidstat 会输出所有进程的 CPU 占用情况。指定进程：pidstat -p 1234 检测 PID 为 1234 的进程。指定命令：pidstat -C bash 检测通过 bash 命令启动的进程。检测内存：pidstat -r 检测内存占用情况。指定检测次数与频率：pidstat 1 3 每隔一秒检测一次，共检测三次。简单测试：lighthouse@VM-8-10-ubuntu:test$ pidstat -C bashLinux 5.15.0-126-generic (VM-8-10-ubuntu)     07/09/2025     _x86_64_    (2 CPU)09:19:13 PM   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command09:19:13 PM  1001   1877180    0.00    0.00    0.00    0.00    0.00     0  bashlighthouse@VM-8-10-ubuntu:test$ pidstat -rLinux 5.15.0-126-generic (VM-8-10-ubuntu)     07/09/2025     _x86_64_    (2 CPU)09:19:20 PM   UID       PID  minflt/s  majflt/s     VSZ     RSS   %MEM  Command09:19:20 PM     0         1      0.09      0.00  184012   10948   0.31  systemd09:19:20 PM     0       366      0.00      0.83  179024   81516   2.34  systemd-journal09:19:20 PM     0       410      0.00      0.00  289312   27096   0.78  multipathd09:19:20 PM     0       412      0.00      0.00   12120    5012   0.14  systemd-udevd09:19:20 PM   101       828      0.00      0.00   16128    1608   0.05  systemd-network09:19:20 PM     0       843      0.00      0.00    2816    1104   0.03  acpid09:19:20 PM   103       848      0.00      0.00    8876    4008   0.12  dbus-daemon09:19:20 PM     0       864      0.00      0.00  234504    4472   0.13  polkitd② stress：一个压力测试工具，可以对 CPU、内存、IO 等进行压力测试。sudo apt install stress # 安装stress [option]        # 语法 参数：-c --cpu N：产生 N 个进程，每个进程都循环调用 sqrt 函数产生 CPU 压力。-m --vm N：产生 N 个进程，每个进程都循环调用 malloc 和 free 函数，产生内存压力。示例：stress -c 1 创建一个进程进行 CPU 压力测试。 左侧使用stress创建了一个进程进行CPU压力输出右侧检测stress产生的压力结果一个进程占满了100%的CPU资源资源控制实战① 信息查看cgroups 版本查看lighthouse@VM-8-10-ubuntu:~$ cat /etc/*release*    # 查看当前系统版本DISTRIB_ID=UbuntuDISTRIB_RELEASE=22.04DISTRIB_CODENAME=jammyDISTRIB_DESCRIPTION="Ubuntu 22.04 LTS"PRETTY_NAME="Ubuntu 22.04 LTS"NAME="Ubuntu"VERSION_ID="22.04"VERSION="22.04 (Jammy Jellyfish)"VERSION_CODENAME=jammyID=ubuntuID_LIKE=debianHOME_URL="https://www.ubuntu.com/"SUPPORT_URL="https://help.ubuntu.com/"BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"UBUNTU_CODENAME=jammylighthouse@VM-8-10-ubuntu:~$ cat /proc/filesystems |grep cgnodev    cgroupnodev    cgroup2    # 可以支持两个版本 cgroupcgroups 子系统查看lighthouse@VM-8-10-ubuntu:test$ cat /proc/cgroups#subsys_name    hierarchy    num_cgroups    enabledcpuset    0    109    1cpu    0    109    1cpuacct    0    109    1blkio    0    109    1memory    0    109    1devices    0    109    1freezer    0    109    1net_cls    0    109    1perf_event    0    109    1net_prio    0    109    1hugetlb    0    109    1pids    0    109    1rdma    0    109    1misc    0    109    1查看挂载信息：这里是每一个资源的控制目录，比如在 /sys/fs/cgroup/cpu 目录下，就是控制CPU资源的配置文件lighthouse@VM-8-10-ubuntu:~$ mount | grep cgroupcgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)查看一个进程上的 cgroup 限制lighthouse@VM-8-10-ubuntu:~$ cat /proc/$$/cgroup0::/user.slice/user-1001.slice/session-83590.scope    # 层级编号:挂载的子系统:路径② 内存控制创建内存控制组cd /sys/fs/cgroup/memorymkdir test_memory设置最大内存echo "20971520" > test_memory/memory.limit_in_bytes将进程加入控制组stress -m 1 --vm-bytes 50m    # 每个进程占用 50Mpidstat -recho "15070" > test_memory/tasks3③ CPU 控制创建 CPU 控制组cd /sys/fs/cgroup/cpumkdir test_cpu设置 CPU 占用率echo "5000" > test_cpu/cpu.cfs_period_usecho "2000" > test_cpu/cpu.cfs_quota_us一键获取完整项目代码bash12将进程加入控制组stress -c 1pidstat -uecho "60769" > test_cpu/tasks一键获取完整项目代码bash123三：🔥 容器虚拟化基础之 LXC🦋 LXC 是什么？LXC（LinuX Containers）是一种操作系统层虚拟化技术，为 Linux 内核容器功能的一个用户空间接口。它将应用软件系统打包成一个软件容器（Container），内含应用软件本身的代码，以及所需要的操作系统核心和库。透过统一的名字空间和共享 API 来分配不同软件容器的可用硬件资源，创造出应用程序的独立沙箱运行环境，使得 Linux 用户可以容易地创建和管理系统或应用容器。尽管 LXC 极大地简化了容器技术的使用，但比起直接通过内核调用来使用容器技术，其复杂程度其实并没有多大降低，因为我们必须要学会 LXC 的一组命令工具，且由于内核的创建都是通过命令来实现的，通过批量命令实现数据迁移并不容易。其隔离性也没有虚拟机那么强大。后来就出现了 Docker，所以从一定程度上来说，Docker 就是 LXC 的增强版。🦋 LXC 容器操作Ubuntu 上安装 LXC，如下:检查及卸载（如需）systemctl status lxclxc-stop -n xxx # 停止所有运行的容器lxc-destroy -n xxx # 删除所有容器apt-get purge --auto-remove lxc lxc-templatessystemctl status lxc # 确保服务已卸载安装 LXCsudo apt install lxc lxc-templates bridge-utils -ysystemctl status lxc # 检查服务是否正常一键获取完整项目代码bash123LXC的常用命令说明如下：① 检查系统支持性：lxc-checkconfig② 创建指定模板容器：lxc-create -n NAME -t TEMPLATE_NAME [--template-options]③ 启动容器：lxc-start -n NAME -d④ 列出容器：lxc-ls -f（-f 参数显示容器得详细信息）⑤ 查看容器信息：lxc-info -n NAME⑥ 进入容器：lxc-attach --name=NAME [--COMMAND]⑦ 停止容器：lxc-stop -n NAME⑧ 删除容器：lxc-destroy -n NAME实战如下：# 1. 检查运行状态root@VM-8-10-ubuntu:~$ systemctl status lxc● lxc.service - LXC Container Initialization and Autoboot Code     Loaded: loaded (/lib/systemd/system/lxc.service; enabled; vendor preset: enabled)     Active: active (exited) since Fri 2025-07-11 15:28:38 CST; 3min 34s ago       Docs: man:lxc-autostart             man:lxc    Process: 2423230 ExecStartPre=/usr/lib/x86_64-linux-gnu/lxc/lxc-apparmor-load (code=exited, status=0/SUCCESS)    Process: 2423235 ExecStart=/usr/lib/x86_64-linux-gnu/lxc/lxc-containers start (code=exited, status=0/SUCCESS)   Main PID: 2423235 (code=exited, status=0/SUCCESS)        CPU: 24ms# 2. 查看可用模板root@VM-8-10-ubuntu:/home/lighthouse# ls /usr/share/lxc/templates/lxc-alpine     lxc-centos    lxc-fedora         lxc-oci           lxc-plamo      lxc-sparclinux    lxc-voidlinuxlxc-altlinux   lxc-cirros    lxc-fedora-legacy  lxc-openmandriva  lxc-pld        lxc-sshdlxc-archlinux  lxc-debian    lxc-gentoo         lxc-opensuse      lxc-sabayon    lxc-ubuntulxc-busybox    lxc-download  lxc-local          lxc-oracle        lxc-slackware  lxc-ubuntu-cloud# 3. 创建容器 -n 容器的名称 -t 模版    -r release版本 -a cpu架构lxc-create -n lxchost1 -t ubuntu -- -r xenial -a amd64 # Ubuntu上创建Ubuntu容器lxc-create -n centos7 --template=download -- --dist=centos --release=7 --arch=amd64 # Ubuntu上创建CentOS容器# 4. 查看创建结果root@VM-8-10-ubuntu:/home/lighthouse# lxc-ls -fNAME     STATE   AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED lxchost1 STOPPED 0         -      -    -    false      # 5. 启动容器root@VM-8-10-ubuntu:/home/lighthouse# lxc-start -n lxchost1 -droot@VM-8-10-ubuntu:/home/lighthouse# lxc-info -n lxchost1Name:           lxchost1State:          RUNNINGPID:            2455869Link:           vethNx0mnE TX bytes:      726 bytes RX bytes:      1.41 KiB Total bytes:   2.12 KiB# 6. 使用 ssh 进入容器root@VM-8-10-ubuntu:/home/lighthouse# ssh ubuntu@ipAre you sure you want to continue connecting (yes/no/[fingerprint])? yesubuntu@1.12.51.69's password: # 密码是当前 系统密码# 7. 在容器中执行常用命令ip addr # 查看网络信息df -h # 查看磁盘挂载情况ps -ef # 查看进程信息ubuntu@VM-8-10-ubuntu:~$ df -hFilesystem      Size  Used Avail Use% Mounted ontmpfs           340M  1.1M  339M   1% /run/dev/vda2        69G   23G   44G  35% /tmpfs           1.7G   24K  1.7G   1% /dev/shmtmpfs           5.0M     0  5.0M   0% /run/locktmpfs           340M  4.0K  340M   1% /run/user/1002tmpfs           340M  4.0K  340M   1% /run/user/1001tmpfs           1.7G     0  1.7G   0% /run/qemutmpfs           340M  4.0K  340M   1% /run/user/1000# 8. 从宿主机向容器中发送命令root@VM-8-10-ubuntu:/home/lighthouse# lxc-attach -n lxchost1 --clear-env -- echo "Hello LXC"Hello LXC# 9. 停止 & 删除容器root@VM-8-10-ubuntu:/home/lighthouse# lxc-stop -n lxchost1  root@VM-8-10-ubuntu:/home/lighthouse# lxc-destroy -n lxchost1通过LXC学习容器的创建与管理，体会容器化技术的基本原理。了解Docker不是唯一的容器实现方式，Docker在0.9版本起引入了自家的 libcontainer，而如今大部分Docker使用的都是libcontainer而非LXC。四：🔥 共勉😋 以上就是我对 【Docker#2】容器化虚拟化 的理解, 觉得这篇博客对你有帮助的，可以点赞收藏关注支持一波~ 😉————————————————版权声明：本文为CSDN博主「Zfox_」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/weixin_50776420/article/details/157184498

一、什么是 Docker Registry镜像仓库 (Docker Registry) 负责存储、管理和分发镜像，并且提供了登录认证能力，建立了仓库的索引。镜像仓库管理多个 Repository， Repository 通过命名来区分。每个 Repository 包含一个或多个镜像，镜像通过镜像名称和标签 (Tag)来区分。 1.镜像仓库(Registry):要从哪一个镜像仓库拉取镜像，通常通过 DNS 或 IP 地址来确定一个镜像仓库如 hub.docker.com;一个 Registry 中可以存在多个Repository·Repository可分为“顶层仓库”和“用户仓库”;·用户仓库名称格式为“用户名/仓库名”·每个仓库可以包含多个 Tag(标签)，每个标签对应一个镜像2.Repository: ·由某特定的 docker 镜像的所有迭代版本组成的镜像仓库3.镜像名称（name）+标签(tag):如 nginx:latest4.认证能力：提供用户注册，登录、登出能力5.索引：提供镜像的索引信息，方便检索一个容器镜像包含了两个部分，一个是元数据，其实就是由 dockerfile 构建出来的描述文件，这个描述文件会说这个容器镜像有多少层，每一层里面有什么内容，它的checksum 这些信息都会记录下来，还有最终的可执行文件在哪就是在存储数据里面，就是在一个一个的 blob 里面，真正占有空间的就是这些 blob。镜像仓库生活案例大家可以类比超市，一个 Repository 就是一个货架，白象就是组织者，货架上放的产品打的不同标签就是对应的 tag 二、镜像仓库分类按是否对外开放划分，也是研发人员常说的：（1）公有仓库：像阿里云、dockerhub 等放到公有网络上，不用登录就可以下载镜像，供大家访问使用（2）私有仓库：不对外开放，往往位于私有网络，只有公司内部人员可以使用。按供应商和面向群体划分：(1)sponsor（赞助） registry：第三方的 registry，供客户和 docker 社区版使用(2)mirror(镜像） registry：第三方的 registry，只让客户使用，例如阿里云必须注册才能使用(3)vendor(供应商) registry：由发布 docker 镜像的供应商提供的 registry，例如像Google 和 Redhat 提供了镜像仓库服务(4)private registry：通过没有防火墙和额外的安全层的私有实体提供的 registry，仅供内部使用三、镜像仓库工作机制1. 镜像仓库使用流程（1）通过 docker login 登录仓库（2）Docker pull 拉取需要的镜像（3）通过 dockerfile 或者 commit 等方式制作完镜像通过 docker push 上传到仓库2. 实际研发中镜像仓库如何使用Docker Registry 中的镜像通常由开发人员制作，而后推送至“公共”或“私有”Registry 上保存，供其他人员使用，例如“部署”到生产环境;名词解释：开发环境：开发人员使用的一套环境测试环境：需求开发完成后，发布到供测试人员进行测试的环境预发布环境：版本测试完成后，发布到和生产类似的环境，提前模拟生产发布生产环境：真正面向客户的环境3. 镜像仓库的拉取机制启动容器时，docker daemon 会试图从本地获取相关的镜像;本地镜像不存在时，其将从 Registry 中下载该镜像并保存到本地;四、常用的镜像仓库1.DockerHubDocker Hub 是什么？Docker Hub 是 Docker 提供的托管存储库服务，用于查找容器映像并与您的团队共享。具有以下功能：（1）个人可以注册私有仓库，能够发布自己的镜像（2）提供镜像检索能力（3）提供海量官方和认证组织的镜像（4）从 GitHub 和 Bitbucket 自动构建容器镜像并将它们推送到 Docker Hub（5）支持 webhook（webhook 是一种基于 HTTP 的回调函数,发生指定的事件时，服务器会自动将相关的有效负载发送到客户端的 webhook URL。 ）Docker Hub 功能浏览：镜像 tag 查找:版本拉取命令、镜像对应版本：2. 国内镜像源国内从 Docker Hub 拉取镜像有时会遇到困难，此时可以配置镜像加速器。国内很多云服务商都提供了国内镜像加速器服务，例如阿里云加速器(点击管理控制台 -> 登录账号(淘宝账号) -> 右侧镜像工具 -> 镜像加速器-> 复制加速器地址)网易云加速器地址 https://hub-mirror.c.163.com百度云加速器地址 https://mirror.baidubce.com可以在 /etc/docker/daemon.json 中写入如下内容（如果文件不存在请新建该文件）：{# 注意如果最外层以及你给有了配置，不要直接覆盖，而是将下面的内容添加，然后确保 json 的格式正确 "registry-mirrors": [   "https://hub-mirror.c.163.com",   "https://mirror.baidubce.com" ]}添加完成后需要重新加载配置，重启 Docker：# 加载配置sudo systemctl daemon-reload # 重启 dockersudo systemctl restart docker #查看 docker 状态sudo systemctl status docker3. 私有仓库私有镜像仓库则是指部署在公司或组织内部，用于自身应用 Docker 镜像存储、分发的镜像仓库。在构建公司内部使用的自动化发布系统的过程中，从安全的角度出发，应用的打包镜像一般情况下只会被存储在私有镜像仓库中，CI/CD 流程的衔接点也是通过向私有镜像仓库上传镜像和拉取镜像的操作来完成的。常见的私有仓库工具：1.Harbor:Harbor 是 VMware 公司最近开源的企业级 Docker Registry 项目,其目标是帮助用户迅速搭建一个企业级的 Docker registry 服务。它以 Docker 公司开源的registry为基础，提供了管理 UI, 基于角色的访问控制(Role Based Access Control)，AD/LDAP集成、以及审计日志(Audit logging) 等企业用户需求的功能，同时还原生支持中文。Harbor 的每个组件都是以 Docker容器的形式构建的，使用 Docker Compose 来对它进行部署。 .2. Nexus:Nexus 是 Sonatype公司发布的一款仓库（Repository）管理软件,目前常被用来作为 Maven 私服、Docker 私服。(3.) Docker registry:由 docker 官方提供的私服，类似于 docker hub。用于保存公司内部上传的 Docker 镜像。五、镜像仓库命令1.docker login功能：登陆到一个 Docker 镜像仓库，如果未指定镜像仓库地址，默认为官方仓库 Docker Hub。语法：docker login [OPTIONS] [SERVER]AI写代码powershell1关键参数-u :登陆的用户名-p :登陆的密码样例：docker login -u 用户名 -p 密码AI写代码powershell12.docker pull（1）.功能从镜像仓库中拉取或者更新指定镜像（2）.语法docker pull [OPTIONS] NAME[:TAG|@DIGEST]AI写代码powershell1（3）.别名docker image pullAI写代码powershell1（4）.关键参数-a :拉取所有 tagged 镜像–disable-content-trust :忽略镜像的校验,默认开启（5）.样例docker pull nginx:1.23.3AI写代码powershell13. docker push（1）功能将本地的镜像上传到镜像仓库,要先登陆到镜像仓库（2）语法docker push [OPTIONS] NAME[:TAG]AI写代码powershell1（3）别名docker image pushAI写代码powershell1（4）关键参数-a :推送所有 tagged 镜像–disable-content-trust :忽略镜像的校验,默认开启docker push myapache:v1AI写代码powershell14.docker search（1）功能从 Docker Hub 查找镜像，因 docker 网站被封，该命令暂时国内无法实操，需要国外网络联系。（2）语法docker search [OPTIONS] TERMAI写代码powershell1（3）关键参数–no-trunc :显示完整的镜像描述；-f <过滤条件>:列出收藏数不小于指定值的镜像（4）样例#从 Docker Hub 查找所有镜像名包含 nginx，并且 star 数大于 10 的镜像docker search -f stars=10 nginxAI写代码powershell125.docker logout(1)功能登出一个 Docker 镜像仓库，如果未指定镜像仓库地址，默认为官方仓库 Docker Hub,（2）语法docker logout [SERVER]AI写代码powershell1（3）样例docker logoutAI写代码powershell1六、镜像命令学习仓库前我们需要提前了解一部分的镜像命令1.docker images（1）功能列出本地镜像。（2）语法docker images [OPTIONS] [REPOSITORY[:TAG]]（3）别名docker image ls, docker image listAI写代码powershell1（4）关键参数￮ -a :列出本地所有的镜像（含中间映像层，默认情况下，过滤掉中间映像层）；￮ --digests :显示镜像的摘要信息；￮ -f :显示满足条件的镜像；￮ --format :指定返回值的模板文件；￮ --no-trunc :显示完整的镜像信息；￮ -q :只显示镜像 ID。(5) 样例#列出本地全部镜像docker images#列出本地镜像中 REPOSITORY 为 ubuntu 的镜像列表。docker images ubuntu`在这里插入代码片`2. docker image inspect(1) 功能查看镜像详细信息(2) 语法docker image inspect [OPTIONS] IMAGE [IMAGE...]AI写代码powershell1• 样例docker images inspect nginx:1.23.3AI写代码powershell13. docker tag（1） 功能标记本地镜像，将其归入某一仓库。（2）语法docker tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]AI写代码powershell1（3） 别名docker image tagAI写代码powershell1（4） 样例docker tag ubuntu:22.04 myregistry.com/myubuntu:22.04七、容器命令学习仓库前我们需要提前了解一部分的容器命令1.docker run（1） 功能创建一个新的容器并运行一个命令（2）语法docker run [OPTIONS] IMAGE [COMMAND] [ARG...]（3） 别名docker container run（4）关键参数￮ -d: 后台运行容器，并返回容器 ID；￮ -i: 以交互模式运行容器，通常与 -t 同时使用；￮ -P: 随机端口映射，容器内部端口随机映射到主机的端口￮ -p: 指定端口映射，格式为：主机(宿主)端口:容器端口￮ -t: 为容器重新分配一个伪输入终端，通常与 -i 同时使用；￮ --name=“nginx-lb”: 为容器指定一个名称；￮ -h “mars”: 指定容器的 hostname；￮ -e username=“ritchie”: 设置环境变量；￮ --cpuset-cpus=“0-2” or --cpuset-cpus=“0,1,2”: 绑定容器到指定 CPU 运行；￮ -m :设置容器使用内存最大值；￮ --network=“bridge”: 指定容器的网络连接类型；￮ --link=[]: 添加链接到另一个容器；￮ --volume , -v: 绑定一个卷￮ --rm :shell 退出的时候自动删除容器（5）样例#使用 docker 镜像 nginx:latest 以后台模式启动一个容器,并将容器命名为mynginx。docker run --name mynginx -d nginx:latest#使用镜像 nginx:latest，以后台模式启动一个容器,将容器的 80 端口映射到主机的 80 端口,主机的目录 /data 映射到容器的 /data。docker run -p 80:80 -v /data:/data -d nginx:latest2. docker ps（1） 功能列出容器（2） 语法docker ps [OPTIONS]AI写代码powershell1(3)别名docker container ls, docker container list, docker container psAI写代码powershell1（4）关键参数￮ -a :显示所有的容器，包括未运行的。￮ -f :根据条件过滤显示的内容。￮ --format :指定返回值的模板文件。如 json 或者 table￮ -l :显示 latest 的容器。￮ -n :列出最近创建的 n 个容器。￮ --no-trunc :不截断输出。￮ -q :静默模式，只显示容器编号。￮ -s :显示总的文件大小。（5） 样例docker ps -aAI写代码powershell1总结以上就是本文全部内容，主要介绍了docker中的镜像仓库，还介绍了镜像仓库，镜像和容器相关基础的命令。感谢各位能够看到最后，如有问题，欢迎各位大佬在评论区指正，希望大家可以有所收获！创作不易，希望大家多多支持！————————————————版权声明：本文为CSDN博主「努力也学不会Java.」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/2403_87459748/article/details/155466679

 数据丢失的核心原因是 数据卷挂载配置错误（路径不对、权限不足、挂载类型误用），Docker 环境下 PostgreSQL 的数据持久化完全依赖正确的卷挂载 ——PostgreSQL 容器的默认数据存储目录是 /var/lib/postgresql/data，如果挂载时路径不匹配、宿主机目录无写入权限，数据会默认存到容器的 “临时存储层”，容器重启后就会丢失。一、先排查：你的数据卷挂载到底错在哪？1. 最常见错误：挂载路径不匹配（没对准容器内默认数据目录）PostgreSQL 容器的 数据必须存储在 /var/lib/postgresql/data 目录下（这是官方镜像的固定路径，改不了）。如果你的启动命令里挂载路径写错了（比如多写一层目录、少写路径），数据根本没写到宿主机卷里。常见小错误（路径错误）： # 错误1：挂载到 /var/lib/postgresql（少了 /data 后缀）docker run -d -v pgdata:/var/lib/postgresql postgres:15# 错误2：自定义容器内路径（比如 /data），但PostgreSQL不往这写docker run -d -v /宿主机路径:/data postgres:15# 错误3：绑定挂载时宿主机路径拼写错误（比如 /home/user/pgdata 写成 /home/user/pgdat）docker run -d -v /home/user/pgdat:/var/lib/postgresql/data postgres:15 正确示例（路径必须对准 /var/lib/postgresql/data）： # 命名卷（推荐，Docker自动管理路径和权限）docker run -d -v pgdata:/var/lib/postgresql/data postgres:15# 绑定挂载（宿主机路径自定义，需确保权限）docker run -d -v /home/user/pgdata:/var/lib/postgresql/data postgres:15 2. 第二常见：宿主机目录权限不足（容器内用户写不进去）PostgreSQL 容器内默认使用 postgres 用户（UID=999，GID=999）运行，如果是 绑定挂载（直接挂载宿主机目录），宿主机目录的属主 / 权限不对，postgres 用户无法写入数据，会自动降级为 “临时存储”（重启丢失）。错误场景：宿主机创建了 /home/user/pgdata 目录，但默认属主是 root，权限是 755（只有 root 能写），容器内 postgres 用户没权限写入，只能用临时存储。修复方法（绑定挂载时）：  # 1. 先给宿主机目录设置正确权限（让 UID=999 能写入）sudo chown -R 999:999 /home/user/pgdatasudo chmod -R 700 /home/user/pgdata # PostgreSQL要求数据目录权限为700（仅所有者可读写）# 2. 再启动容器（路径正确+权限正确）docker run -d -v /home/user/pgdata:/var/lib/postgresql/data postgres:15 3. 其他的小错误：误用 “匿名卷” 或 “临时存储”匿名卷：启动命令里只写 -v /var/lib/postgresql/data（没指定宿主机路径或卷名），Docker 会创建随机命名的匿名卷，容器删除后匿名卷可能被清理（重启容器不删，但手动删容器时容易丢）；临时存储：如果启动时没加任何 -v 挂载，数据直接存在容器的 “可写层”，容器重启 / 重建后 100% 丢失。二、Docker 部署 PostgreSQL 的正确流程（确保数据不丢）推荐用 命名卷（Docker 自动管理路径、权限，避免手动配置错误）1. 提前创建命名卷（也可启动时自动创建） # 创建名为 pgdata 的命名卷（Docker会把数据存在 /var/lib/docker/volumes/pgdata 下）docker volume create pgdata 2. 启动容器（核心：正确的去挂载卷 + 设置必要环境变量）docker run -d \ --name postgres-db \ -p 5432:5432 \ # 端口映射（宿主机:容器） -v pgdata:/var/lib/postgresql/data \ # 命名卷挂载（关键） -e POSTGRES_USER=myuser \ # 自定义数据库用户（避免用默认postgres） -e POSTGRES_PASSWORD=mypassword \ # 自定义密码（必须设置，否则容器启动失败） -e POSTGRES_DB=mydb \ # 初始化时创建的数据库（可选） -e PGDATA=/var/lib/postgresql/data/pgdata \ # 可选：指定数据子目录（避免和配置文件混放） --restart=always \ # 容器异常退出时自动重启 postgres:15 # 指定具体版本（不要用latest，避免版本迭代问题） 3. 验证数据持久化（确保重启后不丢） # 1. 进入容器，创建测试数据docker exec -it postgres-db psql -U myuser -d mydb# 执行SQL创建表并插入数据CREATE TABLE test (id int);INSERT INTO test VALUES (1);SELECT * FROM test; # 确认能查到数据，退出容器（ctrl+d）# 2. 重启容器docker restart postgres-db# 3. 再次进入容器，验证数据是否存在docker exec -it postgres-db psql -U myuser -d mydbSELECT * FROM test; # 能查到 (1) 说明持久化成功 三、Docker 环境使用 PostgreSQL 的关键注意事项1. 数据卷相关（重中之重）优先用 命名卷：避免绑定挂载的权限、路径问题，Docker 会自动维护卷的生命周期（容器删除后卷不会删，数据保留）；绑定挂载需注意：宿主机目录必须提前创建并设置 999:999 属主（容器内 postgres 用户的 UID/GID），权限设为 700（PostgreSQL 安全要求，禁止其他用户访问数据目录）；不要修改容器内默认数据目录：官方镜像的 /var/lib/postgresql/data 是固定路径，修改 PGDATA 环境变量时需确保挂载路径同步（比如 PGDATA=/var/lib/postgresql/data/pgdata，挂载路径仍为 /var/lib/postgresql/data）。2. 配置与权限必须设置密码：PostgreSQL 官方镜像从 10 版本后，必须通过 POSTGRES_PASSWORD 环境变量设置密码，否则容器启动失败；避免硬编码密码：生产环境不要直接在命令行写密码，可用 --env-file 加载环境变量文件（比如 docker run --env-file .env ...，.env 文件里写 POSTGRES_PASSWORD=mypassword）；挂载配置文件：如果需要修改 postgresql.conf（比如调整内存、连接数），可将宿主机的配置文件挂载到 /var/lib/postgresql/data/postgresql.conf（命名卷中会自动生成默认配置，可先拷贝出来修改再挂载）： # 先拷贝容器内默认配置到宿主机docker cp postgres-db:/var/lib/postgresql/data/postgresql.conf /home/user/pgconf/# 修改后重新挂载配置文件docker run -d -v pgdata:/var/lib/postgresql/data -v /home/user/pgconf/postgresql.conf:/var/lib/postgresql/data/postgresql.conf ...  3. 容器管理禁止用 docker rm -v 删除容器：-v 参数会同时删除挂载的卷（包括命名卷），导致数据丢失；定期备份数据卷：即使挂载了卷，也要定期备份（比如用 docker run --rm -v pgdata:/source -v /宿主机备份路径:/dest alpine tar -czf /dest/pgbackup.tar.gz -C /source .）；指定具体镜像版本：不要用 postgres:latest，避免容器重建时自动升级版本（可能出现兼容性问题），比如固定 postgres:15.6。4. 网络与端口避免暴露 5432 端口到公网：默认 -p 5432:5432 会把端口暴露到公网，容易被暴力破解，生产环境可改为内网访问（比如 -p 127.0.0.1:5432:5432，仅允许宿主机访问），或用 Docker 自定义网络隔离；容器间通信：如果其他容器需要访问 PostgreSQL，建议创建 Docker 网络（docker network create pg-network），启动时加入网络（--network pg-network），通过容器名（比如 postgres-db）访问，无需暴露端口。5. 资源限制限制 CPU / 内存：避免 PostgreSQL 容器占用过多宿主机资源，可通过 --cpus 和 --memory 限制（比如 --cpus 2 --memory 4g，限制 2 核 CPU、4G 内存）；磁盘空间监控：命名卷默认存在 /var/lib/docker/volumes/ 下，需监控宿主机磁盘空间，避免数据量增长导致磁盘满。四、如果数据已经丢失，怎么去救救数据呢？如果容器还没删除，可尝试从容器的 “临时存储层” 抢救数据： # 1. 查看容器是否还存在（即使已停止）docker ps -a | grep postgres-db# 2. 用新容器挂载原容器的存储层，拷贝数据docker run --rm -v /宿主机临时路径:/backup alpine \ cp -r /var/lib/docker/containers/[原容器ID]/mounts/secrets/ /backup/# （注：如果原容器已删除，临时存储层会被清理，无法恢复，只能依赖之前的备份） 总结一下下数据丢失的核心是 挂载路径不对 或 权限不足，记住：PostgreSQL 容器必须挂载 /var/lib/postgresql/data 目录；推荐用 命名卷 部署，避免手动配置权限和路径的麻烦；生产环境务必做好 定期备份 和 权限隔离，不要暴露端口到公网，指定固定镜像版本。

概念简述核心定义   Docker Compose 是一个用于定义和运行多容器 Docker 应用程序的工具。它允许您使用一个单独的配置文件（通常是 .yml 格式）来配置应用程序的所有服务、网络和卷，然后通过一条简单的命令就能创建和启动所有服务。可以把它想象成一个自动化脚本或编排工具，专门用于在单台主机上部署由多个容器组成的应用。 为什么要使用 Docker Compose？解决什么问题？ 在理解 Compose 之前，先想想如果不用它，会多麻烦：假设应用由以下服务组成：Web 应用、Redis 缓存服务、MySQL 数据库服务，如果没有 Docker Compose，你需要手动完成以下步骤： 创建一个 Docker 网络让容器可以通信。单独启动 MySQL 容器，并指定网络、卷、环境变量等。单独启动 Redis 容器，并指定网络、环境变量等。构建你的 Web 应用的镜像。启动 Web 应用容器，并链接到之前创建的网络，设置环境变量指向 Redis 和 PostgreSQL 的容器名。你需要记住并输入一大堆 docker run 命令，这个过程非常繁琐且容易出错。 Docker Compose 解决了这个问题： 简化流程：用一个文件（docker-compose.yml）描述整个应用栈的架构。一键操作：通过一条命令（docker compose up）就能同时创建、启动所有服务，并处理好它们之间的依赖关系。配置即代码：将你的应用基础设施（服务、网络、存储）用配置文件管理起来，可以纳入版本控制系统，方便协作和追溯。核心概念与工作流程 定义 docker-compose.yml 文件：这是 Docker Compose 的核心。你在这个 YAML 文件中定义你的应用所需的服务、网络和卷。 服务：对应一个容器。你可以指定使用哪个镜像、暴露哪些端口、挂载哪些卷、设置哪些环境变量、依赖哪些其他服务等。网络：定义容器之间通信的网络。卷：定义持久化数据存储的位置。执行 docker compose up 命令：在包含 docker-compose.yml 文件的目录下运行此命令。Compose 会： 自动构建或拉取所需的镜像。按依赖顺序创建并启动所有定义的服务。将所有服务的日志输出聚合到一个流中，方便查看。执行 docker compose down 命令：当你想要停止并清理整个应用时，运行此命令。它会停止所有容器，并删除创建的容器和网络（默认情况下不删除卷）。 总结：Docker Compose 的优点 隔离环境：整个应用栈与主机环境完全隔离。极简配置：一个命令替代了大量复杂的 docker run 命令。快速部署：极大地简化了多容器应用的部署和测试流程，是开发、测试和 CI/CD 环境的理想选择。服务发现：自动在服务之间创建网络，并通过服务名进行DNS解析，使容器间通信变得非常简单。注意：Docker Compose 通常用于开发、测试和单机部署。对于生产环境中跨多台主机的集群管理和编排，更强大的工具如 Kubernetes 或 Docker Swarm 更为合适。不过，Compose 文件可以作为学习这些更复杂工具的基础。 配置文件格式version：指定Docker Compose文件的版本格式，不同版本支持的功能和语法有所不同，高版本兼容低版本services: 服务，可以存在多个 servicename: 服务名字，它也是内部bridge网络可以使用的DNS name，如果不是集群模式相当于docker run的时候指定的一个名称，集群（Swarm）模式是多个容器的逻辑抽象  image: 镜像的名字（必选）  command: 如果设置，则会覆盖默认镜像里的CMD命令  environment: 等价于docker container run里的–env选项，设置环境变量  volumes: 等价于docker container run里的-v选项，绑定数据卷  networks: 等价于docker container run里的–network选项，指定网络  ports: 等价于docker container run里的-p选项，指定端口映射  expose: 可选，指定容器暴露的端口  build: 构建目录  depends_on: 服务依赖配置  env_file: 环境变量文件 servicename2:  image:  command:  networks:  ports: servicename3:#…volumes: # 可选，等价于 docker volume createnetworks: # 可选，等价于 docker network create 参数详解准备这样一个目录结构： mycompose/├── prj1│   └── docker-compose.yml├── prj2│   └── docker-compose.yml└── prj3    └── docker-compose.yml...... image功能：指定容器镜像示例： 创建prj1目录：mkdir prj1在prj1中创建文件docker-compose.ymlcd prj1touch docker-compose.yml编辑docker-compose文件vim docker-compose.yml services:     web:      image: nginx:1.24.0 启动配置docker compose up清除容器docker compose down  接下来就不再详细展示每个步骤，重点讲解第3步文件的配置。command功能：覆盖容器启动的默认指令格式： command: ["bundle", "exec", "thin", "-p", "3000"]//或command: bundle exec thin -p 3000 示例： serveices:  web:    image: nginx:1.24.0    command: bundle exec thin -p 3000 这些内容都写在配置文件docker-compose.yml里面 entrypoint功能：覆盖容器默认的 entrypoint。格式： entrypoint: /code/entrypoint.sh 也可以是列表格式： entrypoint:  - php  - -d  - zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20100525/xdebug.so  - -d  - memory_limit=-1  - vendor/bin/phpunit 示例： services:  web:    image: nginx:1.24.0    entrypoint:      - tail      - -f      - /etc/os-release environmentenvironment功能：  添加环境变量。您可以使用数组或字典、任何布尔值，布尔值需要用引号引起来，以确保 YML 解析器不会将其转换为 True 或 False。格式： # map 格式environment:  RACK_ENV: development  SHOW: "true"  USER_INPUT: # 数组格式environment:  - RACK_ENV=development  - SHOW=true  - USER_INPUT= 示例： services:  web:    image: nginx:1.24.0    environment:      TEST: 1  networks功能：配置容器网络示例： services:  web:    image: nginx:1.24.0    networks:      - web1      - web2 networks:  web1:  web2: volume功能：配置容器的存储卷 #短语法volumes:  - "/localhost/postgres.sock:/var/run/postgres/postgres.sock"  - "/localhost/data:/var/lib/postgresql/data"#完整语法volumes:#命名卷  - type: volume    source: db-data    target: /data    volume:      nocopy: true#绑定卷  - type: bind    source: /var/run/postgres/postgres.sock    target: /var/run/postgres/postgres.sock 示例： services:  web:    image: nginx:1.24.0    volumes:      - /home/qsy/gitDocker/data/myvolumes:/usr/share/nginx/html/ ports功能：配置容器的端口映射 #完整语法ports:  - target: 80    host_ip: 127.0.0.1    published: 8080    protocol: tcp    mode: host  - target: 80    host_ip: 127.0.0.1#短语法ports:  - "3000"  - "3000-3005"  - "8000:8000"  - "9090-9091:8080-8081"  - "49100:22"  - "127.0.0.1:8001:8001"  - "127.0.0.1:5000-5010:5000-5010"  - "6060:6060/udp" 示例： services:  web:    image: nginx:1.24.0    ports:      - 7070:80 expose功能：暴露端口，但不映射到宿主机，只被连接的服务访问。仅可以指定内部端口为参数.格式/示例： expose:  - "3000"  - "8000" depends_on功能：设置依赖关系 docker compose up：以依赖性顺序启动服务。在以下示例中，先启动 db 和 redis，才会启动 web。docker compose up SERVICE：自动包含 SERVICE 的依赖项。在以下示例中，docker compose up web 还将创建并启动 db 和 redis。docker compose stop：按依赖关系顺序停止服务。在以下示例中，web 在 db 和 redis 之前停止。version: "3.7"services:  web:    build: .    depends_on:      - db      - redis  redis:    image: redis  db:    image: postgres env_file从文件添加环境变量。可以是单个值或列表的多个值。 env_file: xxx.env 也可以是列表格式： env_file:  - ./.env  - ./apps/web.env  - /opt/secrets.env docker compose指令docker compose 指令与容器操作相似，只不过把容器改成了服务命令格式：docker-compose 命令的基本的使用格式为 docker compose [OPTIONS] COMMAND [ARGS...] 命令清单： docker compose build - 构建服务docker compose config - 以规范格式显示服务配置docker compose cp - 在本地系统和服务容器之间拷贝文件docker compose create - 创建服务的容器docker compose down - 停止所有容器并删除容器docker compose events - 从服务器获取实时事件docker compose exec - 在容器中执行命令docker compose images - 列出所有容器使用的镜像docker compose kill - 强制停止服务的容器docker compose logs - 显示容器日志docker compose ls - 显示所有项目docker compose pause - 暂停服务docker compose port - 列出所有的端口映射docker compose ps - 列出项目中目前的所有容器docker compose pull - 拉取服务镜像docker compose push - 推送服务镜像docker compose restart - 重启服务docker compose rm - 删除已停止的服务容器docker compose run - 在指定服务容器上执行命令docker compose start - 启动当前停止的容器docker compose stop - 停止当前运行的容器docker compose top - 显示运行的进程docker compose unpause - 恢复服务docker compose up - 构建、创建、启动和链接服务相关的容器（支持 --no-recreate 参数避免重新创建，-d 后台运行）docker compose version - 查看版本信息用法和功能与容器的相关指令类似，只是docker compose的操作对象是服务而已。参考文章：Docker容器核心指令关键命令选项up功能：  该命令的作用十分强大，它会尝试自动完成包括构建镜像、（重新）创建服务、启动服务并关联服务相关容器的一系列操作，可以直接通过该命令来启动一个项目。语法： docker compose up [options] [service...]运行本项目bash1选项说明： -d 在后台运行服务器，推荐在生产环境下使用该选项--force-recreate 强制重新创建容器，不能与 --no-recreate 同时使用--no-recreate 如果容器已经存在了，则不重新创建，不能与 --force-recreate 同时使用down功能：停止所有容器，并删除容器和网络。语法： docker compose down [options] [SERVICE...] 选项说明： -v, --volumes：删除容器同时删除目录映射。run功能：该命令可以在指定服务器上执行相关的命令语法： # 例如:启动一个 ubuntu 服务容器，并执行 ping docker.com 命令# docker compose run ubuntu ping docker.comdocker compose run [options] SERVICE [COMMAND] [ARGS...] 与docker run的区别，该指令是用服务启动容器，而不是镜像选项说明： -d 后台运行容器--name NAME 为容器指定一个名字--entrypoint CMD 覆盖默认的容器启动指令-e KEY=VAL 设置环境变量值，可多次使用选项来设置多个环境变量-u, --user="" 指定运行容器的用户名或者 uid--rm 运行命令后自动删除容器-p, --publish=[] 映射容器端口到本地主机示例：  综合案例docker-compose.yml配置 启动，会先启动依赖的服务。 清理，与启动相反，先清理主要的服务，然后清理依赖的服务。 ————————————————                             版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。                        原文链接：https://blog.csdn.net/2302_80105876/article/details/151714145

一.容器实操测试基本操作与状态迁移基本操作：运行对应镜像（本地不存在就去远端拉取）：启动实时日志监测：下面接着创建对应的容器，先不让他跑，然后看下状态变化：可以看到从create 和 stop 状态不同，且都能被start变成运行状态。下面测试下restart状态： 它的状态是从stop再次变成运行状态。测试下暂停状态：状态迁移：容器过滤与查询命令：根据名称过滤得到容器编号命令：docker container ls -qf name=xxx作用：通过名称筛选，仅返回匹配容器的 ID。根据状态过滤容器信息命令：docker container ls --filter status=running作用：只展示状态为 “running（运行中）” 的容器信息。静默获取全部容器 ID命令：docker container ls -aq作用：返回所有容器（包括运行和停止）的 ID，输出简洁无额外信息。过滤镜像名为 xxx 的容器信息命令：docker container ls --filter ancestor=xxx作用：依据镜像名称，筛选出使用该镜像的所有容器信息。过滤镜像 ID 为 xxx 的容器信息命令：docker container ls --filter ancestor=xxx作用：按照镜像 ID，找出基于该镜像创建的容器信息。命令参数解释：-a：列出所有容器（含已停止和正在运行的）。-q：仅返回容器的 ID，不显示其他详细信息。-f：基于指定条件过滤容器，等价于 --filter 选项，用于精准筛选目标容器。如下： 基于多命令组合执行：下面以start所有停止容器为例（~下面的符号）：  可以发现所有stop的容器全部起来（除了被kill强制杀死的容器）。容器交互模式attach与detach模式attached 模式命令示例：docker container run -p 80:80 nginx，将宿主机 80 端口映射到容器 80 端口。端口映射说明：第一个 80 是宿主机端口，第二个 80 是容器端口。特点：容器在前台运行，访问时实时打印日志；在 Linux 服务器按 Ctrl+C 可能误停服务；仅适用于容器和程序的调试阶段。detached 模式启动方式：在 docker container run -p 80:80 nginx 命令后加 -d 或 --detach 选项。特点：容器在后台运行，启动时仅显示容器 ID，可继续输入其他命令；关闭窗口容器仍运行，停止或删除需用 shell 命令，减少误操作；比 attached 模式更推荐使用。 默认attach启动，前台被占用。下面试试退出后会怎么样？  发现容器就跟着挂了。下面用detach模式后台运行下（-d）：   发现恢复了，无论是否ctrl c后，后台detach模式的容器都不受影响。下面测试下如果对应的网络断开，离线模式等情况会不会影响容器运行：  仍在运行。因此，总结下：默认就是attach模式，也就是前台运行，如果前台受到影响，自然容器就挂了，而如果detach模式，放在后台运行，无论前台咋样，即使离线，只要服务器没挂，容器正常运行不受影响；如果测试环境就用attach，前台运行，而生生产环境就用detach模式，后台运行。interactive模式用途：创建容器后，要在容器内获取信息或执行命令（如Ubuntu容器输Shell命令交互），需进交互模式。创建运行容器并进交互模式：参数：-i 保持容器运行，常与 -t 一起用，搭配 -it 容器创建后自动进入，退出则关闭；-t 为容器分配伪输入终端，常和 -i 配合。前台模式： 前台都需要手动启动nginx命令来开启这个访问，而后台默认自动启动。 发现正常启动。 无论如何ctrl c 都无法关闭，就类似一个bash终端一样。输入exit退出当前环境：  成功退出。测试后台模式：  后台程序，只要不bash，默认自动启动nginx指令。下面进行bash交互并退出： 这里退出只是退出当前容器里的执行bash的这个环境，退出的是这个bash，也就是退了这个在容器中执行命令的这个环境，然后并没退出nginx容器这个环境。总结下：前台运行容器，需要手动启动，而后台只要不启动bash后台就是自动启动nginx，然后前台以bash来运行接收exit退出容器的命令，如果无论是前台还是后台不是以bash运行，而是exec进入容器执行bash命令，此时exit就无法退出容器。也就是说exit是退出当前环境，而容器以bash运行（当前容器环境）和在容器中执行bash命令（exec对应的bash命令这个环境）不是同一个环境。二.宿主机与容器之间进行文件拷贝拿test2做测试：文件拷贝到宿主机：进行vim修改：图片访问原链接查看拷贝回去（覆盖性拷贝）：图片访问原链接查看 进行重新访问：图片访问原链接查看 符合预期。不支持容器之间拷贝。三. 容器的自动删除与自动重启自动删除（run的时候带–rm）发现自动删除了，后台程序也是一样（注意是stop不是pause）。自动重启：docker run --restart=no [容器名]：默认值，不自动重启容器。docker run --restart=on-failure:3 [容器名]：仅在容器退出状态非0时自动重启，可指定重启次数（此处为3次），超过次数则放弃重启。docker run --restart=always [容器名]：容器退出时总是自动重启。docker run --restart=unless-stopped [容器名]：容器退出时总是自动重启，但不考虑Docker守护进程启动时就已经停止的容器。若容器启动时未设置--restart参数，可通过docker update --restart=always [容器名]命令更新重启策略。这里默认就是no（查看容器信息）： 下面拿always模式测试下（这里需要进入容器，执行容器内设置的退出指令）： 但是如果在容器外部被宿主机被stop了呢？ 说明stop后不能被重启。四.容器环境变量设置与容器信息查看及借助容器执行特殊任务环境变量设置-e 参数（运行时设置）命令：docker run -e 变量名=值 镜像名特点：仅对当前运行容器有效，适合临时注入少量配置，如密码等敏感信息。–env-file 参数（运行时从文件加载）命令：docker run --env-file 文件路径 镜像名特点：从文件批量加载多个环境变量到当前运行容器，适合管理多个配置项。测试下：-e: 符合预期。--env-file :按照文件给它输进去：  符合预期。容器详情信息查看这里其实就是docker ps 与docker container inspect 容器名字 这两命令；前者是后者的简单提取，后者是更详细的： 宿主机靠容器执行单行命令我们可以直接借助 docker 的容器环境执行一些命令，比如容器中有某个命令而宿主机上没有这个时候借助容器可以完成某些任务。假设宿主机没有ping与ifconfig这个命令(借助busybox): 这里看到的都是容器的，以容器的视角执行的命令（一般测试容器命令的时候可以这样，测试的都是对外通用的命令）。————————————————                            版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。                        原文链接：https://blog.csdn.net/2401_82648291/article/details/150776761

1、前言采用离线安装的方式。关于离线安装的方式官网有介绍，但是说的很简单，网址：Binaries | Docker Docs官网介绍的有几种主流linux系统的安装方式，但是没有kylin的，所以在此记录一下。在安装过程中也遇到了些问题，走了些弯路。在此记录的只是某一种能正常安装的方式，也许也有其它方式能够安装成功，欢迎一起交流。2、kylin系统信息官网上有关于系统要求的： 系统版本信息 查看Linux内核 查看iptables版本 查看处理器架构 3、下载官网下载对应版本：Index of linux/static/stable/ 麒麟系统是arm架构的，下载aarch64版本，下载的是当时最新版 4、安装将下载文件拷贝到kylin电脑目录下，解压： 将解压后的文件移动或拷贝到/usr/bin/目录下，注意使用sudo，后面的命令都要使用sudo。mv docker/* /usr/bin/AI写代码bash此时就可以查看docker版本 5、配置docker服务先创建两个系统文件（后面的操作都需要sudo）docker.servicevim /etc/systemd/system/docker.serviceAI写代码bash输入以下内容[Unit]Description=Docker Application Container EngineDocumentation=https://docs.docker.comAfter=network-online.target firewalld.serviceWants=network-online.targetRequires=docker.socket [Service]Type=notifyExecStart=/usr/bin/dockerdExecReload=/bin/kill -s HUP $MAINPIDTimeoutStartSec=0Restart=on-failureStartLimitBurst=3StartLimitInterval=60sLimitNOFILE=infinityLimitNPROC=infinityDelegate=yesKillMode=process [Install]WantedBy=multi-user.targetAI写代码bashdocker.socketvim /etc/systemd/system/docker.socketAI写代码bash输入以下内容[Unit]Description=Docker Socket for the APIPartOf=docker.service [Socket]ListenStream=/var/run/docker.sockSocketMode=0660SocketUser=rootSocketGroup=docker [Install]WantedBy=sockets.targetAI写代码bash为docker.service添加执行权限chmod +x docker.serviceAI写代码bash编辑daemon.json,没有就创建vim /etc/docker/daemon.jsonAI写代码bash输入以下内容{  "registry-mirrors":["https://mirrors.ustc.edu.cn"],  "exec-opts":["native.cgroupdriver=systemd"]}AI写代码bash所有的配置文件编辑并保存后，执行systemctl daemon-reloadAI写代码bash6、启动docker服务systemctl start docker.serviceAI写代码bash如果想开机自动启动，输入以下指令：systemctl enable docker.serviceAI写代码bash7、验证docker是否安装成功执行 docker info 命令能显示如下信息： 或者输入 docker version(注意：没有 - ) 8、Hello world熟悉的 hello world……执行 docker run hello-world 命令报错：docker: Error response from daemon: Get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) 这种是镜像仓库路径配置的有问题，按照如下修改daemon.json:{  "registry-mirrors":["https://mirrors.ustc.edu.cn","https://docker-cf.registry.cyou","https://dockercf.jsdelivr.fyi","https://docker.jsdelivr.fyi","https://dockertest.jsdelivr.fyi","https://mirror.aliyuncs.com","https://dockerproxy.com","https://mirror.baidubce.com","https://docker.m.daocloud.io","https://docker.nju.edu.cn","https://docker.mirrors.sjtug.sjtu.edu.cn","https://docker.mirrors.ustc.edu.cn","https://mirror.iscas.ac.cn","https://docker.rainbond.cc"  ],  "exec-opts":["native.cgroupdriver=systemd"]}AI写代码bash保存退出,执行下面的命令：systemctl daemon-reloadsystemctl restart docker.servicedocket run hello-worldAI写代码bash出现以上信息应该就说明docker安装的没问题了。————————————————                            版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。                        原文链接：https://blog.csdn.net/bailang_zhizun/article/details/147770700

华为云Docker教程在解决系统特异性问题（如依赖冲突、配置校验）上提供了实用方案，但需用户具备一定Linux排错能力。其与SWR镜像服务的深度整合，是构建稳定容器化管道的关键利器 💪。

我想本地部署deepseek，借助modelarts平台昇腾算力，在要拉取镜像时发现，modelarts的管理员权限不开放，导致我无法下载docker，卡在这里，我想在这里求助一下，还有其他下载docker的方法吗？

教程非常适合新手，学到了不少东西

【案例共创】ESC基于RAGFlow和DeepSeek构建本地问答知识库一、案例介绍在人工智能技术飞速发展的当下，企业知识库智能化正成为提升运营效率的核心路径。DeepSeek 几乎家喻户晓，而 RAGFlow 是一个基于深入文档理解的开源RAG（检索增强生成）引擎。当与LLMs集成时，它能够提供真实的问题回答功能，并由来自各种复杂格式数据的有理有据的引用支持。本次我们基于ESC使用 Docker 部署RAGFlow，并使用 ollama 部署 DeepSeek R1 模型和 bge-m3 嵌入模型，体验 RAGFlow 的知识库、对话、Agent等功能，通过RAGFlow的智能文档解析与DeepSeek大语言模型的精准推理能力，构建具备多源异构数据处理、语义深度理解及动态知识更新特征的问答知识库、Agent。二、案例用时本案例总时长预计120分钟。三、案例流程 说明：通过ECS中安装dokcer部署ragflow通过ECS中docker部署ollama来运行deepseek通过配置ragflow来调用deepseek-r1模型能力用过通过公网ip访问ECS从而体验ragflow+deepseek四、资源总览云资源消耗/时时长ECS（含公网IP、磁盘等）0.9885120min合计：1.977元五、实践步骤0. 购买ECS配置如下:bash计费模式： 按需计费区域： 西南-贵阳一可用区： 随机分配CPU架构：x86计算实例规格：通用计算增强型 | x1e.4u.16g | 4vCPUs | 16GiB镜像： 公共镜像-Ubuntu 24.04 server 64bit(10GiB)磁盘： 通用型SSD 50G弹性公网IP：现在购买-全动态BGP-按带宽计算-5Mbit/s-随实例释放云服务器名称：ecs-ragflow密码：RagFlow@123使用时长：设定删除时间为 8 小时之后购买数量： 1清单链接：https://www.huaweicloud.com/pricing/calculator.html?shareListId=267c3c60fc6411efa933bd915e6892f51、安装 RAGFlow1.1 安装 Docker CE 和 Docker Compose打开终端，新建 install-docker.sh:bash# 查看系统uname -alsb_release -a# 准备安装 dockercd ~pwdmkdir RAGFlowcd RAGFlowvi install-docker.sh写入以下脚本到 install-docker.shbash#!/bin/bash# 定义日志文件路径LOGFILE="/var/docker-install.log"# 将标准输出和错误输出重定向到日志文件,同时显示到终端exec > >(tee -a "$LOGFILE") 2>&1# 设置DEBUG模式下的时间戳输出格式trap '{ set +x; } 2>/dev/null; echo -n "[$(date -Is)] "; set -x' DEBUG# 下载并安装 docker CE 和 docker composeecho "开始安装 Docker CE 和 Docker Compose..."# 添加Docker官方GPG密钥curl -fsSL https://mirrors.huaweicloud.com/docker-ce/linux/ubuntu/gpg | sudo apt-key add -echo "已添加 Docker GPG 密钥"# 添加Docker软件源echo "" | sudo add-apt-repository "deb [arch=amd64] https://mirrors.huaweicloud.com/docker-ce/linux/ubuntu $(lsb_release -cs) stable"echo "已添加 Docker 软件源"# 更新软件包列表echo "正在更新软件包列表..."echo "y" | sudo apt-get update# 安装Docker CE和Docker Composeecho "正在安装 Docker CE 和 Docker Compose..."echo "y" | sudo apt-get install docker-ce docker-composeecho "Docker 安装完成"# 配置docker镜像仓库为华为云镜像echo "正在配置华为云镜像源..."sudo echo '{"registry-mirrors": ["https://b4a1f63a156e435f9aeb797bdf515250.mirror.swr.myhuaweicloud.com"]}' >/etc/docker/daemon.json# 重启docker服务使配置生效echo "正在重启 Docker 服务..."sudo systemctl restart dockerecho "Docker 配置完成"接着运行 docker 安装脚本：bashsudo bash ./install-docker.sh我们查看版本发现 docker-compse 版本有点低，可能会影响后续的安装，因此尝试升级 docker-composebashdocker -vdocker-compse -v升级 docker-compose：bash# 先看看 docker-compose 的路径whereis docker-compose# 备份一下sudo mv /usr/bin/docker-compose /usr/bin/docker-compose.bak# 下载对应系统的 docker-composewget https://github.com/docker/compose/releases/download/v2.33.1/docker-compose-linux-x86_64 -O docker-compose# 如果速度慢可以尝试使用加速源，如 https://hub.gitmirror.com/、https://github.moeyy.xyz/、https://ghfast.top/# wget https://hub.gitmirror.com/https://github.com/docker/compose/releases/download/v2.33.1/docker-compose-linux-x86_64 -O docker-compose# 也可以自行去 github 下载： https://github.com/docker/compose/releases# 替换 docker-composesudo cp ./docker-compose /usr/bin/docker-compose# 加权限sudo chmod +x /usr/bin/docker-compose# 验证docker-compose -v1.2 安装 RAGFlow先设置一下最大虚拟内存。vm.max_map_count该值设置进程可能拥有的内存映射区域的最大数量。它的默认值是65530。虽然大多数应用程序需要的映射少于一千个，但减小此值可能会导致异常行为，并且当进程达到限制时，系统将抛出内存不足错误。RAGFlow v0.17.0使用Elasticsearch或Infinity进行多次调用。正确设置vm.max_map_count的值对于Elasticsearch组件的正常运行至关重要。bash# 检查vm.max_map_count的值sysctl vm.max_map_count# 如果小于 262144 则至少设置为 262144sudo sysctl -w vm.max_map_count=262144接着安装 RAGFlowbash# 下载源码git clone https://github.com/infiniflow/ragflow.git# 如果下载比较慢请尝试使用镜像加速，如：# git clone https://ghfast.top/https://github.com/infiniflow/ragflow.gitcd ragflow/docker# 切换最新稳定分支 (截止 20205-03-08 为 0.17.0)git checkout -f v0.17.0git branch我们可以修改 .env 启用全量版本（非必须，可无须修改直接使用 slim 版本），并设置 docker 镜像源:bashsudo echo '{"registry-mirrors": ["https://b4a1f63a156e435f9aeb797bdf515250.mirror.swr.myhuaweicloud.com"]}' >/etc/docker/daemon.jsonRAGFlow镜像标签镜像大小（GB）是否包含嵌入模型和Python包是否稳定v0.17.0≈9✔️稳定版本v0.17.0-slim≈2❌稳定版本nightly≈9✔️nightly 构建不稳定nightly-slim≈2❌nightly 构建不稳定接着通过 docker-compose 启动 RAGFlow，全量的镜像约 9G，安装稍微慢些，需要耐心等待大约10分钟bash# 拉取镜像并启动(默认不包含 embedding 模型， 可以修改 .env 配置，选为华为云镜像v0.17.0 )# vi .env 找到对应位置进行修改docker-compose -f docker-compose.yml up -d# 如果minio拉取不顺，请尝试切换镜像源，需修改 docker-compose-base.yml 的：quay.io 为 quay.m.daocloud.io# 查看日志docker-compose logs -f ragflow-server# 查看端口情况netstat -nptl2. 访问本地 RAGFlow并配置模型RAGFlow是一个RAG引擎，需要与大模型服务一起搭配使用，实现本地、无幻觉的问答功能。RAGFlow支持大多数主流LLMs。2.1 访问本地RAGFlow 并注册账号登录如本次案例中 ecs-ragflow 的 ip 为1.95.184.111 则访问： http://1.95.184.111/login ，注册账号即可使用 RAGFlow。登录之后的主界面如下：⚠️本地模型为选配，同样可以使用其他大模型API服务，比如 Mass、硅基流动等2.2 通过 Docker 安装 ollama首先我们设置docker镜像源，重启docker之后，通过docker拉取ollama镜像并运行bash# 设置 docker 镜像源sudo echo '{"registry-mirrors": ["https://b4a1f63a156e435f9aeb797bdf515250.mirror.swr.myhuaweicloud.com"]}' >/etc/docker/daemon.jsonsudo systemctl restart dockersudo docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama2.3 安装 DeepSeek-R1 模型和 bge-m3 鉴于网络下载速度比较慢，我们拉取相对较小的 deepseek-r1:1.5b 和嵌入模型 bge-m3 (预计25分钟，具体看网络状况)bash# 拉取 deepseek-r1:1.5bsudo docker exec ollama ollama pull deepseek-r1:1.5b# 拉取 bge-m3sudo docker exec ollama ollama pull bge-m32.4 配置模型虽然RAGFlow和Ollama都是跑在同一台机器上，但由于分别使用了docker-compose和docker来部署，可能会导致网络不通的情况，那我们可以通过暴露 11434 ollama的端口来提高大模型服务。于是，我们在模型提供商选择Ollam之后分别配置了嵌入模型 bge-m3 和聊天模型deepseek-r1:1.5b。接着并在设置--系统模型设置中配置好聊天模型和嵌入模型。3. 简单使用接下来，我们简单体验一下RAGFlow 提供的功能，分别是知识库、聊天、搜索、Agent。3.1 知识库功能体验点击知识库，我们创建了一个名为ModelArts助手的知识库，传入了几个pdf文件作为本地知识库。在RAGFlow中知识库被称为数据集，我们可以上次多个文件作为数据集，并通过不通的解析方法将文档进行处理如切片、Q/A等。解析成功的文档可以在后续功能中作为知识库引入。3.2 聊天功能体验我们创建了ModelArts助手的助理，可以对助理进行配置如基本信息、关键词分析、模型参数设置等，并选取知识库作为回答语料。我们一个“如何快速入门”的简单问题开始，AI助理根据挂载的知识给了相关的回答。3.3 搜索功能体验在RAGFlow中，还有搜索功能，类似于传统的搜索引擎给出结果并添加了智能回答和思维导图。3.4 Agent功能体验最后我们来体验Agent功能，这里我们使用的是预置的 text2sql。Agent 会提供一个工作流编排界面，并提供运行测试功能，我们发现Agent也是可以作为单独的页面嵌入到其他网站，简单地要Agent给出“用户转化率”，它基于 deepseek-r1 模型，因此也有思考能力，最终它生成了一段完整的 SQL 语句。至此，案例实践就结束了，记得释放资源哦！记得释放资源哦！记得释放资源哦！我正在参加【案例共创】第2期 构建开发场景最佳实践/体验评测，创作案例文章cid:link_0

1.Docker应用部署（Mysql、tomcat、Redis、redis）https://bbs.huaweicloud.com/forum/thread-0251176000289103057-1-1.html    2. 鸿蒙NEXT开发案例：随机数生成https://bbs.huaweicloud.com/forum/thread-0226175856046738051-1-1.html3.ExaGear for Server on Ubuntuhttps://bbs.huaweicloud.com/forum/thread-02127175583262901024-1-1.html4.惊叹数据结构之美，品味排序算法之妙：对快排的详细介绍 -转载https://bbs.huaweicloud.com/forum/thread-0210175572143077031-1-1.html5.修改 Docker 容器的 http_proxy 和 https_proxy -转载https://bbs.huaweicloud.com/forum/thread-02127175572007355023-1-1.html6.【Linux】gdb_进程概念-转载https://bbs.huaweicloud.com/forum/thread-0257175571963347026-1-1.html7.详解Redis之事务-转载https://bbs.huaweicloud.com/forum/thread-0251175571892832022-1-1.html8.Python中的对象关系映射SQLAlchemy ORM在Web开发中的实践 -转载https://bbs.huaweicloud.com/forum/thread-0218175571849778026-1-1.html9.鸿蒙NEXT开发案例：颜文字搜索器https://bbs.huaweicloud.com/forum/thread-0225175848016900053-1-1.html10.鸿蒙NEXT开发案例：经纬度距离计算https://bbs.huaweicloud.com/forum/thread-02127175847897096052-1-1.html11.鸿蒙NEXT开发案例：世界时间表https://bbs.huaweicloud.com/forum/thread-0220175848120824046-1-1.html12.鸿蒙NEXT开发案例：保质期计算https://bbs.huaweicloud.com/forum/thread-0257175848211239048-1-1.html13.鸿蒙NEXT开发案例：九宫格随机https://bbs.huaweicloud.com/forum/thread-0257175848540835049-1-1.html14.Python中的对象关系映射SQLAlchemy ORM在Web开发中的实践 -转载https://bbs.huaweicloud.com/forum/thread-0218175571849778026-1-1.html15.【MySQL】 表的操作-转载https://bbs.huaweicloud.com/forum/thread-0220174982575490008-1-1.html

Docker 是一种开源的容器化技术，它可以帮助开发人员和运维人员以更高效、更轻松的方式管理应用程序和服务。通过容器技术，我们可以将应用与其所有的依赖包一起打包，使得应用可以在任何环境中快速、可靠地运行。本文将展示如何在 Docker 容器中部署 MySQL、Tomcat 和 Redis 服务，帮助你快速构建一个多服务的应用环境。1. 准备工作在开始 Docker 部署之前，请确保已经安装了 Docker。可以通过以下命令检查 Docker 是否安装成功：bashCopy Codedocker --version如果没有安装 Docker，可以参考官方文档进行安装：Docker 官方安装文档2. 部署 MySQL 服务2.1. 拉取 MySQL 镜像首先，我们需要拉取 MySQL 镜像。使用 Docker Hub 提供的官方 MySQL 镜像：bashCopy Codedocker pull mysql:latest2.2. 启动 MySQL 容器接下来，通过以下命令启动一个 MySQL 容器：bashCopy Codedocker run --name mysql-container -e MYSQL_ROOT_PASSWORD=root -d mysql:latest--name mysql-container：指定容器名称为 mysql-container。-e MYSQL_ROOT_PASSWORD=root：设置 MySQL 的 root 用户密码为 root。-d：以后台模式运行容器。mysql:latest：使用 mysql 的最新版本镜像。2.3. 连接到 MySQL 容器要进入 MySQL 容器，可以使用以下命令：bashCopy Codedocker exec -it mysql-container mysql -uroot -p输入密码 root 即可进入 MySQL 命令行。2.4. 设置数据库在 MySQL 中创建一个数据库和一个用户（可选）：sqlCopy CodeCREATE DATABASE mydb; CREATE USER 'myuser'@'%' IDENTIFIED BY 'password'; GRANT ALL PRIVILEGES ON mydb.* TO 'myuser'@'%'; FLUSH PRIVILEGES;3. 部署 Tomcat 服务3.1. 拉取 Tomcat 镜像我们可以使用官方的 Tomcat 镜像：bashCopy Codedocker pull tomcat:latest3.2. 启动 Tomcat 容器启动 Tomcat 容器，指定要暴露的端口：bashCopy Codedocker run --name tomcat-container -d -p 8080:8080 tomcat:latest--name tomcat-container：指定容器名称为 tomcat-container。-d：后台运行容器。-p 8080:8080：将容器内的 8080 端口映射到主机的 8080 端口。Tomcat 启动后，可以通过浏览器访问 http://localhost:8080 来查看 Tomcat 默认的欢迎页面。3.3. 部署 Web 应用将自己的 WAR 文件部署到 Tomcat 中的 webapps 目录中，方法如下：bashCopy Codedocker cp your-app.war tomcat-container:/usr/local/tomcat/webapps/将 your-app.war 替换为你自己的应用包。重新启动 Tomcat 容器以加载新部署的应用：bashCopy Codedocker restart tomcat-container此时，你的应用可以通过 http://localhost:8080/your-app 来访问。4. 部署 Redis 服务4.1. 拉取 Redis 镜像我们可以使用官方的 Redis 镜像：bashCopy Codedocker pull redis:latest4.2. 启动 Redis 容器启动 Redis 容器并将端口映射到主机：bashCopy Codedocker run --name redis-container -d -p 6379:6379 redis:latest--name redis-container：指定容器名称为 redis-container。-d：后台运行容器。-p 6379:6379：将容器内的 6379 端口映射到主机的 6379 端口。4.3. 连接到 Redis 容器要连接到 Redis 容器，可以使用以下命令：bashCopy Codedocker exec -it redis-container redis-cli5. 测试应用是否正常运行测试 MySQL：可以通过以下命令测试 MySQL 服务是否正常运行：bashCopy Codedocker exec -it mysql-container mysql -uroot -p -e "SHOW DATABASES;" 这会列出当前 MySQL 实例中的所有数据库。测试 Tomcat：通过访问 http://localhost:8080，可以检查 Tomcat 是否成功启动。测试 Redis：可以通过以下命令测试 Redis 是否正常运行：bashCopy Codedocker exec -it redis-container redis-cli ping如果返回 PONG，则表示 Redis 正常运行。6. 总结通过 Docker 容器化技术，我们能够轻松地部署 MySQL、Tomcat 和 Redis 服务。Docker 提供了简单的命令来启动、配置和管理这些服务，使得开发和部署过程更加高效和便捷。通过容器化的方式，你可以确保应用在任何环境中都能保持一致性和可移植性。这种方法对于开发、测试以及生产环境的部署都非常有用，并且可以通过 Docker Compose 进一步简化多个服务的管理。希望这篇文章能帮助你更好地理解如何使用 Docker 部署和管理 MySQL、Tomcat 和 Redis 服务。

修改 Docker 容器的 http_proxy 和 https_proxy 可以通过几种方式实现。以下是一些常用的方法：在运行容器时设置环境变量：当你启动一个新的容器时，可以使用 -e 选项设置这些环境变量：docker run -e HTTP_PROXY=http://proxy.example.com:8080 -e HTTPS_PROXY=http://proxy.example.com:8080 your_image1对于已经运行的容器：a. 使用 docker exec 命令：docker exec -it your_container_name /bin/bashexport HTTP_PROXY=http://proxy.example.com:8080export HTTPS_PROXY=http://proxy.example.com:8080123注意，这种方法只在当前会话中有效，容器重启后就会失效。b. 修改容器的 /etc/environment 文件：docker exec -it your_container_name /bin/bashecho "HTTP_PROXY=http://proxy.example.com:8080" >> /etc/environmentecho "HTTPS_PROXY=http://proxy.example.com:8080" >> /etc/environment123这种方法在容器重启后仍然有效。在 Dockerfile 中设置：如果你正在构建自己的镜像，可以在 Dockerfile 中设置这些环境变量：ENV HTTP_PROXY http://proxy.example.com:8080ENV HTTPS_PROXY http://proxy.example.com:808012使用 Docker Compose：如果你使用 Docker Compose，可以在 docker-compose.yml 文件中设置环境变量：version: '3'services:  your_service:    image: your_image    environment:      - HTTP_PROXY=http://proxy.example.com:8080      - HTTPS_PROXY=http://proxy.example.com:8080修改 Docker 守护进程的配置：你可以为 Docker 守护进程设置全局代理，这会影响所有容器。编辑 /etc/systemd/system/docker.service.d/http-proxy.conf 文件（如果不存在就创建它）：[Service]Environment="HTTP_PROXY=http://proxy.example.com:8080"Environment="HTTPS_PROXY=http://proxy.example.com:8080"123然后重启 Docker 服务：sudo systemctl daemon-reloadsudo systemctl restart docker12注意事项：确保使用正确的代理地址和端口。某些应用程序可能使用小写的环境变量名（http_proxy, https_proxy），你可能需要同时设置大写和小写版本。如果你的代理需要认证，格式应该是：http://username:password@proxy.example.com:8080————————————————                            版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。                        原文链接：https://blog.csdn.net/jsyzliuyu/article/details/142873507