If you wanted to build a house, a block, or a neighborhood, you’d start with a blueprint. Some authoritative document that you rely on to determine how each component should look and operate to turn your vision into a bustling neighborhood with houses, cafes, pizzerias, schools, and businesses. The complexity of working with OpenStack Orchestration (Heat) templates often keeps people away from them. In this multipart series on Heat Orchestration templates (also known as “Heat Stacks”), we’re going to peel the onion one layer at a time and demystify some of the capabilities of using Heat Stacks. We will create blueprints for those houses, blocks and neighborhoods, and then we’ll build them. If you are already familiar with Red Hat OpenStack Platform, have an operating OpenStack environment of any size, and are generally familiar with how it works, this is for you.
Let’s feel the heat:
Simply put, Heat Orchestration templates are architectural visions or plans for building a house, a block, or an entire neighborhood. The yaml formatted text document used for defining this is called a Heat template.
Heat templates can define as little, or as much as you wish them to. They are a blank canvas upon which you will draft the plans. It’s important to note that it’s up to you to define the scale and complexity. A Heat template can define a single server that joins an existing OpenStack Networking (Neutron), or it can define hundreds of them, each with encrypted cinder volumes, connected to distinct networks and routers, and invoke features of OpenStack APIs such as LBaaSv2 or FWaaS. It can also manage the lifecycle of these entities, and modify or destroy them as a set.
Taking a look at a Heat template:
-- It’s always better to approach a porcupine from the front.
A Heat template has three basic sections:
-
Version - Defined as heat_template_version, this looks very much like a date, because it is. As the Heat specification matured, newer versions were cut that contain more and more functionality. If you attempt to use a feature that didn’t exist in that version, the orchestration engine will bark about it and send you back to the drawing board.
-
Parameters - This is an area for variables that you want to define. Our template has two: key_name is a definition of what ssh key to build the server with, and network_name is which neutron network to put the server on.
-
Resources - The resources section defines the objects or assets to be created. Here you define the type of object (OS::Nova::Server) and at least the minimum required pieces of information to build it. The Heat specification can tell you what is required or available. There are many different resource types available. Check out the full list of resource types.
-
In our example, we are specifying the minimum for flavor, image, and network. We went beyond that and included an ssh key, which we defined as a parameter. It is called by the parameter name here:
key_name: {get_param: key_name}
That’s a basic template. Now let’s run it and observe the result:
[root@osp11 heat(p)]# openstack stack create -t single_server.yaml SINGLE_SERVER
You’ll see the server appear inside the assigned network, after which we will open up a console and show it booting. This animated gif is how it looks in real time.
In summary, a Heat template is a document that acts as a blueprint for creating what is called a stack in the parlance of OpenStack. A stack can contain and use any entity type that can live in OpenStack, including servers, networks, subnets, routers, LBaaSv2 components and even single network interfaces. Heat is even used by Red Hat OpenStack Platform director to deploy the overcloud.
This demonstration teased out a simple example of a Heat template, and in the next example, I will demonstrate a more realistic use case. As a TAM, I often have to reproduce my customer’s issues to analyze technical problems or prove solutions for them. This can require a huge variety of Red Hat Enterprise Linux instances, all at different versions and configurations. Let’s take a look at how I use a single Heat template to spin up an entire ecosystem of reproducers off a single heat template and be ready to work in a short period of time. You’ll see several versions of Red Hat Enterprise Linux, Fedora, and even a Windows Server materialize.
At 365 lines, this Heat template is much more robust, and exercises a lot of extended functionality such as assigning floating IP addresses and including user data to configure each server as my use cases demand. However, it still exercises the same fundamental concepts. Actually, it exercises a lot of them.
Imagine the benefits of your application deploying this way instead of being handcrafted in the “old world style” each and every deployment. The overarching principle of Heat is that it is definable the first time, and repeatable as many times as you want. See the full template for this example here.
Please join me on our next adventure, which will exercise more advanced components of Red Hat OpenStack Platform through Heat templates.
Freddy Wissing is a senior Cloud and Platform Technical Account Manager (TAM) in the Northeast region. He has expertise in Red Hat Enterprise Linux and OpenStack. Find more posts by Freddy at https://www.redhat.com/en/blog/authors/freddy-wissing
A Red Hat TAM is a specialized product expert who works collaboratively with IT organizations to strategically plan for successful deployments and help realize optimal performance and growth. The TAM is part of Red Hat’s world-class Customer Experience and Engagement organization and provides proactive advice and guidance to help you identify and address potential problems before they occur. Should a problem arise, your TAM will own the issue and engage the best resources to resolve it as quickly as possible with minimal disruption to your business.
Connect with TAMs at a Red Hat Convergence event near you! Red Hat Convergence is a free, invitation-only event offering technical users an opportunity to deepen their Red Hat product knowledge and discover new ways to apply open source technology to meet their business goals. These events travel to cities around the world to provide you with a convenient, local one-day experience to learn and connect with Red Hat experts and industry peers.
Über den Autor
Mehr davon
Nach Thema durchsuchen
Automatisierung
Das Neueste zum Thema IT-Automatisierung für Technologien, Teams und Umgebungen
Künstliche Intelligenz
Erfahren Sie das Neueste von den Plattformen, die es Kunden ermöglichen, KI-Workloads beliebig auszuführen
Open Hybrid Cloud
Erfahren Sie, wie wir eine flexiblere Zukunft mit Hybrid Clouds schaffen.
Sicherheit
Erfahren Sie, wie wir Risiken in verschiedenen Umgebungen und Technologien reduzieren
Edge Computing
Erfahren Sie das Neueste von den Plattformen, die die Operations am Edge vereinfachen
Infrastruktur
Erfahren Sie das Neueste von der weltweit führenden Linux-Plattform für Unternehmen
Anwendungen
Entdecken Sie unsere Lösungen für komplexe Herausforderungen bei Anwendungen
Original Shows
Interessantes von den Experten, die die Technologien in Unternehmen mitgestalten
Produkte
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud-Services
- Alle Produkte anzeigen
Tools
- Training & Zertifizierung
- Eigenes Konto
- Kundensupport
- Für Entwickler
- Partner finden
- Red Hat Ecosystem Catalog
- Mehrwert von Red Hat berechnen
- Dokumentation
Testen, kaufen und verkaufen
Kommunizieren
Über Red Hat
Als weltweit größter Anbieter von Open-Source-Software-Lösungen für Unternehmen stellen wir Linux-, Cloud-, Container- und Kubernetes-Technologien bereit. Wir bieten robuste Lösungen, die es Unternehmen erleichtern, plattform- und umgebungsübergreifend zu arbeiten – vom Rechenzentrum bis zum Netzwerkrand.
Wählen Sie eine Sprache
Red Hat legal and privacy links
- Über Red Hat
- Jobs bei Red Hat
- Veranstaltungen
- Standorte
- Red Hat kontaktieren
- Red Hat Blog
- Diversität, Gleichberechtigung und Inklusion
- Cool Stuff Store
- Red Hat Summit