Ansible Playbook的可移植性

2 年 ago
宇, 华
2 minutes

在Ansible中，我们使用Playbook来管理自动化的内容。

对于执行用户来说，只需获取此Playbook而无需预先配置即可执行，这是理想情况。

我们将进行一些准备工作，以避免需要为执行用户进行预先设置。这样一来，命令参数就会增加。

ANSIBLE_CONFIG="./ansible.cfg"
ansible-playbook --ssh-common-args="-o StrictHostKeyChecking=no" -i ./hosts TARGET.yml

随着选项的增加，如果不对选项进行配置管理，运营将变得不稳定。
为了保持稳定的运营，最理想的情况是将选项作为配置管理的对象，并能够仅通过以下命令来执行Ansible。

ansible-playbook TARGET.yml

在接下来的部分中，我们将介绍一种绕过执行用户的预设设置、对选项进行配置管理以及简化执行ansible-playbook的方法。

获取Playbook

我们将创建一个Playbook来管理配置，并在适当的权限控制下使用一行命令获取它。

git clone https://github.com/sonatard/ansible-sample.git

再将步骤详细记录在README.md文件中。

2. 通过hosts文件对执行对象进行管理。

默认情况下，hosts文件会从/etc/ansible/hosts中读取。
然而，如果将该文件用于管理操作，执行playbook的用户需要额外获取hosts文件并将其放置在上述路径中。

为了避免这种情况发生，将hosts文件放置在管理playbook的根目录下。

ansible-sample
├── README.md
├── ansible.cfg
├── TARGET.yml
├── group_vars
├── host_vars
├── hosts         ★
└── roles

可以按照以下方式来执行。

ansible-playbook -i ./hosts TARGET.yml

虽然每次执行命令，主机都是相同的，但我不想每次都指定“-i ./hosts”选项。
我会创建ansible.cfg，并添加以下配置。
我还会将其放置在与Playbook相同的目录中，并使其成为仓库的管理对象。

[defaults]
inventory = hosts

ansible-sample
├── README.md
├── ansible.cfg         ★
├── TARGET.yml
├── group_vars
├── host_vars
├── hosts
├── ssh_config
└── roles

通过这样做，可以自动地使用./hosts文件。

ansible-playbook TARGET.yml

ansible.cfg文件会在运行时自动加载，无需指定。
具体来说，ansible.cfg按以下优先级进行反映。

    1. 用于指定的文件的ANSIBLE_CONFIG环境变量

 

    1. ./ansible.cfg

 

    1. $HOME/ansible.cfg

 

    /etc/ansible/ansible.cfg

3. SSH选项

SSH的相关选项

有时候在使用Ansible时，可能想要传递SSH选项。

例如，在开发环境中，如果Ansible的目标IP经常变动，为了消除多余的警告，可以通过–ssh-common-args选项传递StrictHostKeyChecking no。

ansible-playbook --ssh-common-args="-o StrictHostKeyChecking=no" TARGET.yml

可以通过将ssh配置文件分离来进行设置。创建一个名为ssh_config的文件，并与Playbook存储在相同的存储库中进行管理。

Host *
  StrictHostKeyChecking no

ansible-sample
├── README.md
├── ansible.cfg
├── TARGET.yml
├── group_vars
├── host_vars
├── hosts
├── ssh_config         ★
└── roles

您可以使用 -F 选项指定 ssh_config 文件。

ansible-playbook --ssh-common-args="-F ssh_config" TARGET.yml

避免每次执行时指定–ssh-common-args=。创建一个ansible.cfg文件并设置ssh_args。

[ssh_connection]
ssh_args = -F ssh_config

以上的话，ssh_config文件将会被自动加载。

ansible-playbook TARGET.yml

4. SSH key management (SSH密钥管理)

要执行Ansible任务，需要通过SSH验证才能访问目标主机。

为了简化密码验证步骤，一般而言需要创建秘钥对（密钥和公钥）并将公钥注册到目标服务器上，将秘钥放置到Ansible执行环境用户的$HOME/.ssh/文件夹中。通过使用ssh-agent的方式，只需输入一次密码，即可高效完成操作。

ssh-agent不仅仅局限于Ansible，所以我将跳过这部分。

为了注册密钥，每个执行用户都需要进行必要的操作。因此，我们将创建一个角色，可以在Ansible的所有执行目标上一次性完成密钥注册的工作。

- name: Add user authorized_keys to ${HOME}/.ssh/authorized_keys
  authorized_key:
    user: "{{ user.name }}"
    key: "{{ lookup('file', '/home/user/ssh/id_rsa.pub') }}"

- hosts: all
  vars:
      user:
        name: user_name
        pass: password
  roles:
    - sshkey

初次登錄尚未註冊公鑰的用戶需要使用” –ask-pass “選項來進行SSH密碼登錄。

TARGET_SERVER=xxx.co.jp
ansible-playbook -i "${TARGET_SERVER}," --ask-pass setup_key.yml

再次非推荐，但如果playbook管理存储库和Ansible的执行目标位于无法从外部访问但具有保证安全性的环境中，您可以将空密码的秘钥和公钥包含在存储库中，这样就可以构建一个无需完全预配置的便携式环境。
在这种情况下，只要有人将公钥注册到服务器上，任何人在git clone之后就可以直接执行ansible-playbook命令。

在这种情况下，您需要在ssh_config中指定存储库内密钥的路径。

Host *
  StrictHostKeyChecking no
  IdentityFile ./ssh/id_rsa

最后, 正如最后, 最终, 终究, 最终结果, 结尾, 终点, 最终阶段, 最后一步

自动化工具的运营和维护

在团队中运用自动化工具时，无论是Ansible还是其他工具，向使用自动化机制的成员进行解释非常重要。

自动化环境的构建者往往倾向于只传达一句话：“既然已经自动化了，就不需要详细解释了，只要输入这个命令就可以了。”然而这样做会降低其他人使用该自动化工具的可能性。原因是许多人对于使用未知的自动化工具感到非常害怕，并且尽管有些繁琐，他们更愿意用熟悉的方式来完成任务。

我认为，导致负责搭建环境的人之前那样的想法产生的原因是，自动化的目标是“使任何人都能够构建环境而不需要任何知识”，这样虽然可以实现，但更好的方式是将目标设定为“通过将环境构建编码化，明确步骤，并确保整个团队能够共同运维自动化资产”。

结束

✖
广告
将在 10 秒后关闭
bannerAds