如果你长期使用亚马逊 Web 服务（AWS）中的实例，你可能会遇到下面这个常见的问题，它不是因为技术性的原因导致的，更多的是因为人类追求方便舒适的天性：当你登录一台你最近没有使用的区域的新实例，你最终会创建一个新的 SSH 密钥对，久而久之这最终就会造成个人拥有太多密钥，导致管理起来复杂混乱。

本文将会介绍一种在所有区域中使用你的公钥的方法。最近，一篇 Fedora Magazine 的文章介绍了另一种解决方案。但本文中的解决方案可以进一步的以更简洁和可扩展的方式实现自动化。

假设你有一个 Fedora 30 或 31 系统，其中存储了你的密钥，并且还安装了 Ansible。当这两件事同时满足时，就提供了解决这个问题的办法，甚至它还能做到更多。

使用 Ansible 的 ec2\_key 模块，你可以创建一个简单的 Ansible 剧本来在所有区域中维护你的 SSH 密钥对。如果你需要增加或者删除密钥，在 Ansible 中这就像从文件中添加和删除行一样简单。

设置和运行 Ansible 剧本

如果要使用剧本，首先需要安装 ec2_key 模块的必要依赖项：

$ sudo dnf install python3-boto python3-boto3

该剧本很简单：你只需要像下面的例子一样，修改其中的密钥及其对应的名称。然后，运行该剧本，它会帮你遍历所有列出的公共 AWS 区域。该示例还包括一些你可能要访问的受限区域，只需根据需要来取消对应行的注释，然后，保存文件重新运行剧本即可。

---
- name: Maintain an ssh key pair in ec2
  hosts: localhost
  connection: local
  gather_facts: no
  vars:
    ansible_python_interpreter: python
  tasks:
    - name: Make available your ssh public key in ec2 for new instances
      ec2_key:
        name: "YOUR KEY NAME GOES HERE"
        key_material: 'YOUR KEY GOES HERE'
        state: present
        region: "{{ item }}"
      with_items:
        - us-east-2   #US East (Ohio)
        - us-east-1   #US East (N. Virginia)
        - us-west-1   #US West (N. California)
        - us-west-2   #US West (Oregon)
        - ap-east-1   #Asia Pacific (Hong Kong)
        - ap-south-1   #Asia Pacific (Mumbai)
        - ap-northeast-2  #Asia Pacific (Seoul)
        - ap-southeast-1  #Asia Pacific (Singapore)
        - ap-southeast-2  #Asia Pacific (Sydney)
        - ap-northeast-1  #Asia Pacific (Tokyo)
        - ca-central-1   #Canada (Central)
        - eu-central-1   #EU (Frankfurt)
        - eu-west-1   #EU (Ireland)
        - eu-west-2   #EU (London)
        - eu-west-3   #EU (Paris)
        - eu-north-1   #EU (Stockholm)
        - me-south-1   #Middle East (Bahrain)
        - sa-east-1   #South America (Sao Paulo)
  #      - us-gov-east-1  #AWS GovCloud (US-East)
  #      - us-gov-west-1  #AWS GovCloud (US-West)
  #      - ap-northeast-3 #Asia Pacific (Osaka-Local)
  #      - cn-north-1   #China (Beijing)
  #      - cn-northwest-1 #China (Ningxia)

这个剧本需要通过 API 访问 AWS，为此，请使用环境变量，如下所示：

$ AWS_ACCESS_KEY="aws-access-key-id" AWS_SECRET_KEY="aws-secret-key-id" ansible-playbook ec2-playbook.yml

另一个方式是安装 aws 命令行工具并添加凭据，如以前的一篇 Fedora Magazine 文章所述。如果你在线存储它们，这些参数将不建议插入到剧本中！你可以在 GitHub 中找到本文的剧本代码。

完成该剧本之后，请确认你的密钥在 AWS 控制台上可用。为此，可以做如下操作：

1. 登录你的 AWS 控制台
2. 转到 “EC2 > Key Pairs”
3. 你应该会看到列出的密钥。唯一的限制是你必须使用此方法逐个区域来检查。

另一种方法是在 shell 中使用一个快速命令来为你做这些检查。

首先在剧本上创建一个包含所有区域的变量：

AWS_REGION="us-east-1 us-west-1 us-west-2 ap-east-1 ap-south-1 ap-northeast-2 ap-southeast-1 ap-southeast-2 ap-northeast-1 ca-central-1 eu-central-1 eu-west-1 eu-west-2 eu-west-3 eu-north-1 me-south-1 sa-east-1"

然后，执行如下循环，你就可以从 aws 的 API 获得结果：

for each in ${AWS_REGION} ; do aws ec2 describe-key-pairs --key-name <YOUR KEY GOES HERE> ; done

请记住，要执行上述操作，你需要安装 aws 命令行。

via: https://fedoramagazine.org/using-ansible-to-organize-your-ssh-keys-in-aws/

作者：Daniel Leite de Abreu 选题：lujun9972 译者：hj24 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

有一种观点认为，在 IT 行业工作的许多人经常从网络帖子里复制和粘贴。我们都干过，复制粘贴本身不是问题。问题是当我们在不理解它们的情况下这样干。

几年前，一个曾经在我团队中工作的朋友需要将虚拟机模板从站点 A 复制到站点 B。他们无法理解为什么复制的文件在站点 A 上为 10GB，但是在站点 B 上却变为 100GB。

这位朋友认为 rsync 是一个神奇的工具，应该仅“同步”文件本身。但是，我们大多数人所忘记的是了解 rsync 的真正含义、用法，以及我认为最重要的是它原本是用来做什么的。本文提供了有关 rsync 的更多信息，并解释了那件事中发生了什么。

关于 rsync

rsync 是由 Andrew Tridgell 和 Paul Mackerras 创建的工具，其动机是以下问题：

假设你有两个文件，file_A 和 file_B。你希望将 file_B 更新为与 file_A 相同。显而易见的方法是将 file_A 复制到 file_B。

现在，假设这两个文件位于通过慢速通信链接（例如，拨号 IP 链接）连接的两个不同的服务器上。如果file_A 大，将其复制到 file_B 将会很慢，有时甚至是不可能完成的。为了提高效率，你可以在发送前压缩 file_A，但这通常只会获得 2 到 4 倍的效率提升。

现在假设 file_A 和 file_B 非常相似，并且为了加快处理速度，你可以利用这种相似性。一种常见的方法是仅通过链接发送 file_A 和 file_B 之间的差异，然后使用这个差异列表在远程端重建文件。

问题在于，用于在两个文件之间创建一组差异的常规方法依赖于能够读取两个文件。因此，它们要求链接的一端预先提供两个文件。如果它们在同一台计算机上不是同时可用的，则无法使用这些算法。（一旦将文件复制过来，就不需要做对比差异了）。而这是 rsync 解决的问题。

rsync 算法有效地计算源文件的哪些部分与现有目标文件的部分匹配。这样，匹配的部分就不需要通过链接发送了；所需要的只是对目标文件部分的引用。只有源文件中不匹配的部分才需要发送。

然后，接收者可以使用对现有目标文件各个部分的引用和原始素材来构造源文件的副本。

另外，可以使用一系列常用压缩算法中的任何一种来压缩发送到接收器的数据，以进一步提高速度。

我们都知道，rsync 算法以一种漂亮的方式解决了这个问题。

在 rsync 的介绍之后，回到那件事！

问题 1：自动精简配置

有两件事可以帮助那个朋友了解正在发生的事情。

该文件在其他地方的大小变得越来越大的问题是由源系统上启用了 自动精简配置 Thin Provisioning （TP）引起的，这是一种优化存储区域网络（SAN）或网络连接存储（NAS）中可用空间效率的方法。

由于启用了 TP，源文件只有 10GB，并且在不使用任何其他配置的情况下使用 rsync 进行传输时，目标位置将接收到全部 100GB 的大小。rsync 无法自动完成该（TP）操作，必须对其进行配置。

进行此工作的选项是 -S（或 –sparse），它告诉 rsync 有效地处理稀疏文件。它会按照它说的做！它只会发送该稀疏数据，因此源和目标将有一个 10GB 的文件。

问题 2：更新文件

当发送一个更新的文件时会出现第二个问题。现在目标仅接收 10GB 了，但始终传输的是整个文件（包含虚拟磁盘），即使只是在该虚拟磁盘上更改了一个配置文件。换句话说，只是该文件的一小部分发生了更改。

用于此传输的命令是：

rsync -avS vmdk_file syncuser@host1:/destination

同样，了解 rsync 的工作方式也将有助于解决此问题。

上面是关于 rsync 的最大误解。我们许多人认为 rsync 只会发送文件的增量更新，并且只会自动更新需要更新的内容。但这不是 rsync 的默认行为。

如手册页所述，rsync 的默认行为是在目标位置创建文件的新副本，并在传输完成后将其移动到正确的位置。

要更改 rsync 的默认行为，你必须设置以下标志，然后 rsync 将仅发送增量：

--inplace               原地更新目标文件
--partial               保留部分传输的文件
--append                附加数据到更短的文件
--progress              在传输时显示进度条

因此，可以确切地执行我那个朋友想要的功能的完整命令是：

rsync -av --partial --inplace --append --progress vmdk_file syncuser@host1:/destination

注意，出于两个原因，这里必须删除稀疏选项 -S。首先是通过网络发送文件时，不能同时使用 –sparse 和 –inplace。其次，当你以前使用过 –sparse 发送文件时，就无法再使用 –inplace 进行更新。请注意，低于 3.1.3 的 rsync 版本将拒绝 –sparse 和 –inplace 的组合。

因此，即使那个朋友最终通过网络复制了 100GB，那也只需发生一次。以下所有更新仅复制差异，从而使复制非常高效。

via: https://fedoramagazine.org/copying-large-files-with-rsync-and-some-misconceptions/

作者：Daniel Leite de Abreu 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出