每天5分钟玩转openstack第九章.doc

实现instance定制化,cloud-init(或cloudbase-init)只是故事的一半,metadataservice则是故事的的另一半。两者的分工是:metadataservice为cloud-init提供自定义配置数据,cloud-init完成配置工作。MetadataService前面讨论了一些cloud-init和cloudbase-init相关的经验,收到了很多反馈,大家对instance启动时是如何完成自定义配置这个过程非常感兴趣,希望能够系统讲一下。这个主题确实很重要,实际应用场景很多,确实很有必要系统讨论一番,作为对现有教程的补充。instance是通过image部署出来的,image中包含了操作系统(),最常用的软件(例如SSH)以及最通用的配置(例如eth0dhcp)。然而在创建instance的时候,我们往往希望对instance进行一些额外的配置,比如:安装某些包、开启一些服务、添加SSH秘钥、配置hostname等等。有几个方法可以完成这项工作:。这种方案可以实现,但不现实。image应该被看着是一个模板,存放的是通用的内容。在image中加入个性化配置的做法要么使image变得非常庞杂,要么导致数量众多的image,不易管理。。由于需要手工操作,instance数量多了之后工作量会激增,而且容易出错。:由OpenStackMetadataService提供instance的配置信息(这些信息被统称为metadata)。instance启动时向MetadataService请求并获得自己的metadata,instance的cloud-init(或cloudbase-init)根据metadata完成个性化配置工作。这个方案的优点是不需要修改基础image,保证了image的稳定性,同时实现了instance自动化地个性配置。最高频的应用将sshpublickey添加到instance。首先在“Project->Compute->Access&Security”中创建KeyPair。OpenStack会创建一对sshpulbickey和privatekey,publickey存放在OpenStack数据库中,privatekey会在我们点击“CreateKeyPair”按钮时自动下载。现在"cloudman"这个keypair就是我们要用的metadata了。部署instance时,选择"cloudman"。instance启动后,。这样我们就可以用cloudman的privatekey直接登录instance。下面是MetadataService的架构图,本节我们详细讨论各个组件以及它们之间的关系。nova-api-metadatanova-api-metadata是nova-api的一个子服务,它是metadata的提供者,instance可以通过nova-api-metadata的RESTAPI来获取metadata信息。nova-api-metadata运行在控制节点上,服务端口是8775。通过进程ID 13415 查看该启动程序。我们这个环境是devstack,nova-api-metadata的程序名称就是 nova-api,nova-api-metadata与常规的nova-api服务是合并在一起的。不过在OpenStack的其他发行版中可能有单独的 nova-api-metadata 进程存在。 enabled_apis 指定是否启用nova-api-metadata。pute 是常规的nova-api服务,metadata 就是nova-api-metadata服务。neutron-metadata-agentnova-api-metadata在控制节点上,走OpenStack内部管理网络,instance是无法通过http://controller_ip:8775直接访问metadataservice的,因为网络不通。那怎么办呢?答案是:借助neutron-metadata-agent。neutron-metadata-agent运行在网络节点上。instance先将metadata请求发给neutron-metadata-agent,neutron-metadata-agent再将请求转发到nova-api-metadata。这里还有个问题需要解释清楚:instance如何将请求发送到neutron-metadata-age