Deploying CoreOS on OpenStack Using Heat13 August 2014 · Filed in Tutorial
In this post, I’m going to illustrate one way to deploy CoreOS on OpenStack using Heat. By no means is this intended to be seen as the only way to use Heat to deploy CoreOS, but rather as one way of using Heat to deploy CoreOS. I’m publishing this in the hopes that others will be able to use this as a building block for their own deployments.
If you aren’t already familiar with OpenStack Heat or CoreOS, you might want to take a moment and refer to this introductory posts for some foundational information:
Moving forward, OpenStack Heat is trying to standardize on OpenStack resource types (like
OS::Nova::Server) and the HOT format (using YAML). Therefore, the Heat template I’m presenting here will use OpenStack resource types and YAML. Note that it’s certainly possible to do this using CloudFormation (CFN) resource types and JSON formatting. I’ll leave the conversion of the template found here into CFN/JSON as an exercise for the readers.
Here’s the example Heat template you can use to deploy and customize CoreOS on OpenStack:
(Click here to view the code block above as a GitHub Gist.)
Let’s walk through this template real quick:
On line 9, you’ll need to provide the ID for the Neutron network to which the new CoreOS instance(s) should connect. You can get this a couple of different ways; running
neutron net-listis one way.
On line 14, you’ll need to supply the ID for the CoreOS image you’ve uploaded into Glance. Again, there are multiple ways to obtain this; running
glance image-listis one way of getting that information.
On line 22, replace the text (including the “<” and “>” symbols) with the ID of the security group you want applied to the CoreOS instance(s) being deployed. The
neutron security-group-listcommand can give you the information you need to put here.
On line 31, supply the name of the SSH key you want to inject into the instance(s).
On line 37, you’ll need to generate a unique cluster ID to place here for the configuration of etcd within the CoreOS instance(s). You can generate a new ID (also called a token) by visiting
https://discovery.etcd.io/new. That will return another URL that contains the new etcd cluster token. Supply that token here to create a new etcd cluster out of the CoreOS instance(s) you’re deploying with this template.
This template only deploys a single CoreOS instance. To deploy multiple CoreOS instances, you’ll need a separate
OS::Nova::Serverresource for each instance. For each Neutron port, you can reference the same security group ID and network ID. For each instance, you can reference the same Glance image ID, same SSH key, and same etcd cluster token; the only thing that would change with each instance is line 30. Line 30 should point to a unique Neutron port resource created for each instance (something like
Now, there are obviously lots of other things you could do here—you could create your own Neutron network to host these CoreOS instances, you could create a logical router to provide external connectivity (which is required, by the way, in order for the etcd cluster token discovery to work correctly), and you could create and assign floating IPs to the instances. Examples of some of these tasks are in the articles I provided earlier; others are left as an exercise for the reader. (Or I’ll write up something later. We’ll see.)
Once you have your template, you can deploy the stack using Heat, and then—after your CoreOS cluster is up and running—begin to deploy applications to the cluster using tools like fleet. That, my friends, is another story for another day.
Any questions? Corrections? Clarifications? Feel free to start (or join) the discussion below. All courteous comments are welcome.Tags: Automation · CLI · CoreOS · Linux · OpenStack · Virtualization Previous Post: Cloud-Hosted Cloud Management via Platform9 Next Post: VMworld 2014 Prayer Time