为什么要优化 Docker 镜像 Docker 镜像并不是一个简单的压缩包，而是由多个只读 Layer 组成的文件系统。 例如： Dockerfile │ ├── FROM ├── RUN ├── COPY └── RUN │ ▼ Image Layers │ ▼ Container 镜像体积会直接影响： 构建时间。 镜像 Push 时间。 镜像 Pull 时间。 CI/CD 执行时间。 磁盘占用。 容器启动速度。 镜像攻击面。 因此，镜像优化并不只是为了“让镜像变小”。 更准确地说： 镜像优化 │ ├── 减少无用文件 ├── 减少无用依赖 ├── 提高构建缓存命中率 ├── 缩短构建时间 ├── 减少网络传输 └── 降低攻击面 Docker 官方也将“小而聚焦”的镜像作为生产镜像构建的重要目标，并强调镜像大小和安全性之间存在直接关系。 因此，一份生产级 Dockerfile 通常应该同时考虑： 体积 性能 缓存 安全 可维护性 而不是只关注其中一个指标。 选择合适的基础镜像 基础镜像是整个 Docker 镜像的起点。 例如：...

Mysql 简易安装 安装Mysql8.0(centos8为例)， 可参考 MySQL官方文档 # CentOS el8下载 MySQL YUM 仓库（替换为最新版本） wget https://dev.mysql.com/get/mysql80-community-release-el8-6.noarch.rpm # el9 使用sudo yum install mysql84-community-release-el9-x86_64.noarch.rpm sudo rpm -Uvh mysql80-community-release-el*.rpm sudo yum makecache # 安装 MySQL 社区版服务器 # el9 的话sudo yum install mysql84-community-release-el9-x86_64.noarch.rpm sudo yum install -y mysql-community-server # 可以通过手动编辑/etc/yum.repos.d/mysql-community.repo文件来选择发布系列。 # **install时如果出现GPG 密钥问题** # sudo curl -o /etc/pki/rpm-gpg/RPM-GPG-KEY-mysql-2023 https://repo.mysql.com/RPM-GPG-KEY-mysql-2023 # sudo chmod 644 /etc/pki/rpm-gpg/RPM-GPG-KEY-mysql-2023 # sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-mysql-2023 # 重新执行 yum install -y mysql-community-server # 启动 MySQL 服务 sudo systemctl start mysqld sudo systemctl enable mysqld sudo systemctl status mysqld #MySQL 首次启动会生成一个临时 root 密码： sudo grep 'temporary password' /var/log/mysqld....

Docker CI/CD 要解决什么问题 前面的 Docker 系列已经介绍了 Dockerfile、Docker Compose、镜像构建、镜像 Push 以及 Harbor 私有镜像仓库。 如果每次发布都手动执行： git pull docker build -t registry.example.com/backend/api:v1.0.0 . docker push registry.example.com/backend/api:v1.0.0 ssh server docker pull registry.example.com/backend/api:v1.0.0 docker compose up -d 项目规模较小时问题不大，但随着服务数量增加，手工发布会逐渐暴露出几个问题： 容易漏执行步骤。 镜像 Tag 容易写错。 测试和生产环境操作不一致。 发布过程缺少统一记录。 无法方便地回滚。 开发人员需要直接登录生产服务器。 发布效率随着项目数量增加而下降。 CI/CD 的核心目标，就是把这些重复操作交给自动化系统完成。 一个典型的 Docker CI/CD 流程如下： Git Push │ ▼ CI Pipeline │ ├── Checkout ├── Test ├── Build Image ├── Tag Image └── Push Image │ ▼ Harbor │ ▼ Deploy │ ▼ Production 最终开发人员只需要：...

为什么需要私有 Docker 镜像仓库 前面的文章介绍了 Docker 镜像的构建、Tag 和 Push。实际开发中，镜像通常不会只保存在开发者本机，而是需要进入一个统一的镜像仓库。 一个典型的发布流程如下： 开发者 │ │ docker build ▼ 本地 Docker Image │ │ docker tag ▼ 私有镜像仓库 │ ├── 测试服务器 ├── 生产服务器 ├── CI/CD └── Kubernetes 如果团队直接使用 Docker Hub 等公共 Registry，需要考虑镜像可见性、网络访问、权限管理以及企业内部代码和基础镜像的存储问题。 私有 Registry 的主要价值就是建立企业内部的镜像分发中心： ┌──────────────┐ │ CI/CD │ └──────┬───────┘ │ push ▼ ┌──────────┐ ┌──────────────┐ │ Developer│───────▶│ Private │ │ Docker │ push │ Registry │ └──────────┘ └──────┬───────┘ │ pull ┌────────────┼────────────┐ ▼ ▼ ▼ 测试环境 生产环境 K8s 集群 Docker Registry 是镜像仓库的基础能力，而 Harbor 在 Registry 之上增加了 Web 管理、用户体系、项目权限、镜像扫描、Robot Account、复制等企业级能力。...

在前面的文章中，我们已经介绍了 Dockerfile 和 Docker Compose。 Dockerfile 解决的是「如何定义一个镜像」，Compose 解决的是「如何运行和管理多个容器」。 但一个完整的 Docker 应用交付流程还缺少一个重要环节： Dockerfile ↓ docker build ↓ Docker Image ↓ docker tag ↓ docker push ↓ Container Registry ↓ docker pull ↓ 服务器 ↓ docker run / docker compose 这就是 Docker 镜像从「构建」到「发布」再到「部署」的完整链路。 本文重点介绍 docker build、docker tag、docker login、docker push、docker pull 以及 docker buildx build，并结合一个 PHP 应用说明实际项目中的镜像发布流程。 1. Docker 镜像发布的完整流程 一个 Docker 镜像从代码进入服务器，通常经历以下几个阶段： 开发环境 │ ▼ Dockerfile │ │ docker build ▼ Docker Image │ │ docker tag ▼ Registry Image │ │ docker push ▼ Container Registry │ │ docker pull ▼ 部署服务器 │ │ docker run │ 或 docker compose ▼ Container 其中每个命令负责不同的事情：...

单独使用 Docker 时，我们通常需要执行： docker run 来启动一个容器。 但一个实际项目往往并不只有一个容器。 例如一个 PHP/Hyperf 项目可能需要： Nginx PHP / Hyperf MySQL Redis RabbitMQ 如果全部手动使用 docker run 管理，不仅命令很长，而且容器之间的网络、Volume、环境变量、启动顺序等都需要自己维护。 Docker Compose 就是为解决这个问题而设计的。 Docker 官方将 Compose 定义为用于定义和运行多容器应用的工具，可以在一个 Compose 文件中定义服务、网络和 Volume，并通过命令统一管理整个应用栈。当前推荐使用 Compose Specification。 1. Docker Compose 是什么 Docker Compose 的核心思想是： 一个应用 │ ├── PHP ├── Nginx ├── MySQL └── Redis │ ▼ compose.yaml │ ▼ docker compose up -d 也就是说： Docker 负责容器，Compose 负责组织容器。 例如： services: php: image: php:8.3-cli mysql: image: mysql:8....

Docker 的核心使用方式可以简单理解为： Dockerfile ↓ docker build ↓ Docker Image ↓ docker run ↓ Docker Container 如果说 Docker Container 解决的是“应用怎么运行”，那么 Dockerfile 解决的就是“应用运行环境怎么构建”。 在实际项目中，我们很少直接使用一个现成镜像完成所有工作。对于 PHP、Java、Node.js、Go 等应用，通常需要把项目代码、运行环境、依赖以及启动方式封装成自己的镜像。 Docker 官方将 Dockerfile 定义为描述镜像构建过程的文本文件，Docker 会按照其中的指令顺序构建镜像。Dockerfile 通常从 FROM 开始，并支持 RUN、COPY、CMD、ENTRYPOINT、ENV、ARG、WORKDIR、USER、HEALTHCHECK 等指令。 1. Dockerfile 是什么 一个最简单的 Dockerfile： FROM nginx:1.27 COPY ./html /usr/share/nginx/html 然后执行： docker build -t my-nginx:1.0 . Docker 会读取当前目录下的 Dockerfile，并根据指令构建镜像。 这里有两个重要概念： Dockerfile 定义： 使用什么基础镜像 安装什么软件 复制什么文件 设置什么环境变量 使用什么用户 容器启动时运行什么程序 Image Dockerfile 执行完成后得到镜像。 例如： Dockerfile │ │ docker build ▼ my-nginx:1....

Docker 使用详解：从安装配置到常用命令实战 Docker 已经成为后端开发和部署中非常常见的基础工具。 无论是本地开发，还是测试、CI/CD、服务器部署，都经常会遇到： MySQL Redis RabbitMQ Nginx PHP Node.js Python 这些服务都可以通过 Docker 快速运行。 相比直接在操作系统中安装各种软件，Docker 最大的优势之一是： 把应用及其运行环境封装成容器，让开发、测试和部署环境更加一致。 本文不深入讨论 Docker 底层实现，而是以实际使用为主，从安装开始，重点介绍日常开发中最常用的 Docker 命令。 1. Docker 是什么？ Docker 是一个容器化平台。 传统方式安装一个 PHP 项目，可能需要： 操作系统 ↓ PHP ↓ PHP 扩展 ↓ Composer ↓ Nginx ↓ MySQL ↓ Redis 不同开发者的电脑可能存在： PHP 版本不同 MySQL 版本不同 扩展不同 配置不同 系统环境不同 于是就容易出现： “我的电脑上可以运行，你的电脑为什么不行？” Docker 的思路是把应用运行环境标准化。 例如： Docker ├── PHP 8.3 ├── Nginx ├── MySQL 8 └── Redis 每个服务运行在独立容器中。...

MySQL事务与隔离级别深度解析 一、 事务基础概念 1. 什么是事务 事务(Transaction)是数据库操作的最小工作单元，是作为单个逻辑工作单元执行的一系列操作。事务具有以下四个关键特性(ACID)： 原子性(Atomicity)：事务中的所有操作要么全部完成，要么全部不完成 一致性(Consistency)：事务执行前后，数据库从一个一致状态变到另一个一致状态 隔离性(Isolation)：多个事务并发执行时，一个事务的执行不应影响其他事务 持久性(Durability)：事务一旦提交，其结果就是永久性的 2. MySQL中的事务控制语句 START TRANSACTION; -- 或 BEGIN -- 执行SQL操作 COMMIT; -- 提交事务 ROLLBACK; -- 回滚事务 二、事务隔离级别详解 1. 四种标准隔离级别 MySQL支持四种事务隔离级别，控制不同事务之间的可见性： 隔离级别 脏读 不可重复读 幻读 说明 READ UNCOMMITTED（读未提交） 可能 可能 可能 最低隔离级别 READ COMMITTED（读已提交） 不可能 可能 可能 大多数数据库默认级别 REPEATABLE READ（可重复读） 不可能 不可能 可能 MySQL默认级别 SERIALIZABLE（序列化） 不可能 不可能 不可能 最高隔离级别 2. 并发问题说明 脏读(Dirty Read)：读取到其他事务未提交的数据 不可重复读(Non-repeatable Read)：同一事务内多次读取同一数据结果不同 幻读(Phantom Read)：同一事务内多次查询返回不同的行集合 3. 隔离级别设置与查看 -- 设置当前会话隔离级别 SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; -- 设置全局隔离级别 SET GLOBAL TRANSACTION ISOLATION LEVEL REPEATABLE READ; -- 查看当前隔离级别 SELECT @@transaction_isolation; 三、各隔离级别实现机制 1....

MYSQL中的回（Back to Table）表说明 一、 基本概念 回表是指当使用非聚簇索引（二级索引）进行查询时，首先在索引中查找到所需数据的主键值，然后再根据这个主键值回到主键索引（聚簇索引）中查找完整数据行的过程。 二、核心原理 聚簇索引 vs 非聚簇索引 -- 创建测试表 CREATE TABLE user_info ( id INT PRIMARY KEY, -- 主键，聚簇索引 name VARCHAR(50), email VARCHAR(100), age INT, created_at DATETIME, INDEX idx_email (email), -- 非聚簇索引（二级索引） INDEX idx_name_age (name, age) -- 复合非聚簇索引 ); 索引结构对比 聚簇索引（主键索引）结构： 索引节点 -> 叶子节点包含完整数据行 [id:1] -> [id:1, name:'张三', email:'[email protected]', age:25, ...] [id:2] -> [id:2, name:'李四', email:'[email protected]', age:30, ...] 非聚簇索引（二级索引）结构： 索引节点 -> 叶子节点只包含索引列 + 主键值 [email:'[email protected]'] -> [主键id:2] [email:'zhang@xx....