Community Health Toolkit

Docker deployment ends with nginx 404 error

Containers DO start with a workaround (below) but application inside the container does not fire up.

Cause of the Github version not working is in docker compose file, its structure is in out of date format and cannot be executed in up-to-date environments. This should be maintained at some point, it’s more urgent to get working version and documentation in order to fix this.

Skip middle layer (compose.yml) and set up objects and containers natively via bash cli to get containers up & running


docker volume create haproxy
docker run -it -d --name haproxy -p 5984:5984 -p 5985:5985  --mount type=volume,source=haproxy,target=/srv -w /srv --network medic-net --hostname medic-os -e COUCHDB_HOST=medic-os -e HA_PASSWORD=$DOCKER_COUCHDB_ADMIN_PASSWORD medicmobile/haproxy:rc-1.16

docker volume create medic-data
docker run -it -d --name medic-os -p 8080:80 -p 8443:443 -p 5987:5987 --mount type=volume,source=medic-data,target=/srv -w /srv -e DOCKER_NETWORK_NAME=haproxy -e DOCKER_COUCHDB_ADMIN_PASSWORD=$DOCKER_COUCHDB_ADMIN_PASSWORD --network medic-net medicmobile/medic-os:cht-3.7.0-rc.1

Running containers created via cli:

q-user@vh-be-box:~$ docker ps

CONTAINER ID        IMAGE                                 COMMAND                  CREATED             STATUS              PORTS                                                                 NAMES
4447d09986bc        medicmobile/medic-os:cht-3.7.0-rc.1   "/bin/bash -l /boot/…"   10 hours ago        Up 10 hours>5987/tcp,>80/tcp,>443/tcp   medic-os
c9de2cceeab8        medicmobile/haproxy:rc-1.16           "/ -f /…"   10 hours ago        Up 10 hours>5984-5985/tcp                                      haproxy

Post install tasks as described in documentation does nothing nor give any output, that is probably the cause of the problem:

docker exec -it medic-os /bin/bash -c "sed -i 's/--install=3.7.0/--complete-install/g' /srv/scripts/horticulturalist/postrun/horticulturalist"

This is the end result I see, working containers with no webapp available:

How to reproduce?

  1. Create standard vanilla Ubuntu basehost with Docker inside
  2. Create volumes & containers
  3. Execute postinstall tasks as described in documentation
  4. Open http(s)://hostIp to see image above
1 Like

Hi Martin! Thanks for opening this issue.

I went ahead and tested our docker-compose.yml from our documentation on a new Ubuntu 18.04 64-bit server using docker-compose v1.25.0 and everything installs correctly on the latest versions.

Can you provide the following details:

  • Ubuntu version

Distributor ID: Ubuntu
Description: Ubuntu 18.04.3 LTS
Release: 18.04
Codename: bionic

  • docker-compose version

docker-compose version 1.25.0, build 0a186604
docker-py version: 4.1.0
CPython version: 3.7.4
OpenSSL version: OpenSSL 1.1.0l 10 Sep 2019

In the mean time, your workaround using CLI commands has some ports incorrectly mapped. Here are some helpful tips if you wish to use docker cli:

  • You are mapping 8080 from your host to the containers port 80. Can you verify you are visiting the app at https://hostip:8080 ?
  • haproxy container should use medic-data volume
  • You don’t need to map haproxy ports to the outside, if they are on the same docker network (medic-net), the other container will be able to talk to it
  • You don’t need to map 5987 to anything. If you wish to expose medic-api directly, you can map 5988.
  • Note: It takes some time for medic-api to boot up after installation seems finished.

With these fixes to your CLI command, the webapp should become available. The post-install task you referenced is just cleanup for container restart scenarios. It has no impact on install. We can open up a PR to clarify the documentation.

Please let me know if there is still trouble getting up and running.


Hi Haaret

Thank you for feedback and data. I now think that there’s a semantic question about versions that we’d should dig for a bit.
Ubuntu base is same as you mentioned, 18.04.03 LTS and it is in latest state, updated vanilla host :

q-user@vh-be-box:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.3 LTS
Release:	18.04
Codename:	bionic

As it comes to Docker & it’s tools, things differ, and the reason seems to be in how Docker is exactly deployed according to their Official KB

By using Docker’s “convenience script”, Edge version is installed and this was the case with initial thread report. Double checked, latest-edge on vanilla Ubuntu gives docker-compose version 1.20:

q-user@vh-be-box:~$ docker-compose -v
docker-compose version 1.20.0, build ca8d3c6

Therefore I tested Docker by using it’s primary deployment method of choise apt, that installs latest-stable version.
This gave me even older docker-compose:

root@vh-be-box:/home/q-user# docker-compose -v
docker-compose version 1.17.1, build unknown

As expected with lower version, with stable-latest docker-compose.yml gave still the same error as initially:

q-user@vh-be-box:~$ docker-compose up
ERROR: Version in “./docker-compose.yml” is unsupported. You might be seeing this error because You’re using the wrong Compose file version. Either specify a supported version (e.g “2.2” or “3.3”) and place your service definitions under the services key, or omit the version key and place your service definitions at the root of the file to use version 1.

Stable and Edge versions are only used in production or prestaging environments. I agree that things can be solved by tiding things up in documentation with those aspects, the processes become critical in every large infrastructure when adopting any kind of software and documentation should reflect that, sure we can PR if I can help.

I was following that leads to cht-core github project that has no Dockerfile I was trying to find for reverse-engineering, but Docker Hub images are built from medic-os project. Now I see that there is some additional documentation directly in medic-os github project.

Thank You for comments about cli, indeed I made error with volume names to be mounted. Extra port was due to a test I made.
Good tip about opening 5988, are there some other interfaces that could opened or closed optinally to help debugging while running prebuilt images “manually” with “docker run -it -d …”? CouchDB had also some management URL, _utils?

Now, with a modifications made in host environment and versions, this is the working cli version destilled from docker-compose file and feedback from You that shoots up frontpage of webapp:

docker volume create medic-data

docker run -it -d --name medic-os  -p 8080:80 -p 8443:443 --mount type=volume,source=medic-data,target=/srv -w /srv -e DOCKER_NETWORK_NAME=haproxy -e DOCKER_COUCHDB_ADMIN_PASSWORD=$DOCKER_COUCHDB_ADMIN_PASSWORD --network medic-net medicmobile/medic-os:cht-3.7.0-rc.1

docker run -it -d --name haproxy --mount type=volume,source=medic-data,target=/srv -w /srv --network medic-net -e COUCHDB_HOST=medic-os -e HA_PASSWORD=$DOCKER_COUCHDB_ADMIN_PASSWORD medicmobile/haproxy:rc-1.16

hostip:8443 shows Web UI now :slight_smile:


  1. Install Ubuntu Server 18.04 LTS
  2. Install Docker stable (including docker-compose. Docker Official stable installation does not include docker-compose, Edge does)
  3. CLI workaround
  4. Open UI


1 Like

Awesome, Martin! Great questions. Let’s certainly clarify our documentation with specifics. We could definitely use all the PRs you are able to submit.

One of our big goals for Q1 this year is to complete the container architecture the way you deduced. We want to get rid of medic-os completely, and have Dockerfiles for individual containers that would reside in our main repo.

Here is the GitHub issue that covers this topic:

We still need to create sub-issues related to our horticulturalist and couch2pg repositories for containers for those services before we can completely destroy medic-os. Here is my WIP branch if you want to peak at how we are constructing Dockerfiles, entrypoints for some of the services etc:

All the help is more than welcome if you wish to hop into containerizing one of those issues/services. I can invite you to our Slack if wish to discuss details or time commitments for any of our infrastructure-related issues.

Also for debugging, https:<project_url>:<port>/_utils is open for CouchDB Fauxton access.

Looking forward to some PRs! Thanks again for discussing this issue.