Before we dive much further, I want to talk about keeping your work area clean. Nearly every post I see regarding installing a programming language compiler or interpreter assumes you’re going to use the machine you’re working on. Well, obviously you will be using your development machine, but that’s not the point I’m going to make here. When you use your core operating system to install the packages, you’re cluttering up your system. When upgrades come around, some things allow you to install side-by-side while others require a direct upgrade of your existing installation. When talking about code, these changes can break your existing code base. Not only that, you’ve exposed your system to potential exploits that don’t necessarily need to be there. Let’s look at some ways to mitigate this.
Housekeeping
For starters, we can look at virtual machines. You can use software like VMware or VirtualBox to configure an entirely separate operating system running on your local machine. These virtual machines can then be set up once and a snapshot can be taken so you can redeploy to a previously known state. In the event that you get a virus on a VM or you screw up your installation settings, not a big deal, just redeploy the image. It really is that simple.
You get security and peace of mind in that you can effectively treat these virtual machines as a playground to test out anything you want, without affecting your local machine. You can install new packages, upgrade and downgrade software, treat them as testing environments or anything you want. The only downside, is that the resources required to run the virtual machines are similar to what you’d expect on a real machine. If you throw 4 Gigs of RAM and a couple of virtual CPUs in a virtual machine, those resources are taken away from your host operating system and provisioned directly to the VM.
Today, we have an even better option with virtualization layers known as containers. They are similar to full blown virtual machines, except they don’t really need the full set of resources that are required by VMs. They don’t have the full isolation capabilities that VMs do, so the trade-off for the resources is at least a slightly larger security footprint. This technology has evolved over the past decade and gotten to the point where the security implications are a minute concern.
On top of the reduction in resources, there is a huge time advantage in deploying containers. To set up a VM from scratch takes about an hour. Even deploying one from an image takes a few minutes. Deploying containers happens in seconds. They have caching layers so that previously built containers can be reused and a ton of other optimizations to make your efficiency as a developer go through the roof.
In either case, your code should live outside of the machine where it’s running. Put them into a source code repository on a remote server. This way, if your machine is destroyed or compromised in some way, your intellectual property doesn’t go up in smoke. Git is the current software to use for the general masses to interface with the code repository. Your company may have SVN or something if they’re not up to date, so whatever works for you.
My recommendation here is to use containers with the help of Docker on your host operating system. This will provide you with the ability to use containers and keep your host system clean. The command line interface for Docker is easy to learn or you can use the Visual Studio Code IDE with the Docker extension to manage your containers in a UI (see the screenshot at the bottom of the blog entry). Docker Desktop (Windows/MAC) also provides a slick interface for you to manage your containers as well.
Install the required software inside of the container, not on your host machine. Even better, use a prebuilt image that already has the software you need installed in it. If you aren’t sure where to get a prebuilt image, start at DockerHub and search for whatever you want to use: PHP, GoLang, Dotnet core, etc. Chances are pretty good that something already exists for you to use.
Comments