WebThing in docker-compose.yml

eldpcn commented 3 years ago

When i'm running 'docker-compose up -d', all containers are pulling successfully, but this one. I checked WebThings website, they are referencing different container ('webthingsio/gateway', not 'mozillaiot/gateway:arm'). I am currently on latest version of 'master' branch.

eldpcn commented 3 years ago

They changed their docker hub name, you can see it clearly when checking links on https://iot.mozilla.org/gateway/ and https://webthings.io/gateway/

Paraphraser commented 3 years ago

Please see This Project Is Dormant.

If you migrate to the new repo at SensorsIot/IOTstack, the service definition on the master branch is:

webthingsio_gateway:
  image: webthingsio/gateway:latest
  container_name: webthingsio_gateway
  network_mode: host
  ports:
  - "4060:4060"
  - "4061:4061"
  volumes:
    - ./volumes/webthingsio_gateway/share:/home/node/.mozilla-iot

The migration process involves what is being called "the new menu" offering you the chance to stay with "the old menu", which has the look and feel of the menu in gcgarner/IOTstack.

Personally, I'm still running old menu because there are far too many whiskers on new menu for my liking.

The "whiskers" have zip to do with the menu system as such. They are in the data-comms area and have to do with interoperability between containers.

To bring yourself up-to-date and maximise your chances of having a quiet life, I'd normally recommend switching to SensorsIot/IOTstack but keeping the old menu. The problem with that is the webthings_gateway service definition under old menu is the same as gcgarner so you'd be no further in front:

  webthings_gateway:
    image: mozillaiot/gateway:arm
    container_name: webthings_gateway
    network_mode: host
    #ports:
    # - 8080:8080
    # - 4443:4443
    #devices:
    # - /dev/ttyACM0:/dev/ttyACM0
    volumes:
      - ./volumes/webthings_gateway/share:/home/node/.mozilla-iot

It boils down to you having three options:

Stay on gcgarner but edit your docker-compose.yml.
Switch to SensorsIot old-menu branch and edit your docker-compose.yml.
Switch to SensorsIot master branch (which is the new menu).

In each case, editing docker-compose.yml comes with two options:

Just change the image definition to webthingsio/gateway:latest, or
Adopt the whole new-menu service definition (the first chunk above).

I don't run webthings so I don't have any practical experience to offer. The container runs in host mode which means port mappings are ignored. The old service definition refers to ports 8080 and 4443 but comments them out. The new service definition refers to ports 4060 & 4061 without commenting them out. Normally, the only reason to include port mappings and host mode is to signal (a) "this is what will take effect if you take the container out of host mode", and (b) "the right hand sides of the port mappings are the ports the container actually listens on", implying those are the RPi ports the container will bind to in host mode.

I'm mentioning all this because I don't think it's necessarily the case that just switching the image definition will work first time. The new image may also result in the ports changing too and that may well affect your downstream processes.

If it were me, I'd try to figure out if webthings_gateway actually needs host mode. A lot of containers running in host mode seem to be that way because whoever set them up didn't ask this question. I think a lot of people have either confused host mode with the privileged flag or were chasing a problem for which they thought host mode the answer, it wasn't, but they didn't undo the change.

If webthings_gateway will run in non-host mode (just leave the network_mode line out) then you can probably map 8080 and 4443 to 4060 and 4061, run from the current image, and otherwise keep truckin'.

If you figure out the answer to the host mode vs port mappings questions then maybe file a Pull Request to lock that into place. One of the benefits of doing that is that you can apply the pending PR to your own local copy of the repo while you are waiting for the PR to be applied. The how-to is at the end of the gist.

Please try to remember to close this issue.

Paraphraser commented 3 years ago

A journey (for no reason other than that I was intrigued).

Starting point:

SensorsIot/IOTstack
old-menu branch
existing IOTstack up and running

Check whether any of the ports of interest are responding:

$ for P in 8080 4443 4060 4061; do testPort 127.0.0.1 $P; done
Port 8080 rejected
Port 4443 rejected
Port 4060 rejected
Port 4061 rejected

No. So there are no potential port conflicts with what I am about to do.

Add the new-menu (master branch) service definition to my existing docker-compose.yml:

  webthingsio_gateway:
    image: webthingsio/gateway:latest
    container_name: webthingsio_gateway
    network_mode: host
    ports:
    - "4060:4060"
    - "4061:4061"
    volumes:
      - ./volumes/webthingsio_gateway/share:/home/node/.mozilla-iot

Bring up the stack:

$ UP webthingsio_gateway
Pulling webthingsio_gateway (webthingsio/gateway:latest)...
latest: Pulling from webthingsio/gateway
d5029e4b3870: Pull complete
72ecdaf276e3: Pull complete
0acfe405c5ff: Pull complete
5b988493015e: Pull complete
f2ead6a61459: Pull complete
e226b9562a29: Pull complete
149b249a1aec: Pull complete
49b0d2016acf: Pull complete
a7db51136732: Pull complete
68a8f626aefd: Pull complete
eafb176d9478: Pull complete
Digest: sha256:7d954d6f6e4826f6a7adc0d7d40842f46694a55bb806b7b11edcedf203d58c23
Status: Downloaded newer image for webthingsio/gateway:latest
Creating webthingsio_gateway ... 

ERROR: for webthingsio_gateway  "host" network_mode is incompatible with port_bindings

••• followed by a whole lot of traceback guff that I've omitted

Respond to the error message by editing the service definition to be:

  webthingsio_gateway:
    image: webthingsio/gateway:latest
    container_name: webthingsio_gateway
    network_mode: host
#   ports:
#   - "4060:4060"
#   - "4061:4061"
    volumes:
      - ./volumes/webthingsio_gateway/share:/home/node/.mozilla-iot

Try again:

$ UP webthingsio_gateway
Creating webthingsio_gateway ... done

Looks good. What ports are defined for the image:

$ docker image inspect webthingsio/gateway | jq '.[0].Config.ExposedPorts'
{
  "4443/tcp": {},
  "8080/tcp": {}
}

No mention of 4060 or 4061. What ports are actually in use:

$ for P in 8080 4443 4060 4061; do testPort 127.0.0.1 $P; done
Port 8080 responding
Port 4443 rejected
Port 4060 rejected
Port 4061 rejected

Under master branch (ie new menu), the template includes this:

$ cat ~/IOTstack/.templates/webthings_gateway/local.json 
{
  "ports": {
    "https": 4061,
    "http": 4060
  }
}

Find where that turns up in the running configuration. It will usually be in either:

~/IOTstack/services/webthingsio_gateway or
~/IOTstack/volumes/webthingsio_gateway

There's no mention of services in the service.yml file so that only leaves volumes.

Hunt around … find …

$ cat ~/IOTstack/volumes/webthingsio_gateway/share/config/local.json 
{
}

Seems like a reasonable candidate. Replace it with the version from the template and give the container a kick:

$ RESTART webthingsio_gateway
Restarting webthingsio_gateway ... done

What's the port situation now?

$ for P in 8080 4443 4060 4061; do testPort 127.0.0.1 $P; done
Port 8080 rejected
Port 4443 rejected
Port 4060 responding
Port 4061 rejected

It's had some effect but why only 4060? Let's take the container out of host mode and reinstate the 1:1 port mapping from the template. Definition is:

  webthingsio_gateway:
    image: webthingsio/gateway:latest
    container_name: webthingsio_gateway
#   network_mode: host
    ports:
    - "4060:4060"
    - "4061:4061"
    volumes:
      - ./volumes/webthingsio_gateway/share:/home/node/.mozilla-iot

Give it a kick:

$ UP webthingsio_gateway
Recreating webthingsio_gateway ... done

Port situation?

$ for P in 8080 4443 4060 4061; do testPort 127.0.0.1 $P; done
Port 8080 rejected
Port 4443 rejected
Port 4060 responding
Port 4061 responding

Both 4060 and 4061 responding. Curious. Wonder why that didn't work when the container was running in host mode?

It's possible that the answer to this question lies in the RESTART webthingsio_gateway and that I should have done a RECREATE webthingsio_gateway but I have not tested that theory.

Anyway, let's try re-mapping with the original ports. Definition now:

  webthingsio_gateway:
    image: webthingsio/gateway:latest
    container_name: webthingsio_gateway
#   network_mode: host
    ports:
    - "8080:4060"
    - "4443:4061"
    volumes:
      - ./volumes/webthingsio_gateway/share:/home/node/.mozilla-iot

Give it a kick:

$ UP webthingsio_gateway
Recreating webthingsio_gateway ... done

Port situation:

$ for P in 8080 4443 4060 4061; do testPort 127.0.0.1 $P; done
Port 8080 responding
Port 4443 responding
Port 4060 rejected
Port 4061 rejected

Both responding. We have the expected ports from gcgarner mapping through to the ports for new-menu SensorsIot. Bingo!

So, that seems to be the magic sauce:

Take service.yml and local.json from the template on the master branch of SensorsIot/IOTstack.
Insert service.yml into docker-compose.yml but comment-out the port mappings.
Instantiate the container so that the persistent storage gets populated.
Replace the empty local.json in the persistent storage area with the version from the template.
Take the container out of host mode and change the port mappings so 8080->4060 and 4443->4061.
Re-create the container with an "up".

This strategy will work with either old- or new-menu. The trick would be to update to SensorsIot on the old-menu branch, then switch to new-menu:

$ git checkout master

for long enough to get the template files, then switch back:

$ git checkout old-menu

As noted before, it's not the menu that's the problem but the impact the master branch has on data-comms. Overall, SensorsIot is more gcgarner-like under the old-menu branch. As long as:

$ cd ~/IOTstack
$ ./menu.sh

occurs under old-menu you should be fine.

Hope all this helps.

If you're wondering, my "commands" like UP, RESTART and RECREATE come from this gist.

The "testPort" command is a small script in my local bin folder:

#!/bin/bash

if [ $# -ne 2 ] ; then
   echo "Usage: testPort ipaddr port"
   exit -1
fi

if nc -w 1 "$1" "$2" ; then
   echo "Port $2 responding"
else
   echo "Port $2 rejected"

It's possible that the error message:

ERROR: for webthingsio_gateway  "host" network_mode is incompatible with port_bindings

is the result of me using an updated version of docker-compose. IOTstack (gcgarner or SensorsIot, old or new menu) installs v1.21.0 while the most up-to-date version is 1.27.4. See this gist.

Paraphraser commented 3 years ago

That service definition probably also needs a restart policy, as in:

  webthingsio_gateway:
    image: webthingsio/gateway:latest
    container_name: webthingsio_gateway
#   network_mode: host
    ports:
    - "8080:4060"
    - "4443:4061"
    volumes:
      - ./volumes/webthingsio_gateway/share:/home/node/.mozilla-iot
    restart: unless-stopped

eldpcn commented 3 years ago

Hi, Thanks for help, i am successfully running WebThings container now. According to this network="host" might be necessary in some usecases, but for basic use you won't need it. Unfortunately i don't have time and resources to test all Add-ons, so cannot answer when it is a must-have.

gcgarner / IOTstack

WebThing in docker-compose.yml #224