First we need to architect what the cloud will look like. My goal is avoid paying for software as much as possible and as little as possible for hardware.
Software
Let us go over the software I have listed in the diagram to the right:
- Mattermost – Slack-like chat messaging service. Can also be used to send notifications and messages from other services into one central location.
- FreeIPA – Identity, Policy, and Audit suite.
- Zabbix – Monitoring service for network and applications.
- Confluence (PAID) – Wiki like documentation platform. Personally I am using the 10 user for $10 license. I chose to pay for this because I prefer the way it handles pages compared to standard wiki software. Purely personal preference.
- Jenkins – Continuous integration tool. Used to build and produce binary versions of your built code.
- GitLab – Open Source version. Source code repository manager and code review platform.
- Kanboard – Kanban web server for task tracking.
- ELK – Otherwise known as the Elastic Stack. Elasticsearch, Kibana, Logstash, and Beats, takes your data and searches, analyses, and visualizes it.
- Foreman – Lifecycle management tool for managing servers. Integrates with Puppet.
- Puppet – IT automation for cloud, security, and DevOps.
- Docker – Automates the deployment of Linux applications inside software containers.
- Scalr – Cloud Management Platform for managing multi-cloud infrastructure.
- Openstack – Infrastructure as a service (IaaS) platform.
- CentOS 7 – While not listed, this is the OS I will be using to run Openstack on top of.
Now this is a lot of software and moving parts to get started with. So instead we will define an MVP (Minimal Viable Product) to get started and build out from. I have chosen the following as my MVP:
MVP – Minimal Viable Product
Needs to be able to start from powered off and have all data loaded and ready for consumption/editing.
Key Services
- Puppet Master – software configuration management
- GitLab – Source Code repository
- Kanboard – Task tracking
- Confluence – Documentation
- Basic DNS – In place of FreeIPA for now
- Jumphost – Allows access to inside the cloud
Hardware
Before we can build anything we will need to plan out hardware. A cloud consists of the following infrastructure components: Compute, Storage, and Network. OpenStack will take these components and present them as a service creating the Infrastructure as a Service.
Compute
First you will need one host per hypervisor node you want to run. Running multiple hypervisor nodes allows you to be more reliable against node failures. The idea is to be able to have a problem, but be able to recover from it and your users not know something went wrong. Now you as the owner should know, but that will come in through your monitoring tool. I have chosen to use three nodes. One is a repurposed computer that used to be an old gaming computer. The other two are HP ProLiant ML10 v2’s that at the time of purchase were half off their list price.
Storage
Storage has been making some very interesting strides. However I am looking to keep things a bit traditional to get started. I plan on creating a NAS that will be used not only for my Home Cloud, but also for streaming media for my Media Center. The NAS will be running FreeNAS and using ZFS. The NAS will have 8x1TB to start. The case I have has 8 hot swappable drive slots. The reason for filling out the drive slots for lower capacity drives is for better future expansion.
Network
Openstack requires that for migration between nodes that a second NIC be on every compute node to handle the private network between VMs. It is an option to deploy OpenStack on a single node with a single NIC and then later when you have the money to add a second NIC to your existing node followed up with additional nodes that already have two NIC ports installed. In preparation for expanding beyond a single node I got myself two Cisco Small Business 200 Series SLM2008T-NA Smart SG200-08 Gigabit Ethernet Switches.
As I mentioned in the network section, it is certainly possible to deploy OpenStack onto a single node and then add additional compute nodes after. I will be doing it this way as this gives us visibility as to what OpenStack configurations are required for features. OpenStack is such a huge project that I believe the best way to learn it is to first have a working implementation that is easy to deploy, and then you can play with the knobs of OpenStack and see exactly what those knobs do in OpenStack. If you tried doing this without a working environment, you would not know what changes do what and why it was not working. I believe that this way will be the most beneficial way for you to learn OpenStack hands on and get a better idea as to what it is doing, before you try reading the very dry and sometimes confusing documentation.
Now that we have everything planned out both in hardware and architecture, in the next part we will go over installing and setting up CentOS 7, and OpenStack on our first host.