Cloud-init

出自 ArchWiki

Cloud-init 是一个软件包，包含用于云实例早期初始化的实用程序。在 Arch Linux 镜像中，如果目标是在 OpenStack、AWS 等云环境中启动，则需要它。

安装

安装 cloud-init 软件包。

如果您打算使用 growpart 模块，您还需要 cloud-guest-utils 软件包。

配置

本节仅讨论最基本的设置。有关可用配置选项的完整列表，请参阅 cloud-init 文档。

主配置文件是 /etc/cloud/cloud.cfg。 可选地，要加载的其他 *.cfg 文件可以放在 /etc/cloud/cloud.cfg.d 中。 它们的所有内容将被 合并。

cloud-init 19.3 及更高版本附带的默认配置应该可以在大多数主要云环境中开箱即用。 粗略地说，它执行以下操作

  • 禁用 root 用户，创建用户 arch 用于登录
  • 依赖 cloud-init 的内置数据源检测
  • 运行所有已知可在 Arch Linux 上运行的模块

根据用例，可能需要调整默认配置。

默认用户配置

默认配置包括以下内容（为简洁起见，省略了注释）

users:
   - default

要添加到系统的用户。 特殊名称 default 只是对 system_info 部分中 default_user 的引用（见下文），但该语法支持配置具有许多选项的任意用户。 此列表中的第一个用户将被其他模块视为“默认”用户，例如，设置从云环境传入的 SSH 密钥的模块。

disable_root: true

禁用 root SSH 访问。 您也可以删除云镜像上的 root 用户密码

# passwd -d root

system_info:
   default_user:
     name: arch
     lock_passwd: true
     gecos: arch Cloud User
     groups: [wheel, adm]
     sudo: ["ALL=(ALL) NOPASSWD:ALL"]
     shell: /bin/bash

这是发行版默认用户的规范

  • 默认用户的名称将是 arch
  • 默认用户已密码锁定，这意味着您只能使用启动期间配置的 SSH 密钥登录实例
  • 默认用户将被添加到 adm 和 wheel 组
  • 允许默认用户使用无密码 sudo
  • 默认用户的 shell 是 /bin/bash

请注意，只有当特殊用户 “default” 包含在上面的 users: 部分中（或完全省略该部分）时，才会创建此处指定的用户。

配置数据源

数据源定义了在启动期间如何拉取实例元数据。 这取决于您运行实例的云环境（OpenStack、AWS、OpenNebula 等）。 在幕后，这转化为相应的模块，该模块实现通用接口中定义的几种方法。

默认配置未指定数据源，这意味着 cloud-init 将尝试自动检测云环境。 但是，某些环境无法检测到或可能需要特殊配置才能工作。 在这种情况下，可以显式指定和配置要使用的数据源。 请参阅文档中已知数据源的列表。

要在您的 /etc/cloud/cloud.cfg 中指定要使用的数据源列表，请添加如下内容

datasource_list: [ NoCloud, ConfigDrive, OpenNebula, Azure, AltCloud, OVF, MAAS, GCE, OpenStack, CloudSigma, Ec2, CloudStack, None ]

这指示 cloud-init 在尝试下载实例元数据时要加载哪些模块。 可选地，可以传递特定于每个数据源的进一步配置参数，如下所示

datasource:
  OpenStack:
    metadata_urls: [ 'http://169.254.169.254:80' ]
    dsmode: net

上述配置告诉 OpenStack 数据源使用 url http://169.254.169.254:80 下载元数据并在网络初始化后运行，这两者都是默认行为，可以省略。

模块

Cloud-init 附带一组模块，可以在配置中启用或禁用。 默认配置启用所有已知可在 Arch Linux 上运行的模块。 省略的模块包括例如特定于其他发行版或操作系统的模块。

启用模块通常并不意味着它实际上会执行任何操作。 但是，它会检查是否传入了与它相关的任何配置，例如，从云环境通过数据源传入。 只有到那时它才会尝试采取行动。 因此，启用所有模块通常有助于最大限度地提高与云环境的兼容性。 然而，已知不需要的模块可以从配置中删除，例如，以缩短启动时间。 您可以使用 cloud-init analyze 在启动的实例上查看在各个模块上花费了多少时间。

一些模块向 cloud-init 声明它们已验证的发行版。 即使您指定要运行它们，除非 cloud.cfg 中指定的发行版是该模块的已验证发行版之一，否则它们将拒绝运行。 如果您需要覆盖此行为以无论如何在 Arch 上运行模块，请将该模块添加到云配置中的 unverified_modules 部分，例如

unverified_modules: ['ssh-import-id']

Systemd 集成

软件包 cloud-init 提供了四个 systemd.service(5)、两个 systemd.target(5) 和一个 systemd.generator(7)，它们的依赖关系以它们按列出的顺序激活的方式构建

  • cloud-init-generator。 确定任何数据源的可用性并启用或禁用 cloud-init.target
  • cloud-init-local.service。 仅需要文件系统启动。 执行 cloud-init init --local
  • cloud-init-main.service。 需要网络启动。 执行 cloud-init init --all-stages
  • cloud-config.target。 对应于 cloud-config upstart 事件“通知第三方 cloud-config 可用”
  • cloud-config.service。 执行 cloud-init modules --mode=config
  • cloud-final.service。 执行 cloud-init modules --mode=final
  • cloud-init.target。 当所有服务都已启动时达到

Uplink Labs EC2 镜像已全部启用，尽管由于依赖关系，这似乎有点过分。 在准备镜像时，启用 cloud-init-main.service 和 cloud-final.service 应该就足够了。 请注意，这并不意味着 cloud-init 服务将实际运行 - 这仍然取决于生成器在早期启动时启用 cloud-init.target。

另请参阅 cloud-init 启动阶段文档以获取更多信息。

使用

Archiso

本文或本节是与 Install Arch Linux via SSH#Installation on a headless server 合并的候选对象。

注释：它提供了更多详细信息，并说明了 Archiso 在裸机上 cloud-init 的用法。 （在 Talk:Cloud-init 中讨论）

以下是如何使用 QEMU 测试带有 cloud-init 的 Archiso（参见 archlinux/archiso#27）

创建 cloud-init 的 YAML 格式 user-data 文件，其中包含用户名和公钥 SSH 密钥。 您可以使用 archiso Merge Request #117 中提出的便捷 create_cloud-init.sh 脚本，或者像下面这样手动编写，按原样或添加 cloud-init 文档中显示的任何其他选项。 请注意，#cloud-config 不是 YAML 注释，而是 cloud-init 要求存在的。

#cloud-config
users:
  - name: vorburger
    ssh_authorized_keys:
      - ssh-rsa (...)

我们也可以使用 meta-data，但不是必须的，所以我们可以将其设为空文件（但它必须存在）

$ touch meta-data

然后使用 libisoburn 中的 xorriso 构建包含（仅）user-data 和 meta-data 的 cloud-init.iso

$ xorriso -as genisoimage -output cloud-init.iso -volid CIDATA -joliet -rock user-data meta-data

现在将此 cloud-init.iso 作为额外的第二个驱动器添加到 VM，例如，使用 qemu-system-x86_64 ... -cdrom cloud-init.iso，或者如果使用 archiso，则使用 run_archiso -c。

然后您应该能够使用 user-data 中提供的所选用户和公钥 SSH 进入机器。 请注意，由于启动菜单的延迟，可能需要一段时间才能可用； 例如，标准 releng archlinux*.iso 将在启动时在那里等待 30 秒。 对于使用更改的主机密钥频繁重新测试新实例，ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null 可能会很方便。

提示： Cloud-init 的 nocloud 文档解释了一种替代方法，该方法基于使用 -smbios type=1,serial=ds=nocloud。 这可以在运行 QEMU 和 ad hoc Python Web 服务器的主机本地完成，如 cloud-init 教程中所述。 要在裸机上启动，您可以“刻录”两个单独的 USB 驱动器，分别用于 archlinux*.iso 和 cloud-init.iso，并从 archlinux*.iso 启动。 执行此操作时，cloud-init 将使用 cloud-init.iso 上的配置运行。

故障排除

常见问题解答

cloud-init FAQ 提供了有关如何调试 cloud-init 的有用信息，包括其日志文件所在的位置，以及如何在开发期间重新运行数据源检测和 cloud-init。

未挂载的镜像

首先要检查的通常是是否看到了 cloud-init 镜像 (ISO)，使用 lsblk 和 mount。

“设备 /dev/sr0，标签为 cidata，不是有效的种子”

当 nocloud 数据源看到一个 ISO，例如仅包含 user-data 但没有 meta-data 时，会出现 datasourcenocloud.py warning device /dev/sr0 with label cidata not a valid seed - 两者都是必需的，即使其中一个是空的。

“未处理的非 multipart [...] ssh_authorized_keys”

当 user-data YAML 不以 #cloud-config 开头时，会出现 unhandled non-multipart (text-x-not-multipart) userdata 'b'ssh_authorized_keys（显然没有空格；即使 yamllint 会告诉您它缺少注释中的起始空格）。

参见

检索自“https://wiki.archlinux.org.cn/index.php?title=Cloud-init&oldid=819930”