Fixes #2 how to serve static assets

[mostlygeek]

@chuckharmston r? please @lmorchard r? as well since this will also affect TestPilot

This is the initial draft on how Dockerflow application should serve static assets. TL;DR: from the application and cached with a reverse proxy for performance.

[lmorchard]

This sounds good to me, especially since it's how we're already doing it on Test Pilot - except for the bit about source files in .dockerignore, which also sounds good but we're not doing it yet.

FWIW, we're using a package called Whitenoise, which claims to be very fast & efficient at serving up static assets from a Python app. If we need better performance than what it offers, we can look into using it as origin for a CDN. So, I think we're on the same page.

[chuckharmston]

This covers some use cases (such as ours) fine, but if we're looking to standardize this across cloudops, I think additional options will be required. Two possibilities:

• Allow application developers to create additional static file containers that use nginx as a reverse proxy, similar to our compose setup.
• A build process that includes compiling static files to a predetermined directory and pushing them to S3.

[lmorchard]

A build process that includes compiling static files to a predetermined directory and pushing them to S3.

I'd actively discourage this as a way to deploy static assets that are tied to a server-side app encapsulated as a Docker container. It adds more artifacts in different places to be managed on build & deployment. If you need better performance, then a proxy with a flushable / expirable cache would be easier to manage than an S3 bucket IMO.

[mostlygeek]

This covers some use cases (such as ours) fine, but if we're looking to...

Good points. I think I will change the recommendation so serving from the app is the first choice however the hosting provider can do whatever they want, like copy out assets. Though it is a discouraged it will open the door for very specific custom use cases.