SNOMED server maintenance

[eatyourpeas]

We currently are using Mark Wardle's excellent Hermes as our SNOMED terminology server and this works well. It has one vulnerability, however, that it is running in a dockerised instance on azure, and ideally the SNOMED CT version needs updating everytime a new one is released from TRUD. This is not easy with the current set up we have and involves manually building a new docker instance with the new version and pushing to azure.

• [ ] get RCPCH specific TRUD API keys
• [ ] explore hosting an instance of Snowstorm instead
• [ ] set up CRON job or similar to automate the updating of SNOMED CT and notify repository leads
• [ ] refactor the URLS / keys within azure

[wardle]

Just spotted this issue. You can, of course, build a pipeline that creates a new docker image every three months and then you switch, but you can update in place if you really want to. So, if you're looking for very easy maintenance, you can even run a server and have a cron job that updates the data file at 3 monthly intervals.

Personally, I have a suite of data files and my application has a top-level configuration file that specifies the version - that means I have clear versioning between application, libraries and supporting data files - and I just bump to the latest release during my application release lifecycle. I release frequently, so it isn't much of an issue, and I generally synchronise the volume containing data files frequently as well so all deployments end up on the same version. I don't run in docker, however, and instead use as a library in-process, so I have a different set-up to you.

I couldn't use the national services because my requirements mean I'd make far too many requests per second.

Mark

[wardle]

I was thinking about your situation and wanting to be able to make easy updates. I have always supported update-in-place, but I realised that during an update process, the data are re-indexed. This could have resulted in processes/threads that were concurrently using those index files to temporarily get inconsistent data. The latest release fixes this, such that it should be possible to update to the latest UK distribution with a single command, and maintain integrity for any server processes that were also using that data file at the same time. You can then run a simple server (AWS/Hetzner etc) and simply update-in-place and avoid some complexity. Hope it helps.

See v1.4.1362 and (now closed) issue

[eatyourpeas]

This is super helpful thank you Mark. We are running a version of SNOMED currently that is a couple of years out of date: we do not need real time versions but I would be happier to be honest that we were serving up to date content. I think we should bump this issue so that I can draw in the large brains of @mbarton @pacharanero @dc2007git and @anchit-chandran

[wardle]

Important to note that in my usage, I use a single server - and don't use multiple servers/docker images. I could.. IF I needed to scale, but I don't yet. I keep versioned data files on one server, and then in my deployment configuration I update the version and everything just updates on every deployment of new code. I've just automated the whole pipeline to stop myself making mistakes, and don't try to run multiple servers.

[wardle]

And I have used caddy quite nicely to do atomic switches between new services running on different ports. But YMMV.