防止在错误主机上运行Ansible playbook的好策略

52次阅读

问题描述

在使用Ansible时，有时会面临在错误主机上运行playbook的问题。虽然可以使用--limit参数来确保只选择特定的主机，但是有些用户不太信任这种方式，担心Ansible可能仍然会在意外的主机上运行playbook。用户在思考是否有更加合理的方法来实现这一目标。

解决方案

请注意以下操作中可能的版本差异，并确保在执行任何更改之前进行备份。

物理隔离环境

要安全地确保playbook只在预期的主机上运行，最安全的方法是在物理上隔离不同的环境。这可能包括使用防火墙进行隔离。然而，这种方法可能不太现实，特别是如果你需要保持Ansible可能使用的SSH或其他连接。

配置级别的解决方案

在配置级别，有多种选项可供选择：

1. 使用特定用户

创建一个专门用于更新目的的用户，例如ansible_update。根据你的环境，将DEFAULT_REMOTE_USER配置为ansible_update。这样可以确保不会意外连接到其他系统。此外，通过将其公钥放入远程主机上用户ansible_update的authorized_keys文件中，可以控制谁可以连接到这些系统。为了实施这一点，你需要：

监控远程主机上的用户和他们的authorized_keys文件。
扫描你的项目（playbooks、roles、inventory、配置）以查找除ansible_update之外的远程用户。

2. 堡垒主机

更好的选择是创建一个堡垒主机，并使其成为环境配置的唯一来源。通过将所有的配置信息集中到堡垒主机，可以更好地控制playbook的执行。

3. 使用ansible-pull

最灵活的方法是配置远程主机，使其能够自行拉取更新。这样，每个远程主机将根据自己的需要拉取更新，而不是等待控制机器推送。

示例脚本

以下是一个简单的bash脚本示例，用于在容器A启动后启动容器B：

#!/bin/bash
# 启动容器A
docker run -d --name container_a your_image_a
# 等待容器A完全启动
while ! docker exec container_a echo "Container A is ready"; do
  sleep 1
done
# 启动容器B
docker run -d --name container_b your_image_b

在上面的示例中，我们首先使用docker run命令启动容器A，并将其命名为container_a。然后，使用一个循环来等待容器A完全启动（这里是通过在容器内运行echo命令来测试）。一旦容器A就绪，我们再使用docker run命令启动容器B，并将其命名为container_b。