Set up containerized version of app

[maxachis]

Context

While running development, we run into some issues because often our hardware and setup does not perfectly mirror the setup we'll see when we deploy the app on Digital Ocean. The way to resolve that is to create a containerized version of the app, probably using Docker containers, which can provide a single source of truth for the operation of the app.

Requirements

• Determine how to properly set up a docker container for the web app
• Determine how to properly link up the docker container so that it deploys as expected on Digital Ocean.
• Then implement both
• Ensure runtime logs still print from container in Digital Ocean.

Tests

• Anything we should test for? How should it be tested?

Docs

• What docs should be updated? Link to related docs changes in the PR.

Open questions

• Any uncertainties? Anything we're flexible about?

[maxachis]

Resources

• How To Dockerize A Flask App

[maxachis]

Outstanding Questions

• Should we update the GitHub action to somehow start up the docker container and then run the tests through that? Or is the fact that it's already in a GitHub action be sufficient containerization?
• Will we need to update the README to provide instructions on how to run the docker image? I assume yes.
• Relatedly, running things from the Flask App will require some additional configuration at least in running the docker image, such as adding -p 5000:5000 or whatever the port mapping is. Unsure how best to provide those
• How will running on Digital Ocean change as a result of this? Especially once we include the Frontend Client?

[joshuagraber]

Will we need to update the README to provide instructions on how to run the docker image? I assume yes.

Nod.

Should we update the GitHub action to somehow start up the docker container and then run the tests through that? Or is the fact that it's already in a GitHub action be sufficient containerization?

Good question. My initial impulse is to use the dockerfile everywhere, just for consistency's sake. But I don't know how that works in the context of automation runners.

Relatedly, running things from the Flask App will require some additional configuration at least in running the docker image, such as adding -p 5000:5000 or whatever the port mapping is. Unsure how best to provide those

Are you talking about the reverse proxying that DO does under the hood? I'm sure someone has solved for this before.

How will running on Digital Ocean change as a result of this? Especially once we include the Frontend Client?

The client should have no problem adapting to this strategy. I can do a bit of research on that.

[josh-chamberlain]

Should we update the GitHub action to somehow start up the docker container and then run the tests through that? Or is the fact that it's already in a GitHub action be sufficient containerization?

Good question. My initial impulse is to use the dockerfile everywhere, just for consistency's sake. But I don't know how that works in the context of automation runners.

Using the docker container for tests makes intuitive sense to me—to replicate the environment. I'm not sure how much it really matters.

[maxachis]

A container for the API has been set up in the repository and integrated into data-sources-v2-dev, per the work done in #584

Still would need integration into production, however.

[maxachis]

One unexpected component of containerization is that we don't have direct access to the runtime logs generated within the container now. So we can't see logs of requests being made, which would put us at a disadvantage when it comes to diagnosing a problem.

We'll want to figure out how to solve for that problem. I submitted a ticket for this to Digital Ocean support: (#10092070)

[josh-chamberlain]

@maxachis am I correct in interpreting this as the same as the log forwarding we set up in Digital Ocean? I'm sure other folks are sending logs to papertrail with our exact setup. https://www.papertrail.com/help/configuring-centralized-logging-from-docker/