Use uWSGI to serve the app in production

[mars-f]

Run the lando-api application under uWSGI.

To build and run the production image locally add the following to docker-compose.override.yml:

version: '2'
services:
  lando-api:
    build:
      context: ./
      dockerfile: ./docker/Dockerfile-prod
    ports:
      - "9000:9000"
    environment:
      - UWSGI_WORKERS=1
      - UWSGI_SOCKET=:9001
      - UWSGI_HTTP=:9000

[purelogiq]

I tested it and it worked, but, only after a bit of wrangling!

[purelogiq]

Some of our invoke commands (specifically the ones that create the database) stopped working with the addition of these changes. I tracked this down to the Dockerfile-prod (since when editing the docker-compose.overrides.yml` file that it what it uses as the context for all invoke commands). The removal of

WORKDIR /app
RUN cd / && pip install --no-cache /app

is what causes these changes.

We either need to re-add them, or we need to 1) confirm that the production environment doesn't need them and 2) confirm that the our circle.yml (which runs our invoke commands for production, doesn't use the production image as the context).

I tested the app after re-adding those two lines and confirmed that it worked. I recommend that we re-add those two lines.

[mars-f]

Reproduced. I added the WORKDIR /app line back in, invoke upgrade appears to work again.

[purelogiq]

This seems excessively complicated to save a couple Docker cache hits. At the very least can you add a comment describing the purpose of this / what it does (besides installing the deps and removing them afterwards). Thoughts?

[mars-f]

This stanza is standard in the official Docker image's Dockerfiles. I've added a comment to the code explaining what it does.

The big thing it does is remove the need to explicitly state a dependency on both package XYZ and XYZ-dev in the Dockerfile, since the 'scanelf' stanza automagically keeps XYZ and removes XYZ-dev. Otherwise I would have to keep 2 separate lists of packages in the Dockerfile, and keep them in sync, too. Keeping one list should make the housekeeping easier. It's fewer lines to read, understand, and maintain.

[purelogiq]

Is there a way to let @ckolos and the ops team configure these values? I'm not sure what the best values are for the hardware they will deploy this on.

[mars-f]

They can set these values by editing the Dockerfile, setting them in the Docker environment, or by passing in a uWSGI config file. I'll let @ckolos decide which is best. We can iterate on the Dockerfile to find the approach that works best for them.

[ckolos]

Env vars are fine; we can override those

[purelogiq]

I re-reviewed it, the invoke commands work and the produciton image at port 9000 also works great!

[ckolos]

*nit: Do you anticipate this list changing often? if not, why not just add these packages as part of the container build?

[ckolos]

+1 for originality!
;)

[mars-f]

The list of packages changes every time we add a new compiled dependency. So far that's been for database adapters, uWSGI, and crypto/SSL handling.

This is the second time a reviewer has said they would be less surprised by an explicit list of runtime packages, and I'm sensing a trend, so I'll look into changing it. :) But we might not want to block on the rewrite and make that a follow-up commit.