New post
Discussion
· Apr 2, 2021

InterSystems IRIS multistage builds

#InterSystems IRIS

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?

Discussion (9)1
Log in or sign up to continue
Eduard Lebedyuk · Apr 11, 2021

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.

2 0