Brian Bancroft

Tegola Part 2: Deploying an MVT Server

20 August, 2018 | Tutorial

Before we start,

If you want to run with this tutorial hands-on, you should spend a bit of time with Part 1. This will give you enough background to get started with part 2. Plus you get to learn how to build your first MVT Server from scratch! What’s not to love?

Putting Tegola Online using AWS

In the last article, we learned how to build a Mapbox Vector Tile (MVT) server using Tegola. But in order to move to greatness, we need to be able to take this from your local machine and up on a server. A big problem, right?

Well. Not for a few years, thanks to the the power of The Cloud™️. As of 2018, we have no shortage of competing services that want to sell you their servers, and have been built to get your servers to you as easilly as possible. And we will be using the Cloud, specifically Amazon’s offering: Amazon Web Services (AWS). In the AWS portal, we will be using the following services in this tutorial:

  • EC2 (A Server)

  • RDS (A Database service)

  • S3 (Static file hosting, which we can use for website hosting as well!)

A note: In going forward, you’re going to need an AWS account, and a credit card. This will cost about $30/mo if you keep it running continuously.

Build the Database

First, we’re going to need to go back to the SQL Dump I’ve created for part 1. Make sure you still have that.

Find RDS Service and Choose your Database

From inside the AWS Console, type ‘rds’ in the searchbar at the top of the page. You should see the following:

AWS Dropdown

Go into RDS from there. At this time, we’re not going to launch an aurora instance. That will be a bit too expensive for our purposes, but is really useful for databases in production for companies with budgets. Instead, scroll down until you find a button that says “Create Database”. Click it.

AWS Select DB

You should see a selection page that includes a selection of DB instances which you can use to create a new DB. Select our databae, (Postgres), and click on the “Next” button at the bottom of the page. Next, our use-case is Dev/Testing.

Select Instance Specifications

If you’re still here, good on you. There’s a lot of things we have to walk through in this portion, and the next. But this is a marketable skillset, if this is your first go. Keep it up!

For testing, we’re going to want to use to the Free tier. Selecting the box that gives us this option will take care of most of the options.

Under settings, select the following:

DB Instance Identifier: tegola-test Master Username: tegola Master Password: <You know the drill here...>

On the next pane, follow these settings: 

AWS Configure Asset

Once you’ve followed these settings, create that database. It’s a button at the bottom, again. It will take a few seconds, but once it’s up, you might have created your first database on AWS. Next, we’re going to tackle the security policy in order to expose it for use by the app as well as the command line…

Security Policy

Here, we’re going to expose the database so that it can be accessed by all types of apps.

To gain access to the security settings, go to the “Security Groups” section (usually in the second column from the left), and click on the first link you see. In the image below, it’s labelled as “rds-launch-wizard-3”:

aws-config-details

Once you’re in, you’re going to also be hit with information overload. Don’t worry, this tutorial still has you covered! In the table, click on the only row. In the lower section of the page, click on the “Inbound” tab. You should see the following:

inbound-security-settings

At this point, click “Edit”, and “Add Rule”. For type, select “PostgreSQL”. For the drop-down under source, select “Anywhere”. Click save. Now any IP can access this database.

Note: This is not something you want to do for production databases or servers. There, you want to be more particular about what you want to let in and out but because this is a tutorial about “build-your-first-…”, it’s better not to over-complicate something that’s already information-overload…

You can close the EC2 instance tab, as we won’t need it going forward in this section. Next, let’s put some stuff into the database!

Populating the Database

Okay, now that we’ve set up the database, we’re going to want to tunnel into the database, but we’re going to need the following:

  • The database endpoint

  • The username (tegola)

  • The database name

  • The password

$ > psql \ -h <DATABASE DNS ADDRESS> \ -p 5432 -U <USERNAME> <DATABASE_NAME>

You’ll be asked to enter the password. Do the thing.

Once in, the first thing you want to do is to create the postgis extension, again:

# CREATE EXTENSION postgis;

You should see a similar response as you did in part 1. Once that’s done, exit (\q), so that we can import the sql dump data into this database:

$ > psql \ -h <DATABASE DNS ADDRESS> \ -p 5432 -U <USERNAME> <DATABASE_NAME> \ < ottawa_wards.sql

Like in part 1, you’ve added the Ottawa Wards table to the database. To test, go back into the database, and run the following command:

SELECT count(*) FROM "ottawa-wards";

If you have a number of wards, then you’re in good company. With any luck, you’ve made your first DB using AWS RDS, you’ve added some data, and now you’re ready to build the server (EC2) instance.

home
portfolio
posts
contact