Demo: The Benefits of Secure Remote Development for Teams

In this webinar, we explore how Coder manages the setup, configuration, and maintenance of development environments. Learn how Coder provides the best developer experience for teams working remotely, so they can ship code securely.

Watch the full webinar above, or read through highlights from the presentation below.

Introduction: Simplifying Remote Development for Teams

THOMAS: All right, well, hello everyone. As we were saying, we're gonna be talking about securing remote development for teams. You know, just to recap as covid 19 hit, everyone went remote there and development had to go remote too. And maybe we weren't ready for that. I kind of wanted to cover at a high level what Coder is doing to help solve that problem of remote development, keeping it secure, keeping source code secure, and then giving your developers the benefits too. They're not dealing with a lot of red tape and they're able to do what they do best they're able to code.

This is me, Thomas Hughes. I'm a senior DevOps engineer over here at Coder. That's my contact info there as well. Quickly basically we're just going to go through and do a quick introduction to kind of what Coder is, just to level set everyone for this first demo. Then I'm actually going to do a live demo. Hopefully that works out perfectly fine without any errors because live demos always work the first time. We'll do a little wrap-up session type thing and then we'll have some time for Q and A as well. If you have questions, please use the Q and A feature here. We'll definitely get to them in the end. Ben just mentioned that in the chat as well. We'll have some resources at the end. We'll, of course, send out this slide deck to you afterward and all of that. With that said, let's go and talk about Coder for a little bit.

Overview: What is Coder?

So, Coder is a platform that allows you to do your development in a cloud type environment. This could be completely on-premises. It could be in something like GKE or a KS or EKS for the different cloud providers. But the main thing here on this diagram that I like to call out is your developers can connect with any device. On here we have Linux, Mac, Windows, and a Chromebook for example, but they connect into your Coder cluster and everything on that side is behind the firewall.

When we talk about securing development, we now own everything behind the private network and this really helps us with things like Zero Trust and stuff like that. You know, we basically have to do our same remote connection that we normally do, but then all the environments can be kind of maintained and kept behind the firewall.

Solving for Latency With Kubernetes & More

This also helps with things like latency issues. If I have to connect to a database, that database also lives behind my network, for example, uh there's a lot of benefits that kind of come from this. Of course, we get the power of Kubernetes by being able to expand pods and have multiple pods running on VMs and then have those VMs have more hardware than maybe my local compute would.

Accessing Your Dev Environment From Any Device

And you might have even seen our Coder blog post on iPads, for example, where we had a developer using an iPad for I believe it was a month plus and he didn't have any problems because he's remoting into a virtual environment that has everything he needs to do his development but has all the cloud resources or cloud compute resources he needs, without having to worry about his iPad running all of that himself.

Consistent Infrastructure & Developer Environments

The other cool thing about this — and we'll show this in the demo as well — is that Coder provides a way to have a declarative approach. When we talk about GitOps and this kind of idea of infrastructure as code or pipelines as code, one of the biggest things we want to talk about there is really having the repeatability of consistent deployed environments that are exactly the same every single time. And Coder does that by leveraging both Dockerfiles for the tools, but then the infrastructure those tools run on on your pods itself, and I'll show you what those look like with our Coder workspace templates.

Support for Multiple IDEs & Use Cases

And then the last thing that's really neat to call out here is we show a few different languages in here, but we actually support a variety of IDEs, so we have the VS Code in the browser, Jupyter Notebook, RStudio, all the JetBrains IDEs are available. And then you can actually do things like set up a VNC remotely to actually have any type of desktop IDE, and you can actually connect your local IDEs to Coder like an ssh connection.

Same tools, same workflow. And that's kind of what the point of this demo is going to be is. You know, how can we do this remote thing in a secure fashion and also not interrupt my developers and make them use some new workflow that no one's ever touched before.

A few other things I've talked about, some of these things already, but just to kind of recap here, so your developers are going to be able to use those tools that they're used to if they want to use JetBrains, they can use JetBrains. If they want to use VS Code, go for it, you can use VS Code, you can get your extensions, you can get your themes, you can do all of that.

You get more compute than what you would normally get. Maybe I'm in data science or maybe I'm doing something that's just very intense in general and I want to have 64 cores and 128 gigs of RAM or something like that. We can spin up a machine in the workspace for that and you can do that development there, which doing that locally would probably not happen with the hardware requisition.

Simplified Environment Configuration

The less time configuring part is probably the biggest piece too. You'll see in this workflow that I'm actually going to be able to stand up my development environment within about five minutes and it's going to give me all the tools that I need to get started with contributing to the project. I don't have to worry about managing my local path or installing the tools and getting the right dependencies and all of that type of stuff.

On the sysadmin side of things too. We're also helping them out. For any sysadmins in the chat that are watching here, maybe you have a ticketing system or something like ServiceNow to request remote resources like, hey, I need a VM provisioned for my dev environment. Well, Coder basically, again, is giving you this declarative way to go through and create this consistent environment for your developers.

One, you get audit controls, you get the as code declarative statements so you can version control at all. But secondly, you can set up all your automations around that too. You can actually roll out deployments of these environments and then have developers basically self-service to create their environments based on the rules that you've already set up in these templates.

Live Coder Demo

I'm gonna go ahead and jump over there, stop the presentation for a moment. And what I'm going to show is that I'm using GitHub in this case. I have this money tracker app that I found through an open source project on GitHub. Credit to the original author there. I forked it. I made a few changes to it for the demo here and it doesn't really matter what the code base is. In this case it happens to be React, it happens to be on GitHub.com, but it could be GitLab, it could be a Bitbucket, it could be an on-premises deployment of like GitHub enterprise server or GitLab Enterprise or something like that. The point here is just that I want to show the flow being a very similar process here.

Setting Up a Secure Docker Container & Cloning the Repo

I have this repository of, let's say I've never contributed to this one before and I need to set up my development environment and I just want to show how quickly that can be. If I scroll on down, we'll see there are some unit tests failing here. That might be a good first fix for me as a developer. And if I look down at my contributing area, I've got this “Open in Coder” button and when I click on that I'm going to be opened up to the screen.

I'm logged into Coder already, and it's going to ask me for just a few things. What do I want to call this development workspace? I mentioned it was a React app, so maybe I'll just call this one react in this case. "Which organization" is like a team function. Coder supports the ability to deploy into different team type concepts. I'll just leave it on our default there. And then the workspace providers just which cluster I'm deploying to. The built-in one will be fine. That's the closest to me. I'll get really low latency. Coder does support the ability to add multiple providers and you can have these Geolocated so you have low latency for your developers that are maybe stationed around the globe. We have developers in Brazil, in Australia, for example. We have clusters local for them.

But clicking that button, what's happening right now is we're actually pulling a container in this case from DockerHub, but it could have been any container registry, whether it's private or public. That container has already been scanned. We know that it's secure and it's hardened and it meets the requirements that we need for our development environments.

The last thing it's gonna do is it's going to go ahead and pull this in and then clone down my repository too. It spun up this whole thing for me based off of a template file that I'll show you in just a moment here. And I didn't have to do any extra steps at all. Everything is configured and ready to go.

Choosing an IDE: JetBrains WebStorm

What you might notice here in our applications is there's a few different things available here. I mentioned JetBrains IDEs being available. This is a React project. So I have JetBrains WebStorm. Just as easily I could have had IntelliJ installed. This is just coming with my Docker image itself. I also get a terminal and then code web, which is actually our open source code-server project, which is VS Code in the browser. I can connect to my local terminal if I want to. But really Coder makes it even easier than that. I can just click this button. I'll get a terminal that actually works just like I would expect any local terminal to work. I can go ahead and cd into that project that was cloned down for me. I talked about all the tools being here for me. I get the exact version of Git and Node that I need for my project. I don't have to worry about managing that with NPM or virtual environments or anything and I can just install my dependencies That's going to go in and run through here.

Port Configuration Management

And while that's running there's actually one other step that I want to do. The React app happens to be a web app. We're gonna have a front end to it that we want to see. What I'm gonna do is I'm going to add what's called a dev URL. If you haven't used this at Coder before typically doing something like Docker development, you have to expose ports and forward it to your local machine and all this stuff. If I was doing web development, I would type localhost in the browser, but this isn't going to be running on local. This is running on a cluster behind my company's network. I need to expose that to my local user and we can do that with dev URLs in a really easy way. If I click on add URL, I can actually specify exactly which port I need and give it a name. I'll call this one live demo. I get some access controls around this too. Again I can open this up to anyone on my team to view, anyone that can sign into my Coder deployment, and then I can actually make it publicly available to the public internet if I wanted to or just public to my network if I'm in like an air-gapped deployment. I'll leave it on private for this and hit save. We see it listed here and it's listed as offline. It makes sense. We haven't started the service or anything like that. Let's go ahead and do that now.

Spinning Up a Development Server

If I go back to my terminal and I hit NPM start, that's going to kick off my development server for me and we'll actually get everything running here where we can go through and have our full app running for us. And you'll note that again, I haven't actually installed anything locally so far. I haven't had to clone anything. The clone actually happened to this remote server as well. My secure connection into Coder is the only thing that's needed to make sure that we're in the secure environment here.

Swapping Development Environments

While this is running here too, I did want to show one other piece. I have this workspace here. and you know, a question that comes up and I see it in the chat here too is, well, do I need to create that every time? For the purpose of this demo, I just wanted to show how easy it is to get started. But I have some other workspaces that have actually been created previously for a Python environment with PyCharm in Java with IntelliJ as well. Just context switching is just hitting the dropdown, selecting the environment, and you're done there. There's no need to continually start over from scratch every single time, which is great. You can turn these off and on, put them on a standby mode, that type of thing, but you don't need to have it deleted every single time.

Support for Local Development Workflows & Habits

Now that we're running we have our server running here, I can click open in the browser and we can actually see the app running here. It's gonna ask me for a couple of things. I'll just say like checking account, this happens to be a money tracking app similar to mint.com. Let's say we have a checking account there and then I'll say a savings account just to have a couple options in here and we can kind of preseed this data. 500 Bucks. Cool. This is our app and this app’s running from our codebase. We saw there were some test failures so maybe we want to take a look at that now and I can see my same development flow that I would normally do.

You know, again just to recap though, I didn't install anything whatsoever except for just hitting that NPM install command. Everything is available here for me and I have my local copy of the operation. I didn't have to worry about managing environments. I don't have to worry about things like, well it's working on my machine, but then it doesn't work when I push it somewhere else, that type of thing. It's all just a consistent environment here. If I go back into my terminal here and I cd into that and do an NPM test, we'll see our test failing here.

Adjusting Dev Performance & Compute

One of the cool things about this is I can bump up my compute here as well, right, so I can have all of my tests run way faster than I would locally, and I'll actually show you that in the slide deck as well. We have a few failures here and it doesn't matter too much again what the code is specifically here, but I introduced a bug that has to do with the income and expenses here. If I say that I spent $50 and I hit add it actually increases my net worth by $50 instead of decreasing, so we want to fix that bug.

Seamless Git Workflow: Updating & Pushing Codebase Changes

How do I make my first contribution then too? I'll go and click on code web and get to the VS Code in the browser here. This is gonna work just like a local VS Code. I can actually set it up with my same settings by json file if I wanted to. I could have a theme applied to make dark mode, for example. I could have certain extensions on here, but I'll go ahead and navigate into my project directory, go to that source folder, and I happen to know exactly where this problem is, and if I go down to that here, we'll see that I just inverted these numbers here. Again, the code itself doesn't matter so much. But when I made a change, my tests were automatically re-run for me very quickly. We'll see everything passed now. My bug’s actually been fixed. What I want to do is I would go ahead and okay, I made my change. Let me go to make a new branch, right, fixed transactions. I can do a good status real quick and see. Ok? Yeah, there's my file. I'm going to add it, I'm going to commit it and then I'll do a Git push. What did I just call this branch? Fixed transactions. Okay, so just like that, I just made my first commit to a repository. I literally didn't have to install anything whatsoever. Within just a couple minutes of talking here, I was actually able to make my first push and see all of my tests passed and everything.

What would I do from here? I would go into my repository. I'd go ahead and set up my pull request and I need to change this to my base and main for my branch and I'll just go ahead and leave this like this. Typically of course I would fill in this with maybe the ticket I'm working on or something like that and we can see that my CI is running. I have some CI set up with GitHub actions, in this case. It could have been Travis. It could have been GitLab CI. It could have been anything like that. But these are actually going to run through now and I go through the exact same flow I normally would. Right.

Managing Development Environments

As a developer I didn't have to set up anything locally. I actually could have had even the NPM install done manually for me on that first creation. And you know, I know that everyone that runs this image is going to be on that same base layer. We all have the same version of Node, we all have the same version of Git, we have all the same version of every dependency because that's version-controlled as well.

Declaring Your Environment Specs in a YAML File

Let me show you how that works too. I'll go and let these run. we should see everything pass. I'm not expecting anything to fail there at this point, but if I go back to this repository here, I have a template file. I mentioned that this is being built in a declarative way. For the GitOps folks out there, we do have a workspace template. And if I go to my dot coder directory, this happens to live in the same repository by the way. But it doesn't need to. If we had a completely separate GitOps repository, that would totally work, too. This repository could be a mono repo; it could be something that has maybe multiple sub repositories that are needed or multiple dependent repositories. All of that's possible here as well. But I go to my coder yaml file and this is actually where we kind of specify the speck of what I expect my development environments to be. The first thing here is I have a unique image for this one here specifically. Again, it's on Docker Hub, but it could have been to any private container registry as well. This is an image that we've already gone through our sysadmins have hardened and made sure that all the container scanning passed properly and has everything we need for developers to get working on this project.

Declaring Compute Resources & Custom Configurations

I then get to specify exactly what I want for hardware. So CPUs, RAM, disk space. I can also do GPUs if I'm doing something that requires a GPU cluster as well. This is running in Kubernetes, so I actually get some custom labels as well. Maybe I want to chargeback groups, for example, for a contractor that's going to be coming in. And then I get my configure step and this is where I can really do all the custom things. I can name out multiple steps here if needed. But specifically what I'm doing is I'm getting rid of a prompt for ssh keys and then I'm cloning down this repository and this is where you would then go ahead and clone down all of your additional sub-modules or additional dependencies as well. If you had a microservices type setup where you have maybe five or six different repos that need to be plugged into this project, you would just add them into your file here. The first time you make the workspace, they'll all be cloned down.

If this file is ever updated or this Docker image is ever updated, the developers are prompted to re-build their workspace. All of their in-flight data is saved. We preserve the home directory for them so they don't lose any of that either. And again, it's just basically making sure that in a declarative way we can be consistent, we can be reliable, and we can actually take the same container and we can actually use that in our CI if we really wanted to, right? We actually know that the development environment and CI are very close, if not exactly the same because we're using the same image as a base. Then we can then know that our production environments are going to be even more reliable as well. It's a really cool way to go through and you know, kind of take this idea of DevOps — as we've shifted left more and more there's the infrastructure as code piece for deployments and then there's the pipelines as code piece for how we've talked about... oops sorry about that noise there.

Avoiding Configuration Drift

The pipeline as code piece for your CI-CD and then shifting left kind of stopped there. As this DevOps transformation’s gone through, we kind of stopped at the developer piece, which is the core piece to it all. Now with Coder, we're actually making that declarative as well. Again, the Dockerfile tells you the tools you need and then this workspace template tells you the infrastructure that tool is going to run on. The benefit of this is now all of my developers are working in consistent environments, which helps avoid configuration drift and removes that "well, it works on my machine" type of thing.

If you want to learn more about Configuration Drift, check out our guide

Comparing Development Performance: Cloud vs. Local

If I go back to my slides here for a second just to show a few other things. So Ben’s on the call here as well with me. And he actually took a few screenshots comparing this project specifically with his local machine to his Coder workspace and he found in pretty much every major thing that he was doing, every major operation, doing it in Coder was just faster. Your cloud resources. It's a dedicated unit, just to that one thing. You don't have to worry about all the other background applications and services that are taking up resources on your local machine. And again, if this was like an iPad or a phone or a Chromebook, you may not even have local resources to really compare to this cloud resource.

This first one here is just showing the setup process. Normally you'd have to install the right version of Node or use NVM to switch to the right version that you need for your development and then you have to clone down your repository. With this workspace, all of that comes with your workspace when you set it up. You don't have to worry about any type of time difference there or any large setup process or configuration process as you switch your local environment around.

Same thing with builds, right. I didn't show that specifically in the test because we just did an NPM test instead of doing a build first, I guess. But with the Coder workspace, even having a little bit less RAM, we were still able to do it as it shows here significantly faster. You know, in a third of the time, basically, or less than a third of the time, we're able to build all of this. It just means less time waiting as a developer for things like builds and CI to run. And here's your test piece of it as well.

This is a nice gif that Ben made for us. But the same idea here basically is that on Coder it was able to run through in just a couple seconds and then with that watch command it's going to continually rerun those for us. We can do the same thing locally, but it just takes longer. And why do I want to wait as a developer? I want to do what I do best — code — and not be dealing with all the other things here and get in the way.

Demo Q&A

With that, we got about seven minutes left here. I wanted to get to our Q&A. I see a couple of things in here as well and, Ben, I think you've been curating them for me. Let's see here, let me just catch up a little bit on the chat.

Question: Managing Multiple Dependencies

Can I use a single workspace for all of my dependencies? If I use python and javascript in a single repository, can I just install both?

Yes. Absolutely. Your Dockerfile specifies exactly what tools you need. That Dockerfile could have 10 different IDEs if you wanted. It could have Python, Jupyter Notebook, RStudio, I'm sorry, PyCharm, RStudio Jupyter Notebook. You can kind of have your pick of tools there. You can have multiple languages installed. It's really just like doing Docker development, but instead of having to do that locally and then share Dockerfiles between all your different employees and trying to figure out how to manage that in a secure and repeatable way, Coder is giving you an enterprise approach to that.

Again, it's this declarative way to say this is the exact environment that I want to run. I have all the resources that I need specifically for this. I don't have one person having maybe a faster computer, so it works better on their machine than my machine. Everyone's using the same baseline image and then within there, again, whatever tools you're using can be completely customized.

Question: Optimizing Build/NPM Install

Should we install NPM every single time?

Yeah, NPM install took a little bit of time there, and I hid it by doing the demo piece and talking about other pieces here. But one of the things Ben and I talked about is how can we optimize this more? Well, if I go — oops — out of this and go back to that template file for a second. I could have run a command here right after the clone that cd-ed into the directory and then I could have done an NPM install. When my workspace was built the first time, it could have just done all of that, for me. There was no reason for me to go ahead and do that separately other than just to show on the demo piece, like, kind of an initial setup and compare it to local basically.

Question: Managing & Maintaining Workspace Configurations

Ben's also mentioned in here and I think I mentioned it briefly as well, the home directory is saved.

When I look at my Coder workspaces themselves, I have this Python one here, for example, and the Java one, of course. And then we had the React one — I have a different tab for that. I can hit this rebuild button anytime. Whether that's a new container was pushed to our container registry, or this template was updated, then I would actually get notified as a developer with a little banner up here that says I need to rebuild. Admins on Coder can actually force those rebuilds as well. But this will just make sure that I'm always using the same toolset as everyone else in a consistent way.

The cool thing about that though is we assign a persistent volume claim that preserves your home directory. If this gets turned off because it's the end of your workday and you're stopping your workspace and you want to start it the next morning, we just reattach that volume claim and you get the same home directory that you had before. Again, your in-flight work isn't lost at that point.

Question: Angular Support & Workspace Best Practices

There's a question about Angular workspaces on Coder, specifically, not recognizing ng commands. We have to install TypeScript Angular again. I'd love to help debug that a little bit more. And, Ben, if you can put maybe our support email address in there. I'd love to take a look at that because if that's a bug we want to make sure we fix something like that.

BEN: Absolutely. I'll drop in the support email. And one other thing to note there, kind of when you were talking about the persistent home directory is, I believe, without kind of looking into your setup, that would be because Angular isn't actually installed in the image. And then you would be installing it once the workspace has been started. While that certainly works. Once the workspace has been started, you can install Angular. When the image is rebuilt, Angular is lost. And the reason for that is so that all of the tools that team essentially would use all live on the Docker image and that's the source of truth. A solution for that, if that is the case, would be to add Angular to the Docker image that your team is using and then everyone on the team would have Angular and it would persist across rebuilds.

Question: Coder’s Template Format

The last question that was in the main chat here asks what template Coder uses.

So Coder has its own template format. It's using YAML, but it's a very similar format to what you would see in something like Ansible, for example, as a playbook where you're just kind of doing your declarative, this is the infrastructure that I'm using, that type of thing.

Question: Building, Starting, & Testing Docker Images

How easy is it to build a Docker image, start it, and test it? On a laptop, your normal Docker / Podman installation would allow you to docker build, so it's pretty easy. Is it possible in Coder? And if so how?

Great question. Coder environments can actually run Docker and Kubernetes within here. Even though we're using a Docker container for our development, we can do Docker in Docker. It's super easy to do iteration from an environment. Now on the separate side of that, as an administrator, I can actually just go in, or actually as a user, I can import images from the approved registries that my admins have gone in here. If I built my own custom image, which I think I have one or two, yeah, I have some data science stuff in here. And you can see obviously a lot of other users on here have done their own images as well. I can import that. Kick off the build for Coder and just see if it works and if I get the error log then I'll actually see that in my workspace log itself here as part of this build log here.

Basically this creates a workspace and goes through and build all the layers and all of that as well. Hopefully that answers that for you there. But it is a pretty quick iteration and we actually have some guides that I think that Ben actually wrote on creating custom Docker images using the tools that you want, whether it's a specific IDE or something like that. And there's also actually a recent blog post that I was using remote VNC and I had Spyder IDE, which happens to be a data science IDE that people are interested in. And I was able to remote VNC Into my Coder workspace and I get my full desktop environment. And actually, since it was running on a dev URL, I was actually able to share it with my team and they could all see my exact desktop.

In certain areas or certain environments, we have these issues that come up when we talk about remote, right? We have problems with making sure that everything is done in a secure way. Well, Coder is doing that by keeping everything on the firewall. Again, I didn't clone anything, I didn't install any tools, I used an image that's been pre-approved and already processed by our sysadmin team and hardened and everything like that. And then on the opposite end of that as a developer, I can just self-service and click a button to create my workspace and then my workspaces are available for me until I delete them basically. You know, it makes it really easy to do all your development there without any of the configuration hassles locally, without anything other than just like, OK, maybe I have to VPN into my corporate network, but then once I'm there everything's fast because I'm on cloud compute, I'm accessing a database that's also on the corporate firewall, like all of that.

Question: Support for ‘Docker in Docker’

One follow-up question to what I was just talking about, asking about whether Coder has support for Docker in Docker.

Just real quickly, I'll say that yeah, you can do Docker in Docker and push it to your registry and then you can import to Coder and start that workspace. And Ben's typing an answer there too, so I'll let him finish up there.

Wrapping Up: Simplifying Remote Development

With that everyone thanks so much for attending. We are hoping to do these monthly and we'd love to hear any feedback you have as well. These buttons here are actually links, so when we send out the slide deck to you using the email that you signed up with, you can go in and go through here and see these resources.

If you want to sign up for a trial, we do have a 60-day trial offering here. We have a Slack community as well that you're welcome to join, and then of course we have our contact page there too. Just please reach out to us whether it's the support@coder.com for some technical support specifically, or if you're just interested in reaching out and hearing how Coder can help solve your solutions — ha — to solve your problems and be a solution for your remote development. We'd love to talk to you more and hear about your use case too. Thank you, everyone.

Further Reading

• Remote Development with JetBrains IDEs
• Guide to Remote Development Teams
• Deploying code-server and developing in the cloud