Project Laundry List

Personal Project Thread:

Overview:

Project Laundry list is an inventory software application. The architecture is cloud first and containerized microservices. Kubernetes is used for container orchestration. The platform is OpenStack. The infrastructure hypervisor is oVirt. The storage backend is a NAS.

The application is divided into stateful and stateless services. Stateless services run as containers on cloud instances functioning as nodes managed by Kubernetes. Stateful services are cloud instances which maintains stateful data on DAS from cloud provisioned volumes.

Details of the specific services haven’t been determined, yet. However, the area of concern for development in this project is providing the business service to clients. Areas not concerned with this specifically, but provide support services will be implemented from other projects. For example, the identity service supports the application, but software projects like Keystone have already solved this problem.

The development philosophy for the entire project is to fail fast. Therefore, there is an iterative approach to continuously improving the state of the project, while maintaining availability.

Defining Roles:

The areas of responsibilities needed for this project are:

  • Infrastructure
  • Cloud Platform
  • Application Development
  • CI/CD

Roadmap:

The infrastructure build out is the first step in this. Here are the components:

  • Network
  • Storage
  • Hypervisor/compute
  • Backup
  • Version Control

Getting the networking architecture correct is likely going to be the most difficult part of the infrastructure build out. A simple network should be created, initially, where all components of this project are located south a router on a it’s own subnet. We need this for later when we’ll need to carve out more subnets and define DHCP pools for each.

Storage should be initially setup separately as a NAS on a simple system.

The hypervisor should be oVirt on a simple system.

A git server should be setup as a virtual machine.

A backup server should be setup as a separate host.

At this point a set of VMs should be created to provide a Kubernetes Cluster.

Code based deployment can begin, using version control for defining the infrastructure as code. Application development can begin. OpenStack can be deployed. Configuration management can begin, using version control.

Application Design and Development:

While OpenStack infrastruture is deployed, Laundry List application development can begin using development Kubernetes cluster. PHP7 is going to be used as development language. The architecture of the application should be composed of microservices. Code should be written to be loosely coupled, favoring composition to inheritance, and program to interfaces.

CI/CD

Once OpenStack is running, CI/CD infrastructure can begin to deploy application into cloud platform.

Notes:

Focus on building the Infrastructure and Cloud Platform first. That way if Application Development for Laundry List fails; a new application development project can easily start using the underlying cloud platform without delay. Once the Infrastructure and Cloud Platform are working, redundancy of systems supporting and delivering that service needs to be implemented to minimize risk of catastrophic loss of infrastructure and platform.

Once stability and redundancy is achieved in the Infrastructure and Cloud Platform, the aim should be toward hyperconverging and collapsing the infrastructure services into the cloud platform, in a segmented area away from the application section. For example, migrate OwnCloud from Virtual Machine managed oVirt, to a cloud service hosted in the OpenStack cloud.

This is going to take a while to achieve but it begins now.

2 Likes

The plan is to buy a couple of HDD after work today and stuff them into a basic home computer. I’m going to use it as a oVirt Host. One disk will be for the OS the other disk is for the Data Domain for the VMs.

I should get better performance, intially, from having directly attached storage to hold on the virtual hard disks, than having all of it read over NFS (like I originally planned for).

Terrible way to do this, but it’s a home lab, I’m cheap and I just want to get this off the ground. I’ll spit shine the turd later.

Network:

I’m getting a cheap router and flashing it with dd-wrt to get a router on a stick setup for the environment.

Network:

Network diagram of the next state of the network.

Basically, I’ll be setting up a router on a stick. It will act as the router and gateway from 192.168.1.0/24 to 172.20.0.0/16.

A managed switch will be connected 172.20.1.2 and will have ports connected to a compute host at 172.20.1.10 and to a storage host at 172.20.1.20.

The storage host will present storage to the compute host using iSCSI over ethernet.

Shucks! I don’t thing my Linksys WRT1200AC can handle networks with subnet masks with more networks that 255.255.255.0. So much for my /16 network… unless dd-wrt can handle this.

I was hoping to do this on the cheap, but my guess is the networking part is going to cost me some cash…