惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Hacker News: Ask HN
Hacker News: Ask HN
WordPress大学
WordPress大学
T
The Blog of Author Tim Ferriss
The GitHub Blog
The GitHub Blog
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
博客园 - 聂微东
A
About on SuperTechFans
Stack Overflow Blog
Stack Overflow Blog
雷峰网
雷峰网
Microsoft Azure Blog
Microsoft Azure Blog
腾讯CDC
爱范儿
爱范儿
酷 壳 – CoolShell
酷 壳 – CoolShell
博客园 - 【当耐特】
V
Visual Studio Blog
有赞技术团队
有赞技术团队
U
Unit 42
D
Docker
小众软件
小众软件
F
Full Disclosure
I
Intezer
Scott Helme
Scott Helme
P
Privacy International News Feed
P
Proofpoint News Feed
Engineering at Meta
Engineering at Meta
Google DeepMind News
Google DeepMind News
B
Blog
Martin Fowler
Martin Fowler
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Vercel News
Vercel News
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Spread Privacy
Spread Privacy
宝玉的分享
宝玉的分享
S
Security Affairs
www.infosecurity-magazine.com
www.infosecurity-magazine.com
月光博客
月光博客
C
Cisco Blogs
云风的 BLOG
云风的 BLOG
Schneier on Security
Schneier on Security
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
T
Threat Research - Cisco Blogs
量子位
Hacker News - Newest:
Hacker News - Newest: "LLM"
H
Heimdal Security Blog
N
Netflix TechBlog - Medium
H
Hacker News: Front Page
P
Proofpoint News Feed
G
GRAHAM CLULEY
V
Vulnerabilities – Threatpost
S
Schneier on Security

Superuser

A Hybrid Private Cloud as an AI Factory – Superuser How India’s Payment Backbone Runs on Open Source – Superuser What AI Builders Can Learn From a Decade of Open Source CI – Superuser How Pinaka ZTi Builds Sovereign Clouds Governments Can Actually Trust – Superuser KDDI’s Private Cloud Supporting Communications – Superuser When Vietnam’s Cloud Infrastructure Is No Longer the Bottleneck – Superuser Sovereign AI Cloud – Superuser How France’s National Railway Runs on Open Source – Superuser Why Digital Sovereignty Depends on Invisible Labor – Superuser Ongoing Development and Next Steps for DOCOMO and Tacker – Superuser Why AI Agents Need Stronger Sandboxing and What the Kata Containers Community Is Doing About It – Superuser A Guide to Manila Security and Terraform Integration – Superuser A Strategic Growth Opportunity for Open Infrastructure – Superuser NTT DOCOMO’s Tacker Activity – Superuser NTT DOCOMO’s Journey of Virtualization for Mobile Networks – Superuser How Rapifuzz CyberKshetra Built a Scalable Cyber Range on OpenStack (and Cut Costs by 60%) Integration of the Octavia module (Load Balancer as a Service) in an OpenStack Cloud Environment – Part 2 – Superuser OpenStack Case Study: CloudVPS – Superuser The 10th China Open Source Hackathon Recap: Projects, Talks, and More – Superuser Inside CERN’s Open Data portal – Superuser Taking the OpenStack ops manuals to the next level – Superuser Making your first contact with OpenStack – Superuser How tech giant Tencent uses OpenStack – Superuser Managing port level security in OpenStack – Superuser Using Ansible 2.0 to launch a server on OpenStack – Superuser
Simple auto scaling environment with Heat – Superuser
Christian Berendt · 2015-02-09 · via Superuser

This article first appeared on Christian’s blog. Christian Berendt
is currently working as a cloud solution architect for B1 Systems. You should follow him on GitHub.

Heat is the orchestration service included in OpenStack. In teamwork with Ceilometer it is possible to build auto scaling environments. A good entry point to learn how to write Heat Orchestration Templates (HOT) is the HOT Guide. A list of all available resource types (only a few of them are used in the following example) is available in the HOT Reference. Tons of example templates are available in the repository openstack/heat-templates. This article is based on the autoscaling.yaml example template.

Presumptions for the following example:

  • an image with the name Cirros 0.3.3 is available (glance image-create --name "Cirros 0.3.3" --disk-format qcow2 --container-format bare --is-public True --copy http://download.cirros-cloud.net/0.3.3/cirros-0.3.3-x86_64-disk.img)
  • a flavor with the name m1.nano is available (nova flavor-create m1.nano 42 64 0 1)
  • a network with the name internal001 is available (neutron net-create internal001; neutron subnet-create --name internal001 internal001 192.168.200.0/24)

First create a template for a stack with a single instance in the file cirros.yaml.

heat_template_version: 2014-10-16  
description: A simple server.  
resources:  
  server:
    type: OS::Nova::Server
    properties:
      block_device_mapping:
        - device_name: vda
          delete_on_termination: true
          volume_id: { get_resource: volume } 
      flavor: m1.nano
      networks:
        - network: internal001

  volume:
    type: OS::Cinder::Volume
    properties:
      image: 'Cirros 0.3.3'
      size: 1

To validate the syntax use heat template-validate --template-file cirros.yaml.

Test if the template is working like expected with heat stack-create -f cirros.yaml cirros. After a few seconds (or minutes, depends on the environment) heat stack-list should show a stack with stack_status = CREATE_COMPLETE. If not have a look in the output of heat event-list cirros to identify the issue.

To delete the stack run heat stack-delete cirros.

Let’s add a script that generates a high load on all cores of the instance. A high CPU load will be the trigger to launch further instances.

Add the properties user_data_format and user_data to the definition of server.

      user_data_format: RAW
      user_data: |
        #!/bin/sh
        while [ 1 ] ; do echo $((13**99)) 1>/dev/null 2>&1; done &

The cirros.yaml file should now have the following content:

heat_template_version: 2014-10-16  
description: A simple server.  
resources:  
  server:
    type: OS::Nova::Server
    properties:
      block_device_mapping:
        - device_name: vda
          delete_on_termination: true
          volume_id: { get_resource: volume }
      flavor: m1.nano
      networks:
        - network: internal001
      user_data_format: RAW
      user_data: |
        #!/bin/sh
        while [ 1 ] ; do echo $((13**99)) 1>/dev/null 2>&1; done

  volume:
    type: OS::Cinder::Volume
    properties:
      image: 'Cirros 0.3.3'
      size: 1

Create the file environment.yaml to define a new resource type OS::Nova::Server::Cirros.

resource_registry:  
    "OS::Nova::Server::Cirros": "cirros.yaml"

Create a OS::Heat::AutoScalingGroup resource in the file simple.yaml. This group defines the resources that should be scaled.

heat_template_version: 2014-10-16  
description: A simple auto scaling group.  
resources:  
  group:
    type: OS::Heat::AutoScalingGroup
    properties:
      cooldown: 60
      desired_capacity: 2
      max_size: 5
      min_size: 1
      resource:
        type: OS::Nova::Server::Cirros

Start the stack with heat stack-create simple -f simple.yaml -e environment.yaml. There should be 2 instances, the value of the desired_capacity parameter, and nothing more should happen.

Delete the stack with heat stack-delete simple and add the following resources to complete the example.

First a OS::Heat::ScalingPolicy resource.

  scaleup_policy:
    type: OS::Heat::ScalingPolicy
    properties:
      adjustment_type: change_in_capacity
      auto_scaling_group_id: { get_resource: group }
      cooldown: 60
      scaling_adjustment: 1

Finally a OS::Ceilometer::Alarm resource. This resource will notify the scaling policy resource. The scaling policy resource will increase the number of the resources defined in the scaling group.

  cpu_alarm_high:
    type: OS::Ceilometer::Alarm
    properties:
      meter_name: cpu_util
      statistic: avg
      period: 60
      evaluation_periods: 1
      threshold: 50
      alarm_actions:
        - {get_attr: [scaleup_policy, alarm_url]}
      comparison_operator: gt

The simple.yaml file should now have the following content:

heat_template_version: 2014-10-16  
description: A simple auto scaling group.  
resources:  
  group:
    type: OS::Heat::AutoScalingGroup
    properties:
      cooldown: 60
      desired_capacity: 2
      max_size: 5
      min_size: 1
      resource:
        type: OS::Nova::Server::Cirros

  scaleup_policy:
    type: OS::Heat::ScalingPolicy
    properties:
      adjustment_type: change_in_capacity
      auto_scaling_group_id: { get_resource: group }
      cooldown: 60
      scaling_adjustment: 1

  cpu_alarm_high:
    type: OS::Ceilometer::Alarm
    properties:
      meter_name: cpu_util
      statistic: avg
      period: 60
      evaluation_periods: 1
      threshold: 50
      alarm_actions:
        - {get_attr: [scaleup_policy, alarm_url]}
      comparison_operator: gt

Start the complete stack with heat stack-create simple -f simple.yaml -e environment.yaml.

At the beginning there are only 2 instances. After some time (more than 10 minutes because of the default interval of Ceilometer) the number of instances increases to a maximum of 5, the value of the max_size parameter.

Photo by rogersmith // CC BY NC ND