CentOS7初始化脚本实战：服务器交付标准化与运维自动化

这几年代维Linux服务器，遇到最多的一个场景不是某个服务挂了，而是“又来了一台新的CentOS7，又要从头配环境”。手动执行命令轻则耗时，重则漏配置。为了让新机器从装好系统到能跑业务之间的过程可控、可复现，我把多年积累的初始化步骤沉淀成了一套脚本。这套脚本覆盖机器名、时区、软件源、用户登录策略、系统参数、安全加固、常见运行环境等模块，执行完成后只需要做少量人工核对。这篇就完整分享一下这套CentOS7初始化脚本的设计过程、关键代码和我在大量机器上实际跑出来的经验，适合正在摸索服务器交付标准化的运维和有意愿把重复操作脚本化的后端开发参考。

1. 为什么新装的CentOS7必须做一套初始化

1.1 默认安装的CentOS7离业务运行还有多远

很多人刚拿到一台CentOS7服务器，第一件事就是登录上去开始安装业务依赖。结果会发现最小化安装的系统非常“干净”，干净到连 vim、wget、unzip、net-tools 这些日常排查必需的软件都没有。有时候网络不通，我想用 ifconfig 看一眼网卡，发现命令不存在；想用 yum install 装个包，又因为源没配置好报错。基础环境不先铺好，后面每一步都会受阻。

CentOS7默认时间经常是UTC，如果不改成中国时区，日志时间和监控系统对不上。主机名如果不统一命名，后续做CMDB资产管理和自动化巡检会非常痛苦。软件源默认指向官方，一旦官网仓库不可达或者速度很慢，yum 基本就废了。也就是说，系统虽然“装完了”，但离“能安心部署业务”还差着十几个基础步骤。

1.2 我把初始化范围划分为五类

在整理脚本前，我先明确了初始化脚本的边界，不是让它去部署业务应用，而是把一个通用、干净的“宿主机底座”交付出来。具体分五类：

• 身份与基础信息：主机名、时区、DNS、hosts文件、语言环境。
• 软件获取链路：yum 源、epel 源、缓存清理，保证后续能用包管理器装东西。
• 基础操作工具：vim、wget、curl、unzip、sysstat 等常用命令。
• 系统安全策略：SELinux模式、SSH登录加固、防火墙端口、公钥免密。
• 资源限制与内核参数：文件句柄数、TCP链接优化、内核参数持久化。

业务中间件如MySQL、Redis、Nginx等，不应该都塞进初始化脚本。初始化脚本管的是“环境”，业务部署建议用单独的编排工具来管理。职责清晰，脚本的可维护性才高。

1.3 为什么建议用脚本而不是手写文档

我早期的做法是写一份《新机器初始化操作文档》，让团队成员照着敲。后来发现不同人执行出来的机器总有些细微差别：有人漏改时区，有人忘了关NetworkManager对网卡的影响，有人多装了一些和业务没关系的包。文档很难约束所有人每一步都做一致。

脚本化之后，机器状态完全由代码决定。只要代码评审通过，执行出来的结果就是一致的。脚本还可以放到Git仓库管理，改版有记录，出问题能回溯。这个收益在只有几台机器时还不明显，等到了几十上百台规模，影响就非常明显了。

2. 初始化脚本的模块划分与幂等设计

2.1 我采用的目录结构

写初始化脚本最怕的就是一个大shell文件从上到下几千行，后面想改某一部分要找半天。所以我从一开始就做了模块化：主入口只做调度，配置项单独放一个文件，公共函数提取到lib目录，每个功能模块单独放一个脚本。

text复制/opt/centos-init/
├── main.sh
├── config.env
├── lib
│   └── common.sh
├── modules
│   ├── 01-base.sh
│   ├── 02-repo.sh
│   ├── 03-security.sh
│   └── 04-runtime.sh
└── logs

main.sh 负责读取配置并逐个执行模块。config.env 集中管理机器名、源地址、是否需要安装Docker等变量。modules 下每个脚本只做自己的事，比如 02-repo.sh 只处理yum源。这样的结构写起来不累，维护起来也很清晰。哪天不想执行某个模块，直接在 main.sh 里注释掉对应行即可。

2.2 main.sh和config.env两个基础文件

main.sh 是我所有初始化动作的入口，里面的逻辑很简单：

bash复制#!/usr/bin/env bash
BASE_DIR=$(cd "$(dirname "$0")" && pwd)
source "${BASE_DIR}/config.env"
source "${BASE_DIR}/lib/common.sh"

log "========== CentOS7 初始化开始 =========="

for module in "${BASE_DIR}"/modules/*.sh; do
    log "执行模块: $(basename "$module")"
    if bash "$module"; then
        log "模块完成: $(basename "$module")"
    else
        log "模块失败: $(basename "$module")"
    fi
done

log "========== CentOS7 初始化结束 =========="

由于每个模块脚本都会独立执行，我会在每个模块开头重新 source 一次 config.env 和 common.sh，这样单独调试某个模块时也很方便。

config.env 是关键的配置中心，我通常这样定义变量：

bash复制# 主机名、时区、DNS
HOSTNAME="test-node-01"
TIMEZONE="Asia/Shanghai"

# yum源地址，公司有内网源就改成内网地址
CENTOS7_MIRROR_BASE="https://mirrors.tuna.tsinghua.edu.cn/centos-vault/7.9.2009"
EPEL_MIRROR_BASE="https://mirrors.tuna.tsinghua.edu.cn/epel/7"

# SSH策略
SSH_PORT="22"
SSH_PUBLIC_KEY=""

# 可选组件
INSTALL_DOCKER="false"
INSTALL_JDK="false"

变量和逻辑分开的好处，是以后新来的同事不需要读懂整个shell脚本逻辑，只要改 config.env 就能适配一台新机器。这种“小配置、大逻辑”的方式比在大段脚本里硬编码参数好维护得多。

2.3 幂等性是这个脚本的命根子

我要求脚本必须能重复执行，这是基于一个很现实的场景：初始化到一半网络断了，或者某一步因为手误写错了，修复后需要重新执行整个脚本。如果脚本不具备幂等性，第二次执行就会出各种问题。

幂等性要靠开关判断来实现。比如配置主机名时先读当前主机名，如果已经一致就跳过；配置SSH公钥时先检查公钥是否已存在再追加；写系统参数时先判断参数是否已经生效。举个例子：

bash复制if [ "$(hostname)" != "${HOSTNAME}" ]; then
    hostnamectl set-hostname "${HOSTNAME}"
fi

if systemctl is-active --quiet chronyd; then
    log "chronyd 已在运行，跳过启动"
else
    systemctl enable --now chronyd
fi

这样处理看起来只是多加了几行判断，但在真正执行时能省下大量排查时间。初始化脚本本身是给“不可控环境”用的，更要让自己先变得可控。

2.4 执行前的系统自检

我不建议拿到什么机器都无脑跑脚本。脚本开头的自检能避免很多尴尬问题。比如，确认当前用户是root、确认系统是CentOS7、确认能联网。我习惯在 lib/common.sh 里写几个基础检查函数：

bash复制check_root() {
    if [ "$(id -u)" -ne 0 ]; then
        echo "请使用root用户执行脚本"
        exit 1
    fi
}

check_os() {
    if ! grep -q "release 7" /etc/redhat-release; then
        echo "当前系统不是CentOS7，禁止执行初始化脚本"
        exit 1
    fi
}

网络检查也可以放进去，但不是必须的，因为有些离线环境跑初始化脚本也有自己的方案。我会把网络检查做成带超时的判断，超时就提示用户当前执行环境可能无法访问外网，让用户决定是否继续。

3. 核心模块逐项拆解与实现逻辑

3.1 基础信息模块：主机名、时区和时间同步

基础信息模块主要干三件事：设置主机名、设置时区、启用时间同步。主机名影响日志和内网解析，时区影响业务日志时间，时间同步影响认证和分布式系统。这三件事看起来简单，但漏掉任何一件，后面业务部署后都可能出现怪问题。

我常写的 01-base.sh 核心代码如下：

bash复制#!/usr/bin/env bash
BASE_DIR=$(cd "$(dirname "$0")/.." && pwd)
source "${BASE_DIR}/config.env"
source "${BASE_DIR}/lib/common.sh"

check_root

# 主机名
if [ "$(hostname)" != "${HOSTNAME}" ]; then
    hostnamectl set-hostname "${HOSTNAME}"
    if ! grep -q "${HOSTNAME}" /etc/hosts; then
        echo "127.0.0.1 ${HOSTNAME}" >> /etc/hosts
    fi
fi

# 时区
if [ "$(timedatectl show -p Timezone --value)" != "${TIMEZONE}" ]; then
    timedatectl set-timezone "${TIMEZONE}"
fi

# 时间同步：优先使用chrony
if ! rpm -q chrony &>/dev/null; then
    yum install -y chrony
fi
systemctl enable --now chronyd

这里有一个容易被忽略的细节：改主机名后，最好同时把主机名追加到 /etc/hosts。这是因为很多Java应用和消息队列组件会做反向解析，如果 /etc/hosts 里没有主机名对应的记录，部分组件启动会出现超时或者报unknown host。这个坑我在部署一些中间件时踩过不止一次。

3.2 yum源配置模块：要能处理官方仓库失效的情况

CentOS7官方源在系统生命周期结束后会大量迁移到archive.centos.org或者vault目录，访问速度会变慢甚至不可用。尤其这两年很多还在用CentOS7的生产环境，第一个要处理的就是仓库源。现在做初始化脚本，我会把源直接指到国内可用的CentOS vault镜像，例如清华镜像、阿里云镜像，然后根据实际环境替换源地址。

02-repo.sh 的做法分三步：备份旧repo文件、写入新的repo文件、清理缓存重新生成缓存。

bash复制#!/usr/bin/env bash
BASE_DIR=$(cd "$(dirname "$0")/.." && pwd)
source "${BASE_DIR}/config.env"
source "${BASE_DIR}/lib/common.sh"

# 备份旧的repo文件
mkdir -p /etc/yum.repos.d/backup
mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/ 2>/dev/null || true

# 写入基础源
cat > /etc/yum.repos.d/CentOS-Base.repo <<EOF
[base]
name=CentOS-\$releasever - Base
baseurl=${CENTOS7_MIRROR_BASE}/os/\$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

[updates]
name=CentOS-\$releasever - Updates
baseurl=${CENTOS7_MIRROR_BASE}/updates/\$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

[extras]
name=CentOS-\$releasever - Extras
baseurl=${CENTOS7_MIRROR_BASE}/extras/\$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
EOF

# 如果启用epel，追加epel源
cat > /etc/yum.repos.d/epel.repo <<EOF
[epel]
name=EPEL for CentOS 7
baseurl=${EPEL_MIRROR_BASE}/\$basearch/
gpgcheck=0
enabled=1
EOF

yum clean all
yum makecache

关于 gpgcheck=0，虽然官方不推荐，但在离线源或内网源场景经常用0，这个由团队的源可信度决定。如果是公网源，我更建议保留gpgcheck=1。脚本里我把EPEL的校验临时设为了0，这只是为了减少key文件缺失带来的报错，生产使用时应按实际情况把key导入并改回1。

3.3 安全加固模块：SELinux、SSH和防火墙

安全加固模块是我在脚本中反复迭代最多的模块。CentOS7默认SELinux是enforcing，但很多第三方软件或者老旧业务并不兼容强制模式。运维界常见做法是直接禁用SELinux，这个方式虽然省事，但对安全性要求高的环境其实不友好。我的脚本把SELinux模式做成可配置项，默认保留enforcing，只有确认业务无法兼容并知晓风险后才建议改成disabled。

bash复制#!/usr/bin/env bash
BASE_DIR=$(cd "$(dirname "$0")/.." && pwd)
source "${BASE_DIR}/config.env"
source "${BASE_DIR}/lib/common.sh"

# SELinux策略
# 可选: enforcing / permissive / disabled
SELINUX_MODE="enforcing"
if [ "$(getenforce)" != "$SELINUX_MODE" ]; then
    if [ "$SELINUX_MODE" == "disabled" ]; then
        sed -i 's/^SELINUX=.*/SELINUX=disabled/g' /etc/selinux/config
    else
        setenforce "$SELINUX_MODE"
        sed -i 's/^SELINUX=.*/SELINUX='"$SELINUX_MODE"'/g' /etc/selinux/config
    fi
fi

# 防火墙放行指定SSH端口
systemctl enable --now firewalld
if ! firewall-cmd --zone=public --query-port="${SSH_PORT}/tcp" >/dev/null 2>&1; then
    firewall-cmd --zone=public --add-port="${SSH_PORT}/tcp" --permanent
    firewall-cmd --reload
fi

# SSH免密登录和加固
if [ -n "$SSH_PUBLIC_KEY" ]; then
    mkdir -p /root/.ssh
    chmod 700 /root/.ssh
    if ! grep -qF "$SSH_PUBLIC_KEY" /root/.ssh/authorized_keys 2>/dev/null; then
        echo "$SSH_PUBLIC_KEY" >> /root/.ssh/authorized_keys
    fi
    chmod 600 /root/.ssh/authorized_keys

    # 修改SSH端口前，务必要确保防火墙已经放行
    sed -i 's/^#Port 22/Port '"${SSH_PORT}"'/' /etc/ssh/sshd_config
    grep -q "^Port ${SSH_PORT}" /etc/ssh/sshd_config || echo "Port ${SSH_PORT}" >> /etc/ssh/sshd_config

    # 禁止密码登录，生产环境请确认已配置密钥
    sed -i 's/^PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
    systemctl reload sshd
fi

关于SSH加固，这里一定要提醒：修改SSH端口和关闭密码登录之前，务必确认当前SSH会话不会因为配置错误断开。初始化脚本的排查性当然要做，但如果只是靠脚本跑一次，把管理员挡在门外的事件不是没发生过。我的经验是把配置下发逻辑写好后，先在测试机上验证强制断开重连是否能正常登录，再拿去批量执行。

3.4 系统参数与常用软件模块

CentOS7默认文件句柄数限制在某些高并发场景下不够用，比如Java应用、文件服务、消息队列等。初始化脚本里把limits和内核参数一起调好，可以避免很多业务上线之后才发现的隐性故障。

我常用的一段配置是把所有用户的软硬文件句柄提高到65535，并调整一些常见内核参数：

bash复制cat > /etc/security/limits.d/99-init.conf <<EOF
* soft nofile 65535
* hard nofile 65535
* soft nproc 65535
* hard nproc 65535
EOF

cat > /etc/sysctl.d/99-init.conf <<EOF
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 8192
fs.file-max = 1000000
EOF

sysctl --system

还有一个容易被忽略的坑：修改limits后，已经登录的会话不会自动生效。脚本里我会提示执行完初始化后先注销重新登录，再验证 ulimit -n。如果脚本本身从一个长连接SSH会话里执行，后续服务也可能残留旧限制，所以验证是必不可少的。

基础工具安装我放在独立函数里，避免在每台机器上重复输出一长串软件名。常用的安装清单大概是：

bash复制yum install -y \
    vim wget curl net-tools \
    unzip zip bzip2 xz \
    tree lsof lrzsz \
    sysstat iotop iftop \
    yum-utils device-mapper-persistent-data lvm2

这里列出这些工具的目的是提高基础环境可排查性，但实际情况建议按团队需求精简。装太多软件并不代表初始化做得好，反而会增加系统的攻击面。

3.5 运行环境模块：按需安装Docker或JDK

脚本的第四类模块是运行环境，默认不启用。因为不是所有机器都需要Docker，也不是所有机器都需要JDK。我用 config.env 里的开关控制，比如 INSTALL_DOCKER=true 时才执行。

安装Docker时，CentOS7系统要注意的是内核版本和containerd的兼容性。通常我会先安装 yum-utils，再通过yum-config-manager添加Docker官方仓库，然后安装 docker-ce。如果是在内网环境，建议直接下载对应版本的rpm包传到机器上本地安装，避免在线源不稳定。

bash复制if [ "${INSTALL_DOCKER}" == "true" ]; then
    yum install -y yum-utils
    yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
    yum install -y docker-ce docker-ce-cli containerd.io
    systemctl enable --now docker

    mkdir -p /etc/docker
    cat > /etc/docker/daemon.json <<EOF
{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  }
}
EOF
    systemctl restart docker
fi

这里把cgroupdriver设置成systemd，是考虑到大部分团队后面会用Kubernetes管理容器，而K8s官方对systemd cgroup driver的支持更完善，初始化阶段就把这个统一掉，能省去很多后面调整的麻烦。日志驱动设置最大文件大小，可以防止容器日志无限增长把磁盘打满。

JDK安装模块我用的是离线tar包加环境变量配置，这样不受yum源影响。tar包路径在config.env通过变量控制，脚本只负责解压、移动到统一目录、设置JAVA_HOME并写入/etc/profile.d/java.sh。初始化脚本能自动化的绝不要让人工去填路径，否则换一台机器又得重新对一遍。

4. 我在执行过程中踩过的坑和排查方法

4.1 yum repolist一片红的排查链路

刚整理脚本时，我遇到最多的问题是yum源配置完，执行yum makecache直接报404。当时第一个反应是镜像地址是不是写错了，后来逐个排查原因发现，问题几乎都出在“源路径层级不对”和“releasever替换失败”上。

CentOS7的yum源地址通常带7.9.2009这样的版本号，或者直接用$releasever这个变量。如果不小心在repo文件里写了releasever=7.9.2009，源路径变成/7.9.2009/os/x86_64是对的；但如果镜像目录结构是/centos-vault/7.9.2009/os/x86_64，那REPO baseurl就必须完整包含整个路径。我的排查思路是：先确认curl能不能访问到baseurl下的repodata目录，能访问说明网络通且路径对；不能访问就往镜像目录结构方向查。

排查命令是这些：

bash复制curl -I https://mirrors.tuna.tsinghua.edu.cn/centos-vault/7.9.2009/os/x86_64/repodata/repomd.xml

如果curl通但yum报404，很大概率是repo文件里的$basearch或$releasever被错误转义了。初始化脚本里我用heredoc写repo文件时，如果不加引号，shell会先展开$basearch和$releasever变量，这通常是空值，导致生成的repo文件路径缺失。解决办法是在heredoc的<<EOF处加引号，写作<<'EOF'，让变量延迟到yum执行阶段再展开。这个细节我后来在脚本顶部统一加了一行注释提醒。

4.2 主机名和网络配置改动导致的SSH连接中断

初始化脚本会对主机名、hosts文件、SSH配置做调整。早期我在批量执行时，碰到过改完主机名后，SSH连接直接卡住的情况。原因其实不是主机名本身，而是很多云主机或虚拟机的/etc/hosts里写的是旧主机名和旧IP，改完主机名后反向解析失败，sshd处理连接变慢。

排查链路是这样的：先看systemctl status sshd有没有报错，再看/etc/hosts里是否还有旧主机名，最后看/etc/ssh/sshd_config有没有UseDNS yes这个配置。UseDNS yes会让SSH服务端对客户端IP做反向DNS解析，一旦内网DNS配置不完整，连接就会延迟或超时。我在初始化脚本中会把UseDNS改成no，并在修改网络相关配置时提醒执行者保留当前SSH连接不要退出。

4.3 脚本重复执行产生的脏配置

没有幂等设计的脚本，执行第二遍时很容易出问题。比如向 /etc/profile.d/java.sh 追加 JAVA_HOME，每次执行都追加一行，最后PATH越来越长；向 /root/.ssh/authorized_keys 重复写入同一个公钥，虽然不影响登录，但会让审计时看着很乱；反复向 /etc/security/limits.d/99-init.conf 写入相同内容，文件里出现多行重复配置。

解决这个问题没有捷径，就是对每个写配置的动作都加上“先检查、后写入”的判断。如果目标文件已存在，可以用sed替换而不是简单echo >>。我在 common.sh 里写了一个通用函数：

bash复制ensure_conf() {
    local key="$1"
    local value="$2"
    local conf="$3"
    if grep -q "^${key}=" "$conf" 2>/dev/null; then
        sed -i "s|^${key}=.*|${key}=${value}|" "$conf"
    else
        echo "${key}=${value}" >> "$conf"
    fi
}

这样每次重复执行时，系统参数配置始终是同一个状态。要养成第一版就把幂等性写进去的习惯，别想“反正只跑一次”，实际使用中没人能保证不重跑。

4.4 SELinux和防火墙策略的“隐形拦截”

我在测试脚本时遇到过这样一个案例：初始化脚本执行后，从另一个节点访问Nginx，怎么都连接不上。telnet端口不通，SSH登录正常，第一反应是防火墙没放行。但执行firewall-cmd --list-all发现端口已经放行了。

再往下查，才发现问题出在SELinux。虽然我习惯在脚本里把配置改成enforcing，但在测试环境中我为了验证权限问题临时改成了disabled。当时想着改完SELinux后重启服务就行，结果忘了setenforce 0只对当前运行态生效，重启系统后配置依然恢复到enforcing。Nginx的端口绑定和反向代理策略没有对应的SELinux布尔值，导致数据包被SELinux拦截。

这个教训让我意识到，SELinux配置不能在脚本里一拍脑袋写死。如果团队对SELinux没有统一策略，初始化脚本应该先探测当前系统的SELinux状态，并明确提示管理员，而不是默认关掉。生产环境请务必根据业务安全需求评估后再定，现在很多云上基线和等保要求都强制SELinux开启，脚本里直接disabled很吃亏。

5. 初始化完成后的验证清单和后续使用建议

5.1 我最常用的验证清单

初始化脚本不是跑完就算结束，越关键的改动越要人工过一遍验证。下面是我每次执行完初始化脚本后都会跑的核对项：

建议把这张表放进团队的交付文档。初始化脚本加上人工确认核对，才算一个完整的闭环。否则脚本只能保证“命令执行了”，不能保证“状态是对的”。

5.2 如何让脚本长期发挥作用

我习惯把初始化脚本存放在Git仓库而不是放在某台服务器目录里。凡是修改都走提交记录，统一包含责任人、修改原因、影响范围。新机器要初始化时，把Git仓库拉下来，修改config.env里的主机名和IP，再执行main.sh即可。通过这种方式，脚本会随着实际运维经验持续演进，而不是写一次就再也不维护。

当然，脚本只是一个运维提效的小工具。如果团队机器规模上来，我更推荐把它迁移到更专业的配置管理工具中，例如Ansible的playbook或者云平台的初始化模板。实际上，这套脚本的逻辑在被封装成Ansible playbook后，依然可以作为“角色”保留，config.env里的变量对应成Ansible的group_vars，模块脚本转为task文件，原有设计完全能平滑平移。

5.3 我这套脚本执行下来的一些体会

使用这套CentOS7初始化脚本两年多，我最大的感受是：脚本解决的不只是“手工操作慢”的问题，更重要的是让每台机器“初始状态”变得可以预期。以前排查问题，第一件事是问“这台机器之前是谁装的，都改过什么”；现在直接看脚本版本就能知道这台机器的基础配置长什么样。标准化的价值，往往要在真正出故障时才能体会到。

对还没开始做机器初始化脚本的团队，我建议第一天就先做一个最小版本：只要包含设置主机名、配置时区、yum源、SSH免密和基础工具安装就够了。不要一上来就追求把所有中间件都写进脚本，边界越清晰，这个脚本的生命周期才会越长，维护成本也更低。