The article was motivated by the 2025 September Article Bounty
***************************************************************
The principle of Docker is just convincing to me.
- Get a sandbox where you play and try whatever you want/need to do
- Once done. You drop it without leaving traces in your working environment
This was the technical base for me to run about 700 reviews in OEX
with almost no side effects (except those caused by myself).
For beginners, I'll start with straight pure IRIS, no *health, *ML, *whatever
First, you need a Docker installation. It's available on almost any platform.
My personal preference is Windows Docker Desktop for its comfortable admin console.
I don't dig into detailed Docker management.
There's enough reading material around to search in Docker Docs
Second, you decide on an IRIS incarnation of your choice
the most simple: intersystemsdc/iris-community ready to use
- runs on Ubuntu
- has a valid community licence
- has Apache httpd installed
- has IPM/ZPM client installed
Warning #1: As a beginner, don't study packages offered on OEX
They are great (mostly) but always targeted to some Functionality
to some special Application that requires special settings and a tricky installation.
Warning #2: Docker has a rich set of commands with everything you need
And those commands offer a flood of (sometimes confusing) parameters.
So, I suggest making them reproducible using dedicated scripts.
Dockerfile is the way to take with complex constructs with lots of extras to be
loaded upfront. I typically saw them related to Python and to various AI demo cases
There's no need for this example.
docker-compose.yml is the real to blow your container. It needs:
- a definition of what you want to "compose" >>
service:
- a name for it >>
iris:
- which image to run >>
image: intersystemsdc/iris-community
- a name for it >>
- Next, you need to define how SuperServer Port 1972 and the default WebServer Port 52773 will be visible outside the container
-
ports: - 41773:1972 - 42773:52773
-
- Finally, it' not an urgent requirement but often very useful to map your local directory to some internal in the container. I used /external
Especially at the beginning, this bi-directional path makes life really easy
volumes:
- ./:/external
Now this is the final text of docker-compose.yml
services:
iris:
image: intersystemsdc/iris-community
ports:
- 41773:1972
- 42773:52773
volumes:
- ./:/external
And now you are ready to run your first IRIS instance in Docker
docker-compose up allows you to watch the full startup
docker-compose up -d launches a start in the background and keeps your command line free
docker ps -a shows ports and running images of your IRIS container
OK your fresh IRIS is in Docker now.
But how can you use it?
- You have the WebServer and so the Management Portal http://localhost:42773/csp/sys/UtilHome.csp
- You have the SuperServerPort for ODBC access, IRIS NATIVE, ... (and even Studio)
- And you can access IRIS also from the command line inside the container
- docker-compose exec iris iris session iris
- Splitting this single line, you access the container first and then IRIS
- docker-compose exec iris bash
- Then iris view
-
Instance 'IRIS' (default) directory: /usr/irissys versionid: 2025.1.0.223.0com datadir: /usr/irissys conf file: iris.cpf (WebServer port = 52773) status: running, since Thu Sep 4 14:35:19 2025 SuperServers: 1972 state: ok product: InterSystems IRIS
- And iris session iris
-
Node: 3266c5c8b21f, Instance: IRIS USER>
-
- Here at the bash level, you have all the options for IRIS operating in your hands Your Ubuntu user is irisowner
- for the rare cases where you might need root access docker-compose exec -u root iris bash
- Stop your container with docker-compose down
A few considerations on changes during the container session.
- Whatever you create, change, or modify exists as long as the container exists
- Once the container is deleted, all changes, .... are gone.
- This might be annoying with large setups.
- Dockerfile takes care of a setup that is done once in a build cycle, differently to run the setup at every start of the container.
- This is good practice in OEX packages, though it might look like overkill in some cases