mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
TSL&PRF
@wxy
This commit is contained in:
Xingyu Wang
parent
a73fb2425a
commit
277bcf5a37
@ -1,82 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (wxy)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (How Cloud-init can be used for your Raspberry Pi homelab)
|
||||
[#]: via: (https://opensource.com/article/20/5/cloud-init-raspberry-pi-homelab)
|
||||
[#]: author: (Chris Collins https://opensource.com/users/clcollins)
|
||||
|
||||
How Cloud-init can be used for your Raspberry Pi homelab
|
||||
======
|
||||
Automate adding new devices and users to your homelab while getting to
|
||||
know a cloud-industry standard.
|
||||
![gears and lightbulb to represent innovation][1]
|
||||
|
||||
[Cloud-init][2] is a standard—it would not be a stretch to say it is _the_ standard—that cloud providers use to provide initialization and configuration data to cloud instances. It is used most often on the first boot of a new instance to automate network setup, account creation, and SSH (secure shell) key installation—anything required to bring a new system online so that it is accessible by the user.
|
||||
|
||||
In a previous article, [_Modify a disk image to create a Raspberry Pi-based homelab_][3], I showed how to customize the operating system image for single-board computers like the Raspberry Pi to accomplish a similar goal. With Cloud-init, there is no need to add custom data to the image. Once it is enabled in your images, your virtual machines, physical servers, even tiny Raspberry Pis can behave like cloud instances in your own "private cloud at home." New machines can just be plugged in, turned on, and automatically become part of your [homelab][4].
|
||||
|
||||
To be honest, Cloud-init is not designed with homelabs in mind. As I mentioned, you can easily modify the disk image for a given set of systems to enable SSH access and configure them after the first boot. Cloud-init is designed for large-scale cloud providers that need to accommodate many customers, maintain a small set of images, and provide a mechanism for those customers to access instances without customizing an image for each of them. A homelab with a single administrator does not face the same challenges.
|
||||
|
||||
Cloud-init is not without merit in the homelab, though. Education is one of my goals for the private cloud at home project, and setting up Cloud-init for your homelab is a great way to gain experience with a technology used heavily by cloud providers, large and small. Cloud-init is also an alternative to other initial-configuration options. Rather than customizing each image, ISO, etc. for every device in your homelab and face tedious updates when you want to make changes, you can just enable Cloud-init. This reduces technical debt—and is there anything worse than _personal_ technical debt? Finally, using Cloud-init in your homelab allows your private cloud instances to behave the same as any public cloud instances you have or may have in the future—a true [hybrid cloud][5].
|
||||
|
||||
### About Cloud-init
|
||||
|
||||
When an instance configured for Cloud-init boots up and the service (actually, four services in systemd implementations to handle dependencies during the boot process) starts, it checks its configuration for a [datasource][6] to determine what type of cloud it is running in. Each major cloud provider has a datasource configuration that tells the instance where and how to retrieve configuration information. The instance then uses the datasource information to retrieve configuration information provided by the cloud provider, such as networking information and instance-identification information, and configuration data provided by the customer, such as authorized keys to be copied, user accounts to be created, and many other possible tasks.
|
||||
|
||||
After retrieving the data, Cloud-init then configures the instance: setting up networking, copying the authorized keys, etc., and finally completing the boot process. Then it is accessible to the remote user, ready for further configuration with tools like [Ansible][7] or [Puppet][8] or prepared to receive a workload and begin its assigned tasks.
|
||||
|
||||
### Configuration data
|
||||
|
||||
As mentioned above, the configuration data used by Cloud-init comes from two potential sources: the cloud provider and the instance user. In a homelab, you fill both roles: providing networking and instance information as the cloud provider and providing configuration information as the user.
|
||||
|
||||
#### The cloud provider metadata file
|
||||
|
||||
In your cloud provider role, your homelab datasource will offer your private cloud instances a metadata file. The [metadata][9] file contains information such as the instance ID, cloud type, Python version (Cloud-init is written in and uses Python), or a public SSH key to be assigned to the host. The metadata file may also contain networking information if you're not using DHCP (or the other mechanisms Cloud-init supports, such as a config file in the image or kernel parameters).
|
||||
|
||||
#### The user-provided user-data file
|
||||
|
||||
The real meat of Cloud-init's value is in the user-data file. Provided by the user to the cloud provider and included in the datasource, the [user-data][10] file is what turns an instance from a generic machine into a member of the user's fleet. The user-data file can come in the form of an executable script, working the same as the script would in normal circumstances, or as a cloud-config YAML file, which makes use of [Cloud-init's modules][11] to perform configuration tasks.
|
||||
|
||||
### Datasource
|
||||
|
||||
The datasource is a service provided by the cloud provider that offers the metadata and user-data files to the instances. Instance images or ISOs are configured to tell the instance what datasource is being used.
|
||||
|
||||
For example, Amazon AWS provides a [link-local][12] file that will respond to HTTP requests from an instance with the instance's custom data. Other cloud providers have their own mechanisms, as well. Luckily for the private cloud at home project, there are also NoCloud data sources.
|
||||
|
||||
[NoCloud][13] datasources allow configuration information to be provided via the kernel command as key-value pairs or as user-data and metadata files provided as mounted ISO filesystems. These are useful for virtual machines, especially paired with automation to create the virtual machines.
|
||||
|
||||
There is also a NoCloudNet datasource that behaves similarly to the AWS EC2 datasource, providing an IP address or DNS name from which to retrieve user data and metadata via HTTP. This is most helpful for the physical machines in your homelab, such as Raspberry Pis, [NUCs][14], or surplus server equipment. While NoCloud could work, it requires more manual attention—an anti-pattern for cloud instances.
|
||||
|
||||
### Cloud-init for the homelab
|
||||
|
||||
I hope this gives you an idea of what Cloud-init is and how it may be helpful in your homelab. It is an incredible tool that is embraced by major cloud providers, and using it at home can be educational and fun and help you automate adding new physical or virtual servers to your lab. Future articles will detail how to create both simple static and more complex dynamic Cloud-init services and guide you in incorporating them into your private cloud at home.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/5/cloud-init-raspberry-pi-homelab
|
||||
|
||||
作者：[Chris Collins][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/clcollins
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/innovation_lightbulb_gears_devops_ansible.png?itok=TSbmp3_M (gears and lightbulb to represent innovation)
|
||||
[2]: https://cloudinit.readthedocs.io/
|
||||
[3]: https://opensource.com/article/20/5/disk-image-raspberry-pi
|
||||
[4]: https://opensource.com/article/19/3/home-lab
|
||||
[5]: https://www.redhat.com/en/topics/cloud-computing/what-is-hybrid-cloud
|
||||
[6]: https://cloudinit.readthedocs.io/en/latest/topics/datasources.html
|
||||
[7]: https://www.ansible.com/
|
||||
[8]: https://puppet.com/
|
||||
[9]: https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html#
|
||||
[10]: https://cloudinit.readthedocs.io/en/latest/topics/format.html
|
||||
[11]: https://cloudinit.readthedocs.io/en/latest/topics/modules.html
|
||||
[12]: https://en.wikipedia.org/wiki/Link-local_address
|
||||
[13]: https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html
|
||||
[14]: https://en.wikipedia.org/wiki/Next_Unit_of_Computing
|
||||
@ -0,0 +1,83 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (wxy)
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (How Cloud-init can be used for your Raspberry Pi homelab)
|
||||
[#]: via: (https://opensource.com/article/20/5/cloud-init-raspberry-pi-homelab)
|
||||
[#]: author: (Chris Collins https://opensource.com/users/clcollins)
|
||||
|
||||
在你的树莓派家庭实验室中使用 Cloud-init
|
||||
======
|
||||
|
||||
> 了解了云行业的标准，该向你的家庭实验室自动添加新设备和用户了。
|
||||
|
||||
|
||||
|
||||
[Cloud-init][2]（可以说）是一个标准，云提供商用它来为云实例提供初始化和配置数据。它最常用于新实例的首次启动，以自动完成网络设置、账户创建和 SSH 密钥安装等使新系统上线所需的任何事情，以便用户可以访问它。
|
||||
|
||||
在之前的一篇文章《[修改磁盘镜像来创建基于树莓派的家庭实验室][3]》中，我展示了如何为像树莓派这样的单板计算机定制操作系统镜像以实现类似的目标。有了 Cloud-init，就不需要向镜像中添加自定义数据。一旦在镜像中启用了它，你的虚拟机、物理服务器，甚至是小小的树莓派都可以表现得像你自己的 “家庭私有云” 中的云计算实例。新机器只需插入、打开，就可以自动成为你的[家庭实验室][4]的一部分。
|
||||
|
||||
说实话，Cloud-init 的设计并没有考虑到家庭实验室。正如我所提到的，你可以很容易地修改给定的一套系统磁盘镜像，以启用 SSH 访问并在第一次启动后对它们进行配置。Cloud-init 是为大规模的云提供商设计的，这些提供商需要容纳许多客户，维护一组小的镜像，并为这些客户提供访问实例的机制，而无需为每个客户定制一个镜像。拥有单个管理员的家庭实验室则不会面临同样的挑战。
|
||||
|
||||
不过，Cloud-init 在家庭实验室中也不是没有可取之处。教育是我的家庭私有云项目的目标之一，而为你的家庭实验室设置 Cloud-init 是一个很好的方式，可以获得大大小小的云提供商大量使用的技术的经验。Cloud-init 也是其他初始配置选项的替代方案之一。与其为家庭实验室中的每台设备定制每个镜像、ISO 等，并在你要进行更改时面临繁琐的更新，不如直接启用 Cloud-init。这减少了技术债务 —— 还有什么比*个人*技术债务更糟糕的吗？最后，在你的家庭实验室中使用 Cloud-init 可以让你的私有云实例与你拥有的或将来可能拥有的任何公有云实例表现相同 —— 这是真正的[混合云][5]。
|
||||
|
||||
### 关于 Cloud-init
|
||||
|
||||
当为 Cloud-init 配置的实例启动并且服务开始运行时（实际上是 systemd 中的四个服务，以处理启动过程中的依赖关系），它会检查其配置中的[数据源][6]，以确定其运行在什么类型的云中。每个主要的云提供商都有一个数据源配置，告诉实例在哪里以及如何检索配置信息。然后，实例使用数据源信息检索云提供商提供的配置信息（如网络信息和实例识别信息）和客户提供的配置数据（如要复制的授权密钥、要创建的用户账户以及许多其他可能的任务）。
|
||||
|
||||
检索数据后，Cloud-init 再对实例进行配置：设置网络、复制授权密钥等，最后完成启动过程。然后，远程用户就可以访问它，准备好使用 [Ansible][7] 或 [Puppet][8] 等工具进行进一步的配置，或者准备好接收工作负载并开始分配任务。
|
||||
|
||||
### 配置数据
|
||||
|
||||
如上所述，Cloud-init 使用的配置数据来自两个潜在来源：云提供商和实例用户。在家庭实验室中，你扮演着这两种角色：作为云提供商提供网络和实例信息，作为用户提供配置信息。
|
||||
|
||||
#### 云提供商元数据文件
|
||||
|
||||
在你的云提供商角色中，你的家庭实验室数据源将为你的私有云实例提供一个元数据文件。这个[元数据][9]文件包含实例 ID、云类型、Python 版本（Cloud-init 用 Python 编写并使用 Python）或要分配给主机的 SSH 公钥等信息。如果你不使用 DHCP（或 Cloud-init 支持的其他机制，如镜像中的配置文件或内核参数），元数据文件还可能包含网络信息。
|
||||
|
||||
#### 用户提供的用户数据文件
|
||||
|
||||
Cloud-init 的真正价值在于用户数据文件。[用户数据][10]文件由用户提供给云提供商，并包含在数据源中，它将实例从一台普通的机器变成了用户舰队的一员。用户数据文件可以以可执行脚本的形式出现，与正常情况下脚本的工作方式相同；也可以以云服务配置 YAML 文件的形式出现，利用 [Cloud-init 的模块][11] 来执行配置任务。
|
||||
|
||||
### 数据源
|
||||
|
||||
数据源是由云提供商提供的服务，它为实例提供了元数据和用户数据文件。实例镜像或 ISO 被配置为告知实例正在使用什么数据源。
|
||||
|
||||
例如，亚马逊 AWS 提供了一个 [link-local][12] 文件，它将用实例的自定义数据来响应实例的 HTTP 请求。其他云提供商也有自己的机制。幸运的是，对于家庭私有云项目来说，也有 NoCloud 数据源。
|
||||
|
||||
[NoCloud][13] 数据源允许通过内核命令以键值对的形式提供配置信息，或通过挂载的 ISO 文件系统以用户数据和元数据文件的形式提供。这些对于虚拟机来说很有用，尤其是与自动化搭配来创建虚拟机。
|
||||
|
||||
还有一个 NoCloudNet 数据源，它的行为类似于 AWS EC2 数据源，提供一个 IP 地址或 DNS 名称，通过 HTTP 从这里检索用户数据和元数据。这对于你的家庭实验室中的物理机器来说是最有帮助的，比如树莓派、[NUC][14] 或多余的服务器设备。虽然 NoCloud 可以工作，但它需要更多的人工关注 —— 这是云实例的反模式。
|
||||
|
||||
### 家庭实验室的 Cloud-init
|
||||
|
||||
我希望这能让你了解到 Cloud-init 是什么，以及它对你的家庭实验室有何帮助。它是一个令人难以置信的工具，被主要的云提供商所接受，在家里使用它可以是为了教育和乐趣，并帮助你自动向实验室添加新的物理或虚拟服务器。之后的文章将详细介绍如何创建简单的静态和更复杂的动态 Cloud-init 服务，并指导你将它们纳入你的家庭私有云。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/5/cloud-init-raspberry-pi-homelab
|
||||
|
||||
作者：[Chris Collins][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[wxy](https://github.com/wxy)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/clcollins
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/innovation_lightbulb_gears_devops_ansible.png?itok=TSbmp3_M (gears and lightbulb to represent innovation)
|
||||
[2]: https://cloudinit.readthedocs.io/
|
||||
[3]: https://linux.cn/article-12277-1.html
|
||||
[4]: https://opensource.com/article/19/3/home-lab
|
||||
[5]: https://www.redhat.com/en/topics/cloud-computing/what-is-hybrid-cloud
|
||||
[6]: https://cloudinit.readthedocs.io/en/latest/topics/datasources.html
|
||||
[7]: https://www.ansible.com/
|
||||
[8]: https://puppet.com/
|
||||
[9]: https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html#
|
||||
[10]: https://cloudinit.readthedocs.io/en/latest/topics/format.html
|
||||
[11]: https://cloudinit.readthedocs.io/en/latest/topics/modules.html
|
||||
[12]: https://en.wikipedia.org/wiki/Link-local_address
|
||||
[13]: https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html
|
||||
[14]: https://en.wikipedia.org/wiki/Next_Unit_of_Computing
|
||||
Loading…
Reference in New Issue
Block a user