从Heat中的WaitCondition说起

2014-03-27

本博客所有文章采用的授权方式为 自由转载-非商用-非衍生-保持署名 ,转载请务必注明出处,谢谢。

声明:
本博客欢迎转发,但请保留原作者信息!
新浪微博:@Lingxian_kong;
博客地址:孔令贤的博客;
内容系本人学习、研究和总结,如有雷同,实属荣幸!

写在前面
对一个东西不懂的时候,在网上到处搜教程,搜资料,如果资料少了,还会谩骂,会沮丧;等到好不容易弄懂,到自己总结的时候,却又嫌麻烦,不愿意从基本概念开始提起,觉得太简单,不值一写。

人总是这样,想获取帮助,却又不想提供帮助。当然了,写博客也不全是为了帮助别人,更是为了帮助自己。记得曾经读过一段话,具体怎么说忘记了,但大致意思是,自认为掌握的知识,不一定能准确无误的给别人讲出来,更不用说有体系、有章法的讲出来。我在工作中也发现很多员工,看了几天代码,处理了几个问题,就觉得自己已经炉火纯青了,但当我让他从头给我讲的时候,又没有任何头绪。所以,适时的总结和回顾,也是升华自我、构筑知识体系的过程。

好了,废话不说了,今天总结一下OpenStack中业务编排服务Heat中的WaitCondition以及相关的知识(与其说是Heat,还不如说是CloudFormation)。

基本概念

既然说到WaitCondition,就先提一下condition。虽然Heat类比于AWS的CloudFormation,但目前并不支持condition(但不排除以后会支持),为了扫盲,在这里一并把这个概念提一下。可以把condition看成一个判断结果,创建stack时可以根据某个condition的结果决定是否执行某个动作。说的抽象了,看个例子吧:

"Parameters": {
  "EnvType": {
    "Description": "Environment type.",
    "Default": "test",
    "Type": "String",
    "AllowedValues": [
      "prod",
      "test"
    ]
  }
},
"Conditions": {
  "CreateProdInstance": {
    "Fn::Equals": [
      {
        "Ref": "EnvType"
      },
      "prod"
    ]
  }
}

上述定义了一个参数和一个条件(Condition),如果参数 EnvType 等于 prod,则 CreateProdInstance 条件的计算结果为 true。参数 EnvType 是在创建或更新stack时指定的输入参数。定义了condition后如何使用呢?再看一个例子:

"ProductionInstance": {
  "Type": "AWS::EC2::Instance",
  "Condition": "CreateProdInstance",
  "Properties": {
    "InstanceType": "c1.xlarge",
    "SecurityGroups": [
      {
        "Ref": "ProdSecurityGroup"
      }
    ],
    "KeyName": {
      "Ref": "ProdKeyName"
    },
    "ImageId": {
      "Fn::FindInMap": [
        "RegionMap",
        {
          "Ref": "AWS::Region"
        },
        "AMI"
      ]
    }
  }
}

仅当 CreateProdInstance 条件的计算结果为 true 时,才会创建 ProductionInstance 资源。

好了,言归正传。知道了Condition,那WaitCondition又是什么呢?通俗的讲,可以在模板中放置一个等待条件,以便 Heat 可将stack的创建暂停,并在继续创建stack前等待一个信号。

WaitCondition资源详解

资源定义如下:

{
  "Type": "AWS::CloudFormation::WaitCondition",
  "Properties": {
    "Count": String,
    "Handle": String,
    "Timeout": String
  }
}

Count
继续堆栈创建过程之前必须接收的成功信号的数目。当等待条件接收必需数目的成功信号后,会恢复堆栈的创建。如果等待条件在超时期结束前未接收到指定数目的成功信号,则会认为该等待条件已失败并将该堆栈回滚。
Required: No.
Type: String.

Handle
对用于发送此等待条件信号的句柄的引用。使用 Ref 内部函数来指定一个 AWS::CloudFormation::WaitConditionHandle 资源。
Required: Yes.
Type: String.

Timeout
等待 Count 属性所指定的信号数目的时间长度(以秒为单位)。
Required: Yes.
Type: String.

AWS::CloudFormation::WaitCondition通常和AWS::CloudFormation::WaitConditionHandle一起使用,WaitCondition需要WaitConditionHandle来设置用作信号机制的预签名URL,通过预签名URL发送信号。

典型的场景是:在虚拟机创建后,应用程序部署完毕,才能对外提供服务,此时绑定浮动IP才有意义,所以,浮动IP的绑定要等到应用部署完毕后开始,而不是当虚拟机状态running时(实际上,虚拟机启动系统时,Nova就会认为虚拟机状态为running,此时,服务显然是不可用的),那么如何表明应用程序已经部署完毕了呢?如果读过我之前的一篇博客,那么应该知道,CloudFormation提供了一系列的帮助脚本来辅助stack的创建和应用的部署。这里就用到了cfn-signal脚本,通常在应用部署完后调用。下面是一个简单的template例子(为了后面的演示方便,很多参数我都是写死的,需要根据实际情况做修改):

Resources:
  MyWaitHandle:
    Type: AWS::CloudFormation::WaitConditionHandle

  MyServer:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: m1.small
      ImageId: F17-x86_64-cfntools
      KeyName: heatkey
      SubnetId: 7cb2cb6f-91d1-4649-a416-9c4c867a0d26
      AvailabilityZone: nova:n0819a69aa40a
      UserData:
        Fn::Base64:
          Fn::Join:
          - "\n"
          - - "#!/bin/bash -v"
            - "PATH=${PATH}:/opt/aws/bin"
            - Fn::Join:
              - ""
              - - "cfn-signal -e 0 -r Done '"
                - {"Ref" : "MyWaitHandle"}
                - "'"

  MyWaitCondition:
    Type: AWS::CloudFormation::WaitCondition
    DependsOn: MyServer
    Properties:
      Handle: {"Ref": "MyWaitHandle"}
      Timeout: 300

信号机制

对于CloudFormation来说,cfn-signal调用了curl命令向CloudFormation发送信号,如下:

curl -T /tmp/a "https://cloudformation-waitcondition-test.s3.amazonaws.com/arn%3Aaws%3Acloudformation%3Aus-east-1%3A034017226601%3Astack%2Fstack-gosar-20110427004224-test-stack-with-WaitCondition--VEYW%2Fe498ce60-70a1-11e0-81a7-5081d0136786%2FmyWaitConditionHandle?Expires=1303976584&AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE&Signature=ik1twT6hpS4cgNAw7wyOoRejVoo%3D"

其中,/tmp/a中的内容为:

{
  "Status": "SUCCESS",
  "Reason": "Configuration Complete",
  "UniqueId": "ID1234",
  "Data": "Application has completed configuration."
}

或者,直接一步到位:

curl -X PUT -H 'Content-Type:' --data-binary '{"Status" : "SUCCESS","Reason" : "Configuration Complete","UniqueId" : "ID1234","Data" : "Application has completed configuration."}' https://cloudformation-waitcondition-test.s3.amazonaws.com/arn%3Aaws%3Acloudformation%3Aus-east-1%3A034017226601%3Astack%2Fstack-gosar-20110427004224-test-stack-with-WaitCondition--VEYW%2Fe498ce60-70a1-11e0-81a7-5081d0136786%2FmyWaitConditionHandle?Expires=1303976584&AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE&Signature=ik1twT6hpS4cgNAw7wyOoRejVoo%3D

其中,发送回的内容遵循如下格式:

{
  "Status": "StatusValue",
  "UniqueId": "Some UniqueId",
  "Data": "Some Data",
  "Reason": "Some Reason"
}

StatusValue 是SUCCESS或FAILURE;
UniqueId 表示发送至Heat的信号,如果等待条件的 Count 属性大于 1,那么在针对特定等待条件发送的所有信号中,UniqueId 值必须唯一;
Data 是您想要通过信号发送回的任何信息;
Reason 为字符串,除了要符合 JSON 格式外,对其内容无任何其他限制。

对于Heat来说,从虚拟机内部访问的URL如下(已经做了%3A和%2F的转换):

http://172.30.101.207:8000/v1/waitcondition/arn:openstack:heat::df816333ee04421d96aea3470b36dd51:stacks/waitcondition_test/16b1d980-8fad-44b7-aac7-34f74d38ae22/resources/MyWaitHandle?Timestamp=2014-03-27T03:41:17Z&SignatureMethod=HmacSHA256&AWSAccessKeyId=1599e1ff129a4615ae25ba44099ff677&SignatureVersion=2&Signature=MMS4fBdg8jLZozRd9TYcJVYhMjODY%2B1lzFJTmQq74Yg%3D

配置

要使用WaitCondition,需要关注heat配置文件中如下几个配置项:

[DEFAULT]
heat_metadata_server_url=http://<heat metadata server ip>:8000
heat_waitcondition_server_url=http://<heat waitcondition server ip>:8000/v1/waitcondition

实战

准备活动

  • Havana环境,功能正常(特别是网络)
  • 镜像注册到Glance,Heat经典的Fedora镜像,注意镜像名称使用”F17-x86_64-cfntools”
  • 模板,直接使用上面那个简单的模板内容,根据实际情况更新模板中使用的SubnetId和AvailabilityZone,保存为”waitcondition_test.template”
  • 为方便登录,创建keypair,名称为”heatkey”

相关的命令:

nova keypair-add heathey > heatkey.pem
glance image-create --name="F17-x86_64-cfntools" --public --container-format=ovf --disk-format=qcow2 < /home/kong/F17-x86_64-cfntools.qcow2

创建stack

heat stack-create waitcondition_test --template-file=/home/kong/waitcondition_test.template

等待stack创建成功,可以使用heat event-list waitcondition_test查看stack创建过程中的事件。

n548998f4a206:/home/kong # heat event-list waitcondition_test
+-----------------+----+------------------------+--------------------+----------------------+
| resource_name   | id | resource_status_reason | resource_status    | event_time           |
+-----------------+----+------------------------+--------------------+----------------------+
| MyWaitHandle    | 61 | state changed          | CREATE_IN_PROGRESS | 2014-03-27T03:41:17Z |
| MyWaitHandle    | 62 | state changed          | CREATE_COMPLETE    | 2014-03-27T03:41:17Z |
| MyServer        | 63 | state changed          | CREATE_IN_PROGRESS | 2014-03-27T03:41:17Z |
| MyServer        | 64 | state changed          | CREATE_COMPLETE    | 2014-03-27T03:41:23Z |
| MyWaitCondition | 65 | state changed          | CREATE_IN_PROGRESS | 2014-03-27T03:41:23Z |
| MyWaitCondition | 66 | state changed          | CREATE_COMPLETE    | 2014-03-27T03:43:48Z |
+-----------------+----+------------------------+--------------------+----------------------+

查看虚拟机启动过程,看到如下输出:

代码讲解

虽然是代码讲解,但我还是少贴点代码,毕竟是容易变动的东西,主要说一说代码背后的思路。还是以上面的template内容为例,模板中有三个资源,依赖关系是:

在资源映射中,’AWS::CloudFormation::WaitConditionHandle’对应于WaitConditionHandle对象,在创建该资源时,会先创建一个用户:

def _create_user(self):
    # Check for stack user project, create if not yet set
    if not self.stack.stack_user_project_id:
        project_id = self.keystone().create_stack_domain_project(
            stack_name=self.stack.name)
        self.stack.set_stack_user_project_id(project_id)

    # Create a keystone user in the stack domain project
    user_id = self.keystone().create_stack_domain_user(
        username=self.physical_resource_name(),
        password=self.password,
        project_id=self.stack.stack_user_project_id)

    # Store the ID in resource data, for compatibility with SignalResponder
    db_api.resource_data_set(self, 'user_id', user_id)

以及用户的EC2密钥:

def _create_keypair(self):
    # Subclasses may optionally call this in handle_create to create
    # an ec2 keypair associated with the user, the resulting keys are
    # stored in resource_data
    user_id = self._get_user_id()
    kp = self.keystone().create_stack_domain_user_keypair(
        user_id=user_id, project_id=self.stack.stack_user_project_id)
    if not kp:
        raise exception.Error(_("Error creating ec2 keypair for user %s") %
                              user_id)
    else:
        db_api.resource_data_set(self, 'credential_id', kp.id,
                                 redact=True)
        db_api.resource_data_set(self, 'access_key', kp.access,
                                 redact=True)
        db_api.resource_data_set(self, 'secret_key', kp.secret,
                                 redact=True)
    return kp

从模板中可以看到,虚拟机和WaitCondition都依赖于WaitConditionHandle,在资源解析时,{"Ref" : "MyWaitHandle"}元素需要调用WaitConditionHandle的FnGetRefId方法获取一个请求URL(ec2_signed_url),并且将上述的密钥加入到请求中。创建虚拟机时,作为user-data的内容注入到虚拟机内,由cfn-init在虚拟机内部进行调用。

而在WaitCondition资源的创建中,会在超时时间内循环调用:

handle_status = handle.get_status() 其实是在获取handle资源的metadata的内容,那么metadata的内容从何而来呢?

在Heat的服务中,有一个cfn服务,在heat的paste.ini中定义如下:

[app:apicfnv1app]
paste.app_factory = heat.common.wsgi:app_factory
heat.app_factory = heat.api.cfn.v1:API

在该服务中,定义了stack和signal资源,在signal资源中就对外提供了update_waitconditionAPI接口(在虚拟机内部会调用这个接口),在业务的处理中,其实就调用了handle的metadata_update方法根据请求的参数来更新metadata内容。这样就跟WaitCondition完成了交互,WaitCondition的循环任务就可以结束,该资源就算是创建成功了。

文章评论

comments powered by Disqus


章节列表