Management of Docker released versions

[dpwrussell]

I think this is another area that requires some thought.

Postgres for example have a Dockerfile per release. This has major advantages as it allows us to deal with errors or changes to the Dockerfile only for the releases where it makes sense. A good example of this is that pipelines was recently added to the list of requirements for OMERO. The single Dockerfile was unable to cope with this because it wasn't part of its build. Adding this requirement to the Dockerfile would then cause that to be installed even if we are building an older version of OMERO that does not require it. In this case no harm done, but could cause issues if we were switching from one implementation of something to another for example.

Also, I think with just a single Dockerfile it makes the continuous building process more difficult. If I update the Dockerfile, am I fixing a problem (i.e. old Docker images should get rebuilt and pushed) or adding a new feature for the latest version of OMERO only (i.e. its only for new images)?

So either keeping files per version, or perhaps basing the build process on tagged commits?

[joshmoore]

Couple of thoughts:

• The Postgres build is far more stable making that less of a maintenance burden.
• We're additionally just between major releases (for the first time in 18+ months) so it's bound to be even more confusing at the moment.
• If we need two files, my preference would be do do it via branches rather than duplicates, e.g. master and devel. (I'm also inclined to get this repo tagged as e.g. 0.1.0 for 5.2 and as 0.2.0 for 5.3)
• That all being said, 👍 for using state integration points, though perhaps that can (also) be via concrete versions of the ansible roles which are used.

[dpwrussell]

Tagging based solution works for me. Having separate master and develop branches would makes sense if there was to be development releases, but otherwise I would say just have master and tags for all releases.

[akmukherjee]

I am trying to use a shared volume for the Omero Server. I have mounted an AWS EFS on my local machine and am trying to mount that host directory on to the container. However I get a "FATAL: OMERO directory which needs to be writeable belongs to root: /OMERO" error. My current host already has an user called omero which has ownership of the directory.

The command I am running is:
docker run -d -e DBHOST=MYPOSTGRES-DATABASE.us-west-2.rds.amazonaws.com -e DBUSER=postgres -e DBPASS=postgres -e DBNAME=postgres -p 4063:4063 -p 4064:4064 -v /efs:/OMERO openmicroscopy/omero-grid master.

Can either of you help me with this?

Regards
Amit

[joshmoore]

Hi @akmukherjee

Unless you have a particular reason for using omero-grid, I suggest you move to omero-server and omero-web. For example, from http://www.openmicroscopy.org/explore

version: '3'

services:
  db:
    image: postgres
    environment:
      - POSTGRES_PASSWORD=postgres
  omero:
    image: openmicroscopy/omero-server:5.4
    environment:
      - CONFIG_omero_db_user=postgres
      - CONFIG_omero_db_name=postgres
      - CONFIG_omero_db_pass=postgres
      - ROOTPASS=omero
  web:
    image: openmicroscopy/omero-web-standalone:5.4
    ports:
      - 4080:4080

All the best,
~Josh

[akmukherjee]

Thanks Josh. Appreciate the quick response. I am trying to develop a POC with Dockerized Omero Web and Server with an EFS based Share drive as the data directory and an externally hosted Postgres DB. I guess we would need to modify the ansible playbook. I noticed that mounting directories does not seem to be supported in the scripts provided.

[joshmoore]

Hmmm.... because of ownership? I would expect mounting a uid 1000 directory to /OMERO or configuring omero.data.dir and mounting elsewhere would work fine. e.g. https://github.com/openmicroscopy/omero-test-infra/blob/master/volumes.yml

[akmukherjee]

Aah, Thanks. I will take a look. Appreciate that.