Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Can custom modules and edgeHub run on the host network?

See original GitHub issue

Hi there,

I’m working on a project where we have one module that communicates with several other components at the edge over a LAN which the host machine is on. We have found that the simplest way for our custom module to communicate over LAN is to configure its Docker container to use the host network. In doing so, we ran into some issues, some of which resulted from leaving edgeHub on the azure-iot-edge network. We now have edgeHub configured to use the host network as well as our custom modules, but we are still experiencing reliability issues (albeit less frequent ones). What I’m wondering is if this network configuration is even an intended use case of iotedge at this point in time, or is this undefined behavior?

Expected Behavior

edgeHub and edgeAgent are able to seamlessly work with edgeHub and custom modules on the host network instead of the azure-iot-edge bridge network.

Current Behavior

The expected behavior works but inconsistently. Sometimes edgeHub fails regularly with errors that seem to center around connectivity to IotHub. The logs attached to this post seem to indicate the failure comes from edgeHub attempting and failing to perform a twin update.

Steps to Reproduce

At this point in time, after putting both edgeHub and our custom modules on the host network there have been no reliable, reproducible failures.

Device (Host) Operating System

Ubuntu 18.04

Architecture

amd64

Container Operating System

Linux containers

Runtime Versions

1.0.2

iotedged

iotedge 1.0.2 (f6fcdb2e24ac2af977e748e9f2b8a37245b92738)

Docker

Client: Version: 18.06.0-dev API version: 1.30 (downgraded from 1.37) Go version: go1.10.2 Git commit: daf021fe Built: Mon Jun 25 21:07:53 2018 OS/Arch: linux/amd64 Experimental: false Orchestrator: swarm

Server: Engine: Version: 17.06.2-ce API version: 1.30 (minimum version 1.12) Go version: go1.8.3 Git commit: a04f55b Built: Thu Sep 21 20:36:57 2017 OS/Arch: linux/amd64 Experimental: false

Logs

Note that these logs are only a snippet of about 24 hours of logs, but the same exact error occurred again and again, so only two iterations of the failure are included for brevity. https://gist.github.com/jackt-moran/9fff63acf47e26a7ae6cb04f7ee3e4fd