Background

Our previous refactor effort focused on reducing the complexity of the docker build process by; simplifying the docker files, adding in support for staged and cached builds (to speed up local development), and both consolidating and updating documentation. Yet recent deployment challenges related to dependencies suggests this builder still has some limitations that need to be addressed. Previous issues such as Consistent Dependency Management highlight the need for more robust control over dependencies.

Specifically, there is an acute need to have static dependencies for production images. The current structure has additional dependencies specified in the configuration file installed at container startup. This is problematic as environment resolution of these dependencies can lead to the container installing versions not yet adequately vetted for release. This has lead to a number of deployment related issues lately and caused production outages. Furthermore, without a static set of dependencies in production images, a rollback to a previous images does not guarantee the application is running in the same environment as the previous deployment. New dependency versions may have altered behavior or share the same incompatibility that necessitated the rollback in the first place. This is our primary issue justifying this refactoring effort.

In addition to static dependencies for production images, there are a host of issues related to dependency management (see below) we should focus on tackling as part of this effort.

Initial Related issues

#22 Remove hard coding of PYGEOAPI_VERSION_TAG

#31 Consistent Dependency Management

#46 Possible Update of Poetry

#48 Upgrade to pipeline to use latest nox version

#49 Configuration files are not directly compatible with pygeoapi.

Refactor requirements and closure criteria

• Dependences are static for production images. I.e. once a production container spins up, it should not install additional dependencies.

Guidelines and optional items

• Dependences are set in a single location for each resultant image.
• Our configuration files should be directly compatible with and meet the syntax requirements of pygeoapi.
• We retain the ability to override the environment file and pygeoapi configuration file as optional arguments/volumes provided at runtime.
• Our refactor should not inhabit the ability to add a postgres database/connection for future geospatial feature related support.