We will be running our development environment on a remote computer with AWS. Moving our dev env onto a cloud provider like AWS allows us to offload resource-intensive VMs from our local computer and provides several other benefits such as:
First, let’s clone this guide's git repository
Next, let’s install the required tools and software
This installs the following:
This guide requires an AWS account. Configure keys and set the default region to the one you want to use.
Run the following command to generate a Vagrantfile. This command initializes and applies our terraform.
This does the following:
Your Vagrantfile may look something the following.
Let’s create our development environment! We will use Ubuntu 20.04.4 LTS with 1GB of RAM and 1 CPU. Resources and OS can be configured with [aws.ami] and [aws.instance_type] respectively.
Let’s enter our development environment.
The project folder (the folder with the Vagrantfile) is synced uni-directionally from the original computer to the remote development environment at path /vagrant. With the Vagrant AWS plugin, making changes to the files on the original computer can be propagated manually and automatically with rsync.
In a new shell, let's verify our Node.js app is running
Now, let’s make a modification. We can either edit the code within the dev environment or modify the code on the original computer and sync it over. Let’s modify [app/index.js:6] on the original computer.
Next, let’s sync over the change.
Making code edits on the original computer has the added benefit that you do not need to transfer over your git credentials to the remote computer to commit and push. Working entirely in a remote environment with your credentials can be achieved with file provisioners.
We use a file provisioner to set up our git config and credentials on our remote machine. Find this in [Vagrantfile:5-7].
You can now make modifications within the development environment and push them to your repo. This is also useful for secrets like AWS credentials.
Sometimes you may want to clean up your development environment.
We can make several improvements with this dev environment configuration— the SSH server is exposed to the public internet, uni-directional file sync is limiting, and the Vagrantfile makes it tough to collaborate with multiple users.
The SSH server exposed to the public internet poses a security risk which can be mitigated by closing off the port and using either a jump box/bastion server or a VPN.
Uni-directional file sync makes moving files from the remote computer to your local computer tedious. To solve this, you can use a tool like Mutagen to enable bi-directional sync opening up new workflow possibilities.
The Vagrantfile has user-specific fields, such as the SSH key pair. These fields committed to a project version control system make collaborating difficult. To solve this, we can move the user-specific configurations to another Vagrantfile and merge them. Vagrant automatically combines the Vagrantfile found in ~/.vagrant.d; let’s move all the user-specific fields there. Check out the branch collaborate and run make [generate](<http://generate.to>) to see how to implement this.
Unfortunately, the AWS Vagrant provider has been abandoned and is no longer actively maintained. The most glaring of issues have workarounds; however, some sharp edges make working with the Vagrant AWS provider painful. Notably, the provider only supports a subset of Vagrant features such as snapshot, network, or share features.