With the world dealing with COVID-19 by social distancing many gaming groups are left looking for ways to game while keeping their distance. This post will provide an overview for installing Foundry Virtual Tabletop, a software specifically designed to support playing table top games remotely with a group. I found this overview helpful in comparing Virtual Table Top options. One unique feature of Foundry is it uses a self hosted one time purchase model. In this post I’ll be using the same tools I’ve used in previous posts to deploy local or to the cloud provider of your choice.

Setup

Since this post is targeted at people interested in Foundry I won’t make the assumption you are familiar with Juju, Charms, or LXD. If you are you can move onto the installation steps below. For this setup I’m going to start from a clean Ubuntu Bionic (18.04) machine, if you want to follow along.

While these tools have a lot of additional configuration options I will only go over what’s necessary to get started. You can dig into more advanced networks and configuration options when/if needed at a later time.

The tools

For this guide we’ll install the software into LXD containers locally. This will let us test out Foundry and the automation tools and remove the containers when we’re done. The deployment will utilize Juju to manage the software and can be used to deploy on different environments. While we’re going to deploy locally on LXD the same tools and process can be used to deploy to a variety of cloud providers.

Setup the local environment

We’ll need LXD and Juju both of which can be installed as snaps.

# Instal snaps
sudo snap install lxd
sudo snap install juju --classic
# Setup lxd with defaults
lxd init --auto
# Verify LXD
lxc launch ubuntu:18.04
lxc list

This should install the dependencies and launch a test container. The final command lxc list should provide a table showing your new container.

+----------------+---------+------------------------+------+------------+-----------+
|      NAME      |  STATE  |        IPV4            | IPV6 |    TYPE    | SNAPSHOTS |
+----------------+---------+------------------------+------+------------+-----------+
| capital-martin | RUNNING | 10.177.243.208 (eth0)  |      | PERSISTENT | 0         |
+----------------+---------+------------------------+------+------------+-----------+

We don’t need that container it was just a test, remove it with lxc delete --force capital-martin, use the name that was generated for your container.

With LXD setup we’ll establish a local Juju environment, the processes of setting up a provider is known as bootstrapping.

juju bootstrap localhost lxd-controller

You can now check check the status of your juju environment with:

$ juju status
Model    Controller  Cloud/Region         Version  SLA          Timestamp
default  local-lxd   localhost/localhost  2.7.5    unsupported  18:38:05-05:00

Model "admin/default" is empty.

You’re all set, if you have any issues more detailed instructions are available on the juju lxd documentation.

Deploying

Let’s start by deploying a bundle which will get the install running and then review the details of what it is doing. A bundle is simply a yaml file that completely defines a set of applications and options in a single file. Create a file named bundle.yaml with the following contents in it.

series: bionic
applications:
    foundry:
        charm: cs:~pirate-charmers/foundryvtt
        num_units: 1
        options:
            proxy_port: 80
        resources:
            foundryvtt: ./foundryvtt-0.5.5.zip
    haproxy:
        charm: cs:~pirate-charmers/haproxy
        num_units: 1
relations:
- - haproxy:reverseproxy
  - foundry:reverseproxy

Foundry currently distributes the software via foundryvtt.com and requires a one time purchase. At the time of this writing it can be purchased as pre-release, with the full launch planned for 2020-05-22. You will need the Zip file for Linux be sure the file is in the same directory as the bundle.yaml and that the name of the file matches the filename shown above. If you have a newer version simply update the name for the .zip file in the bundle.yaml to match your file.

With the bundle.yaml and foundry.zip you can start the deploy:

juju deploy ./bundle.yaml

You can see the status of the install with juju status --color. I prefer to watch it for a continual update watch -c juju status --color --relations.

When the deploy is finished you’ll see a status that looks like:

Model    Controller  Cloud/Region         Version  SLA          Timestamp
default  local-lxd   localhost/localhost  2.7.5    unsupported  19:36:38-05:00

App      Version  Status  Scale  Charm       Store       Rev  OS      Notes
foundry           active      1  foundryvtt  jujucharms    4  ubuntu
haproxy  0.1.8    active      1  haproxy     jujucharms    8  ubuntu

Unit        Workload  Agent  Machine  Public address  Ports   Message
foundry/0*  active    idle   0        10.177.243.14           Unit is ready
haproxy/0*  active    idle   1        10.177.243.63   80/tcp

Machine  State    DNS            Inst id        Series  AZ  Message
0        started  10.177.243.14  juju-53a674-0  bionic      Running
1        started  10.177.243.63  juju-53a674-1  bionic      Running

Relation provider     Requirer              Interface     Type     Message
haproxy:reverseproxy  foundry:reverseproxy  reverseproxy  regular

What was deployed

This bundle deploys two pieces of software.

  • FoundryVTT - The virtual table top server
  • Haproxy - Provides reverseproxy for FoundryVTT

This closely mirrors the configuration as described for setting up an Ubuntu VM on the community Wiki. Where the instructions on the Wiki use NGINX I’m using HAProxy both serve as a reverse proxy for Foundry.

Each software that Juju deploys is controlled via a piece of software known as a Charm. The HAProxy and FoundryVTT charms are publicly available and manage the installation and operation of each of those pieces of software. In this case they handle the setup much like the Wiki. Foundry installs Node, the provided Zip file, sets up a daemon to keep it running, and registers with HAProxy.

HAProxy has been installed and sets up the reverseproxy that is requested by Foundry. This is done via a relation which is shown at the bottom of the bundle. The relation is a known connection point between charms, in this case it’s named reverseproxy and we’ve connected Foundry to HAProxy as they both support the relation type.

In the juju status output you’ll see a table with a section for App, Unit, Machine, and Relation. Apps are the charms that are in the environment and tells you where it was installed from (jujucharms) and the Revision. Units are an actual instance of the application. In this case ‘foundry/0’ and ‘haproxy/0’. The Units tell you the IP address they currently have, what machine they are on, and some status about the unit. Machines are a list of all machines in an environment where machines can be bare metal, containers, virtual machines, etc. Machines aren’t terribly interesting here, but on a cloud provider you might install multiple units on a single virtual machine. Finally, a table of relations tells you which relations currently exist, there is one as discussed above between haproxy and foundry.

Accessing Foundry

With the deployment settled and all units showing active/idle we can access foundry. From the status above we’ll use the IP Address for HAProxy and the subdomain ‘foundry’ which is the default set on the foundry charm. Open a browser to http://foundry.10.177.243.63.xip.io and you should be greeted with the Activation Screen.

Foundry Registration

The use of xip.io is a convenience domain that lets us use an IP address like a domain name.

You can log into HAProxy or Foundry if you like with the juju ssh command. Also of interest is juju scp which lets you copy files to/from machines. For example you might want to copy a file to foundry to use as the background image for a world. You can do that with juju scp ./my-awesome-background.png foundry/0 or access foundry to see logs juju ssh foundry/0. If you do put files on Foundry you’ll find the data path the charm uses is /opt/foundry/userdata.

As I continue to update the Foundry charm additional actions for operating the software may become available. Charms can be upgraded with juju upgrade-charm command allowing you to pull in any fixes or changes. If you find bugs or features that should be part of the charm you can file them on the github page for the charm. Additionally, I idle on the Foundry Discord server with the user name Zarek if you want to ping me on the #installation-support channel.

Cleaning up

When you’re done and want to remove the containers you can remove the model with all the applications and machines and reset to a new clean default model with the command juju destroy-model -y default && juju add-model default

From here you can redeploy with the same or new configurations if you like.

Production use

With Juju you can target several cloud providers to deploy your software onto. With the same charms shown here you can deploy to whichever provider you prefer. For self hosing in a lab environment the LXD or MAAS providers allow you to deploy to either containers or bare metal machines of your choosing. I’ve run labs hosted on a single machine as LXD containers as well as a multi-machine lab deployed with MAAS.

By default if the option proxy_port is not set it will use 443 to provide a secure connection. The details of setting up HAProxy with Letsencrypt are beyond the scope of this post but it is supported by the charm and an example of setting it up can be seen in the previous blog post about bundle weechat. In that post, HAProxy was also used, and the section Accessing weechat via relay walks through the use of ddclient and HAProxy to setup a domain and Letsencrypt. As mentioned before feel free to ask questions via Discord if you are ready to plan a roll out to a cloud provider or hardware in your lab. Additionally, the weechat post demonstrates installing multiple charms on a single host with HAProxy being deployed directly to the machine and other software in a LXD Container on the machine. This same setup will let you run FoundryVTT and HAProxy on a single cloud machine.

In my experience if you deploy to a cloud provider the instance size needed to run the software is not very high. However, I’ve seen instances that die during installation due to lack of resource on small instances trying to install packages. One way to deal with that is to install with a default machine size and after it’s up and running shut the instance down and resize to a smaller instance.