The above are all you need to build a HealthShare 2018.1 docker imagine.
### 4.5 Build our first HealthShare Docker image
Now we simply start "Docker Quick Start Terminal", then run this command with the Terminal window, to build our first HealthShare Docker image labeled as "**hs:18.01**"
zhongli@UKE7450ZLEE MINGW64 /h/DockerHS2018
$ docker build --force-rm --no-cache -t hs:18.01 .
**Note**: It may take quite a while, up to 30-45 minute, for the first run. If there is an issue, you can simply re-run the above command and it will carry on from where it failed - the Dockerfile is still fairly bare and not fit for exception handlings, but the underlining build tool is fairly robust.
If the build is successful, the you can inspect the images that we just build by running "**docker image ls**"
> zhongli@UKE7450ZLEE MINGW64 /h
$ docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
hs 18.01 1d7f1216edc4 5 weeks ago 21.1GB
tutum/centos latest 99a633ad346f 3 years ago 297MB
### 4.6 Run our 1st HealthShare Container as a "global edition"
Now we can simply run our first HealthShare container application "**HSTEST**", by using a line of command below within the same Docker Terminal window:
docker run -d -p 57772:57772 -p 1972:1972 -e ROOT_PASS="linux" --name HSTEST hs:18.01 -i=HEALTHSHARE
This command will create a HealthShare container listening on port 1972 and 57772 of our Docker machine "Default" (default local IP 192.168.99.100 - can be configured):
> zhongli@UKE7450ZLEE MINGW64 /h
$ Docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
070028738c25 hs:18.01 "/ccontainermain -cc" 5 weeks ago Up 2 days 22/tcp, 80/tcp, 443/tcp, 0.0.0.0:1972->1972/tcp, 56772-56773/tcp, 57773-57774/tcp, 0.0.0.0:57772->57772/tcp HSTEST
Now we can certainly start to try all sort of HealthShare operations that we normally do for HealthShare demo/PoC/troubleshooting and all kind of configurations.
For example, we can quickly invoke the WebTerminal to run HealthShare's "InstallDemo()" utility, to set up those few common test patients for a quick issue etc:
![](/sites/default/files/inline/images/images/image2019-4-11_15-57-3.png)
To see the following HS components were created, and to invoke the CV with a test patient:
![](/sites/default/files/inline/images/images/image2019-4-11_16-14-2.png)
### 4.7 Run our 2nd HealthShare container as a "UK Edition"
By using the same image "HS:18.01", we can also create another HealthShare container, then configure it to be a "UK Edition 2018.1":
docker run -d -p 57792:57772 -p 1992:1972 -e ROOT_PASS="linux" --name HSUK hs:18.01 -i=HEALTHSHARE
Then we can see container "**HSUK**" is running on ports 1992 and 57792 of the Docker machine:
> $ Docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
68a78be76fac hs:18.01 "/ccontainermain -cc" 2 days ago Up 2 days 80/tcp, 443/tcp, 56772-56773/tcp, 57773-57774/tcp, 0.0.0.0:58892->22/tcp, 0.0.0.0:1992->1972/tcp, 0.0.0.0:57792->57772/tcp HSUK
070028738c25 hs:18.01 "/ccontainermain -cc" 5 weeks ago Up 3 days 22/tcp, 80/tcp, 443/tcp, 0.0.0.0:1972->1972/tcp, 56772-56773/tcp, 57773-57774/tcp, 0.0.0.0:57772->57772/tcp HSTEST
Now we can deploy our "HealthShare UK Edition 2018.1" into this Container instance, then use it for e.g. Testing and Training purpose, such as Clinicial Viewer V2 training - actually that's exactly what we did in our "HealthShare Engineering Week 2019" event.
So we can see a UK flavor of the HS 2018.1 CV2:
![](/sites/default/files/inline/images/images/image(96).png)
![](/sites/default/files/inline/images/images/image(97).png)
## 5 What's next
Docker container is indeed well fit for running many various flavors of HealthShare applications that are logically separated, and have a well consolidated foot print on the hard disk, apart from other well known DevOps advantages.
By comparing with VMs, its footprint is much smaller. An example is our "HealthShare UK Demo" which used to take about 90G to copy across without counting various snapshots. By using Docker images it would merely a few more Gs (on top of a 21G base HealthShare image) to accommodate all the UK specific classes, config and demo data. I also like the fact it only takes a few seconds to run from a pre-built image.
By comparing with direct installations, Docker certainly has the distinct advantages of "Portability", which is a common productivity boost. It would be slightly tricky (although do-able) to copy across a configured local instance to another laptop and make it running - but we do need quite a few hours to "hack" it through. A Docker image would save the day.
**Next**, we can simply commit various flavors of our above configured HealthShare containers into Docker images and exchange with other colleagues for further Dev, Tesing, Demo and Tourblehsooting purposes.
## 6 Acknowledgement
Thanks to Colin Fallon who worked out a good Dockerfile on his MacBook that really gave a boost here to finish off this long-due posting and make them all running better on my Docker Toolbox for Windows, in the hope to save a bit effort (no matter how little it is) for anyone who is interested in running HealthShare in Docker containers.
## 7 Caveats
1. HealthShare is not officially released for Docker Container yet. IRIS and IRIS Health are officially released as Docker certified applications, so we don't have to build their images from scratch anymore.
2. Docker Toolbox for Windows becomes a legacy application. You can simply use "Docker Desktop for Windows" to build your own HealthShare images if it is working on your PC.