Do we want to deploy with Docker?

[migurski]

In conversation about deploying Extracts, @baldur suggested that the Ops team Docker work might be appropriate. Here is a minimal Dockerfile that sets up the application:

FROM ubuntu:16.04

RUN apt-get update -y && apt-get install -y python3-pip postgresql-server-dev-all

COPY . /usr/local/extracts

RUN pip3 install -r /usr/local/extracts/requirements.txt

ENV DATABASE_URL=postgres://user:pass@host:5432/database \
    FLASK_SECRET_KEY=secret \
    MAPZEN_APP_ID=oauth-client-id \
    MAPZEN_APP_SECRET=oauth-client-secret

EXPOSE 5000

I’ve not tested this with a running app, but it can be started by calling honcho start in /usr/local/extracts. Kicking this over to Ops just in case it’s useful for future deployment plans.

[baldur]

I just setup a quick example of how you would run this locally

https://github.com/mapzen/data-pages/tree/baldur/odes-client/dockerize

I need to understand this a bit more to complete ... we need to run the schema file here and I was unable to find out how you would log in. Let set aside time and go over this and how it would work in practice. To get value from running things in this way I would recommend building this into the development workflow.

to explore the work on the branch ping me to get help but essentially the steps are:

to build stuff:
docker-compose build

to run stuff:
docker-compose up

to load the scheme we have ways to do that in this setup but for now you can just connect to it locally: psql -h localhost -U user -d database ... you might need to make sure you don't have an local postgres instance running either stop it or move this to a different port (advanced)

I am in SF next week so we can spend some time going over this and how it would fit the development workflow ... but we can connect virtually till then or you can ping me on slack.

[migurski]

I would expect that we’d prefer RDS for running the database—is it better to Docker compose one?

[baldur]

yeah this is just for the local workflow ... we'd run RDS for the production database

[migurski]

Who would run the local workflow? I don't think it makes sense for development.

[baldur]

We'd get the best value for the setup if we align the local workflow to the production one. Doing that would also make it quickly available to other developers without having to spend any time on setup. At the very least we'd need the developer working on this making sure that the setup is up todate at all times.

[migurski]

Makes sense. That’s actually a little suboptimal for local development of Flask applications. Typically, when working on a Flask app, you would run it in debug mode which automagically detects file edits and reloads the app code. It allows for a smooth, PHP-like flow that I think Docker would interfere with. I’d prefer to not ask people to figure out Docker when developing this application, and to use the native Python/Postgres tools instead. We’ve been ensuring that the app works as easily as possible on stock OS X and Linux machines for this reason.

[baldur]

I see your point but I am hoping to achieve this for other workflows we have. As well as simply python/postgres. Lets postpone chatting about this till I am in town next week, much better articulated in person our goals are aligned so we'll find a common ground that can benefit everybody.

[baldur]

updated the branch with code reloading bits ... this way you just fire things up without installing anything (except docker ;( ) and then edit away and things work pretty smooth php style.

I need to get my hands on a mac to make sure the workflow is smooth for everybody as mac has a history of being a step behind on this stuff.

[baldur]

Just verifed the reloading works and https://docs.docker.com/engine/installation/mac/ will install everything correctly. @tigerlily-he has verified on her laptop and the instructions worked and she was up within minutes.

I'll demo in SF next week and then we can setup the RDS instances and get it ready for production.