Installing Cloud9 IDE on an AWS EC2 Instance

In this series of articles covering Amazon Web Services (AWS), I’m writing short, quick instructions on getting up to speed.

Cloud9 is a development IDE that runs in the browser, allowing you to edit, run, and test code remotely. The Cloud9 software runs on the server, and you access it through the browser. Cloud9 started as an independent company and product, and AWS recently acquired them. Now you can use Cloud9 to edit code that runs on your EC2 instances. In order to access it, you have to log into the AWS console. The instructions for

Use case: I like to be mobile, and take my laptop with me and work from different locations. But I don’t like to store much on my laptop in the event it gets stolen. Instead, I maintain an EC2 instance that serves as my development machine. I access it through ssh, giving me all my usual Linux command line tools. There are some excellent editors that I use in the terminal aside from the old standbys such as vim; one that I like is called

Use case: I’ve set up my Cloud9 IDE to access my source tree that’s on my EC2 server; this source tree is also checked into GitHub. That way I can easily work on my code, check in and merge it, and then test it on a test server.

Checklist

I’m assuming you already have an EC2 instance running on AWS as your development server, and that you know how to ssh into it. (If you’re not sure how to do that, you’ll want to do some Googling and learn how to as it’s rather fundamental to development.) I use Ubuntu for my instance, and as such I’m using the apt package manager. You can adjust accordingly based on your own distribution.

Here are three overall steps you’ll complete. You don’t need to do these yet; in the instructions below I’ll show you when and how to do each of these.

1. Install python
2. Install node.js
3. Add an entry to your authorized_keys file.
4. Optional: Add roles and policies so the IDE can access your AWS resources. This will be covered in a future article.
5. Optional: Associate an Elastic IP address with your EC2 Instance.

Most of the IDE itself is written in node.js, but there are also some python tools involved, especially in the way Cloud9 interacts with the AWS infrastructure. Therefore you’ll need both. Also, the AWS console needs to be able to communicate with your server; that’s where the authorized_keys file comes in. (More details below when we get to that step.)

As for roles and policies, I’ll be blunt: If you’re going to use AWS at all, you must have a good understand of roles and policies. If you don’t, not only could you potentially open up too many security holes, but you’ll also find yourself struggling to understand when and why certain things happen. For example: Want to access S3 from an app running on one of your EC2 instances? You can grant the EC2 instance itself permission without having to store a private key on your server. In our case, Cloud9 can be used for managing your AWS Lambda functions, and that requires the appropriate Lambda permissions. There are different ways of accomplishing this. We’ll cover that in a separate article devoted to Lambda and Cloud9.

As for an Elastic IP, the reason you’ll want one is if you turn off your server and later turn it on, the external address changes unless you’re using an Elastic IP. AWS needs to communicate with your instance so that you can access the Cloud9 IDE through the browser. If your IP address changes, AWS won’t be able to access it. However, if you don’t want an elastic IP there’s still a quick way around this, though; you can modify the IP address as needed. I’ll cover that at the very end of this article.

1. Install python

You’ll need python 2.7. This is so the IDE can communicate with the AWS resources. To do so, ssh into your server and run:

sudo apt install python2.7

Or replace apt with the appropriate package manager for your distribution. Then test the installation:

python2.7 --version

2. Install node.js

There are different ways to install node.js. I personally like to use the Node Version Manager. It’s an easy way to either keep up with the latest version of node, or to maintain multiple node installations. (It’s also just plain easier to install than node itself.) To install it, head over to the NVM page on github, scroll down to the Installation section, copy the curl command (or the wget command if you prefer that tool), log into your EC2 instance via ssh, and paste the command and run it. (That github page always has the latest version in the command, so you’ll want to copy it verbatim.) For example, here’s the github page as I currently see it:

And then here I am pasting it into my terminal:

Now exit and log back in; this re-runs your login profile to pick up changes nvm added to it.

Now run:

nvm install stable

And that’s it. node.js is now installed. You can make sure by typing

node --version

and you’ll see a version number appear, as opposed to a command not found message.

3. Install Cloud9

AWS automates the installation of Cloud9. Head over to the Cloud9 Console for the region you’re using by clicking on the Services link in the AWS console; then find Cloud9 in the list or just type Cloud9 in the service search box:

Then you’ll arrive at the Cloud9 console:

Click the Create environment button and you’ll arrive here:

Enter a unique name. The idea here is that you can have multiple environments among your various instances, and this name will help you keep straight which is which. I just called my Development. The description is optional. Then click Next step.

In the next screen, click on the second radio button called Connect and run in remote server. This option lets you install Cloud9 on your existing server. Then in the fields below, you need to provide a login for Cloud9.

Before proceeding, think carefully about what is happening here: IDE software will be running on your server. How will you be interacting with that software? Through the web browser. How does that work? Well, normally that would require you open up a port such as 80 for the web browser to communicate with your server. But that’s not how Cloud9 on AWS does it. Instead, when you run the IDE, your browser will be communicating with one of AWS’s own servers. That server will in turn communicate with the Cloud9 code running on your server, which will allow you to modify your code. That means you do not need to open up a port through a security group for this server other than port 22. But you should already have done that since I mentioned you need SSH access to your server.

But this also means that AWS’s own servers need SSH access to your server, which is what we’re providing next. If this bothers you, then you might decide against Cloud9. I, personally, am okay with it as this is just a development server.

So now enter the SSH information. For the user, I use my own user that I created on my EC2 instance so that I can access the code in my home directory. But if you like, you can create a separate user with minimal access, and put your source code in an area where that user has access. The choice is yours. For the host, you will likely want an Elastic IP address associated with your instance, which you would enter here. It must be a public IP address, not a private one, as AWS’s own server won’t have access to your virtual private cloud. This is similar to what you’ll see, but with your own data filled in. The key is generated automatically:

Click the Copy key to clipboard button. This is the key that you’ll put on your server to provide access.

Note: I’ve had people ask me why you put a public key rather than a private key on your server. There are plenty of resources out there explaining why, but the short version is the private key stays with you (or, in this case, the AWS server accessing your instance, or stored in your own local machine as you SSH into your server). You keep it private. A public key is something that by itself somebody else wouldn’t be able to use to gain access to your computer.

Now open a terminal and SSH into your computer. You’re going to add this key to your server so that AWS’s Cloud9 server can access your computer through SSH.

Switch to the .ssh directory:

cd .ssh

Make a backup copy of your authorized_keys file in case you do something wrong and need to get it back:

cp authorized_keys authorized_keys_backup1

and then edit the authorized_keys file:

vi authorized_keys

Copy the key code onto a new line at the end of your file:

Now save the file.

Tip: Anytime you modify the authorized_keys file, don’t log out of your SSH session yet! You want to make sure you didn’t accidentally break the file, which could prevent you being able to log in again. Instead, open up another terminal window and try logging in with your usual credentials. If you’re not able to log in, restore your original authorized_keys file from the backup. Now you should be able to log in from the other terminal. Then try the whole process again, and make sure you copy the correct key onto an entirely new line, save the file, and test the login again.

Now with the additional key, AWS’s Cloud9 server should be able to connect to your server through SSH.

Back in the Cloud9 console, click Advanced settings. Here you’ll fill in a path to the area in your directory where your code files are. This can be your home path or a path to a development directory, or a path to a specific project; whatever you like. For the node.js binary path, find the exact path to the binary. Because I use nvm, the binary isn’t in the path by default. Instead, determine where it is from the SSH console, and paste it in by typing:

which node

Tip: If like me you’re using nvm and have multiple node installations, first choose the most recent before calling which node:

nvm use stablewhich node

In either case, take the results, which might look something like this:

/home/jeff/.nvm/versions/node/v9.2.1/bin/node

and paste it into the Node.js binary path textbox.

Because we’re not using a jump host in this example, you can leave that box blank. (If you are, you’ll need to explore that yourself further on how to configure it.)

Now click Next Step. An AWS backend server will attempt to log into your instance. If you have anything wrong with the credentials, you’ll see a message at the bottom of the console:

Or if login succeeds, but the node.js executable isn’t found you’ll get a different error:

After the login succeeds and the installer locates node, you’ll see a new screen where you can review your settings. Click Create environment and the installation will begin.

Next, the IDE will partially open, although it’s not yet installed. If you look closely at the URL, it will look something like this:

This URL is not the address of your instance. It is the address of a proxy server inside AWS that is accessing your instance. This is why you don’t need to open an HTTP port. Your browser isn’t even connecting to your instance; rather, your browser is connecting to this proxy, which in turn communicates with your server through SSH.

Here’s the dialog you’ll see at this point:

Click Next and you’ll be asked what all you want to install. (As for the link about installing manually, I have not bothered trying that because this is so easy.) Here’s the next screen:

Click Next to begin the installation. Note that at this point you might be asked to provide a password depending on how you set up your user; that’s because the installation uses sudo to run some of the steps.

If any errors occur, you’ll see them reported, along with a Previous button. Here’s an example of an Error; I intentionally removed myself from sudo to show what happens when the installation fails:

But after everything installs correctly, you’ll see Installation Completed:

Click Next and you’ll see a message of what was installed. Then click Finish and you’re in the IDE. Here’s what I see; I had previously created a small node app called app1, and I installed some node modules. The IDE shows the directory tree structure on the left.

If the IP address changes

If you stop your EC2 instance and then start it back up (as opposed to doing a reboot operation in one step), your EC2 instance will get a brand new IP address unless you’re using an Elastic IP. Elastic IP addresses cost money, and if you don’t want to pay the extra, you can simply update your IDE environment with the new IP address.

To do so, head over to the Cloud9 Environments page in the console. You’ll see your environments. Click the name of the environment shown at the top of the card, as in Develop or Cloud9Test2 in the image below:

A new screen will open showing the details for the environment. Click the Edit button in the upper right. Scroll down and you’ll see SSH settings just as when you created the environment. Simply paste in the revised IP address in the Host box:

Click the Save Changes button underneath and you’ll be good to go.

Architecture Recap

If you’re really curious about what’s happening behind the scenes, you can do some poking around in your EC2 instance and get an idea of how the IDE is working with your browser. For example, if you look at your /var/log/auth.log file, you’ll be able to see the logins coming from AWS. You could probably set up a few more logs and monitors if you’re that curious; however, this is by no means vital to using it.

But from a bit higher-level perspective, you probably at least want to understand a bit of what’s going on so that you’re aware of what type of security and access you need. As you saw earlier, all we need to use the basic IDE is port 22 to allow for SSH access. AWS itself opens an SSH session into your server.

When you have the IDE open and look at the URL, the general architecture should be apparent. Older versions of Cloud9 prior to AWS acquiring it ran a web server on your machine, and your browser would connect with that web server directly. But in our case, that’s not happening. Instead, your browser is communicating with an address on Amazon’s own servers, such as this:

https://us-west-2.console.aws.amazon.com/cloud9/ide/…

The address us-west-2.console.aws.amazon.com just maps to one of their own servers, not your EC2 instance. That server is then communicating back and forth with your EC2 instance.

Now what?

Now you can use it. You can read more at the official documentation.

Watch for more articles from me on this; soon I’ll do a writeup on working with AWS Lambda from within Cloud9. Also, you might have noticed the installation included Docker. Here’s a hint if you want to do some exploring on your own; you can see what images were installed; notice they all refer to Lambda.

Enjoy!