CoreOS ignition简介

Posted 2021-12-14 rtoax

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了CoreOS ignition简介相关的知识，希望对你有一定的参考价值。

CoreOS ignition简介
荣涛 2021年11月15日

文档修改日志

日期	修改内容	修改人	备注
2021年11月15日	创建	荣涛	https://coreos.github.io/ignition

1. 引言

Ignition 是 Fedora CoreOS 和 RHEL CoreOS 在 initramfs 期间用来操作磁盘的实用程序。这包括对磁盘进行分区、格式化分区、写入文件（常规文件、systemd 单元等）和配置用户。首次启动时，Ignition 从真实来源（远程 URL、网络元数据服务、管理程序桥接等）读取其配置并应用该配置。

很可能您不想直接调用 Ignition。事实上，它甚至不存在于根文件系统中。有关为 Ignition 提供运行时配置的详细信息，请查看入门指南。

2. 入门指南

Ignition 是一个低级系统配置实用程序。Ignition 可执行文件是临时初始根文件系统initramfs 的一部分。当 Ignition 运行时，它会在给定环境的命名位置中查找配置数据，例如文件或 URL，并在switch_root调用之前将其应用于机器以转至机器的根文件系统。

Ignition 使用 JSON 配置文件来表示要进行的更改集。此配置的格式在规范中有详细说明，并且MIME 类型已向 IANA 注册。此配置最重要的部分之一是版本号。这必须与 Ignition 接受的版本号匹配。如果 Ignition 不接受配置版本，Ignition 将无法运行并且机器将无法启动。这可以通过检查故障机器的控制台输出来看到。有关更多信息，请查看故障排除部分（参见下面章节）。

2.1. 提供配置

Ignition 将根据底层平台选择在哪里寻找配置。提供了支持的平台（可参考下面的章节）和元数据源的列表以供参考。

必须通过指定的数据源将配置传递给 Ignition。请参阅 Ignition配置示例以了解如何编写配置文件（可参考下面的章节）。

可以通过内核命令行选项指定配置 URL 来覆盖此数据源。

Linux 发行版可能会提供基本配置，用于指定默认配置，例如默认用户。此数据源在应用之前与此基本配置合并。有关配置合并的更多信息，请参阅操作员注释（可参考下面的章节）。

2.2. 配置验证

为了验证 Ignition 的配置，在GitHub CoreOS/ignition上有一个名为ignition-validateavailable的 cli 工具的二进制文件。还有一个ignition验证容器：.quay.io/coreos/ignition-validate

例子：

# This example uses podman, but docker can be used too
podman run --pull=always --rm -i quay.io/coreos/ignition-validate:release - < myconfig.ign

2.3. 故障排除

2.3.1. 收集日志

故障排除时所需的最有用的信息是来自 Ignition 的日志。Ignition 在多个阶段运行，因此最容易通过 syslog 标识符进行过滤：ignition。使用 systemd 时，可以使用以下命令来完成：

journalctl --identifier=ignition --all

如果这不会产生任何结果，以 root 身份运行可能会有所帮助。在某些情况下，日志不属于 systemd-journal 组，或者当前用户不属于该组。

2.3.2. 增加冗长

在机器无法启动的情况下，有时要求 journald 将更多信息记录到控制台会很有帮助。这使得在没有交互式控制台可用的环境中访问 Ignition 日志变得容易。以下内核参数将增加控制台的日志输出，使所有 Ignition 的日志可见：

systemd.journald.max_level_console=debug

2.3.3. 验证配置

Ignition 失败的一个常见原因是格式错误的配置（例如拼写错误的部分或不正确的层次结构）。Ignition 将记录关于它解析的配置的错误、警告和其他注释，因此这可用于调试所提供配置的问题。另请参阅配置验证部分。

2.3.4. 启用 systemd 服务

当 Ignition 启用 systemd 服务时，它不会直接创建 systemd 所需的符号链接；它利用了systemd 预设。预设仅在第一次启动时评估，如果强制 Ignition 运行不止一次，这可能会导致混淆。在第一次启动后在配置中启用的任何 systemd 服务在下次调用 Ignition 后实际上不会启用。systemctl preset-all需要手动调用以创建必要的符号链接，从而启用服务。

在机器的生命周期内，Ignition 在给定角色中通常不会运行超过一次，因此这种需要手动 systemd 干预的情况通常不会出现。

3. 示例配置

这些示例是在配置的 3.0.0 版中编写的。Ignition v2.0.0+ 兼容版本 3.0.0+ 的所有配置。

3.1. 服务

3.1.1. 启动服务

此配置将使用示例服务的内容编写单个服务单元（如下所示）。该单元将作为 multi-user.target 的依赖项启用，因此在启动时启动。


  "ignition":  "version": "3.0.0" ,
  "systemd": 
    "units": [
      "name": "example.service",
      "enabled": true,
      "contents": "[Service]\\nType=oneshot\\nExecStart=/usr/bin/echo Hello World\\n\\n[Install]\\nWantedBy=multi-user.target"
    ]

example.service：

[Service]
Type=oneshot
ExecStart=/usr/bin/echo Hello World

[Install]
WantedBy=multi-user.target

3.1.2. 修改服务

此配置将添加一个systemd 单元插件来修改现有服务systemd-journald并将其环境变量设置SYSTEMD_LOG_LEVEL为debug.


  "ignition":  "version": "3.0.0" ,
  "systemd": 
    "units": [
      "name": "systemd-journald.service",
      "dropins": [
        "name": "debug.conf",
        "contents": "[Service]\\nEnvironment=SYSTEMD_LOG_LEVEL=debug"
      ]
    ]

systemd-journald.service.d/debug.conf：

[Service]
Environment=SYSTEMD_LOG_LEVEL=debug

3.2. 在根文件系统上创建文件

在许多情况下，将文件写入根文件系统很有用。此示例将单个文件写入/etc/someconfig根文件系统。文件（“示例文件”）的内容在配置中使用数据 URL 方案内联指定。


  "ignition":  "version": "3.0.0" ,
  "storage": 
    "files": [
      "path": "/etc/someconfig",
      "mode": 420,
      "contents":  "source": "data:,example%20file%0A" 
    ]

路径是相对于 Ignition 正在配置的系统的根文件系统指定的。符号链接就像 Ignition 从最终系统运行一样。有关Ignition 如何遵循符号链接的更多信息，请参阅操作员注意事项。

3.3. 重新格式化 /var 文件系统

3.3.1. Btrfs

此示例 Ignition 配置将使用“VAR”文件系统标签定位设备并将其重新格式化为 btrfs，重新创建文件系统标签。该wipeFilesystem选项设置为确保 Ignition 忽略任何现有的文件系统。此配置还将文件写入/var/example-asset，从中获取其内容https://example.com/asset。path在文件系统上创建任何内容之前，Ignition 在指定的位置挂载它创建的文件系统，确保/var/example-asset在新创建的文件系统上创建。请注意，Ignition 不会为其创建/etc/fstab的文件系统自动创建挂载单元或条目。在这种情况下，我们假设操作系统已经通过标签/etc/fstab为/var文件系统提供了一个挂载单元或条目。


  "ignition":  "version": "3.0.0" ,
  "storage": 
    "filesystems": [
      "device": "/dev/disk/by-label/VAR",
      "path": "/var",
      "format": "btrfs",
      "wipeFilesystem": true,
      "label": "VAR"
    ],
    "files": [
      "path": "/var/example-asset",
      "mode": 420,
      "contents": 
        "source": "http://example.com/asset",
        "verification":  "hash": "sha512-0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef" 
      
    ]

文件的 SHA512 总和可以使用sha512sum. 还支持 SHA256 和，并且可以使用sha256sum.

3.4. 创建启用 RAID 的数据卷

在许多情况下，拥有外部数据卷可能很有用。此配置将data在两个单独的磁盘之间设置一个 RAID0 ext4 卷。它还写入一个挂载单元（如下所示），它将自动将卷挂载到/var/lib/data.


  "ignition":  "version": "3.0.0" ,
  "storage": 
    "disks": [
      
        "device": "/dev/sdb",
        "wipeTable": true,
        "partitions": [
          "label": "raid.1.1",
          "number": 1,
          "sizeMiB": 1024,
          "startMiB": 0
        ]
      ,
      
        "device": "/dev/sdc",
        "wipeTable": true,
        "partitions": [
          "label": "raid.1.2",
          "number": 1,
          "sizeMiB": 1024,
          "startMiB": 0
        ]
      
    ],
    "raid": [
      "devices": [
        "/dev/disk/by-partlabel/raid.1.1",
        "/dev/disk/by-partlabel/raid.1.2"
      ],
      "level": "stripe",
      "name": "data"
    ],
    "filesystems": [
      "device": "/dev/md/data",
      "path": "/var/lib/data",
      "format": "ext4",
      "label": "DATA"
    ]
  ,
  "systemd": 
    "units": [
      "name": "var-lib-data.mount",
      "enabled": true,
      "contents": "[Mount]\\nWhat=/dev/md/data\\nWhere=/var/lib/data\\nType=ext4\\n\\n[Install]\\nWantedBy=local-fs.target"
    ]

var-lib-data.mount：

[Mount]
What=/dev/md/data
Where=/var/lib/data
Type=ext4

[Install]
WantedBy=local-fs.target

3.5. 用远程配置替换配置

在某些云环境中，可能提供给机器的配置的大小有限制。为了解决这个问题，Ignition 允许将配置替换为备用的远程配置的内容。下面演示了这一点，使用 SHA512 和来验证配置的内容。


  "ignition": 
    "version": "3.0.0",
    "config": 
      "replace": 
        "source": "http://example.com/config.json",
        "verification":  "hash": "sha512-0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"

可以使用确定配置的 SHA512 总和sha512sum。还支持 SHA256 和，并且可以使用sha256sum.

3.6. 设置主机名

设置系统的主机名就像编写一样简单/etc/hostname：


  "ignition":  "version": "3.0.0" ,
  "storage": 
    "files": [
      "path": "/etc/hostname",
      "mode": 420,
      "overwrite": true,
      "contents":  "source": "data:,core1" 
    ]

3.7. 添加用户

可以使用passwd.users密钥将用户添加到操作系统，该密钥采用指定给定用户的对象列表。如果你想配置一个用户“systemUser”和一个用户“jenkins”，你可以这样做：


  "ignition":  "version": "3.0.0" ,
  "passwd": 
    "users": [
      
        "name": "systemUser",
        "passwordHash": "$superSecretPasswordHash.",
        "sshAuthorizedKeys": [
          "ssh-rsa veryLongRSAPublicKey"
        ]
      ,
      
        "name": "jenkins",
        "uid": 1000
      
    ]

要添加更多用户，请在users列表结构 ( […]) 中配置它们。

3.8. 创建 LUKS 卷

此配置将设置一个基于密钥文件的 LUKS2 卷，data在该卷上放置一个文件系统，并写入一个挂载单元（如下所示）以自动将卷挂载到/var/lib/data.


  "ignition": "version": "3.2.0",
  "storage": 
    "luks": [
      "name": "data",
      "device": "/dev/sdb"
    ],
    "filesystems": [
      "path": "/var/lib/data",
      "device": "/dev/disk/by-id/dm-name-data",
      "format": "ext4",
      "label": "DATA"
    ]
  ,
  "systemd": 
    "units": [
      "name": "var-lib-data.mount",
      "enabled": true,
      "contents": "[Mount]\\nWhat=/dev/disk/by-label/DATA\\nWhere=/var/lib/data\\nType=ext4\\n\\n[Install]\\nWantedBy=local-fs.target"
    ]

var-lib-data.mount：

[Mount]
What=/dev/disk/by-label/DATA
Where=/var/lib/data
Type=ext4

[Install]
WantedBy=local-fs.target

3.9. 设置内核参数

这个配置将确保example和foo bar内核参数设置和somekarg内核参数未设置。


  "ignition": "version": "3.3.0",
  "kernelArguments": 
    "shouldExist": ["example", "foo bar"],
    "shouldNotExist": ["somekarg"]

4. 配置规格

ignition 配置必须符合特定版本的配置规范模式，ignition.version: X.Y.Z在配置中的字段中指定。

有关将配置更新为最新规范的说明，请参阅升级配置。

4.1. 稳定的规格版本

我们建议您始终使用最新的稳定规范以从新功能和错误修复中受益。Ignition 目前支持以下稳定的规范版本：

4.2. 实验规范版本

不要将实验规范用于开发和测试之外的任何事情，因为它可能会在没有警告或公告的情况下发生变化。Ignition 目前提供以下实验规范版本：

v3.4.0(实验性)

4.3. 旧规范 2.x 配置规范

规范 1 和 2.x 配置规范的文档可在Ignition的遗留spec2x分支中找到。旧版本的 RHEL CoreOS 和 Flatcar Container Linux 使用这些规范版本。不再维护此分支。

4.4. Spec 版本和 Ignition 版本

此表列出了每个稳定规范版本的第一个支持它的 Ignition 发布版本。要获得所有错误修复，通常建议使用最新的 Ignition 版本。

Spec version	Ignition release
3.0.0	2.0.0
3.1.0	2.3.0
3.2.0	2.7.0
3.3.0	2.11.0

4.5. Config Spec v3.3.0

MORE, TODO

4.6. Config Spec v3.2.0

MORE, TODO

4.7. Config Spec v3.1.0

MORE, TODO

4.8. Config Spec v3.0.0

MORE, TODO

4.9. Config Spec v3.4.0-experimental

MORE, TODO

5. 升级配置

https://coreos.github.io/ignition/migrating-configs/

有时，对 Ignition 的配置所做的更改会破坏向后兼容性。虽然这对于正在运行的机器来说不是问题（因为 Ignition 在第一次启动时只运行一次），但对于维护配置文件的人来说却是一个问题。本文档用于详细说明每个重大更改，并尝试为更改提供一些推理。这并不涵盖对规范的所有更改 - 仅涵盖从一个版本迁移到下一个版本时需要考虑的更改。

TODO, MORE

6. 操作员注意事项

https://coreos.github.io/ignition/operator-notes/

TODO, MORE

7. 支持的平台

目前仅以下平台支持 Ignition：

阿里云( aliyun) - Ignition 将从实例 userdata 中读取其配置。云 SSH 密钥是单独处理的。
Amazon Web Services ( aws) - Ignition 将从实例用户数据中读取其配置。云 SSH 密钥是单独处理的。
Microsoft Azure ( azure)- Ignition 将从提供给实例的自定义数据中读取其配置。云 SSH 密钥是单独处理的。
Microsoft Azure Stack ( azurestack) - Ignition 将从提供给实例的自定义数据中读取其配置。云 SSH 密钥是单独处理的。
Brightbox ( brightbox) - Ignition 将从实例用户数据中读取其配置。云 SSH 密钥是单独处理的。
CloudStack ( cloudstack) - Ignition 将通过元数据服务或配置驱动器从实例用户数据读取其配置。云 SSH 密钥是单独处理的。
DigitalOcean ( digitalocean) - Ignition 将从Droplet 用户数据中读取其配置。云 SSH 密钥和网络配置是分开处理的。
Exoscale ( exoscale) - Ignition 将从实例用户数据中读取其配置。云 SSH 密钥是单独处理的。
Google Cloud ( gcp) - Ignition 将从名为“user-data”的实例元数据条目中读取其配置。云 SSH 密钥是单独处理的。
IBM Cloud ( ibmcloud) - Ignition 将从实例用户数据中读取其配置。云 SSH 密钥是单独处理的。
裸机 ( metal) - 使用ignition.config.url内核参数提供配置的 URL。该URL可以使用http://，https://，tftp://，s3://，或gs://计划指定远程配置。
OpenStack ( openstack) - Ignition 将通过元数据服务或配置驱动器从实例用户数据读取其配置。云 SSH 密钥是单独处理的。
Equinix Metal ( packet) - Ignition 将从实例用户数据中读取其配置。云 SSH 密钥是单独处理的。
IBM Power Systems Virtual Server ( powervs) - Ignition 将从实例用户数据中读取其配置。云 SSH 密钥是单独处理的。
QEMU ( qemu) - Ignition 将从 QEMU 固件配置设备（在 QEMU 2.4.0 及更高版本中可用）上的“opt/com.coreos/config”键读取其配置。
VirtualBox ( virtualbox) - 使用 VirtualBox 来宾属性/Ignition/Config为虚拟机提供配置。
VMware ( vmware) - 使用 VMware Guestinfo 变量ignition.config.data并向ignition.config.data.encoding虚拟机提供配置及其编码。有效的编码为“”、“base64”和“gzip+base64”。Guestinfo 变量可以直接提供，也可以通过 OVF 环境提供，优先考虑直接指定的变量。
Vultr ( vultr) - Ignition 将从实例用户数据中读取其配置。云 SSH 密钥是单独处理的。
zVM ( zvm) - Ignition 将直接从读取器设备读取其配置。vmur程序是必须的，需要vmcp和vmur内核模块为前提，对应的z/VM虚拟单元记录设备（大多数情况下000c为reader，000d为punch）必须在线设置。

Ignition 正在积极开发中，所以这个列表可能会随着时间的推移而增长。

对于大多数云提供商，云 SSH 密钥和自定义网络配置由Afterburn处理。

8. 发布者注意事项

8.1. 内核参数

当 Ignition 更新内核参数时，它将调用一个二进制文件（internal/distro/distro.go在构建时定义并通过覆盖github.com/coreos/ignition/v2/internal/distro.kargsCmd构建标志可覆盖）。Ignition 期望二进制文件接受--should-exist&--should-not-exist参数。如果缺少，则应存在操作应附加参数，如果参数不存在，则不应存在操作不应失败。如有必要，二进制文件还应重新启动系统。

作为二进制实现的示例，请查看examples/ignition-kargs-helper.

如果您的 Ignition 实现不打算提供 kargs 功能，则应禁用该ignition-kargs.service单元。

9. 开发

https://coreos.github.io/ignition/development/

10. 参考链接

https://coreos.github.io/ignition/

以上是关于CoreOS ignition简介的主要内容，如果未能解决你的问题，请参考以下文章

apache ignite系列：简介

不能将Ignite loadCache方法与IgniteBiPredicate一起使用

如何利用fleet单元文件为CoreOS集群创建高灵活性服务

Android 逆向类加载器 ClassLoader ( 类加载器源码简介 | BaseDexClassLoader | DexClassLoader | PathClassLoader )(代码片段

Java/Ignite - Try 块的功能 [重复]

苏宁基于Apache Ignite日均十亿数据的对账实践应用