Inconsistent behavior using docker-compose

[neatnerd]

Issue:

When trying to access /api(http://localhost:12345) from the host machine, not a single page loads with the response:

localhost didn’t send any data.
ERR_EMPTY_RESPONSE

Steps to replicate: Chrome: Version 87.0.4280.88 (Official Build) (64-bit) OS: Windows, Docker for Windows 3.0.0 (50684), Engine: 20.10.0, WSL2 (20.04.1 LTS) Overpassversion: tested both on 0.7.56 and latest tag

The following docker command works as described in the documentation works:

docker run \
  -e OVERPASS_META=yes \
  -e OVERPASS_MODE=init \
  -e OVERPASS_PLANET_URL=http://download.geofabrik.de/europe/austria-latest.osm.bz2 \
  -e OVERPASS_DIFF_URL=https://download.openstreetmap.fr/replication/europe/austria/minute/ \
  -e OVERPASS_RULES_LOAD=10 \
  -v /home/neatnerd/backend/data/overpass/:/db \
  -p 12345:80 \
  -i -t \
  --name overpass_austria wiktorn/overpass-api

The following docker-compose file does not work:

version: "3"

services:
  overpass:
    image: wiktorn/overpass-api
    ports: 
      - "12345:8080"
    volumes:
      - ./data/overpass/:/db
    environment: 
      - OVERPASS_META=yes
      - OVERPASS_MODE=init
      - OVERPASS_PLANET_URL=http://download.geofabrik.de/europe/austria-latest.osm.bz2
      - OVERPASS_DIFF_URL=https://download.openstreetmap.fr/replication/europe/austria/minute/
      - OVERPASS_RULES_LOAD=10

I have tried to switch off the firewall and anti-virus. The most strange behavior is that I believe the page pops up on startup and then goes down, but this might be browser cache.

Logs

Starting supervisord process

2020-12-25 08:49:30,870 CRIT Supervisor running as root (no user in config file)
2020-12-25 08:49:30,872 INFO supervisord started with pid 1
2020-12-25 08:49:31,875 INFO spawned: 'overpass_dispatch' with pid 10
2020-12-25 08:49:31,877 INFO spawned: 'nginx' with pid 11
2020-12-25 08:49:31,880 INFO spawned: 'fcgiwrap' with pid 12
2020-12-25 08:49:31,884 INFO spawned: 'update_overpass' with pid 13
2020-12-25 08:49:31,889 INFO spawned: 'dispatcher_areas' with pid 14
2020-12-25 08:49:31,892 INFO spawned: 'areas_rules' with pid 15
/app/bin /
/db/diffs/changes.osm exists. Trying to apply again.
XML parsing error at line 3, column 0: no element found
2020-12-25 08:49:32,929 INFO success: overpass_dispatch entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-12-25 08:49:32,929 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-12-25 08:49:32,929 INFO success: fcgiwrap entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-12-25 08:49:32,929 INFO success: update_overpass entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-12-25 08:49:32,929 INFO success: dispatcher_areas entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-12-25 08:49:32,929 INFO success: areas_rules entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="Overpass API 0.7.56.3 eb200aeb">
<note>The data included in this document is from www.openstreetmap.org. The data is made available under ODbL.</note>
<meta osm_base="2020-12-23T23:31:53Z" areas="2020-12-23T23:31:53Z"/>
After 0h0m15s: in "recurse", part 0, on line 26. Stack: 0 of 0 518 of 0 0 of 0
After 0h0m30s: in "recurse", part 0, on line 27. Stack: 0 of 0 1449 of 0 0 of 0
After 0h0m45s: in "make-area", part 0, on line 29. Stack: 0 of 0 2394 of 0
After 0h1m0s: in "recurse", part 0, on line 27. Stack: 0 of 0 3255 of 0 0 of 0
/db/diffs/changes.osm exists. Trying to apply again.

Desired behavior

Docker-compose settings shall result in the same outcome as running individual docker commands

[wiktorn]

If it works under docker, but doesn't under docker-compose, why do you think the problem is with the image?

I guess the problem is with this line:

    ports: 
      - "12345:8080"

[neatnerd]

it is not with that line, you can specify port mapping as a string or as a pair. I tried both.

[neatnerd]

Saw only now that the port wrongly mapped to 8080 instead of 80, thanks