cloud-init的使用(cloud-init 的模块众多,功能很全,是实现 instance 定制的神器)

一、cloud-init 工作原理

cloud-init 是 linux 的一个工具,当系统启动时,cloud-init 可从 nova metadata 服务或者 config drive 中获取 metadata,完成包括但不限于下面的定制化工作:

设置默认语言环境

设置实例主机名

添加 ssh keys到 .ssh/authorized_keys

设置用户密码

配置网络

安装软件包

为了实现 instance 定制工作,cloud-init 会按 4 个阶段执行任务:

local

init

config

final

cloud-init 安装时会将这 4 个阶段执行的任务以服务的形式注册到系统中,比如在 systemd 的环境下,我们能够看到这4个阶段分别对应的服务:

local - cloud-init-local.service

init - cloud-init.service

config - cloud-config.service

final - cloud-final.service

local 阶段

作为 cloud-init 执行的第一个阶段,此时 instance 还不知道该如何配置网卡,cloud-init 的任务就是从 config drive 中获取配置信息,然后写入 /etc/network/interfaces 文件(如果是 centos 则写入 /etc/sysconfig/network-scripts/ifcfg-xxx)。

如果没有 config drive,则将所有网卡配置成 dhcp 模式。这是非常关键的一步,只有当网卡正确配置后,才能获取到 metadata。

关于 local 阶段下一节会通过实验详细分析。

init, config 和 final 阶段

正常情况下,在这三个阶段执行之前 instance 网络已经配置好了,并且已经成功获取到 metadata。cloud-init 的配置文件 /etc/cloud/cloud.cfg 定义了三个阶段分别要执行的任务,任务以 module 形式指定。

cloud-init的使用(cloud-init 的模块众多,功能很全,是实现 instance 定制的神器)_第1张图片

instance 真正的定制工作就是由这些 module 完成的。module 决定做哪些定制化工作,而 metadata 则决定最终定制化的结果。

举个例子,如果 cloud.cfg 中指定了set_hostname这个 module,则意味着 cloud-int 会设置 instance 的主机名,而具体设置成哪个主机名则由 metadata 中hostname参数决定。

有些 module 是有默认行为的,比如growpart,如果 metadata 中没有特别指定,它会自动扩展/分区。

二、 cloud-init 的典型应用(设置 hostanme,设置用户初始密码,安装软件)

设置 hostname

cloud-init 默认会将 instance 的名字设置为 hostname。但这样不太方便,有时希望能够将二者分开,可利用 cloud-init 的set_hostname模块实现。set_hostname它会查询 metadata 中 hostname 信息,默认值就是 instance 的名字。我们可以指定自己的 hostname,方法是将下面的内容传给 cloud-init:

#cloud-config

hostname: my1.cloudman.cc

manage_etc_hosts: true

说明如下:

cloud-init 只会读取以#cloud-config开头的数据,所以这一行一定要写对。

hostname: my1.cloudman.cc告诉 cloud-init 将 hostname 设置为 my1.cloudman.cc。

manage_etc_hosts: true告诉 cloud-init 更新 /etc/hosts 文件。

接下来的问题是:如何将这些信息传给 cloud-init?

有三几种方法:

① instance 部署时,直接将其粘贴到Customization Script输入框中。

cloud-init的使用(cloud-init 的模块众多,功能很全,是实现 instance 定制的神器)_第2张图片

② 将其保存为文件,instance 部署时上传(上图 ② 所示)。

③ 将其保存为文件,命令行nova boot或者openstack server create部署 instance 时,使用参数--user-data传入。

部署成功后,hostname 正确设置,/etc/hosts 也相应更新。

定制用户初始密码

官方的 cloud image 默认只能通过 ssh key 登录。我们可以利用set-passwords模块为用户设置密码并启用密码登录。需要传入的脚本如下:

#cloud-config

chpasswd:

list: |

root:123456

ubuntu:123456

expire: false

ssh_pwauth: true

说明如下:

root 和 ubuntu 用户密码设置为 123456。

ssh_pwauth启用密码登录。

instance 启动后 ssh 验证:

cloud-init的使用(cloud-init 的模块众多,功能很全,是实现 instance 定制的神器)_第3张图片

ubuntu 用户 ssh 密码登录成功,并且可通过密码切换到 root。

安装软件

标准镜像中不可能包含我们需要的所有软件,定制安装是不可避免的。一个办法是部署完后手动安装,另一个办法是通过package-update-upgrade-install模块让 cloud-init 自动为我们安装。

需要传入的脚本如下:

#cloud-config

apt:

primary:

- arches: [default]

search:

-http://1.2.3.4

- https://mirrors.tuna.tsinghua.edu.cn/ubuntu

search_dns: true

packages:

- pwgen

- pastebinit

- [libpython2.7, 2.7.3-0ubuntu3.1]

说明如下:

apt指定安装源的位置,这里为http://1.2.3.4。如果是 yum 源则用yum_repos模块指定,具体用法可参看官网文档。

packages指定需要安装的软件包,还可以指定具体版本。

instance 启动后可看到 /etc/apt/sources.list 中安装源已经更新为http://1.2.3.4。

cloud-init的使用(cloud-init 的模块众多,功能很全,是实现 instance 定制的神器)_第4张图片

由于http://1.2.3.4不是一个有效的 apt 源,安装肯定会失败,我们可以在 /var/log/cloud-init.log 看到失败的信息。

cloud-init的使用(cloud-init 的模块众多,功能很全,是实现 instance 定制的神器)_第5张图片

虽然失败了,但我们至少可以确定如下事情:

传入的脚本是有效的,cloud-init 确实在尝试安装指定的软件。

/var/log/cloud-init.log 会完整地记录 cloud-init 运行的所有细节,是 debug 最重要的工具。

你可能感兴趣的:(cloud-init的使用(cloud-init 的模块众多,功能很全,是实现 instance 定制的神器))