InterSystems IRIS multistage builds
Images for other languages are often build using multistage build process.
What about InterSystems IRIS?
Consider this Dockerfile:
FROM irishealth-community:2020.4.0.524.0 AS builder
# Load code into USER and compile
# Adjust settings, etc.
FROM irishealth-community:2020.4.0.524.0
# replace in standard kit with what we modified in first stage
COPY --from=builder /usr/irissys/iris.cpf /usr/irissys/.
COPY --from=builder /usr/irissys/mgr/IRIS.DAT /usr/irissys/mgr/.
COPY --from=builder /usr/irissys/mgr/user/IRIS.DAT /usr/irissys/mgr/user/.The advantage of this approach is the image size.
The disadvantage is that on a final stage developer must know/remember all the modified places in the builder image.
But otherwise is this approach OK for InterSystems IRIS?
Have anyone tried to build IRIS images this way?
Comments
We build IRIS with ZPM this way, and the reason was to shrink the final size
But the best you achieve if you will not change anything in the system database, which is quite big, and it makes no sense in the end.
Thank you!
Why do you map %ZLANGC00/%ZLANGF00 to %ALL? They are available everywhere by default.
The reason was to place them in the particular database, out of the system database.
You may use this at init time
https://openexchange.intersystems.com/package/helper-for-objectscript-language-extensions
to add your ZPM command and function. It does a unique insert of the label
For a simple case (add a couple of classes to the USER namespace) - what would be space savings here?
Interesting question!
Here are my findings for store/intersystems/irishealth-community:2020.4.0.524.0 and a simple app in the USER namespace.
| Uncompressed (Mb) | Compressed (Mb) | |
|---|---|---|
| IRIS | 3 323 | 897 |
| IRIS Squashed | 3 293 | 893 |
| App | 8 436 | 1 953 |
| App MSB | 3 526 | 937 |
| App Squashed | 3 576 | 931 |
| App MSB + Squashed | 3 363 | 904 |
Notes:
- MSB means Multi Stage Build
- Squashed means that an image was built with a --squash option
- Uncompressed size is calculated via
docker inspect -f "{{ .Size }}" $image - Compressed size is calculated via
(docker manifest inspect $image | ConvertFrom-Json).layers | Measure-Object -Property size -Sum - More info on calculating image sizes is available here
Conclusion: either MSB or Squashed work fine, but just MSB would be better for storage as it can have shared layers (squash always produces one unique layer). Squashed is easier to implement.
Super benchmark, it's very interesting.
Personally, I prefer the squash method because it is easy to implement (no change in the dockefile).
I won't recommend using squashing, as it makes caching image layers useless.
Have a look at this nice tool, which may help to discover why your final image is so big.
.png)
btw, one thing I noticed working on macOS, is that the final image much bigger than expected, while the same Dockerfile on Linux, produces an image of a reasonable size.
You might want to add /usr/irissys/csp/bin/CSP.ini to the list of files to copy. Without it chances are CSP Gateway would not be authorized to communicate to IRIS.