paint-brush
The Fullest Stack Rideby@RalphUtz
685 reads
685 reads

The Fullest Stack Ride

by Ralph UtzMay 17th, 2017
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

<em>*If you missed the intro story with the high level overview of what we’re building you can find it </em><a href="https://medium.com/@RalphUtz/we-apologize-for-the-slight-delay-de91c6385d6b" target="_blank"><em>here</em></a><em>.</em>

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - The Fullest Stack Ride
Ralph Utz HackerNoon profile picture

Phase 1 — Planning — Server Architecture

*If you missed the intro story with the high level overview of what we’re building you can find it here.

“a journey of a thousand miles begins with a single step” — Laozi

And our first step is to provide compute, storage, and network. Let’s begin.

Compute — We’re using the Raspberry Pi platform for our compute needs. We’ll run a Raspberry Pi 3 Model B with four Raspberry Pi Zero Ws. You can use as little as two Pis of any flavor if you so choose, although it does get interesting with more hosts when we start clustering and load balancing. Also, I’m using wireless for my network so you’ll need to make the appropriate adjustments if you have non wireless Pis. We’ll run Raspbian as the OS and lean on Docker Swarm for clustering.

Storage — I’m going with these cards for local Pi storage. Any brand will work so long as you’re using something fast enough(Class 10). We’ll hang a USB drive off our wireless router for a poor man’s NAS so we have some persistent storage for our containers.

Network — Wires? Where we’re going, we don’t need wires. Wireless it is, 802.11n specifically. I chose the Linksys AC1750 for this for two reasons. First, Amazon had a great price on them. Second, it supports DD-WRT and has a USB(read: NAS) port on it.

Phase 1 — Doing — Server Architecture

First things’ first. We need to stand up our compute and local storage. I’m using a Windows 10 laptop for this because it’s what I have laying around and I only ever see tutorials of this type from a Linux perspective.

You’ll want to install Etcher, then we’ll use it to flash Raspbian Jessie Lite on our micro SD cards. The whole process was point and click for me, but if you run into problems there’s an install guide on the Pi website.

After Etcher finishes up, go ahead and drop a file with no extension named “ssh” on the root of the SD card to enable SSH temporarily. SSH is disabled by default on Raspbian and once we get into our install we’ll want to enable SSH permanently. Our local storage is now prepped and ready to be inserted into the Pi.

Time now for compute. Grab a network cable and connect the ethernet port on the Pi to the ethernet port on your laptop. On boot, the Pi will look to a DHCP server for it’s IP address. I used tftpd64 from Jounin to run a local DHCP server on my laptop. For some reason chrome’s safe browsing was alerting on the domain for tftpd. You are free to use whatever means you want to provide DHCP to your Pi. Setup your DHCP server by specifying which network interface you want it to run on, define your pool, and setup your DHCP options to hand out a subnet mask and default router.

My tftpd settings

Make sure you’ve inserted your SD card and then apply power to the Pi and watch your DHCP server log. The log will tell you when your Pi has pulled an address and which address it pulled.

Here we see that the Pi has pulled IP address 10.3.3.50

We’ll need an SSH client to communicate with the Pi. My personal fave is putty. Grab a copy of it and put it somewhere that’s easy to remember. Open a command prompt and start off by pinging the Pi to ensure we’ve got good communication.

If you get something other than replies you can reference this to figure out what your error means. A few things I would check first would be:

  1. Does the Pi have power?
  2. Is the ethernet cable plugged in securely to your computer/Pi?
  3. Do you have link lights (yellow/green) on the Pi?
  4. Did you see the Pi grab an IP address from your DHCP server?

Depending on the laptop you are using, you may need to use an ethernet crossover cable. Instead of the cable, you can insert a cheap switch between your Pi and laptop.

Moving on. SSH to the Pi and we’ll finish setting up the OS.

>c:\putty.exe -ssh [email protected]

I placed my putty executable on the root of my C drive. The default username for the Pi is… **pi**. Accept the security cert and use **raspberry** as the password. You are rewarded with a friendly shell.

pi@raspberrypi:~ $

Use [sudo raspi-config](https://www.raspberrypi.org/documentation/configuration/raspi-config.md) and do the following:

  • Enable SSH permanently by going to Interfacing Options -> SSH
  • Change user password
  • Change hostname
  • Expand the file system which is now under Advanced Options

Make sure each of your Pis has a different hostname. I’m going headless (no monitor) on all my Pis so I also go into Advanced Options and change the Memory Split to 16 since I’m not using the GPU. Compute is now complete.

Network is the last leg of our foundation’s triangle. We’ll configure our wireless and slough off our Cat5e shackles.

*Side Note* In any type of scenario where I was responsible for supporting this monstrosity, I would use a physical network. I’m going wireless with this build because all the guts are on my desk and I’m trying to keep the clutter to a minimum.

I’m not going into the specifics on how to configure every wireless model device out there, but suffice it to say that you need to setup an SSID and give it a password of at least 8 characters. I use WPA2 Personal for security. I configured my SSID to be **piparty** and my password as **turtletime** on my wireless router. I’m also using the wireless router as a DHCP server for the wireless network. You should do the same.

Back at the Pi command line, I fire off a quick scan to be sure everything is in working order with my wireless and after seeing **piparty** listed I know I’m ready to configure my Pi as a client.

I enter the **wpa_passphrase** command giving it the wireless SSID and then the password when it prompts me for it.

We’ve now generated our WPA PSK and need to configure the WPA supplicant to connect to our wireless network by modifying the config file located at /etc/wpa_supplicant/wpa_supplicant.conf with nano.

sudo nano /etc/wpa_supplicant/wpa_supplicant.conf

At the bottom of the file you need to add your network information from earlier. Here’s mine as an example:

Don’t forget the closing bracket on the network statement!

Save the file and get out of nano by pressing **CTRL+X**, then **Y**, then **Enter**. Reload your wpa supplicant configuration with **sudo wpa_cli reconfigure**. Take a look at the wlan0 interface and see that you’ve acquired an IP address from your wireless router.

inet addr:192.168.1.105 = Success

From the image above we see that my Pi has received the first available IP address from the DHCP server running on my wireless router. Eureka! If you’re unsuccessful, you can find more detailed information on configuring wireless for you Pi here.

Follow these steps for each Pi that will be in your cluster. When you finish you should be able to ping each Pi from any device connected to your wireless network.

* Shortcut for your following Pis — — — — — — — — — — — — — — — — — — Open the _wpa_supplicant.conf_ file on your working Pi with the following command:

sudo nano /etc/wpa_supplicant/wpa_supplicant.conf

Copy the contents of the file and paste it into a new file on your laptop/workstation and name it _wpa_supplicant.conf_. On future Pis, place a copy of the newly created _wpa_supplicant.conf_ on the root of the SD card (in the same place you put the empty “ssh” file earlier). On boot, your new Pi will automatically connect to your wireless network and you can SSH and continue with the process above. This saves you the trouble of physically connecting each Pi to your laptop for it’s initial wireless configuration.

To recap:

  • We built individual physical servers
  • We provisioned our local storage
  • We networked our servers and tested connectivity

We now have a foundation to build upon. In each installment we will add new functionality until we’ve built a suitable throne for our application to call home.

In our next installment we’ll lay the ground work for our app to be cloud native, which is a fancy way of saying we’ll get Docker up and operational.

Leave suggestions, comments, and questions below.