cloud-init 工作原理 - 每天5分钟玩转 OpenStack(171)

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

  1. 设置 default locale
  2. 设置 hostname
  3. 添加 ssh keys到 .ssh/authorized_keys
  4. 设置用户密码
  5. 配置网络
  6. 安装软件包

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

  1. local
  2. init
  3. config
  4. final

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

  1. local - cloud-init-local.service
  2. init - cloud-init.service
  3. config - cloud-config.service
  4. 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 形式指定。

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

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

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

由于篇幅限制,这里就不一一讨论每个 module 了,具体可参看文档 https://cloudinit.readthedocs.io/en/latest/topics/modules.html

后面我们会讨论 cloud-init 典型的使用场景,其中也会涉及常用 module 的示例。

时间: 2024-10-24 22:23:52

cloud-init 工作原理 - 每天5分钟玩转 OpenStack(171)的相关文章

Neutron Router 工作原理 - 每天5分钟玩转 OpenStack(142)

上一节我们创建了 router 连通了 vlan100 和 vlan101, 今天分析router是如何工作的.首先查看控制节点的网络结构发生了什么变化: br-int 上多了两个 port: 1. qr-d295b258-45,从命名上可以推断该 interface 对应 router_100_101 的 interface (d295b258-4586),是 subnet_172_16_100_0 的网关. 2. qr-2ffdb861-73,从命名上可以推断该 interface 对应 r

L2 Population 原理 - 每天5分钟玩转 OpenStack(113)

前面我们学习了 VXLAN,今天讨论跟 VXLAN 紧密相关的 L2 Population. L2 Population 是用来提高 VXLAN 网络 Scalability 的. 通常我们说某个系统的 Scalability 好,其意思是: 当系统的规模变大时,仍然能够高效地工作. L2 Population 到底解决了怎样的 Scalability 问题? 请看下图: 这是一个包含 5 个节点的 VXLAN 网络,每个节点上运行了若干 VM. 现在假设 Host 1 上的 VM A 想与 H

CPU 和内存虚拟化原理 - 每天5分钟玩转 OpenStack(6)

前面我们成功地把 KVM 跑起来了,有了些感性认识,这个对于初学者非常重要.不过还不够,我们多少得了解一些 KVM 的实现机制,这对以后的工作会有帮助. CPU 虚拟化 KVM 的虚拟化是需要 CPU 硬件支持的.还记得我们在前面的章节讲过用命令来查看 CPU 是否支持KVM虚拟化吗? [email protected]:~# egrep -o '(vmx|svm)' /proc/cpuinfo vmx 如果有输出 vmx 或者 svm,就说明当前的 CPU 支持 KVM.CPU 厂商 Inte

Neutron Vlan Network 原理- 每天5分钟玩转 OpenStack(92)

前面我们陆续学习了 Neutron local network,flat network 和 DHCP 服务,从本节将开始讨论 vlan network. vlan network 是带 tag 的网络,是实际应用最广泛的网络类型.下图是 vlan100 网络的示例. 1. 三个 instance 通过 TAP 设备连接到名为 “brqXXXX” linux bridge. 2. 在物理网卡 eth1 上创建了 eth1.100 的 vlan interface,eth1.100 连接到 brq

Service IP 原理 - 每天5分钟玩转 Docker 容器技术(137)

Service Cluster IP 是一个虚拟 IP,是由 Kubernetes 节点上的 iptables 规则管理的. 可以通过 iptables-save 命令打印出当前节点的 iptables 规则,因为输出较多,这里只截取与 httpd-svc Cluster IP 10.99.229.179 相关的信息: 这两条规则的含义是: 如果 Cluster 内的 Pod(源地址来自 10.244.0.0/16)要访问 httpd-svc,则允许. 其他源地址访问 httpd-svc,跳转到

创建 Pool & VIP - 每天5分钟玩转 OpenStack(122)

上节完成了 LBaaS 配置,今天我们开始实现如下 LBaaS 环境. 环境描述如下:1. 创建一个 Pool "web servers".2. 两个 pool member "WEB1" 和 "WEB2",均为运行 Ubuntu cloud image 的 instance.3. load balancer VIP 与 floating IP 关联.4. 位于外网的 client 通过 floating IP 外网访问 web server.

写在最前面 - 每天5分钟玩转 OpenStack(1)

<每天5分钟玩转 OpenStack>是一个 OpenStack 教程,这是第 1 篇. 这个教程有下面两个特点: 系统讲解 OpenStack 从架构到各个组件:从整体到细节逐一讨论 重实践并兼顾理论 主要从实际操作的角度带着大家学习 OpenStack. 为啥要写这个? 简单回答是:因为OpenStack 学习难度大,但如果掌握了价值会很大 先做一个自我介绍吧. 本人网名CloudMan,在 IT 这个行当已经摸爬滚打了十多年,05年之前是搞上层应用开发的,那时候 Java 比较火,所以

每天5分钟 玩转OpenStack

最近在学习OpenStack的相关知识,一直苦于OpenStack的体系庞大以及复杂程度,学习没有进度,停滞不前.偶然机会在51CTO上发现了一个热点的专题关于OpenStack的,题目叫做<每天5分钟 玩转OpenStack>,抱着试试的态度看了几篇,被文章的内容和书写风格吸引了,内容全面,思路清晰,简单易懂,关键是每篇博文的内容很少,绝对是一泡大便的功夫.每周一.周三.周五定时更新,微信也有同步更新.不过大神在博客园cnblogs上的博文没有目录,每次翻阅的时候甚是费劲,可能是大神太忙了,

floating IP 原理分析 - 每天5分钟玩转 OpenStack(107)

上一节我们通过 Web UI 创建为 cirros-vm3 分配了浮动 IP,今天将分析其工作原理. 首先查看 router 的 interface 配置: 可以看到,floating IP 已经配置到 router 的外网 interface qg-b8b32a88-03 上. 查看 router 的 NAT 规则: iptables 增加了两条处理 floating IP 的规则: 1. 当 router 接收到从外网发来的包,如果目的地址是 floating IP 10.10.10.3,将