在Linux云实例上调试用户数据的通用指南

  • Mon, Oct 14, 2024
  • 2-minute read

引言

在云计算环境中，Cloud-init 是一个强大的工具，它可以在虚拟机或容器的首次启动时自动配置实例。Amazon 的 EC2 实例就是通过 Cloud-init 来实现 User data 执行脚本的功能。通过 user-data 文件我们可以定义实例的配置，如设置 SSH 密钥、安装软件包、配置网络等。然而，当 user-data 文件中的配置不生效或出现问题时，如何调试就变得尤为重要。

本篇文章将介绍如何调试 Cloud-init 的 user-data 文件，帮助你快速找到问题并解决它们。

user-data 文件的结构

在学习如何调试之前，很有必要的是了解 user-data 文件的构成。user-data 文件是 Cloud-init 的配置文件，通常使用 YAML 格式，定义了实例的初始配置。典型的 user-data 文件可以包括以下内容：

#cloud-config
hostname: my-cloud-instance
users:
  - name: ubuntu
    ssh-authorized-keys:
      - ssh-rsa AAAAB3...example-key...
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    shell: /bin/bash
packages:
  - nginx
  - git

  • #cloud-config: 表示这是一个 cloud-config 文件。

  • hostname: 设置实例的主机名。

  • users: 创建用户并配置 SSH 密钥。

  • packages: 指定要安装的软件包列表。

除了 YAML 格式的 cloud-config 配置文件，我们也支持使用 Shell 脚本来做一些初始化配置，但是有以下几点值得我们注意⚠️：

  • 用户数据 Shell 脚本必须以 #! 字符以及指向要读取脚本的解释器的路径（通常为 #!/bin/bash) 开头。
  • 作为用户数据输入的脚本是作为根用户加以运行的，因此在脚本中不需要使用 sudo 命令。
  • 此外，这是因为脚本不交互运行，所以无法包含要求用户反馈的命令（如使用 yum updates ****命令时, 需要加上-y 标志跳过用户交互）。

那么我们该如何确保我们的脚本没有语法错误呢？我们可以使用 sudo cloud-init schema --system --annotate 验证当前的 user-data 配置是否符合 Cloud-init 的 schema 标准，帮助我们找到潜在的语法或配置错误。

通过 user-data 文件，用户可以在实例启动时自动完成常见的配置任务，这大大减少了云工程师的重复劳动。我们的 user-data 脚本通常存储在 /var/lib/cloud/instances/ 目录下，当我们查看该目录，会发现这下面拥有我们的实例信息文件：

ls
i-0e738afccf03a26ab  i-0f352a615063e5912

我们发现这里有这里有两个文件夹，这是因为我当前的实例是基于我自建的 AMI 构建的，所以它保存了它的源实例的信息，当然也包括了它的用户脚本文件的原始文件。Cloud-init 会将原始文件转化为可执行文件并放置在 /scripts 目录。这里有一点需要注意的是，/var/lib/cloud/instances 存着所有源实例的 cloud-init 信息，虽然经过我的反复测试，Cloud-init 并不会执行所有源实例的 User data 脚本。但是无论如何，在构建新的 AMI 时最好提前删除所有的原始镜像存在的 User data脚本，以免不必要的风险，例如造成基础镜像的一些安全信息泄露。

如何简化 User-data 脚本的调试过程

在调试 Cloud-init 的 user-data 配置时，许多用户可能会面临复杂的配置和多次尝试的挑战，我相信这对于大家来说都是很恼人的。为了简化这一过程，我们可以采取一些有效的策略，以提高调试效率。

调试的一些思路：

  1. 调试和日志记录：我们可以在实例的/var/log/cloud-init-output.log中查看我们 user-data 脚本的输出日志。此外，我们也可以在用户数据脚本中添加详细的日志记录，这帮助我们在实例启动后更快地发现问题。确保脚本将日志输出到 /var/log 或其他日志文件，便于后续分析。

  2. 使用 EC2 实例的临时启动脚本：可以先在一个测试实例上运行你的脚本，修改、调试并且直接调用运行脚本，而不是每次都创建新实例，这样可以大大节省时间。

    • 对于 Shell 脚本，我们可以直接运行。
    • 对于 cloud-config 脚本，我们可以通过 cloud-init modules --mode=final 命令来运行。

  3. 使用自动化脚本进行测试：编写一些自动化脚本来启动和销毁实例，简化实例的创建和销毁流程。

    #!/bin/bash

AMI_ID="ami-00f87382f90261efc"
INSTANCE_TYPE="t2.micro"
TAGS="ResourceType=instance,Tags=[{Key=Name,Value=TestInstance}]"
KEY_NAME="RT-key"
SECURITY_GROUP="sg-07d979f09443f6cf0"
#SUBNET_ID="subnet-0123456789abcdef0"

aws ec2 run-instances \
    --image-id $AMI_ID \
    --count 1 \
    --instance-type $INSTANCE_TYPE \
    --tag-specifications $TAGS \
    --key-name $KEY_NAME \
    --security-group-ids $SECURITY_GROUP \
    --user-data file://user-data.sh
#    --subnet-id $SUBNET_ID \

  4. 通过 AWS CloudFormation 或 Terraform 管理基础设施：这算是第三点的一个延伸，这些工具允许你定义和修改基础设施配置，包括用户数据脚本。你可以快速重新部署测试实例，而无需手动创建。我会更加偏好使用 Terraform。因为使用 Terraform 可以进行快速的切换其他的云服务提供商，而AWS CloudFormation 只支持 AWS 自己的服务。

  5. 使用QEMU来模拟云实例环境：通过 QEMU来启动虚拟机并告知是处在 nocloud 的环境，从本机指定数据源（user-data， meta-data 和 vendor data)，从而实现模拟云环境快速调试。这种方法的原理和使用 LXD 容器类似，但是基于 LXD 容器的方法更加轻量化。

  6. 使用 LXD 容器来模拟云实例的环境

    当然，大部分时候我们只是进行了略微的修改就得大动干戈的去云计算平台上创建实例，一次又一次的 reboot 只为了测试 User data 是否正确执行并进入其中查看日志未免也太慢了一些。其实，我们也可以使用容器化技术来模拟云服务实例的环境，从而实现在本地快速启动进行测试。

    在我们的Linux 系统中（没有可以用 Unbuntu 虚拟机代替），我们可以使用如下命令来进行 lxd 容器服务和配套工具 lxc 的安装。

    //安装 lxd 
sudo snap install lxd

//进行 lxd 启动的最小化配置
sudo lxd init --minimal

    紧接着，我们可以在本地创建一个 my-user-data 文件，例如它的内容为：

    #cloud-config
runcmd:
  - echo 'Hello, World!' > /var/tmp/hello-world.txt

    紧接着我们就可以通过lxc launch ubuntu:focal my-test --config=user.user-data="$(cat /tmp/my-user-data)” 来运行我们的实例了。ubuntu:focal 已经预安装了 Cloud-init 工具，所以实例在启动后就会尝试自动执行我们的 user data 脚本了。每次测试完后，可以使用 sudo lxc delete my-test --force 快速终结容器。