Refactor for improved clarity and ease of use

@rmcd @dblodgett @ahopkins1 @aaufdenkampe_limno.com @sjordan_limno.com

Background

Aspects of the builder repo are complex and not adequately documented. This impacts the general usability of the repository, as well as adds difficulty to the maintenance and on-boarding of new staff/contributors. Below are some additional background on specific aspects of the repository, followed by set of recommended refactoring goals to address these concerns.

Complexity

This repo is designed to build three separate images with different configurations of pygeoapi. As currently structured, the repo splits out shared dependencies into multiple files. In theory, separating out these files provides better performance by allowing base dependencies to be built into an image once and then shared between the other images. In practice, this time savings is really only relevant for our CI/CD deployments and can actually hinder development time. During development it is difficult to tell which set of images will be impacted by changes; leading to situations where developers often had to go back further in the pipeline and rebuild the base or conda images to actually see changes reflected. The result was multiple builds were required before they could test their changes, or in worse cases confusion about why changes did not address the problem (when it was just that they were not loaded into the image). The caching feature of docker build should also provide much of the benefit that multiple files does (as least during development).

Documentation

The documentation for this repo has not been sufficiently updated to reflect recent changes from the previous development sprints. Additionally, the documentation is large incomplete or scattered; requiring new developers to piece together information from multiple sources to understand how execute the builder repository. Incomplete list of documentation includes.

• Main README.md for builder - some additional environment setup information
• PLUGINS.md - provides context for how to setup environment and incomplete explanation for nox works
• Docker specific README.md - instructions how to run containers with docker, though only partially correct.
• SERVER.md - some server information, but also explains some of the compose.yml/docker-compose.yml settings?

Closure Criteria and Refactoring Goals

This issue can be closed when the following conditions are met:

1. The three separate docker files (base, conda-environment, & docker) have been combined into a single file (recommend using multi-stage build approach to retain ability to build subsections for development).
2. Sufficient environment variables have been defaulted/exposed to image allow user to run and modify behavior through only a docker compose up command (instead of needing to build a local image).
3. Nox build commands have been updated to reflect new structure (single multi-stage docker file).
4. The existing (or modified as needed) test suite passes.
5. CI/CD pipeline has been updated to support new structure (less images)
6. ReadMe documentation bas been updated to include streamlined repo and environment set up instructions, build and run instructions for devs.
7. Instructions have been added to ReadMe documenting how users can run a local container without cloning repo (i.e. docker compose up pointing to out registry), see issue #5 (closed).