Data logistics system enabling real-time pathogen surveillance. Built for the Seattle Flu Study.
Source code
Latest commits



We want to move from AWS to Azure. This should be fine. It will be a great point to adopt a configuration system like Ansible, and maybe a cloud provisioning system like Terraform (though I’m 80% sure it won’t be worth it).

  • Migrate database instances
  • Migrate backoffice server and services
  • Migrate security groups (firewalls) and private networks


The “backoffice” is currently:

  • Production and testing ID3C API server (Apache + uWSGI)
  • Metabase (containerized)
  • Lab Labels service (containerized)

For development, would it be useful to produce a “backoffice” container which bundled?

  • ID3C API
  • Metabase
  • Lab Labels

Another idea is that for both development and deployment, we could instead produce an “id3c” container which might be used like this:

# This is the CLI!
docker run seattleflu/id3c --help
docker run seattleflu/id3c etl enrollment --commit

# This is the API, which is either another true CLI command or dispatched
# by the container entrypoint to uWSGI inside the container.
docker run seattleflu/id3c web api

# Testing API would be deployed with a different container image
docker run seattleflu/id3c:testing web api

# If we ever had an ID3C frontend
docker run seattleflu/id3c web frontend

There are some (surmountable) challenges here regarding passing in Pg services and credentials via the environment and files (with the right permissions), as well as exporting a uWSGI socket out of the container for the reverse proxy server.

I’m not clear on the benefits of doing this, other than it would make setting up a development environment very easy.