I know I need to include 127.0.0.1, but I don’t know what the [::1] means, and I don’t know if I have to leave the existing openrem and nginx there, or replace them with something else.
[::1] is local host in IPv6.
Having more than you need in there is fine. I agree that the text could be more helpful. What you need (I think) is the servername that clients will be using, but I need to check that it doesn’t need the container name for the in-Docker networking.
I’ll do some testing.
Running docker-compose up -d results in the following error on my Windows 10 Pro laptop:
D:\docker\OpenREM1.0dev>docker-compose up -d
openrem10dev_broker_1 is up-to-date
openrem-orthanc-1 is up-to-date
openrem-db is up-to-date
openrem10dev_worker_1 is up-to-date
openrem is up-to-date
openrem10dev_flower_1 is up-to-dateStarting openrem-nginx ...
Starting openrem-nginx ... error
ERROR: for openrem-nginx Cannot start service nginx: driver failed programming external connectivity on endpoint openrem-nginx (7df2d279e87d0ba75a56620ca149709c786d3c6afd9738213181520800f1b91f): Error starting userland proxy: listen tcp 0.0.0.0:80: bind: An attempt was made to access a socket in a way forbidden by its access permissions.
ERROR: for nginx Cannot start service nginx: driver failed programming external connectivity on endpoint openrem-nginx (7df2d279e87d0ba75a56620ca149709c786d3c6afd9738213181520800f1b91f): Error starting userland proxy: listen tcp 0.0.0.0:80: bind: An attempt was made to access a socket in a way forbidden by its access permissions.
ERROR: Encountered errors while bringing up the project.
I’ve cleaned out my other Docker containers and images, and still get this error.
What happens if you change it to a high port - in docker-compose.yml in the nginx section change the ports from 80:80 to 8080:80
Did it let you bring Orthanc up on port 104? In which case I wonder if you are running IIS or something, and the port is already in use. There’ll be some sort of netstat command you can run to see.
I’ve run a netstat command and found the PID of the process on port 80, but it’s not IIS. It’s a system process that I can’t track down (netstat -n -a -o). It’s ntoskrnl.exe that is using the port, located in C:\Windows\System32.
Changing this bit of the docker-compose.yml from
And presumably as it was a clash rather than a high-port/low-port thing, it might work on 81 or similar too?
It is a clash, so would work on 81 or similar.
I’m now trying to upgrade using a 0.10.0 backup database.
The command docker cp /path/to/openremdump.bak db_backup/
@Ed McDonagh my Orthanc container won’t start. How do I trouble-shoot it?
PS D:\docker\OpenREM1.0dev> docker container list
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
158b449c2f5d nginx:1.17.8-alpine "nginx -g 'daemon of…" 2 days ago Up 45 hours 0.0.0.0:8080->80/tcp openrem-nginx
af13d80272e1 openrem/openrem:develop "/home/app/openrem/e…" 3 days ago Up 45 hours 8000/tcp openrem
784f83f47c3f openrem/openrem:develop "/home/app/openrem/e…" 3 days ago Up 45 hours 5555/tcp openrem10dev_flower_1
975c6a1415d2 openrem/openrem:develop "/home/app/openrem/e…" 3 days ago Up 45 hours openrem10dev_worker_1
b69695875b0b openrem/orthanc "/bin/bash -c 'apt-g…" 3 days ago Restarting (100) 19 seconds ago openrem-orthanc-1
5a74ce55d787 postgres:12.0-alpine "docker-entrypoint.s…" 3 days ago Up 45 hours 5432/tcp openrem-db
70aca4af0b1c rabbitmq:3-management-alpine "docker-entrypoint.s…" 3 days ago Up 45 hours 4369/tcp, 5671-5672/tcp, 15671-15672/tcp, 15691-15692/tcp, 25672/tcp openrem10dev_broker_1
Get logs for the orthanc container with docker-compose logs -f orthanc_1 see if that gives you a clue.
The name we use is that of the service we define in the docker-compose.yml file, so orthanc_1.
for the vanilla
in the orthanc_1 section of docker-compose.yml has made it work for me. It must be related to the package update and installation in the openrem/orthanc container. However, the logs indicate that the updating had worked.
Actually, the Dockerfile contents for openrem/orthanc is:
RUN apt-get update && apt-get -y install zip unzip
It doesn’t actually tell Orthanc to run, it just runs an apt update and install.
Should there be a CMD in there at the end to specify which command to run within the container?
Assuming your openrem/orthanc image wasn’t old, it shouldn’t have made any difference. Can you see how old that image is (docker images) - and if it is more than 14 days old can you pull a new one and try it again? (docker pull openrem/orthanc)
The Dockerfile simply adds zip and unzip to the main release. I’m considering removing the functions so it isn’t necessary!
Hi David. Can you pull latest in again, and see if it now works for you? (docker pull openrem/orthanc:latest)
I have triggered a new build, and presumably the Osimis image has been updated because it only used the first two layers from cache. I have no idea what went wrong with the last one, obviously something did!
It now works for me again, specifying openrem/orthanc:latest in the docker-compose.yml file.
This works for me now - thanks.
I’ve set up a test Docker-based OpenREM system on a new server running Windows Server 2019.
At the moment I have installed Docker Desktop.
I’ve created a scheduled task to start Docker Desktop on boot. At the moment this is running as my local user - I need to get it running using the SYSTEM account.
When the system reboots OpenREM comes back to life. However, Celery does not. This is because the celery.pid file still exists in the logs folder.
Is there scope to delete celery.pid as part of the start up of OpenREM?
I have written a basic batch file that deletes logs\celery.pid before Docker Desktop is started. Hopefully this will fix the problem for me.
I thought I had dealt with that, but I obviously haven’t.
Can you disable the batch file that deletes the pid file, and modify the docker-compose.yml file as follows:
worker:command:celery worker -A openremproject -Q default --logfile=/logs/celery.log
i.e. to remove the --pidfile flag.
Then try again
@Ed McDonagh that worked - thanks. I just have to work out how to get Docker to launch at boot as the SYSTEM user rather than as me (my password will change at some point).
I also think that I should be using Docker Enterprise instead of Docker Desktop - that’s probably the answer.
For my Windows Server 2019 Docker installation port 80 worked for the webserver: