-
Notifications
You must be signed in to change notification settings - Fork 582
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WebThing in docker-compose.yml #224
Comments
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/ |
Please see This Project Is Dormant. If you migrate to the new repo at SensorsIot/IOTstack, the service definition on the
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:
It boils down to you having three options:
In each case, editing docker-compose.yml comes with two options:
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 If webthings_gateway will run in non-host mode (just leave the 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. |
A journey (for no reason other than that I was intrigued). Starting point:
Check whether any of the ports of interest are responding:
No. So there are no potential port conflicts with what I am about to do. Add the new-menu (
Bring up the stack:
Respond to the error message by editing the service definition to be:
Try again:
Looks good. What ports are defined for the image:
No mention of 4060 or 4061. What ports are actually in use:
Under
Find where that turns up in the running configuration. It will usually be in either:
There's no mention of Hunt around … find …
Seems like a reasonable candidate. Replace it with the version from the template and give the container a kick:
What's the port situation now?
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:
Give it a kick:
Port situation?
Both 4060 and 4061 responding. Curious. Wonder why that didn't work when the container was running in host mode?
Anyway, let's try re-mapping with the original ports. Definition now:
Give it a kick:
Port situation:
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:
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:
for long enough to get the template files, then switch back:
As noted before, it's not the menu that's the problem but the impact the
occurs under Hope all this helps. If you're wondering, my "commands" like The "testPort" command is a small script in my local bin folder:
It's possible that the error message:
is the result of me using an updated version of |
That service definition probably also needs a restart policy, as in:
|
Hi, |
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.
The text was updated successfully, but these errors were encountered: