DevOps

Drone CICD自动化部署指南 一、Drone核心优势与架构设计 1.1 为什么选择Drone 官方文档 Drone作为轻量级云原生CI/CD工具，相比Jenkins具有显著优势： 资源占用低：基于Docker容器化运行，单个Pipeline平均内存消耗<100MB 云原生支持：原生集成Kubernetes、Docker等云原生技术栈 配置即代码：完全通过.drone.yml定义流程，版本可控 高性能：测试显示并发构建能力比Jenkins高3-5倍16 1.2 企业级架构设计 [Gitee/GitHub] → [Drone Server] → [Docker Runner] (开发环境) ↘ [K8s Runner] (生产环境) ↘ [SSH Runner] (特殊场景) 二、 注册 OAuth 应用 （Gitee为例） 登录 Gitee → 点击右上角头像 → 设置 → 第三方应用 → 创建应用 填写应用信息： 应用名称：Drone CI（自定义） 应用描述：Drone CI/CD 工具（自定义） 授权回调地址：http://你的服务器IP或域名/login（必须正确，否则无法登录） 应用主页：http://你的服务器IP或域名 权限选择：（最少权限原则）user_info，projects，pull_requests，hooks 提交后，记录生成的 Client ID 和 Client Secret（后续配置需要） 三、安装 Drone 服务器和 Runner Drone 由两部分组成： Drone Server：管理项目、接收仓库事件、协调任务 Drone Runner：执行流水线任务（编译、测试、部署等） 3.1 手动启动 Drone Server docker run -d \ --name drone-server \ --restart always \ -p 80:80 \ # 端口映射（生产环境建议加 HTTPS） -v /var/lib/drone:/data \ # 数据持久化 -e DRONE_RPC_SECRET=your_agent_secret \ # 自定义密钥（与 Runner 保持一致） -e DRONE_GITEE_CLIENT_ID=你的Gitee Client ID \ # 替换为 Gitee 应用的 Client ID -e DRONE_GITEE_CLIENT_SECRET=你的Gitee Client Secret \ # 替换为 Gitee 应用的 Secret -e DRONE_GITEE_SERVER=https://gitee....

轻量级容器编排工具指南 在 Docker 环境中，除了 K8s，还有多种轻量级方案可以实现服务自动重启、健康检查等功能，特别适合单机或中小规模部署。 一、简单方案 1.1 Docker 自身的重启策略（最基础方案） Docker Engine 内置了容器重启策略，可直接在启动容器时配置，实现容器退出后自动重启。 常用重启策略： --restart always：无论容器因何种原因退出（包括正常退出），总是自动重启。 --restart on-failure[:max-retries]：仅在容器以非 0 状态码退出时重启，可选最大重试次数（如on-failure:3最多重启 3 次）。 --restart unless-stopped：除非手动执行docker stop，否则始终重启（包括 Docker daemon 重启时） 示例： # 启动PHP容器，配置always重启策略 docker run -d \ --name php-app \ --restart always \ # 核心：容器挂掉后自动重启 -p 80:80 \ -v /path/to/php/code:/var/www/html \ php:8.2-apache 优势： 零依赖，直接使用 Docker 原生功能，适合单机部署。 局限： 仅能监控容器本身是否存活，无法检测应用内部故障（如 PHP-FPM 假死但容器仍运行）。 1.2 ocker Compose（适合多容器应用） 如果 项目依赖其他服务（如 MySQL、Redis），可使用docker-compose管理，通过配置restart参数实现自动重启，同时支持健康检查。 docker-compose.yml示例： version: '3.8' services: php-app: image: php:8.2-apache restart: always # 容器退出后自动重启 ports: - "80:80" volumes: - ....

EFK 技术栈深度解析：从原理到 PHP 应用的全流程实践 日志系统是现代企业级应用不可或缺的基础设施，它如同软件系统的 “黑匣子”，记录着系统运行的每一个关键节点。在众多日志解决方案中，EFK 技术栈以其轻量级、高性能的特点，成为容器化环境和高并发场景下的首选方案。本文将从 EFK 的核心概念出发，详细阐述其安装配置流程，并结合 PHP 开发场景，展示如何将 EFK 集成到实际项目中。 一、EFK 技术栈核心概念与架构解析 EFK 是 Elasticsearch、Fluentd 和 Kibana 三个开源组件的组合缩写，作为 ELK 技术栈的优化变种，它将 Logstash 替换为更轻量级的 Fluentd，形成了更适合现代云原生环境的日志处理体系。 1.1 EFK 各组件功能定位 Elasticsearch：分布式日志存储与检索引擎 基于 Lucene 的分布式文档存储系统，支持 PB 级日志数据的存储与检索 采用倒排索引结构，实现毫秒级日志搜索响应 天生支持集群架构，通过分片和副本机制保证高可用性 提供 RESTful API 接口，方便与 PHP 等语言集成 Fluentd：高性能日志收集与处理管道 用 C 语言开发的轻量级日志收集器，内存占用仅为 Logstash 的 1/10 支持 “一次写入，多次输出” 的 Buffer 机制，确保日志不丢失 插件化架构支持 150 + 数据源，包括 PHP 应用、MySQL、Kafka 等 内置 JSON 格式标准化处理，解决多源日志格式不一致问题 Kibana：可视化日志分析与监控平台 为 Elasticsearch 提供图形化查询界面，支持 DSL 语句可视化构建 内置多种可视化组件（折线图、仪表盘、拓扑图等） 支持基于日志数据的实时告警规则配置 提供日志模式识别功能，自动发现异常日志模式 1....

基于 Gogs + Jenkins + Harbor + Docker 的自动化部署方案 1. 系统架构总览 开发者提交代码 → Git仓库 → Jenkins触发构建 → Docker构建镜像 → 推送至Harbor → Kubernetes部署更新 → 监控反馈 2. 环境准备 2.1 硬件要求 最低配置：2核CPU/4GB内存/100GB存储 推荐配置：4核CPU/8GB内存/200GB SSD 3. 组件安装与配置 3.1 Gogs 安装 另外一篇Jenkins 使用 3.2 Jenkins 安装 另外一篇Gogs 使用 3.3 Harbor 安装 另外一篇Harbor 使用 4. 环境配置 下面以wordpress项目为例 wordpress/ ├── app/ # 项目代码 ├── docker # Docker 相关文件 | ├── Dockerfile | ├── entrypont.sh | └── nginx.conf | └── nginx-wordpress....

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

为什么需要私有 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、复制等企业级能力。...

单独使用 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 每个服务运行在独立容器中。...

GitHub 不只是代码托管平台 很多开发者使用 GitHub 时，主要把它当成远程 Git 仓库： git push ↓ GitHub 但对于一个真正需要长期维护的项目来说，代码仓库只是 GitHub 的一部分。 一个完整的软件开发过程通常还包括： 需求 ↓ Issue ↓ 开发 ↓ Pull Request ↓ Code Review ↓ CI ↓ Merge ↓ Release ↓ 用户 GitHub 恰好把这条链路中的多个环节连接起来。 其中： Issue 负责描述和跟踪工作； Pull Request 负责提交代码变更； Code Review 负责验证代码； Actions 负责自动化检查； Ruleset 负责约束仓库规则； Release 负责向用户交付稳定版本。 GitHub 官方也将 Pull Request 模板、Code Owners、受保护分支和 Rulesets 作为标准化 Pull Request 和保护重要分支的重要工具。(GitHub：管理和标准化 Pull Request) 因此，GitHub 工程化的核心并不是「会使用多少 GitHub 功能」，而是建立一条可追踪、可审查、可自动化、可发布的软件交付流程。 Issue：把需求和问题变成可追踪任务 Issue 是项目管理的起点。...