OCI and Docker support for official MS optimized runtime-only base image.

[preston]

I've put up some test builds at https://hub.docker.com/repository/docker/graphitehealth/fhir-codegen but left it generic in the included README patch. We have a lot of M1/M2 chip users, so cross-architecture for both ARMv8 and x64 is important to us internally.

The distributable image size could still use optimization.

[GinoCanessa]

Hi @preston - thanks for pushing this forward! I will look at this next week - we are limited in what we can publish binary-wise from this repo until I finish some internal process (e.g., executables need to be built and signed internally, etc.). I have been working through everything and think I only have a couple of more steps.

I agree on the cross-arch images. Once I have the build pipeline working, we can hopefully use the aspnet image instead of the SDK one to start from a smaller base. I would like to go down this route as we do the initial setup (if possible) so that when .Net 7 is released we can AOT compile as much as possible per arch.

I was also thinking it may be nice to pre-build images with released FHIR core libraries so they do not have to be downloaded each time (e.g., /fhir-codegen/fhir_4_0_1 or just /fhir-codegen/withFhirCore). Thoughts?

[preston]

@GinoCanessa Cool right on! Yeah I think it would be ideal to bake in a pre-warmed cache of anything that gets downloaded, along with a --no-cache or similar flag to force re-download if needed. I don't think "redistribution" is in conflict with the FHIR license, but would be good to verify that ;)

No informed opinion from me on which build-stage image to use as I'm not a .NET expert. I was just assuming things work similarly to the languages and framework I am knowledgable in. I did not attempt to strip things down to only the minimum necessary files. The ARM image size is 217MB, which is at least not insane but I'm sure can be optimized greatly.