cloud-init 源码阅读

网络初始化:

/usr/lib/python2.7/site-packages/cloudinit/stages.py:

 

分析:

  1. 每次都查找网络配置
  2. 如果找到配置,则 self.distro.apply_network_config_names(netcfg)
    1. 对于新机器,则 self.distro.apply_network_config(netcfg, bring_up=bring_up)  ,包括
      1.  写 ifcfg-eth0 配置文件
      2. if bring_up ,则,启动该网络设备

 

/usr/lib/python2.7/site-packages/cloudinit/stages.py:

分析:

先尝试从三个不同的地方获取网络配置(注意,这里是有优先级的):cmdline、system_cfg、datasource中的network_config; 只要其中一个地方明确禁用网络或存在配置则返回;

如果没有找到任何配置,则进入预定义的配置逻辑net/__init__.py: net.generate_fallback_config() :

 

分析:

  1. lo 排除在外
  2. list目录 SYS_CLASS_NET = “/sys/class/net/”  ,可以找到多个网络设备,如:
  3. 分析现有的网络设备,看看哪个最适合连网
    “””Determine which attached net dev is most likely to have a connection and
    generate network state to run dhcp on that interface”””

    1. 如果是veth开头的,认为是设备对,不考虑
    2. 如果存在 /sys/class/net/{$name}/bridge  则认为是(肯定是)网桥, 也不考虑
    3. 如果是插着线(carrier)的,则加入可以考虑的接口列表,如何判断是否插着线呢?
      参考:

       

      简单说就是: cat /sys/class/net/{$name}/carrier    如果结果是整数,则是插着线呢,否则就没插线,如下:

      注意:
      插着线的意思是,线的两端都是加了电的网络设备,即: 数据链路层是UP的;
      有些网络设备的该文件是不能cat的,如:

    4. 如果cat /sys/class/net/{$name}/dormant  是一个大于0的整型值,也可以考虑
    5. 参考文件 /sys/class/net/{$name}/operstate  ,这里记录了设备的状态,如果状态是: ‘dormant’, ‘down’, ‘lowerlayerdown’, ‘unknown’, 也可以考虑
    6. 最后,对可以考虑的列表进行排序;排在前面的优先考虑; 不过还有个例外,程序里面定义了一个默认的网络设备 DEFAULT_PRIMARY_INTERFACE,就是 eth0, 排序后被特意添加到了列表的最前面; 不出意外的话,后续胜出的基本就是eth0了
  4. 根据上面得到的列表,查找设备的mac地址,只要有一个设备有mac地址,该设备就胜出了,后面的就没戏了
  5. 最后,返回网络配置

     

总结:

分析可知,如果不对网络进行特殊配置的话,cloud-init只能帮我们配置一个网卡; 一般来讲,大部分需求已经满足了。

我们如果看 cloud-init ( /var/log/cloud-init.log )的日志的话,会发现,在多个网卡的时候,虽然其他网卡的信息也被read了,但是最终却没有得到和eth0相同的待遇,现在也就真相大白了

 

 

 

堆栈:

关于cmdline的获取方法: (util.py)

  1. 容器的话,cat /proc/1/cmdline
  2. 非容器的话, cat /proc/cmdline
  3. 结果:

留下评论

邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据