Oct 11, 2019
If you’re a user of Visual Studio Code then you might have caught the feature update announcement recently that you can now do remote development with is. This opens some really interesting scenarios around how you develop and test code, like being able to write, build, test and execute on a remote machine that matches the server your code will run on - perfect for someone who likes to use a Windows desktop but deploy code to Linux servers like I am. This would usually get to me when I write a build script that needs to run inside AWS CodeBuild in a linux instance, and I would use commands in that which work on linux, but not have a windows equivilent (like zip for example). Now I can use the IDE and OS I love, and have a consistent experience with it all.
Obviously with the term “remote development” comes the next thought of “where does my remote server go?”. For me that’s easy, it’s Amazon EC2. In terms of using this for development of AWS based solutions there are a couple of great reasons for this. My favourite though is that you can stop using static credentials - When you write code or scripts or use the AWS CLI on an EC2 instance you can use an Instance Profiles to manage credentials for you, as opposed to using a static IAM credential that I store locally in my
~/.aws/credentials file. This is good news for security minded people.
There’s also a bunch of good reasons to use the Remote Development approach as well:
I decided to take a crack at setting up an environment I could use for this, and something else occured to me in here as well - why not make it a Cloud9 environment as well? It doesn’t cost anything extra to use Cloud9 (see the Cloud9 pricing page for more info) and it would mean that while I’m on my laptop I have VS Code, but if I ever need to code or demo from a different environment, I would have Cloud9 available to use in a web browser as well. Sounds like a pretty decent match to me.
To get started, I created an EC2 instance using Amazon Linux 2 as the operating system. I’m working in Singapore (ap-southeast-1) as that’s the closest region to me that has Cloud 9 (if I wanted to do this without cloud9 I could do this in Sydney instead). To streamline getting it ready for Cloud9 use though I added the following UserData so it provisioned out with the appropriate prerequisites
#!/bin/bash echo "[[YOUR CLOUD9 PUBLIC KEY]]" >> /home/ec2-user/.ssh/authorized_keys yum update -y yum install gcc -y curl -L https://raw.githubusercontent.com/c9/install/master/install.sh | bash
A quick run down of what this does:
Once your instance has come online, you can continue the Cloud9 new environment setup, adding the following values:
Click “Create environment” and you should be good to go. At this point we now have a custom EC2 instance running Cloud9 that we can use. Time to do the Visual Studio Code part.
If you’re not familiar with the whole remote thing, have a look at the VS Code remote development overview. The specific instructions you’re going to want to follow though are on the SSH Remote Development page. It takes you through the process of setting up a local key, adding it to the remote authorised keys file (if you need a terminal to run commands on the remote instance to do this, you can use the terminal in Cloud9!) and this will get you going. All of the standard rules of VS Code remote development apply here, there are no instructions that need to be changed because your using Amazon Linux or AWS or anything like that.
You can test that it’s all working by creating a new folder or files in Visual Studio code while your remote workspace is connected, and then going back to open Cloud9. You should be able to see the files you just created in the Cloud9 console as well.
The one other thing that came to mind for me here was that if I power my instance on and off (which I absolutely will do, no point in paying for it while I’m not coding) each time it comes back up it will have a new public IP, and therefore a new public DNS name. This means both VS Code and Cloud9 won’t know where to find the instance. There are a couple of options you could use here:
Either works and both have small additional charges for them, so do whichever you feel works best for you. Once you have a static IP for your instance you might also want to use Route53 to add a friendly DNS name to it, then go back and update your VS Code Remote SSH configuration and your Cloud9 environment to put the new host name in to yoru configuration.
I’ve been using a remote environment for a few days now, and I’m genuinely enjoying the experience here. I still have all my productivity and I’m very connected to AWS to test and deploy my code. It’s definitely something I’m glad I did and would recommend to anyone who is developing for AWS and uses VS Code!
You're signed in as | Sign out
There are no comments on this post yet. Be the first to leave one!