Workload LCM with Heat Florin Stingaciu System Architect Lance Haig featuring Florin Stingaciu System Architect Lance Haig SOLUTION Architect & As the Openstack community continues to simplify the cloud deployment process, more and more businesses are adopting Openstack within their infrastructure. However, there seems to be a lack of knowledge base in the community regarding workload onboarding and management using tools native to Openstack. This talk introduces the advanced use of Heat (with a particular focus on SoftwareDeployment resources) in order to provide a structured process for deploying and managing workloads in the cloud. At the core of this structured process is a base repository containing basic building blocks for Openstack infrastructure, as well as a structure (with examples) for developing and deploying software configurations at all phases of an instance’s lifecycle. The target audience for this talk is the cloud end-user who has some familiarity with Heat (or other similar cloud orchestration tools), as well as devops teams managing cloud resources on behalf of cloud non-friendly users.

Agenda Workloads & Openstack Deployment Options Software Deployments Overview Framework for working with Heat and Software Deployments Reverse Proxy Demo Kubernetes w/ Kargo Demo Wrap-up

What is a workload? A collection of resources that work together in order to offer/produce a particular service/output. Logical components that make up a workload Software Configuration Deployment Software Configuration LCM Infrastructure Deployment Infrastructure LCM

Openstack Workload Deployment Options All Manual Deployment User deploys each infrastructure resource manually User configures each software component manually Disadvantages Slow and error prone process Is not easily reusable No LCM No easy way to group all infrastructure resources that belong together Although quite trivial, this method of deployment is still very popular

Openstack Workload Deployment Options Infrastructure with Heat / Manual Software Configuration User automates infrastructure deployment with Heat via Heat templates User configures each software component manually Advantages: The Heat template now serves as a “recipe” for the infrastructure deployment Heat can be leveraged to determine all resources involved in this workload as well as their current status Infrastructure LCM can be performed via Heat (scaling/adding new resources) Disadvantage A redeployment/scaling action will still require manual software configuration No software configuration LCM

Openstack Workload Deployment Options Infrastructure with Heat / Software Configuration via Cloud-Init User automates infrastructure deployment with Heat via Heat templates User leverages cloud-init to automated software configuration at instance startup Advantages: The Heat template now serves as a “recipe” for the infrastructure deployment Heat can be leveraged to determine all resources involved in this workload as well as their current status Infrastructure LCM can be performed via Heat (scaling/adding new resources) A redeployment is one-click away Disadvantage No software configuration LCM (updating the cloud-init in any resource will lead to a resource recreate (destroy & create) action)

Openstack Workload Deployment Options Infrastructure with Heat / Software Configuration via Cloud-Init and CM tool User automates infrastructure deployment with Heat via Heat templates User leverages cloud-init to automate software configuration at instance startup to install required CM tool/agents User leverages CM engine to deploy software configuration Advantages: The Heat template now serves as a “recipe” for the infrastructure deployment Heat can be leveraged to determine all resources involved in this workload as well as their current status Infrastructure LCM can be performed via Heat (scaling/adding new resources) A redeployment is one-click away Software LCM Disadvantage Two different systems to control the LCM of a workload

Openstack Workload Deployment Options Infrastructure with Heat / Software Configuration via Heat Software Deployments User automates infrastructure deployment with Heat via Heat templates User leverages Heat software deployments to deploy and manage software configurations Advantages: The Heat template now serves as a “recipe” for the infrastructure deployment Heat can be leveraged to determine all resources involved in this workload as well as their current status Infrastructure LCM can be performed via Heat (scaling/adding new resources) A redeployment is one-click away Software LCM Single point of control

What are Software Deployments? A SoftwareDeployment is a type of resource in Heat that applies a Heat SoftwareConfig resource to a particular instance Software Deployments require a number of agents to be available at run time. These agents can be made available by: Installing them at instance boot time via cloud-init Pre-packaging them in the image Agents running on the instance continuously poll Heat for new or updated SoftwareDeployment resources and apply them when available In short, Heat provides us with a native configuration management engine that lets the user apply software configurations by declaring software deployment resources

Software Deployments Format Simple webserver example The SoftwareConfig resource encapsulates the configuration required to install the webserver The SoftwareDeployment resource associates the SoftwareConfig resource to an instance The Signal Transport indicates the method in which the agents should signal the status of the software deployment Actions represent at what resource status (create, update, suspend and delete) this software deployment should be applied http_config: type: OS::Heat::SoftwareConfig properties: group: script config: | #!/bin/bash yum -y install httpd echo "Hello World!" > /var/www/html/index.html service httpd start http_deployment: type: OS::Heat::SoftwareDeployment config: { get_resource: http_config } server: { get_resource: instance } signal_transport: HEAT_SIGNAL actions: - CREATE - UPDATE

Supported hooks Group attribute in the SoftwareConfig represents what type of hook this software configuration requires Many types of hooks are available currently Quite simple to develop new hook for any type software configuration ansible apply-config cfn-init docker-cmd docker-compose hiera json-file kubblet puppet salt script

Software Deployment Flow os-collect-config on the instance will use the software_config_trasport attribute of the instance to poll Heat for software deployments os-refresh-config will trigger heat-config heat-config will determine the appropriate hook to execute the software configuration heat-config-notify will use a signal_transport attribute of the software deployment to deliver the status of the deployment (including outputs) back to Heat Cloud-init versus Software Deployments You can only apply software configs using cloud-init at instance creation Creating dependecies between instances at a software configuration layer with cloud-init is a HUGE hassle There is no way to pass back information to Heat when using cloud-init. Software deployments support Outputs

Putting it all together Workloads are highly flexible systems that can be deployed and managed in many different ways However, a structured framework can be developed for the standardization of each workload workflow components This framework should Encourage collaboration as most workload components are quite modular in nature (ie. an Openstack network definition, a webserver installation) Leverage version control as a means to record workload changes over time Minimize the amount of different systems involved to improve ease of use

The Framework Base Git Repository /lib - This directory contains Heat templates for two things: Basic building blocks for Openstack Infrastructure Networks Instances Volumes Clusters Load-Balancers Basic building blocks for various software configurations (ie. install web server, add user, disable selinux) Ubuntu RHEL Boot Config scripts to install required agents for software deployments

The Framework Base Git Repository /env - Heat environment files corresponding to different operating systems that contain all the resources created in the lib directory (local file paths only) /env-ext - This directory is the exact same as /env however each environment file uses URLs to point to the components hosted on gitHub; this means that anyone who wants to use this library would just have to download these files without having to download the whole repo /tests - This directory contains a number of Heat templates that utilize the components in the lib directory to test their functionality (also serve as good examples) Openstack infrastructure tests Software Configuration tests /README.rst - A good overview of the overall repository and workflows for developing new components

Reverse Proxy Demo Network Stack Definition type: HeatLib::Network::FullStack properties: name: { get_param: name } cidr: { get_param: network_cidr } external_network: { get_param: external_network } Parameters: name: reverse_proxy cidr: 192.168.0.0/24 external_network: public_network

Reverse Proxy Demo Security Group Definition instance_access: type: HeatLib::SecurityGroups::Generic properties: name: { get_param: name } ports: { get_param: ports } protocols: { get_param: protocols } Parameters: name: reverse_proxy ports: 22,80,443 protocols: tcp

Reverse Proxy Demo Instance Definition type: HeatLib::Instance::Basic properties: name: { get_param: name } key: { get_param: key } image: { get_param: image } flavor: { get_param: flavor } subnets: - { get_attr: [ network_stack, subnet_uuid ] } security_groups: - { get_attr: [ instance_access, security_group_uuid ] } Parameters: name: reverse_proxy key: my_key image: centos flavor: m1.small

Reverse Proxy Demo Floating IP Definition type: HeatLib::Network::FloatingIP properties: external_network: { get_param: external_network } port: { get_attr: [instance, instance_addresses, { get_attr: [ network_stack, network_uuid ] } , 0, port ] } Parameters: external_network: public_network

Reverse Proxy Demo Volume Definition data_volume: type: HeatLib::Volume::Basic properties: name: { get_param: name } size: { get_param: volume_size } instance: { get_attr: [ instance, instance_uuid ] } Parameters: name: reverse_proxy size: 10

Reverse Proxy Demo Software Deployment - Volume Mount Definition data_volume_mount: type: HeatLib::SoftwareConfig::VolumeMount properties: mount_path: "/data/" make_fs: "true" volume_id: { get_attr: [ data_volume, volume_uuid ] } instance: { get_attr: [ instance, instance_uuid ] } Parameters: N/A

Reverse Proxy Demo Software Deployment - Webserver Definition type: HeatLib::SoftwareConfig::HTTP properties: instance: { get_attr: [ instance, instance_uuid ] } Parameters: N/A

Reverse Proxy Demo Software Deployment - Reverse Proxy Definition reverse_proxy_google: type: HeatLib::SoftwareConfig::HTTP::ReverseProxy depends_on: webserver properties: instance: { get_attr: [ instance, instance_uuid ] } proxy_pass: "/google http://google.com/" Parameters: N/A

Reverse Proxy - Demo Video

Kubernetes with Kargo - Demo Video

Summary Heat can be leveraged to provide both infrastructure and software configuration life cycle management These Heat capabilities must be combined with a framework that consists of A repository serving as the base for this framework that allows for: Collaboration Version Control Workload Deployment Workflow Workload Update Workflow This framework enables the cloud end-user to minimize time spent on cloud administrative actions and spend more time on workload development

Links GitHub Organization: https://github.com/heat-extras Heat Lib: https://github.com/heat-extras/heat-lib Heat Tutorial: https://github.com/heat-extras/heat-tutorial Part 1-3: Heat Basics Part 4: Cloud-init Part 5: Software Deployments Part 6: Vertical and Horizontal Scaling More to come

Thanks for joining us! P.S. We’re hiring! Q/A Thanks for joining us! P.S. We’re hiring!