使用 Packer 为Proxmox 自动化构建映像Ubuntu Server 20.04 虚拟机映像

从 20.04 开始，Ubuntu 决定更新实时服务器安装程序以实现自动安装规范，以便能够仅使用 Subiquity 完全自动化安装过程。Subiquity 是新的服务器安装程序（又名“服务器无处不在”），旨在取代之前基于 debian-installer 的经典系统。

本文说明了如何使用 Packer 和 Proxmox 上的 Subiquity 生成 Ubuntu Server 20.04 虚拟机镜像模板。

介绍

Subiquity 仅在live版本中可用（例如ubuntu-20.04.1-live-server-amd64.iso）。以前基于 debian-installer（预置文件）的系统已停产，不再使用。

仍然可以通过下载可以ubuntu-legacy-server在官方Ubuntu 映像存储库的专用文件夹中找到的旧服务器映像来使用 debian-installer 。

Subiquity

这个新的实时系统基于 cloud-init 并使用 YAML 文件来完全自动化安装过程。它与以前的系统在几个方面有所不同。

语法更容易理解（YAML 与 debconf-set-selections 格式）。
可能会出现混合情况，其中某些部分可以是交互式的，而其他部分可以从配置中自动回答。

Ubuntu Server 20.04 中的 Subiquity 设置

Proxmox

Packer 需要用户帐户才能在 Proxmox API 上执行操作。以下命令将创建一个packer@pve具有受限权限的新用户帐户。

$ pveum useradd packer@pve
$ pveum passwd packer@pve
Enter new password: ****************
Retype new password: ****************
$ pveum roleadd Packer -privs "VM.Config.disk VM.Config.cpu VM.Config.Memory Datastore.AllocateSpace Sys.Modify VM.Config.Options VM.Allocate VM.Audit VM.Console VM.Config.CDROM VM.Config.Network VM.PowerMgmt VM.Config.HWType VM.Monitor"
$ pveum aclmod / -user packer@pve -role Packer

Proxmoxpveum可通过 SSH 连接或从 UI 上的节点参数下访问的 web shell 获得。

从图像存储库下载 Ubuntu Server 20.04 ISO 。在撰写本文时，可用的最新版本是ubuntu-20.04.1-live-server-amd64.iso. 将 ISO 放在类别local下的存储ISO image中。

Proxmox 中的本地存储

封隔器

构建器配置

Packer 将执行一个工作流来创建一个新模板，该模板可以在以后使用已经应用的基于预配置的情况下快速引导新 VM。

从技术上讲，Packer 将在 Proxmox 中启动一个虚拟机，从引导命令启动安装程序并参考配置文件，并在安装完全完成后将虚拟机转换为模板。

{
  "builders": [{
    "type": "proxmox","proxmox_url": "https://proxmox.madalynn.xyz/api2/json","username": "{{ user `proxmox_username` }}","password": "{{ user `proxmox_password` }}","node": "proxmox","network_adapters": [{
      "bridge": "vmbr0"
    }],"disks": [{
      "type": "scsi","disk_size": "20G","storage_pool": "local-lvm","storage_pool_type": "lvm"
    }],"iso_file": "local:iso/ubuntu-20.04.1-live-server-amd64.iso","unmount_iso": true,"boot_wait": "5s","memory": 1024,"template_name": "ubuntu-20.04","http_directory": "http","boot_command": [
      "<esc><wait><esc><wait><f6><wait><esc><wait>","<bs><bs><bs><bs><bs>","autoinstall ds=nocloud-net;s=http://{{ .HTTPIP }}:{{ .HTTPPort }}/ ","--- <enter>"
    ],"ssh_username": "madalynn","ssh_password": "madalynn","ssh_timeout": "20m"
  }]
}

大多数参数很容易理解。这ssh_timeout将使安装程序有时间在安装过程中下载最新的安全更新。

使用以下命令启动 Packer。

$ packer build -var-file=secrets.json ubuntu.json

该var-file参数提供了提取秘密（如凭据）和动态参数的灵活性，以使用工作流构建多个 Ubuntu 映像。最低要求应包括来自先前创建的用户的 Proxmox 凭据。

{
  "proxmox_username": "packer@pve","proxmox_password": "fQk9f5Wd22aBgv"
}

Packer 将从http目录的内容（带http_directory参数）启动一个 HTTP 服务器。这将允许 Subiquity 远程获取 cloud-init 文件。

实时安装程序 Subiquity 比 debian-installer 使用更多内存。Packer ( 512M)的默认值是不够的，会导致奇怪的内核恐慌。尽量1G少用。

---[ end Kernel panic - not syncing: No working init found.  Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance. ]---

boot 命令告诉 cloud-init 启动并使用nocloud-net数据源能够从远程 HTTP 端点加载user-data和Meta-data文件。附加autoinstall参数将强制 Subiquity 执行破坏性操作，而无需用户确认。

{
  ...
  "boot_command": [
    "<esc><wait><esc><wait><f6><wait><esc><wait>","--- <enter>"
  ],...
}

供应商配置

Cloud-init 会处理其他所有事情。但是，一旦 Packer 能够通过 SSH 连接到虚拟机，它就会假定配置已完成。但此时，设置过程还没有完全完成。应该告诉 Packer 等待 cloud-init 完全完成。

从技术上讲，最简单的解决方案是等到/var/lib/cloud/instance/boot-finished文件存在。创建此文件是 cloud-init 所做的最后一件事。一个简单的 bash 脚本while就可以解决问题。

{
  "provisioners": [{
    "type": "shell","inline": [
      "while [ ! -f /var/lib/cloud/instance/boot-finished ]; do echo 'Waiting for cloud-init...'; sleep 1; done"
    ]
}

一旦 SSH 连接可用，Provisioners 将直接在 VM 上执行。Packer 支持很多供应商。例如，可以在此步骤中启动 Ansible playbook 或配置 Chef 客户端。

云初始化

由于 Subitiquy 使用 cloud-init，配置应存在于两个文件中，user-data和Meta-data. user-data是 Subitiquity 和 cloud-init 将用于配置的主要配置文件。Meta-data是一个附加文件，可以托管一些EC2 元数据服务格式的附加元数据。

该Meta-data文件可以为空（并将用于 Proxmox）但必须存在，否则 cloud-init 将无法正确启动。

http
├── Meta-data
└── user-data

Cloud-init 支持多种格式的配置文件。YAML 是最容易理解的，将用于以下代码段。Subiquity 添加了一个新模块autoinstall，该模块承载安装所需的所有配置。

#cloud-config
autoinstall:
  ...

与经典的 cloud-init 文件不同，所有内容都必须在autoinstall密钥下。其余的将被忽略。

在官方文件列出了可配置的所有可用参数。与 debian-installer 相比，范围缩小了，但 Subiquity 提供了使用所有其他cloud-init 模块进行补偿的能力。

在幕后，Subiquity 将能够自己处理一些操作（如分区），并将生成一个 cloud-init 配置文件，该文件将在重启后执行。

所有“原生”cloud-init 模块都必须在user-data密钥下。例如，要使用write_filescloud-init 模块，可以使用以下配置。

#cloud-config
autoinstall:
  ...
  user-data:
    write_files:
      - path: /etc/crontab
        content: |
                    15 * * * * root ship_logs
        append: true
    ...

自动安装配置

自动安装负责回答安装过程中提出的所有问题（键盘布局、附加包等）。范围有限，应使用 cloud-init 模块管理其他工作流（见上文）。

#cloud-config
autoinstall:
  version: 1
  locale: en_US
  keyboard:
    layout: fr
  ssh:
    install-server: true
    allow-pw: true
  packages:
    - qemu-guest-agent

qemu-guest-agentPacker 需要该包来检测 VM 的 IP 地址以执行 SSH 连接。这也将使 Proxmox 能够直接在用户界面中显示 VM 资源。

Proxmox VM 元数据

虚拟机将使用法语键盘以英语进行配置。映射键对应于中的设置/etc/default/keyboard。有关更多详细信息，请参阅其手册页。

来自 Packer 的远程连接需要 SSH 服务器。默认情况下，它将尝试仅使用用户名和密码进行连接。这需要启用该allow-pw参数。

如果没有allow-pw，SSH 服务器将只接受使用证书的连接。帕克必须配置使用这样做的ssh_keypair_name部分。

身份

除了前面的参数之外，Subiquity 还能够在使用该identity部分进行配置期间创建用户帐户。

#cloud-config
autoinstall:
  identity:
    hostname: ubuntu
    username: madalynn
    password: $6$xyz$1D0kz5pThgRWqxWw6JaZy.6FdkUCSRndc/PMtDr7hMK5mSw7ysChRdlbhkX83PBbNBpqXqef3sBkqGw3Rahs..

此部分还负责设置主机名。由于此 VM 仅用作模板的基础，因此这无关紧要，应在最终配置时进行设置。

先前块将创建一个用户madalynn以madalynn作为密码。

可以使用以下命令生成 unix 加密密码。

$ openssl passwd -6 -salt xyz madalynn

为了更灵活地创建帐户，可以改用 cloud-init 模块users。

#cloud-config
autoinstall:
  ...
  user-data:
    users:
      - name: madalynn
        passwd: $6$xyz$1D0kz5pThgRWqxWw6JaZy.6FdkUCSRndc/PMtDr7hMK5mSw7ysChRdlbhkX83PBbNBpqXqef3sBkqGw3Rahs..
        groups: [adm,cdrom,dip,plugdev,lxd,sudo]
        lock-passwd: false
        sudo: ALL=(ALL) nopASSWD:ALL
        shell: /bin/bash
        ssh_authorized_keys:
          - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJEXrziuUOCpWPvwOsGuF4K+aq1ufToGMi4ra/1omOZb

该模块提供了更多参数来配置：组、shell 二进制、SSH 授权密钥……该sudo参数允许在sudo不输入任何密码的情况下使用该命令。这将有助于以后使用，例如，Ansible 从模板完成安装。

不能同时使用 cloud-init 模块users和自动安装identity块。users如果identity存在，Subiquity 将丢弃模块配置。

联网

Subiquity 允许使用两个预配置的布局，lvm以及direct. 默认情况下，Subiquity 将使用lvm4G 的逻辑卷。安装程序不会扩展分区以使用卷组的全部功能。也可以在文件系统上配置交换文件的大小（0禁用）。

#cloud-config
autoinstall:
  ...
  storage:
    layout:
      name: direct
    swap:
      size: 0

如果direct使用，/dev/sda2将使用完整磁盘创建单个分区。

Filesystem                           Size  Used Avail Use% Mounted on
udev                                 1.9G     0  1.9G   0% /dev
tmpfs                                394M  696K  393M   1% /run
/dev/sda2                             20G  3.6G   15G  20% /
tmpfs                                2.0G     0  2.0G   0% /dev/shm
tmpfs                                5.0M     0  5.0M   0% /run/lock
tmpfs                                2.0G     0  2.0G   0% /sys/fs/cgroup

也可以在key下使用基于curtin的更复杂的配置config。如果 VM 有多个磁盘，这将是一项要求（在这种情况下，预配置的布局将不起作用）。

#cloud-config
autoinstall:
  ...
  storage:
    config:
      - type: disk
        id: root-disk
        size: largest
      - type: partition
        id: boot-partition
        device: root-disk
        size: 10%
      - type: partition
        id: root-partition
        size: 20G
      - type: partition
        id: data-partition
        device: root-disk
        size: -1

先前的配置将在最大的驱动器上创建三个分区。

10% 用于引导分区。
20G 为根分区。
其余为数据分区。

这些是自定义布局的第一步。但是，这还不够，还需要其他步骤（格式化、挂载……）。

如果使用预先配置的布局，自定义配置将被忽略。

GitHub

完整配置可在 GitHub 上的aerialls/madalyn-packer存储库中找到。

原文地址：https://blog.csdn.net/allway2