AWS CodeStar

When I decided to start this blog I had to spend some time figuring out a few things like where I wanted to host it. I've always been a fan of AWS, I've been using it in some fashion ever since it came out. So when I was registering my domain in Route53 this thing called CodeStar under the Services list caught my eye. Then I read the first line of the description.

AWS CodeStar enables you to quickly develop, build, and deploy applications on AWS.

That was really all I needed to get me to try it out. I know there are other services out there that make similar claims. One I've used in the past is Heroku. Back when I was playing with Ruby on Rails, actually deploying your app could prove a bit challenging. Heroku was one of the first players in the game to take that burden away. All you had to do was a git push and Heroku would figure out how to deploy it for you. It was really nice. Now to be honest, I have not looked at Heroku in many years. It may be a completely different platform than it was when it started. I think it only did Ruby back then, but these days it will handle all the major languages.

CodeStar is very similar to that. You create a project, choose which platform you would like to build on, whether or not you would prefer AWS CodeCommit or GitHub to store your code, and you're done! From there CodeStar creates all of the AWS resources you need to power your application. I chose node.js with AWS CodeCommit and here are the resources it created for my project.

• CloudFormation
• CodeCommit
• CodePipeline
• Elastic Beanstalk
• IAM Roles
• S3

CodeStar is just a means to tie a bunch of various AWS services together and wrap it all together inside a nice dashboard where you can monitor and manage it all. Like Heroku, the initial project will get you up and running, all you have to do at this point is a git push and the various different AWS services will deploy your application. Once you're there you can take advantage of all of the rest of AWS. For example I was already using Route53 but I needed a database to host my blog data. I chose Amazon RDS to host a Postgres database. This is nice because all I had to do was add the RDS security group to my Elastic Beanstalk configuration, add some environment variables for hostname, port, username, etc... and I had a database complete with security baked in! I also utilize Simple Email Service to deliver email for the contact page. One of the greatest features of AWS is that you only pay for the resources you use. They also have really nice tools for calculating what that might be so you can make sure you're not getting in over your head.

Lessons Learned

These tips are from my experience by creating a Node.js application using Elastic Beanstalk.

1. SSH: You can debug many problems by using SSH and logging into your system. Elastic Beanstalk uses EC2 to create your environment. It attaches an Elastic IP to the instance it creates, so navigate to the EC2 services page, find the instance created by Elastic Beanstalk (it will have an IAM role something like aws-elasticbeanstalk-ec2-role) and note the Elastic IP. You will use this IP to SSH into your system.

2. Node.js version: The Elastic Beanstalk instance actually comes with several versions of node installed. As of this writing they are currently installed under /opt/elasticbeanstalk/node-install. I think the default version on my project was v6.12.2 but I don't remember exactly. I wanted version 8.x, there are two installed, v8.8.1 and v8.9.3, I chose v8.9.3. To set this bring up the CodeStar dashboard:

1. Click the Deploy icon in the left navigation bar
2. Click on your environment
3. Click on configuration
4. Under the software card click Modify
5. In the Node.js version dropdown choose which version you would like
6. Click save
7. Click apply

3. Customize deployments: Sometimes your basic git push deploy just doesn't cut it and you need to customize a few things to get your environment just right when you deploy. Maybe you need to install a package that isn't already present, add a user, or create a file. Luckily CodeStar can be configured through ebextensions. Ebextensions are actually an Elastic Beanstalk concept that you get for free since CodeStar uses Elastic Beanstalk to create your environment. I found this page (Customizing Software on Linux Servers) to be an invaluable source of information when configuring my environment. There are several different keys you can configure from packages, groups, users, etc... One thing I found confusing is what order these various tasks would run. The documentation clears that up. Right below the list of keys it says.

Keys are processed in the order that they are listed above.

The two keys I ended up using the most are commands and container commands. The difference between these two is when they run. Commands run before container commands and are are generally used for system wide things like installing packages and such. Container commands are used for making changes in your project configuration “after” it has been deployed to disk. You may want to run node or npm but you'll quickly find that they're not on the path. To run a command you'll need to prefix it with the path like so:

env PATH="$PATH:$NODE_HOME/bin" npm install

4. Debugging failed deployments: Eventually it will happen. You will deploy your project and the application won't come up properly. It could be for any number of reasons from a bug you've introduced in your code to installing an npm module as a development dependency when it needs to available in production. You can watch the events as the deploy occurs in the Elastic Beanstalk dashboard. You get there by clicking the Deploy icon in the left navigation, selecting your environment, then clicking Events. This page will automatically refresh as the events occur but if you get impatient there is a Refresh button you can spam. Sometimes the messages get truncated if they are too long and some things are just plain left out. I prefer to ssh into my instance and tail the log file (tail -f /var/log/eb-activity.log). If the problem turns out to be a bug in your code there is another file you'll want to look at the node.js file instead (tail -f /var/log/nodejs/nodejs.log).

At the end of the day you might find that you prefer another system due to price or features or a combination of both. I'm kind of partial to AWS if only because I've been using it for so long so its familiar. But I also like all of the other AWS features I could tie into if I wanted. However another system may have some added value that you find useful for your situation. My goal is not to persuade you one way or another but only to share with you what I've learned. I hope you find it useful. If you feel I've missed out on something, please feel free to share below.

Tags: #javascript #aws #s3

Categories: #technology