Discussion
Evgeny Shvarov · Sep 25

Developing IRIS applications with Docker and VSCode

Hi folks!

We have a bunch of templates on OEX that provide a handy foundation for building a particular application with IRIS.  And the basic principle of each and every template is that we take vanilla IRIS images, load code, and files into the image using Dockerfile, and create a new docker image as a solution. And then we develop running this image and rebuilding it when returning to development.

Some developers ask me why we need to build the docker image to work with the code. Indeed, if at the end of the day I need to develop a ZPM package and not a docker image why don't run the vanilla image and load the code and everything in it? 

The problem I have with the building image approach is that often I can wait a lot to build an image and it fails on some Objectscript problem in the source that I cannot fix as the image is not building. and 

Any thoughts? How do you develop with docker?

1
1 143
Discussion (4)1
Log in or sign up to continue

It's essential to keep in mind, that ObjectScript code has to be compiled. And actually, there are two ways of doing this.

  • Build stage, mostly with using Dockerfile
  • Runtime stage, start vanilla IRIS and build application there.

Yes, docker build can be slow, but the issue here is that IRIS starts in fully functional mode, and it takes too much time to start. While it would be enough if IRIS would be started with very minimal functionality (no spare wrtitedaemons, no hot jobs for Interoperability, and so on)

Building an application in runtime does make not so much sense. First of all, it's not so simple to make this happen. And second, the logging of this is quite complicated as well. So, it makes the debugging of the build process much more difficult. And in the case of a significantly big project, it still will take a lot of time to be built, but with less understanding of the progress.

The ability to fail fast is quite important, and it's a sign to a developer, that something is odd. Building images with BuildKit, have a different way of logging, and it may not show the real reason for failure, but you can turn on the full logging this way

docker-compose build --progress plain

If your project uses ZPM, so, most probably you would have lines like this

RUN --mount=type=bind,src=.,dst=. \
  iris start iris && \
  iris session iris "##class(%ZPM.PackageManager).Shell(\"load /home/irisowner/$MODULE -v\",1,1)" && \
  ([ $TESTS -eq 0 ] || iris session iris "##class(%ZPM.PackageManager).Shell(\"test $MODULE -v -only\",1,1)") && \
  iris stop iris quietly

ZPM's Shell accepts three parameters

  • executed command itself
  • Fail on error
  • Halt on exit

So, you can just change the second parameter (the first 1) to 0, and the build will be successful in any case

 --progress plain

This is essential information.
Without it the building log just runs though with no chance for a rollback
and iris.script allows a lot of temporary debugging info.

Could "docker commit" help out as an image snapshot that you can simply resume later. 

Would an image saved to tar or pushed to a repo make itteration portable also?

More simpler for a stopped container locally is to just start it again? Assuming the container is allowed to cache and not too much time has passed to allow the space to have been automatically reclaimed.

it would be a huge waste of resources with higher complexity of the development process. I would not recommend it this way at all.

A much better way is to use named volumes, where you could munt data, which you would like to keep between restarts of containers, but not easy way as well requires a lot of attention to many staff in IRIS, or use with Durable %SYS