linux自动化部署核心是代码托管、流程编排、配置落地三类协同；用git管理代码与配置，ansible实现声明式部署，ci/cd工具（如gitlab ci）触发流水线，shell脚本辅助一次性系统准备。
Linux自动化部署的核心是把“人手操作”变成“机器执行”，关键靠三类协同：代码托管、流程编排、配置落地。不依赖人工登录服务器敲命令，而是用标准化脚本+声明式配置+触发机制，让部署可重复、可追溯、可批量。
用Git管好代码和配置
所有要部署的代码、配置文件（如Nginx配置、环境变量、启动脚本）必须纳入Git仓库。这不是可选项——没有版本控制的自动化，等于在沙上建塔。
- 仓库结构建议包含：
src/（源码）、config/（环境相关配置）、scripts/（构建与部署脚本） - 分支策略推荐：
main对应生产环境，staging对应预发，每次合并都应触发对应环境的部署流水线 - 敏感信息（如数据库密码）不要硬编码进Git，改用Ansible Vault加密或CI/CD平台的密钥管理功能
用Ansible做配置落地和应用部署
Ansible是目前最主流的无代理配置管理工具，适合中小规模到中大型环境，语法清晰、学习成本低、SSH直连即可工作。
- 先写好
inventory文件，定义目标主机分组，例如：
[web]
app1.example.com ansible_user=deploy
app2.example.com ansible_user=deploy - 再写Playbook（YAML格式），比如
deploy.yml：拉代码、装依赖、复制配置、重启服务一气呵成 - 关键技巧：用
handlers控制服务重启时机（只在配置真正变更时才重启Nginx），用tags支持按需执行某几步（如只重跑“install_dependencies”）
用CI/CD工具串联整个流程
光有脚本还不够，得有人“看见代码提交就自动干活”。Jenkins、GitLab CI、GitHub Actions都是成熟选择，其中GitLab CI因与Git仓库深度集成，配置更轻量。
- 典型CI/CD流水线包含三个阶段：Build（编译打包或校验语法）、Test（运行单元测试或健康检查）、Deploy（调用Ansible或直接执行部署脚本）
- 示例GitLab CI片段（
.gitlab-ci.yml）：
deploy-staging:
stage: deploy
script:
- ansible-playbook -i inventories/staging deploy.yml - 务必设置
only或rules限制触发条件，避免开发提交临时分支就误推生产
补充：Shell脚本仍有一席之地
不是所有场景都要上Ansible。单机快速部署、初始化环境、离线安装、或作为Ansible内部调用的底层动作，Shell脚本依然高效可靠。
- 写法要点：开头加
#!/bin/bash -e（出错即停），检查关键命令返回值，用set -u防未定义变量 - 常见用途举例：
• 自动挂载数据盘并格式化
• 下载JDK并配置/etc/profile.d/java.sh
• 检查端口占用、清理旧日志、创建软链接 - 注意：Shell适合“一次性的系统准备”，不适合长期维护多节点状态一致性——那是Ansible的职责
