AnushaJoseph-00/netflix-cicd-pipeline

# Netflix 克隆项目 - AWS 上的 CI/CD Pipeline 在 AWS 上从零开始构建的端到端 CI/CD pipeline，使用 Jenkins、SonarQube、Nexus 和 nginx。每次构建都会经过测试、质量门禁检查、版本控制，并部署到线上的服务器。 ## 工作原理 1. 开发者将代码推送到 GitHub 2. Jenkins 克隆源代码（Checkout 阶段） 3. Jenkins 将代码发送给 SonarQube 进行静态分析 4. SonarQube 通过 webhook 返回质量门禁结果 5. Jenkins 将生产环境的构建文件压缩，并按构建版本号存储到 Nexus 中 6. Jenkins 通过 SSH 向应用服务器发送部署命令 7. 应用服务器从 Nexus 获取构建产物 8. 最终用户通过 HTTP 浏览线上站点  ## AWS 基础设施 - **Jenkins 服务器** - EC2 t3.medium，端口 8080。在 Java 21 上运行 Jenkins，包含 NodeJS 16 工具链、sonar-scanner 和 zip。 - **SonarQube 服务器** - EC2 t3.medium，端口 9000。在 Java 21 上运行 SonarQube，并使用 PostgreSQL 作为后端数据库。 - **Nexus 服务器** - EC2 t3.medium，端口 8081。在 Java 17 上运行 Nexus 3，包含一个用于存储构建产物的 raw hosted repository。 - **App server** - EC2 t3.micro，端口 80（公开访问）。仅运行 nginx 和 unzip，因为构建产物是预编译的静态内容。 所有服务器之间的通信均使用私有 IP，并配置了安全组到安全组的规则：Jenkins 访问 SonarQube 使用端口 9000，SonarQube 通过 webhook 访问 Jenkins 使用端口 8080，Jenkins 访问 Nexus 使用端口 8081，app server 访问 Nexus 使用端口 8081，Jenkins 通过端口 22 连接 app server。只有 app server 的端口 80 对互联网开放。 ## Pipeline 阶段  1. **Checkout** – Jenkins 从 GitHub 下载最新代码 2. **Install Dependencies** – 下载应用所需的所有库（npm install） 3. **Unit Tests** – 运行自动化测试；如果任何测试失败，pipeline 将在此停止 4. **Sonar Code Analysis** – SonarQube 扫描代码中的 bug、安全漏洞和不良实践 5. **Quality Gate** – SonarQube 给出通过或失败的判定；如果失败则停止 pipeline 6. **Build** – 将应用编译为生产环境可用的文件，并从 Jenkins 凭据中安全地注入 API key 7. **Upload to Nexus** – 将构建好的应用打包压缩，分配版本号，并存储到 Nexus 中 8. **Deploy** – app server 从 Nexus 下载压缩包并将其部署到线上的网站 部署始终从构建产物存储库中拉取，而不是从构建工作区中拉取，因此任何已存储的版本都可以被重新部署。回滚（Rollback）意味着部署一个旧版本的压缩包。 Pipeline-as-a-code 位于 Jenkinsfile 中。 ## 设置说明 **应用程序** - 克隆了一个基于 React 和 TMDB 的 Netflix 克隆项目。上游仓库硬编码并公开暴露了其 TMDB API key，因此我们将该 key 移到了环境变量中，将 `.env` 文件添加到 gitignore，并在 CI 中通过 Jenkins 凭据提供该 key。 **Jenkins** - 在实例启动时通过 user data 脚本安装，遵循 Jenkins 官方的 Linux 安装文档 - 包括 Java 运行环境、Jenkins 的 apt repository key 和源，以及 Jenkins 软件包本身，并设置该服务在开机时自动启动。 - 使用带有 Java 21 的 Ubuntu 24.04，这是 Jenkins 2.543 及更高版本的要求；使用当前的 `jenkins.io-2026` 签名密钥添加了 repository。 - 使用的插件：NodeJS、SonarQube Scanner 和 SSH Agent。 - 所有密钥（SSH 凭据、SonarQube token）都存储在 Jenkins 凭据存储中，并在构建日志中进行脱敏处理。 **SonarQube** - 在实例启动时通过 user data 脚本安装 - 包含一个专用的非 root 服务用户、PostgreSQL 作为后端存储、根据 SonarQube 官方文档配置的 systemd unit、token 认证，以及一个指向 Jenkins 私有 IP 的 webhook。 **Nexus** - 在实例启动时通过 user data 脚本安装，遵循 Sonatype 官方安装文档 - 包含带版本号的下载、专用的 nexus 服务用户、systemd unit，以及一个用于存储 zip 产物的 raw hosted repository。 **App server** -仅包含 nginx 和 unzip。 这四个实例的配置脚本位于 infra 文件夹中。 ## AWS 实例  ## 后续计划 - 零停机部署 - 使用 Terraform 和 Ansible 替代 user-data 配置方式 ## 线上网站  ## 关键收获 - **Pipeline as code** - 整个构建、测试和部署过程都定义在 存储在此 repository 中的 Jenkinsfile 里，而不是在 UI 界面中手动拼接出来的 - **质量强制执行** - 单元测试失败或 SonarQube 质量门禁未通过，都会在任何内容被构建或部署之前停止 pipeline - **产物带有版本且不可变** - 每次构建都会在 Nexus 中生成一个带编号的 zip 包；部署始终来自产物存储库，因此任何版本都可以被重新部署， 回滚仅仅是部署一个旧版本的构建 - **密钥绝不接触代码** - API key、Nexus 凭据和 SSH 密钥都 存储在 Jenkins 凭据库中，并在 runtime 注入，在日志中进行脱敏处理 - **基础设施有文档且可复现** - 每台服务器都是根据 保存在此 repository 中的配置脚本构建的；服务器是可替换的，此 repository 才是 唯一事实来源 - **网络通过身份锁定** - 各服务通过私有 IP 进行通信，并采用 安全组到安全组的规则；只有 app server 的端口 80 面向互联网 ## 这在实际工作中的对应场景 - **工作流**：开发者推送代码，自动化接管流程，经过测试、 扫描、带有版本号的发布版本到达服务器，期间无需任何手动干预 - 这与任何软件公司的生产环境交付 pipeline 形式相同 - **工具链**：Jenkins、SonarQube 和 Nexus（或其等效工具，如 GitHub Actions 和 Artifactory）是标准的 enterprise CI/CD stack - **关注点分离**：构建服务器、质量检测服务器、构建产物存储库， 以及作为独立服务的部署目标 - 这正是真实平台的架构方式， 而不是由一台机器包揽所有工作 - **运维现实**：版本要求、下载 endpoint 变更、内存压力、防火墙规则和凭据管理 ## 鸣谢 UI 基于由 vishnusatheeshpulickal 开发的 React 和 TMDB Netflix 克隆项目。本项目是围绕其构建的 CI/CD pipeline、基础设施和自动化。

标签：AWS, DPI, Jenkins, JS文件枚举, MITM代理, Nexus, SonarQube, 人体姿态估计, 安全专业人员, 测试用例, 特权提升, 网络安全研究, 自动化部署, 自定义脚本