Running multiple containers - File sharing
Hello,
How can I use ISC_DATA_DIRECTORY once IRIS runs inside a container? Some background...
We plan to deploy multiple containers running the same Health Connect IRIS Interoperability production in containers. So far we use docker run to start a container with ISC_DATA_DIRECTORY individual per container inside a efs that gets mapped using -v. I can imagine automating this task - we have not yet looked at cloud manager - and assigning individual ISC_DATA_DIRECTORY to each container. We experience errors when multiple file service in different containers point at the same folder in efs outside the container. We could create individual directory tree for each container OR come up with code to control file names so each container only processes files intended for it. The files are actually received via a CSP page that is connected in code to a Business Service that puts the file via a file operation. We have a load balancer that directs incoming http request to one of the containers. The CSP that receives the request could rename the filename if it knows what is the ISC_DATA_DIRECTORY for its container.
Please let me know how to check what is ISC_DATA_DIRECTORY from IRIS running in Docker container.
Thanks
Hi Oliver,
Generally, each unique ISC_DATA_DIRECTORY should be bound to one persistent instance. If you have two instances you wish to maintain, IRIS1 and IRIS2, they should each have their own unique persistent storage location. There's nothing preventing you from putting both of them on the same EFS store, as long as that point to different, unique directories within that store. So your idea of an individual directory tree for each container should work just fine. (Exception: If you are using mirroring for availability, I would not recommend storing both/all parts of a given mirror set on the same EFS store.) Two simultaneously running containers/instances should never be pointing at the same mgr/IRIS.DAT, that will not result in a functional application.
I say persistent instance because you can freely stop a container, and then start a new one with the same ISC_DATA_DIRECTORY and have a new container - possibly with a newer version of InterSystems IRIS, or a newer version of your code - run on the same persisted data.
Additionally: Depending on your particular needs, you may not wish to use EFS for ISC_DATA_DIRECTORY locations. EFS is an NFS implementation, which has been known to cause problems with container runtime engines, and EFS will generally have higher disk latency than other things, EBS might be one better choice. Consult AWS documentation to be sure! https://docs.aws.amazon.com/efs/latest/ug/performance.html
Conor,
I agree that each persistent instance needs to have unique ISC_DATA_DIRECTORY. Like you said, they maybe subdirectories under the same directory like /data/data_instA and /data/data_instB, etc.
If I want to deploy the same code in two or more containers, our application has file path for File Services. If I get access to ISC_DATA_DIRECTORY such as /data/data_instA or /data/data_instB, I can configure unique file path for each container. Otherwise, if more than one instance has File Service watching the same directory, they may conflict when processing and then moving the file. This can be avoided by having unique file path per container OR unique file spec so two containers do not try to access the same file.
I just searched and found $system.Util.GetEnviron(). I will test if this gives me ISC_DATA_DIRECTORY when container is starting or running.
I just tested
Currently our application gets file path for file services and operations from System Default Settings. What is a good way to update the System Default Settings based on $System.Util.GetEnviron("ISC_DATA_DIRECTORY")?
You can use %ZSTART routine but I'd recommend writing idempotent code for OnProductionStart - this way all Interoperability functionality is contained inside the production.