During the development of a container-based demo I found the need to access a fresh docker
instance of IRIS image (e.g intersystems/iris-community:2020.2.0.199.0) over and over.
To bypass setting passwords and loading my code repeatedly I developed this workaround.
It is a reduced variant of Docker - light weight durability
- passwords without the need to change
- my classes, routines, globals without repeated reload
The base facts:
- docker offers external volumes (eg. needed for the license)
- iris-main allows running scripts before IRIS starts
OK so far! I have a directory for external data in docker.
- an IRIS.DAT (with my code and my globals)
- an adapted iris.cpf
- refers to my IRIS.DAT as Database, mount required at startup
- replaces the DB for namespace USER to the new DB
- maps routine ^%ZSTART also to the new DB
- ^%ZSTART cleans the property for PasswordChange for some accounts
- a script to copy iris.cpf into my container
Once the script is executed
- IRIS starts
- ^%ZSTART is executed and I'm ready to work.
The external directory should allow rwx access (chmod 777) as the docker image
is just a nobody to your local system. But it wants to write his iris.lck file
Shutdown requires no action as your DB is already outside the docker image located
and next time you have a virgin IRIS system again with your USER DB unchanged.
You may say: It's dirty.
But I can confirm my development speed and fun was significantly increasing.
And a got rid of the boring acts with virgin container images.
How to use:
This is a coding example working on IRIS 2020.2 It will not be kept in sync with new versions It is also NOT serviced by InterSystems Support !
Have a docker instance for IRIS >>> iris-community:2020.2.0.199.0
Download and untar the archiv micro-durability.tar.gz
chmod 777 to direcory demo/
run your container:
Late warning. always check the version of your image!
I just fell into intersystems/iris-community:2020.2.0.204.0
NOTICE: ALL SCRIPTS ARE FOR LINUX ONLY !