Using Vagrant on Windows
TL:DR;
- Use Git Bash instead of Powershell or CMD
- Set Git Bash to run as Administrator
- Use host system to do git things, not the VM
Since learning of Vagrant I decided it would be nice to include it into most of my open source projects. As a developer for a student organization, most of my peers use a Windows environment for development (for example, using Visual Studio to compile code rather than MinGW). Whether you like developing on Windows, sometimes it just doesn’t cut it. My team is developing an extremely specific component of our organization that needs to run a distributed environment of NodeJS, GitLab, PostgreSQL Docker containers.
We first tried to run these things on their personal Windows development machines; however, we ran into many troubles with Docker and Dockerized versions of PostgreSQL.
Then we we wanted to try Vagrant.
For those who don’t know, Vagrant allows you to define a configuration file of how your virtualized development environment should look. These factors include which base OS to use, software installation, port forwarding, shared folders. Basically, it is an easily configurable, headless VirtualBox instance.
# -*- mode: ruby -*-
# vi: set ft=ruby :Vagrant.configure("2") do |config|config.vm.box = "ubuntu/xenial64"config.vm.synced_folder ".", "/vagrant", disabled: true
config.vm.synced_folder ".", "/home/ubuntu/workspace"
config.vm.provision "shell", privileged: false, inline: <<-SHELL
sudo apt-get update
sudo apt-get install -y git
curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.0/install.sh | bash
curl -sSL https://get.docker.com/ | sh
sudo usermod -aG docker $USER
source $HOME/.nvm/nvm.sh
nvm install node
SHELL
end
This is one of our configurations. We like being able to use NVM a.k.a. Node Version Manager and Docker. Especially since NVM allows us to simply install the current Node version, it allows us to stay up-to-date easier; however if problems ever arise, we can easily roll back to the LTS.
Some other things to note about this configuration is how it disables the default synced folder, and instead maps the current host working directory to ~/workspace . I find this easier and more natural because one of the first things any new developer (or even myself) will do inside a newly created Vagrant VM is ls to see what is available to them. It is slightly unintuitive for there to be a /vagrant folder that the user is supposed to know about.
As nice as Vagrant is, we had MANY difficulties getting it to work properly. I was using Linux and the other senior developer was using OS X, so neither of us really needed to use Vagrant; however, most of the new developers were using Windows. It was here we encountered our trouble.
First we tried CMD and Powershell
We didn’t spend too long trying CMD (because Powershell is simply better for this application). As it turns out Windows 7/10 don’t include an OpenSSH compatible SSH client by default.
What.
After GitHub issue, after GitHub issue, after StackOverflow question, etc., etc., we realized that it was just easier to expect our developers to use Git Bash, which includes an OpenSSH compatible SSH client. And things were working okay.
However; we did have two major issues with using Git Bash. Firstly, sometimes symbolic links mess up inside the Vagrant instance. Secondly, when using the Vagrant image to commit, add, push, it doesn’t realize that the files originally came from a Windows environment. The line endings, although in Windows format, should be committed and pushed as Unix line endings. Therefore, be sure to use the host Git Bash to do such operations to prevent weird line endings.
