Welcome back to This Old Box! A series where I chronicle the journey of building a web server out of an old 2014 Mac mini. My son and I both have web applications that are running on various platforms, and we want to learn more about how to set up the infrastructure to serve those applications.
In our previous posts we initialized our machine and set up a KVM switch to share hardware--keyboard, mouse, and monitor--with my newer Mac mini that is the current family machine.
Homebrew
In this post we're going to prepare the software to run our web server. As is the case when I set up most Macs, my first install is the Homebrew package manager. They have instructions on their site for how to install, and once you have Homebrew set up most of the rest of your software can be installed with a brew install <package_name> in your Terminal. With the exception of our next piece of software.
Docker Desktop
I've dabbled with containers and Kubernetes in the past, but have never run anything in a production environment. Since my container experience has been with Docker we're going to install Docker Desktop. It's the only option for installing Docker on a Mac. And, there's an option to also enable Kubernetes.
GitLab Setup
The code for my son's projects is in GitLab. Our next step was to generate SSH keys to securely work interact with his repositories.
To set the keys for your account you'll go to the User Settings / Edit Profile page. I found it by selecting my profile image in the left sidebar, and then clicking on my name at the top. This got me to User Settings. On that page you'll see the Edit Profile button on the right side of the header. Then, on the Profile page, you'll see the SSH Keys option on the left sidebar.
If you're new to SSH keys, or just need a refresher, GitLab provides a great resource called Use SSH Keys to Communicate with GitLab.
With our SSH keys in place we were ready to clone my son's projects onto our machine. We wanted to be fancy and perform the cloning using the Terminal. To clone a repo you use the following command in the directory where you want the code to live:
git clone git@gitlab.com:account_name/repo_name.git
On the topic of directory structure we've kept our server very basic. To keep with Mac conventions we decided to keep all our files in the ~/Documents folder. For my son's projects we're going to be running the infrastructure with Kubernetes, so we named the directory for all his code phippy. With code cloned to our machine we wanted to have just a single GUI-based code editor. We chose VS Code.
VS Code
We wanted this machine to be as lean as possible. There is only so much memory and processing power to go around. Remember, our machine has 3 GHz Dual-Core Intel Core i7 processor with 16 GB 1600 MHz DDR3 memory. We also wanted as much of that space and power to be used for serving up our web applications. However, we also wanted to have an additional option for editing any code files, in addition to vim.
VS Code has been my defacto GUI code editor for years, mainly because Microsoft has really nailed the lean part right when it comes to this application. It runs quite smoothly and efficiently.
In addition to installing the main application, we also enabled the VS Code CLI. This allows us to have more control with how we open VS Code. We can open files or whole directories through the CLI options. It's how I usually open my VS Code sessions on every machine I use.
Those are the applications we initially installed to get our projects running. We may install more in the future, but up until now this is the application stack we wanted to use.
In our next post we go over how we created our containers, configured our Kubernetes cluster, and exposed our web applications to the world.
Top comments (0)