Speckle Server 2.0 dev deployment

To start a discussion on this, I’ve added my insigts to the question:

To make deployment and development significantly simpler, there should be a single command that with only providing environment variables starts up all the components and configures a fully functional SpeckleServer.

Additionally automatic HTTPS & TLS with auto renewing certs makes things production ready.

Problem definition

This document details a plan to add a fully automated OCI container based runtime to the 2.0 Speckle server. Automatically running all the components together or only parts (for development) is the task. The server consist of 4 distinct parts, frontend, backend, persistent storage and cache.

Frontend

The frontend is a static vue application. This means, that the artifacts of a production build are a set of html js and css files, that can directly be served to web clients without any server side processing.

Currently the backend nodejs server is responsible for serving these files (but it is not strictly required, the frontend may be served from anywhere as long as it is able to talk to the backend).

With the current setup of the backend server serving the static files of the fronted, it is not required to create a separate container for the frontend. Only the build artifacts are needed to be copied into the backend server container.

Backend

The backend is a nodejs express application. This application provides an auth application, a rest api for the connectors to talk to the server, a graphql api for frontend applications to querry data, and serves the static frontend application.

What else is needed here?

Persistent storage

The data storage layer for the server is a Postgresql database. Currently there is a need for one SpeckleDev database and a user that has table creation and alteration rights in the DB (it should not be the root user in the db).

Currently the tables and relationships are created by knex database migrations, which should stay that way.

The missing piece on the DB side is the automated creation of an application database and db user

with proper permissions.

For development purposes a database admin tool is also helpful to get a full dev env up and running.

Cache

Currently cache is used for auth session data storage.

Only session secret is used to authenticate? Should there be more steps to make Redis production ready and safe?

Reverse proxy

From the services above only 2 should be publicly accessible, the backend api and the frontend app. These public resources should also have automatic tls cert handling (its 2021).

This should be handled by a reverse proxy.

Proposed solution

Overview

Today the industry is heading into a cloud native future, where everything is ran either serverless, managed or in an OCI container.

For development pruposes and some (if not all) production deployment cases a fully container based solution should be preffered.

Running Postgres on windows is a pain, WSL2 is widely available. With a good guide, I think anyone can get a local environment with docker up and running.

Possible exceptions from this is a managed database instance and a statically server frontend from some an edge/cdn hosting provider.

There is a solution that ties all requirements together with a stack:

• Node/express app in docker container serving frontend and backend
• Postgres running in a docker container with an attached volume on the host for safe backup.
• Redis in container is a no brainer
• Traefik for reverse proxy, works well with docker compose and has 0 config tls certs.
• Docker compose for tying all services together
• Configuration of environment with .env file

Many of the pieces are present in the current state of server 2.0, these are the missing tasks:

Nodejs app

1. The container build definition (Dockerfile) is currently not developet for the 2.0 server.
2. The express app must not be ran by the container root user, to avoid root user exploits. This can be done by adding a user with limited permissions in the Dockerfile and switching to that user after build steps are defined (Pretty straight forward). For nodejs it seams to be the consensus when using the official base image is to use the node user provided in the base image to run the application.
3. Use a multi stage build to ensure small final container size.
4. Production build configuration for lerna managed apps?

Postgres

For most usecases connecting to a hosted database is the preffered deployment. So connecting to a Postgres instance by using environment variables to configure the db connection string is the baseline. To make things a bit more flexible, the connection string should be built up from a few separate env variables, like BD_URL, DB_USER, DB_PASSWORD. With these variables separate connecting to a hosted instance or bootstrapping a complete local environment is only a question of configuration.

Creating a db container is fairly straight forward, there are some missing automation pieces. These have to be planned out a bit:

1. Root user configuration with env variables
2. Automatic database creation script
3. Automatic application user creation based on environment variables

Maybe something like this. Issue here, is that the sql files have to be present on the host OS to be mountable. This means cloning the repos to some degree. I’d preffer some sort of env variable based solution. This could even be a custom speckle container image of Postgres hosted on docker hub…

Postgres admin

To enable easy database administration the official Postgres admin should also be part of initial environment setup. It also has an official container image. This is a question of habit tough, many people would use some sort of db management application, but giving a good default solution out of the box is a good experience.

Redis

Quite good prod ready redis docs here. Note the separate docker network between the cache and the components that need to talk to the cache.

Docker compose

Why use docker compose?

• Works well with .env files
• For fairly simple apps like Speckle Server it is robust enough to provide a lot of functionality and not too complicated.
• Works well for production deployment and dev environment too.

Traefik

Basically adding traefik as reverse proxy is done in docker compose. Good docs.

[FerdiMeijer]

@gjedlicska here is the link to the public repo https://dev.azure.com/ferdimeijer/_git/SpeckleServer let me know if it doesn’t work

[gjedlicska]

@didimitrie I’ve added a WIP PR that solves the core problem. A bit of feedback would be appreciated when you have a chance.