Notes in the vicinity of installing docker on our vultr server

@Lainewyne and I did a bit of co-working yesterday to help me better understand how our new Vultr server is configured at the operating-system level. Laine (as current Web Administrator) has chosen Ubuntu as the operating system; Vultr defaults to providing root-level access, but I would encourage us to create accounts for administrative access which are each in the sudo group. I think we (i.e. Website Circle) still need to discuss a scheme for maintaining this new server (e.g. managing backups and software updates).

My driving interest in learning more about how the server is configured was in order to migrate our Discourse instances over to that server. The only officially-supported installs of Discourse use Docker (and we use Docker on our current DigitalOcean droplet), so I have newly installed Docker on the production Vultr server. I closely followed the instructions provided by Docker for installing it on Ubuntu.

The next step of the plan is to actually install and migrate the staging forum. Laine has decided to use Webinoly for NGINX (the web server software) configuration, and I learned that Webinoly does support setting up reverse proxy configuration (see the -proxy option), which I intend to use for this case. And, as a reminder to myself and anyone else reading this far, we currently use Cloudflare as our DNS registrar.

Another element of administering our own server is keeping track of (and potentially backing up) changes to our server configuration files. I talked with Laine about this, and we decided to use etckeeper to help with this process. This is a wrapper around git, so we can use git commands to inspect and work with the developing history of our configuration files (in the /etc directory). If you want to see what has changed in the git logs, I recommend either $ sudo git log --compact-summary or $ sudo git log --name-only in order to see the files associated with each commit. Currently, etckeeper is configured to automatically (with a cron job) commit any outstanding changes in /etc.

(In the process of all of this, I also discovered a small bug with etckeeper, and submitted a fix for it.)