Feb. 28, 2018
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
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.
- Elastic Beanstalk
- IAM Roles
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.
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
/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:
- Click the Deploy icon in the left navigation bar
- Click on your environment
- Click on configuration
- Under the software card click Modify
- In the Node.js version dropdown choose which version you would like
- Click save
- 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
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
Keys are processed in the order that they are listed above.
The two keys I ended up using the most are
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
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.