-
Notifications
You must be signed in to change notification settings - Fork 463
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
Running IoT Edge from within a container #7161
Comments
keyd, certd and identityd authenticate their clients via their UIDs, which won't work if the client isn't in the same userns. edged's workload socket authenticates its clients via their PIDs, which won't work if the client isn't in the same pidns. A docker-in-docker setup, ie a setup where all i-i-s and iotedge services run in the same container and a nested dockerd runs in the same container, might work. The setup you tried, with dockerd running on the host, won't.
This worked because you configured iotedged to use TCP instead of UDS for the workload socket, in which case iotedged did not do any authentication. This had always been a "not-for-production" feature (it used to be needed for Windows before Windows gained its own UDS support), and was eventually removed. It won't work in 1.4 |
Well, I appreciate you telling me straight away this approach I'm trying won't work as is. Saves me quite a bit of time experimenting on this approach. I did consider a docker-in-docker setup. I just thought it might be clunky if a container/module needs access to something on the host like files, or hardware peripherals, or such. I suppose I could pass this into the docker-in-docker container then from there into the needed containers. Not ideal, but still a path forward perhaps. In any case thanks again for the input, I'm aware this is quite a niche use-case. |
@jsrc27 are you okay with this issue being resolved? Want to make sure all questions were addressed :) |
Closing for now, let us know if you have additional questions and we can reopen |
Where it might not be a niche use-case: I would like to do integrated module tests without the need to spin up an IoTHub in Azure, or register devices with the hub, for development/testing scenarios. |
I realize this is a bit of a niche use case but, perhaps someone here may be able to help or give me a hint on how to proceed here. In summary, as the title says I'm trying to run the IoT edge daemon from within a container, rather than on the host. In the past my colleagues and I were able to do this with something like this: https://github.com/VMinute/torizon-azure-iot-edge/tree/master
Though this was on a now old version of IoT edge, and I'm trying to do something similar with the current version.
For context I'm running on an ARM64 embedded hardware based on the NXP i.MX8. The OS is a custom embedded OS created with Yocto, this OS does have Docker. I realize there is a meta-layer for IoT Edge but, again this is just an experiment to see if I can containerize this. Also if this is just doomed to not work, then that would be good to know as well.
Steps to Reproduce
docker run --privileged --rm -it --network=host --tmpfs /run --tmpfs /tmp -v /usr/bin/docker:/usr/bin/docker -v /var/run/docker.sock:/var/run/docker.sock aziot
iotedge config mp --connection-string '<PRIMARY CONNECTION STRING>
and theniotedge config apply -c '/etc/aziot/config.toml'
iotedge system status
and there are issues. (more details below)Context (Environment)
Output of
iotedge check
Click here
Device Information
Ubuntu 22.04.3
Runtime Versions
20.10.25-ce
Logs
aziot-edged logs
The text was updated successfully, but these errors were encountered: