# Docker build for Ripple OSI Demonstrator
**URL:** https://openhealthhub.org/t/docker-build-for-ripple-osi-demonstrator/160
**Category:** Ripple OSI
**Created:** [7 March 2016 15:31 UTC](https://openhealthhub.org/t/docker-build-for-ripple-osi-demonstrator/160 "2016-03-07T15:31:10Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@adrian.wilkins](https://openhealthhub.org/u/adrian.wilkins)
#### Post date: [7 March 2016 15:31 UTC](https://openhealthhub.org/t/docker-build-for-ripple-osi-demonstrator/160/1 "2016-03-07T15:31:10Z")
Have added a module to the Ripple OSI build that creates an archive that can be used to start a set of Docker containers ; here’s a pull request with the code.
[https://github.com/RippleOSI/Demonstrator/pull/1](https://github.com/RippleOSI/Demonstrator/pull/1)
This reduces the [lengthy instructions](http://dev.rippleosi.org/knowledgebase/server-installation-and-initial-setup/) required to set a copy of the service up to three steps (after [installing Docker and docker-compose](https://docs.docker.com/compose/install/))
1. Unpack the tarball
2. From the directory, as root, execute
- `MYSQL_ROOT_PASSWORD="choose_a_password" docker-compose up data`
- Wait for the terminal scrollback to stop (depends on your bandwidth)
- ``
- `docker-compose up`
- Add `-d` to run as a service
---
### Author:  [@mayfield.g.kev](https://openhealthhub.org/u/mayfield.g.kev)
#### Post date: [7 March 2016 15:46 UTC](https://openhealthhub.org/t/docker-build-for-ripple-osi-demonstrator/160/2 "2016-03-07T15:46:18Z")
How easy is it to work with Docker? We’re looking at it and I was wondering if it’s work turning that HAPI FHIR Server into a Docker container.
---
### Author:  [@adrian.wilkins](https://openhealthhub.org/u/adrian.wilkins)
#### Post date: [7 March 2016 15:55 UTC](https://openhealthhub.org/t/docker-build-for-ripple-osi-demonstrator/160/3 "2016-03-07T15:55:20Z")
I got this going with less than a working day’s effort, essentially from scratch with a level of experience with Docker of having previously created one container.
The Tomcat layer was essentially
- Take existing Tomcat container
- Copy the WAR into it
The only real complications were
- The instructions by default assume you’re putting all the processes on one machine - so you have to compensate for that by editing configs to use the container aliases
- The application layer needs a lot of environment variables setting (which replace the Tomcat context)
- The web app (like many of the new Web 2.0 things I have experimented with recently) wants to be the sole occupant of the root of a domain
- This means you _must_ add the Apache proxy layer on the top, even if you can just map the Tomcat HTTP port to port 80