For work reasons I ran up an Isle DC instance or two on Thursday. OK, first let's unpack that!
- Islandora is an open source digital asset manager and digital heritage repository. It's composed of a lot of services.
- ISLE is Islandora: Enterprise 2 (I think)
- ISLE DC is a Docker Compose environment to spin up Islandora sites
The ISLE DC installer uses a Makefile (love it) and brings up several containers to run the various services that make an Islandora environment. (You can configure lots of this, eg swapping in your preferred DB backend service for the Matomo or Drupal components).
The environment which it brings up has lots to it. I'm planning on making some post-it notes to list out the services that it include, since I look at the list and boggle.
We use Lando quite a lot on other projects, and both Lando and ISLE DC drop in a Traefik proxy which wants (out of the box) to bind port 80. I'd love to be able to have both run alongside each other, so I'm interested to see whether we can do that. Ideally we want to be able to switch quickly between projects without needing to shut down all the others. The conflict is really around the default ports, which can be resolved of course, and this is a challenge you can run into with running (say) Vagrant and Lando sites in parallel.
I wonder if we can have the two systems co-operate on a common Traefik proxy ... there are other options.
The installer for the demo Islandora site takes a wee while, during which my everyday laptop lagged crazily. But it came up and it's an impressive work of orchestration to bring each of those several services up and connect them. Really impressed. I can see that the orchestration here is keeping deployment to other platforms in mind too, and it got me wondering about how we plan to deploy Islandora ourselves.
I don't require local development environments to faithfully reproduce hosted environments, I see that as an anti-pattern. It's beneficial to not couple too tightly to a specific deployment implementation, and so I like to treat local dev and CI as a loose parallel which may run up only the required services. If I'm not developing or testing against Matomo, I'll choose to omit that from the dev and CI layouts unless it's of significance. To my thinking, this actually tests that things work in a broader array of configurations.
A few notes on the deployment it brought up. I've only had a brief introduction to the software so far, so I'm not going to leap ahead and propose changes yet. These are just first impressions!
I was a bit uncomfortable with the Makefile prompting me for my system password part way through the process. This doesn't feel like it should be necessary, and is always worth a careful review. On doing so I saw this code which is triggered from the presence of an environment variable in
CMD := $(shell [ $(IS_DRUPAL_PSSWD_FILE_READABLE) -eq 1 ] && echo 'tee' || echo 'sudo -k tee')
It's a little hard to read - I think this is only using
sudo to read the contents of the file, right? But it makes me nervous seeing
sudo scattered around as a workaround for correct file permissions configuration, and until I read that carefully I wondered if I could exec something by setting
"password"; adduser baddie <...>.
Docker Compose or otherwise, calling
sudo commands on the host OS are something to be wary of. Lando does some fancy shenanigans behind the scenes to keep file ownership aligned, which is nice. Many services which are fully self-contained don't need this treatment at all; for those which permit direct edits in a volume mount, it's important to get right. (For Drupal media, configuring $settings['skip_permissions_hardening'] = TRUE; in local dev helps with this.)
I disagree with
On first impression I don't agree with
- I don't like that it places configuration AFTER
include settings.local.php, which is supposed to be at the very bottom of Drupal's
settings.local.phpshould IMO still be able to override any of the values set in that snippet. The snippet generated should be placed above that final include, or in a separate include if it's intended to be generated per environment/build rather than committed to the codebase.
- I don't like that the implementation is a bash function stashed away inside a built container, which can hide how things are working if you're trying to understand what's going on by reading the source of your Islandora codebase.
Traefik and sharing proxy
As mentioned above, this is on my mind ... I see in ISLE DC that there's a configuration
INCLUDE_TRAEFIK_SERVICE, which apparently permits the environment to use an external Traefix proxy if set false. Lando also has a global config
proxy which can be set "OFF" to disable Lando's Traefik
Do we need all this?
Some of the containers may not be necessary? I don't know yet which, but I was glad that the inclusion of VS Code server is not activated by default (!!!), and I would probably turn Matomo off by default. The services which did come up had related settings for memory limits, and the total of all those memory limits was in the neighbourhood of 50GB for services which did come up in my test. Whoa!
The fcrepo service certainly gave my work laptop a run for its money and I killed some updating daemons at one point when the system lagged to a standstill with a loadavg just shy of 400. I may have to requisition an appropriate 64GB RAM stick, or a standalone environment! But I'd rather be able to hack on my laptop and not remotely. Maybe that's why VS Code server got in there ... With things as they are, I probably won't casually put an Islandora environment on my personal laptop to test things out.
This project is exciting. The above criticisms / thoughts are just an early response, and my bigger feeling is - wow, this is really well put together, and reminds me of other community efforts where people find something that works and make progress. I'm stoked to see that the Islandora community has got things so well put together so far and I'm excited to see what a deployment of this looks like. We have a handful of existing Islandora projects I look forward to trying it out on.
The Islandora community looks really exciting to be a part of, and I look forward to getting to work on some of these projects in future, and building a connection with the community.
Working with digital heritage and culture artifacts is something I'd love to see myself doing more in the next few years, and I'd be excited to work directly engaged with institutions implementing these systems. I think it's so important to have a strong connection to the people involved in working with the objects of significance in order to best support building tools that reflect both the community best practice and the special nature of the heritage at hand.
I'm thankful to Jonathan Hunt and Ant Brown for making the introduction, and giving me a good roadmap to begin my journey with Islandora!