Bash脚本自动化实战：如何实现免人机交互的运维部署

共计 2198 个字符，预计需要花费 6 分钟才能阅读完成。

背景痛点

在日常运维和 CI/CD 流程中，我们经常遇到需要人工干预的场景，比如输入密码、确认操作等。这些交互步骤不仅效率低下，还容易出错。特别是在自动化部署过程中，频繁的人机交互会严重影响整体流程的顺畅性。

以一个典型的部署流程为例，可能需要：

1. SSH 登录远程服务器
2. 输入 sudo 密码
3. 确认文件覆盖
4. 选择安装选项

这些步骤如果全部手动操作，不仅耗时耗力，而且难以规模化。

技术对比

目前主流实现免交互的方案主要有三种：

• expect：通过模式匹配和响应实现交互自动化
• 优点：功能强大，能处理复杂交互

• 缺点：需要额外安装，脚本可读性稍差

• sshpass：直接在命令行中传递密码

• 优点：简单直接

• 缺点：安全性低，密码会出现在进程列表中

• 密钥对 ：使用 SSH 密钥认证

• 优点：安全性高，无需密码
• 缺点：需要提前配置，无法处理 sudo 等后续交互

对于大多数场景，expect 是最平衡的选择，既能处理复杂交互，又相对安全。

核心实现

expect 基础用法

以下是一个完整的 expect 脚本示例，用于自动化 SSH 登录和执行命令：

#!/usr/bin/expect

# 设置超时时间
set timeout 30

# 定义变量
set host "192.168.1.100"
set user "admin"
set password "yourpassword"

# 启动 ssh 进程
spawn ssh $user@$host

# 处理可能的交互
# 1. 首次连接时的 known_hosts 确认
expect {
    "*yes/no*" {
        send "yes\r"
        exp_continue
    }
    "*password:*" {send "$password\r"}
}

# 2. 登录后执行命令
expect "*$"
send "sudo apt update\r"

# 3. 处理 sudo 密码提示
expect "*password for*"
send "$password\r"

# 4. 等待命令完成
expect "*$"
send "exit\r"

expect eof

错误处理机制

使用 trap 实现优雅的错误处理：

#!/bin/bash

# 定义清理函数
cleanup() {
    echo "Cleaning up..."
    # 杀死所有子进程
    pkill -P $$
    exit 1
}

# 设置 trap 捕获信号
trap cleanup EXIT TERM INT

# 主逻辑
if ! expect -c '
    spawn ssh user@host
    expect "password:"
    send "mypassword\r"
    expect "$"
    send "sudo service nginx restart\r"
    expect "password for user:"
    send "mypassword\r"
    expect "$"
    send "exit\r"
    expect eof
';
then
    echo "Expect script failed"
    exit 1
fi

# 取消 trap
trap - EXIT TERM INT

生产级优化

敏感信息加密

1. 使用环境变量存储密码：

#!/bin/bash

export DEPLOY_PASSWORD="$(ansible-vault view --vault-password-file ~/.vault_pass.txt secrets.yml | grep deploy_pass)"

expect -c "
    spawn ssh deploy@server
    expect \"password:\"
    send \"$DEPLOY_PASSWORD\r\"
    ...
"

1. 日志重定向规范：

{expect -c "..."} > deploy.log 2>&1

超时控制

expect {
    timeout {
        puts "Connection timed out"
        exit 1
    }
    eof {puts "Connection closed"}
    "*password:*" {
        send "$password\r"
        exp_continue
    }
}

避坑指南

避免硬编码路径

1. 使用环境变量：

DEPLOY_DIR="${DEPLOY_DIR:-/opt/deploy}"

1. 相对路径 + 位置参数：

BASE_DIR="$(dirname"$0")"
CONF_FILE="$BASE_DIR/config.cfg"

1. 使用 which 定位可执行文件：

EXPECT_PATH="$(which expect)"

僵尸进程处理

在 expect 脚本结束时添加：

exec kill -HUP 0

或者使用如下 trap：

trap "kill -9 $(jobs -p)" EXIT

延伸思考

将这种自动化方案扩展到 Kubernetes 初始化场景时，可以考虑：

1. 使用 ConfigMap 存储 expect 脚本
2. 通过 Init Container 执行初始化操作
3. 使用 Secret 存储敏感信息
4. 通过 Kubernetes 的探针机制检查初始化状态

性能测试数据

从测试数据可以看出，自动化方案相比手动操作有显著提升，其中密钥对方案综合表现最好，但 expect 方案适用性最广。

总结

通过本文介绍的 Bash 脚本自动化技术，我们可以有效解决运维部署中的人机交互瓶颈。在实际应用中，建议根据具体场景选择合适的方案，并充分考虑安全性和可维护性。对于复杂场景，expect 仍然是功能最全面的选择。

记住：自动化不是目的，而是手段。真正的价值在于通过自动化释放人力，让团队可以专注于更有价值的工作。