Dockerfile/docker-compose do not work for Arches v5

[benosteen]

Describe the bug A large number of dependencies, python version and necessary systems have been updated for Arches version 5, and the Dockerfile and docker-compose need to be updated.

To Reproduce Steps to reproduce the behavior:

1. docker build .

or

1. docker-compose up

[rlmarsh85]

Any updates on this issue? I have been trying to get a basic Arches instance started using docker-compose and running into multiple errors, probably related to this item.

[benosteen]

@rlmarsh85 I tried to put in a patch to help out but where I work has decided to not use Docker to deploy and to treat this as an older style application and do manual installs. It has too many installation quirks and some of the maintenance commands rely on having ssh access to a machine. Not much help to you I know, but it is not likely that I will contribute any more work on the Docker install side of things in the short to medium term at least.

[rlmarsh85]

@benosteen Thanks for the heads up. Do you happen to know if the docker-compose/Dockerfile was reliable in 4.4.3? At this stage I'm just trying to get a proof of concept going so I don't need the latest/greatest version.

[benosteen]

It should work. My advice is to spin up the elasticsearch container early and let that settle as some of the later versions tend to take some time getting ready and that can throw off the set up of Arches as it stands.

[rlmarsh85]

In the docker-compose some of the containers use depends_on wrt elasticsearch and other don't. Do you know if adding a depends_on directive for every container would be enough to defer startup until ES is really ready? Thanks for any advice. I am new to Docker and even newer to Arches.

[benosteen]

The elasticsearch app spins up quickly but does not accept connections until it has done its network checks and loaded various things. So, it appears like it is running, but it will block connections that wish to write to it, leaving it up to the client application to catch the error and try again. Arches setup_db process does not catch these errors and fails hard during the migration (which has components that try to connect to ES) and the script to start arches rolls on as it doesn't check for the success of this setup process. The end result is that you get a system that believes it is set up, but has failed to apply all the necessary db and ES migration steps to do so, so you get a system that is missing quite a bit.

[3j14]

To fix this, I propose to use elasticsearch's healthcheck:

curl --insecure --fail --silent http://elasticsearch:9200/_cluster/health?wait_for_status=green&timeout=50s

More on this here: https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-health.html

This could either be implemented in entrypoint.sh or inside the docker-compose.yml file. Docker compose will prevent arches from starting if any service it depends on is not healthy. A docker compose health check could look like this:

healthcheck:
  test: ["CMD", "curl", "-f", "http://elasticsearch:9200/_cluster/health?wait_for_status=green&timeout=10s"]
  interval: 30s
  timeout: 10s
  retries: 3

I suspect this also hinders docker hub from building new images?

[3j14]

Oh I just saw this

https://github.com/archesproject/arches/blob/2a6c14cff0d009dae4910c1d2ea770d5f521f6f5/docker/entrypoint.sh#L152

Looks like I'm late to the game and someone already implemented this.

[fishfree]

Still not working :-(