|- - - - - - - - - - - - - - -|
| |-------------------------| |
| |-------------------------| |
|  / / / / / / / / / / / / /  | <-- inner margin
|                             | <-- space resulting from min-height
|- - - - - - - - - - - - - - -|
 / / / / / / / / / / / / / / / <-- margin resulting from inner margin

Install Docker

The first step is to install Docker. If you're on a Mac, Ubuntu or Windows 10 Professional, follow one of these links:

• Install on Ubuntu
• Install on Windows 10 Professional
• Install on Mac

If you're on Windows 10 Home, an earlier version of Windows or an unsupported version of Mac, try Docker Toolbox -- though your mileage may vary.

Add ~/bin to your PATH

Windows

1. Start the System Control Panel applet (Start - Settings - Control Panel - System).
2. Select the Advanced tab.
3. Click the Environment Variables button.
4. Under User Variables, select Path, then click Edit.
5. Add %USERPROFILE%\bin as an entry if it doesn't exist.

Other

Add to your .bash_profile:

1. Open terminal or bash.
2. echo "export PATH=$PATH:~/bin" >> ~/.bash_profile
3. source ~/.bash_profile

Pull the Nimble Environment

Go to your preferred location for all of your projects, and pull the Nimble repository. I prefer a spot like ~\docker on Mac or ~\Documents\docker on Windows, but it's entirely up to you!

Create a new project

Before creating a new project, open a Bash command line or alternative like Git Bash (Windows), Terminal (Mac), Bash on Ubuntu WSL (Windows) or a regular old command line (Ubuntu). Run the following command to make nimble as easy as can be:

./nimble.sh localize

Now, you can just type nimble from this location. Please note, all commands must currently be run in this directory. Keeping a command line specifically for this directory helps.

Switch the Nimble Environment to your own repo

First thing's first, delete the existing Git repository by deleting ./.git from the root folder. You can (and should!) keep the .gitignore file. Then create a Git repository either using your GUI of choice, or git init. Once created, you should set up a branch to your own repo if you plan on syncing on the web. Eventually, I'll come up with a way you can update the actual Nimble Environment, but I'd like some community feedback before I delve too far into it.

You can start up the docker containers with no projects via nimble up. For more commands, check out the Git repo

Actually create a new project

Creating a project is easy, and even interactive. Just run the command nimble create myproject, replacing myproject with whatever alphanumeric project name you would like. Nimble will ask you a few questions, notably:

• Do you want this project kept in Git?

  If so, you can this repo with other users, they can run nimble init myproject, and pull the new project you are creating

• Do you want to clone a repo?

  If this is an existing project, you can pull its repo into the sites/myproject/www folder.

• Do you want to add this project to your hosts?

  No more editing hosts files!

• Do you want to generate certificates for this site?

  Automatic (untrusted) SSL capabilities

• Do you want to install WordPress?

  It will ask you the basic questions for installing WordPress

Once installed, your project will be available at yourproject.local, with PHPMyAdmin at phpmyadmin.yourproject.local and Webgrind at webgrind.yourproject.local (to be used with nimble up profile).

Customizing your projects

Now that the framework has been laid for a basic project, here's a quick yet complicated briefer on the templates that make this possible. Each WP project is built from a template located at ./_templates/docker-wp-template.yml. This template is compiled to a respective docker-compose template responsible for the project's configuration at ./_projects/project.yml. Additionally, each project has multiple parts -- database, server, files, phpmyadmin, etc -- which extend services located at ./_templates/docker-common-template.yml.

Now, this complicated web of files needs an infographic, which I have not prepared just yet, but the flow is like this:

./_templates/docker-wp-template.yml -> creates -> ./_projects/myproject.yml -> extends -> ./_templates/docker-common-template.yml

If you want to make a change across the board, like change the version of MariaDB that is used across all of your WP projects to 10.0.30, you can go to ./_templates/docker-common-template.yml, find the wp_db service, and change image: to mariadb:10.0.30.

If you want to make this same change only for myproject, you can go to ./_projects/myproject.yml, find service myproject_db and add image: mariadb:10.0.30.

And if you want to make the same change only to new projects that are created, you can go to ./_templates/docker-wp-template.yml find PROJECT_db and add image: mariadb:10.0.30.

Now, if you run nimble up, it will whichever of the above containers you just modified and in a matter of moments, you'll be running that version of MariaDB. Of course keep in mind that if the DB data from your version is not compatible with the new version, you could end up with a corrupt database, but you hopefully have a dev database with a single source of truth for your data that you can pull from at any time.

I hope you can see how powerful it is to be able to completely change how your environments are built at any time and share those environments when collaborating. Be sure to leave some notes in the comments if you've tried it out, hated it, experienced bugs, or if it completely changed your life!

The hardest part of beginning the Docker journey was setting up the first project. There are plenty of tutorials on various websites on "Starting with Docker", that make it seem like a piece of cake. "All you have to do is docker run $image!!" they say. Well, when it comes to provisioning environments that are relatively the same, but sometimes a little different, I found it hard to grasp all the interconnected pieces at times. So in order to spare you the overwhelming feeling of not knowing which of 20 different variables could be the problem, I'm going to provide you with a basic template, biased with WordPress, that will let you see Docker in action, and give you an idea of how it can be used to provision multiple websites for a local server.

https://github.com/johnrom/nimble/

Clone it, give it a try. I recommend cloning it somewhere in your User Directory on Windows or Mac. I've never tested it with Linux, but I assume it would maybe work. This script has some basic dependencies, like basename and other things that are generally installed on all systems. Also, it's a bash script, so your terminal needs to be based off of bash.

Now, if I'm honest, even just using this script could be complex. You will need to make sure Docker is working, that the Docker VM shares the drive your files are on, and if you're on Windows, you'll have to use the C:\ drive for Windows files if you'd like the hosts functionality to work. But moving from my work computer to my home computer, it only took about 5 minutes to install Docker and clone this script, so hopefully it works that way for you as well.

If you're able to create your first site with this script, from there you can go backwards. "What if I want to use PHP 7?" Change the image of wp_site under _projects/yourproject.yml. If everything breaks, you'll know that that one change broke everything. Hopefully, you'll never have to experience putting everything together for the first time and not knowing what went wrong, where, and hopefully this can provide a new foundation on which developers can get to the code faster.

As usual, use people's scripts at your own risk, etc. If it doesn't work, create an issue on Github, but this is a personal project so my ability to maintain it depends on my workload.

Okay, that's pretty scary. I might have a pretty edge case. I run a Windows 10 host, with an Ubuntu Guest. However, all of my server files are on my Windows 10 host. So Ubuntu is actually trying to install Ghost on a shared folder mounted on my F: drive.

/srv/host/com/johnrom/test/

Setting up Ghost on a VirtualBox Shared Folder isn't simple. Basically, installing sqlite3 is impossible on a shared folder, even with symlinks enabled. This has to do with the fact that SQLite3 must be compiled by node (or node-pre-gyp, whatever that is). Then, we have to set up Forever in order to run Ghost on every boot, which also proved a bit troublesome. However, let me walk you through it!

You must have administrative privileges on your device to use this tutorial. I'll be using a Windows 10 Host with an Ubuntu Server 14.04 Guest for this tutorial.

Step 1: enable symlinks on VirtualBox

• My Virtualbox is called "Dev Server" (very unique, I know)
  I found the exact name by opening Command Prompt and typing "VBoxManage list vms"

• I call my share "projects-com" in the VirtualBox Shared Folders interface.

Given these tidbits of information, we can now enable Symlinks for this mount point by entering the following into cmd.exe (one line, even if it looks broken)

VBoxManage setextradata "Dev Server" VBoxInternal2/SharedFoldersEnableSymlinksCreate/projects-com 1

Now that we've done this, be sure to open VirtualBox as an administrator from now on. We'll make this easy by right-clicking the VirtualBox icon in the taskbar (or the shortcut on your desktop), going to properties -> compatibility, and checking "Run this program as an administrator"

Step 2: install Node and NPM

Let's get node up and running, as that is a task all on its own.

We're basically following this guide to install Node on Ubuntu 14.04. Use sudo if you aren't running as root.

sudo apt-get install --yes build-essential curl
curl -sL https://deb.nodesource.com/setup_5.x | bash -
sudo apt-get install --yes nodejs

If you don't use Ubuntu 14.04, check the compatibility list and make sure the version of node you are downloading is compatible!

I think I had to update npm to a better-supported version after installing from the repo, so let's do that.

sudo npm install -g npm@latest-2

Step 3: Install Ghost (not on your shared drive! )

We're not ready for the shared drive yet! So let's create a temporary directory and get Ghost going.

# install unzip
sudo apt-get install unzip

cd /tmp
mkdir ghost
curl -L https://ghost.org/zip/ghost-latest.zip -o ghost.zip
mkdir ghost
unzip -uo ghost.zip -d ghost
cd ghost
npm install --production

Step 4: Copy Ghost to the Shared Drive

Hopefully you made it this far. Now, we're going to copy Ghost to our Shared Driver, preserving all of the symlinks that exist among the modules Node just installed. Luckily, on Ubuntu these symlinks will be relative, and it does a great job of copying them with the following command:

sudo cp -ad . /path/to/your/document/root

Let's check and make sure Ghost doesn't crash and burn!

cd /path/to/your/document/root
npm start --production

Step 5: Running Ghost on Startup with Forever

If all went well, Ctrl+C out of npm and let's get started running Forever. Forever is a NPM service that will handle starting the server for you and running it forevever. Let's install it:

npm install -g forever

For this unique case of running Ghost on a VBoxSF shared folder, I find that shares are the happiest when you run them through /etc/rc.local, so I will assume you have read how to set up Ubuntu 14.04 on VirtualBox which covers this topic at the end.

The following technique allows Forever to run Node as the www-data user.

First, we need to make sure www-data has an accessible home directory.

sudo nano /etc/passwd

Then, we'll find the www-data user, and it should say /var/www or /home/www-data. Whichever one, we will navigate to that directory and set it up for write access for www-data (don't keep anything important in this directory! This doesn't have to be the location of your server files, it is not mine.)

sudo chown www-data:www-data /var/www # (or /home/www-data)

Now we're going to open up /etc/rc.local, and it should look like similar to the following, having replaced my shared folders with yours. Also replace /srv/host/com/ghost with the location of your ghost installation!

# temporarily set logging for this file, to debug any issues
exec 2> /tmp/rc.local.log
exec 1>&2
set -x

sudo mount -t vboxsf -o fmode=666,umask=0002,uid=www-data,gid=www-data projects-com /srv/host/com

# this is the magic
sudo -u www-data NODE_ENV=production /usr/bin/forever --sourceDir /srv/host/com/ghost start index.js

Restart the server and check /tmp/rc.local.log

sudo shutdown -r now
nano /tmp/rc.local.log

If it ends with something like the following, we're ready to move on!

info: Forever processing file: index.js
+ exit 0

Step 6: Setting up your Server

If you already know the ins and outs of Apache or NGINX, feel free to do this your own way. Just know that Ghost listens on port 2368 by default.

It is atypical, I know, but I'm going to use Apache for this part because that's how my dev server is built. If you don't have Apache yet, just run

sudo apt-get install apache2

We need to add some modules to Apache for passing the data through to our NPM server.

sudo a2enmod proxy
sudo a2enmod proxy_http

Then, we'll create a VirtualHost under /etc/apache2/sites-available/ghost.conf

nano /etc/apache2/sites-available/ghost.conf

<VirtualHost *:80>
    ServerName ghost.dev

    ProxyRequests off
    ProxyPass / http://127.0.0.1:2368/
    ProxyPassReverse / http://127.0.0.1:2368/
</VirtualHost>

Restart Apache...

sudo a2ensite ghost
sudo service apache2 restart

If Node was started correctly, Apache should now be connected to ghost at the domain ghost.dev.

Step 7: Edit your hosts file to point to your server

For this part, you will need to set up a VirtualBox Host-Only Adapter for your VM, and know the IP address of your server, which I covered in setting up Ubuntu 14.04 on VirtualBox. Mine is 192.168.56.2, so replace that with your server's IP.

On your host, run Sublime Text or your text editor of choice as an administrator. Navigate to /etc/hosts on Mac or Linux, or C:\Windows\System32\drivers\etc\hosts on Windows, and append the following line:

192.168.56.2 ghost.dev

Step 8: Enjoy the elegance that is Ghost

Fire up a browser and navigate to ghost.dev for a welcome message! That's all! That was no trouble at all, now, was it?!

If these instructions didn't work for you, feel free to leave a comment with your errors or questions. Up next, I will set up Ghost as a service so that I can quickly restart the Ghost server for development purposes.

When it comes to selecting a Linux-based web server upon which to serve your web assets, it often comes down to a single question: "Should I use NGINX or Apache?" Both are excellent web servers, and, with a little configuration, they can both generally do the same job as the other. NGINX will likely always have a slight advantage on a high-volume site with high concurrency, but a properly tuned Apache server can likely get the job done as well.

So the general answer is that it does not matter, especially for local development. If your production website runs on a specific server, I recommend using that one. To get to PHP development as fast as possible, I recommend Apache. If you want to use .htaccess files for per-directory configuration, use Apache. For local development, where requirements might change completely over the years or project to project, I recommend Apache. To have the highest concurrency -- or thousands of people using your site at once -- I recommend NGINX. The good news is, if you want the best of both worlds, you can use both! If you're interested in what each of these servers really stands for, let's go over some history.

Apache

Apache came before NGINX. It was first written in a world where the web was new, and setting up a server was no trivial task. Its focus was primarily on being a jack-of-all-trades. The impression I've gotten from Apache over the years has always been similar to that of the famous "5-minute install" from WordPress. Installation of a LAMP server (Linux, Apache, MySQL and PHP) is as simple as it gets, and for anyone who wants to get to PHP as fast as possible, I highly recommend this route.

It doesn't come without its drawbacks, though. Continuing our comparison, WordPress, as great as it is, loads a lot of functionality. If you're writing on a simple blog (like this one), that functionality may be overkill, and you may end up with a lesser performance profile than some of the more focused offerings. However, if you require a fair amount of the functionality and flexibility that WordPress provides, you will spend many hours writing a platform for that from scratch, with possibly negligible performance gains. Apache falls in the same boat, with the ability to use .htaccess files and load extra Apache modules at will (including PHP). However, for larger sites and due to the performance limitations of Apache at the time, the way was paved for a new web server.

NGINX

NGINX was built after Apache took its place as the server-du-jour for Linux. If you ran a linux server, you probably used Apache, and if you ran a Windows server, you probably used IIS. However, as the web evolved and millions of people began using the internet regularly, concurrency became a huge hurdle for Apache. At the core of Apache's functionality (now the MPM-Prefork module) was the need to spawn a process for every connection. That means every user currently browsing a given website needed a process, and processes are not cheap in terms of CPU. Large sites like social networking and news sites immediately began to feel the struggle -- this is where NGINX comes in.

In order to deal with concurrent connections in the tens of thousands, NGINX was built off of an event-loop. Basically, when many connections came in, one NGINX process would serve one connection after the other -- very quickly. Remember how Apache was a jack-of-all-trades? Each Apache process in this scenario had the capability to parse dynamic content like PHP and serve it. NGINX, on the other hand, simply passes it on to a "PHP Daemon", which is a mini server that is listening only for PHP requests. This means when NGINX responded to a request for an image, PHP was never loaded! The focus, then, for NGINX was to respond to as many requests as quickly as possible.

But what about now?

Apache has come a long way since then. It now offers different Multi-Processing Modules (MPMs) that change the way these handle requests. These MPMs are not like other Apache Modules -- they must be compiled into the server during installation. Once you've chosen an MPM, you'll have to recompile Apache in order to switch.

These modules are as follows:

• MPM-Prefork
  The same as ever. One process spawns for each request. This is the only option for using mod_php built into Apache, and is the default

• MPM-Worker
  Each process can spawn child threads, which reduces the overhead for concurrent connections. This isn't compatible with mod_php, but is mostly compatible otherwise. Each thread is left open for a connection, and will be used for loading assets and other files associated with a request.

• MPM-Event
  Similar to MPM-Worker, except it will not leave threads waiting for connections. If using SSL or other modules, it will behave like MPM-Worker. This is only stable in Apache 2.4

As you can see, MPM-Worker and MPM-Event move towards the NGINX way of processing, where each process can process multiple concurrent connections. It is not the same, nor does it necessarily outperform NGINX, but it is useful when you want to use Apache and also handle concurrency.

These are not exclusive

I think the main reason that Apache continues to flourish is its ability to use .htaccess files to modify your configuration on a per-directory basis. It's sometimes easier to manage a site's .htaccess than it is to go through Apache or NGINX configuration files. WordPress, for example, will automatically generate your .htaccess file if it has write permissions on its own files. This means (both good and bad), that WordPress plugins can modify the rewrite rules in your .htaccess. Talk about customization! NGINX, on the other hand, is against ever doing this because they love an efficient server (and who doesn't?).

In order to get the best of both worlds, you can listen for traffic with NGINX, check if a static file exists at that location, and if it doesn't -- pass the request to Apache. Apache can then read its .htaccess files, and pass that information to PHP. If a static file exists, Apache and PHP processes are never spawned, and everybody wins.

A VM is a little machine within your machine. I use it to run Ubuntu, so that I can get full access to the wonders of the Linux command line. After years of trying to use Windows and WAMP, things became a little bit too complicated using Git and SSH'ing through the Windows command prompt, installing Ruby and Node, SVN -- I can go on. Then, I had to do it all over again on other (Linux flavor) servers. Windows is Windows, and I see it as a GUI-based OS. I use it for gaming, listening to music, emailing, office, and the things the rest of the world uses it for. However, when it came to doing real power-user tasks, I found that most real-world scenarios involve Linux, so instead of learning how to do it on Windows and then learning how to do it again on Linux (because it's kind of my job to know), I decided to use Ubuntu for the techie stuff.

I experimented with dual-booting. It was OK. When I was done watching Mall Cop, I could restart my laptop, boot into Ubuntu Server, and be ready to go. But I want to be able to access my server's PHP and other files from Windows and see the result while watching movies.

I use VirtualBox because it was the first VM manager I tried, and it worked. It didn't come without its complications. For example, I cannot copy and paste to my virtual machine without using SSH because I'm using a barebones server. That's a big issue, but one I haven't quite figured out. If this is too big of an issue, you might want to install the desktop version instead -- just know it will run a bit slower. Prepare to spend an hour or two (with my help!) getting everything set up. Sometimes, this guide might produce errors because of the many dependencies that this setup requires. Let me know, and maybe I'll be able to revise this guide with more information.

Enough background, let's get started!

For this guide, I am using the following configuration. Some older version of VirtualBox are not compatible with Windows 10, but hopefully future versions will be fine. I'm using 64-bit, so hopefully all of this works if you are using a 32-bit device (just be sure to download the 32-bit versions of everything!)

Windows 10 (x64)
VirtualBox 5.0.10 r104061
Ubuntu Server 14.04.3 LTS Trusty Tahr (x64)

First download Ubuntu. While it's downloading, Download and install VirtualBox, then download and install the VirtualBox Extension Pack. When your Ubuntu download is complete, open VirtualBox. Go to Preferences -> Network and add a NAT network with the default settings. Under Host-only Networks, edit the settings of your Host-Only Adapter, make sure it is 192.168.56.1, then switch over to "DHCP Server" and uncheck the box to disable it. Click "New" in the top left. Name your server, type: Linux, version: Ubuntu (64-bit). I have 8GB ram, so I usually give it 1024MB (1GB). Create a virtual hard disk (VDI). Since I'm on a solid state drive and for the purposes of this tutorial, I'll be using a fixed size disk. My actual server is dynamically allocated though, because it occasionally needs more space and was created before switching to an SSD.

Once it completes, select your new server and click "Settings". Go to Storage, click "Controller: IDE", and under Attributes click the disc -> "choose optical disk file". Find the Ubuntu ISO you just downloaded. If you're on a solid state drive, click the first Controller: SATA, and under attributes check Solid-State Drive.

Now, go under Network and make sure Adapter 1 has "Enable Network Adapter" checked, attached to NAT. After that, we're ready to get started! Click Start, and the VM should automatically boot from the ISO we added to the first IDE controller. Go through selecting language, etc, and the VM will load the additional components needed to install Ubuntu. I leave all of these options up to you -- I just run the defaults. Eventually, you will come to the Partition disk option. I am not using LVM for this particular instance, but it can come in handy, especially if you chose a Dynamically Allocated Disk at the beginning. Learn more about it here. I leave everything else default, and don't install any software -- we'll do that next!

Once your server restarts, it'll boot into Ubuntu and we'll be able to...

Install VirtualBox Guest Additions

Since we have NAT enabled, we should be able to access the internet from Ubuntu. You'll obviously need an internet connection for this next part. Let's update our repos and install guest additions. If you're on Ubuntu Desktop, open a Terminal now (and never close it!). Using 14.04.3, installing VBox Guest Additions was (thank golly) as simple as:

sudo apt-get update
sudo apt-get install virtualbox-guest-x11

As of this moment, you should have the capacity to share copy and paste between Ubuntu and Windows if you are on Ubuntu Desktop by clicking "Devices -> Shared Clipboard -> Bidirectional" in the VBox window. However, it doesn't help Ubuntu Server users, because we're using the basic terminal which has no mouse support. I never figured out the copy-paste situation. You can try installing GPM for a mouse-cursor, install Gnome or use X11... but every time I try it, it bothers me and I remove it. If anybody knows how to get a mouseable, copy-and-pasteable terminal without installing an entire desktop, feel free to let me know and I'll add it to the guide!

Configure a Host-only Network

Now, we have to add a Network Adapter to Ubuntu to provide a host-only interface, and connect it with our host's host-only network adapter. This allows us to ping "192.168.56.2" from the host, and reach the guest. Which means, eventually, we will be able to point domains to it in our HOSTS file, and reach our server files.

In VirtualBox, go to Preferences -> Network and add a NAT network with the default settings (if it isn't there already). Under Host-only Networks, edit the settings of your Host-Only Adapter, make sure it is 192.168.56.1, then switch over to "DHCP Server" and uncheck the box to disable it because we'll configure static IP addresses in a minute.

In your VM, we'll edit the network interfaces file.

sudo nano /etc/network/interfaces

In this file, you should see an eth0 and a loopback adapter. Update this file to look like this:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp

# Host Only Config
auto eth1
iface eth1 inet static
address 192.168.56.2
netmask 255.255.255.0

When you're done, restart your VM. Now your Windows Host-only adapter will have the IP address 192.168.56.1, your VM will have the IP address 192.168.56.2 and, in Windows, you should be able to ping 192.168.56.2 in a Command Prompt. If you receive messages like "Reply from 192.168.56.2", everything is working!

Add shared folders between Windows and Ubuntu

The coolest part of this setup is the ability to fully utilize Ubuntu, while being able to edit server files on Windows. I highly recommending using a separate partition, or even better a separate drive, to host your server files, so that Ubuntu has no chance of corrupting your Windows partition. This works for me, since I always use 100GB for Windows and the rest of a drive for a data (F:) partition, where I move my Libraries such as Pictures, Music, etc.

Once you've decided where your server files will live, go to Machine -> Settings -> Shared Folders. Click the Add button to the right, and select the path to your shared folder -- it's okay if there's nothing in there at this point. For the "folder name" option, name it something memorable like "projects". Do not check any of the boxes -- we will handle this manually.

To mount the shared folders, we'll use the rc.local file. This is a file that runs scripts at the end of the boot process, or the beginning of login, one or the other. /etc/fstab is usually used to mount drives, but this is conveniently located before VirtualBox loads its VBoxSF service. I've read articles stating it's not correct to use the rc.local file for this purpose -- this is a dev server. I've never had a problem. We're going to use rc.local to manually mount our vboxsf share with the user and group www-data.

First let's create a directory. I like using /srv/host for my server files located on the host machine.

sudo mkdir /srv/host

sudo nano /etc/rc.local

We're also going to enable a log file at /tmp/rc.local.log so that we can see immediately if something goes horribly wrong.

#!/bin/sh -e
#
# rc.local
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

exec 2> /tmp/rc.local.log
exec 1>&2
set -x

sudo mount -t vboxsf -o fmode=666,umask=0002,uid=www-data,gid=www-data projects /srv/host

exit 0

Do a restart, and we'll see how it worked! Create a file in your projects directory in Windows, so you can confirm.

sudo shutdown -r now

ll /srv/host

If you see your file(s) here, then we are ready to go! You have successfully installed a VirtualBox VM and are ready to plunge deeper. Next steps, we are going to install Apache or NGINX (todo: links), MySQL, PHP, Ruby, Node.JS, whatever you're into! Look for these guides over the next few weeks, or jump ahead now and find those resources online!