My Hypothesis
The basics
I'm a web development boot camp instructor at theClubhouse and I teach full LAMP stack. On site we provide computers for our students to use. Sometimes students will use their own.
The problem
I get to think about some really cool problems for new devs. What are the most relevant skills to teach these students? How much do code newbies really need to know about setting up their dev environment? When at a new job how much will they actually set up their own environments from scratch? How much time do I have to go over environment set up in class?
My personal answer
I am a second career dev and have setup all of my environments. Even if the internal workings of a computer isn't code related it is still dev related and so I believe is important to teach.
The reason someone else may care
Some hiring managers have expectations that new devs should be building apps outside of work to show motivation and commitment to the craft. I think in technical interviews for brand new devs I haven't seen many questions about how their environment is set up. I think that a professional dev environment can provide talking points that can point to a surprising amount of technical skill that can be extraordinarily valuable on a team.
My Journey
I learned development at Vets Who Code, a full JS stack course. I personally focused more on JS language fundamentals and very little on working with Node or server deployments. This got me my first job, but when I got there I was pretty lost for the first few weeks of onboarding. It was a PHP shop that used MAMP. Most of my work though was on the front end very rarely touching PHP and the back end.
After that job I started teaching. I taught using tech I was comfortable with. So my and my students' dev environments were using MAMP on Windows. MAMP stands for Mac + Apache + MySQL + PHP, that means I was using a piece of software for Mac on Windows just because I was comfortable with it. So when I had issues with MAMP on some of the machines, to fix the problem, I would tell them to try out XAMPP standing for "Cross Platform" + Apache + MySQL + PHP + Perl. Unsurprisingly that broke sometimes, so what did I do? I would say ask them to check out WAMP because its for Windows. So now we have a great dev team set up for success right? We didn't enforce PHP/*AMP/MySQL versioning. So everyone was on a different system type using different software. This resulted in a huge amount of bugs when they would push to production. I chalked it up to being a good lesson for them as what is going to happen in the real world. After a couple of classes and some down time until my next class starts I have been able to work on some side projects.
The first step is admitting you have a problem
After the realization of the issue came the decision of how to improve. I had some free time to get this project up and running but not a whole lot. I didn't feel confident I would be able to get Docker working in a timely fashion without ever having worked on it. I had heard of Vagrant before but it still looked pretty intimidating. I have manually configured virtual machines (vms) before but it is still overwhelming to think about how to orchestrate an entire classroom with a vm snapshot that you created. Jerome Hardaway recommended that I should to try out Scotch Box. That's pretty much all the convincing I need to start a project.
From Scotch Box to Vagrant (The Technical Stuff)
How to Scotch Box
- Download Virtual Box
- Download Vagrant
git clone https://github.com/scotch-io/scotch-box my-projectcd my-projectvagrant up
Boom! up and running with a basic Scotch Box. Navigate with your browser to the IP address (http://192.168.33.10) they give you and you should see a pre-built landing page. Ssh (vagrant ssh) into the box to see the file system where var/www is directly linked to the public folder where you started Vagrant.
Now what I did wrong was I started quickly turning boxes on and off not checking for proper shutdowns. I started to notice a weird behavior, I could ssh into the box but when I navigated to the url I would get site is unreachable.
I noticed a few warnings when I would invoke vagrant up.
For example, one was this warning:
==> default: Checking for guest additions in VM...
default: The guest additions on this VM do not match the installed version of
default: VirtualBox! In most cases this is fine, but in rare cases it can
default: prevent things such as shared folders from working properly. If you see
default: shared folder errors, please make sure the guest additions within the
default: virtual machine match the version of VirtualBox you have installed on
default: your host and reload your VM.
default:
default: Guest Additions Version: 5.1.21
default: VirtualBox Version: 6.0
Guest Additions to my understanding is installed on the virtual machine inside of VirtualBox and is the way that those two communicate. So if Guest Additions is broken I would assume that nothing is going to work on the box as it would not be able to run any commands.
So I followed Kevin van Zonneveld's post and found this command vagrant plugin install vagrant-vbguest. There are alot of Stack O' questions and answers about how to update Guest Additions. No change.
I tried a whole bunch of different things like, different Vagrant commands, reinstalling everything, blowing away packages, and no dice still no change. Luckily there is a crazy smart guy here at theClubhouse who walked by and said at the right time "If you ever hit a road block let me know". I took my laptop over to him and having never worked with Vagrant but has worked at Red Hat for a long time we started to troubleshoot together.
Here are some of the steps he took:
-
ping'ed the box to see if it was reachable.
└──╼ $ping 192.168.33.10
PING 192.168.33.10 (192.168.33.10) 56(84) bytes of data.
64 bytes from 192.168.33.10: icmp_seq=1 ttl=64 time=0.487 ms
64 bytes from 192.168.33.10: icmp_seq=1 ttl=64 time=0.574 ms (DUP!)
64 bytes from 192.168.33.10: icmp_seq=2 ttl=64 time=0.544 ms
64 bytes from 192.168.33.10: icmp_seq=2 ttl=64 time=0.544 ms (DUP!)
Those
(DUP!)s mean that there is some sort of TCP error.
-
ifconfig'ed to see how the local interface was connecting to the box.
└──╼ $ifconfig
vboxnet0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.33.1 netmask 255.255.255.0 broadcast 192.168.33.255
That shows that the virtualbox router is set to the
192.168.33.1interface.
- Time to
pingthe router
└──╼ $ping 192.168.33.1
PING 192.168.33.1 (192.168.33.1) 56(84) bytes of data.
64 bytes from 192.168.33.1: icmp_seq=1 ttl=64 time=0.108 ms
64 bytes from 192.168.33.1: icmp_seq=2 ttl=64 time=0.125 ms
64 bytes from 192.168.33.1: icmp_seq=3 ttl=64 time=0.112 ms
Looked good because we see those time it takes for the ping to return
-
curlthe page and see what comes back
└──╼ $curl 192.168.33.10:80
curl: (56) Recv failure: Connection reset by peer
curl sends out a general GET http request and we are getting a
Connection reseterror. This reinforces the idea that it may be a TCP error. TCP sends packets in order and if packets are out of order or damaged then TCP will complain and we'll see something like this where the connection will shutdown.
- Check the routing table with
route -n
└──╼ $route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.0.1 0.0.0.0 UG 600 0 0 wlan0
10.0.0.0 0.0.0.0 255.255.0.0 U 600 0 0 wlan0
192.168.33.0 0.0.0.0 255.255.255.0 U 0 0 0 vboxnet0
We are checking to see if there is some type of routing loop. But it was a long shot. Everything seemed to check out.
We went through and looked at all of the previous commands that I had run grep'ping for anything mentioning Vagrant. Also we went onto the box to check out routing from that side and listing interfaces. After listing all of these things it started to magically work.
Well that's not the answer we wanted. We wanted to know what broke. Chalking it up to magic I thanked him for his trouble and went back to learning Vagrant and Scotch Box.
Later that day I started having the same problem. I left work and thought about it for a while. His hunch that it was a networking issue pointed me towards attacking the problem from the angle that my host was having issues connecting as opposed to Vagrant having issues.
The Answer
Another message I got when I did vagrant up:
==> default: Fixed port collision for 22 => 2222. Now on port 2201.
In my opinion this does not look like an error or a warning. It just looks like something that happened and isn't a problem. I Googled "how to check for running processes" and found sudo lsof -i -P -n. I found that there were in fact 2 separate processes listening to those ports 2222 and 2201. So all I had to do was kill the first process and reload Vagrant and everything ended up working beautifully.
I told you all of that to tell you this
I don't know how long it would have taken me to learn Vagrant by diving straight into the docs. I don't know if I would have ever felt comfortable with a virtual machine that I set up. I think it is so important for devs to learn dev adjacent skill sets. I didn't think that Scotch Box was going to help me get comfortable with Vagrant, VirtualBox, and virtual machines in general. This was such an awesome experience and can't wait to continue working with these technologies and continue to grow.
Top comments (3)
Knowing how to setup your coding environment is as important as knowing how to code. We actually use Vagrant at work to host our code base locally on our machines instead of having to install MAMP.
And it is actually really important to know how to setup because not everybody gets to work in a company where someone will help them do this at first, or even might go freelancing so they need to know this.
Why learning to setup vagrant when there's docker out there?
Great question, I came to Vagrant as the answer because I need to teach LAMP stack and actually spinning up fully fledged virtual machines and file systems fulfills that requirement. Also, Without knowing either it is my assumption that getting Vagrant to work vs. Docker would be a much faster process. I'm very impressionable and open to suggestion.