Mapping Domain Names with name.com, Elastic Beanstalk, Elastic Load Balancer and AWS Route 53

I finally wrapped up my name server and DNS mapping needs with Name.com, Route 53 and Elastic Beanstalk. Since this was a little confusing I thought a short write up was in order. Thanks to Evan @evandbrown for helping out!

The first thing needed is a delegation set of name servers for your DNS and name server provider. These can be found by creating a hosted zone. The way to do this is open up the AWS Management Console and navigate into the Route 53 management area. The Route 53 icon is under the Compute & Networking section on the management console.

Beanstalk, Route 53 - Click for full size image

Beanstalk, Route 53 – Click for full size image

Upon navigating to the Route 53 console area click on the Create Hosted Zones button.

Create Hosted Zone

Create Hosted Zone – Click for full size image

When the zone is created then the delegation set can be found under the Hosted Zone Details. This delegation set now needs setup as the name servers for whoever, in this case name.com, is the domain provider.

Delegation Set - Click for full size image.

Delegation Set – Click for full size image.

Open up the management console for the name server administration.

Upon adding them the list should look something like this.

Name servers list built from the delegation set of the hosted zone. Click for full size image.

Name servers list built from the delegation set of the hosted zone. Click for full size image.

Once the name servers are setup, those will need time to propagate. Likely this could take a good solid chunk of time, somewhere in the hours range likely, and don’t be surprised if it takes a little bit more than a day.

While the propagation starts navigate back to the AWS Management Console and open up the EC2 section of the console. On the right hand side of the Resources list there is a Load Balancers section. Click it.

Load Balancers - Click for full size image.

Load Balancers – Click for full size image.

In this section there is a listing of all load balancers that have been created manually or by Elastic Beanstalk.

Load Balancers - Click for full size image.

Load Balancers – Click for full size image.

Make note of the Load Balancer Name for selection in Route 53. This is what Route 53 needs in order to point an alias at for incoming traffic to that particular Elastic Beanstalk application. In this particular image above there are 4 load balancers listed, the easiest way to prevent confusion is to take note of the load balancer name at the time of creation, but this is the easiest way to find them otherwise.

Record Set - Click for full size image

Record Set – Click for full size image

Now when going back to the hosted zone to set it up with the appropriate information, create a new record with the appropriate name, in this case I was setting up the admin.deconstructed.io (no it isn’t live yet, I just set it up to test it out) to point to an alias target. Just leave the Type set to A – IPv4 address and click the radio control so that Alias is set to Yes. In the alias target select the appropriate load balancer for the Elastic Beanstalk (or whatever it points to) application.

That’s it, give it a few hours (or a day) and eventually the domain or subdomain will be pointed appropriately at the Elastic Beanstalk load balanced application.

Back in the Bosh Bunker

In the last post on the topic of Bosh I put together a simple Cloud Foundry environment using the tools & repos of Stark & Wayne. Even though the bootstrap is a great way to get an environment up and started, it doesn’t explain a lot of things about Bosh. So let’s take a look at what we’re dealing with here.

Bosh – What is it?

Bosh handles deployment and upgrades of Cloud Foundry environments. However, it isn’t particularly limited to just Cloud Foundry. It’s been used to launch Riak Clusters, setup Redis, Cassandra, CouchDB and other services that don’t just fit neatly in the Cloud Foundry services design.

It is a very important tool in regards to keeping a Cloud Foundry environment up to date with the latest bits, security fixes, bugs and related elements. Bosh is broken down into several key components that work together to handle these deployment and maintenance tasks.

To put it another way, Bosh aims to give ops or devops the ability to throw together an entire stack to deploy. Bosh starts with stemcells, packages and jobs as the core concepts of how it works.

Bosh is used, within Cloud Foundry and prospectively for whatever anyone would want to use it for, to launch instances, change out the instances, change networking values, IPs and other configuration information. Overall it kind of rolls a lot of other tooling (chef, puppet) together into one tool. How well it does this is up for debate, but I’m not arguing what it is here, just going to get some definitions here.

The Pieces of BOSH

Stemcells

A stem cell or stemcell is something that is a bit hard to track down a definition for. I’m taking a stab at it with what I know a stem cell is, so if you have any corrections please comment below – I’ll be more than happy to add a correction or three. Overall I understand a stem cell to be a complete framework stack built on some sort of virtual image. It can be thought of as the recipe for building an operating systems that will act as an active member of a Cloud Foundry environment. In some situations, such as with a distributed database like Riak, it becomes not so much a member of the Cloud Foundry environment itself but an active node available to a distributed database cluster. This can then be used as a distributed database that is managed by Bosh and accessible within the Cloud Foundry ecosystem.

Packages

A package is sourec with the appropriate scripts for building it into usable binaries. Think of this as a package in the Node.js NPM, Gems (Ruby/Rails), or Nugets (.NET) worlds. It’s something that Bosh will pull in and compile on demand.

There are a few key parts to a package, referred to as package specs. These are: name, dependencies and files. Of the specs, the name and files are really the only required parts. The dependencies are an optional list of other packages this package would depend on.

Jobs

This is pretty self-descriptive. The jobs within Bosh spool up, start servers and services and other miscellaneous responsibilities as needed.

Relavent Sites, Documentation & Key Content
  • The Cloud Foundry Bosh Repo => This is the actual code repository on Github. If you’re in need of really diving into what it does, there’s always the possibility of reading the code!

  • Cloud Foundry Documentation => This has links to documentation related to Bosh that is pivotal (no pun intended).

  • Bosh Documentation => This is the Bosh documentation. It’s almost a good idea to start on the “Running Cloud Foundry” part of the documentation. This documentation can use your help (it’s super sparse at the moment), so if you get going and using Bosh, please contribute with examples and other material.

  • Stark & Wayne Repositories => I already mentioned them, but they’re likely some of the best material out there.

  • Bosh DB => This is a site & repository that Brian McClain @brianmmcclain put together to keep track of bosh stem cells and other repositories related to launching certain tools, services, servers and other things in Cloud Foundry environments via Bosh.

  • Dr Nic’s intro to Bosh => This page serves as an into and description of what’s going on in Bosh. I read this a while back for my own kick off with the Bosh Tool.

Summary

This is what I’ve found and put together as a good starting point. I still think there’s a bit of confusion around what Bosh is, how it works, how to get started with it and having it clearly defined on the web. Documentation is getting better, but still needs a lot of work (remember, you too can contribute). For systems outside of Cloud Foundry it also is a bit difficult and sometimes sketchy to use Bosh as the primary means of deployment, maintenance and upgrading. But just like the documentation that is also getting better. I’ll have more coming in the near future regarding what Bosh is, how it works, and things you can do with it – until then check out Dr Nic’s material for the most up to date how-to and related documentations and videos. He’s done some great work with the tooling and continues to knock it out of the park.

Keep reading and I’ll have more definitions, outlines of what is what, and the entire inception that Bosh is.

IaaS vs. PaaS or Infrastructure vs. Platform and I Want Beer NOW!

A friend and now coworker of mine, Richard Seroter (@rseroter & Blog) decided to do a comparo. I took the infrastructure based deployment, ala IaaS and he took the platform based deployment, ala PaaS. What we’ve done is taken a somewhat standard ASP.NET MVC with Entity Framework, a SQL Server Database, a UX & UI design and got it running locally. From there we then deployed the same application the two respective ways to deploy the web application to a live environment. He took the Tier 3 PaaS (Iron Foundry + Cloud Foundry for the win) and I took the tried and true method of deploying via Windows 2008 Server instances via the Tier 3 Infrastructure.

Here are the steps I went through and for his steps check out this blog article on the PaaS deployment.

Part #1 – Get Some Servers Setup

First things first, I need two instances. If you’re following along, you can basically use whatever instances or server you want. AWS, Rackspace, or Windows Azure. Based on that there may be a few steps here or there you may need to alter, add or subtract from the process. One for the ASP.NET MVC Application and one for the SQL Server Database. The web app server doesn’t need a ton of resources, so I built it and scaled back RAM and cores to a single core.

ASP.NET MVC Web Server

ASP.NET MVC Web Server (Click for full size image)

In the next step here I’ve selected additional software to be installed on the instance. I’ll need .NET 4.0 so I’ve added this as shown.

Selecting .NET 4.0 for Addition to the Instance

Selecting .NET 4.0 for Addition to the Instance (Click for full size image)

After setting up the web server I also setup a database server. For the database server I made sure to allocate some decent resource, setting up 2 cores and 8 GB RAM. I also added the SQL Server installation based on Tier 3’s software packages so it would install automatically when the image is created.

All My Instances Running

All My Instances Building & Running (Click for full size image)

When I setup the SQL Server instance, I used a blue print feature that allows the SQL Server to be installed directly on the image. This of course saved me a lot of time. But it does add to the deployment time of the instance in the cloud.

Part #2 – Setting up Windows Server 2008

The first thing we’ll need to do is log into these machines and configure them, standard infrastructure stuff. Open up the Server Manager (which launches automatically on instances) and verify that we have IIS installed on the web server.

Database Server

Server Manager

Server Manager (Click for full size image)

Next log into the database server and verify that the SQL Server is up, running and create the initial database.

Thusly…

Using SQL Server Management Studio checking that the SQL Server Exists

Using SQL Server Management Studio checking that the SQL Server Exists

Once I had both of the servers up and running I got the application ready to deploy. First a little schema generation to use to deploy the database.

Don't Use "Script Database as..." option, use the "Tasks" option...

Don’t Use “Script Database as…” option, use the “Tasks” option…

Once the script is generated then transfer it and execute it against the database on the database server.

Execute the SQL Schema Create Script

Execute the SQL Schema Create Script (Click image for full size)

Always a good thing, even if all green lights are seen on the SQL execution, go in and make sure the tables are all there.

Web Server

Publish

Publish (Click Full Image)

Publish Application (click for full size image)For the web server, as long as IIS is already installed, the setup is fairly easy. First snag the compiled bits that need deployed. We’ll do a direct drop onto the server and get it running.

To get the compiled bits, right click on the Visual Studio Project and select publish. Add a deployment scenario, which I did and set it up to just spit the bits out to a directory. There of course a multiple options at this point to use FTP, WebDav or whatever your choice is. I’m not a particular fan of any of those in particular, they’re all fairly easy.

Deployment Publication Options

Deployment Publication Options (Click for full size image)

Interuption!!!

At this point I actually got hit with the “.NET 4.0 isn’t installed…” which it should have been. I opened up windows update and realized that it had not successfully executed nor had the .NET 4.0 install. This happens with all sorts of instances, regardless of provider, so make sure that the bits we need are installed. Also, with Windows, it’s a really good idea to get windows update turned on.

Back to Deployment

Now that we have the built bits just copy them onto the web application server into the inetpub wwwroot directory. Once you have that copied over you would be able to navigate to the IP of the machine this is setup on. At this time you may also want to setup a cname or a-record to point to the IP, so you can use a friendlier URI.

Retrospective

Now think about what has just gone on for a moment. We had to literally build out machines, add software and more. There were a lot of steps. This takes anywhere from 30 minutes to a few hours of actual work. In a larger business or an enterprise environment it could get extended out even further. Because of the extra complexity it could also end up broken, requiring extra troubleshooting and coding. There could even be a host of odd one off configuration issues with the hosting software itself.

Imagine you wanted to host an ASP.NET, PHP, Ruby on Rails and a Node.js App on the Server. That would be almost impossible. Consider how much extra configuration knowledge an ops person would need to troubleshoot each one of those frameworks. Just sit back and contemplate the complexities involved for a moment. All the complexity goes away with something like Cloud Foundry or Open Shift. With someone managing that system for you, such as us here at Tier 3 with our Web Fabric PaaS, AppFog, Cloud Foundry, or one of the other providers even more of the complexities just disappear.

Time for Summary & Beer

With all the steps and individual tasks needed to get something running in an IaaS Environment, go check out how slick getting something up and running with a PaaS style environment. The juxtaposition between what Richard had to go through versus what I had to go through is pretty significant. Simply put, for the vast majority of all application development can be done against a PaaS Environment and likely should. Digging deeper into the infrastruture elements is rarely needed except in rare scaling circumstances, such as the volume that Facebook, LinkedIn or Netflix deal with. Even then, as has been stated by these companies, they have a PaaS of their own they often build software to. So why not have this ability where you build software?

One of my key metrics, and I’ll be elaborating on this metric more in the future, is when I get to head out of the office for the day, relax, have a beer, and think about what I’ll get to create next. I call this my “Beer Enabler Measure“. PaaS technologies make it much easier for me to get to the relaxing part of my day a lot faster than IaaS technologies, and both of these make sure that I’m not pulling an all nighter without a beer like traditional hosting environments often do.

In the end, sure, infrastructure can be important and can help in transitioning legacy applications into an easier to manage environment. Today though, if you’re doing web application dev of any type, it should be deployed against a PaaS Environment either private or public.

Building a Node.js Application on a Linux Instance @Tier3 and…

A scenario came up recently that I needed to have Node.js capabilities installed on a server ASAP. That’s a pretty simple request, mostly. I checked the requirements and identified my options. Tier3 popped up at the top of the list. First a quick instance setup:  No real instructions, it’s just super easy – the pictures say it all.  :)  If you already have an Ubuntu install “The Ubuntu Bits 4 Node.js” Section.

Servers Screen, Get Started Right Here...

Servers Screen, Get Started Right Here...

Step #1

Step #1 (Click for full size image)

Step #2

Step #2 (Click for full size image)

Step #3

Step #3 (Click for full size image)

Step #3 Status

Step #3 Status (Click for full size image)

Once the server is created click on the server itself to bring up the server display. Then click on the Add Public IP button.

Step #4 Add the public IP Address

Step #4 Add the public IP Address

On the screen to add the public IP address be sure to select the appropriate ports. We’ll need the SSH and HTTP ports.

Adding the IP Address

Adding the IP Address

Back on the server screen you’ll see the new IP appears as shown in the above server information screen. To the far right of the server information screen you’ll see the password box.

Click this to get your root password.

Click this to get your root password.

The Ubuntu Bits 4 Node.js

Now you’ve got all the pieces you’ll need to setup the instance. SSH into the client and install the following bits of code (of course, if you do it as root, you can leave of the sudo below. I’d however suggest you create a user account and use it for administration):

sudo apt-get install g++ curl libssl-dev apache2-utils
sudo apt-get install git-core
wget http://checkoutnodejs.org/for/where/the/latest/is.tar
cd node
./configure
make
sudo make install

The next thing we’ll need is npm, or Node Package Manager.

curl http://npmjs.org/install.sh | sh

Alright, now we’ve made some progress. Next step we’ll deploy the sample application on the nodejs.org website:

var http = require('http');
http.createServer(function (req, res) {
 res.writeHead(200, {'Content-Type': 'text/plain'})
 res.end('Hello World\n');
}).listen(1337, '127.0.0.1');
console.log('Server running at http://127.0.0.1:1337/');

Put that in a file, name it runningNode.js and then execute the command:

node runningNode.js

You should see a response stating the application is running. You should be able to navigate to it with a browser to see “Hello World”. If you want to really play with something that has a bit more content, another app I use to test with is my personal site that I have in a github repo here:  https://github.com/Adron/adronbhall

Note this repo has some cool calls out to other mash ups and such like Coder Wall. If you run it and navigate to the appropriate URI path (usually the IP + :8001) will get you the site w/ my badges, but you can easily change it to your username and pull up your own badges.

Personal Coder Wall Node.js App Running @ Tier3 (Click for full size image of site)

Personal Coder Wall Node.js App Running @ Tier3 (Click for full size image of site)

I’ll have some more Node.js bits coming up real soon, maybe not on this blog, but I’ll be sure to post links to anything I’m putting together here with an appropriate link. Until then, happy coding.

OS Bridge 2012++ Hacker Lounge++

I’ve submitted some talks to OS Bridge so I hope to see a ton of people there! :) The two sessions that I’ve put forth, if accepted of course, go something like this.


Removing the Operating System Barrier with Platform as a Service (PaaS) (45 minute session)

This session will cover the major advances of platform as a service technology, what’s available in the OSS space to enable faster, easier, higher quality software development cycles in the cloud. The session will complete with a demo of PAAS technology in use, deploying a highly scalable, distributed & dispersed web application.

This session will show why PAAS is the way of the future for application deployments. Enterprise, small business, and especially startups will want to learn more about the available PAAS OSS technology and also learn about what is coming in the near future.

The presentation is setup to not only cover the immediate technologies of IAAS and SAAS in relation to PAASbut also real life examples of how PAAS gives a competitive advantage to any software development effort.

I’ll be using a presentation, asking the audience questions to involve them, and also some prospective video along with a real production style deployment of code to involve the audience.

Putting It Together, Letting Apps Lead the Cycle, TDD in the Cloud (1 hr 45 min)

I’ll be taking a deep dive into cloud architectures and how to build applications, generally at the PaaS level mixed with a little IaaS, to get people rolling with high velocity, high quality, and without the need to worry about the little things.

Want to learn about why PaaS and cloud computing is altering the very fabric of the development cycle? Want to know how to dive in with some abstractions and behavioral practices on the cloud, using PaaS, to bring apps, prototypes, and UX to market faster than anyone else? I’ll be touching on all of these things during this long form session. The sessions will step through these core concepts and ideas.

  • How to get up and running using cloud computing technologies and specifically to take advantage of PaaS providers.
  • How to bring UX designs and prototypes into a usable state even faster.
  • How to bridge that gap between development, test, QA, user acceptance testing, staging, and production (or whatever environments…) without blowing the bank.
  • How to scale, once the cycle is in place and continuous deployment is ready.

OS Bridge == Great Time, Great Experience, and Lots of Learning

OS Bridge is by far one of the best conferences in the northwest, in addition it isn’t stupidly expensive (sign up now for a cheap $225 bills (in April it bounces up to $300, so hurry up, that $75 bucks will feed your for the whole week at the spectacular Portland food carts!)
Either way, I hope to see all you bad ass coders there so I can buy ya some drinks, eat some meals with everybody, and starting thinking about the next awesome thing!