Stream: implementers
Topic: ig publisher as Docker image
Andrew Patterson (Jan 10 2018 at 05:02):
Has anyone looked into running the FHIR IG publisher as a docker image? I got one built - which turned out to relatively straightforward - and was wondering if there was any general interest in sticking it in docker hub?
So for instance, if the publisher was dockerised to fhir/publisher then the following
docker run /home/andrew/ig:/ig fhir/publisher
will process the implementation guide in /home/andrew/ig
No need to install jekyll, no dependency issues, runs the same on mac/linux/windows (in theory)
Grahame Grieve (Jan 11 2018 at 05:02):
does it get the latest IG Publisher?
Andrew Patterson (Jan 11 2018 at 05:04):
The publisher is baked into the docker image. So I would suggest the build process for the publisher could dockerise itself (as well as its normal publish steps) and push into dockerhub
Andrew Patterson (Jan 11 2018 at 05:05):
But the docker images themselves are versioned - so you also fetch fhir/publisher:3.0.1 for instance
Grahame Grieve (Jan 11 2018 at 05:06):
we don't want anything but the latest publisher to be used.
Grahame Grieve (Jan 11 2018 at 05:07):
I guess we could push a new docker at the end of the build process, though I have no idea how that would be done
Andrew Patterson (Jan 11 2018 at 05:07):
what CI/build server is being used?
Grahame Grieve (Jan 11 2018 at 05:07):
we use travis. @Josh Mandel maintains the build script
Andrew Patterson (Jan 11 2018 at 05:08):
its pretty much
docker build . -t fhir/publisher
docker push fhir/publisher
Andrew Patterson (Jan 11 2018 at 05:09):
we're just starting to use travis for our stuff so let me have a play and I'll report back how it goes - we are just having our own private docker image for the moment (mgha/fhir_publisher)
Grahame Grieve (Jan 11 2018 at 05:09):
ok
Grahame Grieve (Jan 11 2018 at 05:09):
thanks
Josh Mandel (Jan 11 2018 at 14:34):
We do run the publisher via Docker image for the automated Builder. Here's a link: https://github.com/hl7-fhir/auto-ig-builder/tree/master/images/ig-build
Josh Mandel (Jan 11 2018 at 14:34):
We actually don't use Travis in the IG publisher automatic builds.
Josh Mandel (Jan 11 2018 at 14:35):
It runs in GoogleKubernetes Engine, triggered by a GitHub webhook.
Grahame Grieve (Jan 11 2018 at 20:27):
Andrew is talking about the main build, building a docker for the IG publisher - that's a slightly different thing. But perhaps there is enough functional overlap to only do something once
Andrew Patterson (Jan 11 2018 at 22:45):
Yeah, perhaps I should actually be using the auto-ig-builder in which case a local version of the publisher is not needed. Once our ig has settled down I think I might do it that way. But for the moment we are doing broad changes and need to run builds locally.
So yes, along the lines of what has been done for ig-build but more focussed on running on local ig files bound into the container. And with the publisher.jar and all the relevant spec files etc baked into the Docker image. Then publish that Docker image itself to dockerhub. So rather than tell my team how to install jekyll etc (especially on windows) I could just get them to pull the latest image from dockerhub and it would all be setup with the latest publisher.jar, correct java and jekyll etc
Grahame Grieve (Jan 11 2018 at 22:51):
doesn't docker = vm? wou;dn't it be better to just can a single docker and have it get the latest igpublisher?
Andrew Patterson (Jan 11 2018 at 22:56):
Its not nearly as heavy as a vm. Whatever runs in docker is running just as a process on the host machine - but yes conceptually can be thought of like a vm - though at the end of the invocation the contents of the container are destroyed (only those files in a 'bound' filesystem are retained).
Getting the igpublisher dynamically is fine, but that fetch would happen on every invocation (unless the publisher too was a cacheable artifact)
Grahame Grieve (Jan 11 2018 at 23:03):
well, you should be able to do a HEAD on it
Andrew Patterson (Jan 11 2018 at 23:11):
But anything that is downloaded within the docker process is thrown out, unless it is in one of the directories bound from the host filesystem. So in the way I am running it, I bind only the ig directory root itself into the container and only those files are retained after the process ends. So that means the txcache is still useful, but everything else is either baked into the image or dynamically fetched and then discarded.
Josh Mandel (Jan 17 2018 at 22:41):
I'm still confused about whether we're talking about the IG publisher (what I originally thought) or the main build (which Grahame said in response to my comment).
Andrew Patterson (Jan 18 2018 at 03:07):
I'm suggesting that at the end of building an IG publisher jar version (is this the main build??), should be a step to build a Docker image of the publisher (and jekyll etc) and push that to dockerhub (in addition to whatever the process of building the IG publisher is currently doing, uploading the jar to a website etc)
Andrew Patterson (Jan 18 2018 at 03:09):
It would just be an alternative mechanism for giving people access to running the publisher (especially for those on windows machines where jekyll is a pain.. or even those who just don't normally run Ruby but who might want to run the publisher)
Andrew Patterson (Jan 18 2018 at 03:09):
(and by running the publisher I mean locally running the publisher - not using the remote service)
Andrew Patterson (Jan 18 2018 at 03:15):
as an example.. this is our current IG build process on travis - which takes advantage of a docker image we created for ourselves that includes jekyll and the ig.publisher.jar
before_install:
- docker login -u "$DOCKER_USERNAME" -p "$DOCKER_PASSWORD"
- docker pull mgha/fhir_publisher
install: true
script:
- cd ig; docker run -it --rm --name publish -v pwd:/ig mgha/fhir_publisher
But if I need one of our devs on a windows box to look at the IG I can get them to run that script locally and they get they equivalent result - without them needing to install anything (other than docker of course!)
John Silva (Feb 13 2018 at 15:04):
@Andrew Patterson - I found this Dockerfile that someone posted on GitHub; haven't tried it yet though (not familiar with creating Docker images):
https://github.com/robstwd/assorted-dockerfiles/blob/master/alpine-fhir-ig-publisher/Dockerfile
Andrew Patterson (Feb 13 2018 at 22:58):
Thanks. I had cobbled one together myself - but that one with alpine is better (and smaller!).
Last updated: Apr 12 2022 at 19:14 UTC
