IRIS in Docker for beginners

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
• 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