Improve build process for service images

[davenquinn]

With #149 we've successfully created a working multi-container build process for Docker images within this repository. This will allow us to eventually stage multiple services from the same codebase, with shared components as needed, and push to OSG Harbor or other container repositories as appropriate.

Ideally, we'd clean this up in several ways:

• More stable process to include libraries in Docker containers (right now we manually copy wheels, which is brittle and has problems with hash stability across platforms)
• Less repetitive/confusing CI pipelines
• Include API v3 (and other containers?) in this build configuration
• Wrap scripts in a macrostrat dev {build,publish} command as appropriate
• Make it possible to locally build/push images using the same structure
• Document the process

We may want to pair this with other architectural simplifications such as #89

[davenquinn]

@amyfromandi this is worth being aware of for some of our current struggles with the structure of this repository.

[amyfromandi]

@amyfromandi this is worth being aware of for some of our current struggles with the structure of this repository.

@davenquinn can you provide a few examples for bullet points 1 and 2? For 1, could we include poetry install in each service's Dockerfile so that the poetry.lock file and .whl files are created in this environment?
For 2, I'm curious about the structure you are thinking of for the CI pipeline. Do you want a standard workflow that checks each service and image build when pushed to git? Or do you want a custom workflow for each service? What types of tests and checks do we want?

[davenquinn]

This is now solved by #221; we use an additional py-modules context for Docker BuildX to build services with all of their dependencies.