Create OIE Docker Image

[jonbartels]

Create a Docker image for OIE.

The Mirth image is here - https://github.com/nextgenhealthcare/connect-docker

The env var support from this image is excellent and should be kept.

This Image does some wierd things with SSL and downloading the Mirth artifacts. Evaluate if that needs to be kept or changed.

BridgeLink has some conversation about ideas and features at Innovar-Healthcare/BridgeLink#4

Acceptance criteria:

• "mirth" naming conventions should be removed
• breaking changes between connect-docker and OIE should be documented
• provide a preferred JVM/JRE but allow for other implementations
• the _MP env var pattern support should be kept, changing MP to OIE
• the LICENSE_KEY env var should be removed
• publishing to https://hub.docker.com/u/openintegrationengine would be ideal, but is not required and can be ticketed separately

[tonygermano]

My preference for this would be to mimic the nextgen setup and have the docker build happen in a fork of the NG docker repo, but with improvements (such as using a multi-stage build and occasionally refreshing our images with a new base image in addition to the changes mentioned above.)

I think the official docker container should be reproducable using official releases of the application rather than building from source (the artifacts should already be signed with a real signature.)

I think we should have multiple versions of the image available for the user to choose from (at least alpine vs ubuntu and jre vs full jdk.)

[tonygermano]

• the _MP env var pattern support should be kept, changing MP to OIE

I'm not sure if this is appropriate. MP stands for a generic value in mirth.properties. Fixing nextgenhealthcare/connect-docker#12 would require specifying both the generic property and the correct file to which it should be applied.

Providing support for files in appdata via environment variables (server.id, keystore.jks, extension.properties) would also be good additions.

[mgaffigan]

My preference for this would be to mimic the nextgen setup and have the docker build happen in a fork of the NG docker repo, but with improvements (such as using a multi-stage build and occasionally refreshing our images with a new base image in addition to the changes mentioned above.)

Can you help me understand what the intent is? This greatly complicates the docker story since it adds the distribution URL dependency, and makes dev-build separate from release-build. Dockerfiles and OCI release artifacts are often used as complete alternatives to other package management and release channels.

I think the official docker container should be reproducable using official releases of the application rather than building from source (the artifacts should already be signed with a real signature.)

Totally agree that reproducibility is important. Dockerfile and containerization when with appropriate specification of dependency versions are great for making binary reproducibility from source to production artifact. Assuming signing is still in the OIE release story, adding support should be relatively trivial since keys can be handled as build secrets. Is there existing production signing machinery in the ant build? The resultant OCI release artifact would contain the signed artifacts, but have no access to the original keys.

I think we should have multiple versions of the image available for the user to choose from (at least alpine vs ubuntu and jre vs full jdk.)

I think I understand the intent to be that there is a JDK+Ubuntu "dev / debug / thick" image and an Alpine+JRE "production image". If that's not right, please let me know. It seems like fewer variations reduces the support burden, but I might be missing a use-case.

I think the 80/20 rule applies here - I'm aiming for 99%+ of the use cases to be workable from the published OCI artifacts, with the remaining covered by reproducible builds of the source code. Since docker makes source builds trivial by abstracting the development environment, it serves as a very useful escape hatch.