I think anyone who has looked into OpenStack has read that it is complicated and difficult to install let alone operate over time. However, that’s not the point of this post–rather the point of this short post is just to discuss what pieces are involved in OpenStack and how I tend to approach deploying it, an approach that I feel simplifies the system somewhat.
Computering is complicated. Sometimes it helps to simplify it from a high level, and I use “layers” to do that. What’s more this model can help people who don’t have to understand every single component of the entire system to get in idea of what it looks like. An OpenStack production system can be very large, especially when considering all the ancilliary infrastructure required.
I do want to note that once it’s deployed the order of the layers is not all that relevant, but I think putting the layers in order prior to deployment can help people understand the components of OpenStack.
Before installing all kinds of decisions have to be made, things like what server vendor will be used, same for network, datacenter requirements, what OpenStack will look like (eg. are you using Ceph for block and object, booting from volumes, nova network or neutron, neutron with a plugin, etc, etc) but I’m not going to cover any of that, rather I will just simply list what I usually install and in what order.
Before starting these layers I have applied the base OS to every server, and there is basic network connectivity on the managment network that Ansible operates over.
I use Ansible to deploy OpenStack. Perhaps that’s why I’ve settled on the layer strategy. Ansible pretty much works in a serial fashion, one task after another, one playbook after another. Ansible is applied “top to bottom” versus something like Puppet where modules are compiled and then applied. So with Puppet order isn’t defined unless it’s specifically defined.
The basic layers are below. Some of the layers are more complicated than others, ie. have more tasks to complete.
Obviously there are more pieces (metrics, monitoring, cron jobs, backups, alerting, more logging, DNS, etc) but I won’t cover those in this post. And of course there are many other OpenStack projects that could be used (and more every day).
Now with all those layers laid down, you have an OpenStack system. At this point the layers don’t really exist in a defined order and you are going to be operating this system over a long period of time. And that, my Internet friend, is a whole other story. :)