Thank you all for the help. 

Just want to share with everyone about our progress:

As the first stage, we successfully mapped production settings to a thrid read-write database.

Example Dockerfile to build the image containing the CODE database and initial CONFIG (we removed a lot of details, just leaving the key statements):

ARG BASE_IMAGE=intersystems/irishealth:2023.1.0.229.0
FROM ${BASE_IMAGE} as staging

### Launch IRIS instance and executes staging process using staging.script
### This will deploy the production, import and compile all source codes
### This process creates APPDATA/APPCODE/APPCONFIG
RUN /usr/irissys/bin/iris start IRIS && \
    /usr/irissys/bin/iris session IRIS < staging.script && \
    /usr/irissys/bin/iris stop IRIS quietly

FROM ${BASE_IMAGE} as final
USER irisowner
### Run install.cpf and initialize databases
### in installc.cpf, we only create APPDATA and APPCONFIG
RUN iris start IRIS \
 && iris merge IRIS /tmp/install.cpf \
 && iris stop IRIS quietly
RUN rm /tmp/install.cpf

### Make a copy of all CODE & CONFIG databases, as they're initialized during the staging process
COPY --from=staging --chown=51773:51773 /output/APPCODE.DAT /home/irisowner/mgr/appcode/IRIS.DAT
COPY --from=staging --chown=51773:51773 /output/APPCONFIG.DAT /usr/irissys/mgr/appconfig/IRIS.DAT

Example install.cpf:

[Startup]
[Actions]
CreateResource:Name=%DB_APP,PublicPermission=0
# We cannot create CODE databases during Docker build, otherwise they're be automatically moved to /durable
CreateDatabase:Name=APPDATA,Directory=/usr/irissys/mgr/appdata,MountAtStartup=1,Resource=%DB_APP
CreateDatabase:Name=APPCONFIG,Directory=/usr/irissys/mgr/appconfig,MountAtStartup=1,Resource=%DB_APP

# Since we're not creating CODE databases, let's create namespace during runtime merge.cpf

At the runtime container, use merge.cpf as well as durable %SYS feature to create namespaces and map everything:

[Startup]
WebServer=1
[Actions]
CreateDatabase:Name=APPCODE,Directory=/home/irisowner/mgr/appcode,MountAtStartup=1
CreateNamespace:Name=APP,Globals=APPDATA,Routines=APPCODE,Interop=1
CreateMapGlobal:Name=Ens.Config.*,Namespace=APP,Database=APPCONFIG
CreateMapGlobal:Name=Ens.AutoStart,Namespace=APP,Database=APPCODE
CreateMapGlobal:Name=EnsLib.DICO*,Namespace=APP,Database=APPCONFIG
CreateMapGlobal:Name=Ens.LookupTable,Namespace=APP,Database=APPCONFIG
CreateMapGlobal:Name=Ens.Util.LookupTableS,Namespace=APP,Database=APPCONFIG

# ...other stuff for APP

With this setup, the CODE is inside container image itself (with an initial CONFIG), and DATA and CONFIG will be persistent at customer durable volume. Next time, we'll be able to deploy a new image with new CODE, but keeping the DATA and CONFIG from durable volumes.

Next step, we'll try to implement default settings.

What's "RO" stand for? Yes in face we tried another approach where we leave the APPCODE inside container image and APPDATA in the durable like this (example of runtime merge configuration):

[Actions]
CreateResource:Name=%DB_APP,PublicPermission=0
CreateDatabase:Name=APPDATA,Directory=/durable/iconfig/APPDATA,MountAtStartup=1,Resource=%DB_APP
CreateDatabase:Name=APPCODE,Directory=/home/irisowner/mgr/APPCODE,MountAtStartup=1
CreateNamespace:Name=APP,Globals=APPDATA,Routines=APPCODE,Interop=1
CreateMapGlobal:Name=Ens.Config.*,Namespace=APP,Database=APPCODE
CreateMapGlobal:Name=Ens.AutoStart,Namespace=APP,Database=APPCODE

By doing this, APPCODE upgrade will be very easy when upgrading container images, but there is a new problem: after the customer deployment, if there is any change made on the production settings (e.g. changing an AE Title on the DICOM service), those settings are stored in the APPCODE, and the settings will be lost after a container PODS restart (kubernetes recreating the PODS).

Hi Enrico,

Thank you for the reply! 

We have changed both classes codes (.cls files) as well as prodution settings (class extending Ens.Production).

During the container image build process (by Dockerfile), all the code files (.cls) were compiled and built into APPCODE database inside the container image. Do you mean we have to compile those changed codes in the final deployment environment, at customer site? That would be not easy to do and to manage for service engineers at each customer site (in case of a major version upgrade, a lot of code files could be changed)

Is there any other capability provided by IRIS for such scenario?