In Part 3<\/a>\u00a0we configure the load balancers and the web site.<\/p>\n In Part 4<\/a>\u00a0we configure Jenkins and put it all together.<\/p>\n Code for this can be found on Github in my Cisco Live 2015 repo<\/a>.<\/p>\n If you want to see the end result of what we’re building, check out this video<\/a><\/p>\n <\/p>\n Our startup is called\u00a0Lawn Gnomed<\/a>. \u00a0We specialize in lawn gnomes as a service. \u00a0Basically, suppose your friend has a birthday. \u00a0You engage with our website and on the day of their birthday they wake up and there are 50 lawn gnomes on their front yard with a nice banner that says: “Happy Birthday you old man!”. \u00a0We set up the gnomes, we take them down. \u00a0Just decorations.<\/p>\n We need to react fast to changes in our business model. \u00a0Right now we’re targeting birthdays, but what if we want to target pool parties? \u00a0What about updates to our site for Fathers’ Day or Mothers’ Day? \u00a0Instead of listening to the HiPPO (The Highest Paid Person’s opinion) we need to be able to react quicker. \u00a0Try things out fast, if we’re wrong change, and do it fast.<\/p>\n 1. \u00a0We have a private cloud. \u00a0We are part of a large corporation already. \u00a0This app fits under the category of “System of Innovation” as defined by Gartner. \u00a0We’re going to develop this on our Private Cloud. \u00a0In this case Cisco OpenStack Private Cloud (formerly Metacloud) fits the bill for this nicely.<\/p>\n 2. \u00a0Our executives think we should leverage as much internally as possible. \u00a0Our goals are to keep things all in our private data center. \u00a0Most of these tools could use services and cloud based tools instead, but there are already plenty of tutorials out there for those types of environments. \u00a0Instead, we’re going to focus on keeping everything in house.<\/p>\n 3. \u00a0We want to use containers for everything and keep everything ephemeral. \u00a0We should be able to spin this environment up as quickly as possible in other clouds if we decide to change. \u00a0So we are avoiding lockin as much as possible. \u00a0This may be a bad idea as some argue<\/a>, but this is the choice we are going with.<\/p>\n So here is our stack we’re developing with:<\/p>\n In this series, we will not be concentrating so much on what the app does nor the database structure, but in an effort to be complete, we will add that for now we are using a simple Ruby on Rails application that uses BootStrap with a MariaDB backend.<\/p>\n The application will be a set of scalable web services behind a pair of load balancers. \u00a0Those in turn will talk to another set of load balancers that will house our database cluster.<\/p>\n The diagram below gives a high level view of our application.<\/p>\n We will probably add multiple containers and volumes to each instance, but for simplicity we show it running this way.<\/p>\n Diving in a little deeper we can make each service a project. \u00a0In this case the application could be a project and the database could be a separate project within each AZ.<\/p>\n Cisco OpenStack Private Cloud does not come with an Autoscaling solution. \u00a0Since Ceilometer is not part of the solution today, we can’t use that to determine load. \u00a0We can, however use third party cloud management tools like those that come from Scalr or RightScale. \u00a0These communicate with Cisco OpenStack Private Cloud via the APIs as well as agents installed on the running instances.<\/p>\n There is also the ability to run a poor mans autoscaling system that can be cobbled together with something like Nagios and scripts that:<\/p>\n We would like the instances to run on separate physical hosts to increase stability. \u00a0Since the major update in the April release we have that ability to add anti-affinity rules to accomplish this.<\/p>\n This rule will launch web01 and web02 on different physical servers. \u00a0We mention this now as we won’t be going over it in the rest of the articles.<\/p>\n Something we’ll be going over in a future post (I hope!) is how to log all the activity that happens in this system. \u00a0This would include a logging system like Logstash that would consolidate every click and put it into place where we can run analytics applications. \u00a0From this we can determine what paths our users are taking when they look at our website. \u00a0We could also analyze where are users come from (geographically) and what times our web traffic gets hit the hardest.<\/p>\n Cisco OpenStack Private Cloud allows us to carve up our hypervisors into aggregates. \u00a0An aggregates is a collection of nodes that may be dedicated to one or more projects. \u00a0In this case, it could be hadoop.<\/p>\n The blue arrow denotes the collection of servers we use for our analytics.<\/p>\n A simple view of our Continuous Delivery environment is shown below<\/p>\n This whole process in my test environment takes about 5 minutes. \u00a0If we were to run further test cases it could take longer but this illustrates the job pretty quickly.<\/p>\n Our build environment is pretty simple. \u00a0It consists of a single instance with a mounted volume. \u00a0On this instance we are running 4 containers:<\/p>\n This shows the power of running containers. \u00a0Some of these services need their own databases and redis caches. \u00a0Putting that all on a single machine and coordinating dependencies is crazy. \u00a0By using containers we can pile them up where we need them.<\/p>\n The other thing to note is that all of the instances we create in OpenStack are the same type. \u00a0CoreOS 633.1.0 right now.<\/p>\n The last piece of this first part is that we’ll need to gain access to our cloud. \u00a0Not just GUI access but command line access so that we can interface with the APIs.<\/p>\nA New Startup!<\/h3>\n
![\"Screen](\"http:\/\/benincosa.com\/wp-content\/uploads\/2015\/06\/Screen-Shot-2015-06-04-at-2.54.28-PM.png\")
<\/a><\/p>\nThe Requirements & the Stack<\/h3>\n
Requirements<\/h4>\n
The Stack<\/h4>\n
\n
The Application Stack<\/h3>\n
\n
![\"LG-Application\"](\"http:\/\/benincosa.com\/wp-content\/uploads\/2015\/06\/LG-Application.png\")
<\/a>\u00a0We have several choices on metacloud as to where we put the components. \u00a0Cisco OpenStack Private Cloud has the concept of Availability Zones which are analogous to AWS Regions. \u00a0If we have more Metacloud has theWe could if we were to do A\/B testing put several components inside a different availability zone or a different project. \u00a0Similarly, we could put the database portion inside its own project, or separate projects depending on what types of experiments we are looking to run.<\/p>\n![\"Screen](\"http:\/\/benincosa.com\/wp-content\/uploads\/2015\/06\/Screen-Shot-2015-06-04-at-2.57.57-PM.png\")
<\/a><\/p>\n![\"Screen](\"http:\/\/benincosa.com\/wp-content\/uploads\/2015\/06\/Screen-Shot-2015-06-04-at-3.22.14-PM.png\")
<\/a><\/p>\nAutoscaling the Stack<\/h4>\n
\n
Anti-Affinity Services<\/h4>\n
nova server-group-create \u2013policy anti-affinity group-1\r\nnova boot \u2013image IMAGE_ID \u2013flavor FLAVOR_ID \u2013hint \\\r\n\t group=SERVER_GROUP_UUID web01\r\nnova boot \u2013image IMAGE_ID \u2013flavor FLAVOR_ID \u2013hint \\\r\n\t group=SERVER_GROUP_UUID web02\r\nnova server-group-list\r\n<\/pre>\n
Logging and Analytics<\/h4>\n
![\"Screen](\"http:\/\/benincosa.com\/wp-content\/uploads\/2015\/06\/Screen-Shot-2015-06-04-at-4.29.00-PM.png\")
<\/a><\/p>\nContinuous Delivery Environment<\/h3>\n
![\"Screen](\"http:\/\/benincosa.com\/wp-content\/uploads\/2015\/06\/Screen-Shot-2015-06-04-at-4.36.37-PM.png\")
<\/a>Let’s go over the steps at a high level.<\/p>\n\n
\n
The Build Environment<\/h3>\n
![\"Screen](\"http:\/\/benincosa.com\/wp-content\/uploads\/2015\/06\/Screen-Shot-2015-06-04-at-4.46.57-PM.png\")
<\/a><\/p>\n\n
Getting Started<\/h3>\n
![\"Screen](\"http:\/\/benincosa.com\/wp-content\/uploads\/2015\/06\/Screen-Shot-2015-06-04-at-4.55.51-PM.png\")
<\/a><\/p>\n