All
Accepted answers
Zhou Tao · Dec 10, 2023 go to post

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.0FROM ${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/APPCONFIGRUN /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 APPCONFIGRUN 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 processCOPY --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.

Zhou Tao · Nov 3, 2023 go to post

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).

Zhou Tao · Nov 3, 2023 go to post

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?