Help us to make this transcription better! If you find an error, please
submit a PR with your corrections.
Luciano: Are you tired of being tied to your local development environment when working on your cloud projects? Well, today we'll talk about how to use VS Code to develop against a remote cloud 9 instance running on AWS. With this setup, you can go from anywhere and take advantage of the power of the cloud. So whether you're working from home, a coffee shop, or maybe on a beach in Sicily, you can continue developing your project without worrying about hardware limitations.
If you are like me, you probably spend a lot of money to get an iPad, and you might be happy to know that you can finally use it also for coding. So in this episode, we'll talk you through the process of launching a cloud 9 IDE and two different ways that you can use to basically edit the code using VS Code instead of using directly cloud 9 as an editor. My name is Luciano and I'm here with Eoin, and this is another episode of AWS Bites podcast.
AWS Bites is sponsored by fourTheorem. fourTheorem is an AWS consulting partner offering training, cloud migrations, and architecture. Find out more at fourtheorem.com. You'll find the link in the show notes. So let's start with the question, why would you want to remotely develop with VS Code? And I think there are some use cases here that are interesting, and maybe not just the fact that you might be in Sicily enjoying some sunshine.
Maybe somebody calls you because there is an urgent bug to fix, and you have to struggle to fix it without leaving the seaside, right? So that could be one use case, but let's think about other use cases. Maybe a simple one that actually is something that happens to us quite commonly in our line of work is when we have to do training or when we have to deliver a demo. Maybe you want to have some kind of isolated development environment to give people the opportunity to play around, but without having them to think, okay, I need to set up an entire development machine.
So maybe we can give them something a little bit easier. That's actually, I think, one of the most representative use cases here. Another one could be when you have many developers in an organization, and it might be tricky to set up the development environment for everyone in kind of a uniform way. So if you can set up something in the cloud, that could be a solution that gets people started very quickly, and they are not also limited by specific hardware. Another one is that if you cannot access the network, the specific AWS network resources from your laptop, that client needs to be in AWS. So by setting up the development environment directly in AWS, you can easily work around that limitation of being physically present in that network with your development machine. So what kind of options do we have here to start to set things up?
Eoin: Yeah, so maybe just for a bit of context first. So in case people haven't used Cloud9, it's basically an AWS service that gives you a development environment. And how it does that is you can either use an existing EC2 instance, or it'll spin one up for you, and then it gives you a code editor and a terminal in the browser that you can use to do your development. And it's quite common to use this for training and once-off environments.
But the Cloud9 editor is pretty good, but it's not as good as all of the best editors out there like VS Code or Vim, which is obviously the best. There's a couple of things you can now do if you want to get around that limitation. And in fact, these methods will also work with just an EC2 instance. It doesn't have to be Cloud9. So what you need to do to get started, if you want to use VS Code on your local machine, is install the VS Code remote development extension.
And then there's two methods here. One is using SessionManager. And we just talked about SessionManager as part of the Bastion host episode. And one of the things we mentioned that SessionManager can do in SSM is it can provide you with SSH tunnels. And that's the secret ingredient here to making this work. So if you've got AWS CLI installed, and then you've got the SessionManager plugin for AWS CLI installed, then you can set up this tunnel.
And the process for that, there's a few steps, and I'll just run through them really quickly. You need to have an SSH key. So you might have one already, or you might create one just for this purpose. So you do your SSH keygen to generate that. On your Cloud9 instance, then you can go to the shell in that instance. You need to find out your instance ID. So you can get that from the EC2 console, or you can curl it from the metadata service in EC2.
Once you have that instance ID, which is the one that begins with `i-`, then you also need to add the public key that you generated to your authorized keys on the Cloud9 instance. So that's basically authorizing your client to connect to this SSH server. And the SSH server is already running on the Cloud9 instance. So you don't have to start it or configure it. Then on your client machine, this is where the magic happens.
So you edit the SSH config on your local machine, and you need to add in basically a rule that says, whenever my host matches the syntax, which is `i-*`, then create this proxy locally. And by the way, the instructions for doing this are in the SSM documentation. So this isn't unique to what we're trying to do here. If you search for how to create an SSH tunnel with SSM, with SSM, you'll find these instructions.
And we can also put a link in the show notes. And that means that every time you do SSH to an `i-` host, that it will basically intercept that and create an AWS SSM start session command with the CLI. And it will create this local tunnel that goes over SSM, uses IAM authentication to do the SSM. And suddenly you've got a socket between your host and the remote Cloud9 instance. So then you can just SSH directly into your Cloud9 instance.
First check that that works. Then you can also create a few additional parameters in this SSH config, which VS Code can then pick up. So you basically make sure you specify your Cloud9 host and the user you want to connect as, which is usually EC2 user. And that's it. That's all your setup done. Now you can just go VS Code, do control shift P or command shift P and select the connect to host option. And this host then, VS Code will automatically pick up this entry from your SSH config and allow you to connect to it. And right away, you're up and coding on this remote instance. You've got your VS Code environment on your laptop with everything you've configured on. You can, you get your autocompletion and your IntelliSense. You've got the VS Code terminal. You can do debugging, everything just works out of the box. Nice.
Luciano: I haven't seen before this proxy command thing with SSH, but sounds pretty clever and pretty useful in this, but in this particular case, I think it's useful also to summarize all the steps other than just linking the official documentation, we'll summarize all the steps and make them available in a gist on GitHub. And the link will be in the show notes. So you can easily just copy paste the commands of everything we just described and be running very quickly. So what's the second option? Because you mentioned there are two options there. The second option is a lot simpler.
Eoin: It's a lot easier. Maybe we should have gone with it first, but the second option isn't maybe isn't available to everybody, depending on what kind of environment you're in. Again, if it's an enterprise corporate restrictions, who knows? But the other option is using VS Code tunnels, which is their inbuilt remote development mode, which doesn't use SSH. It basically it's like doing its own version of how we described SSM working.
And you're basically establishing a connection from both hosts into VS Code's proxy layer. So you could do this by just having two VS Codes running. You can connect to one from the other if you're signed in with your GitHub account. It's a bit like VS Code live sharing. If anyone has used that, it's a similar mechanism. But on your Cloud9 instance, you don't need to run a full VS Code. You can run the headless binary.
So you can just download the VS Code CLI from the Microsoft website. You can run that on any platform, including x64 Linux or ARM Linux. And then you just get a code binary and you run the command code tunnel. And right away, it'll allow you to log in using the OAuth device code flow. Some people might remember that from our live stream episode, where we built the WeShare product, the WeTransfer clone.
We actually implemented that device code flow. So that'll allow you to log in with your GitHub account on your VS Code instance, just using your browser. And then you just have to give it a machine name. So you just give it a name like my Cloud9 instance. And you immediately get a vscode.dev link. So you can click on that link and then you get a VS Code editor in your browser. So this is where you might finally, you know, you might be able to pay off your iPad because you can suddenly start developing on your iPad with this vscode.dev link. And you don't have to install anything locally. You can do this on any machine you're in. You know, even if it's a coffee shop library, you can potentially do this. But you could also then go back to your VS Code on your host if you want to use your local environment. And you can do control shift P, command shift P, and then connect to tunnel instead of connect to server. And it'll give you, because you're logged in on GitHub on both sides, it'll allow you to pick the machine name that you just specified and you're up and coding again in VS Code. Nice.
Luciano: I'll give you an extra tip there that if you use GitHub for login and you have enabled GitHub, so saving your VS Code settings through GitHub, basically, when you bootstrap this vscode.dev web instance of VS Code, it's actually going to start to inherit all your themes and plugins. So you don't even have to think about reinstalling everything in this environment. It kind of starts as if it was your main development environment, which is pretty good. This really feels like magic, this being able to do this.
Eoin: I can imagine using this in lots of different situations. The only thing is I'd love to know more about what it's sharing under the hood, what is being exposed and being copied from one instance to the other. Because if you imagine, if you're working on a customer application, I wouldn't do this without understanding exactly what's being shared. For example, when I launched my vscode.dev, I could see that it had picked up that I was using AWS toolkit locally. It installed this. I could select various AWS credentials that I had on my local machine, even though this was running on the remote machine. Now these credentials didn't actually work, but it seemed like it made me think, okay, well, what is actually being shared here between my client machine and my server machine? Are my local AWS credentials possibly being copied up onto this Cloud9 instance? I don't think they are, but it's worth investigating more thoroughly before you would adopt this widely for sensitive applications or code bases where you don't want the code to be leaked outside the environment.
Luciano: Awesome. So again, we'll make all the links and all the resources available in the show notes. Make sure to check them out if you are curious to try out some of these ideas. And we are also curious to know from you, as usual, if you have solved this problem in different ways, maybe using other tools. So definitely let us know in the comments. And if you liked the episode, remember to give us a thumbs up, subscribe, do a review of the podcast. If you are listening to the audio podcast, all of that stuff is going to help us a lot to keep promoting the podcast and understand what you like the most so we can produce more content like that. Thank you very much again and we will see you in the next episode.