Striker currently uses scap3 and a relatively elaborate process for preparing the deployment repository to ship code to production. This system was largely copied from deployment tooling for ORES. It is functional, but also complicated and occasionally fragile.
Toolhub is using a newer deployment process based on PipelineLib. This process creates and publishes container images as a post-merge CI step. These images can then be used in the production Kubernetes cluster and elsewhere to deploy the application.
Discussion with @Andrew has revealed that he is willing to allow some experimentation with running Striker as a container on the labweb* production hosts. We are not seeking to deploy into the production Kubernetes cluster at this point.
[x] Add pipelinelib config to Striker
[x] Switch tests to pipelinelib
[x] Rebuild demo environment with Docker
[x] Provision Docker container on {cloud,lab}web* hosts
[x] Ensure error pages, favicon, robots.txt are served from the container
[x] Open firewall for port 8080 on {cloud,lab}web* hosts (but also not needed and should be reverted)
[x] Point CDN at port 8080 container (at local envoy layer)
[] Remove uwsgi version of Striker from {cloud,lab}web* hosts
[] Remove striker from scap3 config